Re: hurd does NOT need /hurd
Adam Heath <email@example.com> 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
> 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.
Wolfgang Jährling <firstname.lastname@example.org> \\ 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 email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org