The patterns we had established were as simple, basic, and "safe" as practical, and we advised and code-reviewed the mechanics of services/apps for the other teams, like using database connections/pools correctly, using async correctly, validating input correctly, etc (while the other teams were more focused on features and business logic). Low-level performance was not really a concern, mostly just high-level db-queries or sub-requests that were too expensive or numerous. The point is, there really wasn't much of anything for CodeQL to find, all the basic blunders were mostly prevented. So, it was pretty much all false-positives.

Of course, the experience would be far different if we were more careless or working with more tricky components/patterns. Compare to the base-rate fallacy from medicine ... if there's a 99% accurate test across a population with nothing for it to find, the "1%" false positive case will dominate.

I also want to mention a tendency for some security teams to decide that their role is to set these things up, turn them on, cover their eyes, and point the hose at the devs. Using these tools makes sense, but these security teams think it's not practical for them to look at the output and judge the quality with their own brains, first. And it's all about the numbers: 80 criticals, 2000 highs! (except they're all the same CVE and they're all not valid for the same reason)

It's possible, they exist, many such LEDs are probably manufactured in China ... but the legit ones are probably more expensive, and you may need a more recognizable brand to do some QA, and keep pressure on the factory to not slip quality or inputs.

Consider the cheap screwdriver included with the lamp in this story: unexpectedly, many were more faulty than the cheapest $4 screwdriver you'd find in any hardware store. The more stories you read about manufacturing stuff in China, the more you'll see very strange things. It's not about nationality or anything, it's an extreme kind of optimization. If you didn't catch it already, maybe you didn't really need what you thought you asked for ... they're just checking/optimizing

(The price doesn't bother me ... it's worth the much lower chance of leaking than alkaline, if you leave it in a remote or gadget for years. But I've come to think that rechargeable NiMH like eneloops are a better idea due to the voltage.)

https://arstechnica.com/gadgets/2021/10/windows-11-the-ars-t...

> ... the best rationale for the processor requirement is that these chips (mostly) support something called “mode-based execution control,” or MBEC. MBEC provides hardware acceleration for an optional memory integrity feature in Windows (also known as hypervisor-protected code integrity, or HVCI) that can be enabled on any Windows 10 or Windows 11 PC but can come with hefty performance penalties for older processors without MBEC support.

> Another theory: older processors are more likely to be running in old systems that haven’t had their firmware updated to mitigate major hardware-level vulnerabilities that have been discovered in the last few years, like Spectre and Meltdown

Kinda weird, if you think about it. But that seems to be the way it's heading.

So, I do often see deprecation warnings in CI output, and fix them. Am I a bad developer?

I think the mistake here is making some warnings default-hidden. The developer who cares about the user running their the app in a terminal can add a line of code to suppress them for users, and be more aware of this whole topic as a result (and have it more evident near the entrypoint of the program, for later devs to see also).

I think that making warnings error or hidden removes warnings as a useful tool.

But this is an old argument: Who should see Python warnings? (2017) https://lwn.net/Articles/740804/

EDIT: also see the Xperia 10 VII for a phone that isn't 2 years old (I haven't been keeping up, I buy phones to use for 4+ years)

I'd actually call that quite difficult. In the case of xz it was a quite high-effort "long con" the likes of which we've never seen before, and it didn't quite succeed in the end (it was caught before rolling out to stable distros and did not successfully exploit any target). One huge close call, but so far zero successes, over almost 30 years now.

But typo-squatting and hijacked packages in NPM and PyPI, we've seen that 100s of times, many times successfully attacking developers at important software companies or just siphoning cryptocurrency.

But instead, they asked to "hop on a call" which really grinds my gears, I've been asked this a few times in similar situations before. I guess there's two people here: the engineers who really hate this tactic, and the managers who - well, this is what they do. Of course it's the most reasonable thing?

I used Gentoo a lot, jeez, between 20 and 15 years ago, and the install guide guiding me through partitioning disks, formatting disks, unpacking tarballs, editing config files, and running grub-install etc, was so incredibly valuable to me that I have trouble expressing it.

For very simple software, most users use all the features. For very specialized software, there's very few users, and they use all the features.

> The claim is that it handles 80%+ of their use cases with 20% of the development effort. (Pareto Principle)

This is different units entirely! Development effort? How is this the Pareto Principle at all?

(To the GP's point, would "ls" cover 80% of the use cases of "cut" with 20% of the effort? Or would MS Word cover 80% of the use cases of postgresql with 20% of the effort? Because the scientific Pareto Principle tells us so?)

Hey, it's really not important, just an idea that with Postgres you can cover a lot of use cases with a lot less effort than configuring/maintaining a Kafka cluster on the side, and that's plausible. It's just that some "nerds" who care about being "technically correct" object to using the term "pareto principle" to sound scientific here, that bit is just nonsense.