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
libseccomp >= 1.0.0 (optional)
libblkid >= 2.20 (from util-linux) (optional)
libkmod >= 15 (optional)
PAM >= 1.1.2 (optional)
liblz4 >= 119 (optional)
gobject-introspection > 1.40.0 (optional)
elfutils >= 158 (optional)
make, gcc, and similar tools
During runtime, you need the following additional
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/)
Notice how most of those requirements are /optional/. This includes
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
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
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)
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
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...