> 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.
# Regrettable
Posté par IsNotGood . En réponse au journal L'interview vérité de Con Kolivas. É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.