>>> 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?"  ;-)

Well :-P to you.

>>> Download the release and read the design notes, too.
>>
>> 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.

And this makes a difference? It's not meant to be an end-user OS. It's 
meant for OS hackers to play with.

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

Sure I did. They have software-enforced type and memory safety so they 
can turn off hardware protection and make IPC really cheap. They also 
statically check IPC. I don't see anything anywhere about, say, how end 
users invoke programs.

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

Really? I thought that was the entire *point* of package managers. (And 
also the reason that as soon as you attempt to upgrade any Linux 
installation, it breaks on 50,000 instances of "wrong version of glibc" 
or something similar.)

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

Well sure, other programs might want to know as well. I was just 
pointing out that there may not *be* a human sitting at the console, 
that's all. ;-)

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

You still have to get everybody to agree on what constitutes a "type". 
Ask a BASIC programmer and they'll tell you a "type" is either 
"integer", "float" or "string". Ask a Pascal programmer and they'll tell 
you a "type" is a unique identifier that identifies an array or a 
record. Ask an OOP expert and they'll tell you a "type" is a class. You 
don't even wanna *know* what a Haskell programmer has to say about the 
matter...

Seriously, do you have *any idea* how many standards have been put 
forward for "store digital audio in a file"? ;-)

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

Um... AmigaDOS files are streams of octets, just like every other OS.

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

Uh, yeah... Haskell really doesn't fit the MSIL very well. I'm told it's 
not very performant there. (I have no idea about F# - but when I 
researched it, it didn't appear to be very functional.)

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

I'm just wondering how you design assembler so that it can be run 
efficiently on multiple targets, that's all. (I hear it's a stack 
machine rather than a register machine, for example. Aren't Wikipaths fun?)

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

Oh, well, other than the "minor detail" of compatibility, there's no 
problem at all! ;-)

(You recall that "Linux" is actually a tiny bit of software which 
inherited compatibility with Unix, thus earning an instant library of 
userland tools, right?)

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

...which makes significantly more sense.

(Actually, maybe PHP is a bad example. Perhaps you want to assign 
different permissions to each PHP script? Rather than just to the PHP 
interpretter?)

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

Post a reply to this message