Greg Kroah-Hartman est le mainteneur de la branche -stable du noyau Linux. Dans son annonce du 2.6.32.58, il a indiqué qu'il passait la main à Willy Tarreau pour veiller sur cette branche 2.6.32 et il vient de publier une rétrospective très intéressante à propos de ce noyau.
NdM : merci à patrick_g pour son journal.
Greg dévoile que le choix du 2.6.32 par la plupart des « grandes » distributions (SLE11 SP1, Debian Squeeze, RHEL 6, Oracle Linux 6, et Ubuntu 10.4 LTS) est le résultat d'une cabale secrète de la part des hackeurs du noyau. Après s'être mis d'accord entre eux sur le choix de cette version :
Nous sommes tous rentrés dans nos sociétés respectives et nous avons commencé à planter les graines pour laisser filtrer l'information selon laquelle, peut-être, le noyau 2.6.32 serait un bon choix pour baser notre distribution.
Cette campagne a si bien fonctionné que j'ai dû me retenir d'éclater de rire quand un manager nous a annoncé dans un meeting, « nous avons décidé que le noyau 2.6.32 serait le meilleur choix, qu'est-ce que les ingénieurs pensent à ce sujet ? ».
Après la sortie, le 2 décembre 2009, de ce noyau 2.6.32, Greg a centralisé les patchs de maintenance pendant 823 jours. Durant cette période, ce sont 3 349 patchs qui ont été appliqués sur l'arbre des sources (plus que pour aucun autre noyau -stable).
Cette expérience lui a servi pour concevoir son nouveau plan de maintenance à long terme des noyaux Linux. Un noyau spécifique sera choisi chaque année et cet élu, baptisé -longterm, sera maintenu pour les deux années suivantes. Selon lui ce mode de maintenance est plus adapté aux besoins des sociétés du secteur de l'embarqué et il ne pénalise pas les distributions des entreprises classiques.
Greg a quitté son job chez Novell/Suse et a été engagé par la Linux Foundation pour s'occuper de ce projet « Long Term Support Initiative ». De nombreuses entreprises ont décidé de participer à cette initiative et utiliseront les noyaux LTSI : Hitachi, LG Electronics, NEC, Panasonic, Qualcomm Atheros, Renesas, Samsung, Sony et Toshiba.
Le premier noyau a bénéficier de cette maintenance est le 3.0 (nous en sommes actuellement au 3.0.20).
À la fin de sa rétrospective, Greg Kroah-Hartman tient à remercier spécifiquement les développeurs Debian qui l'ont aidé dans son travail de maintenance. Je trouve que c'est un magnifique hommage et, en dépit des statistiques des contributions, une indication de l'importance que continue d'avoir Debian par rapport aux distributions commerciales :
Je voudrais personnellement remercier les développeurs Debian en charge du noyau, plus spécifiquement Ben Hutchings, Maximilian Attems, Dann Frazier, Bastian Blank, et Moritz Muehlenhoff. Ils ont fait bien plus que ce qu'un développeur « normal » aurait fait, dénichant les patchs à chaque nouvelle version sur kernel.org et dans chaque noyau et chaque bugzilla des différentes distributions, les rétroportant vers le noyau 2.6.32, les testant et enfin me les envoyant pour intégration.
Leur dévouement envers la communauté de leurs utilisateurs est incroyable pour un tel groupe de développeurs « bénévoles ».
Je suis fermement convaincu que, sans leur aide, le noyau 2.6.32 n'aurait pas eu le succès qu'il a rencontré. Les utilisateurs des produits Red Hat et Suse ont une sacrée dette envers eux.
Aller plus loin
- Rétrospective du noyau 2.6.32 par Greg Kroah-Hartman (413 clics)
- Annonce du noyau 2.6.32 sur LKML (65 clics)
- Proposition de nouveau plan de maintenance à long terme (58 clics)
- Long Term Support Initiative (41 clics)
- Journal à l'origine de la dépêche (118 clics)
- Dépêche LinuxFr sur la sortie du noyau 2.6.32 (123 clics)
# Hommage pour Debian ou critique...
Posté par mazarini . Évalué à 3.
de ceux qui ne remontent pas leurs corrections ?
PS : http://www.debian.org/donations
# Innovant
Posté par vjm . Évalué à -4.
Encore un petit effort et ils auront recréé la différence entre -STABLE et -CURRENT des *BSD ou entre noyaux Linux 2.4 et 2.5 !
[^] # Re: Innovant
Posté par claudex . Évalué à 5.
Je ne comprend pas, -CURRENT ce n'est pas la version de développement? Ici, on parle juste des versions maintenues.
« 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: Innovant
Posté par Joris Dedieu (site web personnel) . Évalué à 9.
Tout à fait et -STABLE est la branche de stabilisation. Pour être plus précis en ce qui concerne FreeBSD :
CURRENT est la branche de dev (tag=.). Actuellement on est en 10-CURRENT. C'est la que se prépare les futures versions, susceptible de péter de temps à autres
STABLE (tag=RELENG8 par exemple). Version de _stabilisation en rolling release. La compatibilité est assurée tout au long de la branche (actuellement tu peux utiliser RELENG_7, RELENG_8, RELENG_9). Dans ton uname tu verras quelque chose comme 8-STABLE … La compatibilité est garantie mais pas la stabilité.
RELEASE (tag=RELENG_9_0) les versions réputés stables avec un support dans le temps plus ou moins important. Passer d'une RELEASE à l'autre au sein de la même branche (8.1 à 8.3 par exemple) ne casse pas la compatibilité. Les mises à jour de sécu sont ensuite déclinées sous forme de patchset (-p6 par exemple).
Tout cela se retrouve dans le uname.
Eg:
FreeBSD plop.titi.com 8.1-RELEASE-p6 FreeBSD 8.1-RELEASE-p6 #1: Mon Oct 10 15:49:18 CEST 2011 root@plop.titi.com:/usr/obj/usr/src/sys/GENERIC amd64
Liens :
- http://www.freebsd.org/releng/
- http://svnweb.freebsd.org/base/
Exercice : cette machine est à jour mais présente 8.1-RELEASE-p6 au lieu de p8. Pourquoi ?
[^] # Re: Innovant
Posté par gik . Évalué à 3. Dernière modification le 09 mars 2012 à 22:11.
Je dis peut-être une bêtise mais je crois qu’après les mises à jour de sécurité le seul moyen d'afficher la version la plus récente du patchset c'est de recompiler le noyau, ce qui n'est pas forcément nécessaire à chaque fois, puisque lesdites mises à jour ne concernent pas forcement celui-ci.
[^] # Re: Innovant
Posté par Loïc Blot (site web personnel) . Évalué à 1.
Pour passer au patchset suivant, tu peux recompiler le noyau, effectivement, en le patchant dans un premier temps, puis en recompilant celui-ci ainsi le userland.
La plupart du temps les patchsets sont appliqués en majorité sur le userland, tout du moins sur 8.2 c'est ce que j'ai pu observer.
Si tu ne compiles pas ton noyau, ce qui est fortement envisageable et conseillé dans un environnement de production ne nécessitant pas l'optimisation des appels système, il suffit simplement de taper freebsd-update fetch install ce qui aura pour effet d'inspecter et passer ton système de 8.2-p4 à 8.2-p6 par exemple. Il faudra en revanche rebooter pour que le nouveau noyau soit pris en compte, tout comme sous Linux.
Veepee & UNIX-Experience
[^] # Re: Innovant
Posté par bubar🦥 (Mastodon) . Évalué à 2. Dernière modification le 09 mars 2012 à 23:00.
Le # indique le numéro de compilation, sur FreeBSD également ?
Sinon pour linux, on n'est pas forcément obligé de rebooter, kexec fonctionne très bien (il y a des limitations avec certains matériels, bien que je n'en ai pas vu moi même, y compris avec un blob nvidia il y a longtemps, mais je me doute que ça existe bel et bien, sinon ça serait plus largement utilisé). Sur une machine virtuelle, par contre, ça serait vraiment dommage de se passer de kexec : là, c'est juste parfait. Non ?
[^] # Re: Innovant
Posté par navaati . Évalué à 1.
kexec ça permet de laisser tourner les process en userland comme si rien ne s'était passé ? Pasque je crois pas et du coup la différence avec un vrai reboot est pas énorme.
[^] # Re: Innovant
Posté par NanoTech . Évalué à 7.
Avec kexec, tous les processus sont quittés. On économise juste le POST du BIOS et GRUB/LILO.
Par contre, sous Linux, on a aussi Ksplice, qui permet de patcher le noyau sans rebooter.
Ce n'est pas très compliqué pour les patches qui ne modifient pas de structure de donnée, le principe étant de placer quelques NOP avant le début de chaque fonction, pour pouvoir placer un JMP vers l'implémentation alternative, après l'avoir chargée en mémoire.
Par contre, lorsque des structures de données sont modifiées (12% des patches critiques entre 2005 et 2008), il faut du code supplémentaire gérer la conversion des structures de données.
[^] # Re: Innovant
Posté par Krunch (site web personnel) . Évalué à 6.
Un peu comme Windows en fait.
http://blogs.msdn.com/b/oldnewthing/archive/2011/09/21/10214405.aspx
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Innovant
Posté par barmic . Évalué à 2.
Oui et ? Ce n'est pas parce que la gestion des projet se rapproche que les fonctionnalités aussi.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Encore de l'anti-update...
Posté par isildur37 . Évalué à -10.
Mouais, encore une façon d'avoir des systèmes pas a jour, avec des trous et autres failles…
Car les MAJ du noyau ne servent pas uniquement à supporter la dernière carte graphique DeLaMortQuiTue, mais aussi et surtout à améliorer la sécurité, corriger les défauts d'architecture…
[^] # Re: Encore de l'anti-update...
Posté par Jérôme Asseray . Évalué à 10.
Donc les patchs et autres correctifs de sécurité sont bien appliqués à ce noyau.
Seules les nouveautés et/ou évolution d'architecture ne sont pas ajoutées, non?
Cette version est donc à destination d'une population précise d'utilisateurs…
[^] # Re: Encore de l'anti-update...
Posté par Loïc Blot (site web personnel) . Évalué à 2.
La différence entre les noyaux est effectivement la compatilibilité matérielle et le changement dans le code de certains sous systèmes du noyau, notamment. Un Noyau LTS sera patché pour combler des failles de sécurité et/ou stabiliser certains éléments. Si tu souhaite supporter des devices plus récents tu devras forcément passer à un noyau supérieur.
Veepee & UNIX-Experience
# faute fréquente
Posté par erf3d . Évalué à 4.
Cette campagne a si bien fonctionné que j'ai dû me
Juste parce que de plus en plus de personnes ne font pas attention à la différence
entre l'article "du" et les formes du verbe devoir ("dû", "dus", "due", "dues").
[^] # Re: faute fréquente
Posté par BAud (site web personnel) . Évalué à 2.
corrigé, merci.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.