
Boycott systemd - martinp
http://boycottsystemd.org/
======
moreentropy
I can't access that site because it returns 500 right now, but: Can we please
get over it?

Quoting the "Unix philosophy" as the reason to keep things like they were 20
years ago is laughable. I want to get things done, and managing processes
using init scripts and daemonization is pain. _Edit: I 'v read the cached
version now, and this assumption turned out wrong. The authors see a need to
replace sysvinit._

The amount of bad and inconsistent init scripts, messy PID file handling,
makeshift service wrappers, defective daemonization and logging workarounds is
so much worse than having one place that will handle those ever repeated
tasks.

I love that in recent years Linux (as in distributions) got an attitude and
actively push things forward, without losing compatiblity to older software.
Apple introduced launchd and nobody complained. We start to rely docker and
all sorts of new approaches to manage our services and nobody complains. But
init is somehow regarded as the holy cow noone is supposed to touch although
everybody agrees it sucks.

Even if it's technically wrong: Unix as a platform is now Linux. Everything
else is niche products, and we don't have to use the same init mechanism on
Linux/BSD/whatever just because we can.

I have deployed the same software on Debian Linux, RHEL Linux and AIX and
basically had to reimplement service management scripts for every platform to
have the best possible result. How could this get even worse?

~~~
rjzzleep
I don't see a boycott happening. Not unless someone steps in to write an
alternative init system, which solves some of the issues openrc and systemd
solve, but without systemd's baggage.

taking the discussion out of the opinion level to a more factual level(eg. i
like the boot speed of my archlinux machine but the whole consolekit(why did
we get that to begin with ?)/logind/ridiculousness, logging and service files
vs. startx and grep /var/log is annoying to say the least, but as i said
subjective)

on a factual level we have ridiculous bugs specifically caused by systemd that
take down your system, and the lead developers saying either i don't care or
it's by design. let me bring a few examples:

[https://bugs.freedesktop.org/show_bug.cgi?id=76935](https://bugs.freedesktop.org/show_bug.cgi?id=76935)

> That is the expected current behaviour, "debug" can cause "too many"
> messages to be useful anymore if things are broken.

or this one, systemd segfaulting with cgroups off:

[https://bugs.freedesktop.org/show_bug.cgi?id=74589](https://bugs.freedesktop.org/show_bug.cgi?id=74589)

Lennart:

> To make this work we'd need a patch, as nobody of us tests this.

There were a few other recent ones. When your new init system consistently
takes down your operating syste, because of stupid bugs, and the lead
developers say we don't care, and even block efforts to fix these issues, you
should indeed worry.

[https://plus.google.com/111049168280159033135/posts/Kd57G8s1...](https://plus.google.com/111049168280159033135/posts/Kd57G8s1cTD)

In fact Greg KH jumped in to play daddy, and wrote a patch where tom gunderson
commented that that patch would not be merged as it's not clear what problem
it solves.

edit: some say openrc is the one. here's a comparison:

[https://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems](https://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems)

~~~
midas007
runit (from daemontools) might not start things up in parallel, but it's a
whole lot simpler and reliable. Phusion uses it instead of upstart in their
base docker VM.

Also a lot of enterprise shops use daemontools and runit, because they just
fucking scale.

~~~
FooBarWidget
I'm from Phusion.

Runit is great as a tool to manage your own daemons. But as a general init
system for distributions? Not so much. Just take a look at the /sbin/my_init
system that we wrote for baseimage-docker and what kind of functionality it
adds on top of Runit, to give you an idea of why Runit by itself is not
enough. Runit also performs no dependency management (i.e. starting one
service before another) so it's quite painful in certain situations. For
example, if you have a background queue daemon that depends on PostgreSQL,
then you have to manually make sure that the daemon is not started until
PostgreSQL is available. Otherwise you get tons of useless error messages as
your daemon keeps getting restarted.

~~~
midas007
No problem, just wrote a tool for that:

    
    
        waitport [-u] port [timeout (float)] # -u = UDP instead of TCP
    
    
        go get   github.com/steakknife/my_init/waitport
        go build github.com/steakknife/my_init/waitport
        # creates waitport bin here

~~~
midas007
Renamed to
[https://github.com/steakknife/devops_toolchain](https://github.com/steakknife/devops_toolchain)
to avoid confusion.

A collection of individual tools that can be cherry-picked to solve nitty-
gritty problems.

------
andrelaszlo
Tom Gundersen discussed the move to systemd on the Arch Linux forums a couple
of years ago.

[https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530](https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530)

Summary:

    
    
        0) it is hotplug capable
        1) we can know the state of the system
        2) it is modular
        3) it allows dbus/udev to go back to doing the task they are meant to do
        4) we can reduce the number of explicit ordering dependencies between daemons
        5) we get a lot of security/sandboxing features for free
        6) systemd service files can be written and distributed upstream
        7) systemd is a cross-distro project
        8) logind will finally deliver on what consolekit was supposed to do
        9) systemd is fast

~~~
lawl

      0) That's not the init systems job.
      1) That's not the init systems job. Use something like http://cr.yp.to/daemontools.html
      2) Less modular than any init system out there. Having *everything* (including a dhcp deamon soon) in PID 1 is not modular just because you can configure it.
      3) See 1.
      4) Never bothered me, but fair enough.
      5) That's not the init systems job.
      6) Not if the path's differ. E.g. are debianized.
      7) So was sysvinit.
      8) That's not the init systems job.
      9) It actually is.
    

Edit: And if you downvote me, at least add an explanation please. Thanks. I'd
like to know if I'm factually wrong or you just disagree.

~~~
skrause
You failed to mention _why_ it's not the init system's job. An init system
which is aware of what's going on can have a lot of advantages.

In the end djb's daemontools are nothing more than an init system on top of an
init system. So why not include it in the main init system?

~~~
pmahoney
> daemontools are nothing more than an init system on top of an init system

What do you mean by that? That it isn't PID 1? Apparently it can be made to
run as PID 1. But you can keep the (in my opinion) brilliant design of
daemontools and use successors such as s6 are designed to run either as PID 1
or as a plain old daemon (which is nice if you've not got full control of a
machine).

[http://www.skarnet.org/software/s6/index.html](http://www.skarnet.org/software/s6/index.html)

I've been using s6 to manage a few things, and some features I like are:

\- allow a group to manage (stop/restart) certain processes using Unix file
permissions

\- arrange things in a tree. My toplevel s6-svscan starts a second s6-svscan
which starts a handful of related processes. These all inherit the same user
and environment vars which makes config easy.

~~~
aktau
Have you tried runit? If so, could you tell me how it differs from s6? I like
runit, but if it's better, it's better.

~~~
pmahoney
I have not tried runit. s6 is actively maintained; I don't know about runit
(on the other hand, runit is in Debian while you must compile s6 yourself).
The author of s6 has a (very biased of course) comparison or various
supervisors:

[http://skarnet.org/software/s6/why.html](http://skarnet.org/software/s6/why.html)

The big feature s6 has that runit lacks seems to be the ability to wait
without polling on some event (process started). I haven't used this much
myself, but even given that some process has started, it doesn't necessarily
mean that it's initialized and ready to do what you expect.

------
wooptoo
> an abhorrent and violent slap in the face to the Unix philosophy

I'm tired of all this UNIX philosophy crap. I have been using Systemd for more
than a year now, on Archlinux, and it has been a delightful experience.

It works out of the box and it gets a lot of things right. Journald is quick &
easy to use and a real help in finding problems. No more searching around in
log files and grepping. Dependencies between services are handled by the init.
Services start with maximum parallelism. Writing .service files is really
easy.

It simply has better UX than any other init system, and it's supported by a
lot of distros. This means standardization and progress. No more developer
time wasted on sysvinit scripts.

The posted link is the same FUD that I have been reading for the last year on
various forums. Even if systemd can be a single point of failure, it's still
way more stable than anything we have used before.

~~~
voidz
I'm tired of people who are tired of hearing about UNIX philosophies and call
it crap.

------
nemasu
Okay, well, while I agree with most of the points they make, there just isn't
a viable alternative. I maintain noop Linux (nooplinux.org), it started using
OpenRC, but when udev was merged into systemd, things got very complicated,
eventually the switch was made. Systemd is very fast, the 'init.d' scripts are
way better, udev work very well...I don't mind thinking about moving back away
from systemd (because I really do have a love-hate relationship with it), but
what am I supposed to go back to? OpenRC/SysV-whatever? Heck no. Upstart?
Nope. ...is there even an alternative that makes sense? Because moving back to
SysV would be a step back.

~~~
stefantalpalaru
>it started using OpenRC, but when udev was merged into systemd, things got
very complicated

I got past that by using eudev with OpenRC on Gentoo.

~~~
jbergstroem
For uncomplicated systems (such as virtual machines, servers and whatnot)
there's mdev in busybox.

------
SEMW
"Unix philosophy" seems to be one of those phrases that everyone likes
agreeing with because you can use it to either justify or condemn anything you
like.

E.g. you could perfectly plausibly make the argument that systemd's return to
inetd-style service starting (on-demand and in-parallel through socket
activation) is a lot more unix-philosophy-like than the SysVinit way.

~~~
cturner
Agree, but SysV-init isn't notably unixy. In general, SysV distros raced to
embrace and extend away from the mainstream. That created lots of un-unixy
subsystems that live on in linux. Quick wave in the direction of three - NFS,
wacky IPC systems, SysVinit.

SysVinit is complicated - it wants to be a DSL but is still a shell hack-
together. It's inflexible - it's a dependency tracking system, but you can't
easily adapt it for userspace launch control, or as a build tool. It doesn't
do one thing well. (e.g. doesn't reliably contain a process tree, there are
still situations where you want to use pid files or complicated ps greps).

Init is a hard problem. From what I can see all the unix derivatives have made
a mess of it. I've had fleeting attempts at writing my own, and I definitely
made mess.

In the absence of the good, I reckon the simple becomes the standard. In
modern BSDs there's a script called init, it gets called at startup and does
nothing for you. I reckon we should judge challengers to init against that.

------
theanirudh
The author of systemd, Lennart Poettering busts some systemd myths in his blog
post [http://0pointer.de/blog/projects/the-biggest-
myths.html](http://0pointer.de/blog/projects/the-biggest-myths.html)

~~~
espadrine
There's one thing that the boycott post gets right, that Mr Poettering doesn't
address, which is:

 _> 2\. systemd's journal files (handled by journald) are stored in a
complicated binary format._

Mr Poettering tackles the myth that _configuration files_ are binary (they are
very obviously not).

That said, I am not sure how to get the journaling data in an Upstart system,
nor in a sysvinit one.

------
vidarh
They'd get _much_ further if they actually came up with a better alternative.

Even _if_ all of there points were objectively true, it doesn't matter when
sticking with the old init is so much worse in many ways.

People aren't picking systemd because it's perfect, but because both the mess
of init scripts it is replacing, and alternatives like upstart,is seen as
worse/too lacking.

EDIT: Btw. this just got me to install systemd on one of our dev/test Debian
boxes at work, to start testing it.

------
blueskin_
I'd rather see init's problems fixed (i.e. start services in parallel), but
systemd is far better than upstart (edit: got it to load at last, I see it's
not by upstart fans, so ignore that last part).

That said, a lot of systemd seems like a really stupid idea to me, e.g. binary
logs, the massively increased SPOF size, and the "do everything" mentality.
Unfortunately, I don't know of any distros that aren't using it now (edit: I
didn't even realise Slackware was still a thing...), and upstart is even more
of a joke than systemd.

~~~
quasque
What's wrong with binary logs? Seems like an improvement, given how they can
be cryptographically 'sealed' to help tamper detection, and have indexes built
in [1].

[1] [http://www.freedesktop.org/wiki/Software/systemd/journal-
fil...](http://www.freedesktop.org/wiki/Software/systemd/journal-files/)

~~~
mrweasel
Binary logs are pretty annoying because your standard tools for searching
through them no longer works.

tail, less, grep, wc and similar tools are rendered useless. Newer tools like
logstash or Splunk are also going to have issues reading your binary logs.
It's not really a wise thing to break the tools that most people use every
day, it's just going to make them hate you.

~~~
vidarh
Which only means that you need to pipe the output of journalctl to your
standard tools. It hardly renders any of you tools useless.

~~~
blueskin_
Not all tools operate on stdin. For that matter, this doesn't fix the millions
of people and organisations who will have custom tools and processes.

All the binary logs are going to do is make people have a cronjob to extract
them regularly into a readable format.

~~~
vidarh
> Not all tools operate on stdin.

So pipe it to a file and operate on that. Or give the broken tool /dev/stdin
as its filename. Or give it a fifo as a filename and "journalctl |
/path/to/fifo.

> All the binary logs are going to do is make people have a cronjob to extract
> them regularly into a readable format.

For those who insist on that, yes. Most of them will presumably have logrotate
set up anyway, so it's hardly more complexity. Or you can run a syslog, and
trivially set up systemd to forward the log entries to that.

Meanwhile the rest of us will enjoy the ability to do things like specify a
start and end time with command line switches when trying to find stuff in the
log, filter by priority, filter by user, filter by pid. seeing only data since
last boot, get the journal as JSON instead of having to rely on brittle text
parsing of entries that contains less information.

Regarding the last point, here's an example of an entry from journalctl -o
json-pretty:

    
    
      {
            "__CURSOR" : "s=56750fa36ad94eb99c00e7fd6854c400;i=2;b=2f533403d7a041e7a389e3a7090942de;m=172e6e4;t=4f7c809a2f61d;x=79a98b8a5116658a",
    	"_SYSTEMD_CGROUP" : "/system/cron.service",
    	"_SYSTEMD_UNIT" : "cron.service",
    	"SYSLOG_FACILITY" : "10",
    	"SYSLOG_IDENTIFIER" : "CRON",
    	"_CMDLINE" : "/USR/SBIN/CRON",
    	"MESSAGE" : "pam_unix(cron:session): session closed for user root",
    	"SYSLOG_PID" : "2398",
    	"_PID" : "2398",
    	"_SOURCE_REALTIME_TIMESTAMP" : "1398345421294046"
      }

~~~
mblakele
Pipe that into [http://stedolan.github.io/jq/](http://stedolan.github.io/jq/)
and you could do things.

------
mateuszf
Em .. no, thank you. I think that systemd is a good step in the direction of
unifying different distributions. Also, many argument presented on that page
have been debunked or are actually good things.

~~~
tmikaeld
I agree, i find it very hard to believe that so many distos would make the
wrong choice here.

~~~
Fuxy
It's the best option at the moment arguably not perfect but better then
anything else out there.

I wish the owner of that website would would make a better alternative instead
of complaining.

~~~
kourt
I think the concern is that systemd is following a rapid "embrace, extend,
extinguish" path, and very quickly will have achieved critical mass and become
somewhat unstoppable.

There's nothing wrong with saying "I like Linux, but it's becoming Lennartix
and I'm concerned."

------
fidotron
Lennart is rapidly becoming the new Drepper.

As long as characters like this persist Linux as a direct end user system is
going nowhere, and it will remain a lower level component abstracted away by
higher level platforms, as in Android or Chrome OS.

------
_pmf_
At
[https://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems](https://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems)
all of the features that are unique to systemd are immediately something that
I'd rather not have integrated.

------
Gonzih
For me it always feels like people who are bashing on systemd never actually
used it. I was very concerned about systemd for long time. And nowadays I use
it on all my machines/servers. And it just makes my life so much easier. I'm
happy. I like it. I can agree with lot of points on this website. But still
systemd makes my happy. So sorry, but no.

~~~
midas007
For 99% of uses, esp desktop, laptop, embedded... it's great.

For that tiny percent of use cases where services can do all kinds of crazy
things and there needs to be extra control, other things like supervisor,
foreman_god, daemontools/runit come into play. There are use-cases not many
people have to deal with or even exposed to, yet are important considering the
impact (say downing a major service like Gmail).

------
ealexhudson
'systemd flies in the face of the Unix philosophy: "do one thing and do it
well," representing a complex collection of dozens of binaries'

So, a collection of lots of single-purpose binaries that work together flies
in the face of "do one thing and do it well". I kinda stopped reading at this
point, which was sadly quite high up the page.

~~~
TTPrograms
I think the point is you can't replace each of those binaries with
alternatives. The monolithic nature of systemd is not just a function of the
raw number of binaries involved.

~~~
zokier
> I think the point is you can't replace each of those binaries with
> alternatives

Is there any reason why you couldn't do so?

Found this chart:
[http://www.freedesktop.org/wiki/Software/systemd/InterfacePo...](http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/)
Note the columns "Reimplementable Independently" and "Known Other
Implementations"

~~~
cthalupa
Something being (theoretically) possible doesn't mean it's practical.

The attitude of the systemd (And Freedesktop.org folks in general - and please
don't give us the usual Lennart cry of "No really, we're NOT the
freedesktop.org people!" \- despite all of these projects sharing a tightly
knit community of people steering them) devs and their treatment of their
projects has meant for some you basically do things their way or the
highway.[1]

It's already a pain in the ass to strip udev out to keep using it if you've
decided to not use systemd. And that's just taking one portion of the system
that was promised to be kept easily independent of the rest of the muck, not
trying to make other services work within the framework of a systemd system.

As it becomes the standard across all of the major distros, I find it hard to
believe that it will become easier to separate systemd parts from one another
than it is now, because there becomes even less incentive to do so.

I don't have much of a horse in this race, because I've long since migrated
the vast majority of my production systems to FreeBSD and OmniOS, and out of
the few that I have that are running linux still, some of them are using
systemd. I don't particularly like it, but instead of complaining about it and
doing nothing, I've minimized the impact I feel from it.

[1]
[https://news.ycombinator.com/item?id=7534583](https://news.ycombinator.com/item?id=7534583)

------
binaryapparatus
I see this as related and it is less than a month old:
[http://www.muktware.com/2014/04/linus-torvalds-happy-
systemd...](http://www.muktware.com/2014/04/linus-torvalds-happy-systemd-
author-kay-sievers/25151)
[https://plus.google.com/u/0/+TheodoreTso/posts/K7ijdmxJ8PF](https://plus.google.com/u/0/+TheodoreTso/posts/K7ijdmxJ8PF)

I am not much of a systemd fan so I may be biased but it is interesting read
anyway.

------
Spittie
Okay, I like to think as myself as an open minded individual. I'm not a
systemd fanboy either, I just research and use what I believe it's better for
myself. There is a reason why I can't consider the anti-systemd guys
seriously: It all seems FUD to me. Take for example point 8, "you have to
reboot to update systemd. Okay, not really, but the update might go wrong!".
Really?

Going point by point:

1\. As the site says, systemd is both an init system and a collection of
programs that make sense to have in a system. One can already strip most of
everything from it (I think only journald is mandatory), and there is usually
a stable api between every component, so one can simply replace them.

In fact, I believe that half of the complains about systemd would disappear if
it all the tools were developed in a different repository and not under a
"systemd umbrella" (Isn't one of the major point pro-BSD the fact that the
base system is all developed together?)

2\. If you want to use systemd but have plain-text logs, journald can pass
everything to syslog and similar daemons. What everyone forget is the bonus
that journald provides: no more "cat /var/log/*.log | grep <program> | sort
-u" and hope that applications log in the same format, I have everything in a
single place and can browse them by unit, by user, by time, by urgency...

3\. I can agree with that. But it's not that sysinitv or upstart worked on
non-linux systems (without ugly hacks)

4\. And? I'm not sure what's the problem here. udev and dbus are mandatory by
pretty much anything that's not a .sh script nowadays.

5\. Okay, fair point. "It assumes that users and admins are dumb" can you
really blame them?

6\. Fair point again, systemd is bigger than sysinitv. But that's almost
saying that we should all use microhttpd instead of nginx/apache because it's
smaller.

Also the simple fact that it's included in RHEL 7 mean that it got audicted by
RH, which make me feel safe.

7\. That's just FUD. Here's Gnome 3.10 running on OpenBSD:
[http://undeadly.org/cgi?action=article&sid=20140219085851](http://undeadly.org/cgi?action=article&sid=20140219085851)

Gnome will depend on systemd when under wayland, that's instead a fact.
Actually, on logind, which has an api that anyone can reimplemnt
([https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-
logind...](https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-
logindsystemd-thoughts/))

8\. Not true, again. Right now, on my system:

    
    
       pgrep -l systemd
          1 systemd
          354 systemd-journal
          386 systemd-udevd
          766 systemd-logind
          1190 systemd
          1754 systemd
    

Also, I still fail to see why "it's big, it will fail" is a thing. What
matters is code quality, not size.

9\. Fair point.

10\. This might or not be possible, I don't have much experience in writing
unit files so I don't really know the limits.

11\. Nobody is forcing anyone to adopt systemd. It's getting adopted because
distributions and developers think it's better.

And after months/years of complains about systemd, I still haven't seen anyone
trying to produce anything that has the same advantages for sysadmins and
programmers.

Really, that's how it feels: "I'm going to complain and complain and complain,
but I won't lift a finger to change the course of events".

Can anyone make a point in favor of sysinitv (or against systemd) without
bringing in abstract concept as "Unix philosophy" and plain wrong facts?

~~~
meapix
6\. is a big deal for me. 9 CVE since 2011? that's crazy in combination of
"single point of failure".

~~~
exelius
Yeah, but keep in mind that:

1\. It now has a lot more attention focused on it, so it will get more
scrutiny.

2\. Unix admins have always been wary of the bleeding edge; distros are
adopting systemd today, but those distros themselves are unlikely to see wide
production adoption for a year or two.

3\. If the systemd team's processes are not up to snuff, a major distro will
fork it and run it themselves. If the criticisms have any merit, others will
follow. It's why open source is such a great model for critical system
software: it's as pure of a meritocratic model as you can get (well, if you
accept the fact that merit is based on adoption.)

Basically, any new critical unix process is going to have these types of
issues. The fact that systemd has a lot of support basically ensures it will
get a lot of attention and bugs/security holes will be fixed.

~~~
mwcampbell
Still, the simpler something is, the less scrutiny it needs in the first
place. Mind you, I think even sysvinit is too complex for PID 1. PID 1 should
do the bare minimum trhat the kernel expects of it (taking care of orphaned
processes, handling shutdown requests) and leave the rest to other programs.

~~~
exelius
On some level I agree with you, but if you look at the things that Apple is
able to do with OS X and timer coalescing [1], that central point of
coordination becomes critical. You need a mechanism for starting and stopping
all things, not just daemons, that plays by a specific, defined set of rules
so you don't have multiple processes trying to do the same thing.

On another level, I feel the "unix philosophy" of having a lot of
interchangeable modules taking care of small, simple tasks hurt it: each level
of abstraction has a performance hit, and having to support multiple
components in a modular way makes change management a nightmare. There's
something to be said for the elegance of tightly integrated components: you
can make assumptions that you couldn't otherwise make in a more modular
system. I can see how it would be a problem if systemd were proprietary, but
it's open source.

[1] [http://www.apple.com/osx/advanced-
technologies/](http://www.apple.com/osx/advanced-technologies/)

~~~
felixgallo
You are right that loose coupling carries a performance hit. Certainly, if
your only goal is to increase the boot speed of a desktop Linux box, then
systemd makes a lot of sense. That said, there are many other goals and many
other kinds of boxes, which, among other reasons, is why the tide is turning
against systemd.

~~~
exelius
"Performance" can many different things, all of which are useful in different
contexts. It could be lower power consumption, faster thread performance, more
I/O, lots of things.

~~~
felixgallo
agree. So far, the only 'performance' case that I've seen made for systemd is
in desktop system bootup time. Certainly it won't make my threads go faster or
cause significantly lower power consumption, or give me 'more I/O'.

------
mrmondo
For Linux to keep evolving, part of evolution is mutation, the strong will
flourish while the weak will die.

Regardless of what init system is right or wrong, the beauty of the Linux
ecosystem is we can afford for different distributions each to make different
decisions.

Systemd seems functionally better than both sysvinit and upstart and it
certainly doesn't seem to be the root of all evil like this article makes out.

I don't believe that everyone boycotting systemd over what's currently out
there will aid linux in any way.

~~~
chronid
When everything will use systemd (because all the "core system" is starting to
depend on it, wayland included) how do you evolve out of it? Rewrite the
entire lower level of your system AGAIN? That does not help evolving rapidly,
in my opinion.

~~~
therealunreal
That's funny. So what you're saying is that we shouldn't rewrite the lower
level because it'll be harder to rewrite it later on.

~~~
chronid
No, and I'm sorry I was not able to explain that properly. :)

We should not (re)write a lower level where all the components are so coupled
we will be unable to change one of them with a better alternative without
changing the rest.

------
mrweasel
We just install daemontools on all of our servers for our own stuff and let
the system packages use whatevers the default in the distro, they seem to live
happily together.

I suspect that one issue with systemd is that it aims to solve very real
problem, but they are problems that not many noticed. Most of the stuff that's
highlighted as benefits of systemd are things I never experienced, either I
don't thing advanced enough or the issue has already been addressed by the
distro.

Most of us are just going have some daemon/process that we want to start at
boot and for that purpose systemd is going to look like massive overkill and
overly complicated. That might be mostly a documentation issue, systemd could
benefit for a "So you want to start at process" guide.

------
klaasvakie
Does anyone know if this quote is true?:

"Since systemd is very tightly welded with the Linux kernel API, this also
makes different systemd versions incompatible with different kernel versions."

I was pretty meh about the whole systemd thing, but having to change userspace
when swopping out kernels is a spectacular disadvantage. Imagine having to
downgrade your distro whenever you need to test against older kernels ---
madness.

This is especially bad with ARM/embedded stuff where one often runs a modern
userspace with an older kernel.

~~~
cnvogel
In my experiece, upgrading the kernel to a newer one is not a problem. What
can happen, though, is that an upgrade of userspace will suddenly require a
kernel-feature not present, if you run an ancient board-support-package with a
3.0-kernel or so in 2014! (happened to me with a BSP for a Freescale i.MX6).

So, if you have archlinux tracking the latest and greatest systemd, uptrading
userland can make your machine no longer bring up everything (completely). But
in my case the kernel is from 2011...

~~~
klaasvakie
I have an i.MX5 BSP with a 2.6.xx era kernel :(

Can you give an example of the "no longer bring up everything (completely)"?

~~~
cnvogel
After putting a current arch-linux rootfs[1] on the box[2], it seems to come
up, just network and console seems to be misconfigured, but this, I think, I
had to fix the last time also. So: indeed the current systemd seems to work on
a iMX6 running a 3.0 kernel.

[1] ArchLinuxARM-imx6-latest.tar.gz from
[http://archlinuxarm.org/developers/downloads](http://archlinuxarm.org/developers/downloads)

[2] Phytec PhyFlex i.MX6 [http://www.phytec.de/de/produkte/system-on-
modules/produktde...](http://www.phytec.de/de/produkte/system-on-
modules/produktdetails/p/phyflex-imx-6-3.html)

~~~
cnvogel
### addendum ###

Recent systemd doesn't seem to realize that ethernet and the serial console
device are actually there, it's waiting for dev-ttymxc3.device and sys-
subsystem-net-devices-eth0.device ... but both are statically compiled in. So
there is some issue with kernel 3.0.x.

~~~
cnvogel
I was missing one config option from the README, now it works!

------
foxylad
Given that both systemd and upstart exist, it would seem that it is time for a
next generation init. And given that Ubuntu has now accepted systemd, it has
critical mass and should be the new standard.

"Doing one thing and doing it well" is a fine guide for system tools, but does
not apply to everything - look at the kernel, or Gnome for instance.

------
nifoc
> Consider migrating to BSD, Plan 9 or something similar, if things get really
> out of hand.

I can understand suggesting to migrate to BSD, but Plan 9? Seriously?

And what's the purpose of the "Open Source Tea Party" picture? This surely is
not the only picture of Lennart in existence.

------
voidz
I fell in love with FreeBSD's init style, which is what I switched to when the
move Archlinux made broke my systems. Due to virtualisation demands I had to
switch back to Linux, and chose Funtoo (a Gentoo fork) with the OpenRC init
system.

I've never been happier.

~~~
ciupicri
Isn't FreeBSD's init system monolithic?

------
blueben
<meta name="author" content="VR and DnE">

Seems the authors forgot to give themselves the credit they deserve.

[https://forums.darknedgy.net/profile.php?id=589](https://forums.darknedgy.net/profile.php?id=589)
[https://forums.darknedgy.net/profile.php?id=373](https://forums.darknedgy.net/profile.php?id=373)
[http://billyest.es/About_Me](http://billyest.es/About_Me)

------
oldmantaiter
Considering the adoption and improvements, I'm on board with the
"standardization" of distros with systemd.

Can't stand upstart and it's "Oh you wanted to restart your daemon, but I
won't run the pre-start/post-start/post-stop actions you've configured me to",
but that's just me.

------
mordae
> Contribute to and _use distros like Slackware_ and CRUX that follow
> traditional Unix paradigms.

Made my day. Emphasis mine.

~~~
josteink
The good thing about Slackware is that it acts as a timemachine for how
Unix/Linux used to be back in the mid-90s.

When the neckbeards comes around complaining about "Unix philosophy" you can
always tell them to use Slackware. And then watch them go silent.

------
ef47d35620c1
I don't know much about systemd, so I can't say either way.

So long as I can still get syslog style plain text logs, then I have no
objections. Unix and text log parsing is unparalleled. If simple text log
parsing and manipulation is removed (all binary with only xml or json), then
I'd be very opposed to systemd.

~~~
coldpie
The short story is systemd's logs are "binary", but they have tools to
transform them into whatever plaintext format you like.

------
lasermike026
I hate systemd. I will avoid it when every possible. It is an abomination. I
hate upstart even more.

~~~
pekk
Did you read the page? It doesn't advocate upstart.

~~~
lasermike026
Yes, I did read it. The reason I threw in upstart is because these inits have
similar design philosophies.

------
lmedinas
Systemd got a huge boost due the involved from Red Hat. But then most of the
distros are adopting it, even Debian and Ubuntu. I don't see a reason but
still if you want to stay out of systemd better use Gentoo or other "non"
major distro.

~~~
mateuszf
The reason is that it's awesome.

------
duncan_bayne
I recently installed and investigated PC-BSD for this very reason; a friend
who's a BSD user commented that systemd has been driving BSD adoption very
hard recently. I intend switching to PC-BSD for personal and work use within
the year.

------
silon3
Does the old "good standard will have 2 or more implementations" apply here?

------
lvillani
Cached:
[http://webcache.googleusercontent.com/search?q=cache:zylqvGo...](http://webcache.googleusercontent.com/search?q=cache:zylqvGo21_oJ:boycottsystemd.org/)

(the site is unreachable at the moment).

------
midas007
Until there's a viable alternative, it looks like whining.

------
ausjke
I hate to be personal, the guy leads systemd is indeed a genius, but genius
could be more destructive, his way to do things for linux/unix is too
intrusive for whatever he has done so far.

it's always good to try a disruptive way on the side before it matures and
gets accepted gradually, however with the direct support from Redhat(where he
is an employee) this systemd thing carries much more power than a typical open
source project, sigh.

I would rather stay with sysvinit instead of something like this.

I think he should be employed at Microsoft to help them revamp their OS or
whatever, make it or break it there, but please stay out of OSS.

------
legulere
They single out Lennart Poettering but don't have the guts to write their own
names under their arguments. You can't take this serious.

------
bitwize
The "debate" about systemd is like the "debate" about global warming: all the
people with any knowledge of the issue fall on one side, and the opposition
consists largely of the ignorant and butthurt.

Systemd has won by being vastly superior to any alternatives. I suppose it's
all right to use something else but the community has embraced systemd as the
correct solution, and you lose community support and assume all the risk of
breakage if you do not stick with systemd.

~~~
Niten
> Systemd has won by being vastly superior to any alternatives.

Systemd is better than Upstart, but it won in no small part due to politicking
and strategically merging other projects that everyone else depends on.

------
peterwwillis
tl;dr systemd crashes systems, is incompatible with other distros and OSes,
adds admin difficulty, breaks applications, and introduces security holes

\---

systemd was created in order to improve the speed of booting up your system.
I'm serious. It was created because waiting a minute to boot up your machine
once was too long.

In order to accomplish those faster boot times, they ripped out the stock init
system model, and created a monolithic, non-portable, non-backwards-
compatible, kernel-version-specific, Noah's Ark of API calls and custom tools
which use binary formats and incompatible IPC methods to start programs that
were never designed to run that way. They made obsolete virtually every aspect
of the operating system which used to work with existing applications to start
and maintain the running of userland programs. For faster boot times.

Of course, most of you don't care because you don't have to maintain your
system, as long as it just works. What does this mean for people who _do_ work
with the system?

First off, building tools that work with the system are now more complex. It
used to be you could use any i/o or ipc method to do anything you wanted. Now
you have to look up and call and API call - and if the API call you want isn't
in systemd's tool, or it doesn't expose it in a way you can use in your
program, tough. Better become a C programmer fast.

Second, better be careful how you update your system. Every version of
systemd, and any software it depends on, could crash your entire machine if a
bug is introduced. I weep for the poor sysadmins who push out an update to
thousands of machines only to find a strange bug which takes them all down,
all because systemd decided having an enormous codebase was worth booting 20
seconds faster.

I hope you've got money for a security audit. systemd has had nine security
vulnerabilities in the past four years. For comparison, sysvinit has had one
CVE - in 1999. I haven't found any CVEs or security bulletins for upstart,
which sounds amazing to me.

When it comes time to porting your application to Linux, you don't get to just
write it in a way that would normally work on most Unix-like systems (which
would, at this point, be virtually every operating system that isn't Windows
or Mac OS, and now Linux). Now you have a new porting target specifically just
to get your application to _run_ , and then you get to deal with the normal
porting issues.

At the end of the day, systemd is a culmination of two ideas, with one result.
One idea is that a "superior design" with "advanced features" is the only
benchmark in which we should design and run a system. The other idea is that
we don't need to keep compatibility with legacy systems or alternative
platforms, because fuck users, admins, developers, security analysts, distro
maintainers and portability teams, we want faster boot times , damnit. And
it's Advanced! The result? A big fucking mess of complexity that breaks
everything that came before, introduces security holes, makes it more
difficult to modify or maintain your system, and breaks compatibility with
other systems (even Linux ones).

But aside from all that, systemd is great.

------
adimania
It is Linux. Let systemd live and if you don't like it, switch to upstart. No
one is stopping you.

~~~
chronid
It's (slowly) becoming impossible.

~~~
pekk
This is the "TempleOS impulse". The feeling of disgust with byzantine
complexity, driving an impulse to start clean and chase the money changers out
of the temple

~~~
voidz
Upvoted for mentioning TempleOS, I have never been more frightened when
reading about OSs.

------
dschiptsov
There must be already a name for this particular fallacy, when a bunch of
people considered themselves "knowing the [only] right direction" and
especially "destroying and discarding everything to build it up from scratch
as they know will be the best for all". A-la those uneducated, ignorant, but
cook-sure and self-confident lower-class revolutionaries in Russia hundred
years ago who were unable to grasp that "evolved [social] system" has some
subtle "laws , forces and reasons" behind it and that uncomprehensive, even
unreadable philosophy or a naive, oversimplified model [of economics] is much
worse than no philosophy or model whatsoever. Self-regulated (and especially
evolved) complex systems are "smarter" than any bunch of individuals ,)

------
SnakeDoc
Just pointing out it's not that difficult to "roll your own" linux distro.
It'll take you an afternoon if you haven't done it before... and you can very
well choose to keep using sysvinit if you want (my personal distro will use
sysvinit probably until the end of the year when I have time to figure out how
to integrate systemd).

------
SnakeDoc
I think the website is missing the legal disclaimer "Paid for by Canonical
(because we're bitter)".

~~~
pekk
Again no, Canonical wants to sell services around Ubuntu, which will soon be
based on systemd, by decree of Mark Shuttleworth.

Wanting to do that, it doesn't make sense that they would shill for Slackware
at the top of the page.

------
SnakeDoc
The Canonical fanboys are just upset they lost out on their inferior
technology and now are trying to do everything possible to stall it. systemd
is unquestionably a big step forward, Upstart is only a step to the side.
There is a reason the serious linux distros (no, Ubuntu is not serious, it's a
toy for newbies to use on their desktop) have all chosen systemd. There is
also a reason some of them tried Upstart and decided it was not good.

~~~
pekk
No, the Canonical fanboys are following Mark Shuttleworth in accepting systemd
as the future for Ubuntu.

This is a different set of people.

------
lucian1900
This is why we can't have nice things.

------
Grue3
I'm getting code 500 error, but I'm guessing a Republican has been discovered
to be somehow related to systemd.

------
evbogue
If this person had been running systemd, this website would still be up.

