Avec le nouveau modèle de développement, les Linux 2.6 officiels ne sont pas exempts de petits bugs irritants.
Il semble que l'excellentissime Alan Cox, qu'on ne prétente plus (pour ceux qui ont oublié, c'est le barbu qui fait peur aux enfants), a décidé de créer une branche "plus stable" de Linux 2.6 :
http://mir3.ovh.net/pub/linux/kernel/people/alan/linux-2.6/2.6.9/(...)
Le changelog :
http://www.ussg.iu.edu/hypermail/linux/kernel/0411.3/0683.html(...)
La dernier version est ac12. Mais la dernier version stable est le ac11 !
Arjan Van De Ven a fait des rpm :
http://mir3.ovh.net/pub/linux/kernel/people/arjan/ac/(...)
C'est yumifié.
Attention, les deux étants Red Hat, les paquets rpm sont probablement uniquement "compatibles" FC2 et 3. Pour info et pour ceux qui utilise Fedora, FC2 et 3 utilisent déjà ac10.
Journal Branche Linux 2.6 stable
2
déc.
2004
# Rectifications...
Posté par Guillaume POIRIER . Évalué à 6.
À proprement parler, Alan Cox n'a jamais vraiment prétendu que "'2.6.x' est tellement buggé que bah, il faut que je m'y colle"...
Ce qu'il serait plus correct de dire, c'est que Alan a toujours aimé débugger du Kernel, et qu'il a toujours fait ça sur les versions 'stables' du kernel. (au moins sur toute la série 2.x.y, avant je sais pas, j'étais pas là! ;-)
Il se trouve aussi qu'Alan a pris un an sabbatique pendant lequel il a été bien moins actif du côté du kernel, aussi on peu comprendre pourquoi le 2.6.x a 'dérivé' sans son oeuvre bienfaitrice...
Il faut tout de même bien comprendre qu'un Kernel, tout comme n'importe quel logiciel, comporte forcément pas mal de bugs, certains moins gênant que d'autres, aussi c'est assez normal qu'un gars aux yeux de lynx comme Alan puisse en trouver à la pelle... ça veut pas forcément dire que 2.6.x est à chier, ça veut surtout dire que la branche -ac, c'est bon, mangez-en ! ;-)
J'espère ainsi avoir rétabli [un peu] la réalité
[^] # Re: Rectifications...
Posté par galactikboulay . Évalué à 7.
Cet avis n'engage que moi, mais je trouve que la qualité sur les derniers 2.6 s'est quand même un peu dégradée (USB, gravure, ACPI, ...). Là, actuellement, tout patch jugé stable est intégré directement dans la branche stable, alors qu'il est préférable de prendre du recul et de l'avoir en premier lieu dans une version dite instable. Parce que quand le patch est effectivement bon, ben tant mieux, mais quand ça provoque des effets de bord, et qu'on est obligé d'avoir le dernier kernel à jour (tout simplement pour les updates de sécurité), on est bien coincé.
[^] # Re: Rectifications...
Posté par itstimetogo . Évalué à 1.
bidouillages ?
> sur la branche censée être stable du kernel
C'est toi qui le dit. Linus a clairement défini ce qu'est Linux 2.6 et en quoi c'est différent de Linux 2.4 ou 2.2.
> je pense qu'il serait préférable que les développeurs
Je pense qu'ils sont mieux placés que toi ou moi pour savoir ce qu'ils doivent faire.
> mais je trouve que la qualité sur les derniers 2.6 s'est quand même un peu dégradée (USB, gravure, ACPI, ...).
Pour USB et ACPI, je ne sais pas. Pour "gravure" (hors bug mineur), c'est une "feature" qui rend la "gravure" plus sûre lorsqu'on n'est pas root (et sans suid).
Ça demande de mettre à jours les applis. cdrecord grave maintenant parfaitement sans droit root.
> Là, actuellement, tout patch jugé stable est intégré directement dans la branche stable
Non. Il faut l'accord de Linus ou de plusieurs développeurs à la fois.
> alors qu'il est préférable de prendre du recul
C'est le role de la branche -mm.
> Parce que quand le patch est effectivement bon, ben tant mieux, mais quand ça provoque des effets de bord
Si tout le monde pouvait avoir ta science pour savoir de façon définitive ce qui est stable et ce qui ne l'est pas...
> et qu'on est obligé d'avoir le dernier kernel à jour (tout simplement pour les updates de sécurité)
Mauvais choix. Le kernel vanilla n'a pas les derniers updates de sécurité. D'ailleur la branche -ac fixe quelques trous de sécurité.
> on est bien coincé.
On voit rapidement ton paradoxe. Tu veux Linux 2.6 pour les dernières nouveautés et tu ne veux pas que Linux 2.6 évolue. Si la stabilité est important pour toi, utilises Linux 2.4.
[^] # Re: Rectifications...
Posté par galactikboulay . Évalué à 10.
Je donne mon opinion d'utilisateur. Je préférerai l'ancien système stable/instable qui laissait le choix.
Accessoirement, d'un point de vue dév, j'ai déjà fait du code noyau, et j'ai eu par ex. des problèmes avec un changement d'API pour RCU (Read-Copy-Update) qui faisait qu'un patch qui passait nickel pour un 2.6.7 ne passait plus pour un 2.6.8. C'est ce genre de changements qui est pénible.
Tu vas me dire que je n'ai qu'à produire un patch pour chaque version de noyau, certes, mais quand on te fournit des modules pour une certaine version et que ça ne marche plus sur la version suivante à cause du-dit changement d'API, ben tu l'as dans l'os.
> Pour USB et ACPI, je ne sais pas.
Et bien tu devrais te renseigner. J'ai demandé à pas mal de personnes ce qu'ils pensaient du 2.6, toutes ont eu des pb avec au moins un de ces sous-systèmes.
Pour la gravure, je ne parlais même pas de cette fonctionnalité, je parlais de pouvoir graver tout court.
> Non. Il faut l'accord de Linus ou de plusieurs développeurs à la fois.
Oui, d'où le terme "jugé". Ce n'est pas parce que c'est validé par plusieurs personnes - même si c'est Linus ou Alan Cox que c'est forcément stable. Je t'invite à lire les échanges d'Alan Cox avec un Bartlomiej Zolnierkiewicz à propos de la pile IDE, ils se sont bien pris la tête.
> Si tout le monde pouvait avoir ta science pour savoir de façon définitive ce qui est stable et ce qui ne l'est pas...
J'ai prétendu que je le savais mieux que d'autres ? non, apprends à lire.
> Mauvais choix. Le kernel vanilla n'a pas les derniers updates de sécurité. > D'ailleur la branche -ac fixe quelques trous de sécurité.
Et bien AMHA c'est un problème. Le kernel vanilla *devrait* être à jour de ce point de vue là. Interroge-toi sur le fait que nombre de personnes ne savent pas à quoi servent les branches -mm -ac -ck, et j'en passe.
> Tu veux Linux 2.6 pour les dernières nouveautés et tu ne veux pas que Linux 2.6 évolue. Si la stabilité est important pour toi, utilises Linux 2.4.
Je veux un 2.6, parce que les perfs pour les machines que j'ai ne sont pas optimisées avec un 2.4 (multiprocesseur + hyperthreading), et surtout que le support de certains matériels n'est pas présent dans le 2.4.
[^] # Re: Rectifications...
Posté par Philippe MAES (site web personnel) . Évalué à 3.
Je suis plutot d'accord avec toi dans le sens ou à chaque fois que j'essaye une nouvelle version du 2.6 j'ai de plus en plus de 'trucs' qui ne fonctionnent plus ou mal (USB2, ieee1394, gravure...).
Personnelement, je preférais en tant qu'UTILISATEUR l'ancien systeme de developpement du noyaux.
[^] # Re: Rectifications...
Posté par ZeroHeure . Évalué à 4.
>D'ailleurs la branche -ac fixe quelques trous de sécurité.
Et bien AMHA c'est un problème. Le kernel vanilla *devrait* être à jour de ce point de vue là. Interroge-toi sur le fait que nombre de personnes ne savent pas à quoi servent les branches -mm -ac -ck, et j'en passe.
Je suis plutôt de ton avis (sur l'ensemble de tes propos), mais là ceux qui se téléchargent un noyau non fourni par leur distribution n'ont pas vraiment l'excuse de ne pas savoir. Oui oui ça se discute, c'est limite, mais comment tenir compte de la volonté et du comportement de tous?
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Rectifications...
Posté par itstimetogo . Évalué à -4.
Tu as dis :
- "je pense qu'il serait préférable que les développeurs mettent en route une version 2.7 qui pourraient accueillir toutes les nouvelles idées/fonctionnalités/......"
et non :
- "j'aimerai que..."
C'est ton opinion sur ce que devrait faire les développeurs.
Ton "opinion d'utilisateur" sur ce que devrait faire les développeurs ne prend pas en compte que c'est une version de Linux qui a des objectifs clairement définis, définit collégialement, et que tu devrais connaitre !
> Je préférerai l'ancien système stable/instable qui laissait le choix.
Tu l'as toujours. Il y a le noyau 2.4 !
> C'est ce genre de changements qui est pénible.
On ne fait pas évoluer les choses sans les changer. C'est comme ça pour Linux 2.6. Tu devrais le savoir. Si tu n'aimes pas, tu passes ton chemin.
> mais quand on te fournit des modules pour une certaine version et que ça ne marche plus sur la version suivante à cause du-dit changement d'API, ben tu l'as dans l'os.
Ce n'est pas l'objectif du noyau vanilla et tu devrais le savoir !
Si tu ne veux ça (c-à-d le linux 2.6 "touch"), prends une distribution qui garantit qu'il n'y a pas de changement d'API. Il y a RHEL, SuSE Enterprise, etc.
Et si tu es pingre il y a whitebox (qui est une repompe de RHEL).
> Et bien tu devrais te renseigner.
OK, mais si tu me payes pour supporter ta bécane.
Le libre c'est comme ça. Les développeurs bossent sur ce qu'ils veulent et n'ont pas à répondre à désirs/besoins seulement car ça te fairais plaisir.
Je n'ai pas de problème avec USB et ACPI.
> Pour la gravure, je ne parlais même pas de cette fonctionnalité, je parlais de pouvoir graver tout court.
Ben ça marche "tout court" avec Linux 2.6.9.
> Et bien AMHA c'est un problème. Le kernel vanilla *devrait* être à jour de ce point de vue là.
Ce n'est pas l'objectif du noyau vanilla.
Si tu n'aimes pas ça, prend une distribution qui fait ce boulot.
> Oui, d'où le terme "jugé". Ce n'est pas parce que c'est validé par plusieurs personnes - même si c'est Linus ou Alan Cox que c'est forcément stable.
C'est stable quand toi tu as validé ?
Désolé, mais je préfère faire confiance au jugement de Linus ou Alan Cox.
> Je t'invite à lire les échanges d'Alan Cox avec un Bartlomiej Zolnierkiewicz à propos de la pile IDE, ils se sont bien pris la tête.
Linux 2.6 n'est pas "un long fleuve tranquille".
T'es surpris ?
> J'ai prétendu que je le savais mieux que d'autres ?
Mais tu ne propose rien. Tu critiques et c'est tout.
> Et bien AMHA c'est un problème. Le kernel vanilla *devrait* être à jour de ce point de vue là.
C'est comme ça avec Linux 2.6 vanilla et *tu* devrais le savoir. Si tu n'aimes pas alors prends autre chose.
> Interroge-toi sur le fait que nombre de personnes ne savent pas à quoi servent les branches -mm -ac -ck, et j'en passe.
Tu ne connais même pas la politique de la branche officielle Linus. Alors prends une distribution supportée qui fera ce boulot.
> Je veux un 2.6, parce que les perfs pour les machines que j'ai ne sont pas optimisées avec un 2.4 (multiprocesseur + hyperthreading)
Alors je rigole fort.
T'as quoi comme serveur si exigent pour aller cherche +5 voir 10 % (grand maximum) en perfo ?
Pour ton info, l'hyperthreading est dans RHEL 3 (Linux 2.4) et le multiprocesseur est bien supporté par Linux 2.4.
> et surtout que le support de certains matériels n'est pas présent dans le 2.4.
Voilà. Le paradoxe est de retour.
Tu veux que les développements aillent vite (pour ton matériel récent) et en même temps tu veux alourdir le développement. Ce qui aura pour conséquence que les développement iront moins vite.
Tu devrais te décider.
Si au moins tu pouvais trouver aussi à jours que Linux 2.6 et plus stable pour légitimer tes critiques...
Tu préfères quoi à Linux 2.6 ?
- OpenBSD ?
- NetBSD ?
- Solaris ?
- Windows ?
C'est facile de critiquer et de faire du "moi je moi je" ou "je pense que...".
T'es pas obligé d'utiliser Linux 2.6. Si Linux 2.6 est "mauvais", tu trouveras mieux ailleurs. Si tu ne trouves pas mieux ailleurs alors Linux 2.6 est _excellent_ et tes critiques sont nulles et non avenue.
Jute, j'ai oublié qu'il y a SuSE Enterprise 9 avec Linux 2.6 pour te satisfaire :
http://www.novell.com/fr-fr/products/linuxenterpriseserver/features(...)
Offre le premier serveur Linux* d'entreprise bâti autour du puissant kernel Linux 2.6
Voilà le problème : Il n'y a pas consensus au sein de Linux en upstream pour faire un Linux 2.6 rock-solide qui ne bouge pas et qui répond à tes besoins. Par contre, contre du pognon, tu peux trouver chaussure à ton pied et aussi avec Linux 2.6. Et comme tu as semble-t-il un serveur hyper-critique, hyper-utiliser tu peux bien débourser un peu d'argent.
Chez moi j'ai Fedora basé sur Linux 2.6.9-ac10. Au boulot j'ai RHEL basé sur Linux 2.4. Fedora c'est le développement rapide et je ne pleurniche pas en tapotant avec les pied par terre car Fedora n'est pas utilisable comme un serveur hyper-critique, hyper-utilisé et qui ne doit pas subir de changement d'API.
Lorsqu'on veut un truc, il faut déjà bien choisir ce qu'on prend. T'as fait l'erreur de prendre Linux 2.6 vanilla. Il ne tient qu'a toi de corriger ton erreur ou d'aider Alan Cox :-)
Et oui, c'est libre.
[^] # Re: Rectifications...
Posté par itstimetogo . Évalué à -2.
- "lorsque tu as trouvé l'OS hyper stable de tes rèves, prends du hardware supporté par l'OS et pas du hardware uniquement supporté par la dernière version de Linux 2.6. C'est le minimum à faire lorsqu'on prétend gérer un serveur hyper-critique et hyper-utilisé."
Un admin qui ne fait pas ce minimum, est un admin nul.
[^] # Re: Rectifications...
Posté par Colin Leroy (site web personnel) . Évalué à 5.
Linux n'a jamais eu d'API interne stable. Le seul truc qu'ils font attention à laisser stable c'est les API userland (syscalls, ioctls). Et ce n'est pas pour faire chier le monde, c'est pour éviter de traîner des couches et des couches de compatibilité legacy comme d'autres OS (Solaris, Windows) doivent le faire.
[^] # Re: Rectifications...
Posté par Christophe Fergeau . Évalué à 4.
> branche stable, alors qu'il est préférable de prendre du recul et de l'avoir en
> premier lieu dans une version dite instable. Parce que quand le patch est
> effectivement bon, ben tant mieux
L'intégration d'un patch dans une branche instable pour le tester avant de l'intégrer dans une branche stable, ça suppose qu'il y a suffisamment de personnes qui teste la branche instable pour qu'il y ait au moins 1 personne qui aura des problèmes quand le patch est pas bon, et qui signalera le problème. A mon avis ça serait loin d'être le cas, cf la difficulté qu'a eu linus à faire tester suffisamment les derniers noyaux 2.5, voire les 2.6test
[^] # Re: Rectifications...
Posté par Colin Leroy (site web personnel) . Évalué à -3.
Plutôt que d'étaler glorieusement ton avis, tu aurais mieux fait de commencer ta branche -galactikboulay avant qu'Alan Cox ne revienne...
[^] # Re: Rectifications...
Posté par itstimetogo . Évalué à 3.
Oui. Mais le 2.6 n'est pas géré comme le 2.4 ou le 2.2.
D'ailleurs il faut voir comme la branche 2.7 "traine" à arriver et le rythme "infernal" des modifs de 2.6 qui ne sont pas toujours très "catholiques" au premier abord pour une branche stable.
> qu'il a toujours fait ça sur les versions 'stables' du kernel.
Oui mais là ce n'est pas la même chose. Les anciens -ac étaient du débug et de l'expérimental. Un peu comme la branche -mm. Quoique la branche -mm soit plus aventureuse (suffit de comparer la taille des patchs...). La branche actuelle est à 98 % du débug uniquement.
Alan faisait toujours de l'avance de phase avec sa branche -ac. Lorsqu'on voit le changelog de l'actuellement branche -ac, la volontée est clairement le débug et vérifier que tout est remonté en upstream (branche Linus).
Alan étant aussi un développeur Red Hat, son travail dépend aussi des besoins de Red Hat. Possible qu'il donne actuellement un coup de main pour RHEL4 et que les prochains -ac soient plus risqués.
# Heu...
Posté par Calim' Héros (site web personnel) . Évalué à 5.
C'est le pere noel ?
[^] # Re: Heu...
Posté par Dragon . Évalué à -1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.