I don't know about Singularity and it's particular design goals, but the 
other day I was thinking: What would happen if you set out to design a 
new OS completely from scratch? What would that look like?

It seems to me that most OS designs today are really quite similar. For 
example, in every OS I'm aware of, there is some kind of CLI that allows 
you to invoke executable programs, optionally passing some arguments, 
and the invoked program inherits 3 streams - stdin, stdout and stderr. 
The exact details vary, but this basic story seems to apply to every 
common OS.

What if we wanted to shake that up a litle? What might we decide to do 
differently?

Well, currently a program's arguments are just a giant blob of text. The 
OS does nothing more than hand it over to the program, which may then 
interpret them in any way it pleases. This is LCD; it works for 
everything, but it's not terribly sophisticated.

How about if, say, the program could somehow "tell" the OS what 
arguments it actually accepts? (In the same way a program file usually 
contains metadata to "tell" the OS all kinds of other stuff about it, 
such as linking information.) Then the OS could report invalid argument 
names without even needing to bother actually starting the program 
itself. And just think of the auto-complete possibilities.

Hey, let's go one better. The majority of CLI arguments are either 
on/off switches or filenames, right? Well what if we *tell* the OS what 
things are on/off switches, and that their default state should be? What 
if we *tell* it which things are supposed to be filenames? (And whether 
the name in question *should* or *should not* exist when the program is 
run? Or whether it should be a *file* or a *directory*? Or maybe even 
the name of another program?)

Once you start thinking this way, you start to see that actually, if we 
get the OS to interpret the arguments and pass *structured* data to the 
program [rather than just a blob of textual data], suddenly all sorts of 
interesting ideas become possible.

If nothing else, it means that CLI arguments now have a standardised 
format, enforced by the OS, which makes it easier to learn how to 
operate each new program. Maybe all the program does is somehow list a 
bunch of settings it requires? Maybe then you can specify those either 
by CLI arguments, or a per-user or per-machine set of defaults? Maybe 
the OS has a database of these default settings somewhere? All kinds of 
interesting ideas to throw around.

Similarly, on a "normal" OS, each program sets three character streams. 
(And Unix programs in particular seem to do weird trickery to discover 
whether the output stream "is a TTY" and behave differently if it is.) 
It's also traditional to pipe data between programs.

Maybe we can do something more interesting here? Maybe we can pass 
*structured* data around instead of just plain character streams? 
(Although now you start having potential difficulties with finding a 
data representation that everybody likes.) Maybe not every program has 
to have exactly 3 such streams? Maybe piping data between programs 
running on physically seperate networked machines shouldn't be too 
different from piping locally? Just a thought...

Tradition dictates that when a program exists, it returns a "status 
code", which is simply an integer. Zero indicates success, anything else 
indicates failure or at least some kind of warning. (And every program 
uses its own slightly different set of conventions here.)

Maybe we can do something better here too? Maybe we could have a small 
set of standard categories like "program bug", "resource exhaustion", 
"the network won't answer me", and provide a set of application-specific 
codes for the actual failures that a particular program can have?

How about logging? Windoze does this slightly better than Linux in that 
there are (typically 3) logs that applications can write to if they 
want. But maybe we could do something better than that? Maybe 
per-application logs? (If a given application wants it.) Maybe tell the 
OS how to invoke different levels of logging? Just some ideas.

Of course, when you look at filesystems, most OSes provide a construct 
known as a "file" which is an opaque sequence of bytes. (And a few 
provide a means to specify what those bytes are supposed to represent.) 
I suppose you could go down the route of having files contain structured 
data - but again you're going to get people arguing over the best way of 
structuring things.

I've often thought about what would happen if, say, Smalltalk was the 
entire OS. Then the OS would "know about" the internal workings of each 
program to a large degree, and that opens up some rather interesting 
possibilities. Things like highly structured IPC and so forth. Trouble 
is, now you can only run stuff implemented in Smalltalk...

In short, once you sit down and start to question the way OSes work 
today, you start to see that there are actually many things we could be 
doing differently - ranging from the conservative to the highly radical. 
(To me, really radical ideas are interesting to think about but probably 
wouldn't work too well in practice.)

Heh, if *I* had 3 years to sit and write an OS, maybe I could experiment 
with a few of these ideas? ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message