systemd, Part Deux

This is my first post here, and it's about systemd. Systemd is actually great, my big hope is that this goes to production and Alpine adopts it, because Systemd (is not an init system) and is actually because of it's monolithic architecture actually better for Linux systems that need a small footprint such as embedded, and such as Alpine wants to be.

Let me explain... The biggest complaints about systemd is:

1. It big and monolithic
2. It's not Unixy enough (a Unix process should do only one thing and do it good)

Easy to rebutt:

1. It's big and monolithic which in embedded might be desirebale, and things can be compiled away
2. Well, Linux is not Unix anyway, GNU is not Unix and it's not 1985. anymore. Interestingly, the biggest bunch of people complaining on "not Unix enough" are ZFS enthusiasts, and ZFS is a filesystem that is at the same time a Volume Manager (LVM has been in high production projects years before it appeard), a COW filesystem (again, LVM has been able to do it for years before with any FS), an NFS server (? this is my biggest what?? NFS was already working decades before, and was even made by the same company initialy - Sun), a soft RAID (while Linux md have been working happily also for at least a decade before), a caching layer (device-mapper cache was working way before) and I can't think of more features except that it eats heaps of your very expensive RAM (because, is you don't have ECC, your array will fail because of some simple bot flip, and when you tell about it on the forums, the answe will be "but you didn't use ECC RAM"). Now I went ranting about a project that does the same that systemd does to some people, bloats their system. The only difference is that the bloat is desirable for small systems. Let me exmplain, most people will removed about this:

• systemd implemented timers - what do we need that for when we already have cron - BLOAT
• systemd implemented systemd-timesyncd - what to we need that for when we already have ntpd - BLOAT
• systemd implemented socket activated services - what do we need that for when we already have inetd or xinetd - BLOAT
• systemd implemented nspawn - another container manager, when we already have docker, podman, this, that - BLOAT
• systemd implemented systemd-networkd - a network manager when we already have netplan.io, NetworkManager, Debian's terrible ifup/ifdown scripts, etc. it would need me pages and pages to list all
• systemd implemented systemd-resolved - a network resolver - why would we need that that we already have the one that comes with our network manager of choice, or at all

I'm sure I missed many, many features. These are the plus sides:

• we don't need a cron daemon idling most of the time just to run several scripts a day, most of all, we don't need another program (crond) running the entire time
• most systems require system time synchronization, but also they don't have to be a NTP server, like NTPD and chrony are. In that way, we don't have a single extra process on the system to be up-to-date
• we don't have additional progams like xinetd running the entire day just to execute another program (a service) when there's activity on some socket
• nspawn is, as you may discovered during development, an exelent service manager even possible to, for an example, boot an entire aarch64 rootfs on a x86-64 hots through a qemu-static binary. Nspawn is also extremely well integrated with other systemd components (systemd-networkd)
• systemd-networkd is a network manager which works great with other systemd components (systemd-resolved) but can work with others if need be
• systemd-resolved is a stub DNS resolver that works good with system-networkd, but can work with others or none at all
• other plus sides: actually excellent init manager, with great service definitions, no more incompatible init scripts between distributions. This is a great advantage: a vendor makes a service definition (after all, he knows best it's workings) and not the disributor.

After all talking about systemd doing more and more, in the end, with the right compile options, you can get a single daemon that does just what you want and nothing extra.

And as someone mentioned, more and more stuff will be moving to systemd so the effort needed to circumvent it will be increasingly greater, until it becomes impossible, so the best thing would be just to adopt it and focus all those efforts on the primary original goal the distribution had. Unless that goal was to make a distribution without systemd.