cloudfudge

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.

I mean, if it provably produces the same result, calling it "wrong" is a little much.

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

The real question is why you'd give an app full disk access if you didn't want it reading your files.

If what the writer said was strictly true, Apple would be having a little security freakout about how Muse managed to bypass this OS control. My assumption is that the writer did not understand everything he was granting it permission to do, so he legitimately believes that he didn't grant it those permissions. But he did.

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.

Well, given this quote from your reference:

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

One wonders what overly-narrow definition of API you're stuck on.

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.

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.

Login and secret key are from memory (especially login for important accounts). Version number is typically pretty small and thus guessable. Like I said, it worked perfectly for critical stuff when my laptop died recently. There is no database. I used the important accounts from memory to bootstrap my way into github where the full config is saved.

This is Hacker News. We're supposed to dislike DHH on technical grounds, such as "he made Ruby on Rails exist."

That's on me. I've been giving confident advice that doesn't hold up in practice.