On Thu, Jul 5, 2018 at 1:56 AM Warren Toomey <wkt@tuhs.org> wrote:

Ooo, neato. I think about this a lot, because my day job is writing OS kernels.

I think it's kind of paradoxical, but Unix went off the rails in not embracing the filesystem enough, and simultaneously embracing it too much.

Separate namespaces for things like sockets add unnecessary complexity since you need separate system calls to create these objects because you can't do it through the filesystem. "Everything is a file" ended up being too weak for a lot of interesting applications. Plan 9 fixed that by saying instead, "everything is a filesystem and we have per-process (group) composable namespaces." So now your window system is inherently network-capable and recursive with no special effort.

That was great, but it turns out that the simplistic nature of Unix (and plan9) files doesn't fit some applications particularly well: doing scatter/gather is sort of a pain on plan9; fixed on Unix, but with an ugly interface. Modeling objects that are block oriented or transactional on Unix is still something of a hack, and similarly on plan9. Important classes of applications, like relational databases, don't map particularly well to the filesystem (yes, yes, RDBMS servers usually store their data in files, but they end up imposing a substantial layer on top of the filesystem for transactions, indices, etc. In the end, they often end up treating large files like block IO devices, or going straight to the storage layer and working against a raw device).

Further, text as a "universal" medium means that every processing stage in a pipeline has to do substantial parsing and validation of input, and semantic information passed between stages is done using an external representation as a side-channel. Of course, often we don't bother with this because we "know" what the data is and we don't need to (I submit that most pipelines are one-offs) and where pipelines are used more formally in large programs, often the data passed is just binary.

I had a talk with some plan9 folks (BTL alumni) about this about a year ago in the context of a project at work. I wanted to know why we didn't architect systems like Unix/plan9 anymore: nowadays, everything's hidden behind captive (web) interfaces that aren't particularly general, let alone composable in ad hoc ways. Data stores are highly structured and totally inaccessible. Why? It seemed like a step backwards. The explanation I got was that Unix and plan9 were designed to solve particular problems during specific times; those problems having been solved at those times, things changed and the same problems aren't as important anymore: ergo, the same style of solution wouldn't be appropriate in this brave new world. I'm sure we all have our examples of how file-based problems *are* important, but the rest of the world has moved on, it seems and let's face it: if you're on this list, you're likely rather the exception than the rule.

Incidentally, I think one might be able to base a capability system on plan9's namespaces, but it seems like everyone has a different definition of what a capability is. For example, do I have a capability granting me the right to open TCP connections, potentially to anywhere, or do I have a capability that allows me to open a TCP connection to a specific host/port pair? More than one connection? How about a subset of ports or a range or set of IP addresses? It's unclear to me how that's *actually* modeled and it seems to me that you need to interpose some sort of local policy into the process somehow, but that that policy exists outside of the capabilities framework itself.

A few more specific things I think would be cool to see in a beyond-Unix OS:

1. Multics-style multi-level security within a process. Systems like CHERI are headed in that direction and Dune and gVisor give many of the benefits, but I've wondered if one could leverage hardware-assisted nested virtualization to get something analogous to Multics-style rings. I imagine it would be slow....

2. Is mmap() *really* the best we can do for mapping arbitrary resources into an address space?

3. A more generalized message passing system would be cool. Something where you could send a message with a payload somewhere in a synchronous way would be nice (perhaps analogous to channels). VMS-style mailboxes would have been neat.

        - Dan C.