Orchid XP v8 wrote:
>>> 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. ;-)

Then you should have said "What would happen if *I* set out to design a 
new OS completely from scratch?"  ;-)

>> 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.

You say this with such confidence. Yet, surprisingly, you didn't 
actually (say) read any of the papers, and noticed they're all dated 
five years ago.

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

No. You didn't read the papers, so you don't know what they're working 
on. It's better to read what the authors wrote than what some blogger 
says about what the authors wrote.

>> 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?

No.

>> 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.

Right. Of course, since they're writing the OS, they're worried about 
the sorts of problems drivers cause. But the same result applies to 
things you invoke by hand or from other programs.

> 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?

Well, a manifest is a list of what's included. Other than that, I 
couldn't help you guess without seeing one.

>> 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.

No, I'm saying why would you want the exit status to *ONLY* go to the 
parent process, and not to whoever you want it to go to? Why not list in 
the application manifest all the applications that'll be interested in 
knowing that program X failed?  Wouldn't you want everyone using the TCP 
stack to know that the nic driver failed?

>> 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!

Uh, no. You wind up with "everything is strongly typed", not necessarily 
"everything is the same type". I am not sure I've discovered exactly 
what they store in files - I'm still going thru the papers - but I'm 
pretty sure it's not relational.

It's not unlike the Amiga OS in that respect, except safe and strongly 
typed.

>> 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.)

Yep. Or most anything. I'm pretty impressed that they managed to get 
functional languages doing their thing in an OO assembler language.

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

It's ugly. I think the JVM is probably a little easier to understand. 
But think of it merely as strongly typed assembler language with lots of 
metadata about types and layouts.

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

Exactly. Why do you need to execute arbitrary C code, tho? Other than 
compatibility?

> 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...

Yes, exactly. Singularity lets you specify it as both, including the 
history.  So "PHP running from user Fred invoked via Apache" can have 
different permissions from "PHP running from user Fred invoked via bash".

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

OK. Well, some of your assertions about how it works were at odds with 
what they wrote, so I assumed you hadn't read all the way through.

-- 
Darren New / San Diego, CA, USA (PST)
  Ever notice how people in a zombie movie never already know how to
  kill zombies? Ask 100 random people in America how to kill someone
  who has reanimated from the dead in a secret viral weapons lab,
  and how many do you think already know you need a head-shot?

Post a reply to this message