Interesting take on what ails software: https://caseymuratori.com/blog_0031 (Thanks @Cole)

I’ve been a keen follower of Casey and his handmade hero series for a while, along with his partner in crime, Jonathan Blow. Their rants are always fun, and I agree with most of it. His recent demo of how Visual Studio is slower than the version from 10 years ago was telling. The statement that software which works in the morning isn’t guaranteed to work in the afternoon is frightening and so true! A feature I’m keen to build into my own software is a snapshot ability to enable retreat to any modification point. Perhaps that’s something that should happen at an OS level? Because I can’t see a day where we don’t need updates to patch vulnerabilities, if nothing else....

Yes, of course snapshots should happen at the OS level. This is decades overdue, but we are seeing progress in the Linux world. Ubuntu 20.04 has ZFS on root, with automatic snapshots when a package is upgraded. Fedora 33 (due Oct 2020) defaults to BTRFS on root, again with automatic snapshots and the ability to roll back to a previous state. NixOS has a different approach to package management, allowing individual apps to be rolled back, rather than requiring rollback to an earlier state to be a "global" operation. The flatpak app distribution system (works on all modern Linux systems) permits rollback to a previous version (which is granular on a per-app basis). What seems to be largely missing so far is a slick, high level GUI for rolling back software changes.

I have been using Guix (which is based on the same ideas as Nix) for a while to stabilized my software environment, and I wouldn't want to live without it. You can not only snapshot your installed software, but even install the state from an arbitrary point back in time (though that can be slow because everything gets recompiled, starting with the compiler). GUI support is indeed missing, and some important software hasn't been packaged yet. You can't install binaries made for ordinary Linux distributions either, because the file system layout is very different. So this is not ready for prime time, but it's far more than just a proof of concept.

I really wish this future would happen, but we’d need someone with a ton of money to do it and I think that’s very unlikely anytime soon. It always felt like hardware interfaces should be implemented as a blackboard system where devices push events and consume events and nothing else (similar to his “just have ring buffers” idea). Interop is trivial at that point. Creating new devices is just pushing new events that some other system looks for. The events can be easily versioned and so on. The problem is that doing so isn’t just a ground up software rewrite, it really is a ground up hardware ecosystem reconstruction and boy is that a tall order.

(Aside: glad to see Nix and Guix getting some love in this thread)