![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |