<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Before I get into the directed inline
reply below, here's my overall position. I don't have as much time
as I like to go into it in depth, but I might be able to be
convinced to resurrect my blog or put together a talk on it...<br>
<br>
OH! And PulseAudio was mentioned. PulseAudio SUCKED MAJORLY in
the beginning. But today it is superior to anything else I've
used. I still can't figure out how to get Microsoft Windows to
drive my speakers correctly. Modern PulseAudio (as found in
Fedora 20, for example) gets the configuration correct out of the
box, every time. It was not always like that, and anyone can
easily find many of my rants about PulseAudio problems in the ALE
archives and elsewhere on the 'net. But today, I appreciate the
fact that I can actually enjoy my music with it, without modifying
10 different config files to get the channels and upscaling
correctly mapped persistently across reboots.<br>
<ol>
<li>systemd is specific to the Linux kernel. It will not run on
Hurd, FreeBSD, NetBSD, or any other system. It therefore takes
full advantage of everything that Linux has to offer. That is
to say that Linux is one of systemd's four core dependencies.</li>
<ol>
<li>It uses cgroups, which allow it to ensure that processes
never escape their assigned trees.</li>
<li>It works to standardize certain aspects of the environment
which previously did not need standardization. With the
coming obsolescence of X11 (on Linux systems), being
replaced by the far more efficient and versatile Wayland,
having things like "seat" and "session" management provided
by the system is better.</li>
<li>It works to standardize individual user sessions, too. No
longer do you need things like a profile or xinit script.
You can have systemd --user start when you login, and
maintain things for you while you're logged in (and it can
be configured to do certain things only once, globally, such
as start a local daemon, terminating it upon the termination
of your last login session if you've multiple).<br>
</li>
</ol>
<li>systemd is as lightweight as desired. It depends on Linux,
glibc, libcap, and util-linux (satisfiable with busybox).
That's it. Pair a current systemd with Linux 3.17 or later
and the (optional) D-Bus requirement disappears entirely.</li>
<li>systemd makes rapid experimentation easy. 4 dependencies.
Use isolinux to boot from a CD, or use User-Mode Linux to
perform rapid experimentation in your own userspace.<br>
</li>
<li>systemd formalizes a lot of configuration that previously
was done any one of a million ways by different distributions
and subdistributions. And now that (nearly all) distributions
use systemd as the system manager, that knowledge is <i>truly</i>
portable. No longer are there (mandatory) huge low-level
differences between e.g., Debian and RHEL!</li>
<li>systemd makes administration very easy.</li>
<li>systemd is the first stepping stone to having a, IMHO, truly
secure environment to work in. It is aware of capabilities,
and integrates with PolicyKit. Add glue to allow SSH to be
used as a transport for inter-system management (actually, if
I'm not mistaken, systemd already provides that) and you can
now do a great deal either quickly or programmatically,
without having to move terribly much in the way of resources.</li>
<li>It's great for the so-called "DevOps" thing. Since service
configuration in /etc is now admin-controlled and not
partially controlled by the distribution, rsync deployment
becomes possible for far more classes of software than
previously possible. The distribution places unit files in
/usr/lib/systemd, and the host administrator (or host
administration agent software) can override everything, using
a similarly built tree in /etc/systemd.<br>
</li>
</ol>
<p>There's more to it, and it's versatile as well. The journal
mechanism provides functionality that is EXTREMELY useful for
both development and production troubleshooting, and is far
easier to work with than syslog, whether on just one system or
on multiple.<br>
</p>
<p>Below, my reply wherein I highlight just how lightweight a
systemd system can be—like the Linux kernel, which may be very
bloated (when you use a distro kernel, it usually is) or lean
(as you please), the systemd software can be configured to be
very slim indeed.<br>
</p>
On 09/05/2014 10:46 AM, Michael H. Warfield wrote:<br>
</div>
<blockquote
cite="mid:1409928393.5611.247.camel@canyon.ip6.wittsend.com"
type="cite">
<pre wrap="">Really. Look at the dependencies in systemd. Especially this one:</pre>
</blockquote>
Systemd itself (from upstream) has the following dependencies:<br>
<br>
(This is from the systemd README for systemd-216, the very latest
release):<br>
<pre> glibc >= 2.14
libcap
libseccomp >= 1.0.0 (optional)
libblkid >= 2.20 (from util-linux) (optional)
libkmod >= 15 (optional)
PAM >= 1.1.2 (optional)
libcryptsetup (optional)
libaudit (optional)
libacl (optional)
libselinux (optional)
liblzma (optional)
liblz4 >= 119 (optional)
libgcrypt (optional)
libqrencode (optional)
libmicrohttpd (optional)
libpython (optional)
libidn (optional)
gobject-introspection > 1.40.0 (optional)
elfutils >= 158 (optional)
make, gcc, and similar tools
During runtime, you need the following additional
dependencies:
util-linux >= v2.19 (requires fsck -l, agetty -s),
v2.21 required for tests in test/
dbus >= 1.4.0 (strictly speaking optional, but recommended)
sulogin (from util-linux >= 2.22 or sysvinit-tools, optional but recommended,
required for tests in test/)
dracut (optional)
PolicyKit (optional)
</pre>
Notice how most of those requirements are <i>optional</i>. This
includes libqrencode.<br>
<br>
A little while back, when the first major "fuck systemd, it's
bloated" holy war happened, the Debian project performed a <a
href="https://people.debian.org/%7Estapelberg/docs/systemd-dependencies.html">quite
complete analysis of systemd</a> showing that it's quite
worthwhile, comparing it with sysvinit and upstart.<br>
<br>
<blockquote type="cite">
<pre wrap="">Explain to me why in all of hades an init system needs QR codes?</pre>
</blockquote>
Let's find out, shall we?<br>
<br>
If you run the command <tt>for elf in $(rpm -qlR systemd|egrep
'^/usr/(s?)bin'); do ldd $elf | grep qrenco; done</tt>, you'll
find that exactly one instance exists; so let's see what that is:<br>
<pre>mbt@aloe ~$ for elf in $(rpm -qlR systemd|egrep '^/usr/(s?)bin'); do echo $elf; ldd $elf 2> /dev/null; printf '\n\n' ; done | grep -C7 qrenc
/usr/bin/journalctl
linux-vdso.so.1 => (0x00007fff8296d000)
librt.so.1 => /lib64/librt.so.1 (0x00007fe5bc2b1000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fe5bc08c000)
libgcrypt.so.11 => /lib64/libgcrypt.so.11 (0x00007fe5bbe0c000)
libacl.so.1 => /lib64/libacl.so.1 (0x00007fe5bbc03000)
libqrencode.so.3 => /lib64/libqrencode.so.3 (0x00007fe5bb9f6000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fe5bb7df000)
libc.so.6 => /lib64/libc.so.6 (0x00007fe5bb421000)
/lib64/ld-linux-x86-64.so.2 (0x0000003752c00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe5bb204000)
libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007fe5baffe000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fe5badfa000)
libattr.so.1 => /lib64/libattr.so.1 (0x00007fe5babf5000)
</pre>
It appears that the Journal has the <b>(<u>optional</u>)</b>
linkage against the QRencoder library. Why? Because this is a
feature that goes to support <b>Forward Secure Sealing journal
logging</b>. (I realize that this has already been pointed out.)<br>
<br>
As can be seen in the systemd README, this is an <u>optional</u>
dependency which allows systemd to display the QR code of the
verification key when the user runs "journalctl --setup-keys". It
displays the QR code <a
href="https://plus.google.com/photos/+LennartPoetteringTheOneAndOnly/albums/5778855891080167857/5778855890152395650?pid=5778855890152395650&oid=%2BLennartPoetteringTheOneAndOnly">right
on the terminal</a>.<br>
<br>
And this works on anything systemd works on—including your little
Raspberry Pi units—and comes nearly for free. And did I mention
that it is <b><i>optional</i></b>? Talk to Fedora or Red Hat if you
don't like the way they package it, or build systemd from source
yourself and create an RPM that you use. Put the blame where it's
due, and not where the very first thing points to.<br>
<br>
If you want to confirm this, you can build yourself a GCC with
--sysroot support and create, from source, a root filesystem that
comprises of linux, glibc, libcap, busybox, and systemd. Oh, shit.
I was wrong; you can't build a complete systemd system with 4
packages, it's 5 packages. Oops.<br>
<br>
Systemd is pretty damned nice, if you take the time to get to know
it. It <i>greatly</i> simplifies the stack, and has actually
improved the robustness of the systems that use it. <b>Creating a
test distribution that is bootable requires the five packages I
listed above, plus a boot loader.</b> It doesn't get easier or
simpler than that.<br>
<br>
Well, yes, it does. Don't use a boot loader and try everything under
an "ARCH=um" kernel.<br>
<br>
— Mike<br>
</body>
</html>