Linus Torvalds vient d'annoncer la sortie de la version 2.6.13 du noyau Linux qui est au coeur de toutes les distributions GNU/Linux. Le cycle de test a été particulièrement long puisqu'il n'a pas fallu moins de sept versions de déverminage (RC ou Release Candidate).
Parmi les nouveautés, on remarquera les points suivants :
NdM : merci à YodaBZH pour avoir également proposé une dépêche à ce sujet.
Parmi les nouveautés, on remarquera les points suivants :
- l'inclusion de l'architecture microprocesseur Xtensa pour l'embarqué
- Inotify qui remplace Dnotify pour surveiller en temps réel les événements concernant le système de fichiers
- Kexec qui permet lors d'un crash système de charger un nouveau noyau et de démarrer dessus rapidement sans passer par le BIOS
- Kdump qui facilite l'examen d'un noyau défaillant
- l'horloge d'interruption (Timer interrupt) est désormais configurable et passe par défaut à 250 Hz au lieu de 1000 Hz pour l'architecture i386
- CFQ, l'ordonnanceur d'entrées-sorties (IO scheduler) souvent utilisé par défaut dans les distributions, est grandement amélioré avec sa version 3 et supporte maintenant la gestion des priorités
- les processeurs de type i386 utilisent désormais le code générique de configuration du bus PCI pour découvrir les ressources éventuelles qui n'auraient pas été configurées par le BIOS
- etc.
NdM : merci à YodaBZH pour avoir également proposé une dépêche à ce sujet.
L'annonce sur KernelTrap avec le mail de Linus (1392 hits)
L'annonce sur LWN (572 hits)
Kexec et Kdump (866 hits)
Timer interrupt (667 hits)
CFQ v3 (791 hits)
> Lire la dépêche (129 commentaires, moyenne: 3,7).
Vous avez demandé le commentaire #618600.




RC != deverminage
Je suis surpris de voir les versions RC (candidats de sortie) associes dans la nouvelle avec la notion de deverminage.
Les RC, etant des candidats finaux, ne servent pas a deboguer mais a tester que tout marche, ce qui n'est pas du dout a mon sens la meme demarche. Apres, il peut y avoir des vermines [1] dans une version, qui doivent evidemment etre corrigees mais ce sont en theorie de vermines mineures.
La phase de deverminage a lieu normalement pendant le developpement de nouvelles fonctionnalites, c'est a dire bien en amont de la phase des RC.
[1] : j'avoue que j'ai quand meme du mal a ne pas appeler ca un "bug".
phil.freehackers.org
[^]Re: RC != deverminage
En effet, mais Linux préfère appeler tous ces versions "rc" au lieu de "pre" puis "rc" comme avant.
Il ne faut plus parler de "rc" pour "release candidate".
"ridiculous counter" a par exemple été proposé à la place.
[^]Re: RC != deverminage
Tout ça pour éviter le 2.7...
Vous devriez vraiment visiter Aperture First !
[^]Re: RC != deverminage
En effet, mais Linux préfère appeler (...)
tu voulais dire 'Linus' je suppose...
d'autre part, les nouveautés sont censées être testées dans les branches de test (d'Andrew Morton, Andrea Arcangeli...) donc elles entrent effectivement en phase 'rc' quand elles sont inclues dans la branche principale.
[^]Re: RC != deverminage
Oui, "Linus" en effet.
Arcangeli fait encore des noyau -aa ?
[^]Re: RC != deverminage
en fait, non, Arcangeli n'en fait plus.
[^]Re: RC != deverminage
Bon, on en revient a ma conviction premiere, a savoir que Linus, malgre toutes ses qualites, ne sait pas gerer un systeme de versionnage lisible et propre.
Pour comprendre ce que j'appelle lisible et propre, il suffit de regarder la facon dont fonctionne KDE ou Mozilla. Il n'y a pas 24 numero de versions, et les versions en dev s'appellent beta, alpha ou autre, les versions super stables ont un no de release unique, et les versions presque stables avant la release sont notes RC.
On peut suggerer a Linus que les versions dont les 4 chiffres sont multiples d'un meme nombre premier sont stables, celles ou la sommes des 4 chiffres est divisible par 7 sont des release candidate, et les autres sont instables. Ca me paraitrait a peu pres aussi lisible que le systeme actuel.
phil.freehackers.org
[^]Re: RC != deverminage
Oui mais non, ça ne fonctionne pas, parce que le 2.6.8 serait une release canditate et stable à la fois :p
Je préfères le système de Linus. C'est peut être pas plus lisible, mais c'est plus propre (au sens où il n'y a pas de collisions) :)
Le libre vaincra, tout est déjà joué.
[^]Re: RC != deverminage
2+6+8 = 16
Or 2*7 = 14 ; 3*7 = 21
Donc 16 = 2*7 + 2
Conclusion : le 2.6.8 n'est pas une release candidate et stable en même temps.
[^]Re: RC != deverminage
Ah oui :)
Ne soit pas si pointilleux ! :p
Je voulais dire 2.4.8, mais j'avais peur que ce soit pas assez bleeding edge :)
Il fallait bien sûr comprendre 2.6.6 :) (ou 2.6.20 pour le prochain).
Pardon aux familles, toussa.
Le libre vaincra, tout est déjà joué.
[^]Re: RC != deverminage
Super, on va devenir super fort au buzz de 7 et multiple d'un nombre premier.
Par contre, je recherche une prof pour le buzz de 7 et de 3.
KiKouN, Bucheron-Geek
[^]Re: RC != deverminage
Avec le noyau Linux, les RC c'est tout ce qui se passe après les deux premières semaines de développement acharné d'une nouvelle version. Ça va clairement de l'alpha à la vraie "release candidate", et les premières -rc sortent avec entre autre du code testé de façon anecdotique, voire des problèmes connus. Il est donc très improbable qu'on voit un jour un 2.6.X-rc1 aboutir au 2.6.X directement (alors que dans pas mal d'autres projet c'est l'objectif en général quand cette dénomination est utilisée). Linus a d'ailleurs expliqué maintes fois qu'il s'en foutait pas mal des distinctions (bien subjectives) entre alpha, beta et RC, et que donc il appellerait tout pareil pour ne pas avoir à y réfléchir.
[^]Re: RC != deverminage
Ben oui, c'est Linus, hein...
Vous devriez vraiment visiter Aperture First !
[^]Re: RC != deverminage
Je sais qu'il y a eu des changements ...
Le noyau 2.6.13 est il stable ou faut il attendre le 2.6.14 ?
Tant qu'on est dans la branche 2.6 on est stable ?
Ulrich
Java pas bien, Java l'dire à ma mère.
[^]Re: RC != deverminage
2.6.13 et la branche 2.6 sont considérés comme stable, en particulier avec les 2.6.13.x qui suivront pour fixer qqs bugs.
L'idée des noyaux impairs instables a été abandonnée.
[^]Re: RC != deverminage
Non. Le deuxième nombre, si il est impair indique un noyau instable. (2.3, 2.5). Le troisieme n'indique qu'un numéro de version.
Quelqu'un a le lien sur la politique de versionnage GNU ? il y en a une il me semble qui indique tout cela.
http://astrolix.org
[^]Re: RC != deverminage
Non, on ne parle pas du deuxieme mais du troisieme nombre.
Linus avait proposé il y a qqs mois que 2.6. soit stable alors que
2.6. serait instable.
Ca a été abandonné, tous les 2.6 pair et impair sont considérés comme stable.
[^]Re: RC != deverminage
oops probleme de mise en forme
linus avait proposé :
2.6.pair = stable
2.6.impair = instable
[^]deverminage
[1] : j'avoue que j'ai quand meme du mal a ne pas appeler ca un "bug".
Je voudrais juste rebondir aussi un peu la dessus. Je ne suis pas du tout fan de la Francisation à outrance, si une chose à trouvé appelation via un mot Anglais alors pourquoi necessairement le Franciser, l'important étant que chacun sache de quoi l'on parle. Commencer à Franciser absolument un terme ne témoigne généralement que d'un sursaut d'orgueil inutile.
Je pense, de surcrois que le mot deverminage n'est pas du tout adapté. Je n'ai compris son sens dans la phrase qu'après avoir fait une analogie avec le mot bug (ah en fait vermine est l'appelation Française de bug). Car, dans un dictionnaire :
Vermine :
1. Ensemble des insectes parasites de l'homme et des animaux
2. Péjoratif, ensemble d'individus jugés vils, inutiles ou néfastes.
Ce qui ne correspond pas du tout à l'appelation bug du language informatique, un bug, même s'il est parasite, n'est pas un bout de code vil, nefaste ou inutile, mais plutôt une erreur de code (ou un effet secondaire).
Le terme bug à un sens totalement différent, en France dans l'univers informatique, qu'il avait à l'origine (insecte). C'est justement l'utilisation du terme dans un contexte informatique qui en a déformé le sens. Si l'on retourne en arrière en appliquant spécifiquement un terme Français à l'informatique, c'est tout un apprentissage qui sera necessaire et surtout on va se retrouver avec un terme qui aura plusieurs sens, sans forcèment qu'ils soient lié (le sens vermine est trop fort, à mon avis, pour la description Francisé d'un bug).
Juste un avis en passant :-)
[^]Re: deverminage
mais quand tu francise bug en vermine (qui a quand meme un sens) ou bogue (qui n'en a aucun) y'a pas une des deux versions qui te parrait plus logique que l'autre (et plus marrante surtout)
comme ca après tu traduit bug squashing parti par la fete de la chaasse à la vermine... et le sens est conservé
[^]Re: deverminage
et bugfix par réparation de vermine... c'est joli non?
[^]Re: deverminage
Pourtant, un bogue, c'est vant tout un problème épineux : http://fr.wikipedia.org/wiki/Ch%C3%A2taigner(...)
[^]Re: deverminage
Bof, la fête de l'écrasage de bogues me paraît nettement plus appétissante. Et puis tout programme un tant soit peu important garde toujours des bugs et utiliser un truc infesté de vermine j'y tiens pas tandis que les bogues bien qu'ils posent d'épineux problèmes me restent éminemment plus sympathiques. ;-)
--
Jedaï
[^]Re: deverminage
Sans compter que le terme déverminage réfère à un procédé industriel qui n'a rien à voir avec l'amélioration ou la réparation, comme c'est le cas des bugfixes : c'est un procédé de _destruction sélective_ des éléments non conformes.
Donc déverminer un kernel, ça veut dire en faire exploser les parties qui correspondent pas au spécs. Je suis pas sûr que faire sauter toute la gestion du système de fichiers ext3 à cause d'un bug dans ce code soit une démarche très utile :)
Version de test : ok
Préversion : ok
Version de déverminage : ça ira merci j'aime mon kernel entier
[^]Re: deverminage
oui mais bon, il y a bien longtemps quand les ordinateur n'etais que relais, cela degagé beaucoup de chaleur. Les cafards, voir la vermine causaient des disfonctionnement. Il etait commun alors de parler de bug (sous entendu la bete a fait declenché un mauvais relais)
si la france avait été precurseur (dans quoique ce soit d'ailleur :) ) dans l'informatique cela serait appelé vermine ou cafard.
tiens prend un autre petit jaune
[^]Re: deverminage
Je me demande si l'appellation bug n'est pas plus ancienne encore. Je me souviens d'un bugs bunny ou on voit un vilant "bug" essayer de faire exploser des bombes d'avions militaires. Il me semble du coup que c'est lie a une legende, de petits etres qui viendraient foutre la merde dans un truc cense marcher parfaitement.
Ce que confirme au moins partiellement wikipedia:
http://en.wikipedia.org/wiki/Computer_bug(...)
phil.freehackers.org
[^]Re: deverminage
Erreur, grave erreur !!
En fait d'une légende cartoonesque, c'est en réalité un phénomène qui précéde un peu ce qu'on coutume d'appeler (traduction directe et peu trompeuse), les "urban legends" ou les "hoaxes".
Il y a eu toute une série de "racontars", "histoires de bonnes femmes" à l'époque pré-industrielle aux Etats-Unis d'Amérique (très exactement entre la 1ere Révolution Industrielle (vapeur) et la 2eme RI (electricité)) pour déconsiderer la mécanisation et globalement le progrès technique, que les ouvriers des manufactures ont intuitivement perçu comme des sources de sous-emploi.
Sur les RI, premier choix Google pour les oublieux :
http://membres.lycos.fr/bleu/revolution_industrielle.htm(...)
Idéologiquement, ces manoeuvres (dans un vocabulaire actuel, on évoquerait une "intoxication") auraient en réalité été en corrélation forte avec les mouvements Luddites (mais pas de théorie du complot : les mouvements Luddites sont restés cantonnés en Grande-Bretagne alors que le phènomène que j'évoque est strictement Nord Américain).
http://en.wikipedia.org/wiki/Luddism(...)
Un jour de désoeuvrement, j'avais lu ça dans une publication canadienne francophone, j'avais mêmepris des notes (oui, à la BU de Valrose, il y a des Bandes Dessinées mais aussi des trucs encore plus folkloriques ;); ils s'interrogeaient justement sur une résurgence du phènoméne à l'occasion de la troisième révolution industrielle informatique lié avec un formidable outil de propagation des rumeurs, "L'Internet" (sic) puisqu'on était en pleine bulle....
L'étude candienne reprenait les travaux du Professeur Joseph W. Dante (Senior Lecturer in ethno-psychology ou approchant) de la Christophus Colombus University, qui pensait que si la contestation des machines avait pris en Amérique du Nord une dimension aussi folklorique, voire infantile, c'était largement du à l'atomicité du monde ouvrier (grandes distances entre centre de productions, communications chères et difficile) et à une structuration politique et syndicale bien plus faible qu'en Angleterre.
www.ccolombus-univ.edu/dept/anthsci/lecturers/jw_dante/publications#1984
D'autres travaux avaient, globalement corroboré cette anlayse, ceux des professeurs Barret, Bird et Bird de Stanford sur les premièresusines automobiles du secteur des Grands Lacs (avec des réminescences de culture indienne ["Native American" pour adoipter le jargon PC en vigeur dans les Universités Nord-Americaines] dans des groupes cultures d'origine européenne, si je me souviens bien...)
http://www.stanford.edu/dept/anthsci/faculty.html(...)
Ca passe ce coup-ci, mais n'y revenez plus, ...sed perserverare..
Yoj'
Ps : oups, j'allais oublié le lien vers le papier en question : http://www.imdb.com/title/tt0087363/(...)
[^]Re: deverminage
Et bien en réalité non, bien qu'il soit difficile de répondre à un texte aussi décousu.
Pour en revenir aux bugs, il s'agit tous simplement de l'époque ou l'élèctronique prenait beaucoup de place, il arrivait qu'une petite bête se prommene sur les circuits et autour des lampes et se prenne une décharge élèctrique fatal, causant généralement sa mort en même temps qu'un disfonctionnement (court circuit, lampe grillé etc). Le problème n'était généralement visible que par sa conséquence, l'appelation "bug" pour un problème est apparût à ce moment là.
Actuellement, ceci n'est plus de circonstance, je verrais mal des cafards se prommener dans un Datacenter (mais sait on jamais) et surtout se prommener dans le code du Kernel.
Pour le reste, bien qu'il soit exacte que l'ére de l'industrialisation ait causé différents troubles, et pas seulement chez les ouvriers, et qu'il y ait effectivement eu des mouvement de "casseur de machines", celà n'a pas grand chose à voir avec les bugs...
Quant aux Grimlins, je pense plutôt que l'auteur s'est inspiré de cette histoire de bugs plutôt que l'inverse...
[^]Re: deverminage
En fait le terme 'bug' était déjà utilisé avant comme l'a montré un texte de Thomas Edison envoyé en 1878 à un collègue, et on peut en voir un extrait ici [1]. Cependant le premier bug 'physique' (qui était une mite et non un cafard) a été trouvé précisément le 9 septembre 1945 dans le Mark II de l'université d'Harvard court-circuitant un relais. Les logs écrits par les opérateurs font mention du "First actual case of bug being found" (premier cas effectif de 'bug' ayant été trouvé) ce qui montre encore que le terme était déjà en cours. La mite en question a même été gardée et est exposée dans un musée de la marine en Virginie. Pour une photo de l'insecte légendaire, c'est ici [2] !
[1] http://en.wikipedia.org/wiki/Computer_bug(...)
[2] http://www.history.navy.mil/photos/images/h96000/h96566kc.htm(...)
Ced.
[^]Re: deverminage
La creature du Bugs Bunny est un gremlin: http://www.answers.com/topic/gremlin(...)
[^]Re: deverminage
il y a meme une reference au Bunny dans le lien ci dessus.
[^]Re: RC != deverminage
Personnellement j'utilise le mot bogue et ses dérivés depuis que je suis tout petit...
[^]Re: RC != deverminage
Pour pouvoir trouver les bugs, il faut un maximum de gens pour faire les tests et trouver ce qui ne marche aps. C'est encore plus vrai pour tout ce qui touche au matériel ou un changement qui marchera sur la machine du développeur fonctionnera parfaitement mais risque de ne pas marcher sur une machine avec un matériel légèrement différent.
Donc pour faire un débuggage correct, il faut un maximum de gens qui testent le noyau. Et un des seuls moyens que Linus a trouvé pour attirer un maximum de testeurs, c'est de coller un -rc aux noyaux très tôt, les numéros de version instables ou les -pre ayant plutôt tendance à faire peur à des testeurs potentiels.
Si tu as une solution miracle à ce pb et que ça te tient tant à coeur que l'étiquette -rc corresponde à ce que les gens qui écrivent des jolis livres sur le génie logiciel appellent -rc, je pense que tu devrais en parler à Linus...