Cher journal,
Ces quelques lignes pour signaler la sortie de BFS, un nouveau scheduler, écrit par Con Kolivas : Con Kolivas est le célèbre anesthésiste (Australien), grand contributeur au noyau Linux devant l' éternel :)
Pour mémoire, il stoppa pendant un temps ses contributions lorsque le scheduler d' Ingo Molnar fût préféré au sien. 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. Ainsi l'avenir de CFS était assuré pour le noyau. Alors que Con n'est pas un professionnel de l'informatique, on ne peux avoir de certitudes quant à l'avenir de ses contributions. Or un élément aussi primordial que l'ordonnanceur a besoin d'assurance concernant le rythme d'évolution, il ne s'agit pas d'un driver tiers pouvant être facilement/rapidement repris. C'est clairement un argument massue, et je ne sais s'il a servi a cacher d'autres types d'arguments afin de ne froisser personne. En tout les cas, ce fût quant même un coup dur pour Con, qui décida alors de prendre du recul vis à vis du noyau.
BFS, accrochez vous, signifie "Brain Fucker Scheduler".
Il s'agit d'un ordonnanceur orienté "desktop" (dans le sens "machine de mr michu"), également conçu pour des machines dont les qualités techniques sont loin des "stations de travail" (encore une fois, pour "mr michu").
Considérant que les solutions d'architecture des divers ordonnanceurs ne sont pas adaptées à une utilisation "bureautique" d'une station, elles ne seraient efficaces que sur un certain type d'usage. Elles ne garderaient pas assez le contrôle de votre matériel pour les tâches courantes, ne permettant pas d'exploiter pleinement les capacités du matériel lors d'une utilisation "souris" (hihhi) de votre ordinateur.
Con Kolivas qualifie son BFS de "ridiculement simple". On notera qu'il n'est pas possible de faire joujou avec le "nouvel" outil CGROUPS, si on choisi d'utiliser BFS. "Parcequ'un utilisateur de 'desktop' n'a pas besoin de ce genre d'options auquelles il ne comprends rien" (gros sniffff .... autant sur l'absence de cgroups que sur cet argumentaire plus que contestable). Con recommande fortement d'activer la preemption faible (sans spécifier laquelle, on peux penser qu'il parle des patchs déjà présents, et de longue date, dans le noyau) ainsi que DynTicks (et une horloge à 1000 hz, tiens donc....). Enfin on (mr michu, presque) pourra lancer sa session complète avec l'utilitaire schedtool. (ça c'est bourrin... en fait Con donne l'exemple schedtool -I -e amarok )
Mes talents de traducteur étant plus que piètres, je préfère vous laisser lire par vous même le readme de Con, disponible sur son site :
http://ck.kolivas.org/patches/bfs/bfs-faq.txt
Pour finir, une question en forme de petite reflexion : on pourra se demander ce que vont décider les diverses distributions proposant des solutions "desktop" toutes prêtes. A l'issu de banc de tests sur les gains réels, et les impacts éventuels, vont elles proposer une version "desktop / multimédia" vraiment taillée pour ? (et pas seulement avec ce sheduler, mais c' est une pierre de plus dans la potentielle nécessité d'arrêter les "distributions à tout faire" (à reserver aux geeks et admin et ...) du genre option de boot "installation serveur ou installation desktop ?" mais plutôt de proposer des "produits, des distributions parfaitement adaptées au besoin cible.
Journal BFS
3
sept.
2009
# Woh Pitaing Con !
Posté par Nÿco (site web personnel) . Évalué à 5.
# Caste.
Posté par Prae . Évalué à 10.
> et à ce titre on pouvait compter sur ses contributions de manière
> permanente. Ainsi l'avenir de CFS était assuré pour le noyau.
> Alors que Con n'est pas un professionnel de l'informatique, on ne
> peux avoir de certitudes quant à l'avenir de ses contributions.
> Or un élément aussi primordial que l'ordonnanceur a besoin
> d'assurance concernant le rythme d'évolution, il ne s'agit pas
> d'un driver tiers pouvant être facilement/rapidement repris.
> C'est clairement un argument massue,
C'est une surtout un argument à la con oui;
Depuis quand une personne travaillant pour une boite d'info à plus de pertinence qu'une autre personne ?
Je suis désolé, mais moi, ca me casse les bolox ce genre de sectarisme "si t'es pas de ma caste, alors ton travail est moindre".
Bizarrement, ca me fait penser à une certaine caste "scientifique" qui - si on a pas fait tels études ou passé dans tels écoles - on pas le droit à la parole ... ou nos travaux ne sont pas considérés comme sérieux.
Ecarter le boulot de Con Kolivas parce qu'il est anesthésiste, c'est purement et simplement une connerie
En espérant, comme tu le laisses supposer, que ce soit qu'un prétexte pour "cacher d'autres types d'arguments afin de ne froisser personne" (dans ce cas, pourquoi l'avoir plus ou moins considéré depuis le début du développement...)
[^] # Re: Caste.
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 9.
[^] # Re: Caste.
Posté par GeneralZod . Évalué à 10.
Ça me semble pas très convainquant comme argument.
Le modèle collaboratif de Linux permet justement de s'affranchir de ce genre de détails.
Il n'y a pas qu'un seul spécialiste des ordonnanceurs, de nombreuses parties du noyau sont maintenus par des personnes qui n'en sont pas les auteurs originaux.
Vous imaginez le merdier si pour chaque pièce de code du noyau, il n'existerait qu'une seule et unique personne capable de la maintenir ?
Le problème de la disponibilité est un faux problème si CK fait faux-bond, un autre prendra sa place. À moins que son ordonnanceur soit tellement génial/abscons que personne puisse le comprendre, je ne vois pas pourquoi ça ne serait pas le cas. Où alors, faut se faire à l'idée que Linus n'est pas immortel ...
Si l'ordonnanceur de CK n'a pas été retenu, c'est soit les alternatives étaient supérieures, soit pour des raisons plus mesquines.
[^] # Re: Caste.
Posté par zebra3 . Évalué à 7.
C'est encore pire que ça : son ordonnanceur est asbconkonlivas...
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Caste.
Posté par Prae . Évalué à 5.
Du même point de vue que toi, ca me choque quand on avance "il aura pas le temps". J'ai envie de rétorquer "Hey mec! tu connais pas la co-responsabilité du code ?, tu crois que t'es le seul à connaitre ton bout de code ? depuis quand un mec est « propriétaire » ad-vitam-eternam de son code ?"
Ou alors Linus a franchement pas envie de s'emmerder avec son bout de code.
.. Ou bien comme avance quelqu'un en dessous: Con Kolivas aime pas trop les critiques. Enfin bon, venant de Linus, c'est un peu l'hôpital qui se fout de la charité :-)
[^] # Re: Caste.
Posté par B16F4RV4RD1N . Évalué à 4.
Après, bien sûr qu'il est toujours possible de trouver un autre développeur pour travailler dessus s'il devenait complètement indisponible, mais c'est toujours du temps de perdu, et c'est plus facile de choisir s'il y a un autre projet à côté qui fait la même chose...
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Caste. / Quoi Linus n'est pas immortel?!!!
Posté par Tonio (site web personnel) . Évalué à 1.
On m'aurai menti!
C'est dingue...
Désolé je prends de l'avance sur vendredi
:)
[^] # Re: Caste.
Posté par Benoit . Évalué à 3.
> et à ce titre on pouvait compter sur ses contributions de manière
> permanente. Ainsi l'avenir de CFS était assuré pour le noyau.
> Alors que Con n'est pas un professionnel de l'informatique, on ne
> peux avoir de certitudes quant à l'avenir de ses contributions.
> Or un élément aussi primordial que l'ordonnanceur a besoin
> d'assurance concernant le rythme d'évolution, il ne s'agit pas
> d'un driver tiers pouvant être facilement/rapidement repris.
> C'est clairement un argument massue,
C'est l'argument que j'avais soutenu dans une précédente discussion et quelqu'un m'avait fort aimablement fait remarqué que ma mémoire était défaillante et que j'avais tord.
Visiblement, l'argument principal qui avait motivé la décision de Linus Torvald est, hors la supériorité technique du scheduler d'Ingo Molnar, la grande difficulté qu'à Con Kolivas a à supporter et tirer parti des critiques de son travail.
[^] # Re: Caste.
Posté par Benoit . Évalué à 1.
s/tord/tort/g
s/qu'à Con Kolivas a à/qu'a Con Kolivas à/g
Ne pas se relire quand on a l'estomac vide est une mauvaise idée...
[^] # Re: Caste.
Posté par bubar🦥 (site web personnel) . Évalué à 3.
D' où le "difficulté qu'à Con Kolivas a à supporter et tirer parti des critiques".
D'un autre côté on observe largement que ce type de comportement dans le modèle collaboratif GNU - BSD est nettement moins présent, moins visible. Le travail en réseau et les outils utilisés tendent largement à apaiser ce type de comportement d'une part. Et d'aute part à mieux le comprendre et le supporter, en laissant le temps à chacun pour sa 'digestion'.
Bref, c'est un argument valable selon moi (bien que me plaçant du côté de "ceux qui ne sont pas passé par l'école). Mais je crois que peut être ce n'est pas le seul argument. Car par exemple quid de toutes les intégrations des améliorations apportées par la branche -rt en utilisant le bfs ? N'y a t il pas là un risque de ralentissement de l'évolution par cause de manque de cohésion ? Je ne sais pas. En tout cas je vais tester dès ce soir bfs sur kernel-rt (ou plutôt patch bfs puis patch rt, en essayant de comprendre (hum hum, disons plutôt les corrections possibles par mr michu) les modifications nécessaires à faire s'il y avait lieu).
[^] # Re: Caste.
Posté par bubar🦥 (site web personnel) . Évalué à 2.
[^] # Re: Caste.
Posté par nodens . Évalué à 5.
Alors ça ça se discute, quand on lit certains mails de Theo de Raadt, Daniel J. Bernstein, Alan Cox, Linux Torvalds ou autre :-P
# C'est doublement con...
Posté par windu.2b . Évalué à 3.
"vont elles (les distrib') proposer une version "desktop / multimédia" vraiment taillée pour ?"
Je note que les CGROUPS, même s'ils sont trop complexes pour mr. Michu, auraient peut-être pu servir aux mainteneurs de distrib', non ?
[^] # Re: C'est doublement con...
Posté par bubar🦥 (site web personnel) . Évalué à 3.
snifff :(
au début on aurit pû penser qu'ils attendaient une ""api"" simple. Maintenant que Cgroup n'est plus un gros fichier unique, mais est -beaucoup- plus simplement configurable, on peux se demander pourquoi les distributions (que je connais bien, soit Fedora et Mandriva) ne l'utilisent pas. Et la doc (touffue, pas le petit txt de départ) aussi est là maintenant, plus besoin d'y aller à 'tatons pour tests'.
A propos de docc sur le sujet :
http://broadcast.oreilly.com/2009/06/manage-your-performance(...)
D'autant plus intéressant qu'il compare avec la solution (qui-pue-cul) de Solaris. Cette dernière non-intégrée dans le noyau, est en plus mal configurée par défaut... Mort de rire quant il faut attendre 15 minutes pour que la réponse à la demande de connection de root soit lancée... mouarf :)
Solaris propose un ensemble extrèment simple (même moi j'ai compris) pour configurer cela (et avec toujours plus de possibilités par défaut, dans la facilité d'administration) c'etait un avantage indéniable.
Linux à mis plus de temps pour avoir un équivalent, mais celui-ci est dans le noyau, et aujourdhui facilement configurable.
Je ne connais pas de distribution qui en font l'usage par défaut. C'est vraiment dommage et j'aimerai bien comprendre pourquoi ?
# Petites Inexactitudes
Posté par Frédéric RISS . Évalué à 8.
et il conseille de désactiver le tick dynamique et pas de l'activer comme tu le dis.
[^] # Re: Petites Inexactitudes
Posté par bubar🦥 (site web personnel) . Évalué à 2.
# BFS
Posté par patrick_g (site web personnel) . Évalué à 10.
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é.
[^] # Re: BFS
Posté par Prae . Évalué à 2.
- Plus de temps disponible pour le scheduler de Con (les autres s'en occuperont)
- Les problèmes liés à son scheduler seront éprouvés sur le terrain (voire approuvés)
- Du fait de la co-responsabilité du code, tout le monde connaitra le code
En fait, ce qui me dérange dans tout ceci, c'est qu'un contributeur actif, qui fait cela sur son temps libre, que son principal job n'a aucun lien avec l'info, et bien on lui dit d'aller limite se faire f.. voir ailleurs; Je trouve cela limite.
[^] # Re: BFS
Posté par Zenitram (site web personnel) . Évalué à 0.
Si tu considères que quand il y a x compétiteurs pour un truc donné, le fait de choisir un gagnant signifie dire aux x-1 autres d'aller se faire foutre, tu vas avoir un gros problème avec tout les "concours" qu'il y a sur la terre, et tu vas avoir un problème avec ton boulot aussi (on est toujours en compétition dans notre monde...)
Pourquoi parler "d'aller de faire"?
Des gens ont pesé le pour et le contre, un contre mais pas le seul est sa disponibilité.
Si il avait un "pour" qui effaçait ce défaut, ça irait, mais non, il se prendre d'autres "contres" (non prise en compte des commentaires...)
Et franchement, entre un code parfait + un mainteneur, et un code parfait sans mainteneur, en tant que gestionnaire de code je choisi aussi la première solution : ça fera moins de charge pour les autres.
C'est un peu trop facile de mettre tout sur le dos du "pauvre petit qui travaille à côté", mais il faut rester pragmatique : en plus du côté "meilleure prise en compte des commentaire", la solution d'en face a aussi "j'arrive avec du fric pour payer un mainteneur", et ça joue, oui, pragmatique.
Maintenant, si il veut passer au dessus et être le gagnant, il a le choix : trouver un mec qui sera payé pour être mainteneur, proposer une solution qui soit meilleure, vraiment meilleure, et j'en passe.
Ca reste une compétition, rien de plus, mettre des sentiments dans l'histoire est du n'importe quoi.
[^] # Re: BFS
Posté par Prae . Évalué à 3.
> qu'il y a sur la terre, et tu vas avoir un problème
> avec ton boulot aussi (on est toujours en compétition dans
> notre monde...)
Je t'arrêtes de suite, tu vas directement te calmer sur les attaques personnelles et les petites piques de dessous-les-fagots. Cela devient une fâcheuse habitude dans tes réponses.
[-1 parce que hors sujet]
[^] # Re: BFS
Posté par thedude . Évalué à 2.
Apres, c'est toujours la meme rengaine de calimero de soutenir celui qui a perdu face a l'encule de gagnant.
Sur un projet de cette envergure, on demande pas uniquement du code, mais aussi un mainteneur.
Mainteneur dans ce cas voulant plutot dire "lead developper" ou "team leader" que simple grouillot qui bouffe du disque dur pour chier du code.
Et objectivement, entre un leader qui n'ecoute pas la critique sur son bebe et qui n'est pas toujours disponible, face a un autre qui ecoute et est paye pour etre disponible, avec une solution technique comparable en termes de resultats, ben le choix est vite fait...
[^] # Re: BFS
Posté par Prae . Évalué à 2.
[^] # Re: BFS
Posté par Maclag . Évalué à 3.
Le problème, c'est que tu commences comme ça, et ensuite, tu ne peux plus t'arrêter: pourquoi autant de drivers pour les netbooks limités en ressources et peu extensibles, comparés aux desktops? Faisons un noyau de plus!
Pourquoi telle option qui fonctionne bien pour son utilisation mais pas la mienne? On ne pourrait pas faire un noyau dédié?
Et Debian va finir avec 12 noyaus x n_plateformes, le tout non maintenable, et surtout probablement difficilement testable (trop de combinaisons!). Donc il faut faire un choix.
Et ça ne me choque pas que Debian préfère soutenir un noyau de serveur et laisser les utilisateurs desktops se débrouiller que le contraire. ;)
[^] # Re: BFS
Posté par fearan . Évalué à 4.
server, desktop, realtime(rt), vanilla(aussi appelé linus), tmb (pour le support en avance de certains matériel, mais potentiellement moins stable), et netbook.
Mais il est vrai que cette distrib ne gère pas autant d'architecture que débian.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: BFS
Posté par Raphaël G. (site web personnel) . Évalué à 1.
[^] # Re: BFS
Posté par suJeSelS . Évalué à 8.
[^] # Re: BFS
Posté par patrick_g (site web personnel) . Évalué à 3.
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 ?
[^] # Re: BFS
Posté par briaeros007 . Évalué à 3.
[^] # Re: BFS
Posté par bubar🦥 (site web personnel) . Évalué à 3.
Le problème, c'est que tu commences comme ça, et ensuite, tu ne peux plus t'arrêter: pourquoi autant de drivers pour les netbooks limités en ressources et peu extensibles, comparés aux desktops? Faisons un noyau de plus!
Il me semblait que c'était l'une des forces : portabilité, adaptabilité.
J' imagine que ceux utilisant du Debian en embarqué sensible tunent finement le tout. (ha d'ailleurs j'imagine pas, j'en suis sûr ;) ) Et pourtant cela reste une Debian.
Pourquoi telle option qui fonctionne bien pour son utilisation mais pas la mienne? On ne pourrait pas faire un noyau dédié?
Et Debian va finir avec 12 noyaus x n_plateformes, le tout non maintenable, et surtout probablement difficilement testable (trop de combinaisons!). Donc il faut faire un choix
Là, la réponse devrait peut être : "ben fait le pour toi, chez toi" ?
Et ça ne me choque pas que Debian préfère soutenir un noyau de serveur et laisser les utilisateurs desktops se débrouiller que le contraire
Moi non plus :) ! C'est une situation nettement préférable, certainement.
Par contre un noyau de plus, juste un, pour les netbooks, ça serait peut être pas un mal, pour et chez personne.
et ensuite, tu ne peux plus t'arrêter
Espérons que non :) Blague à part, si bien sûr ! La problématique d'une distribution étant sans commune mesure avec la personne recompilant chez soi, il est certain que des choix draconiens doivent être fait. Proposer 2 noyaux ne (me) semble pas la mère à boire.... Et avec un meta-paquet "mr michu" qui s'occupe aussi de pam en général, de limits.conf en particulier, du serveur x une tty suffit, de sysctl, et de qq autres trucs au passage... okok je sort, c'était pour rire :) (désolé)
# brain fuck
Posté par argt (site web personnel) . Évalué à 1.
http://en.wikipedia.org/wiki/Brainfuck
J'imagine que le nom BFS vient de son minimalisme, comme pour le langage brainfuck.
# Inquiétant
Posté par _seb_ . Évalué à 3.
- Con Kolivas n'est pas informaticien de formation. Même si je ne remets pas cause ces compétences dans ce domaine, il avoue lui même avoir des lacunes sur certains points techniques.
- Le noyau Linux est aujourd'hui reconnu par la communauté scientifique, communauté mondiale et composée de nombreuses personnes dont c'est le métier, la passion par certaines.
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".
C'est un coup dur pour les spécialistes d'autant plus que les critiques formulées sur BFS sont au choix: le nom est déjà utilisé par un système de fichier, le source n'est pas écrit en brainfuck, la qualité du code est déplorable, les performances dans des conditions d'utilisation "serveur surchargé" sont moins bonnes, qui sera le mainteneur de cette brique du noyau, etc.
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).
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. La tâche est difficile...
[^] # Re: Inquiétant
Posté par Troy McClure (site web personnel) . Évalué à 7.
[^] # Re: Inquiétant
Posté par Sphax . Évalué à 2.
J'interprète ce que tu as écris, alors je peux me tromper. Je comprends pas très bien non plus ton inquiétude.
[^] # Re: Inquiétant
Posté par _seb_ . Évalué à 3.
Je dis simplement que la solution proposée par Con Kolivas a été rejettée de façon peu élégante. Les principaux arguments apportés sont peu scientifiques et une sorte de coalition s'est créée contre BFS, de ce que je constate.
J'ai l'impression que certaines parties du code du noyau devient une chasse gardée réservée à certaines personnes et que les règles du jeu ne sont pas bien définies.
C'est en cela que je trouve inquiètante cette histoire.
[^] # Re: Inquiétant
Posté par patrick_g (site web personnel) . Évalué à 5.
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).
[^] # Re: Inquiétant
Posté par patrick_g (site web personnel) . Évalué à 3.
[^] # Re: Inquiétant
Posté par bubar🦥 (site web personnel) . Évalué à 4.
vue de mon niveau presque-michu :
je n'ai pas le même besoin dans mon cellulaire que dans mon netbook, que dans des bancs d'intégration et validation 'machin'nique, que pour une station 'simulation', que dans ma station de travail portable, que dans ma station de travail 32go de ram quadri-pro, que dans mes serveurs interne réseau, que dans mes serveurs en frontal toile.
Le gars qui met le même kernel dans tout ça, ouahou, j'ai peur.
[^] # Re: Inquiétant
Posté par patrick_g (site web personnel) . Évalué à 0.
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.
[^] # Re: Inquiétant
Posté par bubar🦥 (site web personnel) . Évalué à 3.
du moins, pour moi, c'était, enfin je re-formule :
Le gars qui met la même config de linux dans tout ça, ouahou, j'ai peur
parceque dans tout ça, ici y a que Linux, c'est évident, la base est identique ;)
parfois il y a des hyperviseurs dessous, mais c'est déjà un autre sujet
[^] # Re: Inquiétant
Posté par patrick_g (site web personnel) . Évalué à 2.
[^] # Re: Inquiétant
Posté par bubar🦥 (site web personnel) . Évalué à 2.
[^] # Re: Inquiétant
Posté par bubar🦥 (site web personnel) . Évalué à 2.
Perso ça ne m'étonne pas.
D'autant plus qu'il est assez simple (petit toussette) d'en choisir un autre de manière "extérieur" dès lors que ce patch s'intègre pas trop mal. (c'est le cas ici de BFS, il est facilement testable).
[^] # Re: Inquiétant
Posté par bubar🦥 (site web personnel) . Évalué à 2.
CFS est une "révolution" (et le mieux est que tu ailles toi même lire les diverses sources d'informations de "l'époque" pour te faire toi même ton avis sur cette question. Perso il me semble me souvenir que les deux étaient considérés comme excellent (on notera que DeadLine est toujours présent mais n'est simplement plus activé par défaut, par exemple). Il y en a déjà 2, l'historique et le nouveau... Pour les autres, ben après tout c'est bien le travail -éventuel- des distributions, non ?
Faudrait pas confondre noyau vanille avec ceux des distros, ou alors c'est parceque tu utilises Fedora ;) ;) ;)
# Kolivas vs Ingo
Posté par IsNotGood . Évalué à 1.
Je ne crois que l'argument était là.
Linus n'était pas que Kolivas refuse toute critique. Linus a donc dit un truc du genre : "je ne veux pas d'un développeur avec qui je ne peux discuter".
Le scheduler de kolivas a donc été refusé et peut-être même avant la proposition d'Ingo.
Ton argument ne tient pas car si le boulot de Kolivas était "fabuleux", d'autres (peut-être des employés de Red Hat ou autre) l'aurait maintenu/développé.
Toute contribution, si elle est bonne, si elle va dans la bonne voie, est accèptée.
on pourra se demander ce que vont décider les diverses distributions proposant des solutions "desktop" toutes prêtes.
Elles ne vont rien "décider". Elles veulent le même ordonnanceur pour la grande majorité des cas d'utilisation (et donc desktop et serveur).
[^] # Re: Kolivas vs Ingo
Posté par Antoine . Évalué à 7.
C'est sûr qu'avec une prémisse pareille il n'est pas difficile de montrer que toute contribution non acceptée était forcément mauvaise et n'allait pas dans la bonne voie.
En d'autres termes, le système fonctionne parce qu'il fonctionne et il est hors de question qu'il ne fonctionne pas, donc il fonctionne.
Dommage que la Pravda ne recrute plus :)
[^] # Re: Kolivas vs Ingo
Posté par claudex . Évalué à 3.
En même temps, si on acceptait n'importe qu'elle contribution dans le noyau, ce serait un joyeux bordel.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Kolivas vs Ingo
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
C'est pas le cas ?
[^] # Re: Kolivas vs Ingo
Posté par wismerhill . Évalué à 4.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.