Le kernel hacker Con Kolivas a donné une longue interview et il s'explique sur les raisons de son abandon du développement du noyau Linux.
Je vous invite à lire cette très intéressante interview ici :
Introduction : http://apcmag.com/node/6735/
Première partie : http://apcmag.com/6759/interview_with_con_kolivas_part_1_com(...)
Seconde partie : http://apcmag.com/6762/interview_with_con_kolivas_part_2_his(...)
Alors si on essaye de résumer un peu son récit (citations extraites pour donner le ton du récit...merci de lire l'intégralité de l'interview et de ne pas m'insulter en m'accusant de sortir les phrases de leur contexte).
1) Tout d'abord il fait le constat que le développement de Linux se focalise sur le marché des serveurs et que le desktop est sacrifié (car les devs son payés par des boites qui se fichent du marché desktop) :
- We were shaping an operating system never designed for the desktop and it was going to hurt... a lot
- The developers were all developing for something that wasn't the desktop. They had all been employed by big name manufacturers who couldn't care less about the desktop
- Performance, as home desktop users understand performance, was gone.
2) Con décide donc de remédier à cette situation déplorable et d'écrire du code qui va améliorer les performances pour le desktop :
- I started writing some code which helped... a lot.
- the fact that my website has close to 1 million hits suggests there are people who agree (my code) makes a difference.
3) Mais les autres développeurs n'incorporent pas son code en mainline car ils se fichent complètement des performances desktop (difficiles à quantifier). Ils refusent d'accepter ses améliorations et la santé de Con s'en ressent :
- I would be sleep deprived, and it had the possibility to impact on my work and family life.
- I posted a pluggable CPU scheduler framework (and) it was flat out refused by both Linus and Ingo
- (swap prefetch) was merged into the -mm kernel 18 months ago and I've been supporting it since. Andrew to this day remains unconvinced it helps and that it 'might' have negative consequences elsewhere.
- The Staircase Deadline CPU scheduler (...) hit an impasse. One very vocal user found that the unfair behaviour in the mainline scheduler was something he came to expect.
- A disc prolapse in my neck basically meant I need to lie flat on my back for about 6 weeks. Yes, kernel development did contribute to this problem.
- one day presumably Ingo decided it was a good idea and the way forward and... wrote his own fair scheduling interactive design( ...) and had help with the code from the person who refused to accept fair behaviour in my flamewar.
4) Con tire de son récit une morale qui est que les kernels hackers se foutent des utilisateurs et prennent plaisir à les rembarrer sur la LKML :
- If there is any one big problem with kernel development and Linux it is the complete disconnection of the development process from normal users.
- There is no friendly way to communicate normal users' issues that are kernel related.
- Most people are absolutely terrified of mailing the list (...) they get flamed for their inexperience
5) Quand on lui demande s'il va continuer à coder :
- just looking at any code gives me a bad taste in the mouth
En conclusion : Comme nous ne sommes pas encore vendredi je me garderai bien de tirer une quelconque conclusion et de prononcer le mot de paranoïa.
Journal L'interview vérité de Con Kolivas
25
juil.
2007
# Cabal
Posté par Beretta_Vexee . Évalué à -1.
P.S. 1 million de hit avec un article sur /. c'est ridicule ;-)
# L'avantage du libre...
Posté par Zenitram (site web personnel) . Évalué à -1.
Maintenant, pour forker faut avoir des utilisateurs qui seront interressés, des finances (dons) corrects pour pouvoir manger, etc...
ah... tiens, comme il dit, le fric vient des entreprises, pour serveur.
Il est marrant lui : il se plaint d'une situation, mais pas beaucoup de monde n'étant prêt à le suivre, ça merde quelque part.
Le libre n'empeche pas de devoir respecter des regles : "business model", des "acheteurs", etc... Le libre, ce n'est pas que du pissage de lignes de code, c'est la création d'une communauté, c'est un mouvement à créer et à maintenir.
"C'est la faute des autres". Un peu trop facile.
PS : KDE, gnome, Firefox et plein d'autres soft s'occupent que du desktop, et ça a l'air de bien fonctionner... donc le problème doit être ailleurs.
[^] # Re: L'avantage du libre...
Posté par briaeros007 . Évalué à 5.
ah... tiens, comme il dit, le fric vient des entreprises, pour serveur.
Meme avec une entreprise derrière, forker le noyau linux tu as intérêt a avoir beaucoup de monde.
Forker c'est faisable pour des 'petits projets', ou contre des projets qui sont abandonées. Mais le scheduling dans le noyau c'est une PETITE partie (mais très importante). Forker pour ca, c'est clairement intenable.
PS : KDE, gnome, Firefox et plein d'autres soft s'occupent que du desktop, et ça a l'air de bien fonctionner... donc le problème doit être ailleurs.
KDE gnome et fx ne vont pas franchement partie du noyau linux...
"C'est la faute des autres". Un peu trop facile.
Je n'ai pas d'opinion sur le cas de CK, mais certaines fois (en général pas forcément sur la lkml) c'est quand meme clairement 'la faute des autres'.
Me souviens d'une autre prise de bec sur la lkml avec reiser4.
Il semblerait que le noyau linux ait accepté un code bien plus crade que reiser4 (xfs) et ait refusé reiser4 parce que le code était 'pas propre'.
Ce sont des humains, et des entreprises derrière ce projet., et il n'est pas du tout impossible qu'il y a du favoritisme etc...
[^] # Re: L'avantage du libre...
Posté par nullisimo . Évalué à 1.
http://www.itwire.com.au/index.php?option=com_content&ta(...)
# Impression de déjà vu ...
Posté par Colin Pitrat (site web personnel) . Évalué à 10.
J'imagine le genre de situation qui lui font dire ce genre de chose, et abandonner son boulot sur le kernel, mais d'ici à dire que Linux va droit dans le mur et ne se soucie pas du desktop, c'est un peu limite. Je lui souhaite de retrouver une vie saine et équilibrée. Je pense qu'il ne s'éloignera de toute façon pas autant du développement que ce qu'il dit.
# Et il va se faire embaucher par ...
Posté par Phoenyx . Évalué à -4.
Bon c'est une blague hein ;)
D'un autre coté je me demande quel crédit on peut accorder a tout ça ...
Enfin, c'est toujours regrettable de perdre un contributeur.
[^] # Re: Et il va se faire embaucher par ...
Posté par B16F4RV4RD1N . Évalué à 2.
Novell investit bcp dans le "desktop", d'ailleurs si bcp de migration de villes, admins etc, se font avec Novell c'est sans doute pour cela aussi.
Compiz c'est Novell...
OpenSuse contribue bcp à KDE et Gnome (entre autres), ainsi que d'autres sponsors etc.
En fait il faudrait que Con Kolivas aille travailler chez Novell, je pense qu'il s'éclaterait plus que sur le noyau.
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
# Regrettable
Posté par IsNotGood . Évalué à 10.
> 1) Tout d'abord il fait le constat que le développement de Linux se focalise sur le marché des serveurs et que le desktop est sacrifié
Le constat est juste, et Con n'est pas le seul à le dire. Le desktop n'est pas "sacrifié", il n'y a pas autant de ressource que pour le serveur. C'est tout.
> (car les devs son payés par des boites qui se fichent du marché desktop)
Il ne faut pas caricaturer. Qui a fait Alsa ? SuSE. Qui a beaucoup bossé sur l'économie d'énergie, tickless, ACPI, etc ? Intel et RedHat.
Donc les boites ne se fichent pas du desktop, elles y affectent moins de ressource. Normal, leurs clients (c'est important de répondre aux besoins du client) ont des besoins liés au serveur. Les ressources en développement de Linux sont limités/finies. Il faut faire des choix. Que les choix soient "dictés" par les clients ne me semble pas anormal.
> 2) Con décide donc de remédier à cette situation déplorable
Déplorable ?!?
Il y a quoi de mieux que Linux pour le desktop quand on ne parle que du noyau ?
Windows est peut-être un poil devant. Peut-être Mac aussi. Après c'est le vide.
> et d'écrire du code qui va améliorer les performances pour le desktop
Ben d'autres vont le faire. Ce qu'il n'a pas apprécié, est que son scheduler n'a pas été choisi par Linus. Il a les boules, on le comprend, on sent qu'il y a mis beaucoup de passion. Et qui va faire un scheduleur aussi adapté au desktop ? Une boite (des boites) qui fait du pognon dans le marché du serveur et qu'il critique tant.
> - the fact that my website has close to 1 million hits suggests there are people who agree (my code) makes a difference.
J'avais un temps utilisé son patch (sur le scheduler). Dans certaines situations c'est nickel. Dans d'autres c'est pire. Globalement c'est mieux (du moins sur ma bécane et mon usage).
> 3) Mais les autres développeurs n'incorporent pas son code en mainline car ils se fichent complètement des performances desktop
Ce qui est faux. Beaucoup (peut-être insuffisament) a été fait pour les performances du desktop. Les accès disques (CFQ), un temps de latence très faible (il y a un paramétrage du scheduler spécifique desktop et un autre spécifique serveur), etc...
> 4) Con tire de son récit une morale qui est que les kernels hackers se foutent des utilisateurs
Quand on voit tout le boulot qu'ils font, Con manque sérieusement de respect.
GNU/Linux a du retard dans le domaine du desktop. Mais le noyau ne fait pas parti de ses plus gros points faibles. Loins de la.
Je me rappelle d'un thread sur le "Staircase Deadline CPU scheduler" de Con. Linus (himself) avait poussé un coup de gueule car Con n'accèptait pas la moindre critique de son scheduler. Autre chose, Linus n'a pas aimé qu'on le "bouscule" pour changer une pièce aussi importante (pas en quantité de code) du noyau. Il n'était pas le seul.
Con est un peu comme Reiser. Il est aigri que son code ne soit pas intégré rapidement. Il devrait regarder l'histoire de Linux pour constater que pour certaines parties du noyau, un long long processus de maturation est exigé avant qu'une solution soit intégrée au noyau (ext3, Xen, GFS, Fuse, etc). Quelques solutions sont intégrées rapidement car elles ont une forte communauté en compétence de développeur (par exemple ext4, KVM) et font quasiment l'hunanimité.
Ce qui est arrivé à Con, est arrivé à d'autres et aussi dans le domaine des serveurs. Vmware a essuié un refus il y a peu. IBM a aussi pris un refus pour son modèle de thread. Etc.
Notons que Xen a été refusé (il n'y a qu'une partie de Xen qui vient d'être accèptée) et pourtant IBM, Red Hat, SuSE/Novell utile Xen, ont une offre commerciale avec Xen. Donc ces "vilaines grosses boites" ne font pas la pluie et le beau temps dans les choix que Linus prend de façon collégiale.
Si Linus était un "tiran", il ne serait plus le mainteneur de Linux. C'est comme ça avec le libre. Si Con est aussi génial qu'il le dit, alors qu'il forke le noyau.
[^] # Re: Regrettable
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à -2.
>Windows est peut-être un poil devant. Peut-être Mac aussi. Après c'est le vide.
j'ai pas compris quoi dans les noyaux ? parce que moi je croyais que à part windows tout était mieux que linux comme noyau...
[^] # Re: Regrettable
Posté par Colin Leroy (site web personnel) . Évalué à 5.
Ceci dit, reiser4 est certainement le moindre des soucis de Reiser à l'heure actuelle ;)
[^] # Re: Regrettable
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
[^] # Re: Regrettable
Posté par totof2000 . Évalué à -1.
De ce côté, Windows est bien mieux fichu que Linux. Mais beaucoup de monde refuse de l'admettre.
[^] # Re: Regrettable
Posté par ahuillet (site web personnel) . Évalué à 4.
L'accélération 2D elle se fait bien avec un support noyau...
[^] # Re: Regrettable
Posté par Camille_B . Évalué à 10.
1) l'instabilité générale (ainsi que la sécurité) du système est augmentée. Si la couche graphique plante, le système plante avec elle.
2) On perd la modularité du modèle client/serveur de X qui, avec d'autres très bons choix, lui a permit d'être structurellement compétitif encore aujourd'hui (et pour encore longtemps). Peut-on dire la même chose des versions successives de l'interface de Microsoft ?
Donc non, intégrer la couche graphique au noyau est une très mauvaise idée.
Si on veut un environnement réactif, soit on choisi un gestionnaire de fenêtre léger, soit on achète une machine un peu plus puissante (ce qui ne pose plus de problèmes depuis un bout de temps), soit on se penche sur le modèle d'un Apple ou d'un Commodore : que ce soit le Mac ou l'Amiga, les deux machines disposaient d'un chipset uniquement destiné à l'accélération de l'interface graphique. Problème : cela suppose un environnement unique, et des machines uniformes.
Quitte à perdre un peu en réactivité, je préfère un environnement évolutif, modulable et indépendant de la machine.
[^] # Re: Regrettable
Posté par totof2000 . Évalué à 2.
le côté réactif n'est pas simplement lié au gestionnaitre de fenêtres: imagine une application CAO 3D par exemple ...
[^] # Re: Regrettable
Posté par Anonyme . Évalué à 2.
Mais je ne suis pas sur qu'il y ait tant de gains de perf que ca à integrer ca directement dans le noyau, donc la couche graphique dans le noyau, c'est surtout des inconvenients.
[^] # Re: Regrettable
Posté par imalip . Évalué à 0.
Le gain en perf a integrer dans le noyau, c'est qu'on a acces au hard, donc ont peut joyeusement utiliser les acceleration hard du chip. Et la ca peut faire une belle différence.
[^] # Re: Regrettable
Posté par ahuillet (site web personnel) . Évalué à 4.
On a pas forcément accès au hard qu'à partir du noyau.
[^] # Re: Regrettable
Posté par totof2000 . Évalué à 3.
en même temps, si on prend l'exemple d'une station de développement CAO, si ta couche graphique plante, tu fais plus grand chose, autant rebooter la machine (on parle de client, hein. Pas de serveur). De même si tu edites un texte sous OO, ou autre truc de ce genre.
2) On perd la modularité du modèle client/serveur de X qui, avec d'autres très bons choix, lui a permit d'être structurellement compétitif encore aujourd'hui (et pour encore longtemps). Peut-on dire la même chose des versions successives de l'interface de Microsoft ?
Je ne tronquerai jamais la modularitté et l'accessibilité d'un environnement x, surtout pour mes serveurs. Par contre pour des postes client, la question se pose ....
[^] # Re: Regrettable
Posté par briaeros007 . Évalué à 4.
Si mon X plante, je repars en ssh et ferme proprement ma session, voir kill X et essaie de relancer X.
Si je peux pas, je peux toujours utiliser les magix syskey pour eviter de trop dégeulasser mon systeme.
si je téléchargeais un truc par exemple, je peux attendre au pifomètre que le dl soit fini puis relancer la machine.
Etc...
Je peux meme, si j'ai encore le clavier (ou avec ssh), repartir en console \o/ puis de la repartir sur un nouveau X \o/
Si le noyau par en kernel oops , ben il part en kernel oops.
[^] # Re: Regrettable
Posté par totof2000 . Évalué à 2.
L'intéret pour un utilisateur n'ayant pas vraiment de notion d'administration? A part appeler le suopport qui fera la manip pour lui sans rebooter son poste? Ah ben vu le temps de réponse, il aura plus vite fait de redémarrer sa machine ....
Si je peux pas, je peux toujours utiliser les magix syskey pour eviter de trop dégeulasser mon systeme.
encore une fois, je parle d'une station de travail, pas d'un serveur.
Je peux meme, si j'ai encore le clavier (ou avec ssh), repartir en console \o/ puis de la repartir sur un nouveau X \o/
Le temps de te logguer, chercher ce qui pose problème, killer le ou les processus figés (en supposant que tu aies les droits pour le faire), t'as plus vite fait de redémarrer la machine.
[^] # Re: Regrettable
Posté par briaeros007 . Évalué à 4.
Il n'y a que ce type d'utilisateur qui utilise un ordinateur en desktop ?
encore une fois, je parle d'une station de travail, pas d'un serveur.
Un serveur chez moi, j'ai pas un clavier branché dessus en permanence et je suis pas dessus en permanence. Faut que j'aille dans une salle machine itou.
Donc un serveur avec X, c'est comment dire, ... completement idiot ?
Le temps de te logguer, chercher ce qui pose problème, killer le ou les processus figés (en supposant que tu aies les droits pour le faire), t'as plus vite fait de redémarrer la machine.
Oh un admin windows.
Et quand le meme probleme réapparait tu la reboot, mais surtout tu essaie pas de comprendre ce qui se passe. Tu reboot juste.
Le temps de te logger : ~2 seconde, voir moins en ssh avec une clé.
chercher ce qui pose probleme : ~ 10 secondes la plupart du temps
killer : ~2 secondes
un reboot : ~ 1 minute (rien que le bios + grub prend 20 secondes)
Non seulement le reboot est plus lent, mais plus inutile pour la résolution des problemes. Quelquefois il peut etre plsu utile ... quand tu sais ce qui va pas (partoch nfs ou le serveur fut down, et encore).
[^] # Re: Regrettable
Posté par Moonz . Évalué à 4.
Pouvoir redémarrer uniquement X avec un simple Ctrl-Alt-Backspace ?
[^] # Re: Regrettable
Posté par totof2000 . Évalué à 2.
[^] # Re: Regrettable
Posté par Moonz . Évalué à 3.
[^] # Re: Regrettable
Posté par briaeros007 . Évalué à 2.
C'est pourquoi je parlais de ssh pour killer X ;)
[^] # Re: Regrettable
Posté par mickabouille . Évalué à 2.
>soit assez dans les choux pour plus répondre à ça...
Bah si un driver proprio pourri in-kernel l'entraine avec lui...
[^] # Re: Regrettable
Posté par herodiade . Évalué à 6.
> Ce qui est faux. Beaucoup (peut-être insuffisament) a été fait pour les performances du desktop.
Et aussi, dans cette interview, Kolivas glisse parfois de ses préoccupations particulières vers un jugement d'ordre très général concernant, pour résumer, « la qualité du desktop sous Linux pour l'utilisateur lambda ». Or son travail porte essentiellement sur un aspect très spécifique de « l'expérience desktop », à savoir les rapports entre la latence et l'intéractivité. C'est une dimension très importante, mais est-ce tout ? est-ce seulement l'essentiel ?
De ce que je peut entendre et lire (par exemple sur linuxfr), il me semble franchement que les utilisateurs finaux de desktops sous Linux sont bien plus souvent préoccupés par les problèmes de support du matériel (cartes graphiques et accélération 3D, cartes wifi, imprimantes, webcams, ...) ou de codecs, que du punch de leur ordonanceur. (évaluation herodiade, certifiée "à la louche"(c) ;-).
Il est même peut-être hasardeux de réduire la question des « performances desktop » à l'ordonanceur ou au pré-chargement de la mémoire virtuelle (par exemple ce n'est pas forcément ce qui compte le plus pour les « performances » du rendu 3D d'un jeux, ou le décodage d'un flux h264, ...). L'interactivité a en outre le désavantage d'être difficile à mesurer (ce qui explique surement une bonne part de ce que Kolivas considère comme un manque d'intérêt des autres développeurs pour son travail, il le reconnaît mais sous-estime peut-être un peu l'influence de ce facteur sur les décisions).
> Notons que Xen a été refusé (il n'y a qu'une partie de Xen qui vient d'être accèptée)
Quelqu'un aurait plus d'infos sur les projets de merge / l'état d'avancement de la partie restante (si je ne me trompe, c'est tout le support pour dom0 qui n'est pas entré durant la fenêtre des gros merges du 2.6.23) ?
[^] # Re: Regrettable
Posté par briaeros007 . Évalué à 3.
Si tu n'as pas un noyau réactif tu ne peux pas avoir une experience desktop satisfaisante : c'est une condition nécessaire mais pas suffisante.
En outre le support du matériel : c'est de moins en moins vrai.
Ca l'est pour les carte 3D .... et encore, avec les drivers proprio non (mais ils sont proprio je suis d'accord).
Le wifi s'intègre doucement mais surement.
Les imprimantes, avec hp pas de probleme.
Il faut pas croire mais windows a aussi des problemes de reconnaissance de matériel, par exemple vista et les imprimantes! Ou encore les carte 3d ati sur du nforce 3 ...
Pour les codecs vidéo, sur un x86, c'est pas compliqué , vlc et mplayer sont les maitres incontestés de la lecture de multiples codecs sur windows comme sur linux. (En tout cas tout ceux qui lisent pas mal de vidéo utilisent soit l'un soit l'autre quand ils arrivent pas a lire une vidéo, voir tout le temps ;))
Mais il manque des choses pour linux sur le desktop : par exemple avoir une configuration de l'affichage aussi simple que sous windows.
Sous windows tu branche un deuxieme écran, tu clic droit, tu vas sur avancé, tu choisis le mode 'clone, ...' et hop ca marche direct.
Ce n'est pas le cas sous windows /o\ (en tout cas j'ai jamais trouvé comment le faire aussi simplement)
Tu parle des jeux et du multimédia.
Imagine que ton noyau bloque ton jeux pendant 1/10 seconde parce qu'il est en 100 Hz (mode serveur) et qu'il a voulu mettre 10 slot time pour un autre process. Tu le ressentiras.
Idem si en meme temps que tu joue, tu as un disque qui est interrogé et qui met du temps a répondre.
A contrario, dans un noyau temps réel (oui linux peut etre rt je sais), si ton jeux s'enregistre en rt et dis 'je veux un slot tous les 20 ms pour le traitement du son' (au dessus de ce délai, ca commence a se ressentir) le noyau fera des pieds et des mains pour respecter ce délai, et donc une meilleur expérience de jeux.
Pour le codec h.264, c'est une autre question, et x264 est quand meme un très bon codec, et ce sous windows ou linux. Ensuite on en revient a la problématique temps réel ou comment réserver du temps/delais cpu pour des programmes.
[^] # Re: Regrettable
Posté par benoar . Évalué à 2.
Tout à fait d'accord, je pense que beaucoup de problèmes de réactivité du desktop sont dûs à différents problèmes concernant les couches graphiques (X11, GTK, etc ...) plutôt que le noyau. Quand on voit la "réactivité" d'une console...
[^] # Re: Regrettable
Posté par imr . Évalué à 10.
C'est quand même le b-a-ba du petit chef:
-tu dis non à quelqu'un de passionné qui a une bonne idée
-de la discussion qui s'ensuit, toutes ses idée vont être mises à plats et quelques variations possibles vont émerger
-tu présentes l'idée résultante comme étant la tienne bien que le gros du truc soit l'original. (Avoir attendu un moment de faiblesse de l'autre pour le faire est un raffinement supplémentaire qui en dit long sur son auteur.)
Dans une boite normale on parlerait de harcèlement moral ou de mise au placard, mais c'est du développement de logiciels libres que nous soutenons et c'est le kernel en plus donc tout est bien, tout va bien et c'est normal.
Ben voyons, et tout ça n'a aucun impact sur le desktop grace à nos saints alliés les intel and co: l'ACPI fonctionne à merveille, on n'est pas obligé de filer des options à la con au noyau dans pleins de cas, le support USB est une merveille, il n'y a pas de régressions tous les 6 mois pour pleins de matériels et comme on vit dans un monde de rêve, tout ça n'a aucun impact sur la progression de linux en entreprise.
Et on se foutait de la gueule des microserfs qui ont dit pendant des années que NT4 c'est génial et qui du jour au lendemain avouaient que c'était de la merde, que 2000 fixe pleins de problèmes!
Non, il y a des problèmes réels avec le noyau linux, certains de ces problèmes viennent du fonctionnement dictatorial (bénévole) du noyau qui n'est pas la réponse à tous les problèmes, et certains de ces problèmes viennent réellement du fait qu'il n'y pas personne qui défende sérieusement le desktop dans le monde linux.
Mandrake/Mandriva a cette ambition mais n'a pas les moyens de le faire et se retrouve cantonné à une niche. Red Hat a les moyens mais n'a pas cette ambition et se cantonne elle même à sa niche (lucrative donc plus difficile à quitter sans volonté). Quant à canonical, elle semble avoir les moyens et l'ambition mais on ne voit toujours rien venir de nouveau, juste des effets d'annonce.
[^] # Re: Regrettable
Posté par imr . Évalué à 1.
c'était: du fonctionnement dictatorial (bienveillant)
[^] # Re: Regrettable
Posté par Zenitram (site web personnel) . Évalué à 6.
Euh... On n'a pas la même définition d'harcélement moral.
Dans une boite normal, on appelerai ça un profiteur, et c'est tout. Rien d'illégal, de malsain, ça arrive tous les jours.
Le harcelement moral c'est emmerder quelqu'un, lui donner des trucs impossible a faire et l'engueuller, c'est des pics mechants. rien de tout ca n'a été fait ici.
La mise au placard c'est ne pas donner de boulot à un gars et le laisser dans un coin. Rien de ça n'a été fait ici (le gars a décidé de bosser dessus, c'est son problème).
Si quand un projet ne va pas jusqu'au bout, c'est du harcelement moral, 90% des chef de projets seraient harcelés (statistiquement, 90% des projets foirent).
Non, c'est juste l'égo du Monsieur.
Comme partout.
Quand tu construis une baladeur MP3, tu pique 99% de la technologie au voisin, mais tu y apportes ta touche (marketing, design), et ça marche (non, je ne pense pas à l'iPod :) ). ca ne donne pas le droit aux autres de se plaindre "il m'a piqué mon idée de baladeur MP3, ouin".
Je croyais que sur ce site, on était contre les brevets logiciels, et la hop bizarrement pour ce mec il faudrait les mettre. Faut décider : soit on est contre les brevets logiciels et donc l'idée de Con peut être reprise et donc il n'a pas à râler qu'un truc mieux basé sur ce qu'il a fait est intégré, soit on est pour et la effectivement c'est comprehensible.
Mais être contre les brevets logiciels et contre ce qui a été fait par les décideurs du noyau, c'est un non-sens.
[^] # Re: Regrettable
Posté par imr . Évalué à 5.
C'est parce que tu n'acceptes l'idée d'harcèlement moral que par rapport au cadre des boites normales et tu ne la transposes pas au cadre nouveau de ce type de travail par voie électronique.
Je trouve qu'à partir du moment où justement on est dans un cadre où on considère que les idées sont libres et n'appartiennent à personne et que les brevets sont une violence superflue pour apporter de la propriété dans un domaine où il n'y en a pas (et pas besoin), il faut d'autant plus être respectueux du travail des autres dans ce type de situation pour ne pas acréditer l'idée que 'les gens sont comme ça, vous voyez bien que les brevets logiciels sont un mal nécessaire'.
Comment veux tu que le système de gratification par la reconnaissance fonctionne si on peut la voler sans réactions?
Ce qui a manqué dans cette histoire et ce dont je parle, c'est du respect humain pour le travail d'un personne et par là, pour cette personne elle même.
J'ai eu la chance de suivre cette affaire depuis le début (j'ai essayé le patch ck au travers d'un des kernel mandriva qui l'intègre sur un matériel un peu faiblard et mon desktop est devenu très réactif, ça m'a surpris et j'ai donc commencé à lire leur mailing list (un peu avant qu'il abandonne :( )) même si le développement du noyau me dépasse un peu, et j'attends toujours la réponse d'un des décideurs du noyau à la déception, à la souffrance et aux critiques sur le fonctionnement interne qui ont été faites. (et ce n'est pas la première fois que ces critiques sont faites, je parle des critiques sur le fonctionnement de l'acceptation des patchs pas sur la récupération du travail d'un autre)
Quand quelque chose comme ça a lieu dans une boite, on remet en cause les capacités de la direction à gérer leur bateau, mais là, comme c'est le noyau et le libre, il faudrait se bander les yeux et se taire? Parce que c'est comme ça?
D'après mon expérience il y a 2 type de personnes qui croient que ce genre de crises ne sont pas graves et sont inévitables: les jeunes gens qui ne s'en sont pas encore pris plein la gueule à cause d'un salaud, et les salaud qui ont pris leur parti de le faire sciemment.
Si beaucoup de monde croient que perdre un type comme ck n'est pas grave, c'est qu'en plus le salaud est entouré d'imbéciles, et çe ne présage pas d'un grand avenir.
[^] # Re: Regrettable
Posté par Zenitram (site web personnel) . Évalué à 4.
Faut que tu décides : si les idées ne sont pas brevetables, ce qui signifie que pour les gens elles n'ont pas d'existence "légale", elles ne peuvent pas se faire voler.
Sur linuxfr, on est 100% contre le fait que les idées appartiennent à quelqu'un, j'ai l'impression que toi aussi, mais dès que ça ne t'arrange pas, hop il faut que les idée appartiennent à quelqu'un.
Pour que tout le monde comprenne, précise ta pensée : es-tu oui ou non contre les brevets logiciels, contre le brevetage des idées?
Si tu es contre, tu ne peux pas dire qu'on a volé l'idée de quelqu'un.
La loi, le vol, dans un état de droit, est une conception qui s'applique à tous, sans sentiments. Ici, tes sentiments modifient ta vision de ce qui devrait être juste. C'est un peu "à la tête du client".
Mais où est le non respect???
Corrige moi si je me trompe, mais ici je ne vois qu'un "appel à contribution", plusieurs solutions ont été proposées, et un a été prise, les autres ont été jetées car moins bonnes.
Ca arrive tous les jours, tous les jours il y a des appels d'offres, tous les jour les 3/4 des projets sont rejetés et un est choisi.
C'est ta vision, moi j'en voit une troisième, ou plutôt une autre façon de voir les choses (car si, c'est grave, et il faut régler le problème) : un "patron" qui voit un gars avec un égo surdimensionné incapable de reconnaitre qu'il n'a pas été le meilleur. Dans une entreprise, ce genre de gars est à éviter comme la peste, car il insistera pour que sa solution soit toujours prise, même si ce n'est pas la meilleure (les autres solutions ayant l'inconvénient de ne pas avoir été faite par lui).
Une entreprise, y compris le noyau, qui va prioriser les sentiments à la technologie, et une entreprise qui mourra vite.
[^] # Re: Regrettable
Posté par imr . Évalué à 1.
Il faut surtout que tu arrêtes de me répondre sur des choses que je n'ai pas dites. le "la" en question est un pronom qui remplace "la reconnaissance".
C'est pas l'idée qui a été volée, c'est la possibilité d'être celui qui l'a l'implémentée dans le noyau linux faisant par là avancer celui ci dans une direction plus desktop friendly ce qui a toujours été la motivation de ck. Comme on lui a retiré cette motivation, il veut quitter le noyau linux n'ayant pas le gout à faire ça pour des raisons de gain de pouvoir.
Pour moi, ça ne s'est pas passé comme ça.
Il n'y a pas eu appel d'offres, c'est ck qui a voulu amené le noyau dans une certaine direction, la direction étant ce dont il parle quand il parle d'orientation serveur contre desktop.
Pour cela il a proposé d'abord un système qui permettrait de choisir le système de scheduling à la compilation afin d'orienter un noyau dans l'une ou l'autre direction sans avoir recours à des patchs. Ca a été refusé sur des questions de principes techniques que je ne discuterais pas, ça me dépasse.
Là dessus, il a donc développé son propre système de scheduling, j'imagine pour convaincre les personnes ci dessus que des systèmes différents ont vraiment un intérêt dans des cadres différents et que donc son système précédent serait l'idée naturelle suivante. Refusé pareil mais là, pas trop sur la base de principe technique puisque ça marche. Là dessus je peux en parler, je suis sur un noyau qui intègre le patch ck sur une via epia et la différence est sensible.
Tout ceci le minant parce que le monsieur a l'air passionné, il tombe malade et pendant qu'il est malade la personne qui a bloqué ses 2 initiatives auprés de linus développe sa propre version de l'idée inspirée de son travail mais pas trop histoire que.
ck arrête le développement du noyau linux sur des questions de principes humains.
C'est exactement ce qui est reproché à Ingo Molnar dans cette affaire.
Pour la partie technique, ck a fait une critique du patch de Ingo Molnar. Je ne peux pas la commenter, ça me dépasse, je te laisse juge de ça.
[^] # Re: Regrettable
Posté par imr . Évalué à 0.
http://realworldtech.com/forums/index.cfm?action=detail&(...)
[^] # Re: Regrettable
Posté par mickabouille . Évalué à 4.
[^] # Re: Regrettable
Posté par imr . Évalué à 2.
Je reste persuadé qu'il y a un problème derrière tout ça, croire que le coté humain n'est pas important mène à la catastrophe, c'est le même genre de comportement que dans d'autres cadres où on ne conçoit que le coté commercial.
Dans la discussion sur lwn, un autre mainteneur de patch dit qu'il est à 2 doigts de partir et le fait que ingo molnar a du lui aussi passer au travers de ce genre de bizutages ne me rends pas moins soucieux. Ou alors ils ont bien de la chance dans le kernel de pouvoir griller des développeurs à ce rythme, ils doivent en avoir plus qu'assez.
[^] # Re: Regrettable
Posté par Bozo_le_clown . Évalué à 3.
C'est RMS et son Hurd qui va être content
===>[ ]
[^] # Re: Regrettable
Posté par herodiade . Évalué à 10.
> Le constat est juste, et Con n'est pas le seul à le dire. Le desktop n'est pas "sacrifié", il n'y a pas autant de ressource que pour le serveur. C'est tout.
Par ailleurs, je me demande si ce n'est pas un peu artificiel d'opposer ainsi desktop et serveur.
Dans bien des cas, les fonctionnalités « serveur » d'hier sont le desktop d'aujourd'hui (par exemple : le réseau, le 64b et le SMP). C'est là qu'on peut apprécier les choix et la vision à long termes des mainteneurs de Linux (d'Unix en général, en fait).
Puisque visiblement les discussion sur ce journal portent souvent sur la comparaison avec Windows, on peut jouer à retracer les décisions pertinentes, à l'époque « orientées serveurs », qui font de Linux un noyau très puissant (je ne parle pas du userland) et de Windows le playskool que l'on connait :
- Le SMP. Il y a 2 ou 3 ans seulement, c'était considéré comme une fonctionnalité purement serveur. Désormais c'est (disons, les CPU multicoeurs) le moyen d'évolution principal annoncé pour les futures CPU, même grand public. Linux supporte le SMP massif depuis longtemps, et a pris une sacrée avance sur Windows dans le domaine (IBM fait tourner des Linux sur des machines à 1024 processeurs, Windows Sever 2003 plafone à 64 CPU, et Vista, c'est du desktop, seulement 2 !), ainsi que dans le calcul distribué (grands clusters, ...).
- Un OS vraiment architecturé pour le réseau (au lieu du TCP/IP ajouté comme un furoncle sur un OS pour dactylos). Si l'on compare les fonctionnalités réseau « avancées » de Windows et de Linux aujourd'hui, on se marre. Néanmoins de nos jours le réseau est considéré comme un compostant standard d'un environnement desktop (plus seulement des serveurs). Pour demain, ce sera IPv6 (Vista le supporte assez mal, parrait-il, sans même parler d'IPsec, Linux a une pile très avancée qui suit quasiment les derniers drafts de RFC au fure et à mesure).
- Un OS multiutilisateur, et un OS utilisant la MMU pour isoler les processus, même sur le desktop. Ok Windows a fini par le faire (mais le multiutilisateur quand presque tout est prévu pour fonctionner à la souris en premier lieu...). Rappelez vous de la « puissance du desktop » Win95. Le fonctionnement multiutilisateur est un élément complètement naturel sous Linux, dès le début, cependant que Microsoft en est encore à batailler pour désapprendre à ses utilisateurs à tout faire tourner en root (en « administrateur », pardon), et sortir des bouts de gui du noyau, c'est dire le chemin restant.
- Le support d'architectures 64 bits. Ça fait pas mal d'années que le « desktop Linux » tourne en 64 bits. Résultat, virtuellement toutes les applis fonctionnent en 64bits sur x86_64 Microsoft n'y arrivera sans doute pas avant longtemps (puisque, notamment, ils n'ont pas habitué les éditeurs tiers à supporter cette architecture : drivers manquants, applications pas portées, cercle vicieux du manque d'utilisateurs qui switchent et donc des éditeurs de logiciels peut encouragés : à mon avis il manquera pendant longtemps des composants cruciaux pour que le bureau Windows 64b soit viable, bien que dés à présent quasiment toutes les CPU x86 pour le desktop peuvent fonctionner en 64bits).
- Une pile SCSI bien soignée. Ça c'était très « serveur » il y a peu, mais aujourd'hui c'est mis à profit et réutilisé pour la gestion du très grand public SATA (et même le PATA en fait) sous Linux. Les développements « serveurs » ont fini par profiter au « desktop ».
- Les gestionnaires de volumes disques (Le LVM). Là encore, une fonctionnalité qui vient des systèmes unix (Linux était assez en retard par rapport à HP-UX ou AIX). L'utilisation « desktop » de LVM est en train d'être redécouverte (chiffrement de volumes/partitions, redimentionnement transparent, snapshots en guise de sauvegardes/"way back machine", ...).
- Le RAID. Une fonctionnalité « très serveur » qu'on trouve désormais salement implémentée en semi-hard sur la plupart des cartes mères desktop, je ne sait pas trop pourquoi d'ailleurs (heureusement, on a une vraie implémentation logicielle dans le noyau qui vaut bien mieux que ça).
- Patches temps réel, high resolution timers, dynticks : ça c'est plutôt l'influence de l'embarqué industriel que celle des serveurs, et c'est pas encore totalement mergé, mais ça fera une sacrée différence sur le « desktop Linux » (lorsque les patchs realtime seront intégrés, le noyau par défaut offrira, pour le traitement de signal/multimédia, une latence extraordinairement faible).
- ...
Donc oui, du gros travail est fait pour les fonctionnalités serveur, et oui, les mainteneurs de Linux sont exigeants là dessus. Mais si, ça profite et profitera au « desktop ». C'est bien l'intérêt d'avoir un noyau qui cherche le « one size fit all », de l'embarqué sur téléphone aux très grands clusters du top500.org.
C'est autre chose qu'un OS où les dirigeants et décideurs sont des services commerciaux, marketing, des actionnaires, où l'on s'impose de conserver une compatibilité arrière avec un ancêtre calamiteux parce que le marché importe plus que la rationalité technique, où l'on est prét à tout dupliquer, réinventer la roue, empiler les quick hacks (bonjour, OpenXML) pour sortir la fonctionnalité wizz bang desktop plus vite, où l'on réimplémente tout pour chaque plateforme un peu différente (Windows CE pour ARM/MIPS, un fork de NT sur ppc pour la xobx, ...). C'est du long terme, quoi. Et on a une terrible avance, les amis :)
Les performances du scheduler en terme d'intéractivité, ce n'est pas tout.
(ps: mais pour être honnête, si l'on compare le merdier de l'audio et des pilotes 3D sous Linux avec ce que font Windows et Mac, on n'est pas au point).
[^] # Re: Regrettable
Posté par pasBill pasGates . Évalué à 3.
Bof, la limite a 64 sur Windows est purement artificielle, le jour ou des machines a >=64 cpus seront en vente(cad a plus de 5 exemplaires par an) ca sera fait.
Si l'on compare les fonctionnalités réseau « avancées » de Windows et de Linux aujourd'hui, on se marre. Néanmoins de nos jours le réseau est considéré comme un compostant standard d'un environnement desktop (plus seulement des serveurs). Pour demain, ce sera IPv6 (Vista le supporte assez mal, parrait-il, sans même parler d'IPsec, Linux a une pile très avancée qui suit quasiment les derniers drafts de RFC au fure et à mesure).
Moi je rigolerais pas trop a ta place, et je me fierai pas trop aux rumeurs, on sait ce que ca vaut les rumeurs quand elles viennent de fans du libre hydrocephales qui ne connaissent rien a Windows. Quand a IPSEC, bah vu que tout le traffic chez MS est sous IPSEC, faut croire que ca marche plutot bien.
Un OS multiutilisateur, et un OS utilisant la MMU pour isoler les processus, même sur le desktop. Ok Windows a fini par le faire (mais le multiutilisateur quand presque tout est prévu pour fonctionner à la souris en premier lieu...).
NT etait multi-user depuis sa naissance hein, faudrait penser a arreter de melanger Win95 et NT si tu veux etre pris au serieux.
Ça fait pas mal d'années que le « desktop Linux » tourne en 64 bits. Résultat, virtuellement toutes les applis fonctionnent en 64bits sur x86_64 Microsoft n'y arrivera sans doute pas avant longtemps
T'as Adobe Acrobat pour Linux 64 bits ? Flash peut-etre ? Maya peut-etre alors ? Bon RealPlayer ? Quake 4 alors ? Eh c'est marrant, meme StarOffice ne tourne pas en 64bits sous Linux
C'est autre chose qu'un OS où les dirigeants et décideurs sont des services commerciaux, marketing, des actionnaires, où l'on s'impose de conserver une compatibilité arrière avec un ancêtre calamiteux parce que le marché importe plus que la rationalité technique, où l'on est prét à tout dupliquer, réinventer la roue, empiler les quick hacks (bonjour, OpenXML) pour sortir la fonctionnalité wizz bang desktop plus vite
Moi je crois surtout que tu ne sais absolument pas de quoi tu parles.
[^] # Re: Regrettable
Posté par herodiade . Évalué à 9.
Clair, c'est d'ailleurs pour ça que Windows est si populaire sur les grands systèmes.
> Quand a IPSEC, bah vu que tout le traffic chez MS est sous IPSEC, faut croire que ca marche plutot bien.
Avec autre chose que du 3DES et MD5 ou SHA-1, et en ESP mode tunnel (pas l2tp hein) ? Pour avoir déployé de l'IPsec sous FreeBSD, OpenBSD, Linux et Windows XP (oui, j'ai pas vu ce qui s'est fait ensuite), j'ai un point de comparaison : Windows est une merde.
> arreter de melanger Win95 et NT si tu veux etre pris au serieux.
On parle de desktop. Avant 2000, la version « desktop » de Windows, c'était NT ou Win95 ?
> T'as Adobe Acrobat pour Linux 64 bits ? Flash peut-etre ? Maya peut-etre alors ? Bon RealPlayer ? Quake 4 alors ?
Seulement des applications propriétaires, dont la moitié ont des équivalents libres (evince, n'importe quel média player), l'autre moitié (quake 4 ou Maya) n'est pas franchement ce qui fait le quotidien moyen de l'utilisateur de desktop). Manque Flash, ok. Pour le reste j'ai environ 15000 applications packagées dans mes dépots: à peut près pareil qu'en x86_32. Désolé de te décevoir, mais on est quelques un à trouver très confortable un environnement totalement libre (donc, n'utilisant aucune des applications que tu cite).
> tu ne sais absolument pas de quoi tu parles.
Ah bah, j'ai cité OpenXML à dessein : avec les specs, contrairement aux logiciels propriétaires, on peut voir les entrailles à l'oeil nu. Et là, mais les sales hacks pour respecter une rétrocompatbilité par impératif commercial (rq, c'est aussi péniblement visible dans les bugs non corrigés d'ie7), le réinventage de roue systèmatique, l'agenda marketing, le bloatage, vous ne pouvez plus les cacher.
[^] # Re: Regrettable
Posté par pasBill pasGates . Évalué à 2.
T'appelles quoi grand systemes ? Clusters scientifiques ? Ca n'a rien a voir avec la scalabilite vu que c'est du travail a peu pres independant sur chaque machine.
Windows n'est pas moins populaires sur gros systemes SMP que Linux.
On parle de desktop. Avant 2000, la version « desktop » de Windows, c'était NT ou Win95 ?
Et la version "desktop" de Linux c'est laquelle ? Parce qu'en 2000 il y en avait pas vraiment.
Seulement des applications propriétaires, dont la moitié ont des équivalents libres (evince, n'importe quel média player), l'autre moitié (quake 4 ou Maya) n'est pas franchement ce qui fait le quotidien moyen de l'utilisateur de desktop). Manque Flash, ok. Pour le reste j'ai environ 15000 applications packagées dans mes dépots: à peut près pareil qu'en x86_32. Désolé de te décevoir, mais on est quelques un à trouver très confortable un environnement totalement libre (donc, n'utilisant aucune des applications que tu cite).
Super tes 15000 softs packages, combien sont utilises par le grand public ? Parce que la plupart sont des outils obscures en ligne de commande completement inutilisable par le pekin moyen.
Sans parler du fait que la majorite de ces softs existent et sont recompilables pour Windows.
Ah bah, j'ai cité OpenXML à dessein : avec les specs, contrairement aux logiciels propriétaires, on peut voir les entrailles à l'oeil nu. Et là, mais les sales hacks pour respecter une rétrocompatbilité par impératif commercial (rq, c'est aussi péniblement visible dans les bugs non corrigés d'ie7), le réinventage de roue systèmatique, l'agenda marketing, le bloatage, vous ne pouvez plus les cacher.
Ah oui, tout comme ODF et OpenOffice, mais la bien sur pas un mot hein.
[^] # Re: Regrettable
Posté par briaeros007 . Évalué à 2.
L'exemple le plus simple a mon sens est nmap (meme si pas forcément desktop)
Ouais nmap suxxor c'est en ligne de commande ... Oui mais nmpafe (le front end de nmap) utilise nmap. Donc nmap il puxxor parce qu'en ligne de commande et n'est pas utilisé par un utilisateur sous X, c'est ca?
Parce qu'en 2000 il y en avait pas vraiment.
J'ai commencé linux en 99/2000 ... et on supportait la souris itou, donc ...
Windows n'est pas moins populaires sur gros systemes SMP que Linux.Tiens des stats ca serait intéressant.
[^] # Re: Regrettable
Posté par windu.2b . Évalué à 3.
Y a bien le top500.org, mais on va dire que je suis de mauvaise foi :-/
[^] # Re: Regrettable
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Regrettable
Posté par briaeros007 . Évalué à 3.
[...]
windows : trace.
XD
[^] # Re: Regrettable
Posté par pasBill pasGates . Évalué à 0.
L'exemple le plus simple a mon sens est nmap (meme si pas forcément desktop)
Ouais nmap suxxor c'est en ligne de commande ... Oui mais nmpafe (le front end de nmap) utilise nmap. Donc nmap il puxxor parce qu'en ligne de commande et n'est pas utilisé par un utilisateur sous X, c'est ca?
Ca on est d'accord, mais tes 15'000 packages au final ils deviennent reellement bcp moins quand on regarde ce qui est utilisable par le pekin moyen au final
J'ai commencé linux en 99/2000 ... et on supportait la souris itou, donc ...
Et moi bien plus tot, mais je savais tres bien a l'epoque que personne dans ma famille ne serait capable de l'utiliser en tant que desktop a l'epoque. Supporter la souris c'est necessaire mais pas suffisant.
Tiens des stats ca serait intéressant.
Qu'on se comprenne, ni Windows ni Linux ne dominent les systemes massivement SMP, ce sont les gros Unix genre AIX et Solaris qui dominent ca, sinon niveau stats il y a http://www.wintercorp.com/VLDB/2005_TopTen_Survey/TopTenWinn(...) qui montre exactement ca : bcp de gros Unix, et qqe Windows/Linux par-ci par-la
[^] # Re: Regrettable
Posté par briaeros007 . Évalué à 2.
Et moi je me suis coltiné le support xp jusqu'a ce que je leur foute ubuntu et trois grosses icones "internet" "mail" "compta" .
Comme quoi, s'appeler windows n'est pas non plus forcément suffisant (comment ca elle était facile celle la? :P)
Merci pour les stats ;)
[^] # Re: Regrettable
Posté par lasher . Évalué à 3.
Je ne sais pas si tu as lu l'article original, mais CK dit que son scheduler, qui pourtant avait été critiqué, a ensuite été adopté comme modèle, et récrit from scratch par d'autres dévs du noyau (ceux qui justement critiquaient son approche). C'est ça qui l'a fait craquer, plus que le refus en lui-même : le côté « non, on veut pas de ton truc car on pense que le concept ne convient pas, mais finalement l'idée est bonne, on va le refaire à notre sauce ».
Tu parles d'IBM, mais leur modèle de threads était plus flexible et performant que celui actuellement utilisé. Sauf que bon, comme le scheduler codé par un pote du mec qui a fait les NPTL, ben... Ils se sont arrangés pour que ça colle bien l'un avec l'autre (rendant l'un dépendant de l'autre, en fait), ce qui a nécessairement désavantagé les threads d'IBM...
[^] # Re: Regrettable
Posté par patrick_g (site web personnel) . Évalué à 2.
Ce n'est pas le cas.
Le concept de Con n'a pas été critiqué. C'est le fait qu'il y avait des régressions de performances dans certains cas et que Con a refusé d'en tenir compte en disant en gros "on ne fait pas d'omelettes sans casser des oeufs".
Ingo Molnar a repris le concept et a écrit un autre scheduler qui, selon les kernels hackers, est de meilleure qualité que celui de Con. Ingo a aussi écouté les retours des utilisateurs et a corrigé les bugs et les régressions. Au final c'est son scheduler qui a été intégré et Ingo n'a pas oublié de remercier Con pour avoir apporté l'idée initiale.
Je ne vois pas ou est le scandale et tout cela me parait tout a fait normal.
# Des utilisateurs sur le LKML ???
Posté par Zorro (site web personnel) . Évalué à 8.
Et je trouve ça normal, chacun à sa place. C'est comme ça que des listes "experts" se retrouvent pourries et inutilisables à cause des débutants.
[^] # Re: Des utilisateurs sur le LKML ???
Posté par Prae . Évalué à 2.
# tiens
Posté par BAud (site web personnel) . Évalué à 2.
http://linux.slashdot.org/article.pl?sid=07/07/25/129254
[^] # Re: tiens
Posté par Anonyme . Évalué à 5.
http://linux.slashdot.org/linux/07/07/24/1432245.shtml
# Manque d'intéret pour le desktop : toujours d'actualité ?
Posté par herodiade . Évalué à 10.
- Oracle et IBM emploient beaucoup de développeurs, et il est très clair que le desktop n'est pas vital pour le business autour de Linux.
- La RHEL de Red Hat n'était peut-être pas non plus très desktop-centrique (?)
- Je crois qu'Intel employait surtout du monde pour le SMP, leurs (mauvais) chipsets RAID, l'architecture Itanium etc.
- Rien à voir avec les priorités du monde corporate, mais le verrouillage de XFree86 ralentissait lourdement les progrès aussi.
Mais il semble qu'ironiquement, c'est au moment où Con Kolivas nous quitte que les priorités basculent (en fait ça à commencé un peu plus tôt, mais les fruits commencent à peine à être récoltés, ie. dynticks, network-manager, l'ordonanceur CFS qui vient à peine d'être intégré dans 2.6.23, mac80211, ...), en particulier grâce au monde de la mobilité bon marché :
- Intel emploie une _foultitude_ de développeurs pour travailler spécifiquement sur le desktop, comme : les principaux développeurs de Xorg, du sous-système drm/dri du kernel, l'économie d'énergie, les principaux développeurs du nouveau framework wifi du noyau (mac80211 et cfg80211), vient de lancer une plateforme semi mobile (moblin), etc. Leur investissement dans "Linux pour le desktop" semble croitre à grande échelle, de jours en jours.
- Red Hat est fortement impliqué dans le projet OLPC (totalement "desktop"), et sort une version de son produit commercial, RHEL5, spécialement orientée desktop (sans parler de leur fort investissement dans Fedora). Ils ont aussi lancé à grands efforts le projet "Mugshot"/Global Desktop. Ils sont aussi l'employeur d'Ingo Molnar, qui a consacré pas mal de temps sur dynticks et sur le nouvel ordonnanceur "fair" CFS (n'en déplaise à CK).
- Ubuntu gagne en popularité, en nombre d'utilisateurs finaux (ce qui doit probablement secouer les à priori et priorités des distros plus anciennes et traditionnellement plus orientées "serveur"). Et Ubuntu dispose désormais de quelques développeurs noyau actifs (or le succès sur le desktop est clairement une priorité stratégique pour Canonical/Ubuntu).
- Apparition de sociétés qui développent essentiellement des produits pour le desktop libre (par ex. autour de Gizmo, Gstreamer, ...)
- L'affaire Dell + Linux a certainement du montrer aux constructeurs que les enjeux (ne serait-ce qu'en terme d'image auprès des "leader d'opinions" que nous sommes) de Linux concernent aussi les produits très "grand public".
La (récente) disponibilité de chipsets mobiles très bon marchés (autour des AMD Geode ou Intel Dothan) permet depuis peu de produire des ordinateurs ultramobiles à très bas prix, où le cout de l'OS est donc extrêmement sensible et significatif : du fait de son prix, Linux a une superbe fenêtre pour s'imposer sur le desktop par ce biais.
À mon avis, c'est ce qu'on compris les boites qui emploient maintenant de nombreux devs pour travailler sur la mobilité et le desktop (Intel et ses projets moblin/classmate/asus eee, Ubuntu et sa future version "semi-embarquée", openmoko, ...)..
[^] # Re: Manque d'intéret pour le desktop : toujours d'actualité ?
Posté par herodiade . Évalué à 8.
Je compte ici le nombre de développeurs distincts utilisant une email contenant le nom d'une de ces grosses sociétés et dont au moins un patch a été mergé dans le git de Linus entre la sortie du 2.6.22 et aujourd'hui. Ces chiffres ne sont pas précis ni très justes (par exemple certains développeurs n'utilisent pas leur email corporate dans les patchs, ...), c'est plutôt pour avoir un ordre de grandeur et de comparaison approximatif (pour des chiffres plus précis cf. LWN, où J. Corbet publie des études pointues) :
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*redhat | sort | uniq | wc -l
41
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*suse | sort | uniq | wc -l
23
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*ubuntu | sort | uniq | wc -l
3
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*mandr | sort | uniq | wc -l
0
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*oracle | sort | uniq | wc -l
9
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*google | sort | uniq | wc -l
15
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*ibm.com | sort | uniq | wc -l
72
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*intel.com | sort | uniq | wc -l
25
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*amd | sort | uniq | wc -l
6
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*sgi | sort | uniq | wc -l
8
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*mips | sort | uniq | wc -l
5
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*fujitsu | sort | uniq | wc -l
7
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*sony | sort | uniq | wc -l
6
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*hp.com | sort | uniq | wc -l
7
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*atmel | sort | uniq | wc -l
6
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*qlogic | sort | uniq | wc -l
14
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*freescale | sort | uniq | wc -l
10
pouet$git log v2.6.22..HEAD | egrep ^Author:.*@.*mvista.com | sort | uniq | wc -l
9
Sur un total de :
pouet$git log v2.6.22..HEAD | egrep ^Author: | sort | uniq | wc -l
754
[^] # Re: Manque d'intéret pour le desktop : toujours d'actualité ?
Posté par Snarky . Évalué à -1.
[^] # Re: Manque d'intéret pour le desktop : toujours d'actualité ?
Posté par Frédéric Guihéry (site web personnel) . Évalué à 4.
# Avec tout ça...
Posté par Nicolas Blanco (site web personnel) . Évalué à 3.
(hop, hop, hop --> [ ] pu là)
# BSD
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à -1.
[^] # Re: BSD
Posté par patrick_g (site web personnel) . Évalué à 4.
1) Parce que les kernel hackers BSD sont à l'écoute des utilisateurs et auraient accepté très vite le merveilleux code de Con Kolivas.
2) Parce que les kernel hackers BSD sont moins regardants sur la qualité du code soumis et et auraient accepté très vite le code tout pourri de Con Kolivas.
Le tout est de savoir si on est dans le cas 1 ou dans le cas 2.
[^] # Re: BSD
Posté par totof2000 . Évalué à 3.
[^] # Re: BSD
Posté par nats . Évalué à 1.
Personne ne dois prononcer son nom sous peine d'être hanté par son fantôme sur 2^128 générations !
La malédiction est sur ce post...
Au final on ne sait pas vraiment pourquoi Con est parti, on ne sait pas ce qui aurait pu se dire en privé etc...
Donc arrêtons de spéculer sur un événement qui dans tous les cas est regrettable pour tous je pense.
[mode mauvaise langue]Même pour MS ça leur fait un scheduler de moins à repomper...)[/mode]
[^] # Les « mérites » de l'ordonanceur de MS Windows [was Re: BSD ]
Posté par herodiade . Évalué à 7.
À ce sujet, et parce que j'ai lu plus haut des remarque laissant entendre que le noyau (ou seulement l'ordonanceur ?) de Windows était meilleur que celui de Linux, une petite info pour relativiser.
Il est tout à fait clair que les développeurs du noyau Linux essaient de trouver un ordonanceur CPU (mais aussi un ordonanceur pour les E/S, ce qui est encore plus important) qui marche le mieux possible pour tout le monde, y compris les desktops et les serveurs, de façon propre, maintenable et globale. Donc pas de hacks/cochonneries, bien que ce soit facile et tentant d'en introduire à ce niveau.
Voici comment Windows (et Solaris) s'y prend, selon la description du développeur de l'ordonanceur « ULE » de FreeBSD, Jeff Robberson :
« Solaris and windows actually both hook into the window manager. The window manager tells the scheduler which x task or windows application is in the foreground. The scheduler then uses this to give an extra boost to those tasks. » (source : http://jeffr-tech.livejournal.com/6602.html ).
Ou, si vous préferez une source plus officielle ( http://www.microsoft.com/mspress/books/sampchap/4354c.aspx ) : « The foreground process is the process that owns the thread that owns the window that's in focus. When the foreground window changes to one owned by a thread in a process higher than the Idle priority class, the Win32 subsystem changes the quantum values for all the threads in that process [...] » (etc., lire le reste de la page).
En bref et en français: le noyau Windows ne « devine » pas vraiment quelles sont les taches interactives à privilégier. L'environnement graphique de Windows indique au noyau le processus dont la fenêtre graphique a le focus, pour que le noyau lui donne une plus grande priorité.
C'est pour le moins inélégant, et c'est une solution à courte vue pour améliorer l'interactivité en environnement graphique fenêtré (windows...), qui n'améliorera en rien le fonctionnement sur des serveurs, par exemple (à l'inverse d'une solution totalement algorithmique pour trouver quel processus mérite du temps CPU sans sale hack, comme Linux essaie de faire) ! Et ce n'est certainement pas adapté à un environment souple et non-monolhitique comme Linux, où l'environement/interface utilisateur n'est pas un « builtin » indélogeable, mais peut être de natures très différentes, nativement réseau et multiutilisateur (X11, protocole X en réseau, console, framebuffer, qtpe, tinyx, ...: il faudrait implémenter ce sale hack partout, et en pondérant l'usage simultané de plusieurs d'entre eux ou par plusieurs utilisateurs, et faire transiter une telle information sur le réseau,...).
Remarquez que l'idée n'est pas neuve : https://db.usenix.org/publications/library/proceedings/cinci(...)
[^] # Re: Les « mérites » de l'ordonanceur de MS Windows [was Re: BSD ]
Posté par pasBill pasGates . Évalué à 1.
C'est au contraire une methode tres efficace, car celui qui a l'info (le window manager) la donne directement plutot qu'essayer de deviner, ce qui peut donner un mauvais resultat, qui coute du temps a essayer de deviner, ...
Quand a ameliorer le fonctionnement sur des serveurs, quelle utilite ? Ton scheduler Linux il continuera a essayer de deviner sur un serveur, sous Windows il perdra pas de temps a essayer de deviner, il a deja la reponse.
Et ce n'est certainement pas adapté à un environment souple et non-monolhitique comme Linux, où l'environement/interface utilisateur n'est pas un « builtin » indélogeable, mais peut être de natures très différentes, nativement réseau et multiutilisateur (X11, protocole X en réseau, console, framebuffer, qtpe, tinyx, ...: il faudrait implémenter ce sale hack partout, et en pondérant l'usage simultané de plusieurs d'entre eux ou par plusieurs utilisateurs, et faire transiter une telle information sur le réseau,...).
Tu me fais bien marrer avec "souple et non-monolithique", les 2 OS ont la meme architecture.
Quand a l'UI elle est tout autant nativement reseau et multi-user sous Windows.
[^] # Re: Les « mérites » de l'ordonanceur de MS Windows [was Re: BSD ]
Posté par Bozo_le_clown . Évalué à 5.
Tu veux dire qu'on peut ouvrir 2 sessions utilisateur avec un bureau et donc que 2 utilisateurs peuvent utiliser la même machine en même temps ?
Ou alors peut-être que pouvoir alterner entre 2 sessions séparées sur un même poste en conservant tant bien que mal des contextes séparés (ceux qui auront essayé de surfer dans 2 session alternées sous XP avec un firewall comprendront) correspond à ta définition d'OS multi-utilisateur.
[^] # Re: Les « mérites » de l'ordonanceur de MS Windows [was Re: BSD ]
Posté par pasBill pasGates . Évalué à 3.
Oui on peut, avec n'importe quelle version serveur de Windows. La limitation est volontaire sur la version desktop, c'est pas une limitation technique.
[^] # Re: Les « mérites » de l'ordonanceur de MS Windows [was Re: BSD ]
Posté par Bozo_le_clown . Évalué à 2.
En quoi est-ce inélégant de donner la main à l'utilisateur dans un contexte mono-utilisateur desktop, car c'est bien le desktop qui connait le mieux ses process en définitive ?
Est-il inimaginable que le kernel délègue la responsabilité au desktop de lui indiquer les process prioritaires pour sa partie par le biais d'un protocole et de composer avec ses autres processus critiques (C'est peut -être déjà le cas)
Quels sont ces algorithmes qui permettent sans coup férir de d'allouer les ressources au mieux . Sont ils toujours fiables ?
L'idée de Con de recompiler un noyau en fonction de l'usage(desktop ou serveur) est-elle si minable ?
Cette séparation des couches sous Linux est avantageuse en ce qu'elle apporte la stabilité; mais bien souvent elle est contre-productive.
En témoigne les nombreux trolls sur DCOP ou encore Beagle pour savoir si le noyau ou le desktop doit gérer ça.
La communication entre les couches ne reste-elle pas un pb entier pour Linux.
Merci d'éclairer la lanterne des candides en kernel hacking ?
[^] # Re: BSD
Posté par kowalsky . Évalué à 3.
J'ai vu une fois sur la mailling list NetBSD un gars qui
code un truc sur NetBSD.
Il envoit son truc.
En retour, on lui dit que c'est bien, mais que ça doit etre
modifiable par sysctl.
Il le fait.
Il envoit
Ensuite on lui demande de créer un branche special pour
sa modif.
Il le fait.
Il envoit.
On lui suggere de creer des sous branche, etc...
Il jete l'eponge, rien n'est fait en fin de compte.
Je ne sais pas sous les autres projets BSD comment
cela se passe, mais sur NetBSD, c'est vraiment serré
pour faire integrer du code dans le noyau...
[^] # Re: BSD
Posté par totof2000 . Évalué à 1.
# Réaction
Posté par patrick_g (site web personnel) . Évalué à 2.
http://lwn.net/Articles/242881/
Du reste toute la discussion sur LWN est intéressante à suivre :
http://lwn.net/Articles/242764/
[^] # Re: Réaction
Posté par patrick_g (site web personnel) . Évalué à 5.
In Linux we reject _lots_ of code, and that's the only way to create a quality kernel. It's a bit like evolutionary selection: breathtakingly wasteful and incredibly efficient at the same time.
# Super interview
Posté par Jean-Philippe (site web personnel) . Évalué à 3.
Le meilleur passage, tellement vrai :
[^] # Re: Super interview
Posté par herodiade . Évalué à 3.
En grande partie parce que, si les performances des CPU, la vitesse des bus mémoire et ATA, la quantité de mémoire vive, la capacité de stockage, les fonctionnalités (donc la taille) des logiciels ont considérablement augmenté, la rapidité des disques durs, elle, à quasiment stagné. La rapidité des disques durs a un rôle considérable dans le temps de démarrage des application ou de l'OS.
En somme nous subissons les conséquences d'une évolution peu harmonieuse des systèmes informatiques (matériel et logiciel). Ici, l'ordonancement des entrées/sorties, les caches, les queues d'accès disques, le prelinking et l'éditeur de liens dynamique, les systèmes de fichiers, etc. sont certainement plus cruciaux que le bon ordonancement des processus (CPU).
Il me semble que la vitesse et le débit des disques durs grand public (pas SCSI) n'ont même pas doublé en 10 ans.
[^] # Re: Super interview
Posté par briaeros007 . Évalué à 0.
pour rappel :
PIO Mode 0 26.4 Mbit/s 3.3 MB/s
Ultra DMA ATA 33 264 Mbit/s 33 MB/s
Serial ATA (SATA-300) 2.4 Gbit/s 300 MB/s
pour les pros:
SCSI 1 (5 MHz) 40 Mbit/s 5 MB/s
Ultra Wide SCSI 40 (16 bits/20 MHz) 320 Mbit/s 40 MB/s
Serial Attached SCSI 2 6 Gbit/s 750 MB/s
(beaucoup) plus de vitesses :
http://en.wikipedia.org/wiki/List_of_device_bandwidths
[^] # Re: Super interview
Posté par herodiade . Évalué à 2.
Tu en connais beaucoup, toi, des disques durs SATA ou PATA qui délivrent 300 MB/s ?
[^] # Re: Super interview
Posté par Zenitram (site web personnel) . Évalué à 4.
Coté disque dur, c'est presque l'inverse : les débits bruts montent certes un peu grâce à la densité, mais cette même densité fait augmenter le temps d'accès.
Au final, les perfs montent, mais pas des même pourcentages...
[^] # Re: Super interview
Posté par briaeros007 . Évalué à 2.
Au moins j'essaie de trouver des choses plutot que de raler quand quelqu'un essaie d'apporter des chiffres et d'affirmer des choses sans rien derrière (j'ai pas dis que c'était pas vrai, juste que vous ne donniez aucune donnée).
Mais bon chacun son truc.
Pour des tests avec des potes, les 50 Mo/s sont atteignables avec les dd actuels, donc déja plus du double de l'ata 33 qui était le débit théorique comme vous le faite si bien remarque.
Ensuite on peut faire des test avec un raptor 10k, ben ca sera pas la meme chose qu'avec un dd portable 5400 ... Tiens on dois aussi prendre en compte la gamme du dd la ...
Bref je suis tout ouï pour avoir d'autres chiffres.
[^] # Re: Super interview
Posté par Zenitram (site web personnel) . Évalué à 5.
http://www.hardware.fr/articles/628-3/comparatif-6-hdd-sata-(...)
Débit moyen en utilisation réelle (séquentiel) : 60 Mo/s. Loin des 300 Mo/s théoriques du SATA-2
En 10 ans, on est passé de 10-20 Mo/s à 60 Mo/s (multiplié par 3 à 6) alors que la RAM est passé de 32/64 Mo à 1 Go (multiplé par 16), et la puissance des CPU par plus de 50.
Les ordres de grandeurs de l'évolution est completement différent!
Temps d'accès moyen : 13 ms, la où on avait 10 ms avant.
Le disque dur est la seule partie mécanique d'un PC, et la mécanique va moins vite que l'électronique, tu devrais t'en être rendu compte.
PS : je compare des disques personnels classiques, les raptors 10K ne sont pas de cette gamme.
[^] # Re: Super interview
Posté par herodiade . Évalué à 3.
Par contre j'ai parfois de tels symptômes (audio ou vidéo saccadée, souris et rafraîchissement des fenêtres qui lagguent un peu) lorsqu'un processus en arrière plan consomme beaucoup d'I/O block (ou, cas similaire, lorsque Firefox ou Amarok ont tellement avalé de RAM que le système doit jongler avec la swap, très lente du fait des accès disques).
(ps: briaeros007, tu parle à point nommé des 5400 dans les portables, et comme justement les ventes de portables sont - en proportion avec les ventes de machines desktop classiques - en croissance constante, ça fait de l'utilisation de ce type de disques un cas d'utilisation de plus en plus représentatif du « desktop Linux », je crois. Les disques SSD seront peut-être une bonne solution).
Et vous, avez-vous rencontré ces problèmes de saccade et lenteurs uniquement lié à la répartition CPU (sans grosse charge I/O concomitante), avec des kernels récents et en utilisation « desktop » ?
[^] # Re: Super interview
Posté par patrick_g (site web personnel) . Évalué à 2.
Le goulet d'étranglement de mon laptop c'est clairement le disque 5400 tr/mn et il n'y a que quand le disque mouline à mort que les perfs s'écroulent vraiment.
Miam dans 15 jours mon nouveau laptop arrive avec son disque 7200 tr/mn et à moi les perfs décoiffantes !
[^] # Re: Super interview
Posté par briaeros007 . Évalué à 2.
Mais il est vrai que les deux choses que j'utilise pour écouter du son : mpd et mplayer, ont toujours au moins une prio de -9 donc ils prennent leur temp cpu sur les autres processus au pire :D
# Explications de Linus Torvalds
Posté par herodiade . Évalué à 2.
Cf. http://kerneltrap.org/node/14008
# Pouf pouf
Posté par Sylvain Sauvage . Évalué à 4.
http://conferences.oreillynet.com/cs/os2007/view/e_sess/1337(...)
C’est-à-dire : « Tout ce que j’ai eu besoin de savoir pour être un développeur à succès sur le noyau Linux et que j’ai appris à la maternelle. »
Coïncidence ?
(Même le nom de la conf…) →[]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.