Pour résumer, certains gros vendeurs Linux, tels que RedHat ou Mandrake, fixent de nombreux bogues plus ou moins mineurs dans les kernels qu'ils distribuent. Et ces patches, le plus souvent, ne sont jamais intégrés dans la distribution officielle. Après tout, la GPL n'oblige personne à envoyer ses modifications au mainteneur du code.
Est-ce un bien ou un mal, ces patches sont-ils de mauvaise qualité ? En tous cas Gentoo pense que des gens devraient se pencher sur le problème, tels que les membres du Kernel Janitor project.
Aller plus loin
- L'article de Gentoo Linux (2 clics)
- Kernel Janitor project (2 clics)
- La discussion Slashdot (2 clics)
# Perplexe...
Posté par Olivier M. . Évalué à -5.
Ne serait-ce pas pour eux un moyen de ternir l'image des distros "mainstreams" en esperant recuperer des users?
Oh et puis a la limite ca serait de bonne guerre: qu'elle continue! ;)
[^] # Re: Perplexe...
Posté par Anonyme . Évalué à 10.
A mon avis, cet article n'est pas fait pour dénigrer qui que se soit, mais pour faire prendre conscience aux mainteneurs du noyau qu'il y a peut-être des patches a intégrer.
[^] # Re: Perplexe...
Posté par matiasf . Évalué à 10.
Mouais.
Je crois qu'un noyau RH officiel (2.4.9) a pres de 150 patchs (la pluspart ne sont pas specifiques RH) et RH (comme d'autre) se balade dans la mailing kernel et ne demande pas mieux que leur patch soit integre au noyau officiel : Un patch de moins a maintenir :-> .
[^] # Re: Perplexe...
Posté par Nÿco (site web personnel) . Évalué à 2.
[^] # Re: Perplexe...
Posté par Jeannin Loïc . Évalué à 10.
Les kernels hackers de toutes les grosses distributions font deja tout pour se coordoner (a quelques exceptions près), et la chose n'est pas facile.
PS: ici, tout les bugfixes internes sont soumis au kernel maintainer.
# Bof
Posté par matiasf . Évalué à 10.
Serieux, l'article c'est du vent.
Linus est toujours deborde, les patchs sont disponibles pour ceux que ca interressent ...
Enfin, le noyau Linus est surtout une "infrastructure" (propre, multi-plateforme, stable, sure, etc...). Apres les derniers perfectionnements/optimisation (meme dangereux), le petit patch qui va bien, etc... ce n'est pas le boulot des developpeurs de Linux (je pense Marcelo, Linux, Alan).
Si l'experience montre qu'un patch RH (par exemple) est stable et indispensable Alan va le proposer. Il va pas faire genre : pas vu, pas pri.
Ou est le probleme ?
[^] # D'accord.
Posté par nemerid . Évalué à 10.
Libre à chaque distribution de faire les modifications ou de patcher les noyau pour répondre aux spécificités ou aux spécialités qui veulent développer. Je pense par exemple au patch de supermount inclu dans la mdk.
Personnellement, je trouve que le travail autour du noyau est impressionnant et efficace et je ne vais pas du tout dénigrer une nouvelle version du noyau car elle n'a pas intégré une toute nouvelle fonctionnalité interressante que telle distribution propose. Libre à chacun de configurer, patcher, modifier ses sources. C'est bien ça le monde du libre, non ?
[^] # Re: D'accord.
Posté par Anonyme . Évalué à 10.
Encore une fois, cet article (lis le, tu verras, il est pas long), ne dénigre pas l'équipe du noyau.
[^] # Re: D'accord.
Posté par matiasf . Évalué à 10.
Mais que conclure ?
- Que les mainteneurs font mal leur boulot ?
- Que les distribs font mal leur boulot ?
- Que la "communaute" n'"emmerde" pas asser les mainteneurs pour des petits patchs.
Regarde le nouveau 2.4.18 et son nombre de correction apportes (la 2.4 a presque 14 mois !).
Pourquoi un bug-fixe n'est pas applique :
- pas le temps et mineur.
- pas propre.
- travail d'evolution en court la ou est applique le bug-fix.
- perdu ! etc...
Bref il y a plein de raisons bonnes et moins bonnes.
Mais la perfection n'est pas de ce monde.
Une comparaison avec la concurrence commerciale montre de les corrections de bug se perdent moins souvent et sont tres prioritaire.
[^] # Re: Bof
Posté par poil oq . Évalué à 5.
ouais mais pour ça faudrait qu'Alan sache ce que font les mainteneurs du kernel chez RedHat.
ok, je --> []
[^] # Re: Bof
Posté par Laurent Mazet (site web personnel) . Évalué à 1.
2c
Laurent
[^] # Re: Bof
Posté par Val Erie . Évalué à 3.
[^] # Re: Bof
Posté par Emmanuel Seyman . Évalué à 10.
Alan travaille pour Linux UK ou il bosse pour la partie SAV de RedHat. La plus grande partie de son temps est consacrée a l'écriture de drivers pour faire fonctionner tel ou tel materiel sous Linux (d'ou le côté SAV).
Il ne travaille absolument pas sur le kernel de RH, maintenu principalement par un autre employé de RH (dont j'oublie completement le nom) qui travaille aux Etats-Unis.
[^] # Re: Bof
Posté par Laurent Mazet (site web personnel) . Évalué à -2.
A+
Laurent
[^] # Re: Bof
Posté par Jeannin Loïc . Évalué à 1.
Arjan van de Ven
# Pour info : le 2.4.18 est sorti
Posté par matiasf . Évalué à -2.
[^] # Re: Pour info : le 2.4.18 est sorti
Posté par G. R. (site web personnel) . Évalué à 10.
En effet, il manque à celui-ci un bug-fix (mineur certes, mais quand même).
[^] # Re: Pour info : le 2.4.18 est sorti
Posté par Patrice Fortier . Évalué à 10.
Les 2 sont au stade du -rc3, et la correction du -rc4 n'est que ds la 2.4.19-pre1.
Voir kernel-trap pour une explication claire (et slashdot pour vous embrouiller :)).
[^] # Re: Pour info : le 2.4.18 est sorti
Posté par Gaël Le Mignot . Évalué à 10.
Le pb que ce patch corrige est lié à l'exécution de binaires statiques sur certaines archis (x86 non comprises). Donc, pour 95% d'entre nous qui utilise GNU/Linux sur un x86, le 2.4.18-rc3, -rc4 ou -final revient au même.
Pour ceux qui ne sont pas sur x86, il vaut mieux prendre le -rc4.
[^] # non x86
Posté par FRLinux (site web personnel) . Évalué à -1.
Steph
# c'est un avis comme un autre
Posté par Rolland Dudemaine . Évalué à 5.
d'ailleurs, NDLR : Linux is the property of Linus Torvalds.
[^] # Re: c'est un avis comme un autre
Posté par Anonyme . Évalué à -3.
« NDLR : Linux is the property of Linus Torvalds. »
Je trouve étrange qu'il ne délegue pas un minimum. Apparement il est incapable de gérer l'afflux de patchs...
[^] # Re: c'est un avis comme un autre
Posté par Annah C. Hue (site web personnel) . Évalué à 2.
Surtout qu'il existe des outils libres permettant de travailler de manière collaborative, genre CVS quoi... Mais Linus est une tête de mule, donc...
[^] # Re: c'est un avis comme un autre
Posté par Johann Deneux . Évalué à 2.
CVS reste trop limité pour le noyau. CVS marche bien si on a un seul repository, mais pour Linux c'est pas faisable (trop de développeurs).
BitKeeper semble être pas mal de ce côté là. Mais le sujet a déjà été discuté lors d'une autre news...
[^] # Re: c'est un avis comme un autre
Posté par Gaël Le Mignot . Évalué à 10.
Marcelo Tosatti est assez surchargé, et c'est compréhensible, et c'est pour cela qu'Alan Cox maintient sa branche (-ac) dans laquelle il intègre plus de patchs, qu'il soumet à Marcelo lorsqu'il les trouve assez propres et testés (note: je simplifie énormément le fonctionnel réel...)
[^] # Re: c'est un avis comme un autre
Posté par Nÿco (site web personnel) . Évalué à -1.
[^] # Re: c'est un avis comme un autre
Posté par matiasf . Évalué à 2.
Vu la vitesse de developpement il se debrouille bien le gaillard pour tout faire !
> Je trouve étrange qu'il ne délegue pas un minimum.
Il delegue. Pour les personnes de confiance, il applique les patchs les "yeux fermes" (c'est le but de son nouvel outil dont j'ai oublie le nom).
> Linux is the property of Linus Torvalds.
Le nom "Linux" seulement. Libre a toi de faire un fork et d'appliquer les patchs plus vite que lui ... et au moins de facon aussi pertinante et sans te faire allume par les autres developpeurs...
[^] # Re: c'est un avis comme un autre
Posté par pasBill pasGates . Évalué à 2.
Il vaudrait mieux que certains ralent car leurs patchs ne sont pas ou peu pris en compte.
Sinon ca voudrait dire que les mainteneurs du kernel ne regardent pas trop ce qui finit dans le kernel et acceptent n'importe quoi.
Mais bon, le tout est de trouver un juste milieu entre tout accepter tout de suite et ne rien accepter.
# A propos du patch utilisé comme exemple
Posté par Marc Lefranc . Évalué à 10.
# sympa gentoo
Posté par kael . Évalué à 8.
je crois que leurs presence est un plus pour tout le monde, ca fait un peu bouger les choses.
# kernel 2.5 le bug no limit ;))
Posté par Code34 (site web personnel) . Évalué à -2.
ca me balance pas mal d'érreur avec les systèmes de fichier, et l'adressage mémoire des disk ide...
Je sais que les impairs c est des versions instables, je crois que c est pas bon de passer au 2.5 sauf pour les kernels hacker ;()
@+ Code34
[^] # Re: kernel 2.5 le bug no limit ;))
Posté par PLuG . Évalué à 5.
La premiere version (2.5.0) vient directement de la branche 2.4 donc assez stable mais rien a gagner autant utiliser le dernier 2.4.x
Puis les modifications les plus profondes sont faites dès le départ. les premières versions d'un noyau impair sont donc TRES INSTABLES. Quand toutes les modifications "dangereuses" ont été faites, il reste a fiabiliser, puis le dernier 2.5.x deviendra un 2.6.0 (donc les derniers 2.5.X seront utilisables pour les plus avantureux, tous les fs fonctionnent, etc).
En ce moment on est pile poil dans la période ou le 2.5.x est ULTRA INSTABLE. Ce ne serait meme pas étonnant que certaines release ne compilent pas.
<troll>
ca c'est meme vu sur des release dites stables alors vous pensez bien ..
</troll>
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.