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. :)
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.
> 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.
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.
Deterministic password generator is the only way to go for me. I have my own that takes the site name, username, and a version number and SHA256 hashes it all with a passphrase, and runs the resulting bytes through a simple transformation that produces a strong password with a good character set. Optionally allows me to specify constraints on the password (e.g. which special chars, limited length) for sites with idiotic password rules. If you want to change a password, you incremement the version number. The whole thing is a simple command line dingus that barfs the password out to the clipboard and a note (including the username reminder) out to stdout. I even had claude port it to ios for me.
I've been using this technique for literally all my passwords for about 7 years now and it works great. The only downside is it doesn't help me in situations where I want to either share a password or receive a shared password from someone else.
The really beautiful thing is that you can reconstruct your important passwords completely from memory even after losing your whole config. This saved me recently when my laptop died. git clone / vim a config / remember your passphrase / done
I think one thing that has made Go have better dependency hygiene is not merely having "batteries included" in the standard lib, but the early focus on having production-ready implementations of a lot of stuff in the standard lib, as opposed to minimum viable implementations. I used to get a long way with one or two dependencies that would barely fan out at all. It's been a while since I worked on a Go project, so I'm not sure if it's still that way.
I had a mixed incredible/horrible experience with Claude's AI support agent. First, I suspected there was a particular problem with the API access, and I articulated it and said, "can you give me a way to test this theory and prove that the problem is on your end? Python is acceptable" and it spit out a python test program that proved the problem was on their end. Then it turned a corner and spent 30 minutes insisting that it was going to connect me with a real person who could fix the problem for me before finally admitting that the whole thing was a boondoggle and it had no way to connect me with an actual person, but maybe I should come back to the chat in a day or two and see if anyone noticed and responded.
The real interesting thing was that early on in that 30 minutes, it gave me very clear instructions about how to get a live agent (including a quoted trigger phrase like "I would like to speak to a live agent" or something), which made me believe it was possible, which ultimately made me resist the slow realization that that was a complete fabrication. It was a very effective way to waste my time.
12 mini is pretty old. I have considered going to a 13 mini, but I sort of hate the idea of spending money on a phone that is already well on the path to unsupported. Then again, the compact options for grapheneos are limited to old stuff too. Sigh.
It's not a great option. My "old" phone that I use to install junk apps (e.g. I buy some hardware that requires an app to set up) and which mostly sits in a drawer is a 2nd gen iphone SE, and it's getting to the point where I'm going to be forced to replace it, because the OS hasn't been upgraded in a while (it errors) and some apps won't install on it now.
Note that they already do this if you buy a mac on an Apple Card, and they even go so far as to link your AppleID that you may have had for decades. I bought a new mac last year and signed up for the 0% Apple Card financing and if I'd have known about this little bit of leverage they use, I would have created a brand new AppleID to partition it off.
It's possible they were trying to do something like remote start, which (at least in my bmw) does use the godawful bmw online service. In the retelling, this might have expanded to "couldn't start the car."
This reminds me of an idea that I build a PoC of many years ago (maybe 2013 if I recall) that I always felt was the nugget of a useful idea. You would SSH into a server and processes on the other end would emit data which was then displayed in a webapp that was served from a localhost port, with a local backend that consumed the data. So for example a short-lived web-based remote 'top'. I did it as part of a company-internal hackathon and thought it was really cool, but nobody else was impressed with it. It was a very half-baked idea, and this looks like a fully-baked version of it. I'll check it out.
I don't think it's very common to believe the Chinese people are bad guys. It's the government and its control of the people that's the problem. And no, I don't think the US is immune to that sort of problem either.
A mocha is an espresso drink. A latte is an espresso drink. A cappuccino is an espresso drink. An espresso is an espresso drink. Some espresso drinks have milk in them and some don't. Anyone offended by the question, "did the espresso drinks have milk in them?" is just looking for something to be offended by, as seems to often be the case with people who fly off the handle over the topics of coffee, pasta, and pizza.
Some sites that block "+" in email addresses are actually just doing it out of incompetence. My credit union, for example, will actually accept an address with a "+" in it, but nothing will work because some broken bit of web 1.0 plumbing along the way converted it to a space (it shows up that way on my profile page). I wouldn't be surprised to see " " on my printed bank statements.