I find this study interesting but wonder if the wording is specifically done to cause some sensationalism.
> However, there is a twist: for positions on distributed teams, the firm consistently hired more experienced workers, even after reopening. This divergence suggests that the firm’s hiring decisions were influenced by the complications of remote work rather than other macroeconomic trends.
They don’t consider (almost intentionally) that remote positions don’t have the same restrictions as in-person positions. Anyone meeting desired qualifications can be considered for a remote position. Only people willing to relocate to, or already live near, a target office and meet the qualifications can be considered for an in-person job. Remote positions therefore are likely to be more competitive and difficult for inexperienced candidates because the pool of candidates is far larger. The hiring manager is incentivized to pick the person they believe will contribute the most for the amount they’re willing to pay.
The findings about mentorship in-person may be true but it is strange to put that as the deciding reason. There are no details provided over how “quality” is quantified nor decided. Selecting a sample size of one firm to analyze in detail without looking at others to confirm this feels very flawed.
Some employers get tangled up in just the legal review process.
Once I asked permission to submit a patch to a project and it had quite an interesting email trail. It came down to a single question: if the patch was written during hours billed to a customer for the purpose of fixing a bug in a deliverable product, and the library being patched had to be recompiled and delivered with the source code, and the contract states that all work and intellectual property associated to the product would be transferred to the customer, do we have authority to release the patch in the public domain?
I frequently reference this exact meme to people whenever someone complains about complicated or difficult-to-write code. Now that’s you’ve made this project I suppose we have zero room to complain anymore!
Dang, haven’t read much on Julia as of late. I remember using it for a CS 300-level course around 2016 when learning about tokenizing and parsing as part of language fundamentals. Julia has undoubtedly made some significant performance improvements since then. Would love to see a follow-up that explores what, if anything, from this still holds true and what improvements can be made.
To answer the first question, a number of veteran independent researchers probably wouldn’t have touched such a system. Plenty of companies will send their lawyers after you if you tell them that you’ve discovered a vulnerability of some sort and wish to responsibly disclose. Even if you do things in good faith, the company has zero reason to assume the best from you and can hold a sword over your head by citing poorly-written laws that lean in their favor regarding computer fraud and abuse.
DoD does appear to offer a “Defense Industrial Base - Vulnerability Disclosure Program” for all public-facing DoD/DoW systems.[1] However, this might not include contractor-controlled assets or services. I cannot view the HackerOne page that it redirects to (login is required) to view more details.
SQLite did decently well but I think they should’ve done an additional benchmark with the database loaded completely into memory.
Since they’re using Go to accept requests and forwarding them to their SQLite connection, it may have been worthwhile to produce the same interface with Rust to demonstrate whether or not SQLite itself was hitting its performance limit or if Go had some hand in that.
Other than that, it’s a good demonstration of how a custom solution for a lightweight task can pay off. Keep it simple but don’t reinvent the wheel if the needs are very general.
Seems the installers hosted by them are fine. The links on the site have been changed to direct people towards Cloudflare R2 storage with various copies of malicious executables.
Looking forward to information down the line on how this came about.
Not exactly a supply chain compromise, as devs should be smart enough to update via a package manager such as winget and chocolatey, but it certainly fits for a watering hole attack.
Plenty of consumer-grade devices have had very lax security settings or backdoors baked in for purposes of “troubleshooting” and recovery assistance. It’s never been limited to foreign-made devices.
Security has never been part of the review process. The only time any agency has really cared is when encryption is involved, and that’s just been the FBI wanting it to be neutered so they can have their own backdoors.
The fatigue of the product (and sting of false promises) causes the negatives to overshadow anything positive to say.
reply