
Without Systemd - turrini
http://without-systemd.org/wiki/index.php/Main_Page
======
tdicola
I'm looking forward to 2 or 3 years from now when we can look back and laugh
at all the fear and apprehension about systemd.

That said though, I did just recently upgrade to Ubuntu 15.04 (which is all
systemd now) and it is noticeably slower to boot up compared to my old
upstart-based 14.04 LTS install. Hopefully there's some more optimization that
needs to be done to bring the boot-up speed to parity with the previous
versions.

~~~
nextos
I like many things systemd has brought.

However, I think the app-ification they are planning to deploy in Linux
systems is extremely dangerous. Essentially they are implementing app bundles
as containers [1].

All good lessons learnt from package managers? Gone. Nix? Forgotten.

Imagine a heartbleed like scenario. In a controlled situation with a distro
that uses a package manager this is easy to fix. Just upgrade the compromised
package. Now think what happens if you have 20 different containers running 20
different userlands...

It's really scary. Linux has become such a nice OS partly because many distros
created great package management tools.

These systemd guys make things terribly complex for no reason. Systemd itself
is a monster running as PID 1, which is not very wise from a security
perspective either. Pulseaudio is slow and unreliable. Dbus is quite
inefficient. Etc.

Things are getting ugly. They are messing up with the Linux userland and
ignoring core Unix principles.

[1] [http://0pointer.net/blog/revisiting-how-we-put-together-
linu...](http://0pointer.net/blog/revisiting-how-we-put-together-linux-
systems.html)

~~~
mercurial
> Systemd itself is a monster running as PID 1, which is not very wise from a
> security perspective either.

No. Only a small part of systemd runs as PID 1. Systemd is not a monolith, it
is a bunch of various utilities.

> However, I think the app-ification they are planning to deploy in Linux
> systems is extremely dangerous.

I agree. This sounds scary. However, it does not mean that distros will hurry
to adopt this kind of system. I also get the impression that it is targeted
more toward special use cases than intended to replace traditional package
managers.

> Pulseaudio is slow and unreliable.

While anecdote is not data, I never had any issue with it.

> Dbus is quite inefficient.

They did not invent Dbus, and using the foremost userland IPC mechanism to
communicate is not unreasonable (since, as mentioned above, systemd is a bunch
of utilities, they do need some form of IPC). I don't think it has an impact
in practice.

~~~
pdkl95
> Only a small part of systemd runs as PID 1. Systemd is not a monolith, it is
> a bunch of various utilities.

Ahh, there's the talking point I mentioned in my earlier post[1].

What you're not understanding is that when we describe something as
"monolithic" (or "modular") we're talking about if the design[2], not the
number of binaries it happens to compile into. This is about minimizing
complexity, and the way to do that is to break the problem into small pieces,
while clearly and rigorously defining the interconnections between those
pieces (an area that necessarily involves higher complexity).

As an example in the opposite direction, consider busybox. While it compiles
into a single binary, the _features_ provided by busybox are very modular. You
could remove any of the utilities it can emulate without that change cascading
into lots of other unrelated features (with build system support), and I could
replace any of the utilities with something else (i.e. the standard non-
busybox version) by simply removing a symlink.

Systemd is designed in the opposite manner, on purpose. They put every but of
code the project absorbs into the same repository, claiming it makes
development easier. Of course it does... initially; you get to skip the all
those clearly and rigorously defined interfaces. They can seem like
unnecessary work in the beginning, but it is going to be hell maintaining that
mess of code in the long run.

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

[2] See the "Rule of Modularity":
[http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2...](http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2877537)

~~~
Ao7bei3s
> What you're not understanding is that when we describe something as
> "monolithic" (or "modular") we're talking about if the design[2], not the
> number of binaries it happens to compile into.

What _you 're_ not understanding is that these other binaries _do_ _not_ _run_
_as_ _PID_ _1_ , which is what nextos wrongly claimed.

> This is about minimizing complexity, and the way to do that is to break the
> problem into small pieces, while clearly and rigorously defining the
> interconnections between those pieces (an area that necessarily involves
> higher complexity).

Which is the exact opposite of what has happened during the sysvinit times.

~~~
pdkl95
> other binaries do not run as PID 1, which is what nextos wrongly claimed.

I never claimed they did. Obviously, I was replying to this claim:

"Systemd is not a monolith, it is a bunch of various utilities."

> Which is the exact opposite of what has happened during the sysvinit times.

I never mentioned anything about sysvinit, which has nothing to do with the
bad design in systemd.

Regarding those times, I would agree that the older sysv-rc/initscripts were
not that great either, which is why many of us moved to OpenRC a long time
ago.

------
jmspring
Voted down once, but most of the comments seem centered on desktop versus
actual server installations.

"pulse audio", "gnome 3", etc.

How many people have experience with running systemd based servers in
production and, if appropriate, at scale?

Thoughts?

Comparisons with tried and true components like syslog?

~~~
nathwill
we run a ~70 node system, ~95% virtual/5% physical, almost fully converted
from Scientific Linux 6 to CentOS 7 (only the NFS boxes left!), which is
systemd based.

Concerning systemd as an init system, it's been extremely reliable and simple
to use and manage. Writing unit files, even ones with complex requirements, is
incredibly easy, because the FDO documentation is really terrific. For
instance, we have a host running docker for services that are contingent on an
NFS mount being present on the host: specifying a requirement on the mount-
point for the docker service to boot-up is as simple as creating a
docker.service.d directory and writing a 2-line drop-in unit file with
RequiresMountsFor=/mount/path. Being able to add this functionality so easily,
without having to assume total ownership of managing the rest of the service
configuration really struck me as exemplary of the reasons systemd won the
init wars. It really feels like it bends over backwards to help administrators
get shit done, and done right.

Systemd also provides a _lot_ more visibility into service behavior than other
init systems i've worked with (logs tailed in status output, exit codes,
_real_ pid tracking, etc), which is very helpful in day-to-day work as an
administrator. I'm also pretty regulary surprised by how fast our servers
reboot, though that's a rather minor benefit. Mount units work just like it
says on the tin, not much to report. We haven't started using any of the other
systemd stuff like timers, but may do so as we encounter use-cases where it's
preferable.

On the flip side, I'm not especially keen on journald. It makes it pretty
rough to do system log aggregation out of the box. There's some plans to add
the ability to forward logs to a remote server, but it's not there yet on
CentOS. Rsyslog has nice integration on CentOS that can help make things
resemble a more traditional log structure, but I can't speak to it's viability
as we ended up using a more lightweight solution that uses journalds option to
forward all message via syslog over a local socket
(/run/systemd/journal/syslog) as an input for our log aggregator. It's
irritating on occasion, but we've never not been able to work around it, and
i'm confident that things will get better going forward, as journald gets more
features and more log aggregators add support for polling the journal.

most importantly, i am _really_ looking forward to Ubuntu 16.04 coming out
with systemd, at which time Ubuntu, Debian, CentOS and more will _all_ use the
same init system in an LTS release. as a regular author of open-source chef
cookbooks, it's exciting to think of a future where there's enough x-platform
consistency that it's no longer necessary to special-case service management.
along this same line, systemd unit aliases are also pretty awesome, and i hope
package maintainers in both the rpm and deb world start working to add aliases
for divergently named services (apache2 vs httpd, mysql vs mysqld, etc.).

ultimately, we're not dogmatic about the philosophy arguments, most of which
at this point strike me as sour grapes. i just want a system that works
reliably, is well documented, and makes it easy for me to get shit done.
systemd fits that bill better than its predecessors, so we're happy using it
until something better comes along :)

~~~
jmspring
I may be showing my gray ear hairs, but I remember the early days of Gentoo
where ZOMG boot 3ms faster by optimizing! The init portion of systemd reminds
me of those days.

Your mention of requirements for service execution is certainly an interesting
avenue for me to think about.

Honestly for my day to day "spin up VM, do some experiments/coding, fine tune"
it doesn't matter. For some other work I am doing dealing with longer term
system maintenance/administration, I've been slow to adapt.

Thanks for the insights.

~~~
the_why_of_y
> The init portion of systemd reminds me of those days.

There is quite a big difference in that systemd was never _designed_ to boot
fast - it was designed first and foremost to boot _correctly_ , and the much
increased performance was mostly a happy accident of the design they came up
with.

~~~
falcolas
This isn't backed up by Lennart's own blog post about the initial Systemd
development:

> Unfortunately, the traditional SysV init system was not particularly fast.

> Another thing we can learn from the MacOS boot-up logic is that shell
> scripts are [...] slow in execution.

> it is also our plan to experiment with systemd not only for optimizing boot
> times

It seems like the real motivation was exactly reversed from your comment -
speed first, and correctness as a happy accident.

He does put up a later post (biggest myths about systemd) some three years
later which tries to change this impression, but that reads much more like an
attempt to move the goalposts than an actual design goal.

[http://0pointer.de/blog/projects/systemd.html](http://0pointer.de/blog/projects/systemd.html)

~~~
the_why_of_y
You have a point - clearly my comment over-stated it - let's say that both
correctness and performance were design goals.

At the time Upstart was considered "the future" ... read the comment from
Scott James Remnant on this post (unfortunately there doesn't seem to be a way
to link to a G+ comment directly?):

[https://plus.google.com/+KaySievers/posts/C3chC26khpq](https://plus.google.com/+KaySievers/posts/C3chC26khpq)

The point is that Upstart's event model was found to be flawed, and the
copyright assignment policy meant that fixing Upstart was undesirable.

This explains the filesystem problem (both relevant for reliability and
performance) and claims that systemd solves it but Upstart cannot:

[https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...](https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/ip8e1DqJdxT)

------
jmspring
I've used distributions w/ systemd on a number of virtual machines, but those
have mostly been non-critical machines.

I was slowly moving back to FreeBSD from Ubuntu/Debian. Systemd has moved that
timing forward. Boot up time and monolithic systems don't do it for me --
managable sure -- but not my cup of tea.

------
Kooontz
Interesting that now distros can list this as a big feature: systemd-free.

