Après tout ce démontage d'idées reçues, il est temps de remonter un peu
systemd est monolithique
Systemd est constitué de pleins, pleins pleins de binaires. Donc il n'est pas monolithique. Le fait que tous ces binaires sont fortement interdépendant n'a aucun rapport avec la choucroute. En plus dans sytemd chaque binaire effectue une tache bien définie, comme par exemple vérifier la config réseau, lancer le DHCP, simuler les connexions en attendant l'initialisation resynchroniser tout ça et balancer les résultats via DBus pour qu'il soit loggués. C'est une tache simple, fine et précise. Pourquoi ? Parceque nous avons le soucis de la sécurité, grâce à l'utilisation de bon nombre de technologies flaguées "experimental" dans le noyau nous arrivons à limiter grandement les droits dont un processus a besoin pour effectuer sa tache. Ainsi il suffit d'être ROOT pour arreter ou relancer un service, il suffit également d'être ROOT et dans la hiérarchie de plus haut niveau dans les CGroups pour pouvoir auditer un autre processus. De même en étant simplement ROOT on peut envoyer des signaux à un autre processus ou encore créer une nouvelle unit.
systemd a été conçu pour la vitesse
Pas du tout, systemd a été conçu principalement pour être propre. Comme il a été conçu et pensé intelligemment, il est en plus rapide - mais c'est juste un effet de bord de notre travail de réflexion. Ce quic ompte c'est que systemd soit super bien conçu, tellement bien conçu même que le des systèmes simples comme les logs ou le monitoring d'initialisation de périphériques n'ont entrainnés qu'une petite dizaines de bugs critiques au démarrage chacun.
La vitesse de systemd ne sert à rien pour les serveurs !
Pas du tout, déjà même sur les gros serveurs dont la partie matérielle du boot matériel peut durer plusieurs minutes, 10secondes de plus ou de moins ca peut changer la vie. Mais sur les VMs qui vont booter en quelques secondes quoi qu'il arrive et avec lesquelles ont peut faire des snapshot à chaud pour les mise à jour de toutes les façons, cette différence de trois secondes est encore plus cruciale. Sur un système qui contient plusieurs centaines de VM et qu'il faut redémarrer en urgence, ces trois secondes gagnées par VM au boot peuvent faire un total de 6 voire 8 secondes. Et puis le SAN est tellement content de voire 250 VM venir lui faire coucou dans un intervalle maximal de 2 secondes.
systemd est incompatible avec les scripts shell
Totalement faux, on peut parfaitement utiliser des scripts shell avec systemd. Du moment que ces scripts sont lancés avec les droits root, ne modifient pas l'environnement, restent cantonnés dans leur CGroup, ne cherchent ni à arréter ni à relancer le processus, et bien entendu ne cherchent pas à remonter une autre info que start, stop, reload aux units - tout ce passe très bien. (Enfin pour le premier script shell, si vous avez besoin que plusieurs scripts shells interragissent avec la même unit ca peut nécessiter l'écriture d'une autre unit, ou d'un wrapper ou les deux.)
systemd est compliqué
Alors là c'est n'importe quoi, en quoi un système qui s'appuie sur les capabilities, les cgroups, DBus, un nouveau système de log, un nouveau système de controle, un petit 500 variables kernel (dont 200+ spécifiques à Linux) le tout derrière une boite noire affreuseument simpliste, serait-il plus compliqué de lancer httpd avec l'utilisateur apache depuis un script shell ?
En plus au cas exceptionnel au systemd viendrait à vous causer des soucis, journald loggue l'ensemble des évènement de façon si claire et si concise que le kernel Linux arive presque à digérer le flux à tous les boot.
systemd n’est pas modulaire
Oui c'est le même sujet que plus haut dans la section "systemd est monolithique" mais j'écris tout d'une traite et ça me fait chier de me relire et de corriger quand je tape du texte aussi.
Donc systemd est modulaire, on peut désactiver pleins de trucs à la compilation ou à l'éxecution. Si vous le fait ca cassera surement le système, mais inutile de nous envoyer un mail pour vous plaindre - au mieux on vous répondra poliment qu'on s'en cogne. Dans systemd vous pouvez désactiver à la compilation les cgroups (mais ca casse le système) les capabilities (mais ca casse le système) passer sur une version plus ancienne de dbus (mais ca casse le système) ou encore activer le mode de compatibilité pour utiliser une libsystemd pas tout à fait synchrone avec la version de l'executable (mais...)
Bref si vous aimez linux 1.xx vous allez adorer systemd.
systemd est seulement pour les ordinateurs de bureau
Pas du tout, quand on a créer systemd on a penser à toute la gamme de produit basés sur Linux. Nous avons déjà vu ce que la vitesse de systemd apportait au serveur. Mais ce n'est rien à coté de ce que DBus+Journald logé en RAM au démarrage+les capabilites+la nécessiter de passer par systemd pour gérer les CGroups peuvent apporter au monde de l'embarqué.
systemd est un résultat du syndrome NIH
Le problème que nous avions avec notre précédent système d'init, Upstart (outre le fait qu'il ne marchait pas non plus) n'est non pas qu'il n'avait pas été inventé par Red Hat, mais qu'il avait été inventé par Canonical. Honnêtement un init inventé par Debian ou même Suse ca ne nous aura pas posé autant de problèmes. Mais là quand même....
systemd est un projet freedesktop.org
Et voilà, sous pretexte que vous êtes hébergés par freedesktop, que votre système se met à gérer toutes les notions d'ACPI, le login et de getty et que son auteur est principalement pour avoir fait deux démons purement orienté utilisateur final non professionnel - vous êtes catalogué tout de suite. Pas du tout si on a fini sur le site freedesktop.org, c'est juste parceque justine, la scrétaire du troisième connait vachement bien le gars qui change les tubes néons dans la salle serveur 4 de chez FreeDesktop. Tout de suite à se faire des idées les gens.
systemd n’est pas UNIX
D'un certains coté c'est vrai que l'on s'est un peu éloigné de la philosophie UNIX. Mais le fondamental de la philosophie UNIX est "avoir un sous système qui fait une seule chose et qui le fait bien", nous un a un macro système qui fait pleins de chose, mais que délègue à plusieurs modules qui eux font ... plusieurs choses aussi, d'accord, mais on est quand même proche de la philosophie UNIX. Quand même. En tout cas on s'en inspire. Par contre pour ce qui est de faire bien, je vous déjà dit à quel point on était bien conçu et rapide ?
systemd est complexe
Bonjour, veuillez regarder le bout de ce stylo s'il vous plait
FLASH
Bien sur que systemd est complexe, les ordinateurs aujourd'hui sont complexes - et comme on veut gérer l'ensemble du système de façon monolithique il est normale que ce soit compliqué et difficile à débugguer. Pour éviter les redondance on centralise les trucs avec des effets de bords WTF à la clef. Mais c'est normal !
Hop rebelotte stylo
FLASH
systemd est une usine à gaz
Mais pas du tout, avant pour lancer un service il suffisait d'avoir les droits sur l’exécutable et/ou le script concerné. Du coup n'importe qui pouvait lancer assez facilement des services sous réserve de ressources et de droits. Et bien c'est ca la vrai usine à gaz.
Nous on a un système centralisé ou pour lancer une copie d'un service qui tourne déjà avec d'autres paramètres il faut copier un template, le linker symboliquement, l'enregistrer, et finalement l'initialiser (éventuellement avec des scripts pre et post traitement) via des commandes DBus et/ou systemctl.
Pas la peine de nous remercier on aime rendre service.
systemd seulement pour Linux, pas sympa pour les BSD
systemd est un OS très différent de BSD. BSD utilise encore l'ancien système ou l'init du système sert principalement à initialiser le système puis à foutre la paix à l'admin. De part leur vision archaique ils ne peuvent pas être interressés par mon init, même si celui ci était portable, je suis sur qu'ils continueraient à me regarder avec des yeux et à me parler lentement.
systemd seulement pour Linux empêche son adoption comme système d’initialisation par défaut sur Debian
Dans le monde, ce sont toujours les gens intelligents qui cèdent. Je me fait pas de soucis, ils utiliseront systemd...
(N.B : C'est fait)
systemd pourrait être porté sur d’autres noyaux si ces mainteneurs le voulaient
On est tellement flexible, modulaire et léger que les autres systèmes seraient probablement incapables de copier les fonctionnalités simple et ciblées de systemd. Même partiellement. Honnêtement on ne peut pas porter systemd ailleurs.
systemd n’a pas de raison de ne pas être portable
On utilise partout et de façon centralisée pleins de fonctionnalités spécifiques Linux (mais en restant modulaire attention). Donc on est pas portable, centralisé, focalisé sur Linux exclusivement (mais modulairement ... Et en s'inspirant de la philosophie UNIX aussi)
systemd utilise des fichiers de configuration binaire
N'importe quoi, systemd utilise des fichiers de configuration texte qui ... Ah vous parliez de la configuration du comportement de systemd lui même, pas des units. Ben c'est encore plus n'importe quoi alors parce que le comportement systemd il est carrément codé en dur. Et toc !
systemd est un cauchemar de fonctionnalités
Vous pouvez penser ça aujourd'hui, mais dans 5 ans vous vous retourner et vous verrez qu'en fait il n'y avait pas tant de fonctionnalités que ça dans systemd à l'époque. En plus comme dit plus haut, vous pouvez désactiver pleins de fonctionnalités (mais ca casse votre système)
systemd vous force à faire quelque chose
Pas du tout, on est pas la mafia. Vous êtes libre de laisser votre ordinateur éteint ou de créer votre propre distrib. En plus il y a des promos sur les licences XP en ce moment. Vous êtes libres.
systemd rend impossible l’utilisation de syslog
Encore faux, systemd peut parfaitement renvoyer le contenu de journald sur syslog si vous tenez tant que ça à doubler les I/Os. J'ai dit doubler ? Mettez tripler en fait on a pas mal modifier la verbosité des logs avec notre nouveau systeme et c'est plutôt chiant à régler...
systemd est incompatible
Comme avec les scripts, du moment que vous avez les droits ROOT, que les fichiers sont là ou on vous à dit de les mettre et que vous respectez scrupuleusement les guidelines vous devriez être capables de lancer la plupart des services qui ne sont ni des sondes ni des outils de chiffrement.
Mais bon avec systemd on peut utiliser les unit d'une distribution sur une autre distribution. Je ne vois pas trop à quoi ca peut servir dans le monde professionnel ou la plupart des admins sérieux font des scripts d'init custom. Mais bon c'était très difficile à faire avant, donc on est assez fier.
systemd n’est pas scriptable, à cause de son utilisation de D-Bus
DBus est presque intégralement accessible par script depuis la plupart des clients (enfin des clients locaux) du moment que vous avez une fois de plus les droits ROOT. Donc argument invalide. Hop là, question suivante.
systemd requiert l’utilisation d’obscurs outils de configuration au lieu d’éditer des fichiers textes directement
Ce n'est pas vrai du tout. Vous pouvez éditer les fichiers de configs avec les outils que vous voulez. C'est pour qu'ils soient pris en compte que vous devez utilisez d'obscurs outils de configuration.
systemd est instable et bogué
Totalement faux, la liste bugtracker Fedora nous indique que nous avons assez peu de problèmes avec systemd. Si l'on exclu un certain Linus T qui commence sérieusement à nous casser les pieds avec ces menaces à peine voilées on est plutôt bien.
systemd n’est pas déboguable
En fait on a tellement peu de soucis que la page pour aider à débuguer systemd fait à peine quelques lignes et qu'elle a été mise à jour la semaine dernière (enfin la semaine d'avant ce texte, parceque depuis rien, que dalle, nada. Et ceci même alors que les saturations journald et les conflits udev ont fait crasher pas mal de machines au démarrage.)
systemd fait des changements pour le plaisir de changer
Très très mensonger. On évite les changement incompatibles autant que possible, mais malheureusement parfois l'ancienne solution n'est vraiment pas assez hype pour nos développeurs. En ce qui concerne l'ajout d'un serveur DHCP dans l'init, c'était obligatoires. Parceque des raisons.
systemd est un projet uniquement dirigé par Red Hat, une propriété privée de quelques développeurs je-sais-tout, qui l’utilisent pour servir leur vision du monde
Oh mon dieu, une attaque à mon orgueuil, vite une réponse de trois pages... Les grecs anciens n'avaient pas le concept du zéro ....
systemd ne gère pas l’utilisation d’un /usr séparé du répertoire racine
Non, nous on supporte très bien un /usr séparé. C'est Linux qui ne sait pas faire. D'ailleurs toutes les personnes qui fonctionnent avec /usr séparé, par exemple les techniques de doubles montages utilisé en pxeboot ou en /usr commun sur SAN ne marchent pas.
Mais sur systemd avoir un /usr séparé fonctionne très bien (sauf en double montage - mais que personne n'arrive à faire marcher. Je vous jure, si, si)
systemd ne permet pas de remplacer ses composants
Comme déjà vu plusieurs fois, vous pouvez remplacer à peu près n'importe quel composant de systemd, du moment que vous avez les droits ROOT, que vous remplacez avec des composants systemd plus récents et que vous n'avez pas peur de casser votre systeme.
L’utilisation de D-Bus dans systemd au lieu de sockets le rend opaque
Ahahaha. DBus utilise les sockets. Du moment que vous avez les droits root, une version custom de DBus avec tracages des paquets et la logique de désérialisation - ca n'est pas plus dur à suivre qu'un socket non DBus.
Promis j'ai commencé un vendredi, donc c'est autorisé.
# Le vendredi c'est permis.
Posté par Kaane . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 10.
Sommaire
Après tout ce démontage d'idées reçues, il est temps de remonter un peu
systemd est monolithique
Systemd est constitué de pleins, pleins pleins de binaires. Donc il n'est pas monolithique. Le fait que tous ces binaires sont fortement interdépendant n'a aucun rapport avec la choucroute. En plus dans sytemd chaque binaire effectue une tache bien définie, comme par exemple vérifier la config réseau, lancer le DHCP, simuler les connexions en attendant l'initialisation resynchroniser tout ça et balancer les résultats via DBus pour qu'il soit loggués. C'est une tache simple, fine et précise. Pourquoi ? Parceque nous avons le soucis de la sécurité, grâce à l'utilisation de bon nombre de technologies flaguées "experimental" dans le noyau nous arrivons à limiter grandement les droits dont un processus a besoin pour effectuer sa tache. Ainsi il suffit d'être ROOT pour arreter ou relancer un service, il suffit également d'être ROOT et dans la hiérarchie de plus haut niveau dans les CGroups pour pouvoir auditer un autre processus. De même en étant simplement ROOT on peut envoyer des signaux à un autre processus ou encore créer une nouvelle unit.
systemd a été conçu pour la vitesse
Pas du tout, systemd a été conçu principalement pour être propre. Comme il a été conçu et pensé intelligemment, il est en plus rapide - mais c'est juste un effet de bord de notre travail de réflexion. Ce quic ompte c'est que systemd soit super bien conçu, tellement bien conçu même que le des systèmes simples comme les logs ou le monitoring d'initialisation de périphériques n'ont entrainnés qu'une petite dizaines de bugs critiques au démarrage chacun.
La vitesse de systemd ne sert à rien pour les serveurs !
Pas du tout, déjà même sur les gros serveurs dont la partie matérielle du boot matériel peut durer plusieurs minutes, 10secondes de plus ou de moins ca peut changer la vie. Mais sur les VMs qui vont booter en quelques secondes quoi qu'il arrive et avec lesquelles ont peut faire des snapshot à chaud pour les mise à jour de toutes les façons, cette différence de trois secondes est encore plus cruciale. Sur un système qui contient plusieurs centaines de VM et qu'il faut redémarrer en urgence, ces trois secondes gagnées par VM au boot peuvent faire un total de 6 voire 8 secondes. Et puis le SAN est tellement content de voire 250 VM venir lui faire coucou dans un intervalle maximal de 2 secondes.
systemd est incompatible avec les scripts shell
Totalement faux, on peut parfaitement utiliser des scripts shell avec systemd. Du moment que ces scripts sont lancés avec les droits root, ne modifient pas l'environnement, restent cantonnés dans leur CGroup, ne cherchent ni à arréter ni à relancer le processus, et bien entendu ne cherchent pas à remonter une autre info que start, stop, reload aux units - tout ce passe très bien. (Enfin pour le premier script shell, si vous avez besoin que plusieurs scripts shells interragissent avec la même unit ca peut nécessiter l'écriture d'une autre unit, ou d'un wrapper ou les deux.)
systemd est compliqué
Alors là c'est n'importe quoi, en quoi un système qui s'appuie sur les capabilities, les cgroups, DBus, un nouveau système de log, un nouveau système de controle, un petit 500 variables kernel (dont 200+ spécifiques à Linux) le tout derrière une boite noire affreuseument simpliste, serait-il plus compliqué de lancer httpd avec l'utilisateur apache depuis un script shell ?
En plus au cas exceptionnel au systemd viendrait à vous causer des soucis, journald loggue l'ensemble des évènement de façon si claire et si concise que le kernel Linux arive presque à digérer le flux à tous les boot.
systemd n’est pas modulaire
Oui c'est le même sujet que plus haut dans la section "systemd est monolithique" mais j'écris tout d'une traite et ça me fait chier de me relire et de corriger quand je tape du texte aussi.
Donc systemd est modulaire, on peut désactiver pleins de trucs à la compilation ou à l'éxecution. Si vous le fait ca cassera surement le système, mais inutile de nous envoyer un mail pour vous plaindre - au mieux on vous répondra poliment qu'on s'en cogne. Dans systemd vous pouvez désactiver à la compilation les cgroups (mais ca casse le système) les capabilities (mais ca casse le système) passer sur une version plus ancienne de dbus (mais ca casse le système) ou encore activer le mode de compatibilité pour utiliser une libsystemd pas tout à fait synchrone avec la version de l'executable (mais...)
Bref si vous aimez linux 1.xx vous allez adorer systemd.
systemd est seulement pour les ordinateurs de bureau
Pas du tout, quand on a créer systemd on a penser à toute la gamme de produit basés sur Linux. Nous avons déjà vu ce que la vitesse de systemd apportait au serveur. Mais ce n'est rien à coté de ce que DBus+Journald logé en RAM au démarrage+les capabilites+la nécessiter de passer par systemd pour gérer les CGroups peuvent apporter au monde de l'embarqué.
systemd est un résultat du syndrome NIH
Le problème que nous avions avec notre précédent système d'init, Upstart (outre le fait qu'il ne marchait pas non plus) n'est non pas qu'il n'avait pas été inventé par Red Hat, mais qu'il avait été inventé par Canonical. Honnêtement un init inventé par Debian ou même Suse ca ne nous aura pas posé autant de problèmes. Mais là quand même....
systemd est un projet freedesktop.org
Et voilà, sous pretexte que vous êtes hébergés par freedesktop, que votre système se met à gérer toutes les notions d'ACPI, le login et de getty et que son auteur est principalement pour avoir fait deux démons purement orienté utilisateur final non professionnel - vous êtes catalogué tout de suite. Pas du tout si on a fini sur le site freedesktop.org, c'est juste parceque justine, la scrétaire du troisième connait vachement bien le gars qui change les tubes néons dans la salle serveur 4 de chez FreeDesktop. Tout de suite à se faire des idées les gens.
systemd n’est pas UNIX
D'un certains coté c'est vrai que l'on s'est un peu éloigné de la philosophie UNIX. Mais le fondamental de la philosophie UNIX est "avoir un sous système qui fait une seule chose et qui le fait bien", nous un a un macro système qui fait pleins de chose, mais que délègue à plusieurs modules qui eux font ... plusieurs choses aussi, d'accord, mais on est quand même proche de la philosophie UNIX. Quand même. En tout cas on s'en inspire. Par contre pour ce qui est de faire bien, je vous déjà dit à quel point on était bien conçu et rapide ?
systemd est complexe
Bonjour, veuillez regarder le bout de ce stylo s'il vous plait
FLASH
Bien sur que systemd est complexe, les ordinateurs aujourd'hui sont complexes - et comme on veut gérer l'ensemble du système de façon monolithique il est normale que ce soit compliqué et difficile à débugguer. Pour éviter les redondance on centralise les trucs avec des effets de bords WTF à la clef. Mais c'est normal !
Hop rebelotte stylo
FLASH
systemd est une usine à gaz
Mais pas du tout, avant pour lancer un service il suffisait d'avoir les droits sur l’exécutable et/ou le script concerné. Du coup n'importe qui pouvait lancer assez facilement des services sous réserve de ressources et de droits. Et bien c'est ca la vrai usine à gaz.
Nous on a un système centralisé ou pour lancer une copie d'un service qui tourne déjà avec d'autres paramètres il faut copier un template, le linker symboliquement, l'enregistrer, et finalement l'initialiser (éventuellement avec des scripts pre et post traitement) via des commandes DBus et/ou systemctl.
Pas la peine de nous remercier on aime rendre service.
systemd seulement pour Linux, pas sympa pour les BSD
systemd est un OS très différent de BSD. BSD utilise encore l'ancien système ou l'init du système sert principalement à initialiser le système puis à foutre la paix à l'admin. De part leur vision archaique ils ne peuvent pas être interressés par mon init, même si celui ci était portable, je suis sur qu'ils continueraient à me regarder avec des yeux et à me parler lentement.
systemd seulement pour Linux empêche son adoption comme système d’initialisation par défaut sur Debian
Dans le monde, ce sont toujours les gens intelligents qui cèdent. Je me fait pas de soucis, ils utiliseront systemd...
(N.B : C'est fait)
systemd pourrait être porté sur d’autres noyaux si ces mainteneurs le voulaient
On est tellement flexible, modulaire et léger que les autres systèmes seraient probablement incapables de copier les fonctionnalités simple et ciblées de systemd. Même partiellement. Honnêtement on ne peut pas porter systemd ailleurs.
systemd n’a pas de raison de ne pas être portable
On utilise partout et de façon centralisée pleins de fonctionnalités spécifiques Linux (mais en restant modulaire attention). Donc on est pas portable, centralisé, focalisé sur Linux exclusivement (mais modulairement ... Et en s'inspirant de la philosophie UNIX aussi)
systemd utilise des fichiers de configuration binaire
N'importe quoi, systemd utilise des fichiers de configuration texte qui ... Ah vous parliez de la configuration du comportement de systemd lui même, pas des units. Ben c'est encore plus n'importe quoi alors parce que le comportement systemd il est carrément codé en dur. Et toc !
systemd est un cauchemar de fonctionnalités
Vous pouvez penser ça aujourd'hui, mais dans 5 ans vous vous retourner et vous verrez qu'en fait il n'y avait pas tant de fonctionnalités que ça dans systemd à l'époque. En plus comme dit plus haut, vous pouvez désactiver pleins de fonctionnalités (mais ca casse votre système)
systemd vous force à faire quelque chose
Pas du tout, on est pas la mafia. Vous êtes libre de laisser votre ordinateur éteint ou de créer votre propre distrib. En plus il y a des promos sur les licences XP en ce moment. Vous êtes libres.
systemd rend impossible l’utilisation de syslog
Encore faux, systemd peut parfaitement renvoyer le contenu de journald sur syslog si vous tenez tant que ça à doubler les I/Os. J'ai dit doubler ? Mettez tripler en fait on a pas mal modifier la verbosité des logs avec notre nouveau systeme et c'est plutôt chiant à régler...
systemd est incompatible
Comme avec les scripts, du moment que vous avez les droits ROOT, que les fichiers sont là ou on vous à dit de les mettre et que vous respectez scrupuleusement les guidelines vous devriez être capables de lancer la plupart des services qui ne sont ni des sondes ni des outils de chiffrement.
Mais bon avec systemd on peut utiliser les unit d'une distribution sur une autre distribution. Je ne vois pas trop à quoi ca peut servir dans le monde professionnel ou la plupart des admins sérieux font des scripts d'init custom. Mais bon c'était très difficile à faire avant, donc on est assez fier.
systemd n’est pas scriptable, à cause de son utilisation de D-Bus
DBus est presque intégralement accessible par script depuis la plupart des clients (enfin des clients locaux) du moment que vous avez une fois de plus les droits ROOT. Donc argument invalide. Hop là, question suivante.
systemd requiert l’utilisation d’obscurs outils de configuration au lieu d’éditer des fichiers textes directement
Ce n'est pas vrai du tout. Vous pouvez éditer les fichiers de configs avec les outils que vous voulez. C'est pour qu'ils soient pris en compte que vous devez utilisez d'obscurs outils de configuration.
systemd est instable et bogué
Totalement faux, la liste bugtracker Fedora nous indique que nous avons assez peu de problèmes avec systemd. Si l'on exclu un certain Linus T qui commence sérieusement à nous casser les pieds avec ces menaces à peine voilées on est plutôt bien.
systemd n’est pas déboguable
En fait on a tellement peu de soucis que la page pour aider à débuguer systemd fait à peine quelques lignes et qu'elle a été mise à jour la semaine dernière (enfin la semaine d'avant ce texte, parceque depuis rien, que dalle, nada. Et ceci même alors que les saturations journald et les conflits udev ont fait crasher pas mal de machines au démarrage.)
systemd fait des changements pour le plaisir de changer
Très très mensonger. On évite les changement incompatibles autant que possible, mais malheureusement parfois l'ancienne solution n'est vraiment pas assez hype pour nos développeurs. En ce qui concerne l'ajout d'un serveur DHCP dans l'init, c'était obligatoires. Parceque des raisons.
systemd est un projet uniquement dirigé par Red Hat, une propriété privée de quelques développeurs je-sais-tout, qui l’utilisent pour servir leur vision du monde
Oh mon dieu, une attaque à mon orgueuil, vite une réponse de trois pages...
Les grecs anciens n'avaient pas le concept du zéro ....
systemd ne gère pas l’utilisation d’un /usr séparé du répertoire racine
Non, nous on supporte très bien un /usr séparé. C'est Linux qui ne sait pas faire. D'ailleurs toutes les personnes qui fonctionnent avec /usr séparé, par exemple les techniques de doubles montages utilisé en pxeboot ou en /usr commun sur SAN ne marchent pas.
Mais sur systemd avoir un /usr séparé fonctionne très bien (sauf en double montage - mais que personne n'arrive à faire marcher. Je vous jure, si, si)
systemd ne permet pas de remplacer ses composants
Comme déjà vu plusieurs fois, vous pouvez remplacer à peu près n'importe quel composant de systemd, du moment que vous avez les droits ROOT, que vous remplacez avec des composants systemd plus récents et que vous n'avez pas peur de casser votre systeme.
L’utilisation de D-Bus dans systemd au lieu de sockets le rend opaque
Ahahaha. DBus utilise les sockets. Du moment que vous avez les droits root, une version custom de DBus avec tracages des paquets et la logique de désérialisation - ca n'est pas plus dur à suivre qu'un socket non DBus.
Promis j'ai commencé un vendredi, donc c'est autorisé.