Sylvain Blandel a écrit 248 commentaires

La vidéo de la conférence Why Debian should (or should not) make systemd the default est disponible en ligne : basse qualité, haute qualité.

Deux autres conférences traitaient de systemd :

Making your package work with systemd.
Le diaporama de la présentation est disponible, de même que la vidéo (basse qualité, haute qualité)

systemd myths debunked !
Le diaporama de la présentation est disponible, de même que la vidéo en basse qualité.

Sur le site, les liens vers les vidéos sont incorrects. J'ai utilisé les bons liens pour ce post.

Le souci c'est qu'avec dd je vais avoir une image de la taille exacte du disque, c'est à dire 1 Tio non ?

Hum … je pense que oui. Ça va être embêtant.

Il me semble que tu t'es trompé dans l'utilisation de dd : le tutoriel n'utilise pas le disque /dev/sdb, mais la partition /dev/sdb1

Bonjour.

Effectivement, l'utilisation de dd pourrait être utile. Voir ce tutoriel : Récupérer les données d'un disque défectueux. Dans le tutoriel, la partition défectueuse est /dev/hda1 ; il faudra que tu remplaces cela par le nom des partitions de ton disque défectueux (/dev/sdb1, …).

Bon courage !

lorsque l'on programme, est-il possible de le faire "en aveugle"

Si tu estimes que les symboles de programmation sont mal placés, tu peux personnaliser ta keymap. Pour cela, deux possibilités :

1. La commande xmodmap

2. En modifiant directement la keymap. Sous Archlinux, les fichiers à modifier sont /usr/share/kbd/keymaps/i386/dvorak/fr-dvorak-bepo.map.gz (keymap pour les terminaux virtuels tty) et /usr/share/X11/xkb/symbols/fr (keymap de l'interface graphique). Sauvegarde puis modifie ces fichiers, puis fais-en une archive de même nom que l'original.

    

En procédant ainsi, j'ai intégré des smileys dans la keymap, pour les écrire directement. Cette page t'intéressera peut-être : Trucs et astuces sur bepo.fr.

Cet article du wiki t'intéressera peut-être : une introduction au contrôle du trafic réseau avec Linux.

Je fait des devis pour des pièces de rechange dans le ferroviaire.

Par hasard, tu ne travaillerais pas au Québec ?

quel est l'intérêt d'aller et venir entre console et X, vu que tu peux avoir un shell dans un terminal ?

Lorsque des logiciels « importants » de l'interface graphique doivent être mis à jour …

Hum … J'ai répondu à côté de la plaque.
Si on souhaite éteindre ces logiciels avant de les mettre à jour, on est obligé d'utiliser un tty (ce n'est pas un choix). Et il n'y a pas « d'aller et retour » entre le tty et X.

quel est l'intérêt d'aller et venir entre console et X, vu que tu peux avoir un shell dans un terminal ?

Lorsque des logiciels « importants » de l'interface graphique doivent être mis à jour (X, KDE, Qt, …), je préfère que ces logiciels soient stoppés durant la mise-à-jour. Dans ces cas-là, je ferme toutes les sessions graphiques, ainsi que le gestionnaire de connexion graphique lui-même. Et c'est depuis un tty que j'effectue les mises-à-jour.

cette manie des distribs de vouloir cacher les message de démarrages du noyau et des services au boot […] à chaque fois que je dois redémarrer une redhat ou une CentOS et que quelque chose se passe mal, je dois rebooter, interrompre le boot du grub, et modifier les options quiet et rhgb.

Sur les machines que tu administres, pourquoi ne pas supprimer définitivement les options quiet et rhgb dans le fichier de configuration de ton chargeur de démarrage ?

Concernant systemd : en cas de problème au démarrage, systemd peut ne démarrer que le strict minimum de services (c'est équivalent au runlevel 1 de SysV). Il suffit pour cela d'ajouter l'option systemd.unit=rescue.target à la ligne du noyau (pour être compatible avec l'existant, les alias single et 1 sont utilisables).

le code de systemd (intrinsèquement plus complexe, et testé sur une échelle infiniment moindre)

Comme systemd est utilisé (par défaut) par plusieurs distributions, la chasse aux bugs est mutualisée.

Je suis d'accord qu'un logiciel ayant plus de lignes de code a, potentiellement, des bugs plus nombreux, et je suis également d'accord que systemd est jeune. Mais il a un avantage : c'est un système d'init identique qui est utilisé par plusieurs distributions. Il y a ainsi plus d'utilisateurs susceptibles de découvrir ses bugs (par rapport à l'époque où chacune de ces distributions avait ses propres scripts d'init).

Sur redhat.com, on apprend que la version 7 de Red Hat Enterprise Linux utilisera systemd. L'entreprise Red Hat estime donc que systemd est suffisamment stable pour être lancé en production.

cela veut dire que même si les développeurs sont nombreux au final, la décision est faite par un seule personne (ou quelques uns) mais qui sont avec RH.

L'auteur principal de systemd a déjà répondu à ce point :

Myth: systemd is a Red-Hat-only project, is private property of some smart-ass developers, who use it to push their views to the world.

Not true. Currently, there are 16 hackers with commit powers to the systemd git tree. Of these 16 only six are employed by Red Hat. The 10 others are folks from ArchLinux, from Debian, from Intel, even from Canonical, Mandriva, Pantheon and a number of community folks with full commit rights. And they frequently commit big stuff, major changes. Then, there are 374 individuals with patches in our tree, and they too came from a number of different companies and backgrounds, and many of those have way more than one patch in the tree. […]

La réponse est très longue, elle est intégralement lisible dans le document The 30 Biggest Myths about systemd (c'est le mythe n°27, en bas de la page).

Pour revenir à l'argument avancé : l'employeur a toujours de l'influence sur ses employés. Si on suit l'argument, il faudrait que tous les « logiciels importants » soient développés par des personnes échappant à l'influence d'un employeur. Dans ce cas, comment ces développeuses/développeurs de « logiciels importants » gagneraient-ils leurs vies ?

Salut.

Utiliseras-tu Grub 1 ou Grub 2 ?
Grub 2 gère les disques partitionnés en GPT. J'ignore si Grub 1 le fait. Le reste de mon message est valable pour Grub 2.

---

j'utilise avant systemrescuecd et gparted
je choisis la table de partition gpt pour le disque système
je crée la partition non formatée de 1 mo pour le boot en début de disque
j'y ajoute le drapeau bios_grub

La méthode me semble bonne. Pour la partition en début de disque (sur laquelle tu mets le drapeau bios_grub), la taille de 1 Mo est peut-être juste. Chez moi, j'ai mis 32 Mo, mais j'ignore qu'elle est la taille minimale nécessaire.

au moment de l'installation du grub j'indique le chemin de cette partition de boot

Non, tu indiques seulement le disque (tu indiques /dev/sdX, et pas /dev/sdX1).

---

je voudrais savoir si des disques durs partitionnés en gpt et msdos peuvent bien cohabiter sur une machine

Je suppose que oui.

---

je sauvegarde mes partitions msdos avec partimage avant le changement de partitionnement
je repartitionne le disque système en gpt
pourrais je sans problèmes restaurer la totalité de mes partitions avec partimage sur ce même disque ?

Je ne connais pas partimage. Pour sauvegarder les données de mes partitions, j'utilise la commande cp -a :

# Pour faire la copie de sauvegarde :
cp  -a  /media/sdX3/*  /media/sdY4

# Pour restaurer les données :
cp  -a  /media/sdY4/*  /media/sdX3

Bien sûr, ceci est à adapter à ton schéma de partitionnement et au numéro de tes partitions.

je peux vous parrainer, vous gagnerez 60€ en tant que filleul

Vous aussi, vous gagnerez de l'argent. Sur le site internet de la banque en question, cette page mentionne une prime versée au parrain.

Ou-ouh ?
Freem ? T'es encore là ? :-)

Grub2 est devenu pénible à configurer, d'où mon passage à LILO

Arf ! 😄

Je me doutais un peu de ta réaction, mais c'est un choix réfléchi :)

N'y vois pas de malice de ma part, c'est juste que nos avis sont différents (et que j'adore utiliser les smileys en UTF-8 😞😐😊😄). Lorsque je l'utilisais, Lilo me semblait pénible à paramétrer car, pour modifier sa configuration, il fallait lancer un exécutable (le binaire lilo) après avoir modifié le fichier de conf. Je trouve Grub2 plus simple à paramétrer : on modifie le fichier de conf, on enregistre, point. La mauvaise réputation de Grub2 me paraît injustifiée.

Enfin, chacun ses besoins. Si Lilo te convient, tant mieux. 😊

Il me semble que, sous Debian, cron (et son copain anacron) sont installés par défaut,

Ça dépend.
Ils le sont si tu sélectionnes les outils de base lors de l'installation du système, mais il se trouve que c'est quelque chose que je ne fais plus depuis bien longtemps

C'est noté.

La quantité de RAM ne me semble pas avoir grand chose à voir avec la modernité par contre. Mais sa techno, si: la DDR3, ça va encore non? Il semble que la DDR4 soit prévue à la vente grand public pour 2015 après tout…).

Ça va m'être difficile de répondre, je suis un fossile, resté à la DDR2. 😊
Et effectivement, je voulais dire : la surconsommation de RAM causée par systemd me semble raisonnable, vu la quantité de RAM utilisée dans le matériel moderne.

Enfin bon, plutôt que de jouer avec les priorités des processus, le plus simple et le plus efficace reste de sélectionner des logiciels qui font ce qu'on leur demande, tout en étant moins gourmands.

Combien de temps passé à chercher les bons logiciels, à les tester, à les configurer ? Mais je reconnais que ta démarche permet d'apprendre, c'est plus instructif que de jouer avec la priorité des processus.

D'ailleurs, je me demande si cups+samba+sysVinit consomment autant que systemd seul? C'est une vraie question hein, vu que je n'utilise pas les 2 démons cités, je n'ai absolument aucune idée de leur consommation.

Je l'ignore. C'est vrai que, si systemd consomme 50 pour économiser 30, mon argument tombe à l'eau. 😊

je ne serais pas contre une solution de remplacement qui soit capable de lire les fichiers utilisés par systemd, mais qui n'apporte pas de dépendances dont je n'ai que faire. Et dont je ne suis manifestement pas le seul à n'avoir que faire: quand le sujet est abordé sur la ml de debian, je constate que je ne suis pas le seul a éprouver des réticences à installer dbus et autres truckit.

Lorsqu'il a conçu systemd, Lennart Poettering a choisi d'utiliser des briques déjà existantes : dbus, les truckit, etc. Conséquence de ce choix : systemd a de nombreuses dépendances. Si Lennart avait cloné toutes les briques nécessaires, et intégré ces clones dans le code de systemd directement, systemd n'aurait aucune dépendance aujourd'hui (ou très peu). Le package d'installation de systemd serait plus gros, mais systemd aurait exactement les mêmes fonctionnalités. Et aucune dépendance (ou très peu).

L'argument « systemd a trop de dépendances » n'existe qu'à cause des choix de conception de systemd : s'appuyer sur des logiciels existants, plutôt que de ré-inventer la roue.

Dans ta conception des choses, tu pourrais remplacer « systemd a trop de dépendances » par « Pour plus de lisibilité, le code de systemd est réparti entre plusieurs paquets à installer ».

D'ailleurs, une anecdote : systemd n'est plus dépendant de consolekit ! Dans la liste des dépendances de la version 202 de systemd, on ne trouve aucun truckit. Les fonctionnalités de consolekit ont été intégrées à systemd, dans un composant nommé systemd-logind. D'ailleurs, l'abandon de consolekit est confirmé sur la distribution qu'il ne faut pas nommer ☠

le truc ou faut avoir un OS fonctionnel pour réécrire le boot à chaque changement de config.

D'après mon expérience, ce n'est pas vrai. Il suffit d'éditer le fichier /boot/grub/grub.cfg et de le sauvegarder. Les modifications seront prises en compte au prochain démarrage. Ce fichier est évidemment accessible même si on démarre depuis un live-CD (je reconnais en revanche que la syntaxe du fichier est peu lisible).

Plusieurs distributions ont une politique regrettable de mise-à-jour de Grub2 : à chaque mise-à-jour, le script grub-mkconfig -o /boot/grub/grub.cfg est exécuté automatiquement, ce qui re-crée le fichier grub.cfg, et efface les modifications apportées par l'utilisateur. En conséquence, Grub2 se traîne une réputation déplorable : « les fichiers de conf sont à refaire à chaque mise-à-jour, c'est nul ! ». En réalité, c'est la politique de la distribution qui provoque ces ré-écritures du fichier grub.cfg.

Ce n'est pas le cas sur la distribution que j'utilise (et que je ne nommerai pas, tu m'accuserais de faire de l'auto-suggestion 😊 ). Lors des mises-à-jour de Grub2, le fichier grub.cfg n'est pas ré-écrit. L'unique moyen de modifier ce fichier de conf est une intervention manuelle et volontaire de l'utilisateur. Ainsi, les modifications que j'ai apportées à ce fichier ne sont pas écrasées lors des mises-à-jour.

LILO :)

Arf ! 😄

tu cites cron. Très bien, mais sur mes machines je n'utilise pas cron, je n'en ai pas l'utilité.

Il me semble que, sous Debian, cron (et son copain anacron) sont installés par défaut, et lancés lorsqu'on démarre dans le runlevel par défaut. Dans le répertoire /etc, pourrais-tu vérifier que les fichiers crontab et anacrontab ne sont pas vides ? De même, pourrais-tu vérifier que les répertoires cron.d, cron.hourly, cron.daily, cron.weekly et cron.monthly ne sont pas vides ?

Les logs de cron et d' anacron devraient être lisibles avec :

bibi@machine:$ grep -i cron /var/log/syslog*

Si je ne me trompe pas sur tous ces points, ça signifie que le fonctionnement d'une Debian nécessite le lancement de tâches selon des contraintes temporelles (que cette Debian soit utilisée comme serveur toujours allumé, ou comme machine de bureau). Ce lancement de tâches selon des contraintes temporelles, nécessaire au bon fonctionnement du système d'exploitation, peut être fait avec cron, ou avec systemd.

Nous parlons d'une surconsommation de RAM (de systemd par rapport à sysvinit) de 30 ou 40 Mo.

Sur la citation que tu as faite, je parlais d'une tendance générale dans l'industrie du logiciel, et pour être précis d'une tendance qui tends à m'exaspérer fortement, pas de systemd en particulier.

J'ai compris ton propos, et je disais juste que la surconsommation de RAM causée par systemd me semble raisonnable, vu le matériel moderne. Si un jour systemd consomme 400 Mo de RAM, je changerais d'opinion. 😄

quand j'utilisais GCC pour compiler autorealm, si je voulais utiliser mon CPU à fond (avec 4 thread donc) ma machine devenais complètement hors de contrôle pendant près de 15 minutes

Ce problème ne peut-il pas être réglé avec nice et son copain ionice ? Les deux sont cumulables, ça donne :

bibi@machine:$ nice -n19 ionice -c3 /usr/bin/processus-très-gourmand

De cette façon, les autres processus ne seront pas gênés pour accéder aux ressources, et ta machine ne sera pas hors de contrôle.

---

Il est possible d'économiser de la RAM grâce à systemd, en utilisant l'activation des services par socket ! Le principe est le suivant : un service est lancé uniquement lorsqu'on fait appel à lui, pas avant. L'opération est transparente pour l'utilisateur.

Une illustration : le service d'impression cups n'est lancé que lorsqu'une tâche d'impression est demandée (c'est un résumé, le lien donne plus d'explications).

Une autre illustration : les différents terminaux virtuels tty2 à tty6 sont lancés uniquement lorsque l'utilisateur appuie sur les touches Ctrl+Alt+F2 (ou Ctrl+Alt+F3, ou Ctrl+Alt+F4 …). Je l'ai vérifié sur ma machine, on peut voir les terminaux virtuels déjà lancés avec :

bibi@machine:$ ps -C agetty

Tant que je n'appuie pas sur Ctrl+Alt+F5, le tty5 n'est pas lancé. Pareil pour les autres.

Avec le traditionnel sysvinit, plusieurs services sont lancés au démarrage. Ces services ne seront peut-être pas utilisés aujourd'hui, mais ils sont lancés, et consomment des ressources, notamment de la RAM. Avec systemd et l'activation des services par socket, les services sont lancés uniquement s'ils sont appelés (par l'utilisateur, par un autre service, par un événement matériel …).

Attention : je doute que tous les services puissent être lancés en utilisant cette méthode, il existe certainement des cas où ce n'est pas possible ou souhaitable. Mais, dans les cas où c'est possible, cela permet d'économiser de la RAM. ;-)

Heu… faut juste que je trouve comment booter directement en runlevel 1 et je te dis ça :)

Si tu utilises grub, il faut rajouter single à la ligne kernel (lien).

Je ne sais pas trop interpréter ces résultats, mais si ton 72Mo viens de la 2nde ligne, alors je suis à 46Mo.

Oui, c'est bien ça. Pour interpréter le résultat de la commande free.

Je viens d'essayer sur une petite machine (un netbook) équipée d'un Go de RAM, et sur laquelle sont installés les deux systèmes d'exploitation :

• Debian Squeeze (32 bits, noyau 2.6.32),
• Archlinux (32 bits, noyau 3.7, systemd 202).

Debian démarrée en runlevel 1 consomme 14 Mo de mémoire vive, Archlinux démarrée en rescue.target consomme 28 Mo (tout ça sur la même machine).

tu es mieux à ce que ton système d'init ne bouffe pas 50 Mo inutilement

Systemd est plus qu'un système d'init : il gère en permanence les processus lancés. Contrairement à sysvinit, systemd est « actif » tout le temps (par exemple, pour remplacer cron et lancer des services selon des contraintes temporelles). Systemd consomme plus de mémoire vive que sysvinit ; c'est normal, il fait plus de choses.

qui consiste à dire qu'on se fiche de l'occupation mémoire des logiciels qu'on écrit parce que le client bah "il a qu'a acheter de la ram".

Nous parlons d'une surconsommation de RAM (de systemd par rapport à sysvinit) de 30 ou 40 Mo. Ce magasin en ligne propose 110 ordinateurs à l'achat. Parmi ces 110 machines, le minimum de mémoire vive est de 1024 Mo (ça ne concerne qu'une seule machine). Pour du matériel moderne, ça ne parait pas exubérant de remplacer sysvinit par un logiciel qui fait plus de choses, et qui ne consomme que 30 ou 40 Mo de plus.

Cette surconsommation de RAM pourra éventuellement poser problème sur certaines machines aux capacités très limitées (comme celle-ci). Dans ces cas-là, il faudra effectivement garder l'ancien sysvinit, ou utiliser un système d'exploitation plus léger, comme NetBSD ou FreeBSD.

De ce que j’ai compris : Debian/kFreeBSD était vaguement fonctionnel en 2004 mais n’était l’œuvre que de quelques développeurs isolés ; depuis 2011 ils profitent de l’infrastructure du projet Debian (machines de build et de test, etc…)

Si c'est bien le cas, ça signifierait que Debian/kFreeBSD est sur une pente ascendante : d'abord un projet confidentiel en 2004, puis une présentation au public en 2011. Et peut-être un support complet et officiel à la sortie de Wheezy ?

On dirait que la surcharge de travail de maintenir 3 kernels différents ne leur fait pas peur en tout cas.

J'ignorais que les contributeurs Debian maintenaient trois noyaux différents ! Effectivement, maintenir plusieurs systèmes d'init devrait leur être possible. 😄

Systemd est un logiciel trop complexe pour qu'on lui confie des tâches critiques

Je n'ai pas dis ça, ou en tout cas n'ai pas voulu le dire. J'ai voulu dire que systemd dépend de trop de logiciels,

En comparant la liste des dépendances de systemd et celles de sysvinit, on constate qu'effectivement systemd a bien plus de dépendances que sysvinit (sous Archlinux).

il semble aussi y avoir du monde pour l'utiliser dans l'embarqué, par exemple, et dans ces situations les ressources sont critiques: ajouter dbus (je garde cet exemple) juste pour pouvoir démarrer le système ne me semble pas trop acceptable.

Je viens de démarrer mon ordinateur sur la cible rescue.target de systemd (c'est l'équivalent du runlevel 1 de Debian : le strict minimum de service est lancé, et un unique terminal virtuel permet d'interagir avec la machine). Combien le système utilise-t-il de mémoire vive ?

bibi@machine:$ free -m

              total       used       free     shared    buffers     cached
Mem:          2005        115       1889          0         19         24
-/+ buffers/cache:         72       1932
Swap:          999          0        999

Le système utilise 72 Mo de mémoire vive après un démarrage en rescue.target. Il faudrait comparer avec la consommation mémoire d'une Debian en runlevel 1.

Concernant le manque de ressources sur les systèmes embarqués : aujourd'hui, même des appareils grand public comme des smartphones sont équipés de plusieurs centaines de Mo de mémoire vive, et de plusieurs Go de mémoire de stockage (un exemple). J'imagine que les appareils embarqués professionnels ont, au minimum, des caractéristiques techniques similaires. Si c'est bien le cas, ils n'auront pas de souci à utiliser systemd, malgré ses nombreuses dépendances.

Je pense que seul le fait de ne maintenir que systemd permets de réduire la charge de travail.

Oui. Tu exprimes ma pensée mieux que moi. 😊

Systemd me semble un outil très intéressant (sérieux, les scripts d'init sont horribles pour un néophyte) pour la facilité qu'il offre aux utilisateurs de contrôler leur système.

Oui, je suis parvenu à écrire un fichier .service pour systemd (lien), alors que je suis incapable de faire un script d'init. Les options de systemd ont des noms très explicites, ce qui facilite leur compréhension.

[Debian] est une distribution qui s'adresse à des gens qui aiment bidouiller eux-même ET qui visent la liberté et le choix. J'inclus la liberté par rapport aux licences, mais aussi par rapport aux tendances générales: les utilisateurs utilisant LILO ou n'ayant pas de DE ne sont pas rares sur la ml internationale.

C'est parfaitement exact : les utilisateurs de Debian aiment le choix, les utilisateurs de Debian sont heureux d'avoir des milliers de logiciels à leur disposition. Et les mainteneurs de Debian, qu'en pensent-ils ? Jusqu'à quel point autoriseront-ils le choix entre plusieurs solutions, sachant que cette multitude de solutions complique leur travail de maintenance ?

kFreeBSD est encore un peu jeune, mais j'ai bien l'impression qu'il attire pas mal de monde.

Oui, ça serait intéressant d'avoir le nombre d'utilisateurs de kFreeBSD. Peut-être est-il possible d'avoir une estimation en regardant les statistiques des serveurs qui distribuent les mises-à-jour ?

si systemd continue de rajouter des palanquées d'options, il sera devenu un bloatware. Pour Debian, se baser sur un bloatware ne sera pas acceptable: la distro qui se veut l'OS universel doit pouvoir marcher sur de vieilles machines.

C'est un argument qu'on entend souvent concernant systemd : « systemd est un logiciel trop complexe pour qu'on lui confie des tâches critiques ». Il se trouve que le noyau Linux est encore plus complexe que systemd. Avez-vous compté les lignes de code qui composent Linux ? Avez-vous compté les options de compilation d'un noyau Linux ? Linux est un logiciel beaucoup plus compliqué que systemd, et pourtant vous l'utilisez tous les jours ; chaque fois que vous allumez votre ordinateur, vous confiez au noyau Linux des tâches absolument critiques dans le fonctionnement du système d'exploitation. Et ça se passe bien. Il est donc tout-à-fait possible de confier des missions critiques à un logiciel extrêmement complexe : vous le faites tous les jours.

Puisque Debian utilise sur un logiciel aussi complexe que le noyau Linux (et que ça se passe bien), ça ne parait pas incohérent que Debian puisse également utiliser un autre logiciel complexe (systemd).

La mise par défaut n'augmentera donc pas la charge de travail.

Sur ce point, effectivement, je me suis mal exprimé. Disons plutôt que, pour une distribution, choisir systemd comme solution par défaut diminue le travail de maintenance de la distribution.

kFreeBSD existait déjà en 2004 : lien

Heu … cette page indique que Debian GNU/kFreeBSD a été publiée avec Debian 6.0 (Squeeze), c'est-à-dire en février 2011. Du coud, je ne sais pas quoi penser : de quand date la naissance de kFreeBRSD ?

Non, c'est la même charge de travail qu'avant systemd puisque plus ou moins chaque distribution importante a un init propre.

Effectivement, je me suis mal exprimé. Disons plutôt que, pour une distribution, passez à systemd (par défaut) diminue le travail de maintenance de la distribution.

il n'y a plus que Gentoo, Ubuntu et Debian qui résistent.

Et Slackware, pour l'instant.

utiliser un outil qui transforme automatiquement les « unité » systemd en script SysVinit quand c'est possible et de faire du travail spécifique uniquement quand c'est nécessaire.

Les fichiers .service de systemd proposent une palanquée d'options, qui sont listées dans les manuels de systemd.exec, de systemd.unit et de systemd.service.

Créer un tel outil (de conversion des fichiers .service en scripts SysVinit) sera un sacré travail. Sans oublier la maintenance de cet outil : systemd évolue vite, de nouvelles options apparaissent fréquemment.

Il faudra également compter sur « le travail spécifique » d'écriture et de maintenance des scripts SysVinit, pour les cas où l'outil de conversion sera inopérant.

Il me semble qu'aujourd'hui, pour les mainteneurs d'une distribution Linux, refuser l'utilisation de systemd par défaut implique une importante augmentation de leur charge de travail.

J'estime que systemd va gagner la partie, c'est-à-dire que, d'ici quelques années, il sera utilisé dans une écrasante majorité des distributions Linux. Pourquoi ? Pas forcément parce que systemd est mieux que l'existant, mais parce qu'il simplifie la vie de ceux qui ont le pouvoir : les mainteneurs des distributions.

Les utilisateurs de distributions auront beau avoir un avis différent des mainteneurs, ils ne sont que … des utilisateurs. Ce sont les mainteneurs qui décident de l'avenir de la distribution. Et systemd leur simplifie considérablement la vie.

Rendez-vous dans quelques années ! 😄

Qu'est-ce que tu appelle les distributions dérivée de Red Hat ? Si tu parle des clones, ça me semble une évidence.

Oui, c'est bien de ça que je parlais.

J'ai préféré faire une supposition, des fois qu'un clone de Red Hat choisisse de ne pas supporter systemd (ça me semble extrêmement improbable, mais sait-on jamais).

Une fois systemd utilisé par défaut sur Red Hat, il nous restera à voir le positionnement des contributeurs de Debian vis-à-vis de systemd :

• Accepteront-ils de maintenir les scripts relatifs au démarrage et à l'arrêt de l'ordinateur, alors que tout ce travail est mutualisé upstream par systemd, ce qui diminue la charge de travail des mainteneurs de distribution ?

• Accepteront-ils de maintenir les scripts (propres à Debian) de lancement des services, alors que systemd se propose de remplacer ces scripts par des fichiers .service (communs entre les distributions utilisant systemd), ce qui, là aussi, diminue la charge de travail des mainteneurs de distribution ?

• Le très jeune projet « Debian GNU/kFreeBSD » (sorti avec Debian Squeeze, en février 2011) justifiera-t-il de rejeter systemd comme solution par défaut ? Ce choix impliquerait, pour les contributeurs Debian, une plus grande quantité de travail : il faudrait en effet maintenir SysVinit/initscripts.

Bref, on verra. 😊

À ma connaissance, à part Arch et Fedora, peu d'autres distribs majeures proposent systemd par défaut ?

Listes des distributions utilisant systemd par défaut.

L'utilisation de systemd par défaut dans la version 7 de Red Hat Enterprise Linux est confirmée sur redhat.com. Il me semble probable que les distributions dérivées de Red Hat suivent le même chemin.