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

Re: Let's talk about intermediate release...

Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:

> Me, too, because this is Debian default. We need to analyse Hurds current
> behaviour and then move it slowly to Debian behaviour. I have ported login
> etc once, and we need to find a naming scheme for Hurd login and Debian
> login (probably dpkg-divert and a configuration option).

I have no particular opinion about the Right Thing right now, so don't
take these comments about what should happen this month.  This is more
a matter of longer term strategy:

There are some nice features to the Hurd that Linux does not have, and
we should try and use them and not restrict ourselves to only what
Linux has.  One of those is no-uid operation and the normal mode that
login terminals have a shell running for the quick typing of
commands.  That was part of the reason for the way the Hurd's
init/getty/login work.

init, getty, and login are very low-level programs, and need to
interface with the OS in a way that other programs never need to.  It
is perfectly fine for them to be OS dependent, and I'd like to
continue to use the Hurd versions.  

If there is a desire to have a sysv style init.d and rc*.d directories
instead of the BSD rc script, then I'd like to have this initial
release keep the Hurd init as it is, and put a command in the rc
script to start up the sysv process.  If that doesn't work, then I'm
willing to consider small changes to the Hurd init to support some
other scheme, but someone will need to make some concrete suggestions
about what to do.  The Linux init cannot replace the Hurd init; they
are simply too different and need to be.

I would ultimately like to have no rc or init.d equivalent at all.  I
have some specific ideas about how to use Hurd features to obtain that
goal, but they aren't mature enough to think about implementing right


Reply to: