>> 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.
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 herodiade . En réponse au journal L'interview vérité de Con Kolivas. É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).