"Boycott Systemd" movement takes shape

by
in linux on (#2S4F)
story imageSome people have had enough, and they've organized a boycott at "http://boycottsystemd.org" to organize efforts. From the top: "Disclaimer: We are not sysvinit purists by any means. We do recognize the need for a new init system in the 21st century, but systemd is not it." OK, that's enough to keep me reading. They outline twelve well-thought-out reasons systemd is dangerous, and a set of ways you can get involved, including refusing to use systemd distros, moving to slackware, crux, gentoo, BSD, and more. Here's just one of them:
systemd clusters itself into PID 1. Due to it controlling lots of different components, this means that there are tons of scenarios in which it can crash and bring down the whole system. But in addition, this means that plenty of non-kernel system upgrades will now require a reboot. Enjoy your new Windows 9 Linux system! In fairness, systemd does provide a mechanism to reserialize and reexecute systemctl in real time. If this fails, of course, the system goes down. There are several ways that this can occur9. This happens to be another example of SPOF.
Interesting times. When's the last time you heard someone advocate moving immediately to Slackware or Gentoo?

Re: Contradiction (Score: 0)

by Anonymous Coward on 2014-09-09 12:32 (#2S6R)

This is purely guesswork, I don't read Debian mailing lists or whatever, but I think you're right in that they might be forced in some way.

Many Linux distributions have depended on RedHat or Ubuntu for a long time. If you look at the "base system" source code including file utilities, kernel, various basic daemons, you will see that someone from RedHat or Ubuntu has worked on it or is maintaining it. These aren't "sexy" projects everybody would want to work on, so I guess it's hard to find a maintainer for "GNU rm" unless you pay.

Now RedHat is bringing their agenda on the table. They aren't going to maintain login(1) anymore, because systemd supercedes it. If you are an anti-systemd Linux distributor, you have to maintain login(1) yourself. Why does an unmaintained piece of code cease to work, you may ask, but it's a completely different idiocy.

Anyway, this is all well and doable until you get to more complicated and ever-changing components like udev. Gentoo people have their own udev fork not because they love to code device managers (I'm guessing), but they either fork it or accept systemd. These guys take the risk of chasing behind the Linux kernel team regarding the changes to the udev interface, but others -understandably- may not. Those who don't will switch to systemd sooner or later..

Other dependencies are small potatoes compared to udev. udev manages all devices including the fixed drives and your PCI cards, most of the other daemons do stupid stuff like counting how many people are working on your computer, raising an alarm to all programs when you insert a USB stick etc. A Linux distributor could get away with a mostly-fake systemd package but not with a fake udevd.

Regarding GNOME, you could run it without any senseless daemons or whatever. I've been doing so in an XFCE system which somehow makes use of GNOME daemons. I killed and -x'ed most gnome daemons and some systemd daemons. It surely complains a lot but it still works.
Post Comment
Subject
Comment
Captcha
The number of body parts in the list fruit, stomach, heart and cheese is?