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

Re: hurd does NOT need /hurd

Wolfgang Jährling wrote:
> > 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/.

You know, from an administrator's perspective, there is not a great deal
of difference between "insmod blah.o options" and magic happens and the
system is able to do some new thing, and "settrans /hurd/bleh options"
and magic happens and the system is able to do some new thing. 

I appreciate that under the hood hurd servers are substantially
different from linux kernel modules, but that's beside the point; perl
modules are substantially different from C libraries under the hood, and
yet they both belong in lib because of the way the files are used.

I think one problem is that settrans seems to have no search path
capabilities, so you are stuck trying to find a directory near the root
to put these in to prevent excessive typing all the time. And this is
such a core part of the hurd that it's tempting to highlight that by
calling the directory /hurd. However, if settrans had an option to
search a path for the files, wouldn't this all go away? 
"modprobe blah options" "settrans -f bleh options"

> > 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.

That's like saying that a daemon or a X program can provide a completly
different interface than a standard unix tools program and advocating a
/daemons and a /gui-apps. It doesn't fly, because the files are used in
similar ways and so belong in similar locations.

see shy jo

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

Reply to: