OK donc si je comprends bien, S2TC serait un sous-ensemble de S3TC qui évite les parties brevetées.
Plus bas on lit:
when a precompressed texture is uploaded, nothing changes - it is uploaded as "full" S3TC
when an uncompressed texture is uploaded as a compressed format, it is converted using the S2TC encoder
OK donc soyons clairs, dans le monde réel, les jeux vidéo fournissent leur propres textures compressées, ils ne se reposent pas sur le GL pour compresser leurs textures pour eux (en tout cas ils n'ont pas à le faire).
La spec OpenGL (et ES) va plus loin en proposant de compresser à la volée des textures non compressées. C'est cette partie qui est sujette à brevets logiciels du point de vue de Mesa (car cette partie doit être implémentée par Mesa) et c'est ça qui rend impossible pour Mesa d'exposer l'extension S3TC. Mais du point de vue d'un développeur de jeux vidéo, ça n'est pas utile.
Ce que j'aimerais, c'est une variante de l'extension S3TC moins le support de la compression à la volée. Comme ça, Mesa pourrait l'exposer sans problème sur les pilotes de matériel gérant ce format en dur (Mesa ne pourrait pas l'exposer sur les autres pilotes et en particulier pas sur LLVMpipe et autres pilotes logiciels), et ça suffirait pour les jeux vidéo.
Note que c'est ce que l'extension de WebGL expose. Pas de support pour la compression à la volée, du coup, pas de problèmes de brevets tant que le matériel prend nativement le format en charge.
Je ne comprends pas: le problème n'est pas qu'il n'existe pas de format de textures compressées libre—il existe ETC2 pour les textures RGBA et ETC1 pour les textures RGB—le problème est que ces formats libres ne sont pas implémentés dans le matériel. ETC1 commence certes à être implémenté dans pas mal de GPUs, mais le manque de support pour les textures RGBA le rend peu utile (90% des textures utilisées dans les jeux ont un canal alpha qui peut être utilisé pour divers effets), donc c'est plutôt ETC2 qu'on veut, mais je ne connais aucun matériel en circulation qui l'implémente.
On peut certes implémenter un format de textures compressées dans le peintre de fragments (ma traduction de fragment shader) mais ça ne sera probablement pas aussi performant qu'un support direct par le matériel, enfin je serais ravi d'être démenti.
Le nombre de symbole dans les libs C++ etant juste dantesque, tu te retrouves avec des temps de demarrage hallucinant et non ameliorable.
La solution à se problème est -fvisibility=hidden.
Pour voir à quel point tu es loin de la réalité, fais un démarrage à froid de la version stable de Firefox (je ne garantis rien sur les binaires de ta distro, je parle des binaires mozilla) avec profil par défaut. Ça devrait démarrer en 2 secondes maxi si tu as une machine correcte, alors que libxul.so est une immense bibliothèque C++ et que Firefox ne peut rien afficher sans qu'elle soit en grande partie chargée.
Ensuite de nombreuses applications C++ sur bureau libre ont d'autres problèmes, mais c'est leur faute:
- Chargement d'un grand nombre de bibliothèques différentes, avec leurs propres dépendances. Le gros truc à éviter.
- Grand nombre de constructeurs d'objets globaux/statiques.
- relocations inutiles
- voir le blog de Glandium
Moi aussi. La solution que j'ai retenue pour pouvoir poster sur LinuxFR sans me faire emmerder est la disposition English-international.
Cette obsession des détails (accents) alors que le français est malmené de façon bien plus profonde sur LinuxFR (anglicismes incontrôlés et inutiles) me fait toujours un peu hésiter à y retourner.
Ce qu'il faudrait ça serait un équivalent français de LWN.net, un site où le commentateur moyen a un réelle expérience du logiciel libre et est là pour parler de sujets qu'il connaît. J'ai l'impression que la majorité des commentateurs ici n'ont pas d'expérience en développement logiciel.
Tu ne devrais pas prendre ça autant au sérieux, je disais ça comme d'autres commentateurs ici disent "Saymal". Une façon d'exprimer un jugement effectivement moral, tout en le reconnaissant et en le tournant un peu en dérision avec cette formule un peu trop solennelle, "le mal".
Epoque révolue, mais même dans ce cas, ça n'est pas mon propos --- je ne suis pas un représentant de Mozilla ici, c'est pas mon job de justifier tout ce que Mozilla a jamais fait.
Encore une fois, je pense que Firefox peut proposer une plate-forme d'extensions sans que pour autant les attentes en termes de compatibilité soient les mêmes que pour un toolkit. Il ne s'agit que d'extensions pour une application, pas d'une base pour construire de nouvelles applications. Le vrai "toolkit" implémenté par Firefox est ailleurs: c'est les standards du Web, et là, on préserve la compatibilité de façon très stricte.
On est bien d'accord que dans les cas simples, où une application n'utilise qu'une version de la bibliothèque, il suffit de distribuer les anciennes versions de la bibliothèque. Encore faut-il le faire. Si une application A utilise LibFoo 1.0 et que LibFoo 2.0 la remplace comme unique version installée dans les nouvelles distros, les développeurs de A vont être submergés de plaintes de clients même si "il suffit de faire apt-get install libfoo-1". Il faut distribuer les anciennes versions par défaut, avec les nouvelles, pour que la sortie de la nouvelle soit réellement indolore pour l'ancienne, tant qu'elle a des utilisateurs.
Ensuite il y a les cas plus complexes où une application a besoin des 2 versions simultanément, non pas parce que ses développeurs sont tordus, mais typiquement parce que parmi les autres bibliothèques qu'elle utilise, certaines sont déjà passées à LibFoo2 et d'autres pas encore. Un exemple de ça est ce que j'ai mentionné dans le journal: les plugins utilisant GTK2 et ne pouvant pas se déplacer dans un processus séparé (Java). De nombreux autres exemples, je suppose, sont à trouver dans les applications de bureau libre où la tradition est de lier dynamiquement à un grand nombre de bibliothèques externes. Dans tous ces cas, en cas de cassure de la compatibilité binaire, en plus de distribuer les anciennes versions, il faut que les différentes versions soient utilisables simultanément.
Les extensions Firefox, ça n'est pas une partie intégrante du Web (puisque ça ne marche que dans Firefox).
Et d'autre part, la surface exposée par Gecko aux extensions (par XPCOM) est si énorme que c'est inévitable. Si tu veux des addons avec compatibilité à plus long terme comme dans certains autres navigateurs, la contrepartie inévitable est des add-ons moins puissants, comme dans ces autres navigateurs. Du point de vue du dév d'extensions, ça se discute, par contre, du point de vue de l'utilisateurs, après une période difficile l'année dernière, actuellement le nombre d'add-ons sur addons.mozilla.org qui ne sont pas à jour lors de la sortie d'un nouveau Firefox stable est si faible (bien en dessous de 1%) que le problème n'est plus visible.
Des add-ons puissants qui accèdent directement au cœur du navigateur, ça cadre bien dans la mission Mozilla: permettre aux gens de bidouiller avec le Web, et de prendre le contrôle de leur Web plutôt que de se le faire imposer. Exemples: AdBlock+, Collusion, etc. Ça vaut bien le compromis sur la compatibilité.
Oh, j'ai lu ce bug maintenant. Apparemment il s'agit d'une propriété CSS qui a été dé-préfixée. Ceci veut dire que les pages qui ont été cassées étaient des pages programmées pour ne fonctionner que dans une liste finie de navigateurs. Ça, c'est le mal. En gardant la compatibilité avec elles (en conservant ce préfixe -moz ) on ferait le mal, en permettant à des pages Web qui ne marchent que dans Firefox de continuer de proliférer. Il est très important que tous les fabricants de navigateurs adoptent cette attitude stricte face aux préfixes CSS propriétaires, sinon on est repartis pour un scénario à la IE6 avec un Web codé pour le moteur Web dominant du moment.
Ce que cet exemple montre est une différence très importante entre le Web et les autres plate-formes: le Web est multi-implémentation, on y décourage les applications qui ne fonctionnent que sur une implémentation.
J'ai (bien entendu) exagéré un peu avec le 100.00%. Disons 99.99% si tu préfères. Il y a toujours des cas où une API doit cesser d'être supportée, par exemple si elle a vraiment trop peu d'utilisateurs pour justifier son coût de maintenance, ou bien si elle est de façon inhérente une faille de sécurité. Mais on ne peut pas comparer ça avec les changements de version majeure de toolkits: quand on entend que "Qt5 est 99% compatible avec Qt4" alors que question compatibilité des binaires existants, ça serait plutôt 0% --- les développeurs de toolkit parlent de compatibilité source alors que les utilisateurs ont besoin de compatibilité binaire pour leurs applications --- je veux dire clairement que le souci de compatibilité du Web en général, et de Firefox en particulier, est plusieurs ordres de grandeur au-dessus de ce que les toolkits offrent. Un site de 1998 a de grandes chances de s'afficher encore correctement dans le Firefox d'aujourd'hui, alors qu'une application de bureau libre de 1998 n'a aucune chance de ne serait-ce que démarrer aujourd'hui.
Le comportement de Microsoft sur Metro me fait penser, et je ne suis pas le seul, que Microsoft a vraiment oublié les raisons de ses succès commerciaux et qu'ils vont se planter cette fois-ci.
Pourquoi faut-il que Microsoft fournisse de quoi faire des interfaces comme à l'époque des win 16bit,
Parce que dans le monde réel, les gens ne considèrent pas acceptable que leurs applications binaires cessent de fonctionner quand ils mettent à jour leur système d'exploitation.
pourquoi faudrait-il que GTK et Qt imitent cette stratégie,
Il ne le faut que dans la mesure où les bureaux à base de GTK et Qt ambitionnent d'obtenir plus de 1% de parts de marché. On se souvient de GNOME qui ambitionnait 10% pour 2010.
et pourquoi Mozilla serait par contre complètement exempté de devoir répondre à la légitime attente de ceux qui font des interfaces avec XUL, sous prétexte que certains ne le demandent pas ?
Là on commence à tout mélanger: avant on parlait de Gecko comme bibliothèque binaire, maintenant tu parles de XUL. Si tu veux parler de ça il va te falloir un autre interlocuteur que moi, car je ne travaille personnellement que sur Gecko.
Gecko ne prétend pas être un toolkit, ni même en aucune façon utilisable comme une bibliothèque externe. On ne prétend pas ça. On ne peut pas empêcher des gens de le faire, mais ça n'est vraiment pas encouragé. Il y a très longtemps, on l'encourageait, mais cette époque est révolue depuis longtemps. Et je ne connais aucun project qui le fasse aujourd'hui.
A partir de là, il n'y a aucune validité à retourner contre Gecko les critiques que je formule contre des toolkits.
C'est comme si je disais "Peugeot n'investit pas assez dans les voitures hybrides" et que tu me répondais "Mozilla non plus".
La contradiction peut se résoudre en admettant qu'il est impossible de maintenir un navigateur Web compétitif sans une équipe d'au moins, disons, 50 personnes (et c'est très optimiste) même en ayant une assez grande partie du travail fourni par WebKit.
Je parlais d'utiliser Qt3 et Qt4 en même temps dans la même application, ce qui suppose en particulier le placement de toute partie incompatible dans un espace de noms séparé.
Les applications utilisant Gecko distribuent leur propre copie de Gecko (par exemple, Firefox et Thunderbird ont leur propre copie) donc c'est un non-problème. On peut bien sûr pointer des inconvénients de cette approche (utilisation de quelques dizaines de MB de mémoire de plus) mais ces arguments ont à leur tour des contre-arguments (permettre à Thunderbird de distribuer un plus petit Gecko que Firefox, par exemple sans support de WebGL sous Windows qui est assez volumineux, etc).
On est bien d'accord sur les faits, mais on en tire des conclusions entièrement différentes.
Le meilleur exemple en est quand tu dis:
Qt5 est quasiment source compatible avec Qt4.
Donc voilà, du point de vue des développeurs de toolkits, pour sortir une nouvelle version du toolkit sans causer trop de problèmes, il suffit d'être "quasiment source compatible".
C'est là que je ne suis pas du tout d'accord: pour moi, la barre en termes de compatibilité est bien plus haut. Il faut aussi préserver à 100.00% la compatibilité binaire descendante: les binaires compilés pour Qt4 doivent continuer de s'exécuter sans aucune modification sous Qt 5, Qt 6, et ainsi de suite jusqu'à ce que vraiment presque plus personne n'ait de binaires Qt4 à faire tourner. Et, chose très importante, il doit rester possible d'utiliser les différentes versions simultanément, dans la même application.
Il y a différentes façon d'atteindre cet objectif. La façon Microsoft, qui est la première direction où regarder puisque c'est ce qu'il y a de plus proche techniquement et qu'ils ont un certain succès commercial, c'est simplement de continuer de distribuer des binaires des anciennes versions de leurs SDK, et de concevoir leurs interfaces pour permettre d'utiliser de multiples versions simultanément. C'est comme si les distributions binaires de Qt5 contenaient une copie des binaires de Qt4.
Android et Apple aussi continuent de distribuer leurs vieux SDK binaires avec les nouveaux.
Idem pour les distributions binaires d'implémentations d'OpenGL, qui sont les championnes de la compatibilité descendante, une application OpenGL 1.0 d'il y a presque vingt ans pouvant encore tourner sans recompilation sur n'importe quelle machine ayant des pilotes OpenGL.
Si les toolkits libres veulent être pris au sérieux, il faut qu'ils fassent la même chose. Dans mon journal, j'ai donné un exemple concret montrant en quoi le fait que GTK3 ne fait pas ça, est une grande cause de problèmes pour Firefox.
Du coup, le coût réel d'accroître un toolkit pour y include des choses come QVector et QList, est plus important dans ma vision des choses que dans la tienne, car ce gonflement va être multiplié par un certain facteur pour garantir la compatibilité au fil des années.
Je ne rentre pas plus dans le détail de ta réponse parce que je pense que le point important de désaccord était celui-ci.
La catégorie des navigateurs WebKits qui prennent au sérieux cette histoire de bibliothèques bien séparées; cette catégorie comprend uniquement des "petits" navigateurs comme Epiphany que presque personne n'utilise, qui ont généralement de 1 à 3 ans de retard sur les fonctonnalités Web des principaux navigateurs, et qui n'offrent pas beaucoup des fonctionnalités d'un navigateur moderne qui ne sont pas fournies par ces bibliothèques (par exemple Sync).
Et puis les navigateurs qui se moquent comme d'une guigne de cette histoire de bibliothèques séparées, qui ont leur propre variante de WebKit, qui le développent conjointement à leur propre moteur JS, et leur propre code applicatif. Cette catégorie inclut tous les navigateurs WebKit qui ont jamais rencontré le succès, en particulier Chrome et Safari.
Bref, l'histoire des jolies bibliothèques bien propres et séparées, c'est une énorme arnaque et ceux qui y croient le font à leurs dépens. En fait, c'est exactement la même histoire qu'avec les toolkits.
Epiphany est un navigateur a minima au-dessus de WebKit, donc l'effort de portage est incomparablement plus faible que pour Firefox. Il y a aussi des facteurs architecturaux, mais ça n'est pas une raison de critiquer les choix architecturaux de Firefox, au vu des bénéfices qu'il en tire par ailleurs (Firefox étant plus multi-plateformes et faisant de l'intégration dans des plate-formes non-GTK, et offrant à ses add-ons des capacités d'intégration impossibles à offrir avec WebKit).
En fait, que ça soit le cas ou pas ne fait pas une grande différence. Être la même personne n'offre pas une bien grande garantie contre les régressions. La seule garantie contre les régressions est d'avoir une batterie de test unitaires vraiment très exhaustive (KDE n'a que quelques maigres parties couvertes par des tests unitaires) et d'avoir une règle très stricte de rejet de toute modification qui régresserait un test unitaire sur une machine de test (KDE n'a pas à ma connaissance de machine de tests ni de règle de rejet de patchs causant des régressions, en tout cas n'en avait pas à l'époque de la réécriture).
[^] # Re: Il existe déjà des formats libres; le problème c'est le support matériel.
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche S2TC fait la pige à S3 pour la gestion libre des textures !. Évalué à 5.
OK, j'ai lu l'annonce et je comprends maintenant:
OK donc si je comprends bien, S2TC serait un sous-ensemble de S3TC qui évite les parties brevetées.
Plus bas on lit:
OK donc soyons clairs, dans le monde réel, les jeux vidéo fournissent leur propres textures compressées, ils ne se reposent pas sur le GL pour compresser leurs textures pour eux (en tout cas ils n'ont pas à le faire).
La spec OpenGL (et ES) va plus loin en proposant de compresser à la volée des textures non compressées. C'est cette partie qui est sujette à brevets logiciels du point de vue de Mesa (car cette partie doit être implémentée par Mesa) et c'est ça qui rend impossible pour Mesa d'exposer l'extension S3TC. Mais du point de vue d'un développeur de jeux vidéo, ça n'est pas utile.
Ce que j'aimerais, c'est une variante de l'extension S3TC moins le support de la compression à la volée. Comme ça, Mesa pourrait l'exposer sans problème sur les pilotes de matériel gérant ce format en dur (Mesa ne pourrait pas l'exposer sur les autres pilotes et en particulier pas sur LLVMpipe et autres pilotes logiciels), et ça suffirait pour les jeux vidéo.
Note que c'est ce que l'extension de WebGL expose. Pas de support pour la compression à la volée, du coup, pas de problèmes de brevets tant que le matériel prend nativement le format en charge.
# Il existe déjà des formats libres; le problème c'est le support matériel.
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche S2TC fait la pige à S3 pour la gestion libre des textures !. Évalué à 5. Dernière modification le 14 octobre 2012 à 01:08.
Je ne comprends pas: le problème n'est pas qu'il n'existe pas de format de textures compressées libre—il existe ETC2 pour les textures RGBA et ETC1 pour les textures RGB—le problème est que ces formats libres ne sont pas implémentés dans le matériel. ETC1 commence certes à être implémenté dans pas mal de GPUs, mais le manque de support pour les textures RGBA le rend peu utile (90% des textures utilisées dans les jeux ont un canal alpha qui peut être utilisé pour divers effets), donc c'est plutôt ETC2 qu'on veut, mais je ne connais aucun matériel en circulation qui l'implémente.
On peut certes implémenter un format de textures compressées dans le peintre de fragments (ma traduction de fragment shader) mais ça ne sera probablement pas aussi performant qu'un support direct par le matériel, enfin je serais ravi d'être démenti.
[^] # Re: Les iles
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 6. Dernière modification le 13 octobre 2012 à 19:10.
La solution à se problème est -fvisibility=hidden.
Pour voir à quel point tu es loin de la réalité, fais un démarrage à froid de la version stable de Firefox (je ne garantis rien sur les binaires de ta distro, je parle des binaires mozilla) avec profil par défaut. Ça devrait démarrer en 2 secondes maxi si tu as une machine correcte, alors que libxul.so est une immense bibliothèque C++ et que Firefox ne peut rien afficher sans qu'elle soit en grande partie chargée.
Ensuite de nombreuses applications C++ sur bureau libre ont d'autres problèmes, mais c'est leur faute:
- Chargement d'un grand nombre de bibliothèques différentes, avec leurs propres dépendances. Le gros truc à éviter.
- Grand nombre de constructeurs d'objets globaux/statiques.
- relocations inutiles
- voir le blog de Glandium
[^] # Re: Les iles
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à -3. Dernière modification le 13 octobre 2012 à 18:49.
Moi aussi. La solution que j'ai retenue pour pouvoir poster sur LinuxFR sans me faire emmerder est la disposition English-international.
Cette obsession des détails (accents) alors que le français est malmené de façon bien plus profonde sur LinuxFR (anglicismes incontrôlés et inutiles) me fait toujours un peu hésiter à y retourner.
Ce qu'il faudrait ça serait un équivalent français de LWN.net, un site où le commentateur moyen a un réelle expérience du logiciel libre et est là pour parler de sujets qu'il connaît. J'ai l'impression que la majorité des commentateurs ici n'ont pas d'expérience en développement logiciel.
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 4. Dernière modification le 13 octobre 2012 à 18:39.
Tu ne devrais pas prendre ça autant au sérieux, je disais ça comme d'autres commentateurs ici disent "Saymal". Une façon d'exprimer un jugement effectivement moral, tout en le reconnaissant et en le tournant un peu en dérision avec cette formule un peu trop solennelle, "le mal".
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à -2.
Ta question montre que tu n'as lu ni mon journal, ni mes réponses à des commentaires ici qui posaient la même question.
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 2.
Epoque révolue, mais même dans ce cas, ça n'est pas mon propos --- je ne suis pas un représentant de Mozilla ici, c'est pas mon job de justifier tout ce que Mozilla a jamais fait.
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 0.
Cf ma réponse à Zenitram ci-dessus.
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 1.
Encore une fois, je pense que Firefox peut proposer une plate-forme d'extensions sans que pour autant les attentes en termes de compatibilité soient les mêmes que pour un toolkit. Il ne s'agit que d'extensions pour une application, pas d'une base pour construire de nouvelles applications. Le vrai "toolkit" implémenté par Firefox est ailleurs: c'est les standards du Web, et là, on préserve la compatibilité de façon très stricte.
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à -2.
On est bien d'accord que dans les cas simples, où une application n'utilise qu'une version de la bibliothèque, il suffit de distribuer les anciennes versions de la bibliothèque. Encore faut-il le faire. Si une application A utilise LibFoo 1.0 et que LibFoo 2.0 la remplace comme unique version installée dans les nouvelles distros, les développeurs de A vont être submergés de plaintes de clients même si "il suffit de faire apt-get install libfoo-1". Il faut distribuer les anciennes versions par défaut, avec les nouvelles, pour que la sortie de la nouvelle soit réellement indolore pour l'ancienne, tant qu'elle a des utilisateurs.
Ensuite il y a les cas plus complexes où une application a besoin des 2 versions simultanément, non pas parce que ses développeurs sont tordus, mais typiquement parce que parmi les autres bibliothèques qu'elle utilise, certaines sont déjà passées à LibFoo2 et d'autres pas encore. Un exemple de ça est ce que j'ai mentionné dans le journal: les plugins utilisant GTK2 et ne pouvant pas se déplacer dans un processus séparé (Java). De nombreux autres exemples, je suppose, sont à trouver dans les applications de bureau libre où la tradition est de lier dynamiquement à un grand nombre de bibliothèques externes. Dans tous ces cas, en cas de cassure de la compatibilité binaire, en plus de distribuer les anciennes versions, il faut que les différentes versions soient utilisables simultanément.
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 0.
Les extensions Firefox, ça n'est pas une partie intégrante du Web (puisque ça ne marche que dans Firefox).
Et d'autre part, la surface exposée par Gecko aux extensions (par XPCOM) est si énorme que c'est inévitable. Si tu veux des addons avec compatibilité à plus long terme comme dans certains autres navigateurs, la contrepartie inévitable est des add-ons moins puissants, comme dans ces autres navigateurs. Du point de vue du dév d'extensions, ça se discute, par contre, du point de vue de l'utilisateurs, après une période difficile l'année dernière, actuellement le nombre d'add-ons sur addons.mozilla.org qui ne sont pas à jour lors de la sortie d'un nouveau Firefox stable est si faible (bien en dessous de 1%) que le problème n'est plus visible.
Des add-ons puissants qui accèdent directement au cœur du navigateur, ça cadre bien dans la mission Mozilla: permettre aux gens de bidouiller avec le Web, et de prendre le contrôle de leur Web plutôt que de se le faire imposer. Exemples: AdBlock+, Collusion, etc. Ça vaut bien le compromis sur la compatibilité.
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à -1.
Oh, j'ai lu ce bug maintenant. Apparemment il s'agit d'une propriété CSS qui a été dé-préfixée. Ceci veut dire que les pages qui ont été cassées étaient des pages programmées pour ne fonctionner que dans une liste finie de navigateurs. Ça, c'est le mal. En gardant la compatibilité avec elles (en conservant ce préfixe -moz ) on ferait le mal, en permettant à des pages Web qui ne marchent que dans Firefox de continuer de proliférer. Il est très important que tous les fabricants de navigateurs adoptent cette attitude stricte face aux préfixes CSS propriétaires, sinon on est repartis pour un scénario à la IE6 avec un Web codé pour le moteur Web dominant du moment.
Ce que cet exemple montre est une différence très importante entre le Web et les autres plate-formes: le Web est multi-implémentation, on y décourage les applications qui ne fonctionnent que sur une implémentation.
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à -2.
J'ai (bien entendu) exagéré un peu avec le 100.00%. Disons 99.99% si tu préfères. Il y a toujours des cas où une API doit cesser d'être supportée, par exemple si elle a vraiment trop peu d'utilisateurs pour justifier son coût de maintenance, ou bien si elle est de façon inhérente une faille de sécurité. Mais on ne peut pas comparer ça avec les changements de version majeure de toolkits: quand on entend que "Qt5 est 99% compatible avec Qt4" alors que question compatibilité des binaires existants, ça serait plutôt 0% --- les développeurs de toolkit parlent de compatibilité source alors que les utilisateurs ont besoin de compatibilité binaire pour leurs applications --- je veux dire clairement que le souci de compatibilité du Web en général, et de Firefox en particulier, est plusieurs ordres de grandeur au-dessus de ce que les toolkits offrent. Un site de 1998 a de grandes chances de s'afficher encore correctement dans le Firefox d'aujourd'hui, alors qu'une application de bureau libre de 1998 n'a aucune chance de ne serait-ce que démarrer aujourd'hui.
[^] # Re: metro
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 2.
Le comportement de Microsoft sur Metro me fait penser, et je ne suis pas le seul, que Microsoft a vraiment oublié les raisons de ses succès commerciaux et qu'ils vont se planter cette fois-ci.
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 1.
Parce que dans le monde réel, les gens ne considèrent pas acceptable que leurs applications binaires cessent de fonctionner quand ils mettent à jour leur système d'exploitation.
Il ne le faut que dans la mesure où les bureaux à base de GTK et Qt ambitionnent d'obtenir plus de 1% de parts de marché. On se souvient de GNOME qui ambitionnait 10% pour 2010.
Là on commence à tout mélanger: avant on parlait de Gecko comme bibliothèque binaire, maintenant tu parles de XUL. Si tu veux parler de ça il va te falloir un autre interlocuteur que moi, car je ne travaille personnellement que sur Gecko.
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 1. Dernière modification le 12 octobre 2012 à 22:36.
Gecko ne prétend pas être un toolkit, ni même en aucune façon utilisable comme une bibliothèque externe. On ne prétend pas ça. On ne peut pas empêcher des gens de le faire, mais ça n'est vraiment pas encouragé. Il y a très longtemps, on l'encourageait, mais cette époque est révolue depuis longtemps. Et je ne connais aucun project qui le fasse aujourd'hui.
A partir de là, il n'y a aucune validité à retourner contre Gecko les critiques que je formule contre des toolkits.
C'est comme si je disais "Peugeot n'investit pas assez dans les voitures hybrides" et que tu me répondais "Mozilla non plus".
[^] # Re: Une solution ?
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 4.
La contradiction peut se résoudre en admettant qu'il est impossible de maintenir un navigateur Web compétitif sans une équipe d'au moins, disons, 50 personnes (et c'est très optimiste) même en ayant une assez grande partie du travail fourni par WebKit.
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à -1.
Je parlais d'utiliser Qt3 et Qt4 en même temps dans la même application, ce qui suppose en particulier le placement de toute partie incompatible dans un espace de noms séparé.
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 3.
Les applications utilisant Gecko distribuent leur propre copie de Gecko (par exemple, Firefox et Thunderbird ont leur propre copie) donc c'est un non-problème. On peut bien sûr pointer des inconvénients de cette approche (utilisation de quelques dizaines de MB de mémoire de plus) mais ces arguments ont à leur tour des contre-arguments (permettre à Thunderbird de distribuer un plus petit Gecko que Firefox, par exemple sans support de WebGL sous Windows qui est assez volumineux, etc).
[^] # Re: Tu critiques Qt ?
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à -1. Dernière modification le 12 octobre 2012 à 19:02.
On est bien d'accord sur les faits, mais on en tire des conclusions entièrement différentes.
Le meilleur exemple en est quand tu dis:
Donc voilà, du point de vue des développeurs de toolkits, pour sortir une nouvelle version du toolkit sans causer trop de problèmes, il suffit d'être "quasiment source compatible".
C'est là que je ne suis pas du tout d'accord: pour moi, la barre en termes de compatibilité est bien plus haut. Il faut aussi préserver à 100.00% la compatibilité binaire descendante: les binaires compilés pour Qt4 doivent continuer de s'exécuter sans aucune modification sous Qt 5, Qt 6, et ainsi de suite jusqu'à ce que vraiment presque plus personne n'ait de binaires Qt4 à faire tourner. Et, chose très importante, il doit rester possible d'utiliser les différentes versions simultanément, dans la même application.
Il y a différentes façon d'atteindre cet objectif. La façon Microsoft, qui est la première direction où regarder puisque c'est ce qu'il y a de plus proche techniquement et qu'ils ont un certain succès commercial, c'est simplement de continuer de distribuer des binaires des anciennes versions de leurs SDK, et de concevoir leurs interfaces pour permettre d'utiliser de multiples versions simultanément. C'est comme si les distributions binaires de Qt5 contenaient une copie des binaires de Qt4.
Android et Apple aussi continuent de distribuer leurs vieux SDK binaires avec les nouveaux.
Idem pour les distributions binaires d'implémentations d'OpenGL, qui sont les championnes de la compatibilité descendante, une application OpenGL 1.0 d'il y a presque vingt ans pouvant encore tourner sans recompilation sur n'importe quelle machine ayant des pilotes OpenGL.
Si les toolkits libres veulent être pris au sérieux, il faut qu'ils fassent la même chose. Dans mon journal, j'ai donné un exemple concret montrant en quoi le fait que GTK3 ne fait pas ça, est une grande cause de problèmes pour Firefox.
Du coup, le coût réel d'accroître un toolkit pour y include des choses come QVector et QList, est plus important dans ma vision des choses que dans la tienne, car ce gonflement va être multiplié par un certain facteur pour garantir la compatibilité au fil des années.
Je ne rentre pas plus dans le détail de ta réponse parce que je pense que le point important de désaccord était celui-ci.
[^] # Re: Une solution ?
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 4.
Il y a deux catégories de navigateurs "WebKit".
La catégorie des navigateurs WebKits qui prennent au sérieux cette histoire de bibliothèques bien séparées; cette catégorie comprend uniquement des "petits" navigateurs comme Epiphany que presque personne n'utilise, qui ont généralement de 1 à 3 ans de retard sur les fonctonnalités Web des principaux navigateurs, et qui n'offrent pas beaucoup des fonctionnalités d'un navigateur moderne qui ne sont pas fournies par ces bibliothèques (par exemple Sync).
Et puis les navigateurs qui se moquent comme d'une guigne de cette histoire de bibliothèques séparées, qui ont leur propre variante de WebKit, qui le développent conjointement à leur propre moteur JS, et leur propre code applicatif. Cette catégorie inclut tous les navigateurs WebKit qui ont jamais rencontré le succès, en particulier Chrome et Safari.
Bref, l'histoire des jolies bibliothèques bien propres et séparées, c'est une énorme arnaque et ceux qui y croient le font à leurs dépens. En fait, c'est exactement la même histoire qu'avec les toolkits.
[^] # Re: Une solution ?
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 4.
Epiphany est un navigateur a minima au-dessus de WebKit, donc l'effort de portage est incomparablement plus faible que pour Firefox. Il y a aussi des facteurs architecturaux, mais ça n'est pas une raison de critiquer les choix architecturaux de Firefox, au vu des bénéfices qu'il en tire par ailleurs (Firefox étant plus multi-plateformes et faisant de l'intégration dans des plate-formes non-GTK, et offrant à ses add-ons des capacités d'intégration impossibles à offrir avec WebKit).
# 2ème -> 3ème
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 1.
Zut, mon titre est faux, c'est la 3ème partie. Apparemment on ne peut pas éditer un journal déjà publié.
# repos éternel
Posté par Benoit Jacob (site web personnel) . En réponse à la dépêche Eugeni Dodonov nous a quitté. Évalué à -3.
Il fait dodo now.
-----> []
[^] # Re: Pourquoi réécrire ?
Posté par Benoit Jacob (site web personnel) . En réponse au journal Conseils aux libristes, 2ème partie: résister à la tentation de la réécriture à partir de zéro. Évalué à 5.
En fait, que ça soit le cas ou pas ne fait pas une grande différence. Être la même personne n'offre pas une bien grande garantie contre les régressions. La seule garantie contre les régressions est d'avoir une batterie de test unitaires vraiment très exhaustive (KDE n'a que quelques maigres parties couvertes par des tests unitaires) et d'avoir une règle très stricte de rejet de toute modification qui régresserait un test unitaire sur une machine de test (KDE n'a pas à ma connaissance de machine de tests ni de règle de rejet de patchs causant des régressions, en tout cas n'en avait pas à l'époque de la réécriture).