Is it time to fork Debian?

by
in linux on (#2TFM)
The grumbles over systemd and its ramifications are well known and have even been discussed on Pipedot [links below]. But it's taken on a new urgency. The members of the Debian community are set to vote on an init system, and if by any chance the "give preference to systemd" option wins, this group of angry sysadmins is organized, willing, and prepared to fork Debian. Their argument is measured and calm, but they've got their finger on the trigger. Here is just a portion of their argument.
Who are you?!
We are Veteran Unix Admins and we are concerned about what is happening to Debian GNU/Linux to the point of considering a fork of the project.

And why would you do that?
Some of us are upstream developers, some professional sysadmins: we are all concerned peers interacting with Debian and derivatives on a daily basis.We don't want to be forced to use systemd in substitution to the traditional UNIX sysvinit init, because systemd betrays the UNIX philosophy. We contemplate adopting more recent alternatives to sysvinit, but not those undermining the basic design principles of "do one thing and do it well" with a complex collection of dozens of tightly coupled binaries and opaque logs.

Are there better solutions than forking?
Yes: vote Ian Jackson's proposal to preserve freedom of choice of init systems. Then make sure sysvinit stays the default for now, systemd can be optional. Debian leaders can go on evaluating more init systems, just not impose one that ignores the needs of most of its users.

Why is this happening in your opinion?
The current leadership of the project is heavily influenced by GNOME developers and too much inclined to consider desktop needs as crucial to the project, despite the fact that the majority of Debian users are tech-savvy system administrators.

Can you articulate your critique to systemd?
To paraphrase Eric S. Raymond on the issue, we see systemd being very prone to mission creep and bloat and likely to turn into a nasty hairball over the longer term. We like controlling the startup of the system with shell scripts that are readable, because readability grants a certain level of power and consciousness for those among us who are literate, and we believe that centralizing control services, sockets, devices, mounts, etc., all within one daemon is a slap in the face of the UNIX philosophy.
Also see:
Kernel hacker's rant about systemd
Boycott Systemd movement takes shape
Uselessd, an alternative to systemd
Debian to vote on init system again

Re: Bravo for sysadmins - and pipedot! (Score: 3, Informative)

by caseih@pipedot.org on 2014-10-21 14:35 (#2TJ7)

Maybe you should read up a bit on systemd before you post this kind of untrue stuff, or maybe run it and see just what it does. Systemd does *not* cram everything in pid 1! To say it does is false, plain and simple. You'd know this if you took some time to examine a system that runs systemd. It also does not require a reboot for most updates to systemd. Everything that can possibly be done outside of pid 1 is done outside of pid 1. If you do an update, the package manager issues systemctl daemon-reexec and all the systemd subsystems restart with the new binaries. If something was changed in pid 1 then, like upstart or system v, a reboot is required. But that just doesn't happen very often. I've installed maybe 2 updates to the systemd packages on RHEL 7, and did not need a reboot.

I don't mind actual arguments being made against systemd, but I rarely find any in these discussions! Just mumblings about philosophy and theoretical problems, completely ignoring the very real and ongoing problems with system v and the like, which are impacting a lot of sysadmins. Which is pretty crazy. We've had maybe a half dozen stories on it in the last month on the other sites, and no one can say anything other than FUD it appears.

I'm not arguing for systemd so much as taking issue with the way people are spreading this sort of misinformation, and taking issue with the idea that system v wasn't broken (it is broken, especially with modern, hot-plugged server hardware).
Post Comment
Subject
Comment
Captcha
Fifty seven, 86, 46, 31, fifty six or 3: which of these is the largest?