Articles : Dernière (longue) ligne droite pour Linux 2.6
Posté par manuel (). Modéré le 02 mai 2003.
La liste des problèmes à corriger avant la sortie de la série 2.6 du noyau est en cours de discussion sur la mailling-list linux.kernel.
En effet, Andrew Morton a posté dans la mailing-list linux.kernel la liste des principaux "must-fix" qui devraient selon lui être resolus pour qu'un noyau estampillé 2.6.0 puisse sortir.
Mon incompétence totale dans le développement du kernel m'empêche de juger si cette liste est "hénorme" ou pas.
A chacun de se faire une idée en lisant le post.
En effet, Andrew Morton a posté dans la mailing-list linux.kernel la liste des principaux "must-fix" qui devraient selon lui être resolus pour qu'un noyau estampillé 2.6.0 puisse sortir.
Mon incompétence totale dans le développement du kernel m'empêche de juger si cette liste est "hénorme" ou pas.
A chacun de se faire une idée en lisant le post.
Le post d'A. Morton (1459 hits)
> Lire la dépêche (25 commentaires, moyenne: 4,3).
Vous avez demandé le commentaire #203550.




Re: Dernière (longue) ligne droite pour Linux 2.6
Ben il reste beaucoup a faire, deja faut qu'ils recuperent/integrent les correctifs eparpilles un peu sur tous les noyaux de devs.
Apres ils ont pas l'air d'etre sur de ce qui reste reelement comme probleme mais juste dont ils sont sur ca fait peur ...
En tout cas ca me jete un froid, je voulait l'essayer bientot
[^]Re: Dernière (longue) ligne droite pour Linux 2.6
Oui il y a beaucoup à faire mais AMA, pour le passage du 2.0 au 2.2 ou du 2.2 au 2.4 la situation devait être similaire.
Perso j'ai testé une partie de la série des 2.5.x et à part quelques petits soucis de compilations et autres dysfonctionnements non bloquant, j'ai pas vu tant de problèmes que ça à l'utilisation.
Bien sûr tout dépend du matériel utilisié, etc...
Donc selon moi il n'y a pas à s'inquiéter d'autant plus que le 2.6 n'est pas prévu pour un bon moment (je ne me souviens plus de la date prévisionnelle).
[^]Re: Dernière (longue) ligne droite pour Linux 2.6
Oui il y a beaucoup à faire mais AMA, pour le passage du 2.0 au 2.2 ou du 2.2 au 2.4 la situation devait être similaire.
Ben de souvenir y avait vraiment pas autant de chose a finaliser pour les precendentes versions.
Enfin c comprehensible vu que du noyau 2.4 il en reste pas grand chose dans le 2.6 :)
Bien sûr tout dépend du matériel utilisié, etc...
C sur, moi vu mon materiel je vait eviter.
Donc selon moi il n'y a pas à s'inquiéter d'autant plus que le 2.6 n'est pas prévu pour un bon moment (je ne me souviens plus de la date prévisionnelle).
Je ne penses pas non plus, vu qu'ils partaient pour le Q4 2003.
Mais ca va faire long...
[^]Re: Dernière (longue) ligne droite pour Linux 2.6
<rabat-joie>
d'autant qu'il faudra attendre un bon 2.6.14 pour avoir un truc stable...
</rabat-joie>
pas taper.
[^]Re: Dernière (longue) ligne droite pour Linux 2.6
pas taper
Aucune raison de taper, puisque je ne doute pas un instant que tu testes chaque jour le noyau 2.5 pour envoyer ensuite des rapports de bugs qui limiteront les dégats :
http://bugzilla.kernel.org/(...)
Et le "HOW-TO" associé (celui qui est livré avec les sources) :
http://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html(...)
:p
[^]Re: Dernière (longue) ligne droite pour Linux 2.6
<menteur éhonté>
oui, absolument. D'ailleurs, dans le soucis de mieux gérer la VM du kernel, je viens de coder un patch en brainfuck qui optimise la bande passante du radiateur sur une configuration bi-proc. je l'améliore et propose le patch dès demain.
</menteur éhonté>
8-p
tout sur le brainfuck : http://www.muppetlabs.com/~breadbox/bf/(...)
c'est lô.
[^]Re: Dernière (longue) ligne droite pour Linux 2.6
Mmmh, du code en Brainfuck dans Linux 2.6? Je te soupconne violemment de l'avoir repompé sur MultideskOS...
[^]Re: Dernière (longue) ligne droite pour Linux 2.6
c'est pas GPL MultideskOs ?
-->
[^]Re: Dernière (longue) ligne droite pour Linux 2.6
Pas nécessairement, le passage de 2.0 à 2.2 c'est fait sans problème et la série des noyaux 2.2 eset rapidement devenue stable. Pour le 2.4 ça a été effectivement la cata. Si on est optimiste on peut penser que les causes des problèmes lors du lancement du noyau 2.4 on été analysées par les développeurs du noyau qui ne les reproduiront pas lors du lancement du 2.6.
[^]Re: Dernière (longue) ligne droite pour Linux 2.6
c'est effectivement à ce passage au 2.4 que je faisais référence....
[^]Re: Dernière (longue) ligne droite pour Linux 2.6
Y a pas le feu au lac ! Bien sûr, nous voudrions tous les futures améliorations tout de suite, mais Linux est utilisé dans de nombreux endroits où la fiabilité et la sécurité sont recherchées. En aucun cas, il ne faudrait que cette réputation justement et durement acquise ne soit remise en cause.
Je pense que l'équipe de développement du noyau fait preuve d'une juste prudence.
[^]Re: Dernière (longue) ligne droite pour Linux 2.6
Je tourne actuellement sur un 2.5.68 ici à mon boulot (juste pour tester) et je n'ai aucun problème particulier. Note que je l'utilise pour de la bureautique et pour tester des solutions de sauvegarde réseau, donc ce que je peux globalement dire, c'est que l'IDE, la mémoire partagée, la VM et la couche réseau fonctionnent bien.
J'ai noté un gain de pratiquement 15% sur les débits des sauvegardes réseau que je fais entre le 2.4.20 et le 2.5.64, donc je peux dire que sur ce qui est de la charge réseau et gestion de mémoire partagée, de nets progrès ont été fait.
Cordialement,
[^]Re: Dernière (longue) ligne droite pour Linux 2.6
J'ai essayé de compiler 2.5.68 en devenant de plus en plus restrictif (j'ai viré le scsi, puis le net, etc...), et j'ai réussi au bout de 5 essais*.
Aprés l'avoir installé, j'ai modifié le menu grub, et j'ai tenté de le faire booter.
Résultat: impossible! Ecran noir.
Je crois que je vais attendre 2.5.70 avant de retenter ma chance.
En attendant, les patches de Kolivas "backportent" les améliorations de la 2.5 sur la 2.4.20:
http://members.optusnet.com.au/ckolivas/kernel/(...)
*
"make-kpkg buildpackage" de debian 3.0 r1 ne semble pas adapté au 2.5, il faut compiler et installer à la main, même si c'est ultra-cracra.
[^]Re: Dernière (longue) ligne droite pour Linux 2.6
En ce qui concerne la compilation d'un noyau 2.5 y a quelques astuces à connaitre que l'on retrouve ici :
http://www.codemonkey.org.uk/post-halloween-2.5.txt(...)
Ton problème y est d'ailleurs listé.
Personnellement, j'ai finallement pris un .config que j'ai trouvé ici sur lequel j'ai pu travailler.
http://lamis.wyrdweb.com/~alfredh/vaio_vx71p/(...)
Au moins, avec ce .config t'es sur de pas tomber sur des problèmes bêtes et connus.
[^]Re: Dernière (longue) ligne droite pour Linux 2.6
Vire le support framebuffer en console de ton boot loader avant de redémarrer. Moi, j'utilise Lilo, donc je ne sais pas trop s'il y a un problème avec grub, mais si je n'enlevait pas l'entrée dans lilo qui appliquait une résolution autre que 'Normal', mon écran était noir jusqu'à ce que X démarre. Et encore, bootant en init 4, j'ai le plaisir de voir X apparaitre, sinon je serais resté comme toi avec un écran noir.
Cordialement,
[^]Re: Dernière (longue) ligne droite pour Linux 2.6
Je bosse dans une société qui fournie des produits sous linux ou j'étais développeur (en partie sur des modification du kernel et de ses modules). J'ai donc une petite expérience qui me permet de dire que effectivement le taf restant est consequent.
le "conséquent" dépendant de l'utilisation que l'on va faire du linux.
En effet, je pense que pas mal de personnes ici tournent avec un kernel 2.5 "non-stable" (en terme de version) et en sont trés contentes.
Le problême va venir de l'utilisation "profesionnelle" (en prod koi :p ) de linux.
Par example, dans ma société, on utilise encore des distribs à base de kernel 2.2 qui n'ont jamais (aprés l'application de toutes les patches correctifs) plantées depuis 19 mois (uptime de 19 mois ). Certes elle sont moins performante sur certaine chose (débit réseau, accés disque) mais elle sont fiable.
Pour passer à un nouveau kernel (2.6) il va faloir lui appliquer toutes les modif (add-on) , toutes les corrections (patch correctif etc ...). valider. Et surtout convaicre que c'est stable. C'est a mon avis ce qui prendra le plus de temps.
Test et intégration en prod prendront au moins , si ce n'est plus, de temps que le developpemtn pur et simple du kernel.