GNU Hurd
Est-ce que ça marche ? Peut-on l'installer ?

Techniquement non, ce n'en n'est pas un, comme le rappelle l'acronyme GNU. Mais GNU Hurd est un système POSIX, partageant donc un grand nombre de caractéristiques avec les systèmes UNIX d'origine, et les OS libres modernes *BSD et Linux.

Concrètement, les grands principes d'UNIX sont les suivants :

• un noyau multitâche préemptif, adapté au multi-utilisateur en offrant la possibilité de gérer différents niveaux de privilèges
• une interface standardisée permettant de dialoguer avec la machine : shell et gestion des terminaux
• une collection d'utilitaires remplissant chacun une tâche simple, mais commutables entre eux

A ce titre, l'utilisation du Hurd est parfaitement similaire en pratique à celle de GNU Linux puisque l'interface de dialogue avec la machine (le shell bash) et les utilitaires sont les mêmes. De plus, le Hurd a été pensé pour être compatible UNIX dès le départ : le code source d'un logiciel écrit pour un système POSIX doit pouvoir se compiler avec gcc sous le Hurd.

Le seul véritable souci que j'ai rencontré avec le snapshot de juin 2023, c'est que le tmpfs (gérant le système de fichiers temporaires en mémoire, comme sous Linux) a tendance à planter. Là où ceci pourrait conduire à un kernel panic sur un noyau monolithique, sur le système GNU ce n'est que le serveur /hurd/tmpfs qui cesse de fonctionner, n'impactant que ce qui lui est lié directement.

Ce peut toutefois être un peu pénible car le contenu du répertoire /run est alors perdu, et notamment les PID file des différents daemons. Utiliser une commande telle que service ssh reload, pour faire relire au serveur SSH sa configuration, devient alors impossible. Egalement, il n'est plus possible de voir quels sont les utilisateurs connectés à la machine, parmi d'autres petites choses.

Vous pourriez très bien ne pas rencontrer le problème, auquel cas je vous conseille de ne pas appliquer les modifications de cette partie. Par contre si cela se produit également chez vous, il y a moyen de corriger le dysfonctionnement en se passant tout simplement du tmpfs pour utiliser un système de fichiers temporaires classique, sur disque.

En admettant que votre /hurd/tmpfs ait cessé de fonctionner, commencez par rétablir les sous-répertoires de /run avec les bons droits :

# mkdir -p /run/lock
# chmod 0755 /run
# chmod 1777 /run/lock

Vérifiez également que les liens symboliques dans /var vers ces répertoires sont également présents, et que les autres répertoires temporaires disposent aussi des bons droits :

# ln -sf /run/lock /var/lock
# ln -sf /run /var/run
# mkdir -p /var/tmp
# chmod 1777 /tmp /var/tmp

Vous pouvez désormais désactiver l'initialisation du tmpfs lors du démarrage. Cela se fait en modifiant le script /etc/init.d/mountall.sh - au début de celui-ci, vous trouverez les lignes :

PATH=/sbin:/bin
. /lib/init/vars.sh
. /lib/init/tmpfs.sh

L'astuce consiste alors à simplement commenter cette troisième ligne, en la faisant précéder d'un # :

#. /lib/init/tmpfs.sh

Après cela, il vous faudra redémarrer la machine. Le serveur /hurd/tmpfs ne se lancera plus, et le contenu de /run ne sera donc pas remplacé par le ramdisk. Tous les daemons et autres services vont alors créer les différents fichiers dont ils ont besoin directement sur le disque dur sous /run.

Problème réglé !