summaryrefslogtreecommitdiff
path: root/public/arch-systemd.md
blob: 3ada0878ab0d24fbd49f7001b10aa43367a6b15c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
What Arch Linux's switch to systemd means for users
===================================================
---
date: "2012-09-11"
---

This is based on a post on [reddit][1], published on 2012-09-11.

[1]: http://www.reddit.com/r/archlinux/comments/zoffo/systemd_we_will_keep_making_it_the_distro_we_like/c66nrcb

systemd is a replacement for UNIX System V-style init; instead of
having `/etc/init.d/*` or `/etc/rc.d/*` scripts, systemd runs in the
background to manage them.

This has the **advantages** that there is proper dependency tracking,
easing the life of the administrator and allowing for things to be run
in parallel safely.  It also uses "targets" instead of "init levels",
which just makes more sense.  It also means that a target can be
started or stopped on the fly, such as mounting or unmounting a drive,
which has in the past only been done at boot up and shut down.

The **downside** is that it is (allegedly) big, bloated[^1], and does
(arguably) more than it should.  Why is there a dedicated
systemd-fsck?  Why does systemd encapsulate the functionality of
syslog? That, and it means somebody is standing on my lawn.

The **changes** an Arch user needs to worry about is that everything
is being moved out of `/etc/rc.conf`.  Arch users will still have the
choice between systemd and SysV-init, but rc.conf is becoming the
SysV-init configuration file, rather than the general system
configuration file.  If you will still be using SysV-init, basically
the only thing in rc.conf will be `DAEMONS`.[^2] For now
there is compatibility for the variables that used to be there, but
that is going away.

[^1]:
    *I* don't think it's bloated, but that is the criticism.
    Basically, I discount any argument that uses "bloated" without
    backing it up.  I was trying to say that it takes a lot of heat
    for being bloated, and that there is be some truth to that (the
    systemd-fsck and syslog comments), but that these claims are
    largely unsubstantiated, and more along the lines of "I would have
    done it differently".  Maybe your ideas are better, but you
    haven't written the code.
    
    I personally don't have an opinion either way about SysV-init vs
    systemd. I recently migrated my boxes to systemd, but that was
    because the SysV init scripts for NFSv4 in Arch are problematic. I
    suppose this is another **advantage** I missed: *people generally
    consider systemd "units" to be more robust and easier to write
    than SysV "scripts".*
   
    I'm actually not a fan of either. If I had more time on my hands,
    I'd be running a `make`-based init system based on a research
    project IBM did a while ago. So I consider myself fairly
    objective; my horse isn't in this race.

[^2]:
    You can still have `USEDMRAID`, `USELVM`, `interface`, `address`,
    `netmask`, and `gateway`. But those are minor.