Hi, thanks for the clarifications. I now see that I forgot about the additional Hurd power.
But please understand that I am just trying to port existing working infrastructure from Debian GNU/Linux to the Hurd. The new Hurd way will require substantial changes to the packages and the Debian policy document. (and to the Hurd source, too, that means implementing new servers etc). On Mon, Feb 22, 1999 at 04:56:35PM -0600, Gordon Matzigkeit wrote: > > Debian's runlevels are merely different types of automatic startup. > Linux has no such thing as passive translators, but the Hurd can use > them to eliminate nearly every aspect of system startup, by deferring > initialization until it is actually needed. Ok. It will need some time until thiese features are fully exploitable in the existing packages. > Marcus's example of foreign keyboards is a good one. I imagine under > Linux, it is implemented by a program that sends a bunch of ioctls to > the kernel shortly after startup. On the Hurd, it would make sense to > be able to specify keyboard settings as arguments to /hurd/term, or a > configuration file that /hurd/term can read, then just change the > /dev/console (or other console) translator. I see now that the use of init scripts will therefore be less on the Hurd, and now I understand why Thomas considers sysvinit as too complex. [...] > It all comes down to the fact that a working Hurd configuration should > only need /boot/servers.boot, and a bunch of passive translators. > Everything more active than that (such as starting inetd, or the > gettys) can be done quite easily from /libexec/rc. Okay. I see now. Still, what about higher level services like apache? > Let's have a program called `sysvinit', which can be called from > /libexec/rc, or symlinked to it. That program will read /etc/inittab, > and do all the magic of emulating a Debian system. The `telinit' > program would contact sysvinit via RPC to change the ``runlevel''. > When it exits, it will kill off all its children. [...] > Does this make sense? I think it should be clear that we can package > a sysvinit for the Hurd without needing to make any changes to the > existing infrastructure. We will have a sysvinit package anyway. > Personally, I'm looking forward to Thomas's new approach to runlevels, > but an independent sysvinit package will provide sysv compatibility > for as long as we need it. If I understood everything correctly, and if the sysvinit program is informed on each runlevel change, this solution is fine with me. How hard is it to implement? Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@ Marcus Brinkmann GNU http://www.gnu.org master.debian.org [EMAIL PROTECTED] for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
