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

On init in Debian

There is a lot of feelings and temper involved in the current discussion
of init implementations in Debian. I'd like to try to de-escalate by
summarizing things in as objective and non-confrontational manner as I can.

* sysvinit is mostly working for everyone, but it has problems, in part
  caused by changes in the kernel over the years. See [1] by Petter. 
  It's not even primarily about boot speed, but about reliability, 
  especially in the early boot.
* It's also the case that our init.d scripts are full of repetitive code,
  often subtly different, and similar bugs happen independently in many
  places. If we stay with sysvinit, we need to fix this.
* Event based init systems attempt to provide other things too,
  including faster boot speed, and an overall simpler, faster, leaner,
  and more reliable system.
* The two main event based contenders are upstart and sysvinit. Both are 
  written for Linux, and rely on various Linux specific kernel features.
  They have some technical and other differences, and have upstream
  developers who can be considered controversial in various ways by
  various people in Debian. However, both are, of course, free software,
  and both should work acceptably well as an init in the Linux version of
* We can choose to stay with sysvinit, but then we'll need to start
  developing it to be more suitable for modern Linux.
* We can choose upstart or sysvinit for Linux, but then we need to deal 
  with their current incompatibility with the Hurd and kFreeBSD ports of 
* It might be workable to have most services use init.d files even in the
  future, and then use sysvinit on the non-Linux ports. However, this
  removes much of the benefit of the new inits on Linux.
* We could require every package that provides a service that needs to be
  started by init to support both sysvinit and upstart or systemd. However,
  given the realities of Debian development, this would probably mean
  that one of them would be badly tested, and therefore likely to be buggy.
* We could try to have a tool to automatically convert an upstart or systemd
  service configuration into a sysvinit init.d script. I have no idea if that
  is really feasible, but if it worked for most packages, we could probably
  live with the others requiring some manual work.
* We can decide to drop those ports. They're not used a lot, but they do
  have a loyal and enthusiastic fan base, even if small. Dropping them is
  not an easy decision. Keeping them is also not easy, if it means 
  compromising the quality of the Linux version of Debian. This is probably
  what causes most of the emotional distress.
* We can attempt to port upstart or sysvinit to the Hurd and kFreeBSD, 
  either by changing the userland code or the kernel code. This may or may 
  not be a large undertaking; I don't know if anyone's actually attempted 
  it yet. (As a side note, if Canonical wants to stick with upstart, it'd 
  be in their interest to have Debian use it too, I think, and perhaps they 
  could do the Hurd and kFreeBSD porting?)
Did I miss anything of substance?

I don't know what should happen next, except someone should take leadership
on this issue and find a rough consensus on what we as a project want to do.
The usual way of that to happen is for someone to grab a keyboard and start
writing actual code, as opposed to e-mails. Do-ocracy ftw.

[1] http://lists.debian.org/debian-devel/2012/02/msg01043.html

Attachment: signature.asc
Description: Digital signature

Reply to: