Logiciel : Le noyau Linux 2.6.25 est disponible
Posté par patrick_g (page perso, ). Modéré le 17 avril 2008.
Peu avant la sortie du 2.6.24 les divers mainteneurs des sous-systèmes ont indiqués sur la liste de diffusion du noyau leurs intentions sur les patchs suffisamment stables pour pouvoir migrer de la branche de test d'Andrew Morton (la -mm) vers la branche de Linus. La période d'intégration de ces milliers de patchs doit durer deux semaines et elle permet l'ajout de toutes les nouveautés prévues dans le nouveau noyau.
Cette fois-ci le démarrage a été rendu un peu plus lent car la plupart des développeurs participaient à la conférence Linux en Australie à la fin du mois de janvier. Une fois la fenêtre d'intégration d'environ quinze jours refermée la saga des "releases candidates" a pu commencer.
![[en]](../images/en.png)
Les nouveautés du noyau 2.6.25 (3383 hits)-
Le bilan des ajouts partie 1 (508 hits)
-
Le bilan des ajouts partie 2 (324 hits)
-
Le bilan des ajouts partie 3 (331 hits)
-
Les prévisions pour l'avenir de Linux (1172 hits)
> Lire la dépêche (134 commentaires, moyenne: 4,1).
Vous avez demandé le commentaire #923654.
Run by 
Cette page a été générée par Templeet en 0.0872s (dont 0.0082 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Coder pour linux
L'histoire de l'inclusion de la pile CAN me rappelle les problèmes que l'on a ici sur l'inclusion de chose dans Linux. Je me rappelle aussi les appels/voeux pieux de Linux concernant le fait d'intégrer de nouveau codeur plus gentiellement/facilement.
1 an, semble énorme pour beaucoup d'entreprise. J'ai lu un peu les threads d'échange pointé par les différentes articles.
So we have to be patient and i personally have to perform the task "It is therefore your responsibility to make the work interesting to the networking developers and fun to review." given by David Miller ...
But this task is hard to perform, when there's no feedback from the netdev guys and when it's not very interesting by design (of CAN) ;-( I have no idea when PF_CAN becomes that interesting to the major players like Patrik McHardy and David Miller, so that the code gets finally reviewed. I assume that is no sufficient answer for your question. Btw. i backed off for two weeks now and i'm patient.
J'aime particulièrement le passage ou il est dis que les nouveau venu doivent montrer du code intéressant pour être revu... J'imagine la tête des équipes soft avec ce genre de "requirement"....
J'ai vraiment l'impression qu'il y a une différence entre la volonté affiché d'intégrer et d'accueillir les nouveaux venu et la réalité. La réalité, c'est la liste des mainteneurs juste en dessous de Linus, qui décide réellement si votre sous-système est digne d'intérêt. Et si vous devez passer par plusieurs mainteneurs, vous êtres mal barré (au hasard: le mainteneur d'une sub-arch arm qui réfère au mainteneur arm qui réfère à Linus).
En gros, si la boite n'emploie pas un dev déjà reconnu au niveau de Linux, elle perd un temps fou pour son problème soit pris en compte ou son code revu.
En tout cas, cela n'encourage pas du tout à pousser sa boite à se mettre dans la boucle...
[^]Re: Coder pour linux
En passant.
De la dépêche :
> c'est à cette tâche que se sont attelés des ingénieurs de la société Volkswagen.
CAN est aussi utilisé par PSA et BMW. Je le sais car je l'ai vu.
Mais probablement par beaucoup beaucoup d'autres pour ne pas dire tout le monde.
Il y a un autre type de réseau qui marche une peu comme CAN, c'est le réseau VAN. Ce dernier n'est pas temps réel et selon mes derniers infos est utilisé par (seulement ?) PSA et Renault. Notons que PSA et Renault utilise CAN et VAN en même temps dans une voiture. CAN est pour le moteur, les trucs de sécurité, etc. VAN est pour le confort.
L'industrie de l'automobile est énorme et si Linux s'y installe c'est formidable.
[^]Re: Coder pour linux
En tout cas il faut eviter les Ford vu que eux ils ont choisi Windows. De tout de facon avec la qualite et la consommation de cette marque on peut tout a fait utiliser l'expression: "Qui se ressemble, s'assemble!".
[^]Re: Coder pour linux
Selon mes infos le VAN est en cours d'abandon même chez PSA au profit du CAN.
[^]Re: Coder pour linux
Ce n'est pas drame. J'imagine que CAN a aussi bien évolué. Je l'ai connu en 1998 :-)
[^]Re: Coder pour linux
Le CAN bus est aussi très utilisé dans l'automation industrielle.
Et en automation, je sais qu'il existe des automates programmables (plutôt petits pc dédiés) qui tournent sous Linux, mais je n'ai jamais eu l'occasion d'en utiliser.
J'ai par contre utilisé une marque concurrente qui n'utilise que win xp embeded, et bien comment dire... Ça plante, comme le pas embeded...
Ha, la joie d'avoir un client qui attend impatiemment que sa machine toute neuve produise à 150% de rendement tout en regardant par dessus mon épaule pour constater que ce p...n de pc vient encore de se vautrer...
http://www.linuxdevices.com/news/NS8034346535.html
[^]Re: Coder pour linux
1 an, semble énorme pour beaucoup d'entreprise.
Tu as déja essayé de proposer quelque chose pour Windows ou MacOS X?
1 an, c'est rien pour une entreprise...
Et si vous devez passer par plusieurs mainteneurs, vous êtres mal barré (au hasard: le mainteneur d'une sub-arch arm qui réfère au mainteneur arm qui réfère à Linus).
Mais que proposes-tu à la place?
Le noyau n'est pas un petit truc, et est utilisé par beaucoup de monde...
Linux T. ne peux pas gérer >1000 développeurs.
Pour info, en entreprise un chef à entre 5 et 20 personnes en dessous de lui (20, c'est déjà énorme!).
Donc je ne vois pas ce qu'il y a de gênant pour une entreprise de devoir passer par x valideurs, ils ont l'habitude.
En gros, si la boite n'emploie pas un dev déjà reconnu au niveau de Linux, elle perd un temps fou pour son problème soit pris en compte ou son code revu.
Tu peux déja commencer par proposer un patch que tu maintiens toi-même, pour montrer qu'il est utile à plus de monde que toi-même.
Et après, ca viendra avec le temps...
Désolé, ce n'est pas rose certes, mais je ne vois pas de meilleure solution.
C'est bien joli de critiquer, mais sans proposition (faisable hein) pour faire mieux, ça ne montre pas un réalisme...
[^]Re: Coder pour linux
ET oh il s'appelle LinuS avec un S pas un X. Ca fait plusieurs fois dans les commentaires sur une seule news que je vois l'erreur!
[^]Re: Coder pour linux
Arghhh... Les gens qui font ce genre d'erreur m'énervent un peu, c'est lourd qu'on prenne le droit de changer un prénom comme ça, et... je fais l'erreur.
Arghhh... (bis)
[^]Re: Coder pour linux
"1 an, c'est rien pour une entreprise..."
Tu me fais marrer (jaune) ! Et je bosse ou à ton avis dans mon garage ?
Je bosse pour une boite pour qui 6 mois de plus est déjà trop, et la boite est énorme.
Et après, ca viendra avec le temps...
C'est bien ça le problème !
Faire son truc dans son coin et balancer ce qui est fait en open source, c'est déjà fait. Mais il y a une perte en ligne monstrueuse sur les fonctionnalité par rapport à ce qui touche le kernel vanilia.
Vu le niveau "générique" de ta réponse, je crois que tu es bien loin du dev kernel, et du dev dans une grosse boite qui aimerait avoir plus de code en mainstream.
[^]Re: Coder pour linux
Et que proposes-tu pour que ton code soit intégré, tout en ne pourrissant pas le noyau avec le code de 10 000 autres gars comme toi qui veulent la même chose et qui font le truc crade car "pressé par Time-To-Market"?
La critique est facile, mais ferais-tu mieux...
La façon de faire actuelle a montré, elle, sa rentabilité.
[^]Re: Coder pour linux
Non il a raison, il n'y a rien de plus sensible qu'un kernel dans un OS. Tu ajoutes qqe chose qui parait insignifiant et hop tu te retrouves avec des perfs qui chutent dans des scenarios particuliers auquel tu n'as jamais pense mais qui sont courant dans certaines industries, des instabilites dues au manque de connaissance de certains concepts sur lesquels est base le kernel, ...
C'est pas par hasard qu'un kernel bouge lentement et que les nouveautes cuisent pendant un moment avant d'etre autorisees partout, que ce soit dans le monde proprio ou OSS/libre
Si on laissait le kernel etre dirige de la meme maniere que Gnome ou OpenOffice, tu te retrouverais regulierement avec un kernel de developpement qui plante ta machine, qui potentiellement te fait perdre tes donnees, ... et cela ralentirait le developpement tout en reduisant le nombre de testeurs car ils ne voudraient plus se retrouver si regulierement avec des problemes. Parce qu'avoir l'outil de configuration de Gnome qui explose c'est une chose, avoir ton kernel qui explose c'est autrement plus serieux.
[^]Re: Coder pour linux
Je comprends tout à fait les problèmes des dev de kernel. Mais sa réponse ne parlait pas vraiment de ça.
De plus, le genre de code kernel dont tu parles est le coeur de Linux, pas vraiment les drivers par exemple. Or, c'est le plus gros du code.
[^]Re: Coder pour linux
En gros, si la boite n'emploie pas un dev déjà reconnu au niveau de Linux, elle perd un temps fou pour son problème soit pris en compte ou son code revu.
C'est exactement comme quand tu travailles avec un sous-traitant, tu n'accèdes pas directement au développeur, tu passes par un ou plusieurs niveaux de filtrage selon la taille du sous-traitant/fournisseur et ça n'a jamais empêché les boites de bosser. Je ne vois pas pourquoi ça serait différent dans ce cas ?
[^]Re: Coder pour linux
Parce que "l'autre" manière de travailler c'est de faire son patch dans son coin pour ses clients et ne pas perdre du temps à chercher à l'inclure.
L'effort supplémentaire pour le faire inclure est souvent jugé hors de proportion et surtout ne respecte pas les planning des boites (même si je comprends que les mainteneurs s'en foutent).
[^]Re: Coder pour linux
L'intérêt de faire inclure son patch, c'est aussi de refiler le bébé de l'adaptation aux versions successives du noyau à d'autres. On comprend que les autres exigent un niveau de qualité correcte.
Pour l'entreprise c'est donc un investissement.
Le problème c'est que pour beaucoup d'entreprise "la qualité", ne concerne pas le produit mais toute la paperasse lié au processus, à des normes ISO machin chose, ... Alors que pour le noyau la qualité ça concerne le code !
bertrand perrotte
webmaistre http://canoe.kayak.free.fr/
[^]Re: Coder pour linux
Je suis tout à fait d'accord, surtout avec ton dernier point :)
Mais il y a des cas ou le premier point est moins vrai typiquement : le cas de CAN, ou les mainteneurs s'en foutent, ou le cas de hardware super complexe pour des gros drivers bas niveau, là il faut déjà avoir le matos et ensuite pourvoir comprendre la doc.
[^]Re: Coder pour linux
Le monde de l'automobile intègre de plus en plus de systèmes informatiques complexes, aux mainteneurs de voir s'ils veulent abandonner ce secteur à Windows. Si la réponse est non ils ne vont pas se foutrent longtemps du CAN ...
[^]Re: Coder pour linux
Il ne faut pas tout mélanger.
Il y a aura (ou a déjà) des systèmes informatiques "lourds". Genre qui font lecture de DVD, etc.
Mais il y a plein de système très léger et qui doivent le rester pour des raisons de fiabilité, de prix, de temps-réel, etc. Il est certain qu'un Windows ne va pas être utilisé dans ce cas.
[^]Re: Coder pour linux
Et en quoi j'ai dis le contraire?
[^]Re: Coder pour linux
En même temps des gens qui mettent Windows à toutes les sauces (même les plus inadaptées), ça existe. Même chose pour Linux d'ailleurs, sauf que ce dernier s'assaisonne plus facilement.