patrick_g a écrit 6387 commentaires

>>> Apres son post, des gars de MS l'ont contacte. Voila, vous pouvez passer a votre prochaine idee de complot, celle la s'est degonflee.

Moi je n'ai jamais parlé de complot. J'ai juste dit que Microsoft ne semblait pas bosser du tout sur le pilote hyper-V (et même l'avoir balancé sans se préoccuper du style de codage).
Si je vais lire le lien que tu nous donne d'un ton triomphal je ne vois rien qui me fait changer d'avis :

"Kroah-Hartman added that he did not see any kernel patches from Microsoft since the original code release, except for an update to the TODO file that happened earlier this week".

Merci pour toutes ces infos et bravo pour ton boulot d'éradication ;-)
Par curiosité pourquoi avoir choisi de bosser sur reiserfs qui n'est pas, c'est le moins qu'on puisse dire, le fs le plus utilisé sous Linux et qui le sera de moins en moins ?

Je pense que ce qui est qualifié de "maladroit" c'est la configuration construite par RedHat (la unconfined_t) et qui a une faille concernant le setting mmap_min_addr.
Ce n'est pas SELinux en soi qui a une faille.

>>> Donc (sans kmemcheck), il n'y a jamais de "crash", qu'on ait de la chance ou pas.

Ce n'est pas ce qu'écrit Jon Corbet dans un article ou il évoque kmemcheck ici : http://lwn.net/Articles/260068/

Using uninitialized memory can lead to some seriously annoying bugs. If you are lucky, the kernel will crash (...) Other times, though, something more subtly wrong happens, forcing a long hunt for the stupid mistake.

>>> juste comme ça, comment connaitre le taux de fragmentation ?

Il me semble qu'après un run de fsck il te dit le pourcentage de fragmentation non ?

>>> Tu fais un travail d'historien qui servira aux élèves de CM1 de 2080 quand ils apprendront l'histoire de l'informatique.

Hem...point trop n'en faut sinon ça va se voir que je stipendie des louangeurs ;-)

Je pense que la phrase "most parts of the kernel now neither require nor run with the Giant lock" s'applique aussi parfaitement à Linux donc je ne sais pas si FreeBSD est en avance ou pas.

>>> @patrick_g : LinuxMag paie (bien ses auteurs), à toi de voir ;-)

Les articles de LinuxMag sont très bien foutus et bien plus techniques et détaillés que les miens. Je serai bien incapable de les écrire.
Je pense aussi que le public n'est, en partie, pas le même.

C'est assez dur de trouver un niveau de détail qui puisse intéresser la majorité des lecteurs LinuxFR sans (trop) rebuter les grands débutants et sans (trop) ennuyer les vieux routiers. C'est pour ça que j'essaye autant que possible de raconter l'histoire autour du code (comme ici pour fsnotify ou perfcounters) afin que ça ne soit pas trop aride.

Corrigé. Merci de la remarque.

Merci. Faute corrigée.
Sur le kernel lock je ne sais pas trop te répondre. J'ai vu passer quelques mails qui concernent ce sujet et c'est donc la preuve que le travail continue doucement...mais je suppose qu'au fur et à mesure que le BKL ne concerne plus que des coins obscurs et très peu utilisés du noyau, l'incitation à le traquer se fait de moins en moins forte.

C'est quand on a de la chance qu'il y a un crash.
La vraie merde ce sont effectivement comme tu le dis les bugs qui ne causent pas de crash et qui corrompent juste les données.

;-)

En tout cas merci aux relecteurs/correcteurs de la dépêche (baud123, Xate, rootix, plic) et un merci très spécial à Victor Stinner qui s'est tapé tout le boulot de création du magnifique sommaire détaillé.

C'est fait exprès pour cumuler les désavantages des deux systèmes ?

Merci.
Je suis impressionné par les perfs de GCC 4.4 qui fait quasiment jeu égal avec ICC sur 32 bits et qui le bat franchement sur 64 bits.

>>> générer des binaire qui ont besoin d'avoir une optimisation plus fine.

Ben ça n'a pas l'air d'être le cas puisqu'une vieille version de GCC semble éclater LLVM.

Je trouve pas. Tu a un lien précis s'il te plait ?

>>> Soit leur acte est spontané, et on les en remercie quand même. Un cadeau est un cadeau, aussi mal foutu soit-il.

Leur pilote vise à faire tourner un guest Linux dans leur hyperviseur Windows. Qu'est-ce qu'on en a à foutre de ce "cadeau" ?

>>> Le noyau Linux met en avant son API instable, en perpétuel changement.

API interne seulement. En ce qui concerne l'API qui s'interface avec le userland ça reste stable (et heureusement !).

>>> Et c'est pas comme si on pouvais pas avoir plus d'un ordonnanceur dans les sources du noyau.

Le problème avec cette solution de mettre plusieurs schedulers dans le noyau c'est qu'il y aura moins de travail de fiabilisation sur chacun.
Il vaut mieux avoir un seul scheduler adaptable aux différents types de machines....comme l'est CFS actuellement !

Un mec posait la question à Ingo : "So what happened to pluggable schedulers?"

Sa réponse (un tantinet ironique) :

"In fact, wouldn't it be even cooler technically to have a scheduler that you could tune either for low-latency desktop workloads or for server-oriented throughput workloads? And this could all be done runtime, without rebooting the kernel.
Some easy runtime tunable parameter in /proc/sys/kernel/ that sets the expected preemption deadline of tasks. So on a server you could tune it to 100 msecs, on a desktop could tune it to 5 msecs - all with the same scheduler.
No reboots needed, only a single scheduler needs to be maintained, only a single scheduler needs bugfixes - and improvements to both workloads will flow into the same scheduler codebase so server improvements will indirectly improve the desktop scheduler and vice versa.

Sounds like a nice idea, doesn't it? "

>>> Ingo sort le gros monstre de puissance pour faire le test, on lui dit que c'est peut⁻être biaisé parce que l'ordonnanceur est prévu pour plus petit, et il ressort un quad-core...

D'un autre coté il dit aussi que faire le test avec le quad-core lui a pris 8 heures alors bon si il faut tester un petit Atom à 1,2 GHz ça va représenter des jours de boulot.
Comme la charge de la preuve repose sur les épaules de celui qui propose un code nouveau c'est à Con Kolivas de faire ce travail de bench et pas à Ingo.
Déjà bien sympa de sa part d'avoir bossé et d'avoir écrit un mail détaillé pour rendre compte des résultats.

>>> e trouve Ingo Molnar bien sympa d'avoir passer du temps à tester tout ça.

Surtout que, comme il le dit sur un commentaire de l'article LWN, il a passé 8h à refaire le test avec le quad-core simple et que nous sommes juste avant l'ouverture de la fenêtre de merge du 2.6.32 donc en période de rush.

>>> Le quad-core de base est, pour un développement actuel, la machine bureautique "type" si on ne veut pas s'enfermer dans des optimisation pour 1% de la planète d'ici deux ans.

Ingo Molnar est de ton avis :

"But when it comes to scheduler design and merge decisions that will trickle down and affect users 1-2 years down the line (once it gets upstream, once distros use the new kernels, once users install the new distros, etc.), i have to "look ahead" quite a bit (1-2 years) in terms of the hardware spectrum.

Btw., that's why the Linux scheduler performs so well on quad core systems today - the groundwork for that was laid two years ago when scheduler developers were testing on a quads. If we discovered fundamental problems on quads _today_ it would be way too late to help Linux users.

Hope this explains why kernel devs are sometimes seen to be ahead of the hardware curve. It's really essential, and it does not mean we are detached from reality. ".

>>> Le contenu éditorial est lui aussi médiocre

Sur Hadopi ils ont fait un super boulot je trouve.

Il a même des trucs anciens et pas puissants :

"Both Peter Zijstra and me have and test on low-spec systems as well. I've got a 833 MHz Pentium-3 laptop that i (auto-)reboot new kernels into about 10 times every day with new -tip kernels. Peter has a 1.2 GHz Pentium-mobile laptop for interactivity testing. My daily desktop is a dual-core box - not some big honking server machine".

>>> D'ailleurs, le ton de la news me laisse perplexe... ça sent un poil le discours marketing...

s/le ton de la news/le ton du journal

D'un autre coté quand FF crashe et bien lors du lancement suivant il propose de récupérer la session.
Quand OpenOffice crashe et bien lors du lancement suivant il propose de restaurer le document.
Ce serait pas mal que ce soit implémenté dans Gimp non ? (même si de mon coté et pour ma petite utilisation je ne l'ai jamais vu planter).