Pour parler de Logiciels Libres en milieu professionnel... ou pas!

Aller au contenu | Aller au menu | Aller à la recherche

Pourquoi systemd?

Voici une traduction rapide de la page: why systemd?. Article très complet qui liste les avantages de systemd par rapport à ces "concurrents" directs. Très intéressant.

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 GnonME 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...

Commentaires

1. Le mardi, mai 3 2011, 15:00 par Fred

Page relatif à upstart sur Ubuntu:
"Why Ubuntu Should Continue with Upstart for 11.10"
http://undacuvabrutha.wordpress.com...

Robbie Williamson est impressionné par ce comparatif, qui oublie que Upstart... ça fonctionne!
En gros: c'est pas pour autant que faut passer de suite à systemd...
Ubuntu restera avec Upstart jusqu'à la 12.04 LTS, et systemd... on verra après ;-)

Fred

2. Le jeudi, mai 5 2011, 10:27 par aishen

Je trouve le nom chouette :
je fais partie de cette génération qui a inventé
à partir de la revue SYSTEME D
Donc je te souhaite autant de bonheur qu'avec l'autre ! :)

3. Le jeudi, mai 5 2011, 10:28 par Edouard

C'est clair que Upstart marche très bien, mais si on reste sur cette logique, Gnome, aussi, alors pourquoi Unity? etc. Surtout qu'il dit qu'ils veulent pas changer tout de suite pour 2 raisons, d'abord qu'en effet Upstart ça marche, et pis la 2e c'est qu'ils ont basculé dessus il n'y a pas longtemps, avec toute la gêne occasionnée pour les utilisateurs ils ont pas envie de recommencer. Mais pour l'instant, vu la compatibilité de systemd je suis pas super convaincu, c'est limite transparent pour l'utilisateur lambda (beaucoup plus que Unity ou Gnome3), la 1ere raison me semble donc la meilleure ;)

4. Le lundi, mai 9 2011, 05:07 par bochecha

@Edouard: "Mais pour l'instant, vu la compatibilité de systemd je suis pas super convaincu"

Systemd est compatible entierement avec SysV, mais pas vraiment avec Upstart.

Pour etre plus precis, les outils clients systemd sont capables de parler au daemon SysV, et le daemon systemd est capable de lancer des jobs SysV (les fameux init scripts).

En revanche, les outils clients systemd sont capables de parler au daemon Upstart, mais le daemon systemd n'est pas capable de lancer des jobs Upstart.

Fedora avait migre a Upstart, mais en utilisant les init scripts de SysV. La migration a donc ete tres simple, et on migre les jobs au fur et a mesure, quand on a le temps. :)

Ubuntu en revanche utilise les jobs Upstart, du coup s'ils veulent migrer a systemd, ils vont devoir tout migrer d'un coup, ce qui va entrainer une enorme charge de travail.

L'argument de Robbie Williamson n'est donc pas du tout infonde.

Lennart le dit lui meme (je cite la traduction ci-dessus) :
" 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."

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.

La discussion continue ailleurs

URL de rétrolien : http://www.linuxed.net/trackback/67

Fil des commentaires de ce billet