Question: why did they decide to make /usr/bin the "primary" and /bin the symlink? Methinks it should have been the other way around as was the original Unix design before the split.
Also the first URL is serving me scam popup ads that do a crap job at pretending to be android system alerts. Next time please try to choose a more reputable source.
Using /usr/bin instead of /bin comes down to that is much easier to mount one /usr instead of doing bunch of bind mounts for /bin /sbin /lib /lib32 /lib64,
Thankfully it's trivially easy to disable OneDrive via the task manager startup tab. Never had any issues with MSFT sneakily turning it back on either.
This super aggressive OneDrive shit is also why I've stopped putting most things in the standard folders and now just have my own alternative hierarchy in %USERPROFILE% instead.
The only alternative suggested by the linked article is giving up email completely in favor of centralized solutions like Signal. My short answer is “no”. My long answer is: <https://news.ycombinator.com/item?id=45390332>
I wrote the linked article. I don't care what secure messenger you use. But if you choose encrypted email over Signal because "centralization", you're LARPing. The first criteria for a secure messenger has to be that it is plausibly secure, and email isn't. You'd use encrypted email (for "decentralization") because you understand the cost of losing the plaintext of your message is nil. If you tell strangers to do that, without certainty that their messages are also valueless, you're committing malpractice.
Something that doesn't require securing email. Both S/MIME and PGP were solutions for 1980s problems (TFA is slightly off about PGP's start date, the PGP design dates from 1987 and MSDOS, not the 1990s, and S/MIME via PEM is from 1986). They're pretty much irrelevant today because almost all email is encrypted anyway via StartTLS and if you need full end-to-end encryption you use Signal or something similar.
I would add to that, replace #include with a proper module system that fixes the encapsulation and redundant parsing problems once and for all.
It's 2025 and C++ modules still aren't suitable for real world use yet despite being standardized 5 years ago.
Additionally standardize the ABI up front so that different compilers can interoperate. Make namespaces native to the object file format.
Also, explicitly standardize a compiler optimization mode that does not try to exploit UB in eldritch ways that break basic assumptions about how the machine works for 1% performance gain. I get that's an undecidable problem so it's ok if some extra annotations (call them "attributes" and write them [[like this]]) are needed here for explicit optimizer hints.
No doubt Nintendo was involved in the lobbying effort for this. Back in the 80s they successfully pushed to amend Japanese copyright law to ban game rentals.
Also, NaN is the only value in JS that isn't === to itself, so if for some reason you want to test for strict value identity with the value NaN of type number, that's one way to do it:
Also the first URL is serving me scam popup ads that do a crap job at pretending to be android system alerts. Next time please try to choose a more reputable source.