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

Re: hurd does NOT need /hurd

On Mon, 20 May 2002, Marcus Brinkmann wrote:

> On Sun, May 19, 2002 at 07:11:34PM -0500, Adam Heath wrote:
> > Fine enough.  But /lib/modules could also have a non-versioned subdirectory,
> > /lib/modules/translators.
> I don't see what fixes that.  Translators are not libraries, not modules.
> Why do you think that /lib/modules/translators is a good place for them?

/lib contains things not loaded by users directly, but by something run by a

> Actually, they should.  It should be /lib/linux or /lib/linux-modules, or
> even just /lib/liblinux_modulename.so.

I could be convinced of this.

> > > 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.
> >
> > Use binfmt_misc, and Linux can run anything.
> Sorry, you lost me.  I see no connection between this reply and the
> paragraph you replied to.

apache has modules it loads.

Linux has 'modules' it loads.  These can be /lib/modules/`uname -r/..., or
/bin.  What is the difference, really?

In fact, any program that uses getent(), may end up using modules, by way of

They all contain executable code.

> If it would run multiple copies of a module, it would run multiple copies of
> a module, not an external binary in user space.

What does it matter were or how it is run, as long as the service it provides
is the same?

> > I say they are.  You have not given any concrete answers.  "/hurd is the
> > place." is not a reason.
> Try your rhetorics on someone else.  I have given plenty of reasons.  I have
> given an introduction on the Hurd design and explained the semantical
> difference between programs in /bin, /sbin, /libexec and /hurd.  Now it is
> on you to try to grasp this distinction, as fine as it is.  The fact that
> you are still comparing Hurd translators to Linux binary modules proves
> clearly that the concept of the Hurd has not trickled in yet.  I don't
> blame you, it usually takes longer than one email and a quick intro to
> understand those details, but don't blame me.  Do some research on
> hurd.gnu.org, maybe read my introductory talk on the Hurd and Thomas
> design paper, and maybe try out a running Hurd system and play around
> with translators a bit.  Come back with concrete questions if you have them.
> "I say they are." is not something that enables me to understand what
> explanantion of mine you did not understand so far.

1500 page essays are not proof.  Make it short, simple, stmts.

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

Reply to: