Slashdot Mirror


Longtime Debian Developer Tollef Fog Heen Resigns From Systemd Maintainer Team

An anonymous reader writes Debian developer Tollef Fog Heen submitted his resignation to the Debian Systemd package maintainers team mailing list today (Sun. Nov. 16th, 2014). In his brief post, he praises the team, but claims that he cannot continue to contribute due to the "load of continued attacks...becoming just too much." Presumably, he is referring to the heated and, at times, even vitriolic criticism of Debian's adoption of Systemd as the default init system for its upcoming Jessie release from commenters inside and outside of the Debian community. Currently, it is not known if Tollef will cease contributing to Debian altogether. A message from his twitter feed indicates that he may blog about his departure in the near future.

12 of 550 comments (clear)

  1. Not resigning from Debian by tfheen · · Score: 5, Informative

    I am not resigning from Debian, just from the systemd maintainer team.

    1. Re:Not resigning from Debian by Peter+H.S. · · Score: 3, Informative

      And this is exactly the kind of thing that makes many of us wary of systemd. I saw a post from someone a few weeks ago complaining that systemd wouldn't let his system start up because there was a problem in /etc/fstab, and he couldn't edit /etc/fstab because systemd wouldn't let his system start up.

      Well, systemd behaves according to classic "Unix Philosophy", see here under "Rule of repair":
      http://en.wikipedia.org/wiki/U...

      A system shouldn't be allowed to boot if important disks are missing since this can lead to "silent" data corruption".

      systemd does the right thing by stopping normal boot and just boot into a safe, minimal shell. A quick glace in the log file (journal) will instantly tell you (using red letters for emphasis) that fstab is broken in such and such a way. A quick edit with Vim can then solve the problem.

      If you have fstab entries for disk you really don't care whether they show up at boot or not, they can be marked with "nofail", that way systemd will ignore any missing disk errors from that entry and just boot normally.

    2. Re:Not resigning from Debian by tfheen · · Score: 5, Informative

      An example here is missing devices/mount points in fstab: sysvinit will happily ignore them, systemd won't consider local-fs.target reached and you'll have to fix your system for it to boot correctly.

      And this is exactly the kind of thing that makes many of us wary of systemd. I saw a post from someone a few weeks ago complaining that systemd wouldn't let his system start up because there was a problem in /etc/fstab, and he couldn't edit /etc/fstab because systemd wouldn't let his system start up.

      Yes, this is a bug (sorry, I don't have the bug # handy) and there's work in progress on preventing you from shooting your foot off (by requiring you to fix your fstab before the installation completes). It's still possible to boot up using sysvinit by booting with init=/lib/sysvinit/init as long as you've not uninstalled the sysvinit package. I'm sorry about people hitting this, but on the other hand, there's a reason why Jessie isn't released yet, we have some bugs to fix first. :-)

    3. Re:Not resigning from Debian by Peter+H.S. · · Score: 2, Informative

      In the sysvinit scripts the philosophy is not so stark: the aim is to bring the system up to the greatest extent possible even in the presence of failures. If a single mount or service fails, we report the error and try to continue on. It's not perfect, but mitigation in the face of unexpected failure is never going to be.

      If I make a typo when editing the fstab, I don't think bailing out is ever appropriate. The "nofail" flag is only useful for expected failures, and I think that the sysvinit script is correct in not using it as a basis for unilaterally failing startup when in almost all cases we could bring the system up to a state where the admin can log in and rectify things. This is going to be incorrect from the worldview of a perfectionist, but it's certainly the pragmatic choice.

      There are several problems with doing things that way; first of all, its is evident that it isn't uncommon for people to have stale or plain broken fstab entries. This strongly suggest that they are unaware of this, probably because if the system boots, people don't look in the log files. Finding such critical errors in legacy style syslog text logs aren't easy either; if you don't know the nature of the error, it is hard to grep for it.

      So exactly because SysVinit cover up such fstab errors, they may remain undiscovered until some other part of the system fails in a noisy matter; at that time irretrievable data loss may have occurred. Allowing such data loss isn't being pragmatic, it is bad practice by any standard.

      systemd detects the fstab problem and boots into a special "emergency mode" (like runlevel 1) where the admin can diagnose and fix the problems.
      systemd works really well in this regard; a simple "journalctl -b -p err" will find all such errors in the boot process and display them.

  2. How systemd became Debian's default init system by tfheen · · Score: 5, Informative

    It's a pretty long story. If you want to read all of it, you probably need to read the entire debian-devel and debian-ctte archives from approximately a year and a half ago until February/March this year.

    A shorter summary is something like (from my memory, coloured by my views, etc, but I believe it's largely correct). User names are generally @debian.org, finger $user@db.debian.org for full names and such. It's a bit rambling and written in one go, but it's what you get this time:

    - I upload systemd to Debian about a month after its initial release, get it into a ok-ish shape for wheezy, but not anywhere near suitable for being the default.
    - Other distros start switching to systemd as default, various people in Debian start discussing if we should switch to systemd. Some people say yes, some no, some want to switch to upstart. Bickering and discussions in equal measure spread out across all media (IRC, blogs/planet, mailing lists, in-person discussions). Most of it reasonably civil.
    - At some point, paultag files https://bugs.debian.org/cgi-bi... (_massive_ bug report, you don't want to read it all) , asking the Debian technical committee to default on what the default should be.
    - Lots of discussions happen, we use a bit of liw's and rra's Essay Debate System (https://wiki.debian.org/Debate, https://wiki.debian.org/Debate...) to structure the debate. It's Debian, it has to be A System.
    - vorlon (Steve Langasek) sets up VMs using the various init systems for the Technical Committee members to play with. They do so and write up their findings and arguments. rra's writeup is at https://lists.debian.org/debia... and is possibly the best comparison I've ever read of init systems. Lots more discussions happen. I contribute a fair bit with my systemd maintainer hat on (though we're at this point a team maintaining systemd in Debian) and is very happy this happens while I'm holidaying in Spain so I don't have to deal with a day job at the same time.
    - A lot of arguing internally to the CTTE whether to couple the question of what the default init system should be with whether it's ok for packages to require a given init system. bdale resolves the knot by calling for votes on a proposal very quickly after proposing a ballot. iwj sees this as backstabbing and is still very, very angry about this to this day.

    The vote ends with systemd being the winner, after bdale's casting vote as the CTTE chair.

    After this, there is an attempted General Resolution in March, which fails to get enough seconds, this is restarted by iwj on late October this year. The goal of this GR appears to be to forbid packages to depend on a specific init system.

    1. Re:How systemd became Debian's default init system by the_B0fh · · Score: 5, Informative

      iwj's rebuttal to rra's write up:

      https://lists.debian.org/debia...

    2. Re:How systemd became Debian's default init system by the_B0fh · · Score: 4, Informative

      And iwj's original comparison of systemd and upstart:

      https://lists.debian.org/debia...

  3. A bit of background by tfheen · · Score: 5, Informative

    Just posted on my blog with a bit more background: http://err.no/personal/blog/te...

  4. Re:Who are you calling "immature twats" ?? by stoborrobots · · Score: 4, Informative

    Serious question here: how avoidable is systemd currently?

    For what it's worth, I managed to purge everything systemd-related from my debian testing system the other day. I had to replace NetworkManager with WICD, which is a pretty good straightforward replacement (although you need to re-create your configuration). Also, I run KDE, so that made things easier.

    As I understand it (if I correctly noted the packages which got removed), you can't run a gnome system without systemd; however, you can still run debian jessie with kde without systemd.

    The only packages which are coming from the systemd source package on my system any more are udev and libsystemd0 - however, given that systemd-sysv and systemd-logind are no longer installed, I consider that basically a win.

    libsystemd0 is only still there because cups-daemon and kde-runtime require it; but given that it only defines the interfaces, it seems benign.

    udev and libudev1, despite being packaged as part of the systemd source, do not depend on it according to the package info...

  5. Re:Systemd is killing the Debian project. by gmack · · Score: 3, Informative

    And the criticism from those who are against systemd is extremely important to consider. The complaints are very sound, from a technological perspective. They're also based on decades of real world experience, which just cannot be ignored.

    I'm not a total fan of every design feature of everything systemd has done but gave you actually read their supporting references? I'm most of the cases boycottsystemd has rephrased events to make the systemd folks look as bad as possible in ways that would make a Fox news reporter feel proud. A good example is their comment about requiring "bug for bug" compatibility with glibc was instead a use of a certain non posix flag needed for thread safety and complaining that it is tightly tied to Linux is about as helpful as complaining that udev is tightly tied to Linux.

    At any rate, I find it very telling that they don't actually mention any of their supporters.

  6. Re:Systemd is killing the Debian project. by t_hunger · · Score: 3, Informative

    Systemd is monolithic - not built into a single binary blob, but split into several tightly-dependant binary blobs.

    Follow the Unix philosophy: Do one thing and do it well and work with other tools to implement complex tasks.

    With your definition "ls -alF | grep "^drwxrwxrwx " is monolithic: The grep statement depends on ls formatting its output in a certain way. That makes them tightly-dependent binary blobs.

    --
    Regards, Tobias
  7. Re:damn by BasilBrush · · Score: 1, Informative

    I'm not the victim. But you are one of the abusers.