Re: hurd does NOT need /hurd
On Thu, 23 May 2002, Marcus Brinkmann wrote:
> On Wed, May 22, 2002 at 07:58:18PM +0200, Emile van Bergen wrote:
> > But while we're sticking to the FHS' *spirit* of {/,/usr}/bin as a
> > gathering place of *all* executables that can be useful to users,
>
> The FHS always talks about "commands" not "executables". A Hurd server is
> not a "command" in the sense and spirit of the FHS.
Neither is a window manager. If you look at sections "3.10 /sbin:
System binaries (binaries once kept in /etc)" and 4.2, where it says
"Binaries that are not needed in single-user mode", you'll see that it
uses commands and binaries almost interchangably.
Also, on any Unix-like system, the only difference between a command and
a program is the PATH environment variable. I've said that before, and
asked you whether inclusion in the PATH is *such* a big problem that you
need a new directory under /, which was left essentially unanswered.
> Your discussion on this topic is based on pure fantasy.
I have the FHS in front of me, and I know Unix' way of passing down open
IPC ports (they're called file descriptors attached to pipe ends), and
QNX's IPC (synchronous, pid-based, combined with a nameserver for
program names, and a separate central mechanism to register pids as
managing certain filesystem prefixes) quite well, thank you.
So far, I just haven't been able to see much *conceptual* difference
between a program passing an open Mach port to a child (the translator)
and a program passing an open fd to a pipe to a child (the filter).
Sorry. It may just be me though.
> I don't know what you want to achieve with this, but it is not
> productive.
That I've found out, and I'm indeed sorry that it won't be either.
> And don't forget: This is not the appropriate forum for this
> discussion.
Allright, allright. But now the thread is already this long, it would
have been nice if people would have gained *any* insight in the Hurd's
concepts (of which the uniqueness is overstated regularly IMHO), or made
*any* productive suggestion for a more *general* FHS amendment, also
looking at the upcoming *BSD ports. But never mind. Let's indeed end it.
Cheers,
Emile.
--
E-Advies / Emile van Bergen | e-advies@evbergen.xs4all.nl
tel. +31 (0)70 3906153 | http://www.e-advies.info
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: