I think it's a reaction to many simpler advocates of Rust saying "it's unsafe and irresponsible of you to not use Rust, you can't write software in C or C++ or Zig (or Go?) and have memory unsafety and put your users at risk, it's not safe, you have to use Rust to be safe".
Freakin' safety. I like doing lots of unsafe things in life: rock climbing without gear (short bouldering sections on hiking trails), bicycling and skateboarding without a helmet, etc. I developed pretty good skills in all these things, and programming C too. What kind of life would be worth living with enforced perfect safety? Without developing skill in life's many un-safe activities?
So people want to emphasize that, if they shouldn't use non-Rust languages because their safety can't be guaranteed, well your safety using Rust isn't absolute, either. So you can't tell me I must use Rust, or the Rust rewrite of my favorite tools, to "be safe".
Do you recall the early rust web framework, that used a lot of "unsafe" "inappropriately" and had some vulnerabilities ... actix web? ... reminds me of the bun-in-zig situation, kinda makes the language's PR situation more complicated and tricky.
The high data rate cables all need to be stiffer. You can find good 100w or 240w charging cables with good flexibility, so that's a good reason to keep usb-2 data-speed but high-power charging cables.
The measure of a good high-power cable is the resistance. You can gauge it with a usb test load, typical usb power meter, and a usb-pd trigger (all can be pretty cheap, often you can find the trigger functionality combined with one of the other two). Calculate voltage drop for a given current by measuring both sides of the cable, or at least compare different cables with similar load.
But I found a "USB Cable Checker 2" by BitTradeOne which will directly measure and show the resistance in milli-ohms, very convenient! A very good cable measures 150 to 250 mOhm, the worse ones are 3 or 4 times that (at which point this device over-ranges around 1000 mOhm). You can really tell the difference with how some phones and laptops will slow their current draw after voltage droops.
If they can provide only 20% of the functionality and only 1% of the bugs, that's a compelling trade-off for many use-cases! (and a bit closer to the reality IMHO)
But you probably depend on over 500 open source libraries and tools, mostly ones you're not aware of. (Do you ever use a linux VM to run or just develop your stuff? Ever use git or curl etc? Did you know that tools and components in turn use other open-source libraries that you didn't pay for?) The main reason you use such things is so that you don't have to worry about this question.
You don't have to use Debian stable, if you'd prefer Ubuntu every 6 months, or Fedora (6 months? 9 months?), or even Arch Linux updated daily ...
I use Arch on my laptop, when I got it 2 years ago the amd gpu was a bit new so it was prudent to get the latest kernel, mesa, everything. Since I use it daily it's not bad to update weekly and keep on top of occasional config migrations.
I use Debian stable on my home server, it's been in-place upgraded 4-ish times over 10 years. I can install weekly updates without worrying about config updates and such. I set up most stuff I wanted many years ago, and haven't really wanted new features since, though I have installed tailscale and jellyfin from their separate debian package repos so they are very current. It does the same jobs I wanted it to do 8 years ago, with super low maintenance.
But if you don't want Debian stable, that's fine. Just let others enjoy it.
Yup, I've had "nomodeline" in my vimrc for years. I used to add the "securemodelines" plugin https://www.vim.org/scripts/script.php?script_id=1876 but just recently removed that too (I think I may have ran into an annoyance after a vim update, and decided I never really use automatic modeline support anyway)
I'm still using Xorg after all these years, on a laptop with 150% scaling, which I occasionally plug into an external monitor with 100% scaling. Somewhat surprisingly, it works great. (Cinnamon desktop, Ryzen 7840u integrated graphics. And also a desktop machine with Radeon RX 6800XT, but it's not surprising that still works great.)
This is how it works in NYC, but the wires are almost twice as expensive as the power. (If you add taxes and the numerous weird fees, the total bill is a solid 3x the cost of the power.) It's really all about the grid maintenance and management these days.
The previous company I was working at (6 months ago) had a bunch of microservices, most in python using fastapi and pydantic. At one point the security team tuned on CodeQL for a bunch of them, and we just got a bunch of false positives for not validating a UUID url path param to a request handler. In fact the parameter was typed in the handler function signature, and fastapi does validate that type. But in this strange case, CodeQL knew that these were external inputs, but didn't know that fastapi would validate that path param type, so it suggested adding redundant type check and bail-out code, in 100s of places.
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)
In addition to the all the other stuff, including light spectrum differences, you can't just trust that a "37000 lumen" light (cheap from China ...) is such a thing. Some examples of "100,000 lumen" flashlights that ended providing more like 2000 to 3000 lumens: https://www.youtube.com/watch?v=6q_0wxzClkg
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
I just worry that the voltage of these is a bit too high, if the device takes 3 or 4 in series. They tend to be around 1.8 volts per cell, significantly higher than a fresh alkaline AA at around 1.6 volts, and even after half the energy is discharged, if the device is off for a long while, the initial voltage for next turn-on creeps all the way back up.
(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.)
> ... 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
I think, practically, everyone will need at least a cheap-ish android or iphone, perhaps $300 (and a new one every few years ...), to be their locked-down "agent" for using financial or government services. It's not for you, it's for the government/banks, it is their agent for talking to you.
Kinda weird, if you think about it. But that seems to be the way it's heading.
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.
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)
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.)
[ my public key: https://keybase.io/ploxiln; my proof: https://keybase.io/ploxiln/sigs/3VcOUGq9c7AQCS5NFB49OXAn6hGOdUXh4xblSshTOIY ]