Fedora-Fr - Communauté francophone Fedora - Linux

Planet de Fedora-Fr : la communauté francophone autour de la distribution Linux Fedora

A propos

Cette page est actualisée toutes les heures.

Cette page est une sélection de blogs autour de Fedora. Fedora-Fr.org décline toute responsabilité au sujet des propos tenus par les auteurs des blogs de ce planet. Leurs propos sont leur entière responsabilité.

Le contenu de ce planet appartient à leurs auteurs respectifs. Merci de consulter leur blogs pour obtenir les licences respectives.

Mot-clefs : SysV

Pourquoi systemd?

Edouard Bourguignon

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 dinstantané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 linté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 some[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