In other words, Uuu is quasi an ultra-high-level virtual machine which provides
all the desired functionality in a single layer of hierarchically equivalent
functions (as opposed to the normal "hardware -> lowlevel -> highlevel ->
library -> toolkit" nomenklatura), isn't it?
This called to my mind the Parrot project. Though I am personally convinced
that Python is an excellent choice, maybe it would be nice to have the ability
to freely combine Python, Perl, Ruby and I do not know what else. If I am not
very much mistaken, Parrot is also going to be function-oriented. What do you
think about this?
-- Ruediger Marcus
Am Dienstag, 15. März 2005 18:00 schrieb uuu-devel-request@xxxxxxxxxxxxx:
> Message: 1
> Date: Mon, 14 Mar 2005 12:01:06 -0500
> From: Phil Frost <indigo@xxxxxxxxxxx>
> Subject: Re: [Uuu-devel] Unununium linux distro
> To: uuu-devel@xxxxxxxxxxxxx
> Message-ID: <20050314170106.GA306@xxxxxxxxxxxxx>
> Content-Type: text/plain; charset=us-ascii
>
> On Mon, Mar 14, 2005 at 01:54:19AM +0000, Charles Goodwin wrote:
> > From a birds-eye-spectator-view of things, I'd have to say I found the
> > EROS idea more attractive. Â EROS seems more aligned with the goals of
> > Uuu and it also is much less exposed which is both a good and a bad
> > thing. Â (Good in that it would make Uuu not yet-another-linux-variation
> > and bad in that it's less tested.) Â However, what is attractive and what
> > is practical are frequently different things.
> >
> > Well, that's yet another opinion for you to digest. Â *shrugs*
> >
> > - Charlie
>
> Uuu is not a linux variant. It's an OS that can run _on_ linux, and
> hopefully, any other posix compliant system. How the hardware is
> accessed, be it by 'in' and 'out' instructions, or by standard C
> functions, is irrelevant at all but the lowest layers. The point of
> using posix is to have a stable, mature, easilly accessible, and widely
> available platform for Uuu to run. EROS might be stable, but I would
> venture a guess that it's driver support is nowhere near that of linux
> or darwin, and it is definately not as available.
>
> I did not think that the hardest part of porting uuu to posix would be
> explaining the concept. The problem is some people are stuck on this
> hierarchy:
>
> Â Â Â Â Â Â hardware
> Â Â Â Â Â Â Â Â |
> Â Â Â Â Â Â Â OS
> Â Â Â Â Â Â Â Â |
> Â Â Â +----+----+----+----+
> Â Â Â | Â Â | Â Â | Â Â | Â Â |
>   app  app  app  app  application
> Â Â Â |
> Â +--+--+
>  f  f functions
>
> When really the only hierarchy we are forced to use is this:
>
> Â Â Â Â Â hardware
> Â Â Â Â Â Â Â |
> Â Â Â Â Â Â program
>
> A CPU doesn't know there is an OS, which runs applications, which are
> composed of functions. It just knows there is a program to run, composed
> of a sequence of instructions. How we name and arrange parts of the
> program is totally irrelevant to what the computer has been programmed
> to do.
>
> An OS when properly designed does not require that to access the disk
> controller it must manipulate IO ports around 0x1f0 and 0x3f6. It could
> just as well use any other interface, such as a posix compliant C
> library, which calls linux syscalls, which manipulates IO ports. This is
> not unlikely running Uuu directly on hardware that is not IBM PC
> compatible, where the instructions to access the disk controller might
> be entirely different, or there might be a different type of controller.
>
> The goal is to eventually have Uuu running directly on hardware for best
> performance. Using "posix" as "hardware" allows development to skip
> boring driver development that doesn't really contribute anything new to
> the OS scene. Furthermore, linux is the platform used by most uuu
> developers, and those who do not have linux have access to a posix
> system as cygwin on windows or darwin on mac. This makes development
> many times faster since there is no rebooting involved.
>
> An EROS port is certainly welcome if someone wishes to try it. Indeed it
> does offer an orthogonal persistence mechanism which could be useful for
> Unununium. However, it is neither our final goal, nor does it satify the
> requirement of device driver support nor is it as accessible.
--
Chevalier Dr Dr Ruediger Marcus Flaig
Institute for Immunology
University of Heidelberg
INF 305, D-69121 Heidelberg
--
Diese E-Mail wurde mit http://www.mail-inspector.de verschickt
Mail Inspector ist ein kostenloser Service von http://www.is-fun.net
Der Absender dieser E-Mail hatte die IP: 129.206.124.135
|
