ploxiln

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.)

it's "Enterprise" grade software! need to check the boxes for the procurement process (actually working is a separate department)

Just type <enter> without cat, your shell will show you another prompt, and the ssh escape command will also work.

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)

High school ... 20+ years ago probably

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.)

Windows 11 officially requires TPM 2.0, secure-boot enabled, and an AMD Zen+ (Ryzen 2xxx) or later or an Intel Core Gen 8 or later.

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

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.

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

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.)

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.

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.

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.

hmm how well did that work for Docker ...

A multitude of tiny dependencies has a multitude of solo maintainers, who eventually walk away, or sometimes get compromised.

A few big dependencies each have a team and a reputation that has earned trust and established release process and standards. If there's a serious problem in a small part of a big dependency, there are a few trusted maintainers of the big dependency who can be reached and can resolve it.

The theory of small dependencies was a good theory, 10 years ago when js devs using NPM started the trend of making them "as small as possible". But it really seems like the emergent pattern is the opposite of what is claimed. These JS and Rust projects end up taking longer to build and resulting in bigger outputs. Instead of a couple of "huge" 200KB dependencies, you end up with _thousands_ of 1KB dependencies including different versions and alternative implementations, you end up with megabytes of "accidental" code you don't really need.

And we can reason about why. In an ecosystem where something has 1 to 3 large deps, well sometimes a dependency pulls in another sub-dependency with code you don't need. But in an ecosystem where something has 10 to 100 deps, this still happens, but 50x more overall. It's a exponential trend: you have 3 big deps that each have 2 big deps that each have 1 big dep, vs you have 20 small deps that each have 15 small deps that each have 10 small deps.

I feel like it was around 10 to 15 years ago that some people were excited to eliminate all the setuid on various binaries in a linux distro, by using linux file xattr capabilities. And eventually it became apparent that this wasn't such a great scheme; many capabilities can be used to escalate to full root, basically. So, yeah, I think this is known. It takes some effort to find some good write-ups from back then, but here we go: https://lwn.net/Articles/632520/ https://forums.grsecurity.net/viewtopic.php?f=7&t=2522&sid=c...

Not really. ECC memory will have an extra ram chip, and store an extra bit per byte or so, for that error detection/correction. DDR5 only has error-correction bits added to the bus, regular DDR5 doesn't have extra chips/bits for error correction of the data while it is stored.

But also, what you really want is ECC that reports all the way up to the OS the corrected and un-corrected bits. This is how you know if it's on the edge, becoming a real problem. Otherwise, it works fine until it doesn't shrug which is the same as regular normal memory.

I think the ECC added to the DDR5 bus is kinda just enough to get the higher data-rate signaling to be as reliable as DDR4. It's nice for marketing to put ECC on the DDR5 box but it's not more robust than DDR4.

I am a consumer who is concerned about evil maid attacks

This is seriously the least likely way for you to be hacked. Much more likely is that an auto-update is downloaded and run from a hacked server, or you sometimes use pip/npm/etc to install dependencies for some software project and get malware that way, or you get tricked into opening a zipped document in an email that ends up having executable code because industry-standard doc viewers and OSes try to be too smart ...

Secure boot never stopped me from doing anything I wanted with my hardware.

But, you may have done a lot of things that it should have stopped you from doing. For 5 to 10 years a bunch of utilites for monitoring temperatures and fan speeds and controlling RGB lighting etc have used the signed "winring0" driver to be able to poke arbitrary hardware registers of various chips over various low-level busses (i2c etc), just a couple months ago this "winring0" driver was blacklisted, identified as malware, and quarantined by Windows Defender. There's other solutions that these tools have shifted to, like "PawnIO" and custom signed drivers.

On the topic of Framework, you can use "ectool" to control fan behavior and charging behavior etc of the environmental controller chip, but for many years you had to disable secure-boot for this thing to be able to poke that chip. About a year ago I recall a forum conversation where someone was intent on porting this tool to use winring0 on windows so that they did not have to "endanger" their system by disabling secure-boot. I really didn't think there was any point, because if winring0 lets you bypass protections that secure-boot relies on, it's just a big charade.

Many signed third-party windows drivers have been found vulnerable to enabling arbitrary memory poking somehow, which theoretically lets you bypass any protections that secure-boot intends to provide. They eventually get updated and old versions blacklisted, but there's always a bunch and there's always more. And remember Logo-Fail? Letting people update the boot logo, without re-signing with their own key loaded into their system?

And if we look at the other discoveries by Eclypsium, the theme here is debug and repair tools. Do you want debug and repair tools to be allowed without disabling secure-boot?

It turns out that lots of people, maybe most people, expect to be able to do things with their laptop, which secure-boot really shouldn't allow. For practical reasons we tend to just go ahead and get that signed with some Microsoft key and allow it. There's a real theater to thinking secure-boot is super important and you're super-secure, while expecting and depending on functionality which really means that secure-boot has been compromised in 100 different ways. I just turn it off, it just makes things more complicated.