Je ne compte plus depuis combien d'années j'ai utilisé Debian + MATE en daily driver. J'en ai toujours été satisfait, mais j'avais aussi envie depuis plusieurs mois d'essayer KDE et surtout de me frotter à SELinux.

Certes il est possible d'installer SELinux sur Debian, mais les policies de base ne sont pas suffisantes car tout crash en mode Enforcing. Il est possible d'y remédier avec quelques commandes audit2allow mais on ne sait pas vraiment ce qu'on autorise et surtout on se retrouve bloqué quand on se frotte à podman.

J'ai donc décidé de réinstaller mon laptop principal sous un système d'exploitation de la Red Hat family !

Choix de la distribution

Bien qu'il soit possible d'installer SELinux sur à peu près toutes les distributions, j'ai choisi de rester dans la Red Hat family car c'est probablement là que l'implémentation sera la plus poussée, et la documentation la plus complète. Cet ensemble désigne :

• RHEL (Red Hat Enterprise Linux) : Payante, même si on peut obtenir une licence développeur gratuitement.
• Fedora : Communautaire, mais rythme de publication trop élevé pour moi. Comme dit dans un précédent article, je préfère les distributions ennuyeusement stables.
• Cent OS : Devenu le "Windows Insiders" de Red Hat, avec une communauté qui ne va pas tarder à déserter, si ce n'est pas déjà le cas.
• AlmaLinux : Un des successeurs spirituels de Cent OS, à vocation communautaire.
• RockyLinux : L'autre successeur spirituel de Cent OS, également à vocation communautaire.
• Oracle Linux : Rires dans la salle. Personne n'aime Oracle.

J'admets ne pas encore avoir assez de recul pour comprendre la différence entre AlmaLinux et RockyLinux, les deux ayant été crées dans le même but. Je suis même étonné de cette concurrence incompréhensible.

Après avoir fait quelques recherches ainsi que des tests en machine virtuelle, je suis finalement parti sur AlmaLinux.

Du ménage à faire

S'il y a une chose qui m'a malheureusement très vite frappé, c'est qu'il y a beaucoup trop de paquets dont je n'ai absolument pas besoin (comme Java...) ou qui peuvent être dangereux sur une station de travail (cockpit, openssh-server, ou des outils de prise en main à distance). J'ai d'ailleurs fait un article à ce sujet : AlmaLinux 9 KDE: remove unwanted packages. Quel dommage qu'AlmaLinux ne propose pas d'image Live "minimale" pour KDE, ou à defaut des instructions pour n'installer que les paquets basiques à partir d'une installation server.

EPEL

On se retrouve rapidement obligé d'activer le dépôt epel-release pour avoir des logiciels tels que htop, kdenlive ou chromium (j'utilise ce dernier pour les PWA). Ma crainte est que ce dépôt ne propose des mises à jour trop fréquentes, ce qui irait à l'encontre de ce que je recherche. Néanmois si je prends l'exemple de kdenlive, celui-ci est actuellement proposé en version 23.08, alors que nous sommes en Octobre 2024. Me voilà donc rassuré car il semble que le rythme de publication des mises à jour ne soit pas trop intense !

Pas de support du H264, H265 & HEIC

On découvre rapidement que Firefox et VLC ne prennent pas en charge les formats H264 et H265, ce qui est très surprenant. Ceci est un choix politique de Red Hat et Fedora, qui ne veulent pas s'exposer aux brevets logiciels. Idem pour HEIC qui est utilisé pour les photos iPhone par exemple, et qui n'est ni supporté dans Gimp, ni dans les miniatures de l'explorateur de fichiers.

Il y a deux solutions :

• Utiliser les versions flatpak de Firefox et Gimp, qui incluent tous les codecs. Je ne déteste pas flatpak, mais je ne suis pas fan non plus car il donne une fausse impression de sécurité à cause de son système de permissions trop laxiste. Il ne permet pas non plus (à ma connaissance) de se fixer sur une version bien précise.
• Ajouter le repository RPM Fusion qui propose les codecs adéquats. Encore un repo :(

J'ai fini par ajouter le dépôt RPM Fusion, mais c'est vraiment dommage d'avoir à la base un système stable et de devoir lui ajouter au moins 2 repositories (EPEL & RPM Fusion) pour le rendre utilisable.

Des paquets manquants, pas de montage de l'iPhone

Sur Debian j'utilise ifuse pour accéder aux fichiers de mon iPhone et copier des photos ou vidéo. Sur AlmaLinux, le paquet ifuse est disponible mais ne fonctionne pas. Il semble que cela soit du à l'absence de usbmuxd qui est disponible dans Debian et AlmaLinux 8, mais pas la 9. Pourquoi ? Aucune idée.

En solution de contournement : installer Debian dans Virtualbox ou QEMU, et faire un USB Passthrough pour récupérer les fichiers.

Un Gimp pas stable et amputé

Gimp est disponible dans les dépôts appstream (activés par défaut). Quelle ne fut pas ma surprise de constater qu'il s'agissait de la version 2.99, compilée à partir d'un commit du code source ! Mais le pire est l'absence de support du format HEIC.

Là encore il faut faire appel à flatpak ou au dépôt RPM Fusion pour avoir un GIMP stable avec support du codec HEIC.

SELinux

SELinux est bien présent, et à la hauteur du défi auquel je m'attendais. Pour avoir fait pas mal de tests en machine virtuelle, SELinux n'interfère pas dans l'expérience desktop ce qui montre qu'un important travail a été effectué sur les policies. Néanmoins il se manifeste lors de l'utilisation de containers avec podman.

Si SELinux n'empêche pas les containers de tourner, il a en revanche tendance à bloquer les accès aux volumes, et l'utilisation de ports sources ou destination. Red Hat propose udica, un outil capable d'ingérer le resultat d'un podman inspect pour ensuite générer une policy SELinux adéquate. J'en ai parlé dans mon article : SELinux: playing with podman + syncthing.

De la documentation et une communauté restreinte

La Red Hat family "stable" (RHEL, Rocky, Alma) sont en général plutôt utilisées sur des serveurs. Pour le desktop, la plupart des gens préfèrent Fedora. La conséquence est que l'on trouve beaucoup moins de ressources et de documentation que pour Debian, par exemple.

Utiliser AlmaLinux en desktop requiert une certaine expérience dans le desktop Linux, ce n'est pas une distribution que je recommanderai aux débutants.

Conclusion

AlmaLinux est dans une très bonne dynamique communautaire, et je n'ai pas cité tout ce qui marche bien. Malheureusement son héritage de Fedora et RedHat peut être un fardeau pour l'expérience utilisateur, notamment à cause de l'entêtement à ne pas supporter les codecs H264 & H265 qui sont probablement les plus utilisés aujourd'hui.

La quasi obligation d'ajouter les dépôts EPEL & RPM Fusion me semble problématique car on dépend alors de composants extérieurs qui sortent du cycle de vie de la distribution. Encore pire pour Flatpak.

Finalement, je suis reparti sur Debian, dans sa variante KDE.