Sylvain Blandel a écrit 248 commentaires

Si seulement Lennart n’était pas si occupé à intégrer tout le reste du système dedans, il pourrait peut-être fiabiliser l’existant …

Oh putain, que c'est vrai ! 😄

D'après le wiki d'Archlinux, systemd gère (entre autres) le montage des systèmes de fichiers distants, et l'ACPI. Et il propose un équivalent à readahead.

Avant de s'occuper de tout ça, il me semble que systemd devrait déjà faire parfaitement son boulot : démarrer et arrêter le système, lancer et arrêter les services.

Attention, systemd n'est pas un remplaçant pour SysV init seul. SysV init, c'est le premier processus, qui lance […] notamment SysV rc

[…]

systemd est un remplaçant pour SysV init et SysV rc.

Y a-t-il un terme pour désigner l'association SysV init + SysV rc ?

Le terme SysV aurait convenu, mais il désigne déja un système d'exploitation. 😞

Si certains refusent systemd pour des raisons techniques il leur reste Debian (mais pour combien de temps encore …)

À l'heure actuelle, les distributions qui utilisent systemd par défaut sont :

• openSUSE depuis la version 12.1
• Mandriva depuis la version 2011
• Mageia depuis la version 2
• Fedora depuis la version 15
• Frugalware depuis la version 1.5

Archlinux utilisera bientôt systemd par défaut, de même que la future version 7 de Red Hat Enterprise Linux (d'après cette dépêche).

À l'heure actuelle, Debian, Ubuntu, Gentoo et Slackware n'utilisent pas systemd par défaut. L'utilisation de systemd par Debian semble improbable pour l'instant.

c’est quoi le problème si les autres distributions passent à systemd ?

Il me semble que systemd devient une solution générique pour l'initialisation du système et la gestion des services. Une distribution peut parfaitement se passer de cette solution générique, elle devra pour cela fournir un surcroît de travail (maintenir seule des trucs qui ne seront pas maintenu upstream).

ça sert à quoi ?

Sans l'option « x-systemd.automount » :

$ cd /media/sda8/sauvegardes
-bash: cd: /media/sda8/sauvegardes: Aucun fichier ou dossier de ce type

« Ah zut ! La partition sda8 n'est pas monté, il faut que la monte manuellement. »

Avec l'option « x-systemd.automount » :

$ cd /media/sda8/sauvegardes
(La partition sda8 n'est pas montée)
(Systemd monte la partition automatiquement)

$ pwd
/media/sda8/sauvegardes

Bien entendu, il est toujours possible de monter manuellement ses partitions avec la commande mount. De plus, les utilisateurs de systemd sont libres de ne pas utiliser cette option.

Les utilisateurs de systemd bénéficient de l'option x-systemd.automount pour un montage automatique des partitions.

Un extrait de mon fichier /etc/fstab :

/dev/sda7  /media/zaza  ext4  x-systemd.automount,…  0  2

Situation initiale : cette partition n'est pas montée :

$ mount | grep sda7
(Aucun retour)

Un programme souhaite accéder à cette partition (par exemple, le programme ls) :

$ ls /media/zaza
fichier1  fichier2  fichier3  …

Le contenu de la partition apparait ! La partition est maintenant montée !

$ mount | grep sda7
/dev/sda7 on /media/zaza type ext4 …

Que s'est-il passé ? Lorsqu'un programme a souhaité accéder au contenu de la partition, systemd a monté la partition automatiquement, sans intervention de l'utilisateur.

Plus d'info sur cette fonctionnalité sur le site de systemd : systemd.mount et systemd.automount.

un système qui ne boutait plus une fois à cause d'un /tmp en tmpfs saturé

Je ne comprends pas.

Si on met le /tmp en tmpfs, /tmp est vidé à chaque arrêt de la machine. Donc, lorsque l'on redémarre, /tmp ne peut pas être saturé : il ne contient rien au démarrage. Ce n'est pas cela qui bloquait le boot, non ?

Utilise e4rat et tu verras de l'inutilité de systemd en terme de performance au démarrage.

D'après le site du projet, e4rat supporte uniquement les systèmes de fichiers ext4. Systemd n'a pas cette contrainte.

C'est le comportement par défaut, du moins sous Archlinux. Je n'ai pas cherché, mais j'imagine que c'est configurable.

Effectivement, c'est configurable. Voir le site de systemd :

Question : I want to enable another getty, how would I do that ?

Answer : Simply place another symlink for instantiating another serial getty in the getty.target.wants/ directory.

ln -sf /usr/lib/systemd/system/serial-getty@.service /etc/systemd/system/getty.target.wants/serial-getty@ttyS0.service
systemctl daemon-reload
systemctl start getty@ttyS0.service

Note that gettys on the virtual console are started on demand. You can control how many you get via the NAutoVTs= setting in logind.conf(7).

Le mot « iLs » est curieusement capitalisé, ce qui ne m'évoque rien non plus.

Peut-être une référence a ce film : Ça - Il est revenu. Ce livre de Stephen King s'intitule « Ça », l'adaptation au cinéma s'appelle « Il est revenu ».

lancer, arrêter, relancer des logiciels pour répondre à des évènements logiciels ou matériels

Un exemple de ce mécanisme, que j'ai constaté sous Archlinux : le lancement des tty (les terminaux virtuels).

Lors du démarrage du système, le tty1 est lancé. En revanche, les tty[2-6] ne sont pas lancés. Le tty2 ne sera lancé que lorsque l'utilisateur appuiera sur les touches Ctrl+Alt+F2. De même, Le tty3 ne sera lancé que lorsque l'utilisateur appuiera sur les touches Ctrl+Alt+F3. Et pareil pour les autres.

C'est le comportement par défaut, du moins sous Archlinux. Je n'ai pas cherché, mais j'imagine que c'est configurable.

Une autre solution est de bricoler les fichiers de disposition des claviers :

Pour connaître le code des lettres accentuées, étudie une disposition de clavier qui contient les lettres accentuées. Par exemple, le fichier /usr/share/kbd/keymaps/i386/azerty/fr-latin9.map.gz

Ensuite, modifie le fichier de la disposition clavier que tu utilises. Pour une disposition dvorak US, j'imagine que ce fichier se trouve dans le répertoire /usr/share/kbd/keymaps/i386/dvorak/

Attention, ces fichiers sont des archives, de la forme machin.map.gz. Lorsque tu auras effectuer tes modifications, tu devras les remettre sous forme d'archive.

Bon plaisir ! :-)

Bonjour.

La commande xmodmap (que je n'ai jamais utilisée) pourrait convenir à ton besoin. Attention : les modifications réalisées avec xmodmap sont temporaires. Pour que tes modifications soient « permanentes », il sera nécessaire d'écrire un script (qui contient tes commandes xmodmap) et de lancer ce script chaque fois que tu te connectes à ta session.

Bon, je comprends ton argumentation. :-)

Ceci étant, puisque personne n'a répondu à la question initiale, je la repose :

Tout comme l'auteur de ce journal (qui y consacre un paragraphe entier), vous regrettez l'agonie du fichier rc.conf car celui-ci permettait, dans un unique fichier, d'administrer les points essentiels de le machine (le fuseau horaire, les démons à démarrer, les modules à charger, ceux à blacklister, …). Un seul fichier à gérer, c'était si simple !

L'auteur du journal qualifie d'ailleurs rc.conf comme étant « le fichier de configuration de ce qu'était Archlinux » ! Bigre, ce super-fichier-qui-centralisait-tout était vraiment important !

Hé les moules, quelle fut votre réaction en réalisant que, pour gérer vos partitions sous Archlinux, il vous faudrait éditer un autre fichier que le rc.conf ?

Vous pouvez moinsser si ça vous chante, mais répondez aussi à la question.

[le fichier rc.conf contient] les options de configuration du système (par opposition à la configuration de chaque logiciel indépendant).

Cet argument est pertinent pour certains des paramètres contenus dans le rc.conf, pas pour tous.

Par exemple, le réseau.

rc.conf contient des paramètres de configuration d'une seule et unique interface réseau. Est-ce que « une seule et unique interface réseau » est une caractéristique du système ?

Je pense que non, puisque certains systèmes ont plusieurs interfaces réseaux. La configuration de ses systèmes n'est pas possible par le rc.conf, ils nécessitent d'autres logiciels, avec d'autres fichiers de configuration.

Puisque personne ne me répond, je continue tout seul. :-)

Le fichier rc.conf contenait des options de configuration très variées sur le système. On y trouvait :

1. des informations sur le matériel : utilisation d'un RAID ou de LVM, pilotes de périphérique (modules) à charger.
2. des informations sur le réseau : le nom de l'interface réseau à utiliser, son adresse IP.
3. des informations sur les logiciels : la liste de démons à lancer.
4. d'autres trucs : le fuseau horaire, le clavier, etc.

Tant d'information de nature si différentes, qui n'ont rien à voir entre elles, et tout cela dans un même fichier ! Vraisemblablement, on aurait dû y ajouter la configuration des partitions, non ? Tant qu'à faire un fichier unique de configuration, pourquoi ne pas y mettre également la configuration des partitions ?

Franchement ?

Heureusement, cela n'a pas été fait. Mettre l'équivalent du fstab dans le rc.conf aurait peut-être faciliter la vie de l'utilisateur, mais cela aurait surtout compliqué terriblement le fonctionnement du système. Puisque tous les composants du système s'attendent à trouver la configuration des partitions dans le fstab, il aurait été nécessaire d'ajouter du « code d’interfaçage » pour que le système lise la configuration des partitions dans le rc.conf. Et cet ajout de code aurait compliqué le système.

Utiliser un fichier central de configuration simplifie la vie de l'utilisateur : tout est au même endroit. Mais cela a un inconvénient : tous les logiciels s'attendent à trouver les options de configuration à des emplacements bien définis, pas dans un fichier spécifique à la distribution. Pour que les logiciels s’accommodent de cette spécificité de la distribution, il faut ajouter du « code d'interfaçage » qui alourdit le système (et peut induire des bugs).

Il me semble qu'il y a eu une erreur d'interprétation sur la philosophie d'Archlinux : certains utilisateurs ont pensé que l'utilisation du système devait être simple, avec, notamment, un fichier unique de configuration. Or, c'est le fonctionnement du système qui se veut le plus simple possible, avec le minimum de code ajouté.

Bonjour.

on tire à bout portant sur /etc/rc.conf, le fichier de configuration de ce qu'était Arch linux. Il est malade depuis un bout de temps.

Beaucoup semble regretter la dépréciation du fichier rc.conf car celui-ci permettait, dans un unique fichier, d'administrer les points essentiels de le machine (le fuseau horaire, les démons à démarrer, les modules à charger, ceux à blacklister, …).

Si vous êtes dans ce cas, voici une question :

Sous Archlinux, la gestion des partitions n'a jamais été intégrée dans le rc.conf. En effet, tout ce qui concerne les partitions (points de montage, options de montage, …) est dans un autre fichier, pas dans rc.conf.

Quelle fut votre réaction en réalisant que, pour gérer vos partitions, il vous faudrait éditer un autre fichier que le rc.conf ?

à force de casser la gestion de la mise à jour tous les trois jours, on habitue l’utilisateur à faire un -f.

Tu utilises très souvent le paramètre --force ???

Dans mon cas : après 4 années d'utilisation quotidienne d'Archlinux, je n'ai utilisé le paramètre --force que trois fois (et la troisième fois, c'était en suivant les conseils de mise-à-jour).

Ceci étant, j'ignore de quelle façon tu utilises ton ordinateur, et quels logiciels tu as installé. 😊

Dans la dépêche, il y a un lien « scripts d'installation ».

pacmatic?

D'après la page de présentation, pacmatic correspond bien au souhait exprimé par plusieurs personnes :

Pacmatic is a small wrapper for Arch Linux's package manager, pacman. It takes care of a few menial tasks you should do every time before updating your system.
[…]
It helps you avoid four common mistakes. First, it adds a tiny RSS reader. The Arch Devs will routinely announce major compatibility breaks on the Arch feed, and it is stuff you really should see before updating.

Nous pouvons considérer ce problème réglé ! 😄

un système qu'il faut installer en suivant une doc, j'appelle pas ça simple.

Le fonctionnement du système se veut simple, cela n'implique pas obligatoirement que l'utilisation et l'installation du système soient simples.

Ceci étant, lorsque l'utilisateur a pris la peine d'apprendre le nécessaire (il faut faire des efforts), il jouit d'un système agréable à administrer.

Le mieux pour se faire une idée des « tendances » au sein de la communauté est de suivre les différentes listes de diffusion, donc arch-dev-public.

Merci.

Comme autre modification importante et récente, le répertoire /lib est devenu un lien symbolique vers /usr/lib (lien).

Bonjour.

Les développeurs d'Archlinux envisagent-ils de choisir systemd comme système d'init par défaut ? Ça semble le cas d'après ce commentaire. Auriez-vous des liens (de préférence en français) ? 😄

Pas mal de monde a eu du mal à faire passer la dernière maj (glibc). Si on faisait une mise à jour forcé bête et méchante (pacman -Syuf) on cassait le système assez lourdement.

Pour les mises-à-jour importantes ou risquées, une actualité est systématiquement publiée sur le site officiel (lien) et sur le site francophone (lien).

Ces actualités sont également consultables par les flux RSS ; en t'y abonnant, tu seras informé des trucs importants (le nombre d'actualités est raisonnable). 😊
Flux RSS officiel
Flux RSS francophone

D'ailleurs à quoi sert de démarrer dans un initrd si on ne dispose pas des outils pour le modifier? Car ces outils font partie du système auquel l'initrd appartient, non? Je suis peut-être complètement hermétique (ça m'arrive aussi) mais je ne mesure pas la pertinence d'une telle fonctionnalité, que je classerais dans les arguments purement marketing.

Je n'ai pas été clair concernant le « boot dans l'initramfs » ! :-)

En fait, tout se passe en mémoire vive.
Le chargeur de démarrage charge le noyau, puis décompresse l'initramfs en mémoire vive, et lance le système d'exploitation ainsi constitué (l'initramfs décompressée joue le rôle de partition racine). Tout se passe dans la RAM, il n'y a aucune écriture sur le disque. Le principe est identique à un live-CD : un système d'exploitation éphémère, lancé uniquement en mémoire vive, et qui n'écrit pas sur le disque.

Une fois que ce système d'exploitation est lancé, l'utilisateur peut s'il le souhaite monter une partition de son disque dur en lecture/écriture afin d'intervenir dessus.

Le « boot dans l'initramfs » est un outil de diagnostic et de réparation, pareillement à la clé USB que tu utilises. Avec, peut-être, un avantage : le noyau de ce système de secours est le noyau utilisé habituellement par le système à secourir. Il supporte donc exactement le même matériel, les mêmes périphériques, les mêmes technologies. Cela facilite les interventions.

un chargeur de démarrage n'est pas, AMHA, le bon outil.

Non, ce n'est pas le chargeur de démarrage qui modifie le contenu d'un disque ou d'un fichier. Le chargeur de démarrage lance un système d'exploitation, point. Une fois le système d'exploitation lancé, le chargeur de démarrage n'agit plus.

Dans le cas du « boot dans l'initramfs », le chargeur de démarrage lance le noyau linux (que tu lui indique) associé à une partition racine particulière : l'archive initramfs décompressée. Une fois ce système d'exploitation lancé, le chargeur de démarrage n'agit plus, et ton ordinateur est fonctionnel. Évidemment, les fonctionnalités de l'OS ne dépendent absolument pas du chargeur de démarrage utilisé, mais du noyau et du contenu de l'initramfs.

Et, comme le dit Zebra3, c'est l'utilisateur qui choisit de modifier des fichiers, certainement pas le chargeur de démarrage.