[ale] systemd or not

[Michael B. Trausch]

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...

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.

 1. 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.
     1. It uses cgroups, which allow it to ensure that processes never
        escape their assigned trees.
     2. 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.
     3. 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).
 2. 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.
 3. 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.
 4. 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 /truly/ portable. 
    No longer are there (mandatory) huge low-level differences between
    e.g., Debian and RHEL!
 5. systemd makes administration very easy.
 6. 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.
 7. 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.

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.

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.

On 09/05/2014 10:46 AM, Michael H. Warfield wrote:
> Really.  Look at the dependencies in systemd.  Especially this one:
Systemd itself (from upstream) has the following dependencies:

(This is from the systemd README for systemd-216, the very latest release):

         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)

Notice how most of those requirements are /optional/.  This includes 
libqrencode.

A little while back, when the first major "fuck systemd, it's bloated" 
holy war happened, the Debian project performed a quite complete 
analysis of systemd 
<https://people.debian.org/%7Estapelberg/docs/systemd-dependencies.html> 
showing that it's quite worthwhile, comparing it with sysvinit and upstart.

> Explain to me why in all of hades an init system needs QR codes?
Let's find out, shall we?

If you run the command for elf in $(rpm -qlR systemd|egrep 
'^/usr/(s?)bin'); do ldd $elf | grep qrenco; done, you'll find that 
exactly one instance exists; so let's see what that is:

mbt at 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)

It appears that the Journal has the *(_optional_)* linkage against the 
QRencoder library.  Why? Because this is a feature that goes to support 
*Forward Secure Sealing journal logging*. (I realize that this has 
already been pointed out.)

As can be seen in the systemd README, this is an _optional_ 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 right 
on the terminal 
<https://plus.google.com/photos/+LennartPoetteringTheOneAndOnly/albums/5778855891080167857/5778855890152395650?pid=5778855890152395650&oid=%2BLennartPoetteringTheOneAndOnly>.

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 */optional/*? 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.

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.

Systemd is pretty damned nice, if you take the time to get to know it.  
It /greatly/ simplifies the stack, and has actually improved the 
robustness of the systems that use it. *Creating a test distribution 
that is bootable requires the five packages I listed above, plus a boot 
loader.*  It doesn't get easier or simpler than that.

Well, yes, it does. Don't use a boot loader and try everything under an 
"ARCH=um" kernel.

     --- Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20140906/365cc869/attachment.html>