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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
|
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>What Arch Linux's switch to systemd means for users — Luke T. Shumaker</title>
<link rel="stylesheet" href="assets/style.css">
<link rel="alternate" type="application/atom+xml" href="./index.atom" name="web log entries"/>
</head>
<body>
<header><a href="/">Luke T. Shumaker</a> » <a href=/blog>blog</a> » arch-systemd</header>
<article>
<h1 id="what-arch-linuxs-switch-to-systemd-means-for-users">What Arch
Linux’s switch to systemd means for users</h1>
<p>This is based on a post on <a
href="http://www.reddit.com/r/archlinux/comments/zoffo/systemd_we_will_keep_making_it_the_distro_we_like/c66nrcb">reddit</a>,
published on 2012-09-11.</p>
<p>systemd is a replacement for UNIX System V-style init; instead of
having <code>/etc/init.d/*</code> or <code>/etc/rc.d/*</code> scripts,
systemd runs in the background to manage them.</p>
<p>This has the <strong>advantages</strong> 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.</p>
<p>The <strong>downside</strong> is that it is (allegedly) big,
bloated<a href="#fn1" class="footnote-ref" id="fnref1"
role="doc-noteref"><sup>1</sup></a>, 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.</p>
<p>The <strong>changes</strong> an Arch user needs to worry about is
that everything is being moved out of <code>/etc/rc.conf</code>. 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 <code>DAEMONS</code>.<a
href="#fn2" class="footnote-ref" id="fnref2"
role="doc-noteref"><sup>2</sup></a> For now there is compatibility for
the variables that used to be there, but that is going away.</p>
<aside id="footnotes" class="footnotes footnotes-end-of-document"
role="doc-endnotes">
<hr />
<ol>
<li id="fn1"><p><em>I</em> 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.</p>
<p>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 <strong>advantage</strong> I missed: <em>people generally
consider systemd “units” to be more robust and easier to write than SysV
“scripts”.</em></p>
<p>I’m actually not a fan of either. If I had more time on my hands, I’d
be running a <code>make</code>-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.<a href="#fnref1" class="footnote-back"
role="doc-backlink">↩︎</a></p></li>
<li id="fn2"><p>You can still have <code>USEDMRAID</code>,
<code>USELVM</code>, <code>interface</code>, <code>address</code>,
<code>netmask</code>, and <code>gateway</code>. But those are minor.<a
href="#fnref2" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
</ol>
</aside>
</article>
<footer>
<aside class="sponsor"><p>I'd love it if you <a class="em"
href="/sponsor/">sponsored me</a>. It will allow me to continue
my work on the GNU/Linux ecosystem. Thanks!</p></aside>
<p>The content of this page is Copyright © 2012 <a href="mailto:lukeshu@lukeshu.com">Luke T. Shumaker</a>.</p>
<p>This page is licensed under the <a href="https://creativecommons.org/licenses/by-sa/4.0/">CC BY-SA 4.0</a> license.</p>
</footer>
</body>
</html>
|
