J'ai entendu la même chose pour Linux 2.2, 2.4 et maintenant 2.6.
Oui le 2.6 est jeune et moins "stable", "fignolé" qu'un 2.4.
Ça te suprend ?
Pour un 2.6 plus stable en développement il faut attendre l'ouverture de la branche 2.7.
Concrètement, il faut tester le 2.6 et conserver un 2.4 dans le coin s'il y a des problèmes. S'il après l'essai il n'y a pas de problème on peut rester sur un 2.6. Sinon il faut attendre.
Sachant que le 2.4 marche encore très bien et avec plein de drivers, les devs Linux auraient tord de ne pas faire tout de suite "the right thing" au-lieu de se limiter à de petits bug-fixes (si c'est possible...) et de systématiquement tout reporter à la prochaine branche de développement. Ceci impliquerait aussi de ne pas ajouter des fonctionnalités très demandées et qui portants ne représentent pas un gros défi pour les développeurs.
Par exemple tu as été contre l'ajoute ext3 dans linux 2.4.7 ? Tu seras contre l'ajout de Reiserfs v4 dans la branche 2.6 ?
De même les utilisateurs auraient tords de ne pas utiliser un Linux 2.4 stable s'il recherche principalement la stabilité.
C'est quoi un "gros patchs" pour 2.6 ? Souvent se sont des patchs qui ont été longuement testés (par exemple dans la branche mm). Ce ne sont pas des ajouts de dernières minutes ! Ces gros patchs sont aussi rapidement stabilisés dans 2.6 et ne compromettent pas durablement la stabilité du noyau. Jusqu'à maintenant j'ai pas vu de "gros patch" introduit dans Linux 2.6 qui ait été remis en cause par une partie significative des dev Linux.
Reporter tous les "gros/moyen patchs" à la prochaine branche de développement c'est uniquement reporter plus de boulot et avoir une phase de stabilisation de la branche de développement longue/pénible et des sorties plus éloignées de versions "stables". C'est aussi avoir moins de développeurs concentrés pour stabiliser la branche stable (ben oui, il faut ouvrir rapidement la branche de développement car un développeurs qui ne faire qu'attendre des rapports de bug pour faire des petits bug-fix en a rapidement marre).
Je fais confiance en l'intelligence des devs Linux pour décider si un noyau doit être marqué stable ou non et ce qui est permis de faire sur un noyau stable. Se sont des décisions collégiales (dev linux, distributeurs, grands constructeurs, etc...) donc je ne vois pas pourquoi les remettre en cause.
Je fais confiance aux distributeurs pour estimer si un noyau récent peut-être utilisé sur un système critique.
Lorsque Windows 2000 est sorti, beaucoup sont restés plusieurs mois voir années sous NT car la stabilisation de Windows 2000 a été longue. Idem pour Linux. Il n'y a pas de mistère.
Les dèv Linux sont-il "lents" ?
Non. Début 2005 les distributions serveurs/professionnelles pour 2.6 vont remplacer les solutions éprouvées à base de 2.4. Un an pour avoir un 2.6 fignolé ce n'est pas long (voir ce qui ce passe avec les OS proprio pour s'en persuader).
Alors arrêtons de se plaindre surtout que l'on est parti prenante dans Linux 2.6. Si tout le monde testaient Linux 2.5, Linux 2.6 aurait moins de problème (Tu as fait un rapport de bug pour Linux 2.5 ?). Ceci implique d'avoir des serveurs qui tournent sous Linux 2.5, beaucoup d'applications qui tournent sous Linux 2.5, tous les drivers testés par beaucoup de monde avec Linux 2.5, ça implique que les développeurs de drivers doivent maintenir très activement leur driver malgrès les nombreuses modifications qui ont cours dans la branche Linux 2.5 etc... et donc d'avoir des distributions avec Linux 2.5 largement diffusées. C'est contradictoire avec l'appellation "développement" de Linux 2.5.
Impossible d'avoir un Linux 2.6.0 parfait. C'est IMPOSSIBLE.
Puis Linux 2.4 rox toujours.
> Je pense honnêtement qu'il est sorti trop vite*.
Pour toi. Pas pour moi et surement pas pour les développeurs.
Dire que Linux 2.6.0 est sorti trop tôt car il y a beaucoup de modifications dans Linux 2.6.6 c'est comme dire que Mandrake Community sort trop tôt car il y a beaucoup de bug-fix dans Mandrake Official ou que Fedora Core sort trop tôt car RHEL basé sur Fedora Core sort plusieur mois après avec plein de bug-fixe. 2.6.0 indique le début de la stabilisation, que c'est exploitable, que c'est une base de travail pour les autres developpeurs (applis drivers) stable. Ça n'indique pas la fin des développements. Une noyau est très complexe, les conditions d'utilisation sont très très variées, les drivers et les combinaisons de matériel extrèmement nombreuses. Il faut du temps pour arriver à une réelle stabilisation.
Dans ton monde "parfait" il y aurait 2.6.0 et rien après. Faut pas rèver.
Je suis sûre que quelqu'un va me sortir l'exception qui confirme la règle...
J'oubliais : ici j'ai Linux 2.6 depuis 2 mois et pas de problème. Sauf un épisode avec kernel panic lorsque je supprimais un module.
PS : coup de gueule "fatigué" sur les mecs qui critique les devs Linux sans réflechir deux secondes à la complexité ÉNORME de développer Linux. C'est pas tout blanc et tout noir.
# Toujours la même histoire...
Posté par 007 . En réponse au journal Kernel 2.6, 6 mois après. Évalué à 9.
Oui le 2.6 est jeune et moins "stable", "fignolé" qu'un 2.4.
Ça te suprend ?
Pour un 2.6 plus stable en développement il faut attendre l'ouverture de la branche 2.7.
Concrètement, il faut tester le 2.6 et conserver un 2.4 dans le coin s'il y a des problèmes. S'il après l'essai il n'y a pas de problème on peut rester sur un 2.6. Sinon il faut attendre.
Sachant que le 2.4 marche encore très bien et avec plein de drivers, les devs Linux auraient tord de ne pas faire tout de suite "the right thing" au-lieu de se limiter à de petits bug-fixes (si c'est possible...) et de systématiquement tout reporter à la prochaine branche de développement. Ceci impliquerait aussi de ne pas ajouter des fonctionnalités très demandées et qui portants ne représentent pas un gros défi pour les développeurs.
Par exemple tu as été contre l'ajoute ext3 dans linux 2.4.7 ? Tu seras contre l'ajout de Reiserfs v4 dans la branche 2.6 ?
De même les utilisateurs auraient tords de ne pas utiliser un Linux 2.4 stable s'il recherche principalement la stabilité.
C'est quoi un "gros patchs" pour 2.6 ? Souvent se sont des patchs qui ont été longuement testés (par exemple dans la branche mm). Ce ne sont pas des ajouts de dernières minutes ! Ces gros patchs sont aussi rapidement stabilisés dans 2.6 et ne compromettent pas durablement la stabilité du noyau. Jusqu'à maintenant j'ai pas vu de "gros patch" introduit dans Linux 2.6 qui ait été remis en cause par une partie significative des dev Linux.
Reporter tous les "gros/moyen patchs" à la prochaine branche de développement c'est uniquement reporter plus de boulot et avoir une phase de stabilisation de la branche de développement longue/pénible et des sorties plus éloignées de versions "stables". C'est aussi avoir moins de développeurs concentrés pour stabiliser la branche stable (ben oui, il faut ouvrir rapidement la branche de développement car un développeurs qui ne faire qu'attendre des rapports de bug pour faire des petits bug-fix en a rapidement marre).
Je fais confiance en l'intelligence des devs Linux pour décider si un noyau doit être marqué stable ou non et ce qui est permis de faire sur un noyau stable. Se sont des décisions collégiales (dev linux, distributeurs, grands constructeurs, etc...) donc je ne vois pas pourquoi les remettre en cause.
Je fais confiance aux distributeurs pour estimer si un noyau récent peut-être utilisé sur un système critique.
Lorsque Windows 2000 est sorti, beaucoup sont restés plusieurs mois voir années sous NT car la stabilisation de Windows 2000 a été longue. Idem pour Linux. Il n'y a pas de mistère.
Les dèv Linux sont-il "lents" ?
Non. Début 2005 les distributions serveurs/professionnelles pour 2.6 vont remplacer les solutions éprouvées à base de 2.4. Un an pour avoir un 2.6 fignolé ce n'est pas long (voir ce qui ce passe avec les OS proprio pour s'en persuader).
Alors arrêtons de se plaindre surtout que l'on est parti prenante dans Linux 2.6. Si tout le monde testaient Linux 2.5, Linux 2.6 aurait moins de problème (Tu as fait un rapport de bug pour Linux 2.5 ?). Ceci implique d'avoir des serveurs qui tournent sous Linux 2.5, beaucoup d'applications qui tournent sous Linux 2.5, tous les drivers testés par beaucoup de monde avec Linux 2.5, ça implique que les développeurs de drivers doivent maintenir très activement leur driver malgrès les nombreuses modifications qui ont cours dans la branche Linux 2.5 etc... et donc d'avoir des distributions avec Linux 2.5 largement diffusées. C'est contradictoire avec l'appellation "développement" de Linux 2.5.
Impossible d'avoir un Linux 2.6.0 parfait. C'est IMPOSSIBLE.
Puis Linux 2.4 rox toujours.
> Je pense honnêtement qu'il est sorti trop vite*.
Pour toi. Pas pour moi et surement pas pour les développeurs.
Dire que Linux 2.6.0 est sorti trop tôt car il y a beaucoup de modifications dans Linux 2.6.6 c'est comme dire que Mandrake Community sort trop tôt car il y a beaucoup de bug-fix dans Mandrake Official ou que Fedora Core sort trop tôt car RHEL basé sur Fedora Core sort plusieur mois après avec plein de bug-fixe. 2.6.0 indique le début de la stabilisation, que c'est exploitable, que c'est une base de travail pour les autres developpeurs (applis drivers) stable. Ça n'indique pas la fin des développements. Une noyau est très complexe, les conditions d'utilisation sont très très variées, les drivers et les combinaisons de matériel extrèmement nombreuses. Il faut du temps pour arriver à une réelle stabilisation.
Dans ton monde "parfait" il y aurait 2.6.0 et rien après. Faut pas rèver.
Je suis sûre que quelqu'un va me sortir l'exception qui confirme la règle...
J'oubliais : ici j'ai Linux 2.6 depuis 2 mois et pas de problème. Sauf un épisode avec kernel panic lorsque je supprimais un module.
PS : coup de gueule "fatigué" sur les mecs qui critique les devs Linux sans réflechir deux secondes à la complexité ÉNORME de développer Linux. C'est pas tout blanc et tout noir.