Netbook, Arch GNU/Linux, un joli i3 et des optimisations en vrac

Alors que je m’étais fendu d’un billet introductif concernant la configuration minimaliste que j’arbore sur mon netbook (un Compaq Mini 700EF, je le rappelle), voici un second billet à ce même sujet, cette fois-ci consacré à la configuration-même des différents composants logiciels que j’utilise (pour les plus importants).

J’essaierai de présenter les choix que j’ai pu faire, mais entre nous soit dit, il se peut bien que je ne me rappelle plus exactement des raisons de l’une ou l’autre modification, un peu trop pris que j’étais dans le travail d’édition ou de création de mes différentes configuration. Néanmoins, tentons tout cela !

i3 et Tomorrow Theme

Faisant quelques infidélités au thème Solarized que j’apprécie énormément, j’ai décidé  non sans un vif pincement au cœur de m’éprendre du Tomorrow Theme, très efficace et dans des teintes que j’apprécie. Visuellement, voici ce que ça donne à peu près :

Ça vous plaît ? Pour avoir cette palette, voici les fichiers de configuration que j’ai (commentés pour la plupart) :

• ~/.i3/config et ~/.i3status.conf ;

Notez l’importance de quelques programmes auxquels fait appel ce fichier, par exemple ceux cités en fin de fichier : i3lock (voir plus bas), nitrogen (pour le fond d’écran), urxvtd (démon pour rxvt-unicode, appelé avec le client urxvtc), clipit (gestionnaire de presse-papier), redshift (ajuste la température de l’écran en fonction de l’heure et de la position géographique), ou encore unclutter (cache le curseur si inutilisé après un certain délai). Je mentionnerai que j’utilise la police Terminus, pensez à l’installer si vous utilisez mon fichier, ou éditez les lignes en faisant mention. Pour avoir les ressources nécessaires :

pacman -S terminus-font unclutter redshift clipit

Notez que pour un support effectif de cette police, vous devez rajoutez dans votre ~/.xinitrc (voici le mien en exemple) les lignes :

xset +fp /usr/share/fonts/local
xset fp rehash

• ~/.Xresources ;

Pour la configuration de rxvt-unicode, référez-vous à ce fichier. Notez le besoin de quelques dépendances également, les extensions et de quoi gérer la molette. Pour ce faire, il suffit d’installer les dépendances suivants (pour la molette voir le lien précédent) :

pacman -S rxvt-unicode urxvt-perls

• ~/.bashrc ;

Suivant le principe de comment obtenir un bash coloré, voici l’épure de mon .bashrc, nécessitant pour son fonctionnement les paquets colordiff et most. Le reste se trouve dans l’article sur ArchWiki.

Avant toute modification du système

Je vous conseille vivement d’avoir une clef USB d’Arch Linux à proximité, si jamais ça plante, histoire de chrooter tout ça et annuler les modifications effectués. Pour ce faire, il n’y aurait qu’à suivre sommairement l’utilisation des Arch Install Scripts, monter les partitions nécessaires (/boot et / devraient suffire), faire un arch-chroot /mnt et essayer de réparer ce qui n’aura pas été convenablement. Avec cela, il est toujours possible de rétablir la plupart des fausses manipulations – cela n’empêche pas néanmoins de faire attention !

Prêts ? Commençons par changer de noyau !

Noyau CK

Soyons franc, je n’ai pas spécialement envie de présenter ce noyau que je trouve réactif, complet et ma foi, dont le mainteneur est une personne plutôt serviable et attentive aux régressions annoncées. Au rang des avantages de ce noyau, il y a non seulement un excellente réactivité du système qu’importe la charge de ce dernier, mais aussi des gains de performance réels. Pour bénéficier de tout cela, il vous faudra :

• ajouter le répertoire à /etc/pacman.conf

[repo-ck]
SigLevel = PackageRequired
Server = http://repo-ck.com/$arch

• ajouter la signature de graysky

pacman-key -r 6176ED4B; pacman-key --lsign-key 6176ED4B

• mettre à jour la base de pacman (et avoir la musique en tête, accessoirement, de rien c’est gratuit)

pacman -Syy

• installer le noyau qui va bien (ici optimisé pour un Intel Atom)

pacman -S ck-atom

À ce moment, il faut sélectionner les paquets qui vont bien par rapport à la configuration matérielle, pour ma part j’avais besoin des drivers Broadcom, donc j’ai sélectionné le noyau (évidemment), et le module (qui ajoutera tout ce qu’il faut dans /etc/modules-load.d/.

• changer d’elevator (si par exemple vous n’avez pas de SSD, auquel cas il est conseillé de garder deadline) :

Insérez elevator=bfq dans /etc/default/grub à la ligne GRUB_CMDLINE_LINUX_DEFAULT, puis régénérez GRUB2 d’un grub-mkconfig -o /boot/grub/grub.cfg.

Sources : Linux-ck sur ArchWiki, Repo-ck sur ArchWiki, le site officiel pour Arch Linux Repo-CK (des benchmarks y sont disponibles).

Optimisation du mkinitcpio

Certes, l’autodétection des modules du noyau fait un boulot fabuleux dans la plupart des cas, dans le mien il y a une motivation simple : réduire drastiquement la taille de l’image du noyau, de sorte de n’avoir que les modules nécessaires au fonctionnement de ma machine. Pour cela, il faut :

• trouver les modules disque (pour l’exemple, admettons qu’on ait sd et ahci)

udevadm info --attribute-walk -n /dev/sda1 | grep 'DRIVERS=="[^"]'

• ajouter ça à MODULES, comprendre : sd_mod + second pilote + système de fichier (je clair, ne pas ?)

MODULES="ahci sd_mod ext4"

• placer dans les BINARIES en conséquence pour la détection des systèmes de fichier, dans mon cas il s’agit de :

BINARIES="fsck fsck.ext4"

• changer les HOOKS pour n’en garder que le minimum : base seulement, ou bien ajoutez-en quelques autres comme timestamp, pour avoir un systemd-analyze plus précis. Le mien est celui-ci :

HOOKS="base timestamp"

• changer la compression, ce qui nécessite dans le cas présent l’installation du paquet lzop

COMPRESSION="lzop"

• régénérer l’image du noyau

mkinitcpio -p linux-ck

Source : Optimizing Bootup With mkinitcpio.

Économie d’énergie sans laptop-mode-tools

Pour un ordinateur portable, considérons deux liens permettant d’avoir un environnement n’utilisant que systemd (permettant de virer acpid et pm-utils, youpie)

1. un script d’économie d’énergie du forum CrunchBang ;
2. une application de ce script moyennant quelques changements, compatible avec systemd avec quelques règles udev ;

Prêts ? Nous allons :

• copier le répertoire git ;

git clone git://github.com/Unia/powersave.git; cd powersave

• installer les dépendances en fonction des nécessités (à votre discrétion, par exemple je ne touche pas à hdparm puisque j’ai un SSD) ;
• installer le contenu du script ;

sudo make

• éditer /usr/bin/powersave en fonction des spécificités du matériel ;

Par exemple, j’ai enlevé la gestion de la luminosité, trop peu fiable pour moi, ou j’ai ajouté des arguments gérant des paramètres spécifiques aux puces Intel (i915, commentés suite à la manipulation suivante). Voici mon fichier /usr/bin/powersave tel que je l’ai modifié, libre à vous de vous en inspirer ou de l’ignorer. La majeure partie des règles sont présentes, libre à vous donc de les décommenter et de vérifier si ces règles ne génèrent aucune erreur quand vous entrez powersave true dans votre terminal. Il ne faut pas hésiter à faire des cat sur les chemins des lignes du script, histoire de voir s’ils existent.

• forcer ASPM powersave par un argument dans GRUB ;

Insérez pcie_aspm=force dans /etc/default/grub à la ligne GRUB_CMDLINE_LINUX, puis régénérez GRUB2 d’un grub-mkconfig -o /boot/grub/grub.cfg.

• permettre à systemd de gérer les événements du matériel en éditant le fichier /etc/systemd/logind.conf ;
• créer le fichier /etc/modprobe.d/blacklist.conf avec pour contenu :

blacklist pcspkr

Cette petite ligne permet de désactiver le « beep » atroce et faisant saigner les oreilles sortant parfois des entrailles de la machine – pour un dispositif nomade, donc coutumier des salles de cours, c’est un comportement indisposant.

• créer le fichier /etc/modprobe.d/snd_hda_intel.conf avec le contenu :

options snd-hda-intel model=laptop
options snd_hda_intel power_save=1
options snd-hda-intel enable_msi=1

• créer le fichier /etc/modules-load.d/cpufreq.conf afin d’activer les modules de contrôle de la fréquence du processeur, avec le contenu suivant ; ici j’utilise le module acpi_cpufreq mais choisissez le module qui convient le mieux à votre matériel :

# Load cpufreq driver
acpi_cpufreq
# Load cpufreq governors
cpufreq_performance
cpufreq_powersave

Accélérer un poil le démarrage de systemd

Premièrement, il n’y a pas de secret : choisissez bien les services à démarrer. Une fois cette manipulation faite (que je ne peux pas faire à votre place, comprenez bien), on peut vider le contenu de /etc/vconsole.conf (oui, même si le wiki le suggère) et laisser X.Org être le seul à s’occuper des dispositifs de saisie comme inscrit dans ArchWiki.

On va donc :

• supprimer le contenu de /etc/vconsole.conf ;
• rétablir /etc/X11/xorg.conf.d/10-evdev.conf à l’originale parce que comme des buses on l’avait modifié pour avoir une jolie disposition clavier ;
• créer et éditer le fichier /etc/X11/xorg.conf.d/20-keyboard.conf avec le contenu suivant :

Section "InputClass"
       Identifier             "Keyboard Layout"
       MatchIsKeyboard        "yes"
       MatchDevicePath        "/dev/input/event*"
       Option "XkbLayout"     "fr,fr"
       Option "XkbVariant"    "latin9,bepo"
       Option "XkbOptions"    "grp:shifts_toggle"
EndSection

Cette configuration me permet de passer de la disposition fr-latin9 (azerty sous stéroïdes) à fr-bepo en appuyant sur les deux touches majuscule en même temps. Pratique, non ?

N.B. L’utilité de cette manipulation a été soulevée dans les commentaires, dans le sens où le fichier /etc/vconsole.conf gère les tty, et que 20-keyboard.conf s’adresse à X.Org, sans rapport entre les deux. Je me suis rendu compte que la population de /etc/vconsole.conf demandait plus de temps à l’exécution de systemd-vconsole-setup.service, alors qu’il est excessivement rare que j’utilise directement une tty sur cette machine (à part de façon automatique, voir le point suivant). La différence n’est évidemment pas énorme, 40ms à tout casser, mais c’est toujours 40ms de prises pour passer en dessous de la barre des quatre secondes. Cette manipulation n’est donc pas fondamentalement indispensable, mais il me semblait utile de la mentionner.

Connexion automatique et i3lock

Il y a sur ArchWiki un article qui m’avait jusqu’alors échappé, répondant au titre plutôt explicite de Automatic login to virtual console, que l’on peut combiner avec cet autre : Start X at Login.

Alors qu’auparavant je voulais utiliser SLiM en connexion automatique, et appeler i3lock en début de session pour tout de même avoir une demande de mot de passe, cette méthode me permet de réduire encore un peu les dépendances nécessaires à mon environnement. Notez que cette manipulation me déplaisait cruellement, étant donné la relative inutilité de SLiM sinon pour passer la main entre systemd et X.Org.

Notez cependant que pour désactiver SLiM ou tout autre service du genre, et activer la méthode de connexion telle qu’exposée dans le wiki, il vous faudra un peu faire le ménage dans les services de systemd. Ajoutez donc qu’il faut désactiver SLiM, mais aussi enlever la cible par défaut du service « graphique » :

systemctl disable slim.service graphical.target default.target

Vous pouvez ensuite suivre les pages du wiki sans problème, à savoir créer un service lançant une tty automatiquement, et une ligne dans le profil bash ou zsh qui lancera X automatiquement.
Il ne suffit plus que d’éditer .xinitrc ou le fichier de configuration du gestionnaire de fenêtre et d’y ajouter une commande pour i3lock. Dans mon cas, j’ai ajouté exec --no-startup-id i3lock -c 1D1F21 au début de mes exécutions automatiques dans .i3/config comme mentionné plus haut.

systemd-analyze blame

Je charge un minimum de services au démarrage, comme vous pouvez le constater :

193ms systemd-udev-trigger.service
159ms systemd-logind.service
134ms systemd-modules-load.service
82ms systemd-remount-fs.service
79ms sys-kernel-debug.mount
77ms dev-mqueue.mount
73ms systemd-sysctl.service
69ms systemd-tmpfiles-setup.service
61ms systemd-udevd.service
52ms systemd-vconsole-setup.service
50ms dev-hugepages.mount
38ms dev-sda2.swap
33ms home.mount
33ms systemd-user-sessions.service
27ms boot.mount
25ms tmp.mount

systemd-analyze time

En somme :

Startup finished in 1129ms (kernel) + 1366ms (initramfs) + 1480ms (userspace) = 3977ms

Certes, le SSD me permet de gagner énormément de temps, mais auparavant (configuration lourde et pas optimale, avec un DE bien trop complet pour mes besoins je ne descendais jamais en dessous des dix secondes.

pstree sur une utilisation courante

systemd─┬─anacron
        ├─bash───dwb───4*[{dwb}]
        ├─bash───gajim
        ├─clipit
        ├─crond
        ├─3*[dbus-daemon]
        ├─2*[dbus-launch]
        ├─dhcpcd
        ├─dropbox───13*[{dropbox}]
        ├─dunst
        ├─i3bar───i3status
        ├─ifplugd
        ├─login───startx───xinit─┬─X
        │                        └─i3
        ├─redshift
        ├─systemd-journal
        ├─systemd-logind
        ├─systemd-udevd
        ├─unclutter
        ├─urxvtd─┬─bash───pstree
        │        └─bash───vim
        └─wpa_supplicant