On Mon, May 20, 2002 at 07:52:11AM +0200, Marcus Brinkmann wrote:
> > "/hurd" isn't needed simply as somewhere to put these translators,
> > it's needed as a namespace to reference them.
> That is a nice description for /servers actually (oh, no, another new top level
> directory. But that was the last one, promised).
Hrm? Why are you typing "/hurd/foo" in your settrans command instead of
"/servers/foo" then? What's /servers for?
(If /hurd *is* just somewhere to store them and isn't meant to be a
convenient namespace, then you probably shouldn't be polluting the
"/" namespace directly -- after all, it's easy to put the files in
/usr/lib/some/strange/place, and then make them referencable from
/servers. But that would only apply if you're using /servers as the
namespace, in which case you'd be typing /servers/msdos in your settrans
commands, which you're not. So what gives?)
> > > Linux modules are not even remotely comparable to Hurd servers. Linux
> > > modules are comparable to other binary plugins that are dynamically loaded
> > > and unloaded at run time by some programs that support plugins.
> > Sure they are. Hurd servers may have signficant advantages over Linux
> > modules, but they have the same broad aim. The latter was even partially
> > inspired by the former, aiui.
> There are some specific problems that both solve, but they are different
> enough that it is dangerous to mix them up by presenting them side by side
> without explaining the differences thoroughly.
Right, but that does make them remotely comparable.
> I have heard quite often
> terms like "kernel extensions" in this thread when people talked about
> Hurd servers, this is not something one should encourage.
How about "kernel extensions on acid" ?
Hrm, maybe we could make a variant of the Chinese Fortune Cookie game
for the Hurd: everytime you try to make an analogy to Linux or similar,
you add "on acid" to the end.
"Hurd developers are like Linux developers on acid."
Fun for the whole family ;)
> The Hurd translators are not internal binaries, though. They are not directly
> executed by users, but especially in the settrans -a case above they are
> explicitely invoked by the user, with the help of settrans.
They're referred to by the user, but they're not invoked by the user.
Take debootstrap, eg, which uses a bash script with a particular ABI
(you source it, it defined a few functions which you then call) to work
out how to install different versions of Debian's base system. It has
a bunch of scripts in /usr/lib/debootstrap/scripts which can either be
referred to longhand:
debootstrap unstable ./chroot http://ftp.debian.org/debian /usr/lib/debootstrap/scripts/woody
or, if your dist has a script of its own, in shorthand:
debootstrap woody ./chroot http://ftp.debian.org/debian
The fact that /usr/lib/debootstrap/scripts/woody is a script (or that its
ABI used to make it a program) is basically irrelevant. It shouldn't go
in /usr/bin because people don't call it directly, even though they could.
The same thing applies to the Hurd servers; with the exception that while
they *could* go somewhere under /usr/lib (or /usr/libexec) they need
to be much easier to reference. This latter thing could be achieved by
having some sort of shorthand notation in all the cases where it matters
(which is easy in debootstrap's case, but might be an annoying thing
to have to retrofit with the Hurd), or to make a new, short, top-level
directory (which you seem to have done twice).
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``BAM! Science triumphs again!''
-- http://www.angryflower.com/vegeta.gif
Attachment:
pgpglb9_Soc2x.pgp
Description: PGP signature