Orchid XP v8 wrote:
> And this makes a difference? It's not meant to be an end-user OS. It's 
> meant for OS hackers to play with.

It's designed to support research into building another OS that uses the 
same technologies. They even tell you the name of the "production" OS, 
whose name starts with an "M" but I don't remember offhand. :-)

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

Fair enough. They actually show it in the videos. It looks like a pretty 
straightforward CLI thing.

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

To some extent. Package managers tell you which dynamic libraries are 
needed for which programs. They don't enforce anything, and you cannot 
(for example) look at an RPM without installing it and know if it'll 
work right once you're done installing it.

It's a small part of what RPMs are supposed to do, and they do it 
relatively poorly. Enough so that I'd have to say "no, they're different 
things."

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

Right.  I'm not sure how we wound up talking past each other. :-)

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

Sure. But there's a least-common-denominator that gets passed back and 
forth, called the "rep types". Basically, stuff everyone can represent. 
And that's why you can take the rep type and cast it to a 
language-specific type.

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

Sure. But they're all of the same type by the time you talk to the codec 
to get the data out of them.

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

No they're not. Amiga OS devices are things that listen for and respond 
to typed messages.  Certainly the narrator isn't a "stream of octets", 
nor is the clock, nor is the audio device.

Files, yes, to some extent (i.e., discounting the metadata). But you 
don't access files in the Amiga OS. You access drivers. Files on disk 
are one small part of it. And even the directories aren't arrays of bytes.

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

The only thing I'd heard is that F# is apparently a port of Caml to 
.NET.  You now know as much about it as I do. :-)

> I'm just wondering how you design assembler so that it can be run 
> efficiently on multiple targets, that's all. 

One of the things .NET does, for example, is require that every path 
through the MSIL that gets to the same opcode has to have the same types 
on the stack at that point. For example.  Apparently this makes it 
easier to generate good code, because you can statically assign 
addresses or registers to what's on the stack.

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

Right. How much C is there that couldn't be ported with relative ease to 
C#?  Of course, if you want to maintain compatibility, you're not going 
to learn much in a research system. And if your company's reason for 
existence is to write software, maintaining compatibility with the other 
peoples' software isn't that big a deal.

Now, if something's written in C++, it might be harder to port, yes. And 
it would be hard to automate porting anything, of course. Or you could 
just make a C compiler that generates safe code - if your program works, 
it probably wouldn't be too difficult.

And if you're targetting a new platform, compatibility isn't too 
important. How much legacy code is there for in-dash car computers, or 
TiVo-like media systems?

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

Sure. Most of which suck. ;-)  Just look at the file system layout you 
wound up with.

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

That too.  Or different permissions to "Fred logged in via SSH with a 
certificate" vs "Fred logged into the console with a password". So you 
can put more trust on certificates, or smart cards, or whatever, at the 
application level, but built into the ACL system. So you can look at the 
static ACLs in the system, and know you can't get to see your Quicken 
data unless you used the smart card to log in.

What's cool is, you can also ignore what program is claiming to be Fred, 
and just say "Anyone that claims to be Fred can see this, regardless of 
whether he logged in or not as Fred."  It's up to the individual 
programs as to which apps they trust to give good authentication.

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