Re: hurd does NOT need /hurd
On 22 May 2002, Thomas Bushnell, BSG wrote:
> It's your lack of understanding and knowledge of the Hurd. No big
> surprise there! What amazes me is that you think you're competent to
> try and solve, let alone understand design issues without actually
> understanding the design.
What amazes me is that you cannot explain in a few words, to a person
who is capable of abstract reasoning, and knowledgeable in Unix, QNX,
and software engineering, why a separate directory is *critical* in the
Hurd's design for its usability, *while other changes to FHS are not*.
And yes, I understand that Hurd translators are ran only a tiny
percentage of the time as commands, and the rest of the time in a
settrans-environment, whether registered as a passive translator or
started immediately as an active one.
But if *frequency*, *likeliness* of use in a particular execution
environment is the criterium you want to use for using separate
directories for binaries (as opposed to *possibility* for use in a
particular way), then why say that window managers, which are ran
possibly 0.02% of the time as a shell command, do *not* deserve a
separate directory because of their *most likely* use (not as a shell
command, regardless of what you do personally), or filters, or cron
jobs; while the Hurd's translators, which will possibly also be ran say
0.02% of the time as a command in order to check the version and usage,
*do* deserve a separate directory because of their most likely execution
environment? Why?
I don't *need* to understand the Hurd's design at all in order to be
able to reason about different execution environments and *how* they
differ, the difference between program images and user commands, or
about programs that manage part of the filesystem namespace.
If the Hurd's design is *so* unique that *none* of those general
concepts are useful for discussing it, then you *definitely* could have
done a better job in explaining it.
But so far, everything I've seen from it completely fits the Unix
model for program images, commands, and it only adds user programs to
manage the filesystem namespace, which is done by resolving pathnames to
Mach IPC ports in a nifty way, which gives the overall system some very
nice properties. Tell me what I'm missing here. Text or URLs. Thanks.
To paraphrase Richard Feynman: if you can't explain it in simple terms,
you don't understand it properly. Thats a shame for a primary author.
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-hurd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: