Les 2.6 n'ont jamais prétendu respecter l'ancien mode de dévelopement, mais on toujours fonctionnés en suivant le nouveau, même si tout ça n'a été officialisé que récemment. Alors des petits changement d'API, effectivement, il y en a eu et il y en aura encore. Ça n'a rien de contradictoire avec une certaine idée de la stabilité, ça dépend vraiment de la définition qu'on adopte. Celle considérée par les dévelopeurs du noyau n'est pas "rien ne bouge", mais plutôt "tout marche". En ce sens, la plupart s'accordent à dire que le 2.6 est la branche la plus stable qu'ils aient connu, alors qu'elle est effectivement assez mouvante.
> Trop régulierement des éléments experimentaux y sont introduits.
Les éléments introduits au fil des 2.6 ne sont pas expérimentaux. Ils sont passés par la branche -mm avant d'être intégrés, et ça n'est que là qu'ils étaient expérimentaux.
Ce qu'il faut bien voir, c'est qu'il n'y a aucune garantie qu'une mise à jour entre deux noyau 2.6 vanilla puisse être faite sans la moindre conséquence sur le reste du système. C'est plutôt du côté des noyaux des distributions qu'il faut se tourner si on veut pouvoir faire des mises à jour sans se poser de question. C'est à eux de fournir des ensemble noyau + drivers externes + outils userspace cohérents. L'utilisateur qui par contre se jette tête baissée sur le dernier vanilla le fait à ses risques et périls. Cette situation était clairement assez criticable tant qu'elle n'était pas annoncée noir sur blanc, mais maintenant que c'est fait, je n'y vois rien à redire.
Un truc intérressant à noter aussi c'est qu'il est serieusement envisagé, si il y a de la demande, de faire des backports des correctifs les plus importantes entre les versions mineures des 2.6 vanilla. Ainsi, si on est en 2.6.x et qu'il y a une nouvelle faille corrigée, ça ne serait pas en 2.6.(x+1) qu'il faudrait upgrader (enfin pas si on veut une stabilité au sens "rien de neuf"), mais plutôt en 2.6.x.1. Ça fournirait bien la même garantie de stabilité que des noyaux de distrib, mais sans imposer toutes les features additionnelles et parfois douteuses qui sont souvent livrées avec.
[^] # Re: Question ?
Posté par tgl . En réponse à la dépêche Nouveau modèle de développement pour Linux. Évalué à 10.
> Trop régulierement des éléments experimentaux y sont introduits.
Les éléments introduits au fil des 2.6 ne sont pas expérimentaux. Ils sont passés par la branche -mm avant d'être intégrés, et ça n'est que là qu'ils étaient expérimentaux.
Ce qu'il faut bien voir, c'est qu'il n'y a aucune garantie qu'une mise à jour entre deux noyau 2.6 vanilla puisse être faite sans la moindre conséquence sur le reste du système. C'est plutôt du côté des noyaux des distributions qu'il faut se tourner si on veut pouvoir faire des mises à jour sans se poser de question. C'est à eux de fournir des ensemble noyau + drivers externes + outils userspace cohérents. L'utilisateur qui par contre se jette tête baissée sur le dernier vanilla le fait à ses risques et périls. Cette situation était clairement assez criticable tant qu'elle n'était pas annoncée noir sur blanc, mais maintenant que c'est fait, je n'y vois rien à redire.
Un truc intérressant à noter aussi c'est qu'il est serieusement envisagé, si il y a de la demande, de faire des backports des correctifs les plus importantes entre les versions mineures des 2.6 vanilla. Ainsi, si on est en 2.6.x et qu'il y a une nouvelle faille corrigée, ça ne serait pas en 2.6.(x+1) qu'il faudrait upgrader (enfin pas si on veut une stabilité au sens "rien de neuf"), mais plutôt en 2.6.x.1. Ça fournirait bien la même garantie de stabilité que des noyaux de distrib, mais sans imposer toutes les features additionnelles et parfois douteuses qui sont souvent livrées avec.