Theoretically ... in practice, Boeing's most rigorous days in the 80s and 90s were directed by empowered individuals in the manufacturing org, and when it went full "strict process only" in the 2000s and 2010s the quality fell.
I don't think that's due to following the process but rather systemic cultural issues. The process doesn't exist in a vacuum. There's a good faith meta process that needs to be followed to incrementally fix issues as they arise.
Bad faith actors and cultural dysfunction can break pretty much anything no matter how well thought out it might be.
It's also leaving out that system only works (worked) for building airplanes because it happens (happened) to be an industry with a hugely passionate workforce. Switch it to contracted out wage slaves and 'the system' doesn't work. Because the system never 'worked', many passionate people worked via sheer force of will/desire/care/investment into the final product. It was about the people all along.
When I update python version, python packages, container image, etc for a service, I take a quick look at CI output, in addition to the all the other checks I do (like a couple basic real-world-usage end-to-end usage tests), to "smoke test" whether something not caught by outright CI failure caused some subtle problem.
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.
The "Sony Xperia 5 V" (I have the previous "Sony Xperia 5 IV") has a headphone jack, takes a uSD card, and is somewhat compact. (And no silly camera cutout in the screen, it's in a reasonably small bezel.)
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)
According to the specs it's 154 x 68 x 8.6 mm and 182 grams, so it's more compact than most phones of 2025 but not really compact. My Samsung A40 is smaller and lighter but it's 4 years older.
For many years (20+?) Vietnam has had huge import tariffs on US/German/etc cars. It varies by origin country and engine displacement, but it's around 75% to 175%. Some trade agreements with other Asian countries result in much more reasonable tariffs for Asian brands, but some rich Vietnamese people have bought BMW or Merc with 150%+ tariff/tax. (I found it a bit mind-blowing.) So, it's pretty obvious why Asian made EVs are expected to "explode" in popularity over there. (I'm pretty sure the trend is already well underway, I know a retired guy there who replaced a Merc with a hybrid Mitsubishi (?) last year.)
> it wouldn't be hard to get a bad update into a package (xz did that)
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.
Certainly seems absurd to think that xz was the only target Jia Tan had been pursuing for years. Surely there were parallels initiatives to exploit other projects in the security chain.
The grievances were rather detailed and concise. The communication channel is right there already. The relevant Mozilla employee should have responded with a detailed and concise explanation, of either why the translator is wrong, or why mozilla messed up and how they will fix it. They should post for public and historical record.
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?
No it doesn't. It's extremely valuable with the scope it already has. These massive corporations do not operate the Wayback Machine nor the various (less controversial) public archives that IA hosts, and makes available at no cost, no login-wall, no cloudflare-infinite-captchas, etc.
FWIW the cool thing about gentoo was the "use-flags", to enable/disable compile-time features in various packages. Build some apps with GTK or with just the command-line version, with libao or pulse-audio, etc. Nowadays some distro packages have "optional dependencies" and variants like foobar-cli and foobar-gui, but not nearly as comprehensive as Gentoo of course. Learning about some minor custom CFLAGS was just part of the fun (and yeah some "funroll-loops" site was making fun of "gentoo ricers" way back then already).
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.
I still use Gentoo for that reason, and I wish some of those principles around handling of optional dependencies were more popular in other Linux distros and package ecosystems.
There's lots of software applications out there whose official Docker images or pip wheels or whatever bundle everything under the sun to account for all the optional integrations the application has, and it's difficult to figure out which packages can be easily removed if we're not using the feature and which ones are load-bearing.
I started with Debian on CDs, but used Gentoo for years after that. Eventually I admitted that just Ubuntu suited my needs and used up less time keeping it up to date. I do sometimes still pull in a package that brings a million dependencies for stuff I don't want and miss USE flags, though.
I'd agree that the manual Gentoo install process, and those tinkering years in general, gave me experience and familiarity that's come in handy plenty of times when dealing with other distros, troubleshooting, working on servers, and so on.
It probably applies better to users of software, e.g. 80% of users use just 20% of the features in Postgres (or MS Word). This probably only works, roughly, when the number of features is very large and the number of users is very large, and it's still very very rough, kinda obviously. (It could well be 80% / 5% in these cases!)
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.
reply