patrick_g a écrit 6397 commentaires

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).

Ah ben acheter des nouveaux meubles de bibliothèque cela sera de toute façon incontournable. C'est pas ça le problème...le vrai souci c'est de vivre dans 35 m² et d'avoir déjà recouvert les murs de livres : http://patrickguignot.free.fr/videos/biblio.avi
Et encore dans la vidéo on ne voit pas la bibliothèque de l'entrée et on distingue mal le fait que presque toutes les étagères ont des doubles rangées de livres.

Non y'a pas a tortiller, je vais devoir vaincre mon caractère de bernard l'ermite casanier et me mettre en quête d'une nouvelle coquille ;-)

Oui la bibliothèque est chez moi. C'est d'ailleurs dramatique car je n'ai plus de place dans ma bibliothèque (donc il faut déménager) mais en même temps avec mes bouquins le futur déménagement va être un calvaire atroce.
Pour l'instant je tergiverse.

Ah OK je n'avais pas compris ce que tu disais. Désolé.

>>> Le gars qui met le même kernel dans tout ça, ouahou, j'ai peur.

Pourtant les superordinateurs les plus puissants du monde tournent sous Linux....et les téléphones/gadgets GPS/télévisions Sony/Tux droid/etc tournent aussi sous Linux.

>>> Peut être qu'au contraire, l'avenir est à la spécialisation.

Si tu veux spécialiser les scheduler alors cela signifie qu'il faut un système de plugin puis qu'il faut multiplier les scheduler, chacun adapté à un type d'utilisation, déboger/tester/valider/maintenir les différents scheduler, etc

Sur le long terme cela ne paye pas du tout. Il vaut mieux un seul scheduler d'excellente qualité.
J'ai même lu sur la LKML que les mainteneurs regrettaient beaucoup d'avoir choisi la solution plugins pour les scheduler d'entrées/sorties (ou tu peux choisir en "Anticipatory", "Deadline", "CFQ", etc) et qu'ils préféreraient n'en avoir qu'un seul.

s/refuse cette solution/refusent cette solution

>>> Je suis assez surpris qu'une personne propose un nouvel ordonnanceur, extrêmement simple et performant (d'après ses dires). Je le suis encore plus lorsque j'apprends que cette personne "n'est pas du métier".

Pourquoi est-ce que tu est surpris ?

>>> C'est un coup dur pour les spécialistes

N'importe quoi.

>>> L'implémentation d'un système de plugin pour l'ordonnanceur du noyau Linux, permettant ainsi de choisir quel ordonnanceur l'on souhaite utiliser, semble avoir été refusé (information à confirmer).

Effectivement tous les mainteneurs du noyau, Linus en tête, refuse cette solution bâtarde qui consiste à ne pas choisir et à laisser entrer tous les scheduler en mainline.

>>> Pour marquer la fin de cette histoire, il va falloir se retrousser les manches pour que le noyau Linux possède un ordonnanceur capable de réagir parfaitement dans toutes les situations d'utilisation.

CFS est déjà excellent dans la grande majorité des cas de figure.
Con a choisi de privilégier un "use case" au détriment de tous les autres (il dit lui même que BFS n'est pas fait pour les machines NUMA alors que les processeurs récents ont souvent une telle architecture).

Effectivement un noyau serveur et un autre desktop ce serait quand même pas la mer à boire (surtout que les différences c'est juste quelques options en plus ou en moins).
Y'a un moyen de voter pour des bugreports ?

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539209

PS : que fait Ubuntu à ce sujet ? Il me semble qu'il y a deux sortes de noyaux non ?

Mensonge !
Je ne suis qu'au cinquième étage sans ascenseur.

>>> Le principal argument retenu étant que Ingo était un employé de Redhat et à ce titre on pouvait compter sur ses contributions de manière permanente

Ouais enfin Linus a aussi bien insisté sur le fait qu'Ingo tenait compte des rapports de bugs des utilisateurs de son scheduler et qu'il corrigeait rapidement le code.
de son coté Con Kolivas a passé beaucoup de son temps a nier les problèmes de son scheduler et semblait bien moins enclin a corriger son code.
Il n'y a donc pas qu'un problème de "temps disponible".


Sinon il y a un article sur LWN (avec beaucoup de commentaires) a propos de ce nouveau scheduler BFS : http://lwn.net/Articles/350100/

A noter que j'ai appris en lisant ces commentaires que les noyaux Debian ne sont pas compilés avec l'option CONFIG_PREEMPT donc on a par défaut un noyau qui est bien plus adapté aux serveurs qu'aux machines de bureau.
Pourquoi est-ce que Debian ne propose pas 2 sortes de noyaux ? Le profil d'utilisation d'un serveur et d'un laptop n'ont rien à voir et il serait bien d'avoir un noyau un peu plus adapté.

>>> C'est bien. Mais un message des admins "on est au courant", c'est mieux.
Ça fait plus pro, c'est plus rassurant.

Ben chez google ils sont pas pro alors. Gmail a l'air d'être méchamment down :

http://farm3.static.flickr.com/2632/3878479843_793161c23b_o.(...)

>>> Et oui, j'ai oublié de présenter LLVM

En même temps il y avait déjà eu plusieurs news :

LLVM 2.2 : https://linuxfr.org//2008/02/18/23723.html
LLVM 2.4 : https://linuxfr.org//2008/11/12/24671.html
LLVM 2.5 : https://linuxfr.org//2009/03/04/25108.html

Mais c'est vrai que c'est mieux de faire un petit rappel au début.

Purée une matinée au boulot sans pouvoir aller sur linuxfr...j'ai cru mourir !

>>> il va falloir que je trouve comment dire à PulseAudio d'utiliser le micro de ma webcam pour envoyer le son à Skype

Pareil.
J'ai essayé d'utiliser Skype afin de pouvoir faire des vidéoconf avec les membres de ma famille qui sont sous Windows...ben j'ai l'image mais visiblement le micro de ma webcam n'est pas pris en compte et ils ne m'entendent pas. J'ai pourtant une Logitech Quickcam basique.
A noter que j'ai aussi installé cette nouvelle version 2.1 beta. Une fois que la communication est établie, dès que j'appuie sur le bouton pour lancer la vidéo j'ai un crash de Skype.
Saloperie.

>>> Note aussi que c'est bien plus rapide dans les dernières Fedora.

Ouais enfin tu a noté que le test qui fait l'objet du journal , celui ou Fedora/Yum se fait littéralement tronçonner par Ubuntu/Apt, est effectué en prenant une Fedora 11 ?
Ce que tu nous dit c'est que Yum était encore pire avant ?

C'est bien de voir un article qui fait cette comparaison et c'est ahurissant de constater une telle différence de rapidité.
Je ne prend que le premier test (un refresh de la base des packages) : On s'attend à ce que Fedora gagne car les dépots sont moins nombreux et moins fournis...et Ubuntu l'éclate dans les grande largeurs.
Bien entendu je ne pense pas que ce soit lié intrinsèquement au format RPM...c'est juste que Yum à l'air de suxer pas mal.