"On a Mac with Apple silicon with macOS 26 or later, FileVault can be unlocked over SSH after a restart if Remote Login is turned on and a network connection is available."
Most codebases that ban exceptions do it because they parrot Google.
Google’s reasons for banning exceptions are historical, not technical. Sadly, this decision got enshrined in Google C++ Style Guide. The guide is otherwise pretty decent and is used by a lot of projects, but this particular part is IMO a disservice to the larger C++ ecosystem.
If my system doesn’t work - I want to be alerted. If notification was supposed to be sent but wasn’t - it’s an error regardless of whether it wasn’t sent because of a bug in my code or external service being down. It may be a warning if I’m still retrying, but if I gave up - it’s an error.
“External service down, not my problem, nothing I can do” is hardly ever the case - e.g. you may need to switch to a backup provider, initiate a support call, or at least try to figure out why it’s down and for how long.
We wanted TLS everywhere for privacy. What we ended up with is every site needs a constant blessing from some semi-centralized authority to remain accessible. Every site is “dead by default”.
This feels in many respects worse than what we had with plain HTTP, and we can’t even go back now.
If you mean that sites with expired certificates may technically be accessible if one jumps through enough hoops and ignores scary warnings - yes, of course you’re right.
Maybe this will just teach everyone to click through SSL warnings the same way they click through GDPR popups - for better or worse.
This is also one of my arguments. I'm exaggerating, of course, but to me it feels like major software products and services haven't been adding new features for years now. What we get with updates these days are new restrictions on use, and "streamlining", i.e. the removal of features. Usually with the justification that the effort to maintain them was too high.
I used to look at release notes excited about what new features I might get. Now I read them with some level of anxiety. I hope none of the inevitably removed features are ones I used.
The AI evangelist talks to me about 10×. Meanwhile, all the software I use is becoming less functional, less configurable, less powerful, less secure, less stable, and in general crappier by the day.
I was hoping for easy backup via zfs send as well, but turns out it’s not so easy atm.
IncusOS does not give you shell access, you have to figure out IncusOS ways to do things via their CLI/API. I haven’t found an easy way to do incremental backup of the whole system yet. You can backup individual instances/volumes via incus export (which seems to use zfs send under the hood), but not the whole thing.
I have mixed feelings about their decision not to give you shell access. Guess those who want flexibility can always just install Incus on top of any Linux they like, but it would be nice to have an escape hatch for when IncusOS gives you almost everything you want…
I occasionally contemplate that, if I were designing an OS meant to be sort-of-immutable (like Incus OS or Fedora Silverblue etc or MacOS), I would probably build it like this:
The main filesystem is verified and immutable. Everything that isn't configuration or the user-controlled payload is genuinely read-only, and the system will even cryptographically verify it on boot or first use. You cannot modify /bin/bash, etc.
If you want to test a modification, you can configure an overlay, and you can boot with that overlay live. You can configure the overlay to also be immutable or you can make the overlay mutable. But the choice of booting into the overlay is controlled by code that cannot by overlaid, so you can always turn the overlay off no matter how much you screw it up.
The user may get root access, but if your system is remotely attested or uses a TPM or such for security, then that policy will find out if you do so before you can do anything as root. So you can shell in and attach a debugger to a system service, but you cannot do that and also pretend to your orchestration tools that you have not done so.
The default configuration is mostly empty. When you change a default, you are not modifying the middle of a giant plist where no one will ever understand what happened. You only create new configuration, and deleting it is just fine.
The result would, I think, give system owners plenty of ability to hack on their own systems, but they could also unhack their systems easily. There are very few systems out there with both of these properties right now...
Check out SmartOS, it's illumos/solaris based but I think you'll find it is a nice middle ground. Not as abstracted, nice tooling that makes common tasks simple but not so opinionated you have to de-abstract things to get under the hood. Not painless but what is?
The ticketing system might very well be the oldest.
AFAIK the very first large-scale commercial deployment of what we now call "distributed cloud apps" was SABRE, a ticket reservation system built back in 1960s, still in use today.
I wonder if technical complexity of implementing online age checks is about the same as implementing a robust direct democracy system - one where people can vote down bad laws instead of outsourcing those decisions wholesale to politicians they don’t even like?..
The systems which permit voting down stupid laws also permit voting down good laws. This is very "be careful what you wish for" and reductive to "the voter is always right even when they want stupid things" interpretation of democracy.
E.g. Swiss cantons opposing votes for women inside the last 2 decades.
Well, direct democracy already exists in various forms (e.g., referendums, propositions on California ballots, etc.). Sometimes bad decisions are made, but I wouldn’t call it a total disaster. Can it be improved through technical means? How much improvement would it take for it to be better than the status quo?
