Darren New wrote:
>> Uh... why? It's an experimental research prototype. It probably 
>> doesn't even run yet.

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

These two statements are what led me to believe you hadn't looked past 
the very surface of what they wrote. Both of these are contradicted by 
(for example) videos demoing the software and the very first design 
notes on the announcement pages.

Sorry if my misinterpretation led me to believe you didn't read up.

> Isn't this what RPM does? 

Specifically, the best the RPM does is to check that the package 
database says that the other packages you need are installed. It doesn't 
check that (for example) you've actually configured Apache to run 
correctly in order to support mod-php, it doesn't check that services 
this program depends on are turned on, it doesn't check that the 
contents of the files are correct, or that an installed device driver 
will be able to run and support the thing you're trying to add.

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

Invisible wrote:
> How about if, say, the program could somehow "tell" the OS what 
> arguments it actually accepts?

And if you want to see how Singularity does this, and what the interface 
to the disk subsystem looks like (for example), check out
singularity-6709\base\Applications\Benchmarks\diskrw\diskrw.sg
and look at the attributes on the config class.

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

And if you want to see how the file system isn't "array of bytes" files, 
look at the different files in
singularity-6709\base\Contracts\Io.Contracts
which specify the types and state machines you can pass around. Note 
that (for example) the Video Device contract isn't anything like an 
array of bytes.  (Of course, the compiler stores the records in arrays 
of bytes in memory, but that's invisible to the programmers.)

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

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

OK, the documentation I read didn't say that anywhere.

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

Except that (say) GIF supports animation and only 256 colours and 1-bit 
alpha, whereas PNG supports only single images, but with 24-bit colour 
and 8-bit alpha, and TIFF supports something else again...

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

The narrator accepts a stream of octets. It just interprets them as 
ASCII text and attempts to synthesize speach for them. But there's 
nothing stopping you from feeding it with arbitrary binary gibberish.

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

Um... surely porting C code to *any* other language is intractably 
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?

My dad has a DVD player which appears to be running a modified version 
of Mencoder. (AFAIK, that's a C application.)

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

What, you mean assigning permissions only to the person that owns the 
file is a bad idea? You do surprise me. ;-)

But my point is... it's much faster than writing an entire OS from 
scratch, all by yourself. And it instantly gives you a huge library of 
usable software. Otherwise I suspect Linux would still be nowhere...

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

Post a reply to this message

Invisible wrote:
> Except that (say) GIF supports animation and only 256 colours and 1-bit 
> alpha, whereas PNG supports only single images, but with 24-bit colour 
> and 8-bit alpha, and TIFF supports something else again...

Um, yes? So? You don't think you can abstract that?  (BTW, GIF supports 
more than that, as you can change the color table after each row. FWIW.)

>> 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.
> 
> The narrator accepts a stream of octets. It just interprets them as 
> ASCII text and attempts to synthesize speach for them. But there's 
> nothing stopping you from feeding it with arbitrary binary gibberish.

And the narrator, when read, returns discreet messages with X/Y 
coordinates. Which isn't a stream of octets.

Of course, at some level of detail, everything is a stream of octets. 
It's how the octets are interpreted that's interesting. At some level of 
detail, everything's a voltage too - that's not an interesting level of 
detail for this discussion either. :-)

>>> 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#?
> 
> Um... surely porting C code to *any* other language is intractably 
> difficult?

Uh, no?  Porting C code to C++ is actually fairly easy (almost trivial), 
for example. C# isn't all that different from C, conceptually speaking.

>>> (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.
> 
> What, you mean assigning permissions only to the person that owns the 
> file is a bad idea? You do surprise me. ;-)

No, I mean putting everything that hasn't anything to do with users in a 
directory called "user" is probably a sign of legacy code. :-)

> But my point is... it's much faster than writing an entire OS from 
> scratch, all by yourself. And it instantly gives you a huge library of 
> usable software. Otherwise I suspect Linux would still be nowhere...

Oh, no doubt doing things the same old way makes it easier to port code. 
Not always trivial, mind, but certainly easier. Most operating systems 
that are still around are based on old cruft from 20 years ago for just 
that reason. And obviously Linux didn't do a *sufficiently* good job of 
it, or the amount of UNIX software that people actually want to use and 
is portable is not enough to give Linux significant market share. It's 
really, really difficult to make something that big *actually* 
compatible. (See, for example, all the strangeness in any autoconf.) 
It's probably almost as easy to port most non-GUI Linux utilities to 
Windows as it is to port them to (say) Solaris. The port may be rather 
poor (like, it might not interact with stuff the way you want it to 
under Windows, such as not being startable with "net start" or not 
recording how many unread emails you have for the login screen, say), 
but it'll probably run as well as on Linux without too much hassle.

I'd guess things are way easier to port from UNIX to Windows than from 
either to AmigaOS or Singularity, for example.

I think it's not so much that Linus T said "If I make it look like UNIX, 
I can use all the tools."  I think it was probably at least as much "If 
I make it look like UNIX, I won't have to figure out how an OS *should* 
work."  Hence, it starts out with all the brokenness of UNIX, then 
slowly piles on even more patches to try to make it useful, as long as 
you're not trying to maintain binary compatibility anyway.

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

Darren New wrote:

> I think it's not so much that Linus T said "If I make it look like UNIX, 
> I can use all the tools."  I think it was probably at least as much "If 
> I make it look like UNIX, I won't have to figure out how an OS *should* 
> work."  Hence, it starts out with all the brokenness of UNIX, then 
> slowly piles on even more patches to try to make it useful, as long as 
> you're not trying to maintain binary compatibility anyway.

The mental image of coding a broken system from scratch and then piling 
more complexity on top really amused me for some reason.

I guess because it's so true. ;-)

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

Post a reply to this message

Orchid XP v8 wrote:
> The mental image of coding a broken system from scratch and then piling 
> more complexity on top really amused me for some reason.

Welcome to the wonderful world of backward compatibility! :-)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

>> The mental image of coding a broken system from scratch and then 
>> piling more complexity on top really amused me for some reason.
> 
> Welcome to the wonderful world of backward compatibility! :-)

"Darren puts the 'backwards' in 'backwards compatibility'." ;-)

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

Post a reply to this message

Orchid XP v8 wrote:
> "Darren puts the 'backwards' in 'backwards compatibility'." ;-)

Me? Heaven forbid. It's the bane of my career. :-)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New wrote:
> And if you want to see how Singularity does this,

Actually, I kind of like their implementation of "compile time 
reflection", which is sort of like C++ templates. You can pre-compile 
them, ensure they'll work at compile time, and write templates in a 
language different from the one you're using them in. Pretty funky. 
Seems pretty straightforward, as well, and I'm guessing Turing complete 
also, given you have the full power of the language available to 
generate the code, without any weirdness necessary.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message