Le carnet du grincheux

Le bloatware systemd ? A piece of shit, ni plus, ni moins.

Comprenez-moi bien, je ne suis pas contre l'évolution, mais l'évolution doit aller dans le sens du progrès. En aucun cas, l'évolution doit se justifier par elle-même surtout lorsqu'il s'agit de changer des mécanismes éprouvés par des trucs complètement délirants.

Je l'avoue, je suis un utilisateur de Linux. Après avoir fait mes débuts informatiques sur des systèmes de type VMS devenus depuis OpenVMS, j'ai touché à SunOS devenu Solaris et à d'autres Unix. J'ai toujours échappé à la merdouillique informatique microsofto-ouïndowzienne. Je ne vais pas jusqu'à dénigrer totalement Microsoft parce qu'il faut reconnaître que Xenix n'était pas le plus moisi des Unix.

J'ai attaqué Linux avec le noyau 1.0.9, ce qui ne nous rajeunit pas, avec des distributions RedHat puis, après un plantage complet d'un serveur lors d'une migration de RH 7.3 vers la 8.0 et plusieurs jours à triturer des fichiers binaires de configuration totalement cassés, avec Debian. J'en était relativement satisfait. Je dis relativement parce qu'en dehors des architectures mainstream comme le i386, l'amd64 et certains ARM, les autres architectures sont plus souvent cassées qu'à leur tour.

Aujourd'hui, je migre de plus en plus mes machines de travail vers FreeBSD. Pas activement, mais lors de réinstallation au gré de changement de matériel. Mes serveurs, quant à eux, tournent maintenant sous NetBSD. Les BSD restent cohérents et conformes à ce qu'est un système Unix. À savoir un système de base avec un noyau et des utilitaires sur lequel viennent des applications. Et l'organisation du système est propre, le système de démarrage carré. Il n'y a pas de surprise.

Le noyau Linux est devenu un grand bazar que plus personne ne maîtrise vraiment, même pas ses développeurs. Nous avons pu y voir un serveur http intégré dans le 2.2, des choses bizarres et inutiles au système de base comme systemd, hal et j'en passe.

Systemd est l'archétype de l'usine à gaz avec des fuites. Un énorme machin qui fait tout sauf son boulot correctement, qui utilise une configuration binaire au boot et qui est capable de planter sur des erreurs de segmentation lorsqu'il est en PID 1 sans autre forme de procès. Et le bougre ne se relance pas pour remttre le système dans un état minimal pour corriger le problème, ce serait trop facile. C'est propre, c'est bien moisi et, surtout, parfaitement irrécupérable lorsqu'on essaie d'installer une distribution Linux sur une carte processeur spécifique d'une architecture différente de celle de l'hôte sur lequel on a la faiblesse de travailler. C'est irrécupérable parce que le fichier core est inutilisable à moins d'avoir une distribution compilée avec les bonnes options de debogage et toute la chaîne de cross-compilation, debugger compris.

La question fondamentale est de savoir pourquoi un système de démarrage comme le SysV ou le BSD (ou tout autre système éprouvé) a dû être remplacé par un truc infect capable de mettre un système en vrac pour simplement gagner quelques secondes lors de ce démarrage. Pour toutes les machines que l'on ne redémarre pas quinze fois par heure, c'est très discutable voire risible. Et pour gagner ces quelques secondes en gérant les dépendances à-la-va-comme-je-te-pousse, on rajoute des concepts totalement abscons et incompréhensibles même par les développeurs. Je prétends que l'outil n'est pas compris par ses développeurs en raison des effets de bord que j'ai pu observer sur mes serveurs et des daemons de base qui n'arrivaient pas à démarrer proprement.

Mais cela ne fait rien, c'est un progrès et il faut y aller à marche forcée. Il faut y aller même si systemd est une bouse.

Pour mémoire, voici l'extrait d'un site web malheureusement en anglais (lien) :

1. 1. systemd flies in the face of the Unix philosophy: "do one thing and do it well," representing a complex collection of dozens of tightly coupled binaries. Its responsibilities grossly exceed that of an init system, as it goes on to handle power management, device management, mount points, cron, disk encryption, socket API/inetd, syslog, network configuration, login/session management, readahead, GPT partition discovery, container registration, hostname/locale/time management, and other things. Keep it simple, stupid.
   
   2. systemd's journal files (handled by journald) are stored in a complicated binary format, and must be queried using journalctl. This makes journal logs potentially corruptible, as they do not have ACID-compliant transactions. You typically don't want that to happen to your syslogs. The advice of the systemd developers? Ignore it. No, seriously. Oh, and there's embedded HTTP server integration (libmicrohttpd). QR codes are served, as well, through libqrencode.
   
   3. systemd's team is noticeably chauvinistic and anti-Unix, due to their open disregard for non-Linux software and subsequent systemd incompatibility with all non-Linux systems. Since systemd is very tightly welded with the Linux kernel API, this also makes different systemd versions incompatible with different kernel versions. This is an isolationist policy that essentially binds the Linux ecosystem into its own cage, and serves as an obstacle to software portability.
   
   4. udev and dbus are forced dependencies. In fact, udev merged with systemd a long time ago. The integration of the device node manager that was once part of the Linux kernel is not a decision that is to be taken lightly. The political implications of it are high, and it makes a lot of packages dependent on udev, in turn dependent on systemd, despite the existence of forks, such as eudev. Starting with systemd-209, the developers now have their own, non-standard and sparsely documented sd-bus API that replaces much of libdbus's job, and further decreases transparency.
   
   5. By default, systemd saves core dumps to the journal, instead of the file system. Core dumps must be explicitly queried using coredumpctl. Besides going against all reason, it also creates complications in multi-user environments (good luck running gdb on your program's core dump if it's dumped to the journal and you don't have root access), since systemd requires root to control. It assumes that users and admins are dumb⁵, but more critically, the fundamentally corruptible nature of journal logs makes this a severe impediment.
   
   6. systemd's size makes it a single point of failure. As of this writing, systemd has had 9 CVE reports, since its inception in March 2010. So far, this may not seem like that much, but its essential and overbearing nature will make it a juicy target for crackers, as it is far smaller in breadth than the Linux kernel itself, yet seemingly just as critical.
   
   7. systemd is viral by its very nature. Its scope in functionality and creeping in as a dependency to lots of packages means that distro maintainers will have to necessitate a conversion, or suffer a drift. As an example, the GNOME environment has adopted systemd as a hard dependency since 3.8 for various utilities, including gdm, gnome-shell and gnome-extra-apps. This means GNOME versions >=3.8 are incompatible with non-Linux systems, and due to GNOME's popularity, it will help tilt a lot of maintainers to add systemd. The rapid rise in adoption by distros such as Debian, Arch Linux, Ubuntu, Fedora, openSUSE and others shows that many are jumping onto the bandwagon, with or without justification. Other dependent packages include weston, polkit, upower, udisks2, PackageKit, etc. It's also worth noting that systemd will refuse to start as a user instance, unless the system boots with it as well - blatant coercion.
   
   8. systemd clusters itself into PID 1. Due to it controlling lots of different components, this means that there are tons of scenarios in which it can crash and bring down the whole system. But in addition, this means that plenty of non-kernel system upgrades will now require a reboot. Enjoy your new Windows 9 Linux system! In fairness, systemd does provide a mechanism to reserialize and reexecute systemctl in real time. If this fails, of course, the system goes down. There are several ways that this can occur. This happens to be another example of SPOF.
   
   9. systemd is designed with glibc in mind, and doesn't take kindly to supporting other libcs all that much. In general, the systemd developers' idea of a standard libc is one that has bug-for-bug compatibility with glibc.
   
   10. systemd's complicated nature makes it harder to extend and step outside its boundaries. While you can more or less trivially start shell scripts from unit files, it's more difficult to write behavior that goes outside the box, what with all the feature bloat. Many users will likely need to write more complicated programs that directly interact with the systemd API, or even patch systemd directly. One also needs to worry about a much higher multitude of code paths and behaviors in a system-critical program, including the possibility of systemd not synchronizing with the message bus queue on boot, and thus freezing. This is as opposed to a conventional init, which is deterministic and predictable in nature, mostly just execing scripts.
   
   11. Ultimately, systemd's parasitism is symbolic of something more than systemd itself. It shows a radical shift in thinking by the Linux community. Not necessarily a positive one, either. One that is vehemently postmodern, monolithic, heavily desktop-oriented, choice-limiting, isolationist, reinvents the flat tire, and just a huge anti-pattern in general. If your goal is to pander to the lowest common denominator, so be it. We will look for alternatives, however.
   
   12. systemd doesn't even know what the fuck it wants to be. It is variously referred to as a "system daemon" or a "basic userspace building block to make an OS from", both of which are highly ambiguous. It engulfs functionality that variously belonged to util-linux, wireless tools, syslog and other projects. It has no clear direction, other than the whims of the developers themselves. Ironically, despite aiming to standardize Linux distributions, it itself has no clear standard, and is perpetually rolling.

Mais puisqu'on vous dit que systemd, c'est le bien…