Je suis tellement pas d'accord avec toi, aussi bien sur ton analyse technique que sur les objectifs de ton message que je ne sais meme pas par ou commencer. Disons la technique.
Donc commencons par Qt, honneur au plus age. Qt existe depuis une epoque ou le C++ n'etait pas portable avec la STL et qu'il etait difficile de trouver un compilo qui s'en sorte avec. Cela explique beaucoup de chose dans son design. Apres il y a une faute fondamentale pour un toolkit. Il y a une regle, qu'ils ont decouvert que trop tard dans leur histoire, si on veut fournir une API/ABI stable au cour du temps, on utilise le C. Le C++ qui a du mal a avoir une ABI stable pose deja un probleme de base, mais le fait que les champs prives finissent dans les headers rend impossible de fournir la moindre stabilite a long terme. LLVM l'a bien compris, seul l'api C sera stable. Cette erreur est a mon gout fatale pour un toolkit. On peut rajouter que le C++ a aussi un coup d'utilisation CPU et memoire superieur a du C, mais c'est globalement irrelevant pour cette discussion.
GTK n'a pas ce probleme, et ils ont ete capable de faire vivre leur API sur le plus long terme. Par contre, le design meme de l'architecture de ce toolkit pose de gros probleme de performance et d'efficacite, hors dans un monde ou tout se dirige vers l'embarque, GTK se revele completement inadapte. Les evolutions de ce toolkit ont essaye de combler le probleme, mais ca releve plus de la rustine que d'une veritable solution. Ce qui tend a rendre ce toolkit obsolete (et par la meme, la desaffection des developpeurs du coeurs du biniou).
Maintenant tu prend en exemple Chrome parce que eux, ils n'ont pas pris de toolkit, donc ils s'en sortent mieux que Mozilla. Comment dire, c'est une excuse facile ! Deja les problemes d'integration et les bugs de Chrome sont nombreux. Copier/Colle qui foire une fois sur deux, le rendu des textes dans un autre alphabet que occidentale qui sont loufoque, … Pour Mozilla, le principal probleme a mon sens c'est leur code source et leur gestion de la communaute. Je n'ai regarde que le code de SpiderMonkey et consort, mais c'est vraiment calamiteux et la communaute des developpeurs autre que Mozilla a vraiment du mal a participer (voir meme a juste utiliser leur techno). Ca s'explique par l'age de la bete, mais quand on voit v8 ou WebKit, c'est une tout autre histoire… Faudrait commencer par faire le menage chez soi avant d'accuser les toolkits de pas vous aider.
Dans le meme genre, tu peux prendre aussi LibreOffice/OpenOffice qui ont aussi leur propre toolkit. Une vrai bouse qui rame et prend son temps meme avec un i7, des Go de ram et un SSD. Et je parle meme pas de l'integration correct a X (l'integration correct au desktop kde/gnome etant trop loin…). Developper son propre toolkit, ca donne ca. Des couts de developpement supplementaire, des erreurs de design, car on n'a pas l'experience des gens qui font des toolkits donc on "loupe" des trucs. Et avec le temps ca ralentit completement le developpement d'un projet en augmentant la masse de developpeur necessaire pour le maintenir en vie. Surtout que l'excuse le toolkit, il fait pas ce qu'on veut ou ils cassent tout dans le temps, c'est vraiment petit quand on est une societe avec les moyens ou un gros projet libre. On peut influencer voir participer (concept nouveau dans le logiciel libre) dans le developpement des projets utilises en dependences. Vraiment une idee de fou.
Enfin sur le fond, ton message est de dire que c'est la faute au toolkit si Linux n'a pas pris sur le desktop. Qu'il n'en faut que un pour que l'on reussisse a s'imposer. Bah meme si on avait eu un super toolkit de la mort qui tue, unique, performant, joli, portable, lege et stable pour les 50 ans a venir, on n'aurait pas plus pris de part de marche sur le desktop. Regarde juste Apple, ils n'arrivent sur le desktop que par le cote (les vents d'ipod, iphone et ipad drivant les ventent de matos) et malgre tout ca, ils en sont a 7 ou 8% de part de marche mondial. Oh, et ils ont aussi un toolkit unique et du beau matos. Le probleme du desktop, c'est qu'il y a une arme de milliard d'individu et de societe refractaire a tout changement qui ne changeront jamais leurs habitudes. La strategie de l'attaque frontale, genre troll qui fonce dans le tas, c'est sur c'est heroique, ca fait un beau film d'action et de sympathique scene de bataille. Mais a la fin, le troll, il meurt. Il faut toujours s'installer la ou l'ennemie n'est pas, se fortifier et s'etendre. Et uniquement a la fin attaquer la cible principale, si elle existe encore.
De plus, tu pars du principe qu'avoir des applications isolees, des iles qui echangent des donnees de temps en temps, c'est la solution. La preuve, Apple, Microsoft et le web font ca et ca leur reussi. Sauf que une des raisons pour la reussite de Gmail, c'est que tu as en meme temps, l'IM, le calendrier, la recherche, la preview de document, … Le tout bien integre. Parcontre, tu n'as plus le choix. Et globalement aucun lecteur de mail classique ne s'en approchent (a part Kontact, mais ils arrivent pas a gerer mes 7Go de mails). Tu loupes un pan entier de ce qui est l'objectif d'une partie des developpeurs du libre. Quand on a fait le deuil de la domination du monde, qu'on arrete de vouloir concurrencer des gens qu'on ne peut pas concurrencer. Alors ce pose la question de qu'est-ce qu'on peut faire mieux ? Qu'est-ce qu'on peut ameliorer par rapport a l'existant et qui attirera suffisamment de gens, plutot des developpeurs si possible, dans notre petite forterresse ?
La reponse que le libre a donnee a cette question, c'est l'integration quit a avoir 5 ou 6 desktop. C'est sur, ca correspond pas a Mozilla, qui vit dans un monde ou tout est isole et ou la communication entre chacun est limite. Mais et pour le coup, je trouve ce qu'a fait le projet KDE vraiment pas mal dans ce domaine. Ils n'ont rien standardiser pour la communication entre leurs applications, ils ont juste developpe leur technologie adhoc et integre joyeusement tout ca. Et je suis pas un developpeur de KDE, je participe au projet Enlightenment, mais ca m'empechera pas de reconnaitre les reussites des autres projets.
D'ailleur, j'ai oublie de faire ma charge sur les standards. C'est truc, c'est une calamite, suffit de regarder FreeDesktop, le jour ou j'y trouve un standard de qualite, bien ecrit, bien pense et utile, je t'offre le champagne. Les standards sont une maniere a un projet d'imposer ses choix a un autre en etant le premier a ecrire la spec, car les temps entre les projets ne sont pas les memes. Il n'y a pas un expert en permanence disponible dans tous les projets de desktop pres a negocier n'importe qu'elle sujet de standard. Resultat, le standard, il se fait tout seul dans son coin et 6 mois plus tard on se rend compte qu'on veut implementer la meme feature, donc on regarde ce nouveau standard pour se rendre compte que c'est une catastrophe… Et on perd du temps a l'implementer de la maniere la moins catastrophique qui soit. Forcement c'est encore une solution a minima qui aide personne et impact tout le monde.
# Les iles
Posté par cedric . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 10.
Je suis tellement pas d'accord avec toi, aussi bien sur ton analyse technique que sur les objectifs de ton message que je ne sais meme pas par ou commencer. Disons la technique.
Donc commencons par Qt, honneur au plus age. Qt existe depuis une epoque ou le C++ n'etait pas portable avec la STL et qu'il etait difficile de trouver un compilo qui s'en sorte avec. Cela explique beaucoup de chose dans son design. Apres il y a une faute fondamentale pour un toolkit. Il y a une regle, qu'ils ont decouvert que trop tard dans leur histoire, si on veut fournir une API/ABI stable au cour du temps, on utilise le C. Le C++ qui a du mal a avoir une ABI stable pose deja un probleme de base, mais le fait que les champs prives finissent dans les headers rend impossible de fournir la moindre stabilite a long terme. LLVM l'a bien compris, seul l'api C sera stable. Cette erreur est a mon gout fatale pour un toolkit. On peut rajouter que le C++ a aussi un coup d'utilisation CPU et memoire superieur a du C, mais c'est globalement irrelevant pour cette discussion.
GTK n'a pas ce probleme, et ils ont ete capable de faire vivre leur API sur le plus long terme. Par contre, le design meme de l'architecture de ce toolkit pose de gros probleme de performance et d'efficacite, hors dans un monde ou tout se dirige vers l'embarque, GTK se revele completement inadapte. Les evolutions de ce toolkit ont essaye de combler le probleme, mais ca releve plus de la rustine que d'une veritable solution. Ce qui tend a rendre ce toolkit obsolete (et par la meme, la desaffection des developpeurs du coeurs du biniou).
Maintenant tu prend en exemple Chrome parce que eux, ils n'ont pas pris de toolkit, donc ils s'en sortent mieux que Mozilla. Comment dire, c'est une excuse facile ! Deja les problemes d'integration et les bugs de Chrome sont nombreux. Copier/Colle qui foire une fois sur deux, le rendu des textes dans un autre alphabet que occidentale qui sont loufoque, … Pour Mozilla, le principal probleme a mon sens c'est leur code source et leur gestion de la communaute. Je n'ai regarde que le code de SpiderMonkey et consort, mais c'est vraiment calamiteux et la communaute des developpeurs autre que Mozilla a vraiment du mal a participer (voir meme a juste utiliser leur techno). Ca s'explique par l'age de la bete, mais quand on voit v8 ou WebKit, c'est une tout autre histoire… Faudrait commencer par faire le menage chez soi avant d'accuser les toolkits de pas vous aider.
Dans le meme genre, tu peux prendre aussi LibreOffice/OpenOffice qui ont aussi leur propre toolkit. Une vrai bouse qui rame et prend son temps meme avec un i7, des Go de ram et un SSD. Et je parle meme pas de l'integration correct a X (l'integration correct au desktop kde/gnome etant trop loin…). Developper son propre toolkit, ca donne ca. Des couts de developpement supplementaire, des erreurs de design, car on n'a pas l'experience des gens qui font des toolkits donc on "loupe" des trucs. Et avec le temps ca ralentit completement le developpement d'un projet en augmentant la masse de developpeur necessaire pour le maintenir en vie. Surtout que l'excuse le toolkit, il fait pas ce qu'on veut ou ils cassent tout dans le temps, c'est vraiment petit quand on est une societe avec les moyens ou un gros projet libre. On peut influencer voir participer (concept nouveau dans le logiciel libre) dans le developpement des projets utilises en dependences. Vraiment une idee de fou.
Enfin sur le fond, ton message est de dire que c'est la faute au toolkit si Linux n'a pas pris sur le desktop. Qu'il n'en faut que un pour que l'on reussisse a s'imposer. Bah meme si on avait eu un super toolkit de la mort qui tue, unique, performant, joli, portable, lege et stable pour les 50 ans a venir, on n'aurait pas plus pris de part de marche sur le desktop. Regarde juste Apple, ils n'arrivent sur le desktop que par le cote (les vents d'ipod, iphone et ipad drivant les ventent de matos) et malgre tout ca, ils en sont a 7 ou 8% de part de marche mondial. Oh, et ils ont aussi un toolkit unique et du beau matos. Le probleme du desktop, c'est qu'il y a une arme de milliard d'individu et de societe refractaire a tout changement qui ne changeront jamais leurs habitudes. La strategie de l'attaque frontale, genre troll qui fonce dans le tas, c'est sur c'est heroique, ca fait un beau film d'action et de sympathique scene de bataille. Mais a la fin, le troll, il meurt. Il faut toujours s'installer la ou l'ennemie n'est pas, se fortifier et s'etendre. Et uniquement a la fin attaquer la cible principale, si elle existe encore.
De plus, tu pars du principe qu'avoir des applications isolees, des iles qui echangent des donnees de temps en temps, c'est la solution. La preuve, Apple, Microsoft et le web font ca et ca leur reussi. Sauf que une des raisons pour la reussite de Gmail, c'est que tu as en meme temps, l'IM, le calendrier, la recherche, la preview de document, … Le tout bien integre. Parcontre, tu n'as plus le choix. Et globalement aucun lecteur de mail classique ne s'en approchent (a part Kontact, mais ils arrivent pas a gerer mes 7Go de mails). Tu loupes un pan entier de ce qui est l'objectif d'une partie des developpeurs du libre. Quand on a fait le deuil de la domination du monde, qu'on arrete de vouloir concurrencer des gens qu'on ne peut pas concurrencer. Alors ce pose la question de qu'est-ce qu'on peut faire mieux ? Qu'est-ce qu'on peut ameliorer par rapport a l'existant et qui attirera suffisamment de gens, plutot des developpeurs si possible, dans notre petite forterresse ?
La reponse que le libre a donnee a cette question, c'est l'integration quit a avoir 5 ou 6 desktop. C'est sur, ca correspond pas a Mozilla, qui vit dans un monde ou tout est isole et ou la communication entre chacun est limite. Mais et pour le coup, je trouve ce qu'a fait le projet KDE vraiment pas mal dans ce domaine. Ils n'ont rien standardiser pour la communication entre leurs applications, ils ont juste developpe leur technologie adhoc et integre joyeusement tout ca. Et je suis pas un developpeur de KDE, je participe au projet Enlightenment, mais ca m'empechera pas de reconnaitre les reussites des autres projets.
D'ailleur, j'ai oublie de faire ma charge sur les standards. C'est truc, c'est une calamite, suffit de regarder FreeDesktop, le jour ou j'y trouve un standard de qualite, bien ecrit, bien pense et utile, je t'offre le champagne. Les standards sont une maniere a un projet d'imposer ses choix a un autre en etant le premier a ecrire la spec, car les temps entre les projets ne sont pas les memes. Il n'y a pas un expert en permanence disponible dans tous les projets de desktop pres a negocier n'importe qu'elle sujet de standard. Resultat, le standard, il se fait tout seul dans son coin et 6 mois plus tard on se rend compte qu'on veut implementer la meme feature, donc on regarde ce nouveau standard pour se rendre compte que c'est une catastrophe… Et on perd du temps a l'implementer de la maniere la moins catastrophique qui soit. Forcement c'est encore une solution a minima qui aide personne et impact tout le monde.