Un petit article qui trotte dans mes vieilles méninges depuis quelques temps. C’est la mise en route de la communication de l’équipe de Mageia pour faire connaître sa dernière version qui m’a donné l’occasion de rédiger cet article.
Deux points que personne ne lira, mais peu importe.
- Cet article ne vise pas la descendante de Mandriva.
- Cet article ne concerne que les distributions GNU/Linux dites « fixed releases », celles qui sortent tous les 6 mois à 2 ans une nouvelle version majeure.
Ensuite, j’ai eu l’occasion de dire plusieurs fois que les modèles fixed et rolling sont complémentaires, avec une répartition « idéale » qui serait la suivante :
- Fixed : postes de collectivités privées ou publiques, monde du serveur et applications scientifiques (comme les satellites)
- Rolling : les postes de « monsieur et madame tout le monde » ayant une connexion décente avec des équipes de maintenance sérieuses aux commandes.
Mais il est vrai que selon certaines personnes, j’ai la haine des distributions fixed releases… On ne va pas se mettre la rate au court-bouillon pour un tel anathème.
Je viens de m’apercevoir qu’avec les deux phrases qui précèdent, j’ai perdu une bonne moitié de mon lectorat. C’est cela, les expressions de vieux 🙂
Prenons maintenant les principales distributions GNU/Linux en fixed, celles qui sont mondialement connues et qui sont utilisées partout. Par ordre alphabétiques, ça donne :
-
- Debian GNU/Linux
- Fedora Linux
- Linux Mint
- Ubuntu et sa famille
Avec ce quatuor, on doit être dans les 80 à 90% du total. Sur une année civile, ça donne ça :
- Avril : Ubuntu xx.04, LTS toutes les années paires
- Mai : Linux Mint, première, basée sur la dernière révision de la Ubuntu LTS
- Mai à juillet chaque année impaire : Debian GNU/Linux xx.0
- Octobre : Ubuntu xx.10
- Novembre : Linux Mint, deuxième, basée sur la dernière révision de la Ubuntu LTS
La Fedora sort avec un cycle de 9 à 10 mois en « roulant », donc difficile de l’y caser.
En gros, en avril/mai et octobre/novembre, les blogs et webzines proposent des articles sur les « X ou Y trucs à faire après avoir installé Ubuntu ou Linux Mint », qui sont souvent des reprises d’articles vieux de 6 mois avec un gros travail de remplacement automatisé des noms de codes et des numéros de versions.
Ce qui est vrai pour les distributions l’est aussi pour les environnements de bureau. Reproduisons l’expérience pour le quatuor Gnome, Plasma, Mate Desktop et Xfce.
- Février : première version majeure de Plasma de l’année
- Premier trimestre : sortie de la nouvelle version de Mate-Desktop
- Mars : première version majeure de Gnome de l’année
- Juin : deuxième version majeure de Plasma de l’année
- Septembre : deuxième version majeure de Gnome de l’année
- Octobre : troisième version majeure de Plasma de l’année
Pour Xfce, c’est en gros tous les ans. La 4.14 était parue en août 2019, la 4.16 en décembre 2020.
Pour Plasma, je me suis basé sur la feuille de route disponible sur le wiki du projet.
Pour l’année 2021 :
- 11 février 2021 : Plasma 5.21
- 8 juin 2021 : Plasma 5.22
- 12 octobre 2021 : Plasma 5.23
Prenez donc les deux calendriers, croisez-les et vous aurez une idée de l’actualité qui sera traitée par les blogs et webzines. Ce n’est pas si sorcier. Après, libre à vous ne de pas me croire. J’ai mis un maximum de sources dans l’article pour que vous puissiez recouper tout ce que j’affirme.
Sur ce, je vous laisse et je vous souhaite une bonne journée.
Au-delà de la presse linuxienne qui reste des plus anecdotiques, les calendriers de sortie des fixed-releases permettent aux utilisateurs en production (entreprises, collectivités, particuliers semi-pros ou indépendants) de préparer, selon un calendrier connu à l’avance, la montée en version de leurs OS ça paraît légitime du point de vue fonctionnel.
Je suis entièrement d’accord.
Je dois sûrement me tromper, mais nombre de collectivités doivent rester sur des versions LTS, histoire de ne se prendre la tête que tous les 2 ou 3 ans.
Ce qui comprend donc des projets comme RHEL/CentOS/Oracle Linux, Debian GNU/Linux ou encore Ubuntu LTS.
J’attends encore qu’on me dote en OS Linux au boulot 🙂 Je me verrais bien en RH ou Oracle.
Pour des serveurs oui autant être en hyper LTS, après pour des stations de travail, une montée en version propre et maîtrisée tous les 2 ou 3 ans c’est jouable, il y a pas mal d’entreprises qui reformatent leur PC à chaque nouvelle version de Windows voire systématiquement tous les 3 ans et maintenant avec les SSD qui ne durent quand même pas une éternité (sauf pour les matériels hauts de gamme mais il faut y mettre le prix) ça peut valoir le coup de se faire un changement de disque à chaque montée en version d’un OS de quoi repartir sur des bases saines.
Le point 2. de ta liste est très parlant, j’adhère direct !
Sinon pour Ubuntu, c’est XX.04 et XX.10, les .04 tous les deux ans sont des LTS mais la mise à jour d’une LTS à l’autre n’est proposée que sur la .1 disponible en général en juillet.
De plus, je ne sais pas si c’est pareil pour toutes les distros, mais Ubuntu « freeze » les mises à jour hors bugs très tôt,c’est pourquoi, même si un DE sort une mise à jour majeure juste avant la sortie d’une Ubuntu, elle ne sera pas incluse.
Ça doit être idem pour les noyaux and co.
Je suis resté dans les grandes lignes. Je sais très bien que Canonical n’active la migration d’un LTS vers la LTS+1 à la sortie de la LTS+1.1.
Toutes les fixed releases ont une période de gel plus ou moins longue. Debian c’est en gros 6 mois. Ubuntu, un petit mois.
Je ne dénombre même plus le nombre d’articles a chaque fois où de videos viral sur la YouTube sphère « ohh la linux mint est sortie comment l’obtenir’ etc… Au moin chez debian y sont moin cloche avec sa ses plus calme , pas étonnant que j’en est eu ma claque a fini sous Ubuntu mate puis migrer définitivement vers une base arch « Endeavour os «
La Linux Mint est devenu depuis l’arrivée d’Unity – qui était détesté au dernier degré, marrant quand on voit les réactions lors de son débranchement – en 2011 la distribution pour « monsieur et madame tout le monde », même si cela n’est pas complètement exact.
Concernant ton cheminement, je pense que tu ne dois pas être le seul dans ce cas.
A la louche, les OS Linux en entreprise se résument à : CentOS/RHEL et Debian
Leur efficacité/stabilité/notoriété n’est plus à prouver
Tu peux prévoir tes patchs environ 2 fois par an ( 1 par semestre, je sais c’est pareil 🙂 )
Suivant le volume, tu peux monter à 1 fois par trimestre, mais honnêtement la charge de travail, pour la boite ou pour l’hébergeur n’est clairement pas la même, et sur ce genre de distrib ca n’aurait pas réellement de sens. Mis à part pour les patchs de sécu, comme pour sudo récemment, ou effectivement tu peux intercaler une série de patchs hors-planning
Les montées de version, en entreprise, ca existe pas
Ca s’appelle une migration, est c’est en mode projet que tu gère ca. Et en général, c’est nettement plus long à traiter que le reste, c’est pour ça que ce genre de distrib offrent du support à 5,7 ou 10 ans
C’est devenu un peu le même cirque tous les six mois avec Windows et ses 2xH1 et 2xH2. À chaque fois, c’est le déluge d’articles sur les nouveaux bugs/nouvelles fonctionnalités (rayez la mention inutile). J’y jette toujours un œil en espérant y voir LA nouveauté que j’attends, comme tant d’autres visiblement, pour les rares fois où je m’en sers : les onglets dans l’explorateur Windows.
Et je bénis ensuite mon Arch préférée qui, elle, reste d’une discrétion rare et bienvenue dans les médias informatiques.
Bah, Arch en elle-même, y a pas grand-chose à en dire : ses nouveautés se résument en fait aux nouveautés des nouvelles versions des paquets qu’elle propose, la plupart du temps.
Parce que pour la distribution elle-même, à part annoncer le passage à la compression Zstandard par défaut au lieu de Gzip pour la génération des initramfs, maintenant que le noyau LTS est passé en branche 5.10, qui prend nativement ce format de compression en charge ; dernière étape d’un processus qui a commencé avec la bascule du format LZMA (.tar.xz) au Zstandard (.tar.zstd) pour la compilation des paquets, ben, y a rarement à dire… Ah, oui : une histoire avec Chromium et la fin dans deux semaines de la possibilité d’utiliser des API que Google veut garder pour son seul Chrome, parce que les mainteneurs du paquet pour Arch auraient eu un accès privilégié à ces API jusque-là et s’inquiètent de savoir ce qu’il adviendra de cet accès, mais ce type d’événement ne survient que très rarement.
Té ! À peine je dis qu’Arch est une distro qui vit sa petite vie tranquille que même pas 24 heures après, je découvre une demande sur le GitLab d’Arch Linux pour limiter la prise en charge des CPU compatibles à la génération « x86-64-v2 » (autrement dit : des CPU prenant en charge des jeux d’instructions supplémentaires apparus il y a environ 10 ans, dont SSE4.2). Personnellement, ça m’embête, car les deux PC utilisés chez moi, et qui sont tous les deux sous Arch, ont des CPU qui ne disposent pas de certains de ces jeux d’instructions (dont le fameux SSE4.2…).
Bon, à l’heure actuelle, rien n’est encore formellement décidé, et il y aurait de toute façon un délai entre l’annonce et la mise en œuvre, mais si ça doit avoir pour conséquence de devoir abandonner Arch Linux pour une autre distribution, voire acheter de nouveaux ordinateurs (forcément sous Windows 10…)… Ce serait une chose dont on se passerait bien, les ordis fonctionnant parfaitement malgré leur âge (12 ans, cette année), et mes parents ayant autre chose à faire que de rechanger leurs habitudes (ils sont déjà septuagénaires…) ! L’abandon du i686 pouvait se comprendre, mais là, même si les premiers CPU x86-64 datent de plus de 15 ans, je trouve cette décision (encore discutée) pas cool de la part d’Allan McRae ! J’ai d’ailleurs lu un message expliquant que ce serait une mauvaise idée, tous les CPU sortis après 2010 ne prenant pas forcément en charge tous les JI requis, même si certains sont déjà vieux d’une décennie, reste à voir si ça suffira à maintenir le statu quo. Parce que même le gain de performances escompté pour la compilation des paquets ne serait pas probant pour justifier une telle décision.
Bonjour, quand j’ai commencé à m’intéresser à Linux je suis allé chez mon marchanddejournaux. En feuilletant plusieurs magazines je me suis aperçu que les articles étaient parfois les mêmes, dans un ordre diffèrent, et parfois je trouvais les mêmes journalistes et propriétaires pour deux magazines différents.
GL HF