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-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: