l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: POSIX (was: Re: Let's do some coding :-) )


From: Marcus Brinkmann
Subject: Re: POSIX (was: Re: Let's do some coding :-) )
Date: Tue, 25 Oct 2005 13:11:00 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Tue, 25 Oct 2005 02:04:31 +0200,
<address@hidden> wrote:
> Mind to point me to those? The best I know are GNU/Linux and some BSD
> variants. Quite frankly, they all suck.

Just for the record, I don't agree.  GNU/Linux works very, very, VERY
well in many contexts.  We can start nitpicking, but we should not
forget that in terms of usability, it offers quite a lot.

> We (well, most of us at least) aren't aiming at creating a perfect
> system. All we really want is a considerably better implementation
> of something resembling POSIX.

Well, I don't.  If all I get is POSIX, I am quite happy with
GNU/Linux, thankyouverymuch.

> (Including extensions that, in
> conjuction with the more powerful base architecture, allow both
> users and programmers to avoid the biggest problems of POSIX.)

Here starts the trouble.  What we have found out is that you can not
extend POSIX in a perfectly compatible way at the lowest level of the
operating system, and still fix its problems.  The problems with POSIX
are inherent in its design.

So, what to do?  The solution for me is to look for a better native
system, and then provide a compatibility layer on top of it.

Note that even the Hurd on Mach agrees with this goal: It has a native
system (Mach, and the Hurd servers) and then a compatibility layer on
top of it (the Hurd servers and glibc).  It's just that the "native
system" we have on Mach sucks vehemently.

> Of course, in the long run we want to move away from POSIX; and we are
> trying to create a migration path, be it through extensions, be it
> through slight changes, be it through alternative interfaces where
> unavoidable. But we definitely do *not* want to make POSIX applications
> some kind of second class citizens.

This is not strictly necessary.  We would have to discuss some of the
details, but well, in some sense they are second class because they
use an inherently insecure interface.  However, this can be mitigated
by confinement.

There are basically two models I have in mind.  I think both models
can be supported by the same implementation.

The first model is a POSIX server per POSIX process.  This would mean
rather tight integration.  For example, you could run one POSIX
process on your desktop, among other native applications. The POSIX
process gets certain capabilities, and is hopefully confined.

The second model is a POSIX server for several users.  This would
basically emulate a complete Unix environment.  In this environment
you could configure multiple users.  You would have a system
administrator and individual users.  You could install a complete
operating system like Debian (with a bit of effort).  The whole system
would be confined.

The first variant would be more useful for users.  The second variant
would be more useful for system administrators who want to leverage
the wealth of Unix software without rethinking old strategies in terms
of software installation, configuration etc.  It would be a bit like
"subhurds".

So far, in the Hurd on Mach, we support something a bit like the
second model.  We do not really support the first model well.  As a
gut reaction, I would like to work on that.  Haven't thought about it
much, though.

Thanks,
Marcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]