
Arch Linux to migrate to Systemd - g-garron
http://mailman.archlinux.org/pipermail/arch-dev-public/2012-August/023389.html
======
dredmorbius
Systemd takes a reliable, known, thoroughly debugged process (init, or various
of its tweaks, including Ubuntu's _upstart_ and Debian's _insserv_ ), and
converts booting from a deterministic, predictable process to one that's
inherently _unpredictable_.

And the stated objective? "To reduce boot times".

The best way to reduce boot times is to _not boot_. The _reason_ I reboot
systems is _to return them to a known good state_ (or, very rarely, to perform
a kernel upgrade).

On server hardware, I perform boots infrequently, and really, really, really
want them to work right.

On end-user hardware, I perform boots infrequently, preferring to use
suspend/restore to quiesce my systems (suspend to RAM, occasionally suspend to
disk). _That_ is a process which I'd like to have very thoroughly debugged and
not give me any unhappy surprises (say: crash my video, e.g.: interactive
session, lose track of drivers/hardware, especially wireless).

Systemd is the wrong answer to the wrong problem.

Much written better than I can:
[http://blog.mywarwithentropy.com/2010/10/upstart-better-
init...](http://blog.mywarwithentropy.com/2010/10/upstart-better-init-or-more-
painful-one.html)

Systemd loses the huge transitivity of shell scripting, and puts you in the
position of needing to acquire a novel skill at the one time you least need to
be _learning_ and most need to be _applying_ : when your systems won't boot
straight: <https://lwn.net/Articles/494711/>

I'm also not much surprised that Red Hat, who've had such a historic problem
with consistency and reliable dependency management within their packaging
system (as compared to Debian/Ubuntu) are proponents of this technology (hint:
it's not the package format, it's the policy, or lack thereof). And now Arch.

~~~
FooBarWidget
I'm sorry, but shell scripts _suck_ as a language for booting the system. You
need to fork() and exec() for almost anything non-trivial, wasting precious
CPU cycles in the progress. It looks like every Linux distro has its own way
to manage boot scripts. And when they fail, you have no idea what happened.

More importantly, init only handles _starting and stopping_ of services. They
don't _manage_ services, like restarting them when they crash. Systemd can do
that. The socket activation stuff also allows one to potentially save
resources by not starting services until they're really needed.

The best way to reduce boot times is to not boot? Have you ever heard of
"laptops" and "average users"? Even on my servers, a shorter boot time is
welcome.

~~~
thaumaturgy
I'm a daily laptop linux user, specifically Chakra Linux, <http://chakra-
linux.org/>.

My wish list goes something like this: better wireless drivers, improved
sleep/suspend/hibernate/resume, better power management, a better package
manager, more up-to-date applications ...

At the very, very bottom of that list -- the very last item, so far at the
bottom of the list that it's in danger of falling off entirely -- is "faster
boot times".

Dredmorbius is spot on, at least for me and my daily usage and the couple
dozen or so servers that I'm responsible for. If things are so pooched that I
have to reboot it, then it doesn't really matter to me anymore whether it
takes 30 seconds or a minute to start up. I would much prefer not having to
reboot it in the first place.

Since Chakra was (I think) forked from Arch Linux, I'll have to check and see
if they're gonna do this too.

I hope not.

(edit: none of this is intended as a criticism of Chakra's development team,
who have been doing an amazing job of putting together a system that, despite
its warts, I genuinely enjoy using every day.)

~~~
jwcacces
I'm a daily laptop linux user, and like you I know how to go a long time
between reboots, so I can wait for my computer to start up.

But forget about us, we're already converts, we don't matter. My grandfather
(93 years old) is also a daily laptop linux user. When he presses that power
button, that laptop better be booted and ready /yesterday/. And when he pushes
it again, it better be off before he closes the lid. Slow startup and shutdown
times are simply not an acceptable user experience; they are literally the
difference between enjoying and wanting to use the computer, and not wanting
to bother with it.

And don't think for a minute he's going to learn about suspend, hibernate,
power savings, battery life, or whatever. It's just not going to happen. His
laptop lives in the closet, so it's going to be off (either by his doing, or
the battery running out). When he sees something on tv and wants to read about
it, he takes the laptop out, plugs it in, and turns it on. If it's not ready
for him when he's ready for it (i.e. now) then he just won't use it.

However, since I've got that sucker booting from power button to firefox home
page load complete in under 7 seconds, he uses it all the time. And it's
amazing how it enriches his life. You simply can't get computer use to
penetrate into lives like his without fast booting and an easy user
experience.

~~~
dredmorbius
The sane thing is to tie power management to the power button.

Light press: hybrid suspend suspends to RAM, also saves state to disk --
system spins down quickly and, so long as it's not been hibernating long
enough to drain battery, restores in a second or so. Longer and it will do a
boot/restore from disk.

Long press: powerdown.

Many devices have separate "suspend" and "poweroff" hardware (or soft
controls) as well.

The OS and tools do all the magic bits.

~~~
jwcacces
That's lovely, but you're not paying attention. It doesn't matter how it's set
up. It matters how it preforms.

To the non-enthusiast / casual user, closing the lid, pressing the power
button, doing a system shutdown, inactivity sleep timeout, and the battery
running out are all the same thing: the computer was "on", now it's "off".
Asking someone like this to think about how the reason it came to be "off"
affects how fast it will be ready for them later is a fool's errand. It needs
to be fast in every circumstance.

Normal people just want to get something done. They judge their computer by
how easy it is to use and how fast it responds to what they do. That included
cold boots, launching program, and downloading webpages. Even if they're doing
something "the wrong way", they will still judge it with the same criteria and
the same harshness. I want my grandfather to use linux because I can quickly
help him and fix things from afar, and because there are very few ways for him
to mess it up. He uses it because he really thinks it's better then windows,
and that's purely because it's fast and easy, every way he uses it.

For the record, I set it up so the power button does a shutdown, and
everything else results in a hybrid sleep. What he understands that he can
shut it down if he wants, otherwise no matter what happens (lid closed or not)
everything will be the way he left it, even if he forgets about it for a few
days or doesn't charge it.

That kind of simplicity is what allows people to think of linux as something
they can use, not just some super complicated tool for "hackers" and "computer
geniuses". I'm not saying it should be dumbed down or have options removed,
but I am saying that making it enjoyable for everyone results in more people
using it, and that benefits us all.

------
ominous_prime
The opposition that is seen from some people to moving away from SysV style
init is amazing to me. I don't have much experience with systemd, but upstart
has been a refreshing change from the old shell scripts.

Having been both on the packaging side, as well as the admin side, I can't
imagine _not_ abandoning the daemonize and PID file paradigm. The number of
package I've seen that have init scripts that don't properly stop or start the
daemon, or don't check the pid file and or subsys lock file; or daemons that
don't properly chdir, or don't release an errant file descriptor, make me want
to scream. Not to mention the process monitoring and full lifecycle
management, it just seems like a no-brainer decision.

There's a lot of noise coming from people saying that their laptop doesn't
need it, booting isn't that slow, etc; the driving force isn't targeting
laptops/desktop, it's targeting the largest use of Linux -- servers. The
process management is the big win, and boot time is just a bonus.

~~~
dredmorbius
On every server I've seen, firmware initialization, generally networking and
storage controllers, takes far more time than the OS boot sequence. To the
tune of 4-5 minutes for hardware vs. ~1-2 minutes (or less) from kernel boot
to console login.

At which point actual workload stack initialization (webserver, application
server, database, caches) generally takes additional time. Depending on where
you're starting form, a few seconds to many minutes or hours (DB
init/restore/replication from snapshots/backups/master).

Again: the few seconds you're going to save swapping out _really stable
infrastructure_ 1) isn't the problem and 2) introduces change and complexity
(and hence uncertainty and unreliability) to a very critical system component.

~~~
reinhardt
Did you actually read the comment you replied to or you keep copying and
pasting blindly your strawman argument in this thread? If you did read it,
which part of "The process management is the big win, and boot time is just a
bonus" was unclear?

~~~
dredmorbius
1: boot time is Poettering's own argument in favor:
<http://0pointer.de/blog/projects/systemd.html>

If the systemd team wants to drag goalposts all across the field, that's fine.
I'm just going to note their original location.

If you want to build a better xinetd, or better SysV init based dependency
system (insserv), or alternative (upstart), then do it. OK, upstart _also_
fucks with init, but with a lot less whack then systemd.

As to the "I've seen poorly written init scripts": on my distro of choice
(Debian), package maintainers do a very good job of providing sane scripts
(which are a lot easier to follow than RH scripts, something I noticed when
first cutting over to Debian), in part because the distro provides a solid,
18-years of evolution, SysV init based process, and a policy that tends to
iron out occasional bouts of dumpth.

------
planckscnst
systemd is so obviously better than anything out there, I'm surprised there is
any controversy. I've yet to see a valid complaint.

"Poettoering sucks! PulseAudio!" That's not much of a technical argument
against systemd, now is it? Pretty much everyone who complains about
PulseAudio doesn't even know what it is; they just blame it when their audio
doesn't work (usually for some unrelated reason).

"It's not deterministic!" You're probably talking abot the socket activation.
That part is pletny deterministic - a message comes in for a service, that
service gets started. Are the messages coming in not deterministic enough for
you? You can add your own unit files that starts the service at boot, and you
can even control what starts before and after the service.

"Shell scripts are so simple!" You know what's simpler than a shell script? A
unit file. They are also more consistent. The various shell scripts are all
written by different package maintainers and are rediculously diverse. Some
are full-featured init scripts that can send signals to the service to make it
do stuff; others can't even restart the service. Unit files are so simple that
it's pretty hard for any different styles to really matter.

Also, the method for enabling a service is different in all the distributions
with shell scripts. Debian is update-rc.d; Red Hat is chkconfig; Arch is vi
/etc/rc.conf. With everything moving to systemd, we finally have one way:
systemctl.

~~~
sparkie
> I've yet to see a valid complaint.

Perhaps this is the main problem - the people pushing technology are not
willing to acknowledge that people have different use cases to them. There are
complaints, and they are valid - you just do not see them as valid, because
they don't concern you.

Since you brought PulseAudio up, there's a very legitimate, common complain
about it - latency. Yes, the people who care most about audio - the creators
and audiophiles - are pushed aside as "not relevant," because Lennart is only
interested in "appealing to the majority," not some minority fringe groups.

Really, the only reasonable solution for some people is Jack - but any hope of
bridging the gap between Jack and Pulse is lost in a barrage of people pushing
for a "single audio solution" - and prematurely claiming Pulse as the victor.

As a result, people write applications to only use PulseAudio, which are then
unusable to someone using Jack (aside from hacks to make pulse act as a jack
client). Professional audio software is still basically required to code for
both Jack and Pulse/ALSA or whatnot - we're nowhere near a single audio
solution.

But don't tell that to Poettering - because he is adamant that his solution is
the only solution, and anyone who it doesn't suit is just playing with toys.

That's literally how he referred to Debain's choice to not push systemd
because it targets multiple kernels, which systemd does not work with. (Which
btw, Arch does too - although perhaps not the same people.)

Have you still yet to see a valid complaint? Of course kFreeBSD is not a valid
complaint to you, because you've never used it, and never plan to - it's of no
concern for you.

If we only cared about what's popular, Linux would not be what it is now - and
you'd be on Windows. Linux is not the end-all solution to every problem
anyway, as other lesser popular kernels have some great technology in them
which is lacking in Linux. It's the only solution for Red Hat though - so you
can see why they're happy to push such agenda. If you're not a Red Hat
customer, your opinion is invalid.

Arch was built with a different mentality - the one of personal freedom to do
what the hell you want with your desktop, not for the benefit of some company.
You are free to use or reject any software you don't want.

Well, not any more. Pushing systemd on users breaks that mentality - because
the choice is stripped from you. The choice is already there in Arch though -
and has been for a while. If you want systemd, you can use it. If you don't
want it, don't bother. Moving the other way is not really possible though -
because if you build your system around systemd, you can't revert back
(without taking the time to rewrite everything that depends on systemd.)

The dependency problem in itself is a complaint against systemd. Should udev
users be forced to use systemd for example? Normally we would introduce
another layer of abstraction to our code - such that we can share common code
between systemd-udev and non-systemd-udev, and have a solution where everyone
wins - the systemd users benefit from improvements in systemd integration,
whilst everyone benefits from improvements to udev which aren't systemd
dependent. This is programming 101.

Well, not if you're the package maintainer and have more political motives.
Any proposal to introduce such a split with common code will probably be met
with: NO, we're not interested - It's too much work - It's pointless
supporting non-systemd - Fork it.

A fork it will be - and because the fork will be much less popular - it will
obviously be a toy.

Just to be clear - I'm not against systemd and Pulse from a technical point of
view, and I can very clearly see the advantages they have over alternatives,
for linux. I'm not really against fragmentation either.

What I am against though, is the politics of it. The constant pushing of
systemd down everyone's throat like it's a fucking panacea. One day saying
"don't use if if you don't want," and the next blogging "you're fucking idiots
for not using it." (Lennart's approach to Ubuntu.)

~~~
ElliotH
This takes away no choice, I'm sure if you want to use old style init that'll
be available too, you'll just sacrifice easier config, faster boot, better
diagnostics, logging and profiling of boot.

~~~
sparkie
The old init will still be available, but the point is that anything built to
run on systemd only, will not be easy to use with older systems without effort
to backport them. This isn't much of a problem if you do choose to use systemd
though, because it's backward compatible with older scripts.

~~~
planckscnst
It would be awfully hard to make a service that didn't work without systemd.
Your software shouldn't depend on systemd, just as it shouldn't depend on
init.d, rc.d, or anything else unless it's a tool specifically for working
with that (like chkconfig or update-rc.d).

------
Ralith
I've been running systemd on my computers for a few months now, and it's
great. Dramatically accelerates my boot times, easy to configure, and easy to
use. The only problem I've ever had is when a daemon doesn't include a systemd
unit file, and I imagine official migration will include resolving all the
remaining cases of that.

~~~
JoshTriplett
systemd supports standard init scripts as well, allowing an incremental
migration.

------
jacques_chester
There's a whole bunch of tools groping awkardly in a single direction here:

1\. Give a graph to the computer

2\. The computer makes the graph a reality

[http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-
reign...](http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reigning-in-
chaos/)

Puppet, Chef, Cfengine come at it from an on-disk direction.

Upstart, SMF, systemd, launchd come at it from a runtime direction.

They're still talking past each other. And it's annoying.

What I would really like is a system that does _both_ as first-class citizens.
I may be waiting a while.

~~~
_sh

      There's a whole bunch of tools groping awkardly in a single direction here:
        1. Give a graph to the computer
        2. The computer makes the graph a reality
    

The good ol' fashioned make tool does exactly this and, in the spirit of Unix,
pretty much nothing else.

The problem is in determining whether the dependencies of a node in the graph
are satisfied. Make does this by comparing file times. All the other 'graph
resolving systems' you mentioned do something different. Obviously the
solution is to abstract the dependency test from the graph itself. Then all
these systems become pretty much the same.

~~~
jacques_chester
> The good ol' fashioned make tool does exactly this and, in the spirit of
> Unix, pretty much nothing else.

Make still requires a manual step. I'm thinking of systems that do this
themselves. Active control systems, constantly comparing the state of the
world to the reference graph.

I don't want the unix tradition. The unix tradition is a pain in the rear end
to actually administer. I want a single management framework with a single DSL
that does it all.

------
CrLf
I don't really understand the problems these "init" replacements wish to
solve. I mean, actual, real-world problems. To me, it's just another instance
of the same worrisome trend that brought us NetworkManager and makes
everything evolve to integrate with D-Bus: do everything to make desktop-Linux
better, even if it negatively impacts the use-cases where Linux is actually
successful (everything else).

I don't care much for the desktop, but I do care for servers.

Boot times on servers are irrelevant. Reducing them brings little benefit.
Servers shouldn't have to be rebooted that often for it to matter, and also,
servers spend most of their boot time POSTing and initializing firmware for
the various cards. In many cases, twice as much as it takes to boot a normal
SysV init Linux install.

Not only that, but it is much more important to be able to effectively
troubleshoot boot problems than to get some dubious features that nobody
really felt missing for all these decades.

I don't care if Fedora or Arch do this, but I do care if more server-oriented
distributions do. I still haven't gotten over the fact that RHEL6 now gives
you the option of using NetworkManager (bleh) or configuring interfaces
through (badly designed) configuration files. What's wrong with the old
system-config-network?

~~~
alexchamberlain
I have little experience with servers, but... I must agree with your
sentiment. One of the great things about Linux is how simple things are. GUIs
are great, but not if I have to start a desktop just to get a network
connection!

~~~
Ralith
It's this kind of complaint that suggests all the unease is a result from
resistance to learning new systems, rather than any actual flaw in those
systems. NetworkManager operates headlessly, and can be manipulated just fine
with nmcli.

------
bct
It's too bad that opposition to changes like this is often expressed so
trollishly. There's a real tradeoff here (of simplicity and of portability)
that gets glossed over.

~~~
ajross
It's certainly true that the "minimal summary" of the features of systemd vs.
sysvinit (or Busybox, or a BSD init script, which is even simpler) is hugely
skewed against systemd. Understanding how systemd's process tracking works
requires understanding cgroups, for example. Things that used to be one liners
in a script ("mount hugetlbfs -t hugetlbfs /dev/hugepages") suddenly become
first class "mount" objects with status. Systemd introduces a bunch of new
jargon and new tools.

But at the same time systemd really does do much more than a classic "launch
some stuff and call wait()" style init. And that stuff is pretty nice -- in a
systemd world, no one needs to worry about writing a "daemon" any more. Any
program that sits in a loop writing to standard output can be started, stopped
and syslog'd.

And making this work isn't bad at all. You configure systemd with
straightforward .ini file syntax and clear fields (e.g.
"ExecStart=/path/to/my/program").

Basically it's complicated in structure (and the task of porting a whole
distro to it strikes me as pretty scary) but simple in interface, and that's
pretty much the right place to be. Most "systemd is too hard!" rants don't
survive long past the initial implementation phase.

~~~
bct
> Basically it's complicated in structure [...] but simple in interface, and
> that's pretty much the right place to be.

Thanks for posting this, this is a great analysis. It gets right to the heart
of many of the disagreements I have with system design orthodoxy.

I think it's exactly the wrong place to be.

------
cies
see here the discussion `systemd vs upstart` (the default on ubuntu):

[http://unix.stackexchange.com/questions/5877/what-are-the-
pr...](http://unix.stackexchange.com/questions/5877/what-are-the-pros-cons-of-
upstart-and-systemd)

and here the design docs of systemd:

<http://0pointer.de/blog/projects/systemd.html>

overall i think systemd is a much better implementation toward the same goal.
some distros have already switched from upstart to it, not saying that upstart
is not an extremely popular choice as well.

------
sciurus
Allen McRae had an interesting, relvant post recently- "Are We Removing What
Defines Arch Linux?"

[http://allanmcrae.com/2012/08/are-we-removing-what-
defines-a...](http://allanmcrae.com/2012/08/are-we-removing-what-defines-arch-
linux/)

------
throwaway54-762
Here's the (much more readable) mailing list in gmane:
<http://news.gmane.org/gmane.linux.arch.devel>

Currently (Friday 3:48 Pacific time), this thread is at the top.

Edit: Lots of +1s in the early thread messages; some elaboration surrounding
migration issues in later emails.

------
ijobs-ly
In my biased opinion, once you have gotten over the learning curve, nothing
beats daemontools for running services. It is a fantastic set of tools. Why
some OS doesn't just embrace djbware I'll never understand. It compiles,
smoothly, in seconds. (There's no need for distributing binaries.) And the
chances of the author initiating lawsuits (as some Linux foundations are known
to do), over something placed in the "public domain" are close to nil. He's
got better things to do.

BSD's rc system is fine. Sometimes the scripts are too verbose. But the whole
idea is the system is simple enough to understand that you can write your own
scripts -- more concisely, if you wish. You don't need to read a book (e.g.
Linux from Scratch), keep most things disabled by default and let the user
turn stuff on as they need it.

I recently used Debian's live USB, the rescue version, for a little while and
was amazed at how much stuff is turned on by default. I guess if you
understand each and every choice that's been made for you it's OK. But if not,
that approach is not very conducive to learning.

As for Apple, never mind all the XML fluff, good luck trying to understand
what's going on behind the scenes with their computers anymore. They can't
even manage to let you have an nsswitch.conf or equivalent.

~~~
dredmorbius
Debian (and other apt-based systems) are the Lego blocks systems of the Linux
world. If you install a service, the assumption is that you want it to run (if
you don't want it to run, you can either uninstall it or deactivate it).
Bootable / live versions tend to have more comprehensive lists of installed
packages to allow for greater utility/flexibility -- though some (Knoppix)
actually allow you to install additional packages (yes, booted RAM-only) into
the booted system.

The is not the case on BSD systems (generally an integrated whole, though
they've got package management) or RPM (poorer package management leading very
frequently to a "kitchen sink" installation paradigm).

Yeah. RHEL's even got a package you can install to enable/disable postfix vs
... oh, whatever the default MTA is, I can't keep track (smail still? I know
they've moved off of sendmail, right? Right?).

------
tungstentim
The link is to a proposal, rather than an announcement, but the replies seem
very positive, which bodes well.

~~~
vhf
A proposal followed by a discussion without any opposition to the proposal,
and then a decision.

Announcement will surely be made shortly :)

~~~
gbraad
Which resulted in a discussion on a different thread?
[http://mailman.archlinux.org/pipermail/arch-dev-
public/2012-...](http://mailman.archlinux.org/pipermail/arch-dev-
public/2012-August/023386.html)

------
ari_elle
they should just migrate to openrc, i heard debian might actually do that.
would be there 2nd nice choice this month after switching to xfce as default
de

