On nous vend depuis des années l’idée que les distributions Linux en fixed release doivent tenir un cycle de publication « raisonnable ». Traduction : pas trop court pour éviter l’usine à gaz, pas trop long pour ne pas finir en fossiles. Et pourtant, certains projets persistent à croire qu’un cycle de 3, 4 ou même 5 ans est viable. Pas vraiment au final.
Le problème des cycles trop longs ? Il y en a trois.
- Logiciels obsolètes : attendre 3 ans pour une mise à jour majeure, c’est condamner l’utilisateur non professionnels à traîner des versions dépassées de sa suite bureautique ou de son environnement de bureau. Dans un monde où Firefox (cycle mensuel) ou LibreOffice (cycle semestriel avec mises à jour mineures mensuellement), c’est suicidaire.
- Sécurité : maintenir pendant des années des paquets vieillissants, c’est multiplier les patchs et les rétroportages. Autant dire que c’est une sacrée utilisation de ressources pouvant être théoriquement employées ailleurs.
- Attractivité : qui veut installer une distribution figée dans le passé ? Les utilisateurs non professionnels finissent par migrer vers des des fixed releases plus dynamiques, voire des rolling release pour les plus courageux.
Deux ans, c’est une limite plutôt pragmatique, pour plusieurs raisons.
- Rythme des projets en amont : la majorité des logiciels libres suivent un cycle rapide, d’un mois à six mois en moyenne. Deux ans, c’est déjà généreux.
- Charge de maintenance : les équipes de développement ont souvent pris pour habitude de ne conserver que deux versions en même temps. La version actuelle et celle qui l’a précédé. Un exemple ? LibreOffice, avec une version « ancienne » dite stabilisée et une récente qui est plus dynamique. Mais la version ancienne reste utilisable.
- Équilibre entre utilisateurs et développeurs : deux ans, c’est assez long pour garantir une certaine stabilité. Tout en restant gérable.
Il y a un seul cas où les deux ans ne sont pas applicables, c’est celui du monde de distributions à destination des entreprises. Comme ce sont des entités qui changent rarement le matériel informatique – du moins tant que celui-ci n’est pas rincé – un cycle long est préférable. Mais ce sont souvent des distributions adossées à de grosses structures comme RHEL qui est maintenue par IBM. Ce qui nécessite de rétroporter des patchs, d’utiliser des paquets universels quand la vieillesse commence à se dévoiler.
Pour conclure ? Si on se place dans le monde de l’utilisateur non professionnel, les deux ans sont la limite acceptable. Ni trop court, ni trop long, ce cycle est donc idéal. Reste le problème de rétroporter les correctifs de sécurité, mais la plupart des fixed release contournent leur fixité en ce qui concerne les navigateurs en utilisant par exemple la version ESR (long terme) de Mozilla Firefox.
C’est sûrement le seul contre-exemple (du moins, c’est celui qui me vient directement à l’esprit) dans la tradition de ne bouger qu’à la marge des fixed releases.
pour les entreprises , ce n’est pas le probleme matériel qui limite les montées de version des différentes distributions , mais les montée de version applicative en relation avec les versions os , beaucoup d’entreprise ont préféré conservé le couple os + appli plutôt que de devoir valider une montée technique et une montée applicative ( souvent c’est fait en même temps ) avec tout ce que cela suppose en suivi et gestion infrastructure pour ces différentes versions.
Une migration sur un gros compte, ça se compte en mois d’essais. Autant dire que des distributions qui n’évoluent que pour les patchs de sécurité seront bien vues. Donc autant dire que les migrations se font quand il n’y a plus d’autres choix disponibles.
Pour les 2 ans de support des fixed, oui c’est suffisant, alors que penser des 15 ans annoncés il y a peu par ubuntu ? j’imagine mal meme avec mes vieux pc utiliser ubuntu 14.04 (celle de mes debuts) et me dire quelle est valable jusqu’a 2029
Pour Ubuntu, les années supplémentaires annoncées ne concernent qu’un support étendu déjà supplémentaire (il était de deux ans, il est maintenant de cinq) payant et réservé aux entreprises. Pour les particuliers, on reste sur 5 ans pour les LTS (9 mois pour les autres), extensibles à 10 si on souscrit à Ubuntu Pro (gratuit pour eux et dans la limite d’un certain nombre de machines inscrites sur un même compte U Pro).
A contrario, je pense que deux ans est le strict minimum syndicale, je parle en connaissance. Alors pas sur ma machine principale, pas chez moi, quoique sur mes vielles machines comme mes portables ça me suffirait largement, par contre chez les amis / la famille/ les connaissances, dont je dois me farcir le changement de version moi même, je serais content, et eux n’y verront que du feu car se foutent royalement des versions de leurs navigateurs, courrielleurs, [X]offices, environnements…
Heureusement que les navigateurs sont suffisamment dynamiques pour tenir le choc sur le long terme. Et jusqu’à preuve du contraire, Debian (pour ne prendre qu’elle) a un cycle de 5 ans en comptant une période LTS. Est-il vraiment utile de migrer dès qu’une nouvelle version stable est sortie ? Vous avez 4 heures et 2 copies doubles à remplir 🙂
Oh pas besoin des cinq ans, je fais le passage dans l’année en cours, j’aime pas le faire à distance, j’ai jamais aimé, donc c’est physiquement que je fais la montée de version.
Les navigateurs LTS est une très bonne chose, mais ce qui compte avant tout c’est d’avoir confiance aux instruments de la distribution pour faire les dites mises à jour, on ne peut pas le faire partout et avec tout, je parle des updates automatiques.
J’ai essayé Nixos et c’est pas mal, mais le saut de version me demande pas mal de vérification, d’ajuster les nombreuses options qui peuvent changer mais si on reste avec un fichier de conf assez généraliste on s’en sort pas mal… Et puis Debian, comme toujours, je sais c’est la vieille dame, mais c’est vraiment celle qui fait chier le moins dans ce cas. Ubuntu lts est pas mal aussi.
Au contraire, ces distros sont très utiles dans le monde pro. Dans un monde où tu gère des postes avec des pro IT et des pro non IT, t’es bien content de ne pas débugger le software utilisé par untel tout les 4 matins qu’une mise a jour de librairie a fait planter.
Ca passe aussi sur des pc perso où les personnes s’en foutent du système, tant que ça marche. Une LTS ou une debian avec le navigateur web et 2-3 outils en flatpak, c’est un très bon combo stabilité/à jour. Que la libmachintruc.so ait 2 ans n’est pas un souci quand y’a pas des impératifs de driver ou autre soft à la dernière version.
La stabilité d’une LTS, c’est impressionnant. T’as juste à prévoir une après-midi tout les x années pour la grosse mise à niveau, mais à part ça, pour le reste c’est du « fire and forget ». J’ai quelques LXC et VM debian que je traine depuis des années, et j’ai pas eu de souci majeur.