Je commence ma propre distribution.

Pour ceux qui sont proches de moi, cela n’est pas vraisemblablement une surprise. En effet depuis mes débuts dans le monde du logiciel libre il y a 16 ans de cela, j’ai beaucoup navigué entre les différentes distributions populaires.

Ayant une exigeance parfois extrême, ce qui est parfois handicapant soit dit en passant; je ne suis pas en mesure de trouver chaussure à mon pied.

Créer une nouvelle distribution parmis une multitude existantes est parfois mal vu et je le comprend. Les réactions les plus communes sont « pourquoi ne pas contribuer à une existante ? », « pourquoi en faire une nouvelle alors qu’il y en a déjà 207 millions ? ». Je vais essayer d’y répondre en mettant les points qui me dérangent dans la plupart des distributions populaires.

Distributions

Rapide tour des distributions que j’ai le plus testées.

Debian

La distribution Debian est une des plus ancienne et populaire du marché. Elle est simple, efficace et solide. On peut l’utiliser pour de nombreux buts différents comme le bureau, serveur, embarqué, containeurs. Cette stabilité embarque tout de même son lot d’inconvénients :

• Les paquets sont anciens. Les versions de Debian sortent tous les 2 à 4 ans, les versions stables n’auront jamais de mises à jour majeures des paquets et c’est une bonne chose. Cependant, si vous êtes afficionado des nouvelles technologies et environnements, vous serez rapidement frustré et obligé de passer à testing ou sid.

• Les paquets sont fortement modifiés. Les développeurs Debian modifient les paquets afin de fournir une meilleur expérience utilisateur dès les premières utilisations. Sont aussi modifiés des paquets, les fichiers de configurations pour éviter que l’utilisateur se mette en danger lui même. Pour simple exemple, regardez le fichier sudoers Debian et celui d’une autre distribution. Ils n’ont plus rien en commun. Ceci est un des points les plus problématique. En effet, lorsque vous cherchez la documentation officielle d’un programme, le paquet Debian aura tellement modifié le paquet que la documentation en est presque voire plus compatible. Vous en arrivez à taper sur votre moteur de recherche préféré « debian + mon programme + howto ».

• Politique étrange. Debian n’intègre aucun logiciel non libre par défaut. C’est aussi une bonne chose, mais les .iso standards ne possèdent pas non plus les firmwares des pilotes wifi du noyau ce qui vous oblige à monter une clé USB avec ces derniers pendant l’installation si vous n’avez pas d’ethernet. Il existe cependant des images .iso les contenant mais nécessitent un parcours de santé avant d’être trouvés sur le site officiel. Debian a aussi décidé de retirer des paquets simplement parce qu’ils ont un nom explicite.

Fedora

Pour être honnête, Fedora est de loin la distribution que j’ai le plus apprécié depuis mes débuts. C’est une distribution avant gardiste intégrant les dernières technologies et avec mises à jour fréquentes.

Le problème, c’est que les employés de RedHat ont une tendance à vouloir recopier dans les détails Microsoft Windows et à rendre Linux aussi bloat que possible. Vous avez par exemple NetworkManager, PulseAudio, PackageKit, et évidemment systemd.

Pour avoir commencé à utiliser Fedora lorsqu’elle portait encore son suffixe Core, je suis déçu de la qualité décroissante au fil des sorties. PackageKit qui remplit votre SSD, NetworkManager prenant 100% du processeur, gnome-abrt suivant au talon, GNOME plantant aléatoirement (GNOME est majoritairement développé par des personnes de RedHat).

En bref, Fedora souffre d’un symptôme fréquent dans le monde de l’informatique.

OpenSuSE

Cette distribution rejoint Fedora pour de nombreux points. À cela nous pouvons rajouter :

• YaST. Cette antique relique du passé est fortement intégré dans le système à tel point que si vous souhaitez configurer votre Wi-Fi dans GNOME, vous aurez le droit à un message vous demandant de passer par YaST. Pour l’expérience utilisateur, on repassera. Peut-être que ça a changé depuis.

Ubuntu

J’aurais besoin d’un nouveau blog.

Slackware

La simplicité, la stabilité, le concept KISS à son plus haut niveau ? Pas de doutes, vous êtes bien sous Slackware. Pour être franc, je ne me suis intéressé qu’à cette distribution que très tard et j’ai eu tort, c’est une distribution intéressante qui frôle la perfection.

Slackware est la plus ancienne distribution encore et toujours maintenue principalement par un seul homme.

Elle se veut simple, par exemple chaque paquet installé est tout simplement inscrit dans un fichier /var/log/packages/nom-du-paquet qu’il vous est accessible via cat. Ni plus ni moins. On apprécie la philosophie du tout est fichier texte.

Pas de magie noire, sysvinit encore en action lance simplement un script d’initialisation. Si vous souhaitez rajouter un nouveau service, modifiez /etc/rc.local. Pas d’rc-update ni systemctl enable.

Parmi les inconvénients je citerais :

• Difficulté de contributions. J’ai bien tenté d’envoyer quelques patchs simples à Patrick, je n’ai jamais eu de réponses. Ni oui, ni non. Il n’y a aucun moyen officiel de contribuer, votre chance est de tenter un mail au hasard des mainteneur de la distribution.
• Figée. Slackware ne supporte pas les dépendances dans son gestionnaire de paquet, de ce fait la recommandation de base est de tout installer soit l’équivalent d’une dizaine de Go sur votre disque. Ainsi, par défaut tous les services seront lancés. En d’autre conséquences mineures, le fichier /etc/passwd installé par défaut contiendra tous les utilisateurs de tous les paquets, même si vous ne les avez pas installés. Solution de facilité au déprimant de la propreté.
• Manque de cohérence et homogénéité. Ce paragraphe s’applique principalement à SlackBuilds qui n’est pas officiellement affilié à Slackware mais particulièrement indispensable. Bien qu’il y ai une convention sur les paquets, il y a encore beaucoup de différences mineurs qui réduisent légèrement l’expérience utilisateur. Exemples : vous ne souhaitez pas pulseaudio ? L’option pour désactiver porte un nom différent pour plusieurs paquets : PULSE, PULSEAUDIO. Pour les paquets python2 / python3 c’est encore une autre histoire.

Gentoo

Quoi de plus gratifiant de compiler soi même tous ces paquets afin de les personnaliser au maximum ? Avoir sa propre version de Gentoo non ressemblante à aucune autre ? Bienvenue sur Gentoo, on parle même de meta-distribution tant aucune installation est identique.

Sur Gentoo, vous compilez tous vos paquets et même votre noyau Linux. Point de vu éducatif on ne peut faire mieux. C’est d’ailleurs en passant à Gentoo que j’ai appris le plus à m’expertiser au maximum.

Ce qui a tendance à me déplaire sur Gentoo :

• Les .ebuild. Les paquets de Gentoo sont écrits via des fichiers .ebuild ayant une syntaxe particulière et difficile à maitriser. Beaucoup disent et pensent qu’il est difficile de concevoir un ebuild tant de fonctionnalités de portage sont « cachées » ou mal documentées.
• Perte de temps. Évidemment compiler n’est pas une mince affaire. Vous êtes au travail, vous avez fraichement compilé votre environnement graphique quand soudain vous recevez un document en .doc/.odt. Il va falloir vous armer de patience afin d’avoir une suite office permettant de l’éditer. J’ose imaginer la réaction de votre collègue quand il reviendra vous relancer n’ayant pas encore reçu le document modifié une heure plus tard. « LibreOffice n’a toujours pas fini de s’installer ».
• Rolling release. C’est une distribution sans version donc chaque mise à jour est plus ou moins risquée.

Arch

La distribution Arch est connue pour sa simplicité et sa philosophie KISS. On saluera aussi la qualité exceptionnelle de sa documentation qui est probablement de loin la meilleure du paysage libriste. Pour le développeur et le passionné de nouveautés, Arch est très simplement la distribution idéale.

Arch est réputée pour être instable et risquée. Cependant, pour l’avoir utilisée plusieurs années je n’ai rien eu de bien marquant. Certes les mises à jour peuvent demander des manipulations préalables mais rien de bien grave.

Comme Gentoo, Arch ne dispose pas de versions fixes la rendant particulièrement inadaptée aux serveurs.

Vanilla

Alors vanilla et pourquoi vanilla ?

Dans le monde de l’informatique, on utilise parfois le terme vanilla pour indiquer la neutralité et la forme originelle d’un programme. C’est un des buts fondamentaux de vanilla.

Peut-être que mon arôme préféré étant la vanille y joue un peu, aussi.

Ce qu’est vanilla

Une philosophie simple

• Un gestionnaire de paquet en pur shell POSIX basé sur le tout est fichier. Lorsque vous utiliserez vpk, celui ci téléchargera des fichiers de texte simples de métadonnées pour connaître la liste des paquets disponibles. En d’autres termes, on peut résumer l’installation des paquets via vpk avec wget, cat/grep et tar xf.
• Les paquets installés copient l’idée originale de Slackware en stockant les informations essentielles des paquets dans de simple fichiers.

Opensource

Évidemment, en tant que libriste la totalité de vanilla est opensource et sous license ISC. Par là vous entendez vpk, les scripts des paquets vanilla et les autres outils à venir.

Traditionnel

Bien qu’en toute franchise systemd ne soit pas si terrible que ça. Il est néanmoins à l’encontre de la philosophie d’UNIX qui est de faire une seule chose et de la faire bien.

Pour vanilla, j’opte pour le traditionnel sysvinit qui a certes quelques défauts mais est simple d’utilisation.

Pour activer ou non des services, rien de plus simple que de rajouter ce dernier dans le fichier /etc/rc.start et /etc/rc.shutdown.

# /etc/rc.local: local startup script
if [ -x /etc/rc.d/nginx ]; then
    /etc/rc.d/nginx start
fi

Note : sysvinit n’est pas gravé dans le marbre et pourrait changer avec une bonne raison mais je ne suis pas grand fan de runit et openrc.

Versions stables et fixes

Comme la plupart des distributions, vanilla sort avec des versions. Cela la rend adaptée pour de nombres utilisations où la stabilité est de mise.

À cela sera garanti :

• API/ABI figés, si vous compilez un programme à la main vous pouvez être sûr qu’il soit fonctionnel toute la durée de vie de cette version.
• Aucune mise à jour majeure des programmes.
• Aucune manipulation administrative à faire.

musl

La bibliothèque C est musl. Une bibliothèque simple, claire et efficace qui a déjà fait ses preuves dans d’autres distributions.

LLVM

La boite à outil par défaut est LLVM/Clang au lieu de binutils, gcc. Principalement pour une raison de licence et de simplicité.

Contrairement aux idées reçues, LLVM est bien moins bloat que GCC.

Malheureusement, le noyau Linux n’est pas compatible avec LLVM 7 donc cette idée sera reportée.

Pas de découpage de paquets

Beaucoup de distributions découpent les paquets en différentes parties (-dev, -devel, -dbg, -doc). Non seulement cela alourdit les scripts de construction des paquets mais en plus agace les développeurs qui ont souvent besoin de ces paquets.

Pour ma part, je pense que c’est au gestionnaire de paquet lui même d’exclure des fichiers lors de l’installation.

Exemple : vpk install -x usr/include zlib n’installera pas les fichiers d’entêtes C de zlib.

Dépendances faibles

Contrairement à Slackware qui est plus radicale sur le sujet, vpk installera les dépendances par défaut mais autorise de les passer. Ainsi, l’utilisateur pourra s’affranchir de paquets dont il n’a pas besoin.

Voir aussi le paragraphe suivant.

Gestion fines des uid/gid nécessaires

Quand vous installez un service, il se peut que ce dernier ait besoin d’un utilisateur et un groupe pour fonctionner. Dans la plupart des distributions cela est fait par le gestionnaire de paquets sans pouvoir le personnaliser.

Par défaut, si un paquet demande un utilisateur et un groupe il proposera à l’installation de les créer. Ainsi, si vous souhaitez créer l’utilisateur avec vos propres paramètres, vous pouvez le faire au préalable et vpk les réutilisera. C’est le cas de pkgng sur FreeBSD par exemple.

Reconstruction des paquets

Avec vanilla, il est possible de recompiler des paquets du système pour les personnaliser. Cela se fera de manière aisée.

Exemple : vous ne souhaitez pas dbus dans le paquet foo/bar

cd /usr/src/vanilla/foo/bar
DBUS=no vpk build && vpk install

Cependant, si une mise à jour de bar est disponible, elle sera à nouveau liée à dbus mais comme une version de vanilla est figée en ABI/API, on peut se contenter de marquer le paquet comme « personnel » pour que vpk n’y touche plus.

vpk mark bar own # own pour indiquer qu'il m'appartient

Note: il faudra néanmoins vérifier qu’il n’y ai aucune faille dans le paquet bar ce qui pourra être envisageable avec une tâche quotidienne d’audit via cron.

Reconstruction en masse

Reconstruire des paquets épisodique est adaptée pour des changements mineurs. Mais admettons que vous souhaitiez réduire au maximum les dépendances pour un système embarqué, vous voulez donc reconstruire un grand nombre de paquets en masse. Cela se fera avec vpod.

Pour reconstruire des paquets en masse, il est nécessaire de générer un arbre de dépendances dans le bon ordre et reconstruire les paquets dont les options ont changé. Avec vpod cette tâche fastidieuse sera faire pour vous à la même manière que poudriere sur FreeBSD dont il s’inspire également.

L’outil vpod n’est pas encore en développement mais son but est de pouvoir construire des paquets depuis n’importe quel distribution. Ainsi, vous pouvez personnaliser votre vanilla avant même qu’elle existe.

Pas de bibliothèque statiques ni libtool

Les bibliothèques statiques posent un nombre de problème élevé de sécurité et peuvent largement être remplacées par des bibliothèques dynamiques.

Les fichiers .la ne seront pas installés non plus.

Homogénéité des répertoires

Une des modifications autorisée dans les paquets est le placement des fichiers afin de respecter une norme précise.

Par exemple:

• /usr/lib/pkgconfig : fichiers .pc
• /usr/lib/cmake : export CMake
• /usr/share/doc : documentation des paquets
• /usr/share/man : pages de manuel (tous compressés au même format)
• /usr/libexec : exécutables non prévus pour l’utilisateur final

Aussi, plus de séparation entre /bin et /usr/bin, de même pour lib. Ainsi les répertoires suivant sont de simples liens symboliques :

• /bin -> /usr/bin
• /lib -> /usr/lib

Homogénéité visuelle

Tous les scripts d’initialisation du système doivent avoir le même format stricte. La cohérence et l’homogénéité forment une valeure qui m’est chère et ceux qui me connaissent bien le savent.

Il en va de même pour les conventions des outils fournis par vanilla ainsi que les conventions de code.

Pas d’installateur

Quand j’installe une distribution grand public, je suis surpris par le manque de choix. Il fût un temps on pouvait encore personnaliser ce qu’on voulait installer. Souvenez-vous de vos parents vous faisant croire que la cuillère était un avion pour vous nourrir ? Bienvenue sur Ubuntu et Fedora.

À mon humble avis, les installateurs sont beaucoup trop complexes à implémenter pour couvrir tous les cas de figure possible. En effet, avec l’émergence de nouvelles technologies il faut pouvoir couvrir : MBR, GPT, UEFI, RAID, lvm, les systèmes de fichiers, grub, lilo, elilo, syslinux. Au final pourquoi essayer de faire un installateur complexe quand nous pouvons simplement laisser l’utilisateur partitionner lui même puis faire un bootstrap ?

Grand féru d’efibootmgr, je ne pouvais pas l’utiliser sous Fedora car anaconda me forcait l’utilisation d’une partition montée sur /boot/efi et les kernels étant placés sur /boot, j’aurais du faire en sorte que les kernels soient copiés après chaque mise à jour.

Exemple d’une installation de vanilla minimale avec une partition / :

fdisk /dev/sda
mkfs.ext4 /dev/sda1
mount /dev/sda1 /mnt
vbootstrap /mnt minimal
chroot /mnt               # bootloader puis quelques éditions

En seulement 5 commandes vous avez un système bootable fait par vos soins. L’outil vbootstrap est similaire à debootstrap afin d’installer un système personnalisé dans un répertoire.

Cela est d’autant plus avantageux lorsque vous voulez installer votre distribution pour un système embarqué n’étant pas sur la même architecture. Vous montez votre micro SD sur votre PC, vous utilisez vbootstrap pour installer vanilla arm sur celle ci, vous insérez la micro SD dans votre raspberry et vous la mettez en marche.

Encore une fois, vbootstrap sera conçu à pouvoir l’utiliser depuis n’importe quelle distribution Linux hôte. Nul besoin de créer des live CD/USB.

ARM

J’aime ARM et j’aime que ma distribution principale soit aussi compatible pour les plateformes ARM comme la Raspberry Pi. Malheureusement, ce n’est pas le cas officiel de Fedora (partiel), Slackware (partiel), Arch et CRUX. Ainsi, vous devez vous contenter d’éditions tierces non officielles.

Vanilla aura pour but de supporter ARM (ainsi que AArch) officiellement en mode hard-float.

Simplicité de création de paquets

Avez vous déjà essayé de faire un paquet Debian ? Gentoo ? C’est loin d’être chose facile. Dans vanilla vous écrivez un script shell qui doit se contenter de construire le paquet dans un répertoire précis. À la manière claire et précise de Arch, CRUX et Slackware.

Rien de magique ni de caché, le script est lisible et clair. On comprend tout ce qu’il se passe sans aucune boite noire.

C’est à vpk de faire le nécessaire comme télécharger les archives, lancer le script puis générer un paquet.

Exemple de cas simple avec lib/zlib.

Ce que ne sera pas vanilla

• Bloat, la distribution, l’infrastructure, les outils et les paquets resteront simples.
• Assistée, le but n’est pas de faire une distribution pour les expérimentés aguéris mais nécessitera un peu de connaissances.

À venir

Alors intéressé ? Est-ce qu’il y aurait des distributions proches de ce que je prévois et que j’aurais ratées ?

Vous me demanderez, « Pourquoi pas Alpine ? » c’est vrai qu’Alpine est particulièrement proche de mon idée mais elle a deux trois points que l’on peu retrouver dans l’ensemble des distributions plus haut.

N’hésitez pas à voir le projet Redmine pour voir les avancements ainsi que les dépôts Mercurial.

• https://redmine.malikania.fr/projects/vanilla
• http://hg.malikania.fr/vanilla
• http://hg.malikania.fr/vanilla-vpk