[COFF] Other OSes?

[Dan Cross]

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

> OK, I guess I'll be the one to start things going on the COFF list.
>
> What other features, ideas etc. were available in other operating
> systems which Unix should have picked up but didn't?
>
> [ Yes, I know, it's on-topic for TUHS but I doubt it will be for long! ]
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20180705/0733af85/attachment.html>