SystemD a été adopté par beaucoup de distribution sous la contrainte : l'intégration de Gnome (qui représente environ 50% des utilisateurs) nécessite soit le passage à SystemD, soit de patcher à mort Gnome, ce qui n'est pas aisé, soit de proposer plusieurs init system et activer SystemD quand l'utilisateur veux Gnome. C'était le choix de départ de Debian pour Jessie mais qui s'y est cassé les dents et à abandonné devant la surcharge de travail. Ce fut un véritable déchirement chez Debian qui a vu le départ de près d'un tiers de ses développeurs pour fonder des forks sans Systemd (Devuan en particulier, que j'utilise sur mes serveurs). Gentoo et Slackware ont juste choisi de se séparer des utilisateurs de Gnome et continuent de développer des alternatives aux composants de SystemD que les devs intègrent dans leurs softs, à savoir EUdev et ELogind.

Ce choix des développeur Gnome à été volontaire et très critiqué, ils sont d'ailleurs souvent les mêmes, encouragé par Red Hat qui a une forte volonté de standardiser Linux à leur sauce (qu'elle soit bonne ou mauvaise). C'est exactement la même technique qu'avec l'adoption générale de PulseAudio. Leur argument de l'indispensabilité d'une intégration toujours plus accrue de Systemd dans Gnome tient de moins en moins puisque aucun autre environnement de bureau n'a fait le choix de cette intégration et KDE propose au moins toutes les fonctionnalités de Gnome. Chez KDE le débat à eu lieu mais ils refusent d'exclure les autres Unix de l'offre KDE. Ils se sont contenté d'un module de configuration optionnel. XFCE et Mate ignore simplement l'init utilisés, ils n'ont pas besoin de le savoir.

Le simple fait que beaucoup de distribution se soit fait forcer la main ainsi en a irrité plus d'un, mais Systemd fait gueuler d'avantage encore à cause de sa criticité, de son inadaptation totale à certains besoin spécifiques (embarqué, serveurs critiques, etc...) alors qu'il est impossible de se passer d'un système d'init. Par opposition, PulseAudio je m'en passe très bien sur serveurs. Par ailleurs, de nombreux développeur Linux ont fait état de harcellement pour qu'ils intègre spécifiquement Systemd dans leur dépendance. Pour être en liens avec des devs de KDE, il y a eu pas mal de pression il y a une 10aines d'années dans les listes de diffusion, à coup de troll et de menaces, de la part de Red Hat notamment, mais aussi de fanboy Systemd inconnus.

Pour les reproches concret qu'on peut faire à Systemd, en dehors du mode d'adoption très discutable :
* Log binaire lisible qu'avec l'utilitaire systemd ad hoc ;
* Volonté d'obscurcir et de complexifier toute la base du système ;
* Vampirisation des services systèmes au profit d'implémentation Systemd à la sécurité très discutable (DNS, DHCP, NTP) et aux fonctionnement inadapté sur serveurs ;
* Conso RAM (moins de 1 Mo pour sysvinit, 80 Mo pour Systemd) ;
* Failles de sécurités innombrables alors que sysvinit en a 0 ;
* Difficulté de mise en oeuvre de script init personnalisé et maîtrise très difficile de la séquence de démarrage dans ce cas ;
* Comportement de l'équipe de développement qui refuse de corriger certains bugs et rejette la faute sur les utilisateurs et développeurs tiers (c'est l'objet de pétage de câble légendaire entre Torvald et Poettering) ;
* Le désir de contourner certaines limitation volontaire du noyau pour privilégier la fonctionnalité sur la sécurité/stabilité ce qui est criminel sur un processus aussi critique qu'init ;
* Pour avoir lu une partit du code (je travaille en ZRR, équivalent recherche du secret défense), il est dégueulasse, ce qui fait que dans mon labo les distrib basé sur Systemd sont très fortement déconseillées.

Répondre