Is it time to fork Debian?

in linux on 2014-10-19 16:09 (#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

May the Gods save us from systemd (Score: 4, Insightful)

by bsdguy@pipedot.org on 2014-10-20 05:02 (#2TGJ)

I started out in Unix in the very early 1980s. I was drawn to it because of the toolbox approach and the readability of the configs and startup scripts. I started with BSD 4.2 on PDP 11s, then dualport OSX from Pyramid, followed by some Xenix and Suns running SunOS 3.x (BSD based). Over the years I have worked with pretty much every flavor of Unix, BSD, or GNU/Linux you can think of. Most of them were simple to deal with when moving from one to the other because the configs and startups were readable by anyone with even moderate skill in the art. I could teach a newbie how to understand the startup system and troubleshoot startup problems in very short order.

At some point commercial Unix vendors decided to "make things easier" and we started to get things like SCO Unix overwriting startup files and configs from it's GUI admin tool. It stored stuff in a private DB and just over wrote changes put in files by hand. NOT GOOD. Then of course with Solaris 10, which brought us the great ZFS, Sun decided to go to a monolithic startup database, which if corrupt means the system will not boot. Other commercial vendors have done similar stupid things over the last 10 years.

I think if the Debian core team wants to go against 30+ years of good solid proven engineering then they need to find a surgeon to give them a Rectal craniotomy.

If non-systems administrators can not figure out how to administer a system who the hell cares? Every time I have been called in by startups where the programmers tried to develop code and figure out system administration as well as design how the programs interact with the system it has been a total FUBAR.

The problem these days is everyone who has walked past a computer thinks they are a systems administrator or systems engineer, and vendors as well as, it appears, Team Debian , are feeding that fantasy and in the process destroying the versatility, agility, and maintainability of current POSIX systems. It is exactly this kind of stupidity that makes it more difficult all the time to properly administer systems as well as move between POSIX systems from different vendors.

JUST SAY NO TO FORCED INIT SYSTEM CHANGES.