Is it time to fork Debian?
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.
Kernel hacker's rant about systemd
Boycott Systemd movement takes shape
Uselessd, an alternative to systemd
Debian to vote on init system again
Who are you?!Also see:
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.
Kernel hacker's rant about systemd
Boycott Systemd movement takes shape
Uselessd, an alternative to systemd
Debian to vote on init system again
The truth is that we had a more functional desktop in the days of kernel 2.4. During that time even kernel versions meant stable and uneven meant development kernels. With 2.6 Linus broke this scheme as he considered it to slow down the development. We had really many broken kernels. Picking a working kernel was like a gamble. The latest years however he has managed to get some kind of stability back. Just when other things are beginning to get messed up in the whole community.
Then came the whole KDE messing with KDE4. And for those prefering a full blown DE, KDE3 was the only serious option. GNOME was not having enough of features and it was slow. Opening one folder full of pictures caused GNOME to crawl. KDE had a thumbnail cache and behaved a lot better. GNOME crashed often and had all kind of strange bugs.
Also, while most cherish the xorg fork from xf86, I am not happy with it. We had working graphics for many years. Sure the development was very slow comparing to what it is now for xorg, but it was stable. Now many times I have to fight quite a bit to get the graphics to work on even standard computers.
Slowly GNOME became quite useable. Then it was time to mess up that one too in the worst way splitting the already splitted Linux community even more. Now we have GNOME3, Cinnamon, Mate and many other DEs.
Then also came the Pulse audio change. Suddenly, having a working sound system was nothing to take for granted. Still, even today adjusting microphones, selecting recording sources and other settings are non-trivial. All this worked a decade ago. Meanwhile the BSDs never did the OSS->ALSA->Pulse conversion. They continued to develop on OSS and now OSS is able to play from multiple sources and everything works as it should.
Granted SystemV is not perfect. I have seen nasty race conditions with SystemV but I seldom have seen a system having trouble to get to a working condition. Now when systemd got introduced things began to break and things are more difficult to debug.
I hope they fork and bring back some sanity. Do as the BSDs did with OSS: Improving on what you have rather than throwing out and beginning from scratch. Do we want many years of experimentation with the init system rather than improving what we have in a stable pace?