Sylvain Blandel a écrit 258 commentaires

Bonjour.

Suite à la dépêche que j'ai publié récemment, les Éditions Eyrolles ont eu la gentillesse de m'offrir ce livre !

Un grand merci aux bénévoles qui s'occupent de LinuxFr, ainsi qu'aux Éditions Eyrolles. 😊

Remarque : la feuille scotchée en haut de l'écran est une carte du clavier Typematrix 2030, destinée à apprendre la configuration bépo. Vous la trouverez sur ce lien.

Je plaisantais, hein

Ah. 😊

J'en ai mis un moi-même. Il ne s'affiche pas, chez toi ?

Ton smiley s'affiche chez moi.

La page wikipédia contient les codes de plusieurs smileys. Pour ma part, j'ai intégré certains smileys dans la carte du clavier, pour les écrire directement. Voici un extrait du fichier /usr/share/X11/xkb/symbols/fr :

key <AC07> { [               t,            T,         U1F61E,          U1F610 ] }; // t T 😞 😐


key <AC08> { [               s,            S,        U1F60A,          U1F604 ] }; // s S 😊 😄

Comment est-ce que tu arrives à afficher des caractères-émoticon comme ça 😲 ?

J'utilise une police d'affichage qui prend en charge ces caractères, il s'agit de la police Linux Libertine. Après l'avoir installée, elle est disponible dans les polices d'affichage de Firefox.

😊

Ils ont migré sur systemd? ou ils sont toujours avec des technos périmées?

Toi, tu pêches à la dynamite ! 😄

Où est le problème à conjuguer cette expression à l'imparfait ?

Tout compte fait, tu as peut-être raison. Je ne vois rien qui interdit de conjuguer cette phrase à l'imparfait. C'est juste que la formulation me paraissait très laide.

C’est du plus que parfait pour le coup

Du conditionnel plutôt ? « Si je m'étais fait l'écho de ce sondage, alors j'aurais eu du karma. »

Sainte Merde, comment peut-on écrire comme ça ? 😞

Je m'étais fait l'écho Je me suis fait l'écho

c'est plus simple pour eux d'être plus proche de l'upstream

Je ne vois pas en quoi tu es plus proche de l’upstream.

Ce que je comprends : jusqu'à présent, les scripts initialisant le système d'exploitation étaient propres à chaque distribution ; chaque distrib' devait faire l'effort de les maintenir.

Sous Archlinux, ces scripts étaient /etc/rc.sysinit, /etc/rc.single, /etc/rc.multi et /etc/rc.shutdown.

À présent, pour les distributions utilisant systemd, ces scripts sont mutualisés. Cela allège le travail de maintenance de la distribution.

j’aurais préféré un truc du genre freedesktop

Le site officiel de systemd est hébergé sur freedesktop.org : http://freedesktop.org/wiki/Software/systemd/ 😄

quand on lit des trucs genre « on migre parce que la dépendance sur systemd et les outils associés va augmenter », ça fait peur!
[…]
Bon, ce n'est qu'un petit extrait, ailleurs, ce que je comprends c'est que « tout ce qui est reproché à systemd d'un point de vue technique n'est pas un problème ».

La lecture du long message (en anglais) de Tom Gundersen (le mainteneur de SysVinit dans Archlinux) est intéressante. Il précise plusieurs raisons techniques qui justifient, à ses yeux, l'adoption de systemd. Ça se passe sur ce lien (seule la seconde partie du message est pertinente, après le « Benefits »).

J'avais incorporé son message dans le corps de la dépêche, mais les modérateurs l'ont supprimé à la publication. 😞

Et comment s'occuper des services sans monter les filesystems ?

C'est juste.

Reste que systemd se propose de gérer l'ACPI, les logs ainsi que le readahead. À mon humble avis, systemd serait plus robuste s'il se contentait de son « cœur de métier » : démarrer et arrêter le système, lancer et arrêter les services.

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