Plus de deux ans après sa sortie et sa nouvelle numérotation qui a beaucoup fait parler d'elle, le noyau 3.0.x ne sera plus mis à jour. La série 3.0.x était une version supportée sur le long terme (LTS - Long Term Support). Greg Kroah-Hartman incite à basculer sur les autres LTS qu'il maintient, soit la branche la plus récente, à savoir la 3.10.x ou à défaut 3.4.x, sachant que cette dernière sera maintenue encore un an. Si vous utilisez directement les noyaux de vos distributions, vous n'êtes que peu concerné(e). Par contre, si vous gérez vous même votre propre noyau, il est temps de basculer !
L'annonce de fin de vie a été faite le 13 octobre dernier lors de la sortie du 3.0.100, rappelée régulièrement (notamment lors de la stable review du 3.0.101 et actée lors de la sortie finale du 3.0.101 :
This is the LAST 3.0.x longterm kernel release.
It is now end-of-life.
I will NOT be doing any more 3.0.x kernel releases. If you rely on the 3.0.x kernel series, you should now move to the 3.10.x kernel series, or, at the worse case, 3.4.x. Note, 3.4.x will only be maintained for one more year, so your time is limited on that as well.
Rappel des date de support des version à long terme
| Version | Mainteneur | Date de sortie | Fin du support (prévu) |
|---|---|---|---|
| 3.10 | Greg Kroah-Hartman | 2013-06-30 | Sep, 2015 |
| 3.4 | Greg Kroah-Hartman | 2012-05-20 | Oct, 2014 |
| 3.2 | Ben Hutchings | 2012-01-04 | 2016 |
| 3.0 | Greg Kroah-Hartman | 2011-07-22 | Oct, 2013 |
| 2.6.34 | Paul Gortmaker | 2010-05-16 | Milieu-2013 |
| 2.6.32 | Willy Tarreau | 2009-12-03 | Milieu-2014 |
Aller plus loin
- Annonce de la fin de vie lors de la sortie du 3.0.100 sur la LKML (32 clics)
- Confirmation de la fin du support lors de la sortie du 3.0.101 sur la LKML (19 clics)
- Bien comprendre les catégories de noyau Linux (101 clics)
- Kernel .org, le site du noyau Linux (41 clics)
- DLFP : Le noyau Linux est disponible en version 3.0 (36 clics)
- DLFP : Linus envisage de changer la numérotation du noyau Linux (79 clics)
# Au risque de paraitre un peu raleur (encore) ....
Posté par totof2000 . Évalué à 6. Dernière modification le 26 octobre 2013 à 12:45.
… je trouve que 3 ans c'est un peu juste pour le monde de la prod.
J'ai travaillé dans certaines structures ou 3 ans, c'est le temps que met un projet pour sortir. 3 ans, c'est la phase de développement + tests (et encore, certains durent plus longtemps). Certains des projets que j'ai vu passer ne sont pas sorti sous GNU/Linux justement parce que les 3 ans de support étaient trop courts. On ne pouvait pas se permettre de relancer une batterie de tests juste avant la sortie en prod. Donc un OS proprio a été choisi.
C'est dommage, parce que je suis sur que je ne suis pas le seul à avoir vu passer ce genre de cas de figure. Si on prend Microsoft par exemple, on en a au moins pour 10 ans; Alors certes 10 ans c'est peutêtre un peu trop long, mais passer de 3 ans à 5 ans, ce serait peut-être un juste milieu ?
Note : j'ai bien vu que le 2.6.32 reste supporté 5 ans, mais ça reste une exception.
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par claudex . Évalué à 10.
Ce n'est pas parce que le support de kernel.org ne dure que 3 ans que c'est le cas pour toutes les distributions. Red Hat, c'est 10 ans, Ubuntu, c'est 5 ans pour les LTS. En plus, ça te fait une base avec la libc prise en charge et des backports de pilotes.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par totof2000 . Évalué à 2.
Avec support pendant 10 ans de la même version du noyau (modulo correction de bugs et de failles de sécu ) ?
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par claudex . Évalué à 6.
CentOS 5 a le kernel 2.6.18 http://mirror.centos.org/centos/5/os/x86_64/CentOS/
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par Sylvain Blandel . Évalué à 3. Dernière modification le 26 octobre 2013 à 14:48.
Confirmation : le support de Red Hat Enterprise Linux est de 10 ans, et peut s'étendre jusqu'à 13 ans.
Je l'ignore. J'imagine mal, vu le nombre de clients qui utilisent leurs produits pour des applications critiques, que Red Hat prenne le risque de changer la version du noyau en cours de route.
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par totof2000 . Évalué à 3.
Dans ce cas je suppose que l'argument avancé pour ne pas utiliser Linux dans certains projets en raison de la faible durée de support ne tient plus. Ca m'avait surpris à l'époque mais je n'avais pas les arguments et les preuves nécessaires, donc j'ai laissé couler.
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par Raphael R . Évalué à 7.
Pour ma culture personnelle, je serais curieux de connaître le contexte du type de projet qui prend 3 ans à prendre forme avec une telle adhérence avec un noyau tout de même. Surtout avec une telle criticité, on doit être assez loin de cas "classiques". Merci d'avance.
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par totof2000 . Évalué à 3.
Le projet en lui-même ne collait pas trop avec le noyau : simplement les gens qui ont travaillé sur le sujet ont simplement argumenté sur le fait que le support noyauu de Linux n'était que de 3 ans, qu'au bout de 3 ans ça les pousserait à changer de noyau et refaire des tests, et ils sont partis sur AIX. Le contexte du projet, je ne m'en rappelle plus trop, ça remonte à plusieurs années déjà (plus de 5 ans). C'était basé sur une base de données Oracle, avec forte volumétrie, et un applicatif par dessus dont je ne me rappelle plus.
Sinon, des projets qui prennent plus de 3 ans à être développés, ce n'est pas si rare. Le dernier projet important sur lequel j'ai bossé a bien mis ce temps entre le moment ou les premiers dossiers sont passés devant moi et le moment effectif de la mise en production. C'était un grops projet de refonte du système de facturation d'une grosse boite. Les bases tournaient sur de l'Oracle RAC sous Linux, mais l'applicatif lui tournait sous HP-UX. La version sur laquelle les tests avaient été faits n'était pas dispo sur Linux, mais la version N+1 l'était. Mais comme le changement de version aurait eu un impact non maitrisé, ils ont décidé de laisser l'applicatif sur HP-UX, et de réserver le passage à Linux lors d'une future évolution.
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par Raphael R . Évalué à 4. Dernière modification le 27 octobre 2013 à 14:48.
Sincèrement, je ne vois pas comment on peut arguer que le support du noyau ne dure que 3 ans, surtout avec RedHat et SuSE pour les professionnels. Et puis ce n'est pas vraiment mieux du coté d'AIX : http://www-03.ibm.com/systems/power/software/aix/support/release_strategy.html ! Ça me laisse à penser que ceux qui ont fait ces choix ne connaissaient pas vraiment l'alternative aux des systèmes fermés du genre AIX.
Je baigne aussi professionnellement dans ce genre d'univers avec du Mainframe, de l'AIX, du Linux, mais aussi de la (grosse) base de données DB2 qui a migré sur de l'Oracle tout ça sous Linux (et même du Windows Server pour d'autre choses). Le problème étant que certaines sociétés savent se montrer "persuasives" envers les décideurs, qui n'ont pas forcement les compétences techniques pour déceler un enfumage caractérisé.
Et puis, bon si ça marche et que tu décides de ne rien changer, que ça soit sur AIX ou Linux, je ne vois pas trop la différence.
Mais bon au moins on a le contexte pour ce faire une idée du choix qui a été opéré.
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par totof2000 . Évalué à 6.
C'est un peu ce que je me suis dit à l'époque, mais comme j'ai vu passer le projet de loin et que je ne participais pas aux instances de décision, je n'ai pas cherché plus loin. Par contre vu que la boite disposait d'un parc conséquent AIX, la maintenance ne posait pas trop de problème, et ce pour une durée de plus de 5 ans. Si c'était aujourd'hui, je pense que je ne laisserai pas passer, et que je ferais une proposition/chiffrage à base de lames sous Linux à côté de la proposition AIX.
Pour le projet sur lequel j'ai bossé, le choix Linux se serait imposé si le soft avait été dispo sous Linux lors du lancement du projet. D'ailleurs, initialement, le projet devait se faire sur Superdome, puis le choix s'est porté sur des chassis C7000 avec lames Itanium et lames x86/Linux. L'intéret est de pouvoir remplacer à l'avenir les lames Itanium par des lames x86 Linux, lorsque la qualif aura été faite.
Aujourd'hui les choses changent. Linux devient de plus en plus le choix No 1, et les autres OS proprios arrivent derrière, avec justification du besoin. On a parfois affaire à des réfractaires à Linux en raison des habitudes, mais ça devient de plus en plus difficile pour eux de se justifier.
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par Xavier Teyssier (site web personnel) . Évalué à 7.
Et bien, petit exemple pratique.
Un matériel livré par un gros industriel. Protocole de communication propriétaire, évidemment.
Une librairie fournie pour communiquer avec ce matériel. Compilée pour le Kernel et la Libc de Red-Hat 7.3. Et surtout, certifiée, pour cet environnement. Le "Certifiée", il signifie que tant qu'on veut du support, on doit utiliser cet environnement.
Et tant que l'industriel fait la sourde oreille pour migrer vers un truc un peu moins obsolète, tu conserves des Red-Hat 7.3 dans ton parc machine :-(
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par Zenitram (site web personnel) . Évalué à 2.
Pourquoi n'avoir simplement jamais regardé les pages de présentations de RedHat (et Suse de nos jours)? les "10 ans" n'a rien de nouveau pour RedHat (c'est même pour ça qu'on met du RedHat partout en entreprise un minimum sérieuse), et le libre permet à bien d'autres personnes que les mainteneurs "officiels" de maintenir un produit (dont redHat lui-même).
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par totof2000 . Évalué à 2.
Parce qu'à l'époque j'étais occupé à autre chose et surtout on ne m'a pas demandé mon avis … Mais comme dit plus haut, aujourd'hui, avec le recul, je ferais autrement.
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par Kerro . Évalué à 4.
Cela dit, ouvrir sa gueule pour « dire la vérité » n'apporte souvent que des choses négatives. La meilleure stratégie lorsqu'on n'est pas aux manettes c'est de la boucler. Sa évite par exemple de se trouver dans la liste noire de son supérieur.
Le chef est payé correctement pour prendre les bonnes décisions. S'il ne prend pas l'avis de ceux qui peuvent savoir, c'est son choix.
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par totof2000 . Évalué à 5.
Effectivement. Par contre si tu apportes une proposition avec les chiffres qui vont bien, les preuves précises et les arguments précis, ça peut passer. Mais ça prend du temps et quand ce n'est pas le dossier ur lequel on t'a demandé de bosser, ça peut poser problème.
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par xcomcmdr . Évalué à 4. Dernière modification le 26 octobre 2013 à 16:12.
Oui ben même chez MS c'est dans ces eaux là, pas beaucoup plus, contrairement à ce qu'on pourrait croire.
Le support de Windows 3.11 fut de 8 ans. (1993 - 2001)
Le support de Windows 95 fut de 6 ans. (1995 - 2001)
Le support de Windows 98 fut de 8 ans. (1998 - 2006)
Le support de Windows ME fut de 6 ans. (2000 - 2006)
Le support de Windows 2000 fut de 10 ans. (2000 - 2010)
Le support de Windows NT 4 fut de de 8 ans. (1996 - 2004)
Et enfin, 11 ans pour Vista
Quant aux versions plus récentes :
Le support de XP fut de 13 ans (c'est une exception dû au retard énorme du projet Longhorn/Vienna qui a finit par un accouchement douloureux de Vista) (2001 - 2014)
Le support de Windows 7 est de 11 ans (2009 - 2020. Pour le moment).
Le support de Windows 8 est pour le moment de 10 ans (2013 - 2023).
En revanche, c'est clairement plus long dans le monde de l'embarqué, comme Windows 3.11 Embedded qui a terminé sa vie en 2011, ou Windows XP Embedded qui finira sa vie en 2016 après 15 ans de service.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par Kerro . Évalué à 10.
Le support que tu indiques est celui d'une version de l'OS, pas d'une version du « noyau ».
Par exemple le support de Windows XP n'est actuellement valable que pour le SP3.
Donc chez Microsoft, c'est beaucoup moins que chez Red Hat.
Cela dit il faut relativiser. Avoir un projet qui dépend d'une version précise :
- soit c'est hyper pointu, donc hyper surveillé. Auquel cas les mecs pointus savent parfaitement faire évoluer les choses
- soit c'est un truc auquel on n'apporte aucune modification, même pas un caractère dans un fichier de configuration. Dans ce cas n'importe quel OS convient puisqu'on ne fait pas de mise à jour (et donc on ne le branche pas sur le réseau, hein, on est d'accord)
- soit le chef de projet est un âne. M'est avis que c'est la majorité des cas
Le reste des cas n'a pas de dépendance à ce point.
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par Zenitram (site web personnel) . Évalué à 4.
RHEL 5.0 (sans updates) est encore supportée? Il me semble que non (il faut la 5.9 oups 5 update 9), donc RedHat "updates" ou Windows "SP", même combat si on veut comparer.
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par Kerro . Évalué à 5.
Je dis peut-être une ânerie, mais une RHEL 5.0 n'a aucune différence d'API, de configuration, de comportement, etc, avec une 5.x.
Alors que Windows XP SP3 n'est pas tout à fait le même OS que celui d'origine. Il y a des choses en plus (ça ne compte pas si ça ne casse rien), mais il y a quelques détails qui sont modifiés : machine virtuelle Java d'origine désinstallée, navigateur web différent, pare-feu activé par défaut lors de l'installation du SP, blocage par défaut de l'usage excessif de la mémoire, nouvelle interface pour certaines applications intégrées, etc etc.
Si on a une application réellement dépendante de la version, alors passer au SPx nécessite de faire bien attention.
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par Zenitram (site web personnel) . Évalué à 2.
Il me semble que les "updates" RHEL font à peut prêt la même chose (des "détails" plus ou moins importants suivant à qui on cause, par exemple tout ce que tu as dit sur le SP3 est vrai mais ne changeait rien pour pas mal de monde qui n'ont vu aucune différence, tu en entends plus parler que pour RHEL surtout parce qu'il y a plus d'utilisateurs, et en plus plus ou moins calmes quand la MAJ pose problème par rapport à des admins RHEL qui vont fouiller le web avant de reposer la question une 1000è fois)
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par claudex . Évalué à 4.
Tu as un exemple de changement dans RHEL5 qui n'est pas une mise à jour qui ne casse pas la compatibilité. Du genre, règles de pare-feu modifier, cassage d'API… Parce que vu les versions des paquets, ça ne me semble pas du tout comparable à XP SP3.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par totof2000 . Évalué à 3.
Je ne sais pas pour XP ou Windows Enterprise seever, mais par contre je me rappelle avoir eu de mauvaises surprises lors de l'application de SP sur NT4 à l'époque ou je faisais du Windows. Et je sais que sur SAP R/3 par exemple, il était hors de question d'appliquer un SP tant qu'il n'avait pas été validé par SAP.
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par Zenitram (site web personnel) . Évalué à 3.
Reste à savoir ce qu'on fait avec les "updates" de RedHat : tu les appliques sans tester? La ou tu utilisais une version x.y, tu installes le jour suivant une version y.x+1 sans tester?
Admettons que tu es utilisateur de matahari
CentOS 6.4 Release Notes
"As announced in the CentOS-6.3 Release Notes matahari is now deprecated. CentOS-6.4 ships one last update that should remove all remains of matahari." (donc j'imagine que si tu installes direct la 6.4, tu vas plus rien trouver, même si j'ai pas testé)
Ouch, te voila sans ton logiciel que tu utilisais, ton logiciel ne marche plus, au secours. Comme windows donc.
J'ai pris au pif la dernière CentOS, juste pour dire que des modifications, ça arrive. Dans 99% des cas, tout fonctionne correctement, SP (j'ai installé bon nombre de SP sans aucun problème rencontré) ou update (plus rare certes pour moi, sans problèmes pour moi certes, mais peux-tu garantir que personne n'a eu de problèmes?)
Je ne veux pas "casser du Linux", juste faire remarquer que sous Linux il y a aussi des updates (c'est vicieux les updates, ça prévient moins qu'un SP) qui peuvent casser des choses (tiens, ma clé SSH ne marche plus depuis le dernier apt-get update…).
Je conçois qu'on trouve que les updates sont moins violents que les SP, n'empèche c'est pas le truc parfait qui bouge rien de rien non plus.
PS : je ne connais pas la politique de SAP vis à vis des updates RHEL.
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par totof2000 . Évalué à 2.
Par principe, sur un système de prod, je désactive les updates automatique, je passe chaque modif sur un système de test, que ce soit du Redhat, ou n'importe quoi d'autre. Et bien souvent, je me renseigne par rapport à ce qui tourne dessus : est-ce que l'on garde le support éditeur des softs par dessus l'OS si on applique les updates ? En général, c'est oui, mais il arrive que ce soit non dans l'immédiat. Et ça c'est valable tant pour les softs windows que les softs Unix/Linux.
C'est même plus vicieux que sous Windows : vu que toute la distrib est gérée par le sustème d'update, lorsque tu lances un apt-get update (ou un yum update), tu peux te retrouver avec un truc cassé sans savoir quelle mise à jour a pêté quelque chose : mise à jour des couches basses OS ou mises à jour applicative : c'est pour ça que je préfère de loin la gestion de l'OS "à la BSD" ou il y a séparation des diverses parties que tu peux mettre à jour progressiveent : plus facile de savoir à quel endroit ça pête.
On est d'accord, et pour celà, les mises à jour automatiques devraient être désactivées sur tout système de prod un tant soit peu sensible.
A noter qu'avec Yum, il est possible de faire un retour arrière sur les installation de packages. Je me demande si c'est possible avec les mises à jour (pas encore testé), et si on a la même chose sur Debian.
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par claudex . Évalué à 3.
Je ne sais pas avec yum avec apt-get, c'est assez simple de faire des mises à jour sélectives à coup de
apt-get install.« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par Psychofox (Mastodon) . Évalué à 3.
SAP est pénible avec tout le monde. Ils ne certifient leurs applis que pour des versions mineures des distributions par exemple.
[^] # Re: Au risque de paraitre un peu raleur (encore) ....
Posté par Maxime (site web personnel) . Évalué à 1.
Et avec Windows, le noyau n'est pas du tout touché pendant 10 ans ?
# Vue graphique des versions
Posté par François Perrad (site web personnel) . Évalué à 10.
Ce dessin permet de se rendre compte du travail fourni par Greg.
Je mets à jour régulièrement d'autres graphes, voir http://fperrad.github.io/graph-versions/linux.html
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.