>> 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?
> 
> Dude? That's Singularity. :-)

Not quite. They didn't do it the way *I* would do it. ;-)

Actually, I can think of *several* ways to do it, and I'd probably spend 
the rest of my life analysing them and never write any real code! :-/

> Download the release and read the design notes, too.
> http://codeplex.com/singularity

Uh... why? It's an experimental research prototype. It probably doesn't 
even run yet.

>> What if we wanted to shake that up a litle? What might we decide to do 
>> differently?
> 
> Read the Singularity papers. This is exactly the premise they started with.

They were focused specifically on "how do we increase security?" I'm 
just thinking "what widely-used but suboptimal abstractions might we 
change?"

> Or "I can't let you install 
> telnet[1] until you have some sort of TCP/IP stack installed."

Isn't this what RPM does?

> Once you can specify as arguments things beyond stuff represented as 
> strings, you get a whole nuther ball of wax. You're not stuck with 
> stdin, stdout, and stderr, for example. You can say "Hey, this program 
> needs an interrupt and two DMA channels to serve as a driver" for example.

A device driver is a rather unusual type of program. I'm thinking more 
about end-user level stuff. You know - the kind of thing you might 
invoke by hand.

> Yep. Singularity calls it the "application manifest".  An application is 
> a first-class object, rather than being "a pile of files full of code".

As an aside... Whenever I compile a Haskell program, it generates a 
*.manifest file that contains some random XML. Any idea WTF that's about?

>> 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?
> 
> Nah. You just answer back on the stream that goes to whoever invoked 
> you. :-)  Why would only the parent want to know how you exited?

Maybe because it's a lights-out system and you want the failed process 
to be started back up again? IDK.

>> 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.
> 
> Not any more than saying "you'll have people arguing about the best way 
> to represent structures".
> 
> You're still thinking UNIXy.  Get rid of the mindset that you have to 
> agree on data formats and embrace the mindset that you only have to 
> agree on APIs.

I guess if you follow all this to its logical conclusion, you end up 
with "the filesystem is a relational database" - and we all know what a 
bad idea *that* was!

>> 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...
> 
> Yep. That's traditionally been the problem. Singularity does this, but 
> makes MSIL the bottom level for applications and such. So anything you 
> can compile into structured typed assembler language you can use. This 
> includes C#, F#, Iron Python, etc.

(Or Haskell, when they fix the bitrot in the MSIL backend.)

One day, I'll have to sit down and find out how the Java VM or the CLR work.

>> (To me, really radical ideas are interesting to think about 
>> but probably wouldn't work too well in practice.)
> 
> It seems to be working well in practice. For example, one radical idea 
> (which I always thought would be a good idea) is to use safe languages 
> for everything. Singularity does this, and in so doing, can run 
> everything in Ring 0 and with no hardware memory protection.

Yah, but this only really works if you're not going to execute arbitrary 
C code - which would be kind of a problem.

>> Heh, if *I* had 3 years to sit and write an OS, maybe I could 
>> experiment with a few of these ideas? ;-)
> 
> Read the papers first. It's exactly what I've been wanting to do myself, 
> except they figured out what seems a really good way of doing it.
> 
> I like the stuff on permissions, too.

Specifying access control by application seems like a perfectly logical 
thing to want to do. That whole Unixy trip with creating a user and 
group named "apache" and making sure the Apache httpd runs under that 
account just seems like a huge kludge to me...

> Really, all the stuff you're speculating about, they've written about in 
> detail and implemented. It's very cool.  I highly suggest if the idea 
> "what if we started over in *this* millenium?" interests you, you read 
> the literature they've published. :)

...and what do you think I just spent my entire afternoon doing? :-P

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

Post a reply to this message