
Avoiding systemd isn't hard - jorgecastillo
http://www.vitavonni.de/blog/201410/2014102101-avoiding-systemd.html
======
Karunamon
Now? No, not really, just avoid GNOME.

In the future? Yeah, probably.

This wouldn't be an issue if the systemd people weren't notoriously hard to
get along with. Really, I think all of the reasons why systemd attracts hate
can be boiled down to this. Nobody wants a standard init system that's
_overtly hostile_ to bug reports and reasonable changes.

Say what you want about upstart and sysvinit, but I don't recall a point where
the maintainers of it were told off for hijacking kernel flags...

~~~
xfs
Core package bsdutils predepends on libsystemd0. Now it is impossible for any
Debian jessie systems to be without systemd code.

[https://packages.debian.org/sid/bsdutils](https://packages.debian.org/sid/bsdutils)

~~~
geofft
That's moving the goalposts in a significant way. Debian has always been of
the philosophy that binaries that have runtime-optional support for something
link libsomething and have a dependency on it, but there cannot generally be a
dependency from libsomething to the actual something package.

For instance, openssh-client depends on libgssapi-krb5-2 and libselinux1, but
neither of those packages have a dependency on the Kerberos 5 userspace
clients or on SELinux being configured or enabled, respectively. If you happen
to install Kerberos or enable SELinux, then openssh-client will work fine
without a recompile (because Debian doesn't have USE flags). If you don't, the
libraries will just do nothing. I think SELinux is a terrible and misguided
idea that subverts the UNIX philosophy, adds needless complexity, and also
doesn't work, but I have no objection to libselinux1 being installed.

Same thing with bsdutils and libsystemd0. The discussion has never been about
being "without systemd code" as if it were a noxious poison. (It's free
software, I would _hope_ people incorporate good code from it into other
packages.) It's about being without systemd, the init system, and if bsdutils
did depend on a particular init system, it would be flagrantly in violation of
the Technical Committee resolution.

~~~
xfs
This libsystemd points to a dangerous habit of the certain group of developers
who prefer strong interdependency and monolithic architecture. In similar way,
you have libdbus which is technically not the actual dbus, but tries anything
to launch dbus processes if loaded and initialized as a library. And gconf
libraries which ship daemon executables and also launch daemons from library.
Libsystemd is apparently not doing such right now, but given its windows.dll
like nature, it's a reasonable concern to have.

~~~
geofft
> In similar way, you have libdbus which is technically not the actual dbus,
> but tries anything to launch dbus processes if loaded and initialized as a
> library.

That can only happen if the dbus executables are installed; libdbus-1-3
Recommends but does not Depend on dbus. This is the standard way of things for
everything in Debian, and the dbus packaging is no different from the Kerberos
packaging here.

As I mentioned, it would be in violation of the tech-ctte ruling if depending
on libsystemd0 also brought in systemd itself as a hard dependency.

> it's a reasonable concern to have.

The entire worldview of systemd is that you shouldn't be spawning things from
your current environment (cf. daemonizing in /etc/init.d/foo), you should ask
some parent keeper process to spawn the executable. It sounds like it would
involve systemd doing the exact opposite of what it currently does if
libsystemd were to fork-and-exec much of anything.

For instance, systemd is obsoleting the setuid dbus-daemon-launch-helper,
which I am super excited about, having gotten on dbus-daemon-launch-helper's
bad side far too many times.

------
namarkiv
On gentoo, we have virtual/service-manager[0], that allows you to use
openrc/systemd/runit/daemontools.

[0] [http://sources.gentoo.org/cgi-
bin/viewvc.cgi/gentoo-x86/virt...](http://sources.gentoo.org/cgi-
bin/viewvc.cgi/gentoo-x86/virtual/service-manager/service-
manager-0.ebuild?revision=1.6&view=markup)

------
doe88
I think the author should refrain from using the word _trolls_ so much it
hampers his overall message.

So what happens with the pinning example with GNOME (I didn't know this useful
command)? Because of the dependance on systemd it is not upgraded then?

~~~
db48x
There have been some real hate-filled messages on the mailing lists. If they
had been directed at a women then they would have made HN all on their own.
The article links to one of them, if you want to check it out.

~~~
e7620
Here is the message:

 _There has been no General Resolution amongst debian package maintainers. Red
Hat has instituted a regulatory capture of the "bug squashing" committee
within debian (the "Technical Committee") by having current or former (but
stock holding) employees moonlight in debian and gradually gain membership in
that comittie.

Once their numbers were sufficient they proceeded to file a bug report on the
fact that systemd was not standard in debian.

This is illicit abuse of process and they need to be prosecuted.

Debian is an unincorporated association. It has bylaws, trade practices, and
dealings by which it was governed. The RedHat associated members of the
Technical Committee have illegally and in bad faith abused their positions in-
order to realize financial and strategic gain for their employer._

Do you really believe this is hate speech? Hate speech attacks a person or
group on the basis of attributes such as gender, ethnic origin, religion,
race, disability, or sexual orientation.

~~~
alephnil
It may not be hate speech, but it is not very constructive and have a smell of
conspiracy theory.

~~~
e7620
Mr. Snowden's revelations prove that "a smell of conspiracy theory" is not a
strong enough argument. Obviously Red Hat is interested in widespread systemd
adoption, and that message might offer an explanation as to why debian only
considered 3 alternatives and unprecedentedly rushed the adoption process. So
this angle is definitively constructive.

------
lotsofcows
Oh great, now people whose opinions differ are "trolls". I think we all know
who the troll is...

~~~
chimeracoder
He's not casting all opponents of systemd as trolls; he's saying that trolls
have spread a lot of misinformation about systemd, which is true.

Opponents of systemd _have_ spread a LOT of FUD and misinformation about
systemd. I know, because I was initially very skeptical of (or even opposed
to) systemd based on what they had said. Fortunately, I discovered that much
of it was misleading or inaccurate after my main distro switched to systemd.

Even if we give them the benefit of the doubt and say that it wasn't an
intentional attempt to spread misinformation, and that they were simply
speaking very vocally about a topic that they themselves had not taken the
time to read up on, it is not much of a stretch to call that behavior
"trolling".

~~~
e7620
> Opponents of systemd have spread a LOT of FUD and misinformation about
> systemd

Well, obviously there's another, more charitable interpretation.

> I discovered that much of it was misleading or inaccurate after my main
> distro switched to systemd.

Systemd is a continuously-varying project, and just because your distro
smoothly switched, doesn't mean there were no problems for early adopters. Or
that just because your configuration works, no difficulty with the multiple
systemd components have, do or will arise.

~~~
chimeracoder
> systemd is a continuously-varying project, and just because your distro
> smoothly switched, doesn't mean there were no problems for early adopters,
> or that just because your configuration works, no difficulty with the
> multiple systemd components have, do or will arise.

Actually, I never claimed that my distro switched smoothly. Ironically, I
literally commented just yesterday complaining that my distro (Arch) did _not_
switch smoothly (and IMHO switched too early)[0]. I had a lot of issues when I
first switched - I couldn't even boot my system, as a lot of stuff did not
migrate cleanly.

Switching is always going to cause upheaval and breakage to at least some
extent, and that's not what OP and I are referring to when talking about FUD.

What I'm talking about are people making factually incorrect (and worse,
_trivially verifiably incorrect_ ) statements about systemd and what it does.
Some of them are just blatantly wrong ("systemd forces you to use binary log
files"[1], "systemd means you can't use init scripts"[2]), "systemd means you
can't use crontab"[3], or my favorite "systemd gives QR code output"[4]).
Others are technically true, but highly misleading ("I don't want everything
to run in PID 1"[5], "systemd is the only way to run cgroups"[6])

There's a difference between disliking systemd on technical merit and
disliking it based on false information that one hasn't even bothered to
verify, and then vocally spreading that misinformation.

[0]
[https://news.ycombinator.com/item?id=8482950](https://news.ycombinator.com/item?id=8482950)

[1] systemd by default does not use _any_ log files (IIRC), and provides text
logs as an alternative to the recommended binary default. You can keep using
syslog just as always.

[2] systemd allows for init script compatibility. I won't claim that all init
scripts will work without any modification, but it's not like you can't keep
using init scripts instead of systemd configs if you don't want to

[3] systemd.timer is something you can use instead of crontab, but it will
also run regular CRON jobs as well.

[4] systemd _does_ have an option to display kernel dumps as QR codes. This
feature is generally not compiled or available by default

[5] systemd includes some functionality that runs in PID 1, but most of what
people actually are talking about does _not_ run in PID 1

[6] systemd is the only way to run cgroups, because the _Linux kernel_
requires that a single arbiter handle all cgroups, and systemd is (was?) the
only program that has actually implemented the entire necessary ABI to do so.
Anyone is free to write another program to handle cgroups instead of systemd.

~~~
e7620
Okay, I was saying, just because some people doesn't know, it doesn't have to
be FUD, that'd be just an ad hominen attack. I've been a user of Arch back
before systemd and I know your points are mostly right, but as you admit, in
some cases you're true only technically, so don't attribute all errors to
malice.

I think most people don't care how much of systemd is pid 1, there are
components like udev that systemd is assimilating, we just want choice, I
happen to like modern daemontools-like init systems a lot, but I use various
init systems depending on what I want, and that's great IMO. However, read
this:

 _Unless the systemd-haters prepare another kdbus userspace until then this
will effectively also mean that we will not support non-systemd systems with
udev anymore starting at that point. Gentoo folks, this is your wakeup call._

The factually incorrect statements stem from such messages from lead
developers, they've stated that in the future systemd will be sort of "merged"
with linux, and that's no good. We know because we've been using great OSs and
this is clearly a regression.

------
taeric
I thought the big concern is that it isn't hard _yet_.

~~~
Alupis
it will only get "hard" if software projects bake in hard-dependencies to
systemd, like the gnome project has (because they thought/think it provides a
lot of benefits, and imho it does). Even so, there are plenty of shims being
built that provide the small amount of api compatibility necessary to make
things like gnome work on non-systemd systems (FreeBSD for example).

~~~
taeric
So, it is going to get hard, is what you are saying?

I mean, it could be that the shims are nice and easy, but it seems to be the
expectation that this will not be the case, right? Especially since systemd
seems to be on a very aggressive expansion of responsibilities campaign.

~~~
Alupis
systemd is 69 individual components (and binaries) last time I checked. You
can opt to build some, or all when you compile it. Yes they work together, but
they have an open and now-more-or-less standardized api. So nothing prevents
another developer from writing against the api, be it a shim to reduce/remove
systemd but provide compatible calls into another system (init, logging, etc),
or a complete replacement for a specific component of systemd.

I see it only getting easier actually. Folks in the BSD projects for example
have their own init system but still want software like gnome, so shims are
used to provide the api abstraction. This can be applied elsewhere in the
Linux world as well. Again, this is only for software where the developers
have explicitly decided to hard-code in dependencies to systemd, which is not
likely going to be everyone.

~~~
deong
> Again, this is only for software where the developers have explicitly
> decided to hard-code in dependencies to systemd, which is not likely going
> to be everyone.

I'd put good money on this getting harder and harder going forward though. At
some point it will be everyone, or at least practically everyone, because
every Linux distribution with any mindshare will have been using systemd for
years, and hard-coding systemd will be not a lot different than hard-coding
calls to the C standard library.

Also, shims? How god-awfully inelegant can we be? "You don't like systemd?
Cool. You can run something else (as long as it looks, feels, and behaves
exactly like systemd)."

Look, I'm not a religious zealot. Systemd is what they want me to run; systemd
is what I'm running. I can live with ugly software. It's not the end of the
world. But oh dear god is it ugly.

~~~
Alupis
In what way is it "ugly"?

~~~
deong
I'd give the same answers as you've probably heard a dozen times before.
Binary logs, D-bus fundamentally baked in, the whole "shims are a perfectly
good solution" viewpoint, basically the usual things people like me don't
like.

------
byuu
Thanks for the guide. Serious question, say I were to do a clean install of
Jessie. I would use Xfce with either LightDM or no DM, or I might choose to
set up a VPS that obviously won't even need Xorg. Is there a way during
installation that I can skip installing systemd at all in that case, perhaps
through a minimal install and then following up with adding the software I
want? I don't like the idea of trying to purge systemd and its dependencies
after a fresh install.

~~~
gh02t
I am not sure about Jessie, but whenever Debian switches to Systemd as the
default, I would guess even the minimal install would have it. Systemd is the
init process, so you can't really just do without it (or some other init
system at least). I think it will probably require somebody remixing the
installer image to use a different init system.

Not sure though, I'm not super informed about what Debian is planning for the
switch.

I _think_ (no experience, but it makes sense) that Gentoo lets you pick the
init system easily at install, you might want to look at that.

You might want to try it though. In my experience, the minimal config for
systemd is quite lightweight and clean. I don't use KDE or Gnome, but I quite
like systemd on my Arch workstation. Arch (and Fedora) have had it for quite a
while now, even back when it was probably a bad idea to switch...

~~~
icebraining
The netinstall (not sure about the others) lets you choose exactly what
packages you want during the installation, including init system, as far as I
know.

------
toni
apt-pinning (something that I have always thought is a bad practice) and using
a shim. Honest question: isn't this just a giant hairy hack? Am I missing
something?

~~~
forgottenpass
Pinning? That's only a hack if you don't care to learn how apt works. And not
actually necessary to avoid systemd unless you're running with `--assume-yes`
or hammering 'y'.

systemd-shim? Well, yeah, but that's the entire point of it's existence.

------
rogertux
They have fear of systemd becoming the mainstream init system. It's more easy
for a project to become obsolete if we start to forget about it. Although
sysvinit still has an chance to evolve.

~~~
Alupis
not to mention all of the _good_ things systemd actually provides.

I'm particularly excited about socket activation for my servers, as well as
auto-remounting of network shares if connectivity is lost (my laptop on/off
wifi or traveling, etc).

I really don't get the systemd "hate" that is still floating around. It seems
a lot of arguments against end up boiling down to "it's different and
therefore I don't want it". systemd is a collection of smaller tools, which
_is_ the UNIX philosophy (debunking that argument). It can be replaced as per
this article and if software projects don't explicitly bake in hard-
dependencies (but even then there are ways around it like shims and what-not
that several people have built).

Distros are looking around at all the available init systems, and a large
amount are deciding systemd offers something more than the rest, and then
going with it. (you can review the debian debate for gritty and technical
details). There really is no reason to be so angry at systemd.

~~~
deong
As another article I read just today pointed out (in a completely different
context), the point of Unix isn't the number or size of the tools. It's the
composability of the tools.

systemd might be a collection of many small tools, but they don't compose
well. Dbus isn't a substitute for piping little blobs of text between stdin
and stdout of a bunch of different programs that are utterly agnostic of each
other's existence.

And systemd might well be great. Aesthetically, I don't care much for it, but
I'm using it with no problems, so I guess it's fine. But it's not "the Unix
philosophy".

~~~
chr15p
Serious question: in what ways would you want systemd commands to be
composable? I'm struggling to think of a use case for being able to pipe a
service name into systemctl (or "service" for that matter) and its output is
reasonably grepable for running|failed etc (and more consistant the old SysV
scripts)

I'm guessing you want more then that though right?

~~~
VLM
Conceptually composable. The logging in systemd sucks, sorry but true. Binary
logs? LOL. Someday if rsyslog could speak raw systemd language as an input,
that wouldn't be quite as awful. Then you could have systemd talking to a real
logging platform. Just like "ls" can talk to "grep". Doesn't mean the talking
can only be in the format of a pipe or whatever.

~~~
adestefan
/etc/systemd/journald.conf

ForwardToSyslog=True

or

systemd.journald.forward_to_syslog=True on the kernel command line.

Is it just cool to not read documentation anymore?

~~~
e7620
To say that this is not fair would be an understatement. systemd-journald is
only one component, there are more than 50!

------
alex_duf
On a purely technical perspective (I don't care about people not getting
along), what is reproached to systemd ?

------
anonbanker
another pro-systemd post. there's been two of them today, the other being the
uselessd blog post. What's with this community rushing to defend themselves?
doesn't this smell like astroturfing to anyone else?

