

DistroWatch QA: Distributions not adopting systemd - mariuz
http://distrowatch.com/weekly.php?issue=20140908#qa

======
DCKing
I've seen this discussion come by many times, and every time I had to get my
eyebrows back from the back of my head when reading the responses.

I get what the technical differences are between systemd and alternative
solutions. That is not the problem. What I don't get is how the init system of
_anything_ can evoke such emotions. It all goes _way_ beyond expressing
preference. The flamewars and vitriol that have been spread are disgraceful,
and people are seriously considering switching to different operating systems
because of whatever package runs their daemons and their startup scripts. It's
embarrassing.

As a frequent user of Linux, it completely mystifies me how changes in this
can cause such emotions. I mean, I'm the kind of guy who did not prefer Fedora
for such details as font rendering and certain package policies, so I'm not
insensitive to distro differences in general. But I guess I'm ignorant about
why so many people seem to cherish such very strong opinions about an init
system.

What is it about init systems that causes this outrage? I really want to know!

~~~
e7620
In general, this is not about the merits of systemd as a program.

GNU/Linux represents choice and freedom. The abundance of distros is proof of
that. You can choose your preferred init system, system logger, cron daemon,
desktop environment, browser, etc.

Now, systemd is being forcefully pushed to all distros. For instance, by
merging udev (a part of the Linux kernel) with systemd. We can't even build a
distro anymore without downloading systemd. User choice is under threat.

In this situation, some people align with the forceful approach of systemd.
Some prefer to choose what goes into their computers. This is similar to the
inclusion of DRM in Firefox, there's no middle ground.

So the debate is really about competitition vs a walled garden provided by
systemd.

~~~
icebraining
_udev (a part of the Linux kernel)_

I thought one of the advantages of udev (vs devfs) was that it was completely
in userspace?

~~~
e7620
You're correct, but that's not the point. Some device drivers run in
userspace, even the Linux kernel itself can run in userspace!

~~~
icebraining
How is it not the point? You said "we can't even build a distro anymore
without downloading systemd," due to the implication that udev was embedded in
the kernel, but that's not true. You can build a distro - just don't use udev.

~~~
e7620
udev is a necessary component of Linux. You could say just use a fork like
eudev. Fine (for the time being). But the thing is, you can't _remove_ udev
from the Linux kernel _if_ you want to keep it calling Linux, as it'd be a
fork.

~~~
icebraining
_udev is a necessary component of Linux._

Why do you say that? That's what I don't understand. As far as I know, that's
not true. You can run a Linux system without the udev daemon, or with one
written by you.

 _But the thing is, you can 't remove udev from the Linux kernel if you want
to keep it calling Linux, as it'd be a fork._

But udev isn't _in_ the Linux kernel! How can I remove it from there?!

~~~
e7620
> You can run a Linux system without the udev daemon, or with one written by
> you.

A GNU/Linux system consists of several components.
[http://www.gnu.org/gnu/linux-and-gnu.html](http://www.gnu.org/gnu/linux-and-
gnu.html) shows some examples.

If you remove udev from Linux, I see at least two problems. One of them is
technical: programmers expect Linux to have udev, because that's what the
Linux authors advertise. The other is legal: Linux is a trademark, and if you
replace something and introduce some incompatibility, it's a bad idea to keep
calling it Linux.

> But udev isn't in the Linux kernel! How can I remove it from there?!

I think here lies the misunderstanding, udev was previously in the kernel
repository, now it isn't. Fair enough. But consider that GNU is also separated
in a different repository, but it still comprises the GNU/Linux system as a
whole. Imagine we could only download GCC (necessary to compile Linux) as part
of Adobe Flash, don't you think I could say the same? That "we can't even
build a distro anymore without downloading Adobe Flash"?

~~~
icebraining
_But consider that GNU is also separated in a different repository, but it
still comprises the GNU /Linux system as a whole._

Yes, and udev would compose an hypothetical "Udev/Linux system". But Linux
itself doesn't need udev.

GNU / GCC is different because you literally can't compile Linux without it.
But if and when LLVMLinux succeeds, I don't think you could say the same.

~~~
e7620
> But Linux itself doesn't need udev.

Would it really work? I think you'd have to rewrite some parts of the kernel,
but I may be wrong now, in the past or the future.

Anyways, we're arguing semantics here, it'd be better for all to separate udev
from systemd. It's like Windows installers usually bundling the program with
some crap, and I know most people don't appreciate that.

------
josteink
That piece seems a bit ... unbalanced.

It starts off with confirming that systemd is indeed the very baddest bad
thing there is. And then later on mentions that "but, yeah, I don't actually
have any troubles with it" at the very end.

I'm sure there are people who have their reasons for avoiding systemd, and for
them a list like this is probably great.

But for those still on the fence, this reeks of scare-tactics.

Let's make on thing clear: Systemd _does_ provide a sufficient amount benefits
and I can say that without any particular source of my own.

Why? Because pretty much all the distros out there are moving towards systemd
and you would be out of your mind to think they are putting in this _effort_
to migrate to systemd if they hadn't done a technical consideration and
decided it was a worthwhile thing doing.

~~~
empressplay
"Pretty much all the distros out there" except for: (from TFA)

"The PCLinuxOS distribution has not adopted systemd and, so far as I know, has
no plans to migrate to the new init software. Slackware Linux, CRUX and Gentoo
Linux are all Linux distributions which are unlikely to adopt systemd as their
default init system for philosophical reasons."

The philosophical reasons being the centralisation of control over a key
aspect of Linux to a group of developers that aren't universally trusted?

~~~
nailer
Red Hat/Fedora, Suse, and Debian are massively popular.

Gentoo is fairly large, but the others are niche.

~~~
bigbugbag
I've used debian for 15 years and I'm looking for a replacement because
systemd.

The turning point was systemd breaking a fully functional system and forcing
it into recovery mode which was simply broken and going in an infinite loop of
displaying it was about to offer a recovery terminal which never came.

Not having log as text and useless info from systemctl and journalctl instead
of the useful info I had in traditional logs played a significant part and the
attitude and position of the systemd guys too.

This debian forums post sums it all:

From my (relatively short) experience with systemd as init I find that systemd
(at least as packed in debian) is really far from being ready. Even the
slightest unexpected (to systemd) configuration will make it break from all
sides, and even the so-called emergency shell is painfully broken. Together
with both the upstream _and_ downstream (debian maintainer) attitude ("this is
not a bug, fix your configuration so that it matches our expectations, which
by the way change every day and we don't tell you about it" \-- i.e. the exact
opposite of Linus/kernel's attitude "we don't break userspace").

~~~
baldfat
Arch users made the switch a long time back. When switching to systemd it
isn't just install and go.

Systemd is mature and reliable and is running on so many servers it isn't even
funny. I personally like it and it is much better for me to admin my services
on servers.

~~~
josteink
> When switching to systemd it isn't just install and go.

This I can definitely agree with. Has debian said anything about _replacing_
sysvinit on existing installs or will they just be using systemd as the
default on new ones?

The latter would from my point of view be a reasonable compromise and
shouldn't alienate anyone.

~~~
chaosesqueteam
Yes. The systemd people are in control of the decision making process in
debian now. They have decided that an upgrade to jessie will silently replace
sysV with systemd. They have rejected all other arguments.

Honestly, these truly are authoritarian scumbags. Linux is finished. And it
happened quickly too.

------
dsr_
Let's suppose that you don't want to use systemd, but you do want to use
Debian.

No, let's back up a step. Let's say you don't want to use GNOME3, but you do
want to use Debian as a desktop system.

In that case, you would simply install KDE or XFCE or LXDE, or just have a
display manager of your choice start the window manager of your choice. There
are lots of choices and Debian considers them all first-class citizens. Nobody
gets upset when you say "I don't like running KDE, what are the alternatives?"
If you say "It looks like xterm has a new dependency on gtklib, what's up with
that?" your bug report will be addressed.

But if you say "I don't want to run systemd, it seems to have been installed
by mistake" what you get is:

    
    
       systemd is the future, you should run it.
    
       why are you so rude? systemd is the default init. Get used to it.
    
       it's not that there are lots of people who object to systemd, it's all the same people being loud and repetitive.
    

and

    
    
       it's all settled now, so any attempt to object is a flame.
    

And that's why systemd is causing such a ruckus in the Debian community: they
don't play well with others.

~~~
icebraining
What if I wanted to use Debian but with yum/rpm instead of apt/dpkg?

I don't care for systemd (I've never even used it), but it doesn't shock me
that some components are just core to the distro.

~~~
dsr_
That would be asking for a new feature, not asking for the preservation of
existing functionality.

Even so, the answer is that yum and apt have already been packaged for Debian,
so can install those, install alien, and then convert deb packages to rpm
packages, build a repo, and work from that. Ask around, maybe other people are
interested in doing that too.

~~~
icebraining
Installing rpm packages by converting them with alien to .debs seems akin to
systemd's sysv compatibility layer.

------
empressplay
I'll just leave this here...

[http://www.networkworld.com/article/2175826/softwareinus-
tor...](http://www.networkworld.com/article/2175826/softwareinus-torvalds-
suspends-key-linux-developer/software/linus-torvalds-suspends-key-linux-
developer.html)

~~~
uulbiy
You should note the date on that article (April 3rd). Kay Sievers rights have
been reinstated by Linus.

It's also important to note that the issue was with Sievers specifically and
not with systemd. As Linus said "[...] you don't fix problems in the code
_you_ write [...]".

~~~
reidrac
But as Kay is a systemd developer, IMHO it is interesting. Read Linus mail:
[http://lkml.iu.edu//hypermail/linux/kernel/1404.0/01331.html](http://lkml.iu.edu//hypermail/linux/kernel/1404.0/01331.html)

eg, "[...] But I'm not willing to merge something where the maintainer is
known to not care about bugs and regressions and then forces people in other
projects to fix their project."

I can't talk about systemd, but I had to deal with pulseaudio issues as
developer of a third party project and it wasn't a pleasant experience. Kay is
not involved with PA in any way, but I remember PA developers blaming Ubuntu
because of their PA integration.

Yes, it is probably me seeing things here as result of my own frustrations,
but I wouldn't like to experience a similar situation with systemd.

------
keithpeter
Of course systemd _works_ , and works _well_ , it is in RHEL7 and the clones
(the 'EL' world), it has to work! And be maintained for 10 years. That 10 year
support horizon rolls forwards each release.

At the philosophical level, does anyone not have _mild_ concerns about the
binding together of large parts of the underlying systems and the general loss
of modularity?

At the coal face do any sysadmins really value the new logging and monitoring
tools?

One metric might be the speed adoption of EL7 by those currently using EL6 and
EL5. A high speed of adoption means general happiness (or just need for newer
packages). A low speed of adoption means unhappiness (or just no pressing need
to upgrade).

~~~
Sanddancer
The logging and monitoring tools are /worse/ than in a BSD or SysV init
situation. Journald, as opposed to rsyslog and syslog-ng, can't talk to other
systems in anywhere near a sane manner, can't connect to databases, has no
ability to filter and direct messages, etc. On top of that, it makes core
dumps require root privileges to analyze them, making user level development
and debugging more difficult. Systemd has a heavy, heavy stink of someone from
the desktop realm coming in with no knowledge of what tools sysadmins already
use, and screwing everything up in the process.

~~~
kiyoto
>The logging and monitoring tools are /worse/ than in a BSD or SysV init
situation. Journald, as opposed to rsyslog and syslog-ng

I have to agree. I am one of the main people to support Fluentd (an open
source log collector [https://www.fluentd.org](https://www.fluentd.org)), and
a lot of people do forward rsyslog/syslog-ng to Fluentd for further
processing/analytics. We've been trying to figure out a way to do the same
with journald, and while it does seem possible, it will require a ton more
work.

------
thwarted
This closes with the line

    
    
        The only time I interact with systemd is when I'm running
        it on a server, something the majority of people don't do.
    

And there's the crux of the issue, from my perspective. I'm sure this year
will be The Year of the Linux Desktop™ (are we still saying that?) but the
fact is that there are way more Linux machines in a server role than in a
desktop role and the people who run those machines are doing so because they
are in the critical financial path of a company. This is a change that doesn't
directly cater to the people who are running servers (despite the message that
systemd has features that are valuable on servers). Relatively few people are
running Linux at home compared to the number of server installations. So while
more individual _people_ may be impacted by systemd, it's designed and
targeted for the desktop which has a lot fewer actual installs.

I've had to interact with systemd on my desktop system rarely (but enough that
it's frustrating for things that should be easy and obvious and just work) so
what's on the desktop doesn't impact me _that much_. But I run way more server
installations where things like boot-time and NetworkManager and multi-seat (I
question how many people actually need this on the desktop anyway) and name-
systemd-feature-of-week doesn't offer much advantage over the old system which
seemed to be working fine, was mature, and everyone was sufficiently familiar
with it (not to say it doesn't have warts, as everything does).

------
turnip1979
Systemd adds complexity and functionality. The question is, does the price of
complexity outweigh the gain in functionality. I got really annoyed at systemd
initially but that was because I knew a bit about upstart and init. My systemd
knowledge was zero - it is still pretty low. Now that I've seen it in action,
it doesn't seem as offending. In time, there will likely be docs on the
Internet. I do hope this isn't a harbinger of bad things in Linux. I think the
original commenter in the article alluded to the same philosophical point.

~~~
astine
One thing to think about is that my adding complexity in the beginning, you
can avoid complexity in long run. Imagine a Unix shell without pipes. That
would certainly be simpler in a sense, but the ability for programmers to
write simple programs that work together would be severely curtailed. Systemd
itself might be more complex than initv, but it provides a lot of tools and
guarantees to application developers which makes life simpler for them in the
long run.

------
timtadh
To add some balance, I found this article "The Biggest Myths"
([http://0pointer.de/blog/projects/the-biggest-
myths.html](http://0pointer.de/blog/projects/the-biggest-myths.html)) to be
really helpful in sorting out what is going on with systemd. I was a bit sad
that Upstart did not win on the Ubuntu side because I had already invested in
learning the technology and I quite like it versus SysV init scripts.

~~~
embolalia
> I quite like [Upstart] versus SysV init scripts.

Have you tried systemd service files yet? They're quite nice to work with. I
haven't written Upstart's equivalent, so I only know what those are like
second-hand, but I imagine if ease of creating a service is a major factor
you'll be pleasantly surprised by systemd.

~~~
timtadh
Not yet. I am waiting till I actually need to use it. Right now I administer
Ubuntu servers at work so I am still on upstart and at home I am on a
combination of (Free|Open)BSD and Ubuntu.

------
Havvy
I use VirtualBox on Windows with a shared folder, and when the virtualbox
package breaks for whatever reason, the OS decides that's a good enough reason
to fail startup and go into emergency debug mode.

I also notice it with the systemctl command line tool, which is actually
really pleasant to use.

I'm not sure what would happen if this happened with other init packages.

------
chaosesqueteam
It's over. Linus is fine with systemd:
[http://www.youtube.com/watch?v=2mIPPKReeGg](http://www.youtube.com/watch?v=2mIPPKReeGg)
1:11:00

A fork of linux is needed, both userspace and kernel.

~~~
techdragon
We have this thing you may be interested... its called BSD ... in fact we have
several of them, any one of which may be exactly to your tastes. If your not
sure, check out PCBSD.

I like using FreeBSD and Solaris, and all sorts of other OSes. SystemD makes
it harder to do. For every system service, now were maintaining a systemd and
a non systemd version of its init files.

