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

Re: hurd does NOT need /hurd



Adam Heath <doogie@debian.org> wrote:
> 1) is /hurd versioned?  Or is /hurd a 'special' filesystem(kinda like devfs
>    for linux), that lists the available services that have been compiled into
>    the kernel?

Hell, no. Why would one want to compile services into the kernel?
*schudder* It's just a directory like /bin, which containy binaries. But
it contains very special binaries, as has been said before.

> 2) Could the ideas that the items placed in /hurd be useful outside of hurd?
>    Ie, could other operating systems make use of translators?

Of course you can change Linux so that is essentially the Hurd. But I
don't see how any existing system could use them.

> Now, for some other analogies, to existing practices, showing that /hurd is
> not needed, *at all*.

Of course it is not needed. Just as there is no need for /bin. Or /lib.
Or /home. You can put everything in one directory. And with the Shadowfs
translator you could actually kind of do this if you like. ;-)

> In the current FHS, there is documentation about /lib/modules.  Currently,
> this describes Linux drivers.  However, I see no reason it can't be used for
> hurd as well(hurd purists will say that because Linux came up with it, it
> *CAN'T* be good, so they don't want to use it).

Translators are no kernel modules. They are normal binaries, but with
special functionality.

> However, unlike /hurd, /lib/modules does not contain any reference to the
> kernel that is being run.

Sorry, I don't see any reference to GNU Mach here.

> I'd much rather have hurd use /lib/modules, instead
> of tainting file system layouts with special /linux, /hurd, /freebsd crap.

Of course you do, because you don't understand what /hurd is about. It
is about the Hurd server binaries, which are started by users and should
not be hidden in a directory like /lib/you/cant/find/me/.

> hurd.  In fact, there already is use, in Linux.  Think user-space nfs(a
> kernel-based nfs module talking to a user-space nfs daemon).  cfs works this
> way, as does probably sfs.

Translators can provide arbitrary interfaces, not only the file system
interface. Thus, this is something completely different.

> So, why then do we really need /hurd?  What are the *real* reasons?

The reason is that the stuff in there is semantically different from
everything that exists in Unix and ever will exist in Unix.

Cheers,
GNU/Wolfgang

-- 
Wolfgang Jährling  <wolfgang@pro-linux.de>  \\  http://stdio.cjb.net/
Debian GNU/Hurd user && Debian GNU/Linux user \\  http://www.gnu.org/
The Hurd Hacking Guide: http://www.gnu.org/software/hurd/hacking-guide/
["We're way ahead of you here. The Hurd has always been on the    ]
[ cutting edge of not being good for anything." -- Roland McGrath ]


--
To UNSUBSCRIBE, email to debian-hurd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: