systemd is just wrong

Stop the madness before it is too late!

If you are a desktop linux user, especially if you like Gnome, there’s a big change (risk) that you are using systemd. Fine. No problem. Good for you.

If you however want to be in control of your server, enjoy flexibility and simple-to-grasp concepts, pretty much the essence of unix for the last 40+ years, you have probably come across an init or rc script that you can read and understand, as well as figure out how to replace it with something else. Perhaps when switching from sendmail to postfix.

Computers still get faster and faster, especially in parallel processing power, and operating systems, especially with a graphic desktop environment, get more and more complex. Thus it makes sense to utilise the increased processing power by doing more things  at the same time, thereby reducing start times.

Another aspect of the increased complexity in todays computer systems are that, partly thanks to the open source software movement, these complex systems are built much according to the unix philosophy: modularly. You take generic pieces of software that does something (and doing it well), and stick them together. This way you get much functionality, built on stable components, which is much better than in the closed-source version, where everybody reinvents the wheel, only with less quality.

How can I say that? Mostly because of very simple mathematical proof:

  • software takes time to write
  • time exists only 24h each day
  • the human brain can only focus on 1 thing at a time
  • bugs can be found in software
  • software is written by humans with brains

Because there are bugs in software, the less software (smaller codebase) there is, the fewer number of bugs it can contain. Smaller, less complex software pieces are more stable than big monoliths. Making changes in a big monolith is more difficult than changing the internals of a small tool/module with a clearly defined interface. The small module can be replaced/rewritten and exchanged with something that implements the same interface, without affecting the functionality of the complex system using it.

What is systemd?

A very bad idea in many ways, that looks appealing in some other ways.

Why is it bad?

Because it replaces /sbin/init, (PID EINS! as the author titles the pages on his nullpointer blog). PID 1, /sbin/init is the most important program in a unix system. It is responsible only for reaping zombies, being the parent process of daemons, and initially starting the system (hence the name “init”). This is the only special process in a unix system, and it is in fact so special that if this process dies, the entire system (the kernel) dies.

What do we know about bugs and code size/complexity? How would we want our most important process? Small and bug-free? Big and bloated? I’d like to say it’s your pick, choose what you like, but with systemd it’s not that simple, because it infects the major linux distributions, gaining momentum and requiring everybody that writes system-oriented open system software to adapt to systemd. After a while it will be too much trouble to maintain compatibility with traditional/portable solutions that have functioned very well for 40+ years now. Things that work on Solaris, BSD, Linux, OS-X that change to systemd, will be Linux-only, because systemd is linux-only, and will never be ported to other kernels.

Remember when Gnome was a desktop environment that you could run on Solaris and BSD? Well, no more. Gnome will have dependencies on systemd, meaning that because systemd always will be linux-only, so will Gnome.I’m late to the party, screaming about this now, many years too late, but it is IMPORTANT. Someone is wrong on the internet. Many before me have been upset about systemd and the many ways in which systemd is bad. There are lists detailing the top 5 systemd troubles, other good summaries on why systemd is bad for you. Some funnier than others, but I very much recommend reading all the linked pages from this post. Most of them are much more insightful and debating than what I can show in this short blog post.

duty_calls

Howto install perl modules

I often find myself trying to install (binary) packages that have dependencies to perl modules.

Because I work on varying platforms, sometimes RHEL/RedHat, CentOS, sometimes Debian based, like Ubuntu, and sometimes, less often now, but maybe I will go back again, to Gentoo. In many ways my ideal platform.

However, Perl is wicked, and the concept of perl modules in a package manager is even more crazy.

What are we going to do when we need a new version of a software (say, amavisd-new) that is not available in the distros package library?

I’m thinking, build from source and you can’t go wrong, right?

In the case of amavisd-new, these are the listed prerequisites:

Archive::Zip   (Archive-Zip-x.xx) (1.14 or later, currently 1.23)
Compress::Zlib (Compress-Zlib-x.xx) (1.35 or later, currently 2.008)
Compress::Raw::Zlib (Compress-Raw-Zlib) (2.017 or later)
Convert::TNEF  (Convert-TNEF-x.xx)
Convert::UUlib (Convert-UUlib-x.xxx) (1.08 or later, stick to new versions!)
MIME::Base64   (MIME-Base64-x.xx)
MIME::Parser   (MIME-Tools-x.xxxx) (latest version from CPAN - currently 5.425)
Mail::Internet (MailTools-1.58 or later have workarounds for Perl 5.8.0 bugs)
Net::Server    (Net-Server-x.xx) (version 0.88 finally does setuid right)
Digest::MD5    (Digest-MD5-x.xx) (2.22 or later)
IO::Stringy    (IO-stringy-x.xxx)
Time::HiRes    (Time-HiRes-x.xx) (use 1.49 or later, older can cause problems)
Unix::Syslog   (Unix-Syslog-x.xxx)
BerkeleyDB     with bdb library (preferably 4.4.20 or later)
Mail::DKIM     (Mail-DKIM-0.31 or later)

So, if I’m going to install amavisd-new, from souce, on a RHEL6 server, what do I need to do? -Well, I’ll show what I did. Not neccessarily what is the best thing to do… OK?

yum install cpan
perl -MCPAN -e shell

(going with the defaults, automatic is nice)

When I attempted to install the first module (Archive::Zip), I discovered that I did not have web access from my server, so I had to download the CPAN modules by hand. I did this by using the powerful http://search.cpan.org/ search tool, and just pasting the package name (Archive::Zip) in the search box and then downloading the tar.gz packages one at a time.

Manual installation of 1 CPAN package:

tar zxf Archive-Zip-1.31_04.tar.gz
cd Archive-Zip-1.31_04
perl Makefile.PL
make
make test
sudo make install

Had I had internet connection available:

perl -MCPAN -e 'install Archive::Zip'

The beauty of CPAN installation is that it resolves dependencies automatically.