I think OS designers have too small a vision. The basic principle separating 'OS' from any other support is: sharing. Device, process, hardware, access, network, anything.

There are so many things to share that are usually exclusive, they should be pushed back into the 'OS'. So many lame devices surface a serial streams - the OS doesn't allow sharing those. Lots of OSs don't allow multiple clients access to a webcam, microphone or other capture devices.

Even the model of 'process, thread, priority' is inadequate today. I'd much rather schedule latency than priority. And I'd like virtual hardware to be mapped into app space to remove copy/interrupt/stack switch time from drivers (and reduce latency to zero). I'd like to schedule network traffic across purposes/apps.

I'd like the 'file system' to abandon the ceremonial file tree, and expose a persistent object store. Objects could (should) be uuid-labelled at root, have no fixed location. The local file system could be thought of as a cache of resources, with the authentic directory cloud-based. Access should be through attributes and relations.

I guess my point is, there's so much more to what an OS should be, than page table/scheduler/disk drivers.

> Lots of OSs don't allow multiple clients access to a webcam, microphone or other capture devices.

Does the multiplexed access need to be at the kernel level? It could be done with a user space server.

> And I'd like virtual hardware to be mapped into app space to remove copy/interrupt/stack switch time from drivers (and reduce latency to zero).

There have been efforts to eliminate copies, and to allow direct access to network devices from userspace.

> I'd like the 'file system' to abandon the ceremonial file tree, and expose a persistent object store. Objects could (should) be uuid-labelled at root, have no fixed location. The local file system could be thought of as a cache of resources, with the authentic directory cloud-based. Access should be through attributes and relations.

I'm in agreement that the filesystem tree is problematic. It's inefficient to traverse a directory tree when it's structured as a persistent linked list, and it's brittle. The tree is intuitive, but you could create a tree interface even if there isn't a literal metadata tree on disk.

You might be surprised by all of the zany things that have been proposed and tried in the OS community. The abstractions that have stuck around are oldies but goodies that are simple but work. A lot of things don't need to be done at OS level, like cosmetic changes to the interface of some resource. You can usually do that in userspace. Linux is pretty remarkably flexible with filesystems, too. FUSE is about as flexible as you can get.

The best argument to change the kernel is when something simply can't be done efficiently in userspace. If there's a way to implement something useful in userspace on top of existing kernel functionality, that's the way to go.

The ceremonial file tree doesn't 'work' for nearly anybody. All significant apps embed their own structured data inside a big file, effectively implementing their own filesystem. The OS could have done so much to help.

In particular, no single OS can reimplement a distributed object store by themselves - there has to be an ecosystem. Somebody big has to invent that. Then, how to shim that under the file tree without changing the OS? E.g. I want an entire enterprise to get their apps from ... wherever its convenient for them to be stored today. Not from c:\xyz on their local disk. And I want some subset of my users to change to a new version without obsoleting the old, by changing the directory record in my enterprise cloud, NOT by triggering some binary update monstrostrosity, then writing another script to back out the update etc.

I'd say its universities that are letting us down, by continuing to teach the obsolete ideas current in the 1980s.

> The ceremonial file tree doesn't 'work' for nearly anybody. All significant apps embed their own structured data inside a big file, effectively implementing their own filesystem. The OS could have done so much to help.

Do you mean like a SQLite file? You have to consider how much there is to gain from embedding this stuff deeper.

> In particular, no single OS can reimplement a distributed object store by themselves - there has to be an ecosystem. Somebody big has to invent that. Then, how to shim that under the file tree without changing the OS? E.g. I want an entire enterprise to get their apps from ... wherever its convenient for them to be stored today. Not from c:\xyz on their local disk. And I want some subset of my users to change to a new version without obsoleting the old, by changing the directory record in my enterprise cloud, NOT by triggering some binary update monstrostrosity, then writing another script to back out the update etc.

This doesn't necessarily need to be in the OS. Look at it as a technical problem to solve. Is there a way to meet this need without changing the OS? There's usually a creative solution.

Ever try playing with plan9? It persuaded me that, yes, the modern tree filesystem sucks, but not because organizing persistent data into heirarchies is bad, but because you don't always want the physical translation presented to you. Plan9 was pervasively virtual, with an applications filesystem view being radically different than anothers, and with everything accessable through file read / writes (including OS system calls besides open, read, write, and close).

I've never tried Plan9. Doing searches over deep source code hierarchies has been my most recent experience with the inefficiency of the directory tree (nevermind the inefficiency of overly-complex source code). Really, there's no fundamental reason why `find /usr -name foo` has to take all day. While installing software, also, I was struck by how long it took, while it was apparently updating all the filesystem metadata. For the problem of long installs, I had a brainstorm: what if userspace could hand the filesystem an entire archive in a single transaction, and let the filesystem handle materializing it into a directory tree at its leisure? Just give the filesystem a tarball, rather than the application having to piece together the subtree step by tiny step? It would certainly make it more ACID, and it's not like tarfiles are bleeding-edge technology. Maybe that's a good project for someone who wants to hack filesystems.

This. So much.