Unix And Windows Hell

There's a common assumption out there that it's either Unix or Windows, that if you hate one then you must necessarily like the other. Well, that's not true.

There's another common assumption that Unix and Windows are different, very significantly different, well that's not true again.

This page is dedicated to the realization that both Unix and Windows are very, very similar and that they should both be bashed in unison.

"Sure, sure, but other than that, how did you like the play, Mrs. Lincoln?" :-)

I don't. :p What's left to like?

Funny, that's what Mrs. Lincoln said, too.

Unbundle Services

It has been suggested that the different services that OS's provide should perhaps be split such that they can be mixed and matched as needed. Thus, the file system, the GUI, the security model, etc. are different things similar to the way a web server is considered a different thing than a database (server) these days. Choosing one does not force using the other. I think there is an existing wiki topic on it, but I could not readily find it.

ExoKernel and LibOs? probably. Now, if by "unbundling OS services" you mean something beyond run of the mill modularization then it will get you a radically inconsistent OS. IOW, the most horrific OS imaginable, by definition. Oh, and security cross-cuts every other component of the OS, it can't be unbundled. Unless of course you've got something like KeyKos that centralizes security <shudder> and even then it would still cross-cut every component.

[I didn't recall that you had written about (taken a strong position on) centralized vs. distributed security, which pages did I overlook or forget? -- Doug]

I'm not sure I've written it up, and if I have written it up it probably isn't clear. But yeah, I'm for distributed security and against centralization. The main reason for this is because it's gratuitous. Every component that wants to export objects or services has to possess a deep knowledge of security, even if some centralized component is supposed to provide security for everybody. Plus, centralization involves too much gratuitous indirection.

In a centralized system, if component A wants a cap to object 3 from component B, then it first asks its cap of the kernel for a cap of component B, which is duly returned, then it asks this cap of component B for a cap of object 1, which is duly returned, and so on. For every cap in the chain, the kernel is involved right in the middle of the dereference, so by the end of it you've been in and out of the kernel 5 times. If that chain involves passage through the network, then this is death.

In a decentralized system, things are simpler and more direct. You don't ask the kernel for a cap to component B, you tell the kernel to pass on a message to component B, which it does, and upon reception component B passes the message to object 1 which passes it to object 2 and so on. At the end of the chain, the results return. Any dereferences are made in-place so they stay hidden, and the kernel only gets involved a single time. The end result is that the kernel has no knowledge of caps to objects 1, 2 or 3, and they can be implemented in any way that component B wishes.

The centralized example is how I've figured out KeyKos works but it's difficult to be sure given how absurd it seems to be. It could be that the system isn't as centralized as it claims or that components don't have internal caps. The latter would mean that security is much coarser-grained than it appears. Or it could just be absurd. -- RK

See: SplitOperatingSystemIntoServices

EditText of this page (last edited December 25, 2008) or FindPage with title or text search