Traduction:
systemd est encore un projet jeune, mais il n’est plus un bébé maintenant. L’annonce initiale a été posté il y a exactement un an. Depuis, la plus part des distributions majeures ont décidé de l’adopter, d’une manière ou d’une autre, alors que des distributions plus petites l’utilisent déjà. La première distribution importante utilisant systemd par défaut sera la Fedora 15, pour la fin du mois de mai. On peut s’attendre à ce que les autres distributions suivent le mouvement un peu plus tard (avec une exception). Beaucoup de développeurs l’ont déjà adopté, et il y a même déjà une entreprise qui propose des services et une expertise spécialisés sur systemd. En bref, en un an systemd est devenu un projet prometteur.
Malgré cela, il y a encore des gens qui n’ont pas été convaincu. Si vous faites partie d’une de ces catégories, alors veuillez lire la comparaison des systèmes d’init qui va suivre:
- Vous travaillez sur des projets pour de l’embarqué, et vous vous demandez s’ils devraient être basés sur systemd.
- Vous êtes un utilisateur ou un administrateur et vous vous demandez quelle distribution choisir, et vous hesitez si elle doit être basée ou nonn sur systemd.
- Vous êtes un utilisateur ou un administrateur et vous vous demandez si votre distribution favorite utilisera systemd, même si tout marche déjà bien jusqu’à présent.
- Vous developpez une distribution qui n’a pas encore basculé sur systemd, et vous vous demandez s’il faut investir du travail pour basculer sur systemd.
- Et même si vous ne faites pas partie de ces catégories, vous pourriez trouver cette comparaison intéressante.
nonus allons comparer les 3 principaux système d’init utilisés sous Linux: sysvinit, Upstart et systemd. Bien sûr, il y a d’autres systèmes d’init qui existent, mais ils ne jouent virtuellement aucun rôle majeure dans le tableau. A moins que vous utilisez Android (qui est une bete à part de toute façon), vous avez surement déjà utilisé un des ces trois systèmes d’init sur votre nonyau Linux. (OK, ou busybox, mais alors grossièrement vous n’êtes pas en train d’utiliser un système d’init du tout). A moins que vous ayez un besoin exotique il n’y a pas besoin d’aller voir plus loin. Et aussi parce que je suis un peu paresseux, et que je ne veux pas passer du temps à analyser ces autres systèmes en détails pour être complètement honnête avec ceux-ci.
En parlant d’honnêteté, je suis bien sûr l’un des créateurs de systemd. J’essayerais de faire de mon mieux pour être juste envers les deux autres concurrents, mais au final, à prendre quand même avec des pincettes. Je suis sûr que même si je devrais être injuste ou d’une manière incorrect, quelqu’un le signalera dans les commentaires, donc n’hesitez pas à les lire aussi, avant de mettre trop de confiance dans ce que je dis.
nonus ne regarderons que les fonctionnalités déjà implémentées dans une version déjà disponible. Les fonctionnalités futures ne comptent pas.
Fonctionnalités générales
| sysvinit | Upstart | systemd | |
|---|---|---|---|
| Interface avec D-Bus | non | oui | oui |
| Démarrage sans Shell | non | non | oui |
| Services modulaires codés en C disponibles très tôt au boot |
non | non | oui |
| Read-Ahead | non | non[1] | oui |
| Activation basée sur surveillance de socket | non | non[2] | oui |
| Activation basée sur surveillance de socket: compatibilité avec inetd |
non | non[2] | oui |
| Activation évènementielle par surveillance d’un bus | non | non[3] | oui |
| Activation évènementielle par un matériel | non | non[4] | oui |
| Configuration des dépendances matériel avec des règles udev |
non | non | oui |
| Activation évènementielle par surveillance d’un chemin (inontify) |
non | non | oui |
| Activation basée sur un timer | non | non | oui |
| Gestion de mount | non | non[5] | oui |
| Gestion de fsck | non | non[5] | oui |
| Gestion des quota | non | non | oui |
| Gestion de automount | non | non | oui |
| Gestion de la swap | non | non | oui |
| Prise d’instantanés de l’état du système | non | non | oui |
| Support de XDG_RUNTIME_DIR | non | non | oui |
| Suppression optionnelle des processus restants quand un utilisateur se delogue |
non | non | oui |
| Intégration des Control Groups Linux | non | non | oui |
| Génération d’enregistrement pour audit des services démarrés |
non | non | oui |
| Intégration de SELinux | non | non | oui |
| Intégration de PAM | non | non | oui |
| Support des disques durs encryptés (LUKS) | non | non | oui |
| Gestion du certificat SSL ou du mot de passe pour LUKS, incluant Plymouth, Console, wall(1), TTY et les agents Gnome |
non | non | oui |
| Gestion du périphérique loopback pour le réseau | non | non | oui |
| Gestion de binfmt_misc | non | non | oui |
| Gestion de la localisation globale du système | non | non | oui |
| Configuration de la Console et du clavier setup | non | non | oui |
| Infrastructure pour créer, supprimer et nettoyer les fichiers temporaires et volatiles |
non | non | oui |
| Gestion de sysctl pour /proc/sys | non | non | oui |
| Intégration de Plymouth | non | non | oui |
| Sauvegarde/restauration d’un random seed | non | non | oui |
| Chargement statique des modules kernel | non | non | oui |
| Gestion automatique de la console série | non | non | oui |
| Gestion d’un identifiant unique de la machine | non | non | oui |
| Gestion dynamique du nonm d’hôte et des meta données de la machine |
non | non | oui |
| Arrêt fiable des services | non | non | oui |
| Enregistrements /dev/log très tôt au boot | non | non | oui |
| Démon minimal de syslog basé sur kmsg pour un usage embarqué |
non | non | oui |
| Relance sur plantage de service sans perte de connectivité |
non | non | oui |
| Mises à jour de service sans indispo | non | non | oui |
| UI graphique | non | non | oui |
| Outils et profilage intégrés | non | non | oui |
| Services instanciés | non | oui | oui |
| Intégration de PolicyKit | non | non | oui |
| Accès distant/Support Cluster intégrés dans les outils clients |
non | non | oui |
| Peut lister tous les processus d’un service | non | non | oui |
| Peut identifier le service d’un processus | non | non | oui |
| CPU Cgroups automatiques par service, pour contrôler l’utilisation CPU | non | non | oui |
| Cgroups automatiques par utilisateur | non | non | oui |
| Compatibilité SysV | oui | oui | oui |
| Services SysV contrôlables de la même manière que les services natifs | oui | non | oui |
| /dev/initctl compatible SysV | oui | non | oui |
| Re-exécution avec une sérialisation complète des états | oui | non | oui |
| Démarrage interactif | non[6] | non[6] | oui |
| Support des container (remplacement évolué de chroot()) | non | non | oui |
| Démarrage basé sur des dépendances | non[7] | non | oui |
| Désactivation de services sans éditer un fichier de configuration |
oui | non | oui |
| Masquage de services sans éditer un fichier de configuration |
non | non | oui |
| Arrêt du système robuste avec le PID 1 | non | non | oui |
| Support intégré de kexec | non | non | oui |
| Génération dynamique de service | non | non | oui |
| Support en amont depuis d’autres composants de l’OS |
oui | non | oui |
| Fichiers de service compatibles entre distributions | non | non | oui |
| Transmission de signaux vers services | non | non | oui |
| Arrêt fiable des sessions utilisateurs avec l’arrêt du système |
non | non | oui |
| Support de utmp/wtmp | oui | oui | oui |
| Fichiers de services facilement compréhensible, parfait pour la manipulation avec des outils de gestion |
non | non | oui |
¹ L’implémentation de Read-Ahead pour Upstart est disponible via un paquet séparé « ureadahead », nécessite un patch non standard sur le kernel.
² L’implémentation de l’activation par socket pour Upstart est disponible en tant que « preview », mais ne supporte pas la parallélisation et du coup rate complètement l’intérêt de l’activation par socket.
³ L’implémentation de l’activation par Bus pour Upstart disponible comme patch, pas encore intégré.
⁴ L’implémentation de l’évènementiel via udev sur les périphérique au niveau d’Upstart est disponible en tant que « preview », en transmettant intégralement la base udev, peu pratique.
⁵ L’utilitaire de gestion mount « mountall » pour Upstart est disponible dans un paquet séparé, ne couvrant que les montages lors du boot, avec un système très limité de dépendance.
⁶ Certaines distributions offrent cette implémentation dans le shell.
⁷ Les scripts d’init LSB supportent ceci, s’ils sont utilisés.
Réglages disponibles sur les services natifs
| sysvinit | Upstart | systemd | |
|---|---|---|---|
| Ajustement de l’OOM | non | oui[1] | oui |
| Répertoire de travail | non | oui | oui |
| Répertoire racine (chroot()) | non | oui | oui |
| Variables d’environnement | non | oui | oui |
| Variables d’environnement depuis un fichier extérieur | non | non | oui |
| Limitation des ressources | non | partiel[2] | oui |
| umask | non | oui | oui |
| Groupement des Utilisateurs/Groupes/Groupes supplémentaires | non | non | oui |
| Classe/priorité de l’ordonnancement des IO | non | non | oui |
| Valeur de nice pour l’ordonnancement CPU | non | oui | oui |
| Politique/priorité d’ordonnancement CPU | non | non | oui |
| Contrôle de la remise à zero de l’ordonnanceur CPU sur fork() | non | non | oui |
| Affinité CPU | non | non | oui |
| Timer Slack | non | non | oui |
| Contrôle des capacités | non | non | oui |
| Contrôle du bit de sécurité | non | non | oui |
| Contrôle des Control Groups | non | non | oui |
| Contrôle d’un espace de nommage de haut niveau sur le système de fichiers: rendre des répertoires inacessibles | non | non | oui |
| Contrôle d’un espace de nommage de haut niveau sur le système de fichiers: rendre un répertoire en lecture seul | non | non | oui |
| Contrôle d’un espace de nommage de haut niveau sur le système de fichiers: /tmp privé | non | non | oui |
| Contrôle d’un espace de nommage de haut niveau sur le système de fichiers: héritage de montage | non | non | oui |
| Entrée depuis la Console | oui | oui | oui |
| Sortie via Syslog | non | non | oui |
| Sortie via kmsg/dmesg | non | non | oui |
| Sortie sur un TTY donné | non | non | oui |
| Contrôle du signal Kill | non | non | oui |
| Exécution conditionnelle: par l’identification d’une virtualisation CPU /container | non | non | oui |
| Exécution conditionnelle: par la présence d’un fichier | non | non | oui |
| Exécution conditionnelle:: par un framework de sécurité | non | non | oui |
| Exécution conditionnelle: par ligne de commande kernel | non | non | oui |
1 Upstart supporte seulement le mécanisme obsolète oom_score_adj, pas l’actuel logique de oom_adj.
2 Upstart ne supporte pas RLIMIT_RTTIME et RLIMIT_RTPRIO.
A noter que certaines de ces options sont relativement faciles à ajouter aux scripts d’init de SysV, en éditant les sources shell. Le tableau au dessus ne cible que les options facilement accessibles qui ne demandent aucune modification du code source.
Autres
| sysvinit | Upstart | systemd | |
|---|---|---|---|
| Maturité | > 15 ans | 6 ans | 1 an |
| Services disponibles de la part d’ingénieurs et consultants spécialisés | non | non | oui |
| SCM | Subversion | Bazaar | git |
| Contribution sans Copyright | oui | non | oui |
Résumé
Comme les tableaux précédents le montrent clairement, systemd a laissé derrière lui sysvinit et Upstart dans la plus part des aspects. A l’exception de l’age/maturité du projet systemd gagne dans chaque catégorie. Maintenant, il sera très difficile pour sysvinit et Upstart de rattrapper les fonctionnalités que systemd fournit aujourd’hui. En 1 an, nous avons réussi à pousser systemd plus loin que Upstart a fait en 6 ans.
C’est notre intention d’être moteur dans le developpement de la plateforme Linux avec systemd. Dans le prochain cycle de sortie, nous nous concentrerons plus sur le fait de fournir les mêmes fonctionnalités et amélioration de rapiditié, que nous offrons déjà pour le système, sur l’ouverture de session utilisateur. Cela apportera une intégration plus proche avec les autres parties de l’OS et des applications, rendant la plus part des fonctionnalités que le gestionnaire de services fournit, en le rendant ainsi disponible aux sessions utilisateurs. Certains composants comme ConsoleKit seront rendus redondants avec ces améliorations, et les services s’appuyant sur ceux-ci seront mis à jour. Le fardeau de maintenir ces composants obsolètes reposera de fait sur les vendeurs/intégrateurs qui voudront continuer à s’appuyer sur ceux-ci.
SI vous vous demandez si vous devez adopter ou non systemd, alors systemd gagne quand il vient avec plus de fonctionnalité. Bien sûr cela ne devrait pas être le seul aspect à garder à l’esprit. Dans la longue course, s’attacher à l’infrastructure existante (comme ConsoleKit) à un prix: du travail de portage doit être fait, ainsi qu’un travail additionnel de maintenance. Le faire par vous même signifie une charge de travail accrue.
Cela dit, adopter systemd n’est pas non plus sans effort. Surtout si vous aviez fait des investissements sur les deux autres solutions, adopter systemd signifiera du travail. Le travail basique pour adopter systemd est relativement minime pour le porter sur des systèmes utilisant SysV (vu que la compatibilité est assurée), mais cela peut signifier un travail plus que substantiel quand il s’agira d’Upstart. Si vous cherchez à aller sur un système 100% systemd sans aucune compatibilité avec SysV (recommandé pour l’embarqué, la cible à long terme pour les grosses distributions), vous aurez besoin de pouvoir investir du temps pour convertir tous les scripts d’init vers les fichiers simples d’unité de systemd.
systemd est en phase de devenir une plateforme modulaire, intégrée et compréhensible, fournissant tout le nécessaire pour démarrer et maintenir un environnement utilisateur du système d’exploitation. Il inclut la ré-écriture en C de tous les scripts basiques d’init du début de la phase de démarrage, fournit par les distributions. Spécifiquement pour le cas de l’embarqué, adopter systemd vous fournira en une étape tout ce dont vous avez besoin, et vous pourrez choisir les modules que vous voulez. Les deux autres systèmes d’init ont des composants singuliers et individuels, qui pour être utiles nécessitent un grand nombre de composants additionnels pour décaler l’interfaçage. Le but principal de systemd à fournir une plateforme plutôt qu’un composant permet une intégration plus précise, et une API plus propre. Tôt ou tard, cela remontera jusqu’au niveau des applications. Déjà, il y a les spécifications XDG qui ont été acceptées (sur le basedir XDG, et plus spécifiquement sur XDG_RUNTIME_DIR), et qui ne sont pas supportées par les autres systèmes d’init.
systemd est aussi une belle opportunité pour la standardisation de Linux. Vu qu’il standardise un grand nombre d’interfaces du système qui était avant différentes sur chaque distribution, sur chaque implémentation, adopter systemd permettra de lutter contre la balkanisation des interfaces de Linux. Choisir systemd signifie redéfinir plus précisément ce qu’est la plateforme Linux. Ceci facilite le travail des programmeurs, des utilisateurs tout comme des administrateurs.
Je crois que le mouvement s’amorce clairement avec systemd. Nous vous invitons à rejoindre notre communauté et ainsi faire partie de ce mouvement.
EDIT: Il manquait la fin…