J’ai publié un article dans Linux Pratique n° 95 (mai-juin 2016) intitulé « La meilleure distribution universelle n’existe pas ». Il est disponible publiquement à http://connect.ed-diamond.com/Linux-Pratique/LP-095/La-meilleure-distribution-universelle-n-existe-pas, sous licence Creative Commons BY-NC-ND.
Les éditions Diamond proposent 3 modes de cession des droits pour les articles dont une qui permet la republication sous cette licence, 6 mois après la publication papier (cession de droits type B).
Dans ce cas où l’article disparaîtrait du site Diamond, je le reproduis ci-dessous :
Pourquoi est-il impossible d’avoir une réponse définitive à la question récurrente de la meilleure distribution Linux ? Si la question suscite de vifs débats, c’est plus souvent dû à une relation passionnelle à l’une d’entre elles qu’à un raisonnement rationnel…
Bien souvent, un nouvel arrivant dans l’écosystème Linux demandera quelle est la meilleure distribution dans le but de l’installer. La réponse est pourtant plus compliquée qu’un simple nom donné rapidement.
Une distribution est un ensemble de logiciels cohérents fournis par une organisation, à but lucratif ou non. Elle peut aussi être représentée par un ensemble de caractéristiques qui la définit. Par exemple, le niveau de fiabilité, la diversité de paquets, la réactivité, l’âge des logiciels empaquetés, etc. Cette liste n’est évidemment pas exhaustive.
Pour connaître la meilleure distribution, il est nécessaire de comparer les distributions. Une fois les distributions triées entre elles, la première du classement pourra être définie comme la meilleure.
1. Comment comparer les distributions ?
Pour comparer les distributions entre elles, il faut définir une relation d’ordre entre elles. Il existe deux types de relation d’ordre.
1.1 Comparaison ordre produit
Supposons deux distributions A et B avec deux caractéristiques : x et y pour A et x’ et y’ pour B.
Définition
L’ordre produit se définit tel que (x, y) ≤ (x’, y’) si et seulement si x ≤ x’ et y ≤ y’.
Comparer deux distributions est donc comparer toutes les caractéristiques (x avec x’ et y avec y’ dans la définition précédente) des deux distributions entre elles. Si une distribution possède toutes ses caractéristiques supérieures (resp. inférieures) à une autre, alors cette distribution est supérieure (resp. inférieure) à l’autre.
Par exemple, on peut considérer que si l’on compare deux versions de la même distribution, la plus récente sera meilleure, car l’ensemble des caractéristiques est équivalent [1] sauf celle de l’âge des paquets. Des paquets plus récents étant préférables, la distribution plus récente est supérieure à la plus ancienne. Assez logiquement, la version 9.04 (Jaunty Jackalope) d’Ubuntu aura des paquets plus vieux qu’une 15.10 (The Wily Werewolf).
De même, on peut trouver des distributions abandonnées ou restées à l’état d’ébauche inférieures à celles qui sont vivantes actuellement en utilisant un ordre produit.
Cependant, ce mode de comparaison a une portée limitée, car c’est une relation d’ordre partiel (il existe des cas non comparables).
Si chaque distribution a quelques caractéristiques supérieures à l’autre, alors elles ne sont pas comparables. Par exemple, supposons qu’il existe deux distributions A et B que l’on note sur deux caractéristiques x et y :
| A | B | |
| x | 3 | 4 |
| y | 5 | 2 |
A est préférable sur la caractéristique y et B est préférable sur la caractéristique x. Il n’est donc pas possible de déterminer quelle est la meilleure distribution entre A et B avec un ordre produit.
D’un point de vue pratique, avoir les toutes dernières versions des logiciels augmente les risques d’instabilité, car la fiabilité vient avec les tests et l’expérience, caractéristiques plus faciles à réunir si l’ensemble logiciel reste stable.
Avec le tableau précédent, cela donnerait :
| A | B | |
| Logiciels récents | 3 | 4 |
| Stabilité | 5 | 2 |
La distribution A est plus stable alors que B fournit des logiciels plus récents.
Pour contourner cette limite, il est possible de faire une comparaison lexicographique qui offre une relation d’ordre total, c’est-à-dire que l’ensemble des distributions est ordonnable.
1.2 Comparaison lexicographique
Dans un ordre lexicographique, il faut ordonner les caractéristiques par priorité. L’ordre peut être défini en comparant x avec x’, puis y avec y’ si nécessaire.
Définition
L’ordre lexicographique est défini tel que (x, y) ≤ (x’, y’) si et seulement si [x < x’ ou [x = x’ et y ≤ y’]].
Avec le premier tableau, si l’ordre de préférence des caractéristiques est x puis y, alors la meilleure distribution est B. Si l’ordre des préférences est y puis x, alors la meilleure est A. Une fois qu’un ordre entre les caractéristiques est défini, il est possible de trier toutes les distributions et d’obtenir notre champion.
Il est tout à fait possible pour une personne ou une organisation d’ordonner les caractéristiques qui lui importent et de s’en servir pour faire un choix éclairé. Par exemple, pour un serveur, la distribution A serait privilégiée alors qu’un utilisateur voulant les dernières nouveautés aura tendance à se tourner vers la distribution B.
Comme les besoins sont différents pour chaque personne, l’ordre des caractéristiques est lui aussi différent. Cela implique que l’ordre de préférence des distributions le sera aussi. Il n’est donc pas possible d’obtenir un choix universel avec l’ordre lexicographique (alors qu’avec l’ordre produit, on obtient un choix universel sur une relation d’ordre partiel).
Tenter de donner une note globale en se basant sur chaque caractéristique ne change pas le problème. Le choix des caractéristiques à prendre en compte et le poids relatif de chaque caractéristique reviennent au même problème qu’un ordre lexicographique : l’ordre est total, mais la solution n’est pas universelle.
2. Que comparer ?
La difficulté de choix entre les caractéristiques peut sembler plus théorique que pratique. Pourtant, ce n’est pas le cas.
2.1 Caractéristiques incompatibles
Certaines caractéristiques sont incompatibles entre elles.
Le cas de la stabilité contre le fait d’avoir des logiciels récents a été vu dans la partie précédente. Cependant, ce n’est pas le seul exemple possible :
– Avoir une portabilité maximale des logiciels et une quantité maximale de logiciels puisque certains logiciels ne sont pas prévus pour fonctionner sur certaines architectures. Souvent, ce sont les architectures rares ou anciennes qui sont négligées. Debian fournit une version pour dix architectures de processeur, mais certains paquets ne sont pas disponibles sur certaines architectures. Par le passé, certaines architectures (processeurs SPARC, Alpha, Motorola 68k, etc.) ont été abandonnées, car le matériel ou le manque de volontaires pour la maintenance a poussé à arrêter de fournir une version pour eux.
– Avoir une maintenance longue des logiciels et des paquets très à jour. Pour pouvoir maintenir longtemps des paquets, il est nécessaire de limiter les versions des logiciels pour limiter la quantité de versions à maintenir. La maintenance de RHEL (Red Hat Entreprise Linux) est payante, mais dure jusqu’à 10 ans. Il est même possible de l’étendre avec un contrat supplémentaire. Debian fournit une maintenance de deux ans environ pour sa version stable et le projet Debian LTS a pour but d’augmenter la durée de la maintenance à un minimum de 5 ans. Par contre, les paquets de RHEL et Debian stable changent très peu au fil du temps (pour des mises à jour de sécurité uniquement). Au contraire, Archlinux dispose de paquets récents, mais il n’y a pas de maintenance dans le temps, uniquement des mises à jour continues. Fedora, une version communautaire de Red Hat, tente régulièrement l’inclusion de technologies récentes à titre de tests ; la branche Rawhide dispose de paquets très récents. Certains essais seront ensuite intégrés à la version RHEL.
– La facilité d’utilisation est obtenue en faisant des choix raisonnables pour l’utilisateur. C’est contraire à une priorité axée sur la facilité de personnalisation puisque la première étape sera de demander à l’utilisateur de faire des choix. Par exemple, Ubuntu choisit pour l’utilisateur son environnement de bureau (GNOME) et certains paquets visant à aider l’utilisateur sont installés par défaut (comme command-not-found [2]). Au contraire Gentoo nécessite des choix de configuration avancés (comme les flags de compilation des paquets). De même, LFS (Linux From Scratch) est une distribution permettant à l’utilisateur de configurer et construire l’ensemble de son système à la main. Son objectif est plus didactique qu’une réelle utilisation au quotidien. Il est donc logique que la facilité de prise en main soit négligée au profit du contrôle fin par l’utilisateur.
– Une distribution avec un but très spécifique et ayant un paramétrage convenant au plus grand nombre. Par exemple, BackTrack dispose d’outils préinstallés pour les audits de sécurité, tests de pénétration, etc. Il est toujours possible de l’utiliser pour un usage générique. De manière comparable, Tails est conçue pour garantir la confidentialité et l’anonymat de son utilisateur et est utilisable à partir d’un CD ou d’une clef USB. Par défaut, aucune donnée ne sera enregistrée et les données transmises sur Internet passeront par Tor pour cacher l’origine de l’émetteur de la requête. La priorité classique des distributions est de privilégier la vitesse d’échange plutôt que l’anonymat, ce qui est le but même de Tails. De même, l’idée de ne rien enregistrer est incongrue pour une distribution classique.
Au-delà des programmes, des caractéristiques comme le fait de fonctionner de manière ouverte s’opposent à la possibilité d’avoir une communication lisse et contrôlée puisque les débats seront publics. Les distributions communautaires auront plutôt des listes de diffusions ouvertes, rendant les débats et désaccords visibles publiquement sur la plupart des sujets. Les distributions commerciales gardent certains débats privés (en particulier concernant la stratégie, le marketing et la communication), ce qui est logique puisque ce sont des éléments clefs de la réussite d’une entreprise. La transparence s’oppose à la protection de données sensibles.
2.2 Caractéristiques non comparables
Certaines caractéristiques sont d’ordre qualitatif et non quantitatif. On peut préférer une qualité à une autre pour les avantages qu’elle induit, mais la caractéristique en elle-même ne peut pas être classée.
– Distribution source et distribution binaire : une distribution source fournit uniquement le code source et l’utilisateur doit compiler les paquets. Dans une distribution binaire, les paquets sont fournit compilés. Une distribution source sera naturellement plus orientée contrôle par l’utilisateur que facilité d’usage. Les distributions binaires seront plus faciles d’usage puisque les utilisateurs n’auront pas ni à choisir la configuration des compilations, ni attendre la compilation des logiciels. Les paquets restent compilables par l’utilisateur s’il le souhaite. Gentoo est probablement la distribution source la plus connue. Debian, Red Hat, SUSE, Archlinux, etc. sont des distributions binaires.
– Distribution rolling releaseet sortie régulière : les distributions rolling release (mise à jour en continu, sans version fixe) auront plus facilement des logiciels récents que des distributions avec des sorties régulières qui auront des décalages dans le temps. Plus des sorties sont espacées et plus les logiciels vont vieillir. Archlinux est probablement la distribution rolling release la plus connue. Ubuntu a des sorties fixes tous les 6 mois. Fedora fait approximativement de même. Debian publie une version stable approximativement tous les 2 ans. Les distributions à sorties régulières peuvent avoir des versions qui ressemblent à une rolling release pour mettre au point leur prochaine version. Par exemple, Fedora possède une branche nommée Rawhide, Debian utilise unstable et testing.
Conclusion
Selon les priorités de la distribution, leurs caractéristiques seront différentes. Certaines caractéristiques seront plus travaillées que d’autres. C’est ce qui fait la diversité entre les distributions. Cette diversité les rend imparfaitement substituables entre elles. La situation ressemble à une concurrence monopolistique : les distributions sont proches, mais toutes légèrement différentes [3].
Pour un utilisateur débutant, au-delà des caractéristiques de la distribution et son adaptation à son besoin, la facilité à trouver des utilisateurs ayant la même distribution que lui devrait aussi être un critère de choix, car cela lui permettra d’être aidé plus efficacement.
Notes
[1] Les nostalgiques des temps anciens considéreront probablement que c’est une hypothèse à démontrer.
[2] command-not-found est un paquet qui permet d’afficher des suggestions de paquets à installer lorsque la commande saisie dans un terminal par l’utilisateur n’est pas trouvée sur le système.
[3] L’analyse de la concurrence monopolistique a été initiée par E.H Chamberlin en 1933. L’analyse étant basée sur le comportement des entreprises, elle ne s’applique qu’imparfaitement aux distributions Linux. Par contre, la situation de différentiation reste pertinente.
Faker est une bibliothèque python pour générer aléatoirement des noms, adresses, etc. Elle facilite l’écriture de script pour remplir une base de données avec de fausses informations diversifiées.
Les données produites peuvent être en français. Comme ça, vous pourrez avoir Bertrand Picard plutôt que Lisa Smith. L’anglais est la langue par défaut mais il est aussi possible d’avoir des résultats en italien, espagnol, russe, ukrainien, etc.
from faker import Factory
fake = Factory.create('fr_FR')
fake.name() # 'Laetitia Roger'
fake.name() #'Victoire de la Cohen'
fake.first_name() # 'Jeannine'
fake.first_name() # 'Christophe'
fake.first_name_female() # 'Alexandrie'
fake.first_name_male() # 'Rémy'
fake.address() # 'chemin Catherine Legendre\n33959 LerouxBourg'
fake.department_name() # 'Tarn'
La bibliothèque est disponible en python 2.7 et 3, sous licence MIT, et est activement maintenue.
La liste de champs possibles (nom, prénom, adresse, siren, etc.) est presqu’aussi longue qu’une boucle sans condition de fin. Certains champs ne sont pas encore traduits mais ils sont assez secondaires.
De manière assez inattendue, on m’a suggéré de mettre à jour la frise chronologique montrant des différentes distributions de Debian au fil du temps. L’image de l’article précédent s’arrêtait à la sortie future de Wheezy. Cette fois-ci, elle va jusqu’à la future sortie de Stretch :
Il s’agit simplement d’une version modifiée du fichier Gimp précédent. Le nouveau fichier .xcf est téléchargeable à http://stephane.yaal.fr/frise-chronologique/frisechrono_debian_1993_2016.xcf.
♪ …et pour lui ça voulait dire des trucs : ♫ ♪
Je suis tombé sur cet essuie-tout par hasard et ça m’a rappelé de suite un logo, voire un thème. 🙂
Face à une succession de if-elif-elif-elif-… longue comme un générique de film, il peut être tentant de les remplacer par un switch-case comme on peut en voir en C, PHP, Java, etc. C’est simplement impossible en Python car cette instruction n’existe pas.
Plusieurs propositions pour l’inclure dans le langage ont été faites mais elles ont été rejetées car Guido Van Rossum ne les a pas trouvées convaincantes. Son argumentaire détaillé est disponible dans la PEP 3103 publiée en 2006.
L’enchaînement de conditions que l’on souhaite éviter :
if personnage == "Le manchot":
acteur = "Clint Eastwood"
elif personnage == "Colonel Douglas Mortimer":
acteur = "Lee Van Cleef"
elif personnage == "El Indio":
acteur = "Gian Maria Volontè"
#je vous fais grâce de toute la distribution
else:
acteur = None
La FAQ de la documentation python explique comment se passer du switch (pour python 2, pour python 3). Inutile le lire les deux, c’est la même réponse à chaque fois. Elle recommande l’utilisation d’un dictionnaire. C’est aussi la solution la plus courante que l’on trouve dans du code Python.
L’équivalent du code précédent avec un dictionnaire est :
d = {"Le manchot": "Clint Eastwood",
"Colonel Douglas Mortimer": "Lee Van Cleef",
"El Indio": "Gian Maria Volontè"}
acteur = d.get("El Indio", None)
Comme la structure switch n’est pas disponible dans le langage, plusieurs tentatives ont été faites pour l’ajouter à partir des structures existantes. Comme on peut s’y attendre, le code est plus verbeux et, à mon avis, la solution à base de dictionnaire reste préférable. Parmi les essais disponibles dans pypi.python.org, on peut trouver plusieurs choix d’interface :
Switchcase qui utilise l’instruction break de manière similaire au switch des autres langages : sans l’instruction break, les cas suivants sont automatiquement considérés comme vrai. Fonctionnalité permettant des comportments astucieuses mais qui est aussi un nid à bogues difficile à comprendre. C’est donc probablement une excellente idée de l’avoir ajoutée.
Switch qui a une interface me semblant plus simple à comprendre. La simulation du break est fait par un paramètre facultatif, ce qui s’écarte du switch canonique.
Pyswitch qui utilise les annotations pour définir les différents cas. Je ne suis pas sûr que ce soit le plus lisible mais c’est un choix original.
Une autre solution est de transformer le code en remplaçant les tests par du polymorphisme. Avec l’exemple précédent, on aurait :
class Personnage:
acteur = None
class LeManchot(Personnage):
acteur = "Clint Eastwood"
class ColonelDouglasMortimer(Personnage):
acteur = "Lee Van Cleef"
class ElIndio(Personnage):
acteur = "Gian Maria Volontè"
p.acteur # p étant une instance d'une des classes précédente
Il n’est pas nécessaire que p soit une instance héritant de Personnage. Il suffit que l’interface soit identique. Cette transformation n’est pas spécifique à Python, elle est utilisable dans tous les langages objet.
