Sylvain Blandel a écrit 248 commentaires

Je ne comprends pas : sur le bépo non plus il n'y a pas de touche « ou », non ?

Au-dessus du «é»…

Je ne comprends pas ce que tu veux dire. Sur mon clavier bépo, au-dessus de la touche « é », il y a trois touches :

• la touche qui fait " 1 — „
• la touche qui fait « 2 < “
• la touche qui fait » 3 > ”

Je ne vois pas de touche qui, lorsqu'on appuie dessus, affiche la lettre « o » suivie de la lettre « u ».

Je ne crois pas avoir vu de touche « ou » sur l’azerty !

Je ne comprends pas : sur le bépo non plus il n'y a pas de touche « ou », non ?

Une licence sur un truc est, à mon avis, la liste des droits et des interdictions de l'utilisateur du truc. C'est-à-dire : ce que l'utilisateur a le droit de faire avec le truc, et ce qu'il ne peut pas faire avec le truc. Qu'est-ce que les utilisateurs peuvent faire avec une disposition de clavier libre qu'ils n'ont pas le droit de faire avec une disposition de clavier pas libre ?

Ma question est sincère.

Ah, un commentaire positif parmi tous les grincheux de Linuxfr ! :)

N'accorde pas trop d'importance aux grincheux. Ce n'est pas parce qu'ils grognent longtemps qu'ils sont nombreux :-) Et merci encore d'avoir fait intégrer le bépo dans kbd, cela va faciliter la vie de beaucoup de monde !

ayant aussi une disposition custom, j'aimerai savoir s'il n'y a pas moyen de faire autrement.

Pour ma part, j'utilise le programme xmodmap pour personnaliser la disposition bépo. Au démarrage de ma connexion graphique, la commande suivante est automatiquement lancée :

$ xmodmap /home/pikachu/.xmodmap.conf

Cela applique des règles de personnalisation du clavier qui surchargent celles du système. Le fichier /home/pikachu/.xmodmap.conf contient ceci :

! Smiley sous les touches C, T, S et N :
keycode 43 = c C NoSymbol NoSymbol copyright U0001F60D
keycode 44 = t T NoSymbol NoSymbol U0001F61E U0001F610
keycode 45 = s S NoSymbol NoSymbol U0001F60A U0001F604
keycode 47 = n N NoSymbol NoSymbol U2661 U2665

! Caractère # accessible directement avec AltGr+D :
keycode 31 = d D NoSymbol NoSymbol numbersign numbersign

! Le séparateur décimal est la virgule (au lieu du point) :
keycode 91 = KP_Delete comma NoSymbol NoSymbol period U202F period

Cette méthode ne nécessite pas de créer de fichier dans le répertoire /usr/share/X11/xkb/, il n'y a donc pas besoin des droits administrateur sur la machine pour personnaliser sa disposition de clavier. De plus, les mises-à-jour du paquet xkeyboard-config n'affecte pas cette méthode. En revanche, il est nécessaire que le paquet xmodmap soit installé sur la machine.

Plus d'infos sur xmodmap.

si Lennart réécrit une bonne partie des services pour qu’ils s’interfacent mieux avec systemd, pourquoi pas. […] Le problème avec une partie des autres, c’est qu’il faudrait en finir un avant d’en ajouter d’autres. Un automount suffisant sauf si on en a vraiment besoin, une gestion de l’ACPI suffisante sauf si on en a vraiment besoin, c’est quand même dommage. Autant en faire moins, mais les faire jusqu’au bout. […]

D’un côté, on a systemd qui remplace le système d’init en faisant aussi le café et la vaisselle, d’un autre, on a des services associés qui ne font que la moitié de leur boulot. Il ne sont pas à la hauteur.

C'est nouveau, ça vient de sortir : systemd proposera prochainement systemd-networkd pour gérer le réseau (plus d'explications par ici).

personne n’avait entrepris de contacter les développeurs du projet kbd.
Défi accepté.

Merci pour ton initiative !

J’ai donc recontacté le mainteneur, et les fichiers ont été à nouveau renommés : ce sont désormais les fichiers fr-bepo.map et fr-bepo-latin9.map, disponible dans la toute fraiche version 2.0.1 de xkb

kbd plutôt ?

Non, puisque là, on est sur les postes clients et qu’il n’est pas lancé.
C’est autofs qui est lancé et il est bien stoppé au bon moment… sauf qu’il reste parfois des répertoires encore montés derrière.

Si systemd s'obstine à « patiner pendant un certain temps dessus », l'option TimeoutStopSec=, placée dans le service qui patine, diminuera l'attente (mais ne résoudra pas le problème).

Le problème avec une partie des autres, c’est qu’il faudrait en finir un avant d’en ajouter d’autres. […] Autant en faire moins, mais les faire jusqu’au bout.

Entièrement d'accord sur ce point. J'utilise systemd pour remplacer cron, mais pour la gestion de l'énergie, je préfère utiliser le service acpid plutôt que systemd. Systemd veut faire trop de trucs, il se propose même de remplacer la commande mount. Par exemple, si vous avez un point de montage /media/data dans votre fstab, on peut remplacer

$ mount  /media/data
$ umount /media/data

par

$ systemctl start media-data.mount
$ systemctl stop  media-data.mount

La dépendance de plus en plus forte de Gnome envers systemd génère actuellement d'intenses discussions sur les listes de Debian.

Changer la priorité ne va pas tout du diminuer la charge, ça va juste permettre aux autres processus d'avoir plus de temps d'exécution mais au final, il aura toujours le problème des ventilateurs qui tourneront.

C'est parfaitement exact, nous sommes d'accord. Le changement de priorité permettra juste d'éviter que

journald sature les accès disque et le cpu

Autrement dit, l'ordinateur restera utilisable, même lorsque journald fera des opérations lourdes.

les pics d'utilisation CPU […] ont lieu dans journald lui même alors que je ne fais aucune requête utilisateur. […] journald sature les accès disque et le cpu.

Ah. J'avais mal compris.

Si les modifications proposées par Xavier Claude ne fonctionnent pas, tu pourras diminuer la priorité de journald pour accéder aux ressources (je viens d'essayer chez moi, ça marche) :

$ cat /etc/systemd/system/systemd-journald.service.d/personnalisation.conf 

[Service]
Nice=15
IOSchedulingClass=idle

Les paramètres Nice et IOSchedulingClass sont expliquées sur cette page.

Peut-être faudra-t-il faire de même avec les unités systemd-journal-flush.service et systemd-journal-gatewayd.service ?

j'observe très souvent journald qui prend 80% d'un de mes deux cœurs

Même constatation chez moi. C'est parce que journalctl affiche tous les logs enregistrés, qui peuvent remonter à plusieurs mois. journalctl -b n'affiche que les logs du boot actuel, la consommation processeur est alors infiniment moindre.

Il y a d'autres options pour afficher moins d'informations, et ainsi diminuer la consommation du processeur :

$ journalctl  --since=2013-09-27  --until=2013-09-30
$ journalctl  --since=yesterday
$ journalctl  --since=-2h

À noter que journald peut utiliser beaucoup d'espace disque (répertoire /var/log/journal et commande journalctl --disk-usage). On peut limiter cet espace disque en utilisant les bonnes options dans le fichier texte /etc/systemd/journald.conf. Chez moi, j'ai mis MaxRetentionSec=3week.

Systemd remplace (hormis le système d’init) l’automontage (mal), la gestion de la veille (sans fournir toutes les fonctionnalités non plus), les journaux système …

→ Systemd propose une alternative à autofs (avec l'option x-systemd.automount à ajouter dans le fstab). Si cette solution ne satisfait pas ton besoin, libre à toi de ne pas l'utiliser, et de préférer autofs.

→ Systemd se propose de gérer la mise en veille. Si tu préfères qu'il ne le fasse pas, voici comment faire : avec un éditeur de texte, modifie le fichier /etc/systemd/logind.conf, et utilise les options suivantes :

• HandlePowerKey=ignore
• HandleSuspendKey=ignore
• HandleHibernateKey=ignore
• HandleLidSwitch=ignore

Bien entendu, tu peux utiliser le traditionnel démon acpid pour gérer la mise en veille, l'hibernation, etc.

→ Systemd centralise les journaux système, et tu peux utiliser syslog qui écrira les logs dans des fichiers texte.

Bref : que ce soit pour l'automontage, la gestion de l'énergie ou le format des logs, l'utilisateur a le choix.

---

À l’opposé, sur un serveur, le démarrage parallélisé, voire à la demande, rend plus difficile de vérifier que tous les services ont démarré correctement.

Pour vérifier qu'un service a bien démarré :

journalctl  --unit=reseau.service  --all

Pour déboguer :

journalctl  --unit=reseau.service  --all  --follow

Les mêmes options, en version courte :

journalctl  -u reseau.service  -a  -f

Si le lancement d'un service à la demande ne répond pas à ton besoin, tu peux lancer ce service automatiquement au boot :

ln -s  /usr/lib/systemd/system/machin.service  /etc/systemd/system/multi-user.target.wants/

Si le démarrage parallélisé des services ne répond pas à ton besoin, tu peux personnaliser les fichiers .service pour imposer un ordre de démarrage :

$ cat /etc/systemd/system/truc.service.d/personnalisation.conf

[Unit]
# truc.service doit être lancé après machin.service :
Requires=machin.service
After=machin.service

---

Il arrive que des points de montage NFS restent après l’arrêt du réseau

Ah.
Peut-être avec en personnalisant nfsd.service ?

$ cat /etc/systemd/system/nfsd.service.d/personnalisation.conf

[Unit]
# nfsd.service doit être *lancé après* reseau.service,
# et *stoppé avant* reseau.service :
Requires=reseau.service
After=reseau.service

Au démarrage, reseau.service sera d'abord lancé, puis ensuite nfsd.service. Et à l'extinction, nous aurons l'ordre inverse : nfsd.service sera stoppé le premier, puis ensuite reseau.service sera stoppé (comme expliqué sur ce lien).

Fini les commandes tail -f /var/log/messages

Oui et non.
Les logs générés par journald sont des fichiers binaires ; pour autant, il est parfaitement possible d'utiliser syslog avec systemd. Voici comment faire :

1. Installez syslog (chez moi, syslog-ng)
2. Demandez le lancement automatique de syslog-ng au démarrage, avec la commande systemctl enable syslog-ng.service
3. Pour que journald redirige les logs vers syslog, ajoutez l'option ForwardToSyslog=yes dans le fichier de configuration /etc/systemd/journald.conf (ce fichier de configuration est un fichier texte, comme tous ceux contenus dans le répertoire /etc/systemd/).

Au démarrage suivant, le répertoire /var/log/ contiendra les fichiers habituels générés par syslog :

• daemon.log
• everything.log
• messages.log
• user.log
• errors.log
• auth.log
• kernel.log
• syslog.log

Tous ces fichiers sont des fichiers texte. Je viens d'essayer un

tail -f /var/log/messages.log

et ça fonctionne : les nouveaux évènements du système s'affichent en temps réel.

Si au moins on avait des arguments, là on pourrait discuter, mais là, c’est vraiment du troll pur et simple.

Effectivement. Autant l'entretien est intéressant, détaillé et bien écrit, autant la réponse à cette dernière question est bâclée. C'est dommage, l'opinion argumentée d'un développeur *BSD sur systemd est certainement intéressante à connaître.

Confirmation : le support de Red Hat Enterprise Linux est de 10 ans, et peut s'étendre jusqu'à 13 ans.

Avec support pendant 10 ans de la même version du noyau ?

Je l'ignore. J'imagine mal, vu le nombre de clients qui utilisent leurs produits pour des applications critiques, que Red Hat prenne le risque de changer la version du noyau en cours de route.

Le support natif de systemd par chaque package qui propose des scripts SysV

Actuellement, la plupart des paquets Debian sont uniquement prévus pour SysV. Si systemd est actif, il vient alors surcouche. L'objectif est de fournir systématiquement, en plus de la configuration et du script shell pour Sysv, une configuration et un exécutable ELF pour systemd.

D'après cette page du wiki Debian, il s'agirait, pour chaque paquet qui fournit un script dans le répertoire /etc/init.d, de fournir également un fichier .service dans le répertoire /usr/lib/systemd/system/

L'objectif semble atteignable : plusieurs distributions sont déjà passées à systemd. Les mainteneurs Debian peuvent s'inspirer (voir copier-coller) les fichiers .service des autres distributions. Cette possibilité est d'ailleurs clairement envisagée par un mainteneur Debian :

Adding a service file and dh-systemd support
[…] Then, search for a service file, either upstream or in other distributions such as Arch Linux, Fedora, Gentoo, etc. In case there is no service file yet, write one.

D'ici le gel de Debian 8, la version 7 de Red Hat Enterprise Linux aura vu le jour, et elle utilisera systemd par défaut. Les fichiers .service de RHEL 7 seront également une source d'inspiration pour les mainteneurs Debian.

si une API survit et s'avère utilisée, elle mérite que l'on s'y intéresse. Si elle crève dans son coin, on aura bien fait de ne pas s'y intéresser.

Et si elle survit parce que tu as utilisé cette API pour créer des technologies innovantes, pertinentes et efficaces ? Bin non, vu que tu n'auras rien fait, « l'interface n'était pas raisonnablement figée, alors j'attendais ». Tu laisses les autres décider quelles seront les technologies dominantes de demain.

La version 7 de Red Hat Enterprise Linux utilisera systemd, et systemd dépend des cgroups. Sachant que la maintenance de Red Hat Enterprise Linux peut s'étendre jusqu'à 13 ans, l'existence des cgroups me semble garantie pour quelques années

Gnome utilise certaines API de systemd mais ce sont des API qui peuvent être implémenter par n'importe quel système d'init, et Canonical les porte sur Upstart.

Il semble que tu as raison. Sur le wiki de Gnome, il est écrit :

the creation of the GNOME desktop experience […] focuses on a tightly-integrated desktop environment based on the GNOME Shell running on a GNU-based operating system with a Linux kernel.

Et à la section « Recommended components », il est écrit :

It is assumed and encouraged (but not required!) that distributions make use of the following technologies : Wayland, systemd.

Systemd est mentionné, mais pas Upstart. J'en déduis que « Gnome upstream » fonctionne naturellement avec systemd, mais pas avec Upstart. Ainsi, les distributions utilisant Upstart (comme Ubuntu) doivent fournir un travail supplémentaire pour utiliser Gnome.

« tes applications préférés vont arrêter de tourner sur ton système d'exploitation préféré »

Quelles sont ces applications qui, actuellement, ne nécessitent pas systemd, et qui, dans leurs versions futures, exigeront systemd ?

(ce n'est pas de l'ironie, les réponses m'intéressent sincèrement)

Sur ma bécane, je suis parvenu à remplacer cron par systemd. J'en ai fait un tutoriel : Remplacer cron par systemd

Qu'est-ce que le système d'initialisation aurait à faire dans /usr/lib ? Dans /lib, à la rigueur, et même là je trouverais encore ça anormal. Ça a tout à faire dans /bin au contraire, ou /sbin, à la rigueur.

Il y a eu des modifications à ce niveau-là sous Arch : /lib est devenu un lien symbolique vers /usr/lib. Le système d'initialisation peut donc être appelé par /usr/lib/systemd/systemd ou /lib/systemd/systemd

De plus, la totalité des binaires est maintenant installée dans /usr/bin ; en effet, les répertoires /bin, /sbin et /usr/sbin sont des liens pointant vers /usr/bin

Les explications sont ici.

/bin/systemd plutôt.

Sur Archlinux, le binaire /bin/systemd a disparu, il est remplacé par /usr/lib/systemd/systemd. J'ignore si cela est dû à la distribution, ou à une version récente de systemd.

De toute façon, /bin/init pointe vers /usr/lib/systemd/systemd. Ainsi, lorsque l'on ne précise pas de init= sur la ligne du noyau, on démarre sur systemd.

modifier la conf du noyau d'Arch et recompiler

Tu peux essayer le noyau LongTerm Stable d'Archlinux (le paquet s'appelle linux-lts).

À noter que c'est Debian qui maintient la version 3.2 du noyau : c'est la version utilisée par Wheezy, l'actuelle Debian stable. En effet, Ben Hutchings, le mainteneur de cette version, est membre de l'équipe noyau de Debian (autre lien).

Archlinux va prochainement adopter ce noyau en tant que noyau LTS (LongTerm Stable). Actuellement, c'est la version 3.0 de Linux qui est le noyau LTS.