It's almost sensible if you only think of one side. It's like if /etc/passwd put "NO_PASSWORD" in the field for disabled logins and someone was like, oh, I'll be clever and say crypt() returns "NO_PASSWORD" on error because that's obviously invalid and won't match. But that's exactly what *does* make it match.
If I understand what you're suggesting, wouldn't this result in a lot more swinging since the gripper would be suspended from a single point directly above it?
You seem to. That is a good point I hadn't considered - the tension from the sides holds it in place. Maybe we need to use a telescoping arm (which doesn't seem practical, I'm mostly joking). It might still work, but I imagine if you don't grab it on the first try, you may have to go back to the ceiling. And hope there are no strong drafts in the room.
EDIT: maybe lower it on three lines instead of one?
If you're editing /etc/ssl/cert.pem yourself, you're setting yourself up for failure. Use the proper mechanism to add your own trust roots (on macos it's "security add-trusted-cert").
Whatever reason Apple had for not updating /etc/ssl/cert.pem yet, I am certain it's not out of consideration for users that might have put custom certs in there.
I used to manage OS level trust root management for all internal machines at a hyperscaler. Hundreds of thousands of machines. Even when you have an edict from a common VP or CEO, and most people are even using the same linux distributions, it's hard to get people to adhere to or even understand that there is a standard. Throw containers, embedded devices, windows and mac in and it's just a total nightmare unless you exert strict control on how every single machine is set up. Which, of course, is impossible because cowboys gonna cowboy.
Fundamentally, people don't want to think about the intricacies of how we decide whether or not to trust a particular cert. They want it to just work without thinking about it. This includes that if they have a custom private root they need to trust, they just drop it various places until it starts working and call it done. And sometimes they do weird things like adding intermediates to their trust store because they were trying to call a service that has their cert chain configured incorrectly, and that "fixes it". Again, it's a nightmare.
The fact that linux, a system notoriously cobbled together by 873 different factions on the internet, is even more of a mess is not surprising in the least.
One of my last productive acts when I was at microsoft was to get a two-line change committed in windows to a tree outside my org. It took two full months just to propagate the change up the very fragile and fractured tree of repos from my team's to WINMAIN and from WINMAIN back down to the owning team's org, and my efforts were required every step of the way. It was truly soul-crushing.
Edit: this was in the windows vista days and I hope/expect they have overhauled that entire process in a major way, because things were at a near standstill.
Makes me wonder if any implementations will do the cute trick of dispensing with the seed constants and deriving them at startup from the unix timestamps. :)
In all honesty, I read your whole page and didn't find it one bit distracting or noticeable. I got to the end and saw the disclaimer about the AI writing and thought, "well, at least that'll head off the inevitable bitching about it being AI writing." Then I came to HN and saw people acting like you were committing atrocities. Sigh.
> The interface to a software library is one type of API. The API describes and prescribes the "expected behavior" (a specification) while the library is an "actual implementation" of this set of rules.
Yes, I still wonder why you'd be picking this particular silly semantic battle.
The problem with everything being single threaded isn't so much that you want to do a lot of parallel processing, but that you don't want to have the occasional fat loop cause the whole engine to start stuttering. If you want butter smooth scrolling while there's (for example) a lot of dynamic content moving around, you want very precise control of the threading so you can get the gnarly stuff done without causing hitches that don't feel right.
The browser, iOS, and Android all use a main thread separate from the thread responsible for scrolling animations.
However, I think it's true that controlling threading in order to perform gnarly work in a separate thread is more ergonomic on mobile than in JS/React.
You'd need to create a Promise that wraps a Web Worker, which would be an unusual thing to use. I don't think most apps need such control over threading in the browser.
If you care about smooth interactions, the browser even in 2026 is not the most straightforward route, nor the route any reasonable small company takes.
It's been many years since I talked to him, but he's an extremely by-the-book guy, so I'm sure he has a process for clearing everything he writes. His reputation does probably provide him a lot of leeway, though. He also has a queue of oldnewthing articles about a mile long and we could probably get years' worth of articles after his death if they let them run.
reply