Oh, too many things to list. Orthogonal persistence, seamless process checkpointing, process migration, dynamic binding (like dynamic linking but with unused symbols being deduplicated and freed), a generic name service that lets users define their own mechanisms for resolving names to resources throughout the system (like how directories, environment variables, device nodes are all discrete objects that name references -- imagine redirecting between any arbitrary object type or making your own abstract one) [1], single-system imaging, dynamic code upgrading for every part of the system, process and executable semantics implemented as user-space servers, capability-based security, autorestarting drivers, etc. etc.
The thing is that despite them bringing enormous economic benefits when realized in the mainstream, the short-term incentives are aligned to hacking around what's broken instead.
I'm not sure that many of those are a net win for the end-user (where end-user = "grandma"), though. Orthogonal persistence and seamless process checkpointing destroy the "reboot to fix corrupted software" solution, and now that devices can stay in sleep mode for 6 months on a charge, there's very little reason for them. End users don't want to think about names, let alone generic naming services that let them perform more configuration; they want to think in terms of tasks and get them done with a minimum of extraneous details. Dynamic code upgrading loses much of its benefit when users want to be prompted every time an upgrade is ready.
Many of these would be big wins for developers. But developers actually have an incentive to make their own job harder, as long as they charge for their skills. Tougher development serves as a barrier to entry for the profession, which increases the wages they can charge. Make an OS so developer-friendly that the end-user can develop and the profession of software engineer would go away...which may not actually be a bad idea in theory, but neither software engineers nor end-users seem to be that keen on it.
Orthogonal persistence and seamless process checkpointing destroy the "reboot to fix corrupted software" solution
Well, not if you can also just restart to known-good states. Having a reincarnation server of some sorts is a given.
Not to mention "turn it off and on again" usually never works for Unix to begin with.
Dynamic code upgrading loses much of its benefit when users want to be prompted every time an upgrade is ready.
How does DSU hinder post-completion prompting?
But developers actually have an incentive to make their own job harder, as long as they charge for their skills. Tougher development serves as a barrier to entry for the profession, which increases the wages they can charge. Make an OS so developer-friendly that the end-user can develop and the profession of software engineer would go away...which may not actually be a bad idea in theory, but neither software engineers nor end-users seem to be that keen on it.
This is actually an interesting hypothesis. That a lot of inefficiency in software is really a form of job security.
It might make sense, but then again it seems like programmer wages dropping is inevitable, since software does not have scarcity unless you maintain it artificially. I'd wager FOSS has had an impact, though it obviously hasn't finished the job.
It's certainly possible this is why programmable UIs like Oberon and Cedar never caught on, though.
It doesn't hinder it, but post-completion prompting destroys a lot of the benefit.
Think about the user's perspective: they have already context-switched out of what they were doing to read the upgrade notice. Most apps these days either have auto-save or they're passive information-consumption apps, and so they're not going to lose work if the system shuts them down and restarts them. The OS can prompt them and restart the affected programs automatically after swapping out the binaries in the background, like how MacOS/Ubuntu/Google software updaters work.
So making it fully dynamic saves the user about 30 seconds every month, at the cost of a lot of complexity. There are much easier ways to save 30 seconds per month in user time.
This is actually an interesting hypothesis. That a lot of inefficiency in software is really a form of job security.
It doesn't even have to be deliberate. The only requirement necessary for this dynamic to emerge is to believe in the division of labor and have a mechanism for payment.
A certain segment of the developer population has a burning curiosity about how things work, all the way down. This segment is disproportionately represented among OS developers, because why else do you get into OS development if not to know how things work all the way down? The general public lacks this desire; most of them are quite happy to fork over money (or their personal data) to get the computer to do something useful to them. And a good portion of the developer population lacks it as well; many of them are quite happy to make what people want in exchange for money. The general public doesn't care about orthogonal persistence as long as they don't lose work when an app crashes. A commercial developer would almost rather it didn't exist, because then he can build auto-save functionality into his product and use it to differentiate from his competitors.
OSes that understand this dynamic and embrace it - like Microsoft, Apple, Android - tend to do much better than OSes that don't, like Genera, SmallTalk, or Oberon.
> Many of these would be big wins for developers. <
I sometimes wonder if devops is the developers way to get admins out of their way so they can work on the next shiny without the admin going "sorry, not until you can prove it is as stable etc as the one we already have".
The thing is that despite them bringing enormous economic benefits when realized in the mainstream, the short-term incentives are aligned to hacking around what's broken instead.
[1] https://www.usenix.org/legacy/publications/library/proceedin...