The systemd controversy

[TWPonKubuntu]

I found this site, which states one side of the argument about systemd (not in favor):

http://boycottsystemd.org/

Since this battle is still being fought, I think it advisable to keep an eye on it.
We are, after all, the battle ground itself.

[kubicle]

Yes, the BSD people are miffed about it (although that's not a good excuse for them to spread moronic FUD), so not really news there.

Since this battle is still being fought

Battle is already over, systemd has spread not because it's "viral" but because it's better than the alternatives (this doesn't mean it's perfect, nor that there couldn't be something better in the future).

[SteveRiley]

The comment thread on the Phoronix article is interesting to read. I especially like #31:

To me, the fact that systemd, together with other Lennart projects, do not follow "traditional UNIX paradigms" is what makes them necessary. I firmly believe that *nix holds Linux back. I see why someone would like to stick to *NIX and in some cases, it may be a good thing, but for 99% of the population and 99.99999% use cases, I thing it's time to move on. A lot has happened since the 1980s and Linux should not try to cater primarily for those who judge an OS by how easy it is to edit config files with arbitrary, unpredicable syntaxes using vi. For those who want that, there will always be BSD and certainly also some non-mainstream Linux distros.

The boycot systemd website is basically one big screed. Post #48 in the comment thread deconstructs the boycot arguments quite nicely.

[dibl]

Many siduction users have been running systemd for over a year now -- I have it on 6 systems. I don't even think about it any more -- except when I run across material such as referenced here. I suppose, like the transition from KDE 3.x to KDE 4, there will be folks tying themselves into knots to cling to sysvinit for years into the future. If you think systemd is a disturbing change to Linux as you know it, take a read on this.

[SteveRiley]

If you think systemd is a disturbing change to Linux as you know it, take a read on this.

Go Lennart!

[claydoh]

Only thing I sort of fear about some of these big changes is the complexity, real or perceived, that raises the bar for what knowledge is needed to be able to muck about with things under the hood.

(Not that it is a bad thing, mind you!)

Also, if it becomes systemd/Linux instead of gnu/Linux, it will be interesting to see how the upstreams deal with handling with all the bug reporting and patching, theming etc etc that gets filtered through the distros right now.

[SteveRiley]

Much of the work has the end goal of reducing brittleness and complexity and simplifying day-to-day maintenance. SysV init scripts are the prime example. They're terrible to maintain and have become the boot equivalent of cellophane tape and bailing wire. systemd the thing may be more complex, but what administrators do with systemd is much more streamlined and doesn't require knowing how to write code. Thus, managing such systems is simpler.

[dibl]

As a longtime student of human nature, I find the user community reaction to major changes in Linux absolutely fascinating. Debian "Jessie" adopters are just now having their initial encounters with systemd, and suddenly systemd becomes the prime suspect for everything from overheating CPUs to dead kittens.

[SteveRiley]

Yeah, this one's gonna be fascinating to watch. Even better, to compare how the Debian community reacts vs. how the Arch community reacted. Arch switched almost two years ago -- in October 2012. There were a few of the usual complaints, but most people accepted it and got on with their lives.

[dibl]

There was only one hiccup in the systemd transition into sid. At a point in time, a package that needed to be aware of the init system was updated, and it was still looking for sysvinit. So it was necessary to convert the system back to sysv, run dist-upgrade, then convert it back to systemd. That was many months ago -- my systems have been trouble-free for a long while, booting systemd. For folks booting an OS that lives on an SSD, "systemd-analyze blame" is fun to see how fast you can get it to boot to the user login.

[claydoh]

Lennart's latest proposals are quite fascinating, necessary, but will likely change things dramatically, I am wonder which way or ways it can go. It is these complexities (again, real or imaginary) , these monolithic seeming things that scare some people.
We'll be fine as long as we can keep it from being all gnome and redhat centric.






As an aside, who noticed that the edX Intro to Linux course teaches how to do things in 3 distros - CentOS's Gnome, Ubuntu's Unity, and Opensuse's............Gnome

[SteveRiley]

CentOS's Gnome

People use a GUI on CentOS? Why? It's a server OS, and many of its packages lag current by several versions.

[claydoh]

People use a GUI on CentOS? Why? It's a server OS, and many of its packages lag current by several versions.

It's the default GUI, and it is a red Hat clone, so the instructions would be the same. Plus, I am at the beginning of the course still. lol!

[kubicle]

The boycot systemd website is basically one big screed. Post #48 in the comment thread deconstructs the boycot arguments quite nicely.

One can also read a thorough post from Lennart himself that debunks common FUD about systemd (of course he's the lead developer, but he certainly knows more about it than the people spreading the FUD).

The main reason why the BSD people are against systemd is that they aren't using it (and can't use it), and when software projects start using systemd (or depending on it) it'll marginalize BSD even more (if that's possible).

But is it the job of linux developers to make sure the things they develop work with the BSD kernel? (at least I don't think so).

People use a GUI on CentOS? Why? It's a server OS, and many of its packages lag current by several versions.

It's not uncommon for organizations to run more slowly moving distributions on their workstations (upgrades are always a hassle in bigger organizations, and they're normally happy to run stable versions for the duration cycle of the workstations). They really don't want to train their users every time there is a small change in the software they use.

[SteveRiley]

But is it the job of linux developers to make sure the things they develop work with the BSD kernel? (at least I don't think so).

I agree -- it isn't. I'm perplexed that the BSD derivatives are still even around.

It's not uncommon for organizations to run more slowly moving distributions on their workstations (upgrades are always a hassle in bigger organizations, and they're normally happy to run stable versions for the duration cycle of the workstations). They really don't want to train their users every time there is a small change in the software they use.

I realize this. I was thinking more about servers and about the security implications. Old versions of kernels, SSH, Postfix, Apache, etc. are not good to keep around. Maybe the distros are taking upstream patches and applying them to code rather than taking newer upstream branches. That can work, but it'll mess up a lot of vulnerability scanners and creates major maintenance headaches.