Re: hurd does NOT need /hurd
On Sunday 26 May 2002 07:17, Thomas Bushnell, BSG wrote:
> Andrew Suffield <asuffield@debian.org> writes:
> > On Sat, May 25, 2002 at 12:22:11PM +0200, Fabian Sturm wrote:
> > > So please dont think that sysadmins should have any right to forbid
> > > something to the users who actually use the machines.
> > > In my eyes is this one of the biggest grievence which exist nowadays.
> > > E.g. not to have the possibility to set up a crypto filesystem
> > > on your own in Linux..
> >
> > I presume by that you mean Linux is incapable of this; if so, you're
> > misled.
>
> The key phrase is "on your own". One strong advantage of the Hurd is
> that you don't have to be root to do things like this.
Please, let's be quite clear and fair here. Linux kernel couldn't not be
directly compared with Hurd, because Hurd is a set of programs running in
user space and implementing critical system tasks (hence the flexibility and
the arbitrary runnable servers of it) which in traditional unix kernels are
implemented in kernel space. User space is not so safe place to run these
tasks, but it is another issue anyway. Instead you must compare Linux kernel
with Mach microkernel (although they are quite different things). Do you
think that if all those monolythic kernel supporters like these hundreds of
Linux and *BSD kernel developers find that Hurd is something worthy, will not
implement some features (in unforeseen future) in their modular monolytic
kernels to unload appropriate kernel module(s) and to start the relevant
hurd's (or whatever) user space system server (s) and these kernels to be
capable to handle message passings like Mach does. (which is hard to believe
because they are strong supporters of monolytic, but modular kernel approach,
any technical reasons that to be imposible?). So they can move some task(s)
from kernel space to user space and vice versa (runtime or not) . In other
words, if Linux and *BSD can serve as kernel (microkernel, in that case) to
Hurd. So Hurd must not be thought as kernel like you are trying to present,
and nobody said that it won't be ported to other kernels (which appear to be
called semi-monolytic if they exist in the future, except other microkernels
of cource like L4, etc). There is nothing new here.
--
Greets,
fr33zb1
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: