Un slashdotter signale un article intéressant paru sur le site de Gentoo Linux.
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.
Le gourou de l'Open Source, Eric Raymond, a dit que la création de patchs du noyau Linux est en crise et il a renouvelé son appel pour que quelqu'un viennne en aide à Linus Torvalds en tant que "penguin patch lieutenant."
S'exprimant lors d'une conférence organisée par le "UK Unix Users Group" à Londres mercredi soir, Raymond précise que les patchs du kernel sont l'un des vestiges de la centralisation dans le développement Open Source.
Il a dit aussi que Linus a "atteint ses limites de stress" et qu'une personne seule ne pouvait traiter tous les patchs proposés par les développeurs du noyau.
Les patchs, dont beaucoup pourraient aider au développement de Linux, ne sont pas pris en compte et ce sans raison apparente a observé Raymond.
Avis aux amateurs!
"à l'aide, je suis troublé !" Tel est le message posté par Anton Blanchard sur LinuxKernelMailingList.
En effet, compiler un noyau x86 en moins de 8 secondes, sur des machines ppc64 (et en gcc s'il vous plait !), c'est pas banal.
Le message de la fin :
" make[1]: Leaving directory `/home/anton/intel_kernel/linux/arch/i386/boot'
128.89user 40.23system 0:07.52elapsed 2246%CPU (0avgtext+0avgdata 0maxresident)k0inputs+0outputs (437084major+572835minor)pagefaults 0swaps"
Nombreux sont les débutants qui ont peur de recompiler un noyau Linux par eux-mêmes et qui finissent le plus souvent avec un kernel panic lors de leurs essais.
Je viens de complètement réécrire la troisième édition de mon article sur la compilation et l'installation d'un noyau Linux 2.4.x
Commentaires bienvenus.
ELKS sort sa première bêta !
ELKS est un petit noyau linux destiné à tourner sur des 8088 et supérieurs (linux ne fonctionne que sur des processeurs 32bits (NdM: ou plus)).
Note du modérateur : ELKS = « Embeddable Linux Kernel Subset », sous-ensemble du noyau Linux embarquable. Le Changelog commence en 1995 apparemment.
KernelTrap nous informe que Robert Millan a pu faire tourner le système d'exploitation GNU (basé sur le Hurd et sur GNU Mach, donc) avec l'émulateur Bochs. Une image était proposée, mais, à la demande de Robert, elles ont été supprimées temporairement, avant qu'il
ne soit en mesure de fournir des images stables.
Note du modérateur: il faut cependant noter que Bochs est extrêmement
lent, et que le système GNU n'étant pas lui-même un modèle de rapidité à l'heure actuelle, le tout ne sera vivable que pour un court essai. Essayez-le en vrai!
Mardi soir est sorti une nouvelle version bêta du noyau 2.5, la version 19.
Cette fois-ci, contrairement au noyau 2.2.21, le ChangeLog est disponible, et face à la liste conséquente de corrections et autres, je vous renvoie à la lecture de ce ChangeLog.
A noter quand même quelques points importants :
- nouveaux drivers pour le FB,
- quelques corrections pour le support de l'USB...
enfin bon, le CL est quand même plus explicite que moi ;-) !
En parallèle au Preemption Patch dont on a beaucoup parlé ici, le Low-Latency Patch vise le même but mais pas de la même manière. Pour nous éclairer, Clark Williams (architecte système chez Red Hat) nous a concocté un petit test des 2 patch sur un noyau 2.4.17.
Après les explications indispensables (et claires, même en anglais), des chiffres étonnants sont fournis (graphiques à l'appui) !
Le grand vainqueur est le duo Low-Latency+Preemption qui tire le meilleur parti des 2. C'est donc en toute logique que les mainteneurs des patch (Robert Love et Andrew Morton) travaillent sur une fusion.
Linux n'a pas fini d'accélérer...
Chaque mois de janvier, Linux Magazine dresse un état du noyau Linux, apportant aux lecteurs les dernières informations sur les modifications/améliorations du noyau à venir.
Pour 2002, la boule de cristal est plus évasive que d'habitude principalement par ce que les travaux sur le noyau 2.5 n'ont pas réellement commencé. Néanmoins, quelques lignes directrices semblent se détacher. Les auteurs de cet article ont discuté avec les développeurs majeurs afin d'en savoir un peu plus sur leurs projets et leurs espoirs pour le noyau 2.5.
NdR: L'article est deja sorti dans la version papier du magazine, mais vient d'être mis sur le site Internet.
SecurityFocus nous propose de jeter un oeil au patch Openwall. C'est un patch apportant au noyau Linux des fonctionnalités de sécurité. Cet article explique comment installer ce patch et nous en présente les pricipales fonctionnalités.
La fonctionnalité la plus connue d'Openwall est certainement l'option qui consiste à rendre la pile noyau non exécutable. Mais il ne fait pas que cela, vous le découvrirez dans cet article.
Ce qui est dommage c'est que ce patch n'est pour l'instant disponible que pour les versions 2.2.x du noyau (même si les travaux pour le 2.4.x sont en cours). Ceux qui utlisent les noyaux 2.4.x se tourneront peut-être plus facilement vers le patch Grsecurity.
NdR : Ceci est une adaptation/traduction du début de l'article...
NdM : Grsecurity r0x0r !
Une nouvelle version du noyau 2.2 vient de sortir lundi soir : la 2.2.21.
Le Changelog n'est pas encore disponible mais si cette version est là, c'est surement pour de bonnes raisons ;-)
Vu que de nombreux serveurs GNU/Linux tournent sous Debian Potato et, en attendant la version finale de la Woody, ce noyau devrait interesser beaucoup de monde.
Note du modérateur : j'imagine que ce noyau doit au moins corriger la faille de sécurité sur d_path(). Comme il s'agit d'un problème de sécurité, il est possible que le Changelog soit censuré pour cause de DMCA (comme pour le 2.2.20). Néanmoins The Freeworld.net ne contient pas (encore ?) le Changelog du 2.2.21
Alors que les grands de ce monde sont réunis au Canada pour un sommet du G8 sous haute surveillance, les grands de notre monde les imitent à Ottawa :)
Linux Weekly News réalise un résumé de chaque journée. Lundi la mémoire virtuelle, le portage sur le Hammer d'AMD, les entrées/sorties en bloc, les paramètres du noyau, et les modules. Mardi les besoins pour les bases de données, la lettre au père Noël de HP, le module de sécurité chargeable, les entrées/sorties asynchrones, le SCSI.
A noter des absents de marque pour chaque sommet: José Bové (qui fait du roquefort) pour cause de prison et Keith Owens (qui fait du boudin).
Un gel des fonctionnalités du noyau 2.5 (futur 2.6) a été décidé pour Halloween. Après cette date, seuls des corrections de bugs ou des améliorations mineures seront acceptés dans ce qui deviendra le noyau 2.6.
Pour voir la liste des modifications majeures déjà effectuées, et celles qui sont prévues, suivez le lien sur kernelnewbies. Pour résumer: beaucoup de parties ont été réécrites (block io, ide, framebuffer, ...) et pas mal de patchs externes ont été intégrés ou le seront (preempt, ALSA, ACL, rmap, ...)
Comme dit le Changelog :
« 2.4.19-rc5 was released as 2.4.19 with no changes. »
Au programme, un nombre de corrections de bogues très important. On relèvera notamment des mises à jour importantes de Netfilter, avec notamment l'inclusion du port forwarding local.
Ce noyau, qui m'a l'air d'être aussi interessant que l'avait été le kernel 2.2.18 à sa sortie, est enfin là et il est peut-être pour longtemps le dernier noyau 2.4. Ne serait-ce que de part le temps qu'il a mis à sortir ;-)
Bryan W. Headley vient de mettre en ligne une page consacrée au développement d'un module pour la tablette graphique DigitalEdge.
Prévu pour la version 2.5 du kernel, il a été backporté pour la 2.4.19
Il est à noter que Bryan bosse sous Debian, aussi, certains paramètres peuvent différer (point de montage de dvfs, xie.so dans l'arborescence de XFree...)
N'hésitez pas à tester et à soumettre vos bug-reports.
Le nouveau noyau Linux 2.5.35 intègrera enfin User-Mode Linux. Il a en effet été inclus dans l'arbre BitKeeper.
User-mode Linux permet au noyau de fonctionner comme un processus séparé, en mode utilisateur sur un système Linux. Ceci rend possible notamment le suivi de ce noyau avec gdb, et ainsi autant faciliter qu'accelérer le développement de pilotes de périphériques et autres composants du noyau, tout ceci en limitant considérablement les risques de corruption de données ou de dommages du système "réel".
Il semble donc que Linus ait décidé d'intégrer le système de fichier journalisé XFS au prochain noyau 2.5.36. Il rejoint les autres systèmes de fichier journalisés : ext3, ReiserFS, JFS, et JFFS/JFFS2.
On peut noter aussi une mise à jour du firewire (IEEE 1394) cher à nos caméras DV pour ce nouveau noyau !
Après une série de 115 patches censés nettoyer la partie IDE du noyau Linux dans la série 2.5, Marcin Dalecki a laissé tomber (voir le message de Marcin). Il faut dire que son travail sur le sous-système était impopulaire, car il n'hésitait pas à tout "casser".
Alors que tout le monde s'accordait à dire que la version précédente était impossible à maintenir, il a repris le projet et a entrepris de le nettoyer, s'attirant de nombreuses remarques. Malgré le soutien de Linus, il a abandonné suite à la dernière critique (du type "ôte tes pattes de là").
Le sous-système a été remplacé par le portage de l'IDE du noyau 2.4, qui existait déjà pour permettre aux autres développeurs de travailler en attendant une stabilisation.
Il semblerait que ce soit Alan Cox qui reprenne le système IDE (avec conditions). Après E.S.Raymond et CML2, Rik Van Riel et sa VM, Keith Owen et Kbuild, que de travail gâché!
Récemment, le mainteneur des patchs de haute performance du noyau Linux a fait des benchmarks sur les dernier noyaux 2.4.x de Linux. La méthode qu'il a utilisé pour faire ces benchmark repose sur une compilation du noyau et un logiciel appelé
irman
(Interactive Response Measurement and ANalysis). Ses résultats sont assez intéressants car ils montrent à la fois le temps pris par la tâche qui sert de benchmark et la charge totale du noyau. C'est à dire qu'il évalue aussi comment la montée en charge modifie le temps de réponse du noyau.
La question des performances du noyau Linux ont toujours été dans les préoccupations de l'équipe du noyau Linux. Il existe un grand nombre de benchmarks (dont certaines comparaisons Trollesques Linux vs NT, vu par
Microsoft ou par
d'autres).
Mais, il existe aussi des moyens d'optimiser vos performances (voir la page de "Linux Performance Tunning) ou de mesurer combien votre configuration (in)efficace (voir "Linux Benchmark Suite Homepage" et le "Linux Benchmarking HOWTO").
La version 2.2.22 du noyau Linux est sortie ce 16 Septembre 2002.
Il s'agit uniquement d'une version de correction de bugs visant à s'assurer que le dernier noyau de la série 2.2 est tout à fait stable et sans failles. Les personnes utilisant toujours un noyau 2.2 sont invités à mettre à jour pour éviter les problèmes de sécurité.
2.2.22 c'est quand même un joli numéro de version ;-)
Alors que le noyau de développement entrera en phase de « feature freeze » le 31 octobre, on peut déjà voir à quel point nos joyeux hackers ont fait du super boulot.
En effet, avec la récente intégration de ordonnanceur O(1) de Ingo Molnar, associée à la toute nouvelle bibliothèque sponsorisée par Red Hat de support natif des threads POSIX (Native POSIX Thread Library), le noyau se montre capable de créer et détruire sur un « vieux » IA-32 dual 450MHz PII Xeon 100 000 threads en 2,3 secs (avec jusqu'à 50 threads à tourner en même temps).
Même si concrètement aucune application n'utilise pour le moment autant de threads en parallèle, ce test montre surtout que ce nouveau design supporte bien mieux des changements d'échelle et est bien plus efficace (le même test prend 15 minutes sur un noyau non modifié).
La NPTL est appelée à être incluse à la bibliothèque GNU C quand elle sera jugée suffisamment stable.
NdM: Merci à MadCoder qui nous a proposé aussi cette nouvelle en indiquant également que des architectures powerPC récentes, il a même été réussi de lancer près d'un million de threads avec 200 qui tournaient en parallèle.
Un débat fait rage actuellement sur la Linux Kernel Mailinglist pour savoir si la prochaine version du noyau devra s'appeller 2.6 ou 3.0. En effet, le grand nombre de changements en profondeur (nouvelle VM, nouveau scheduler, nouvelle couche block-io, ALSA, preempt, intégration d'XFS et de JFS, ...) justifient pour certains le passage à un numéro de version majeur.
Pour Linus, tout en profitant pour rappeller qu'il a besoin de plus de testeurs :
Hey, _if_ people actually are universally happy with the VM in the current 2.5.x tree, I'll happily call the dang thing 5.0 or whatever (just kidding, but yeah, that would be a good enough reason to bump the major number).
Vous vous êtes toujours demandé :
"A quoi servent donc tous ces fichiers dans /proc/sys/net/ ? je peux utiliser le remote manager dessus ?", ou bien encore "sysctl: command not understood " , alors ceci est pour vous ....
Attention, avis à la populace, Linus annonce la sortie du kernel 2.6 pour le mois de Juin. Ce n'est qu'une prévision, la " feature freeze" ayant lieu dans quelques jours. Mais le développement du kernel 2.6 semble être parti sur de bonnes bases, on peut donc peut-être espérer avoir une release aux environs de la fin du deuxième trimestre.
Cependant, au vu du nombre impressionnant de nouvelles fonctionnalités, le programme est très chargé et certains développeurs comme Robert Love sont moins optimistes et, en "murphysant", arrivent à une release jusqu'à 18 mois après le freeze, soit aux environs du début 2004.
Pour tout ceux qui aimeraient bidouiller le noyau Linux, appliquer un patch, compiler un module, trouver de l'aide, voici un site créé par Rik van Riel ( kernel kacker, auteur d'une VM ) qui vous donnera sûrement envie d'appliquer un patch :)
Dans l'interview on apprend notamment que les patchs de linus sont plutôt "timides" par rapport à ceux d'Alan cox (branche -ac) et que selon lui ( Rik), mieux vaux prendre la branche ac.
