il s'est mal exprimé. Ce n'est pas un problème de gagner trop d'argent, mais le fait pour une fondation d'avoir des contrats commerciaux. Quand ceux-ci deviennent trop important, ça devient compliqué vis à vis du fisc. Enfin bon, je suis loin d'être expert en fiscalité américaine, mais ce que j'en ai compris.
D'où la création de la corp. C'est elle qui gère les contrats commerciaux et qui gèrent les équipes de dev/marketing etc.
De l'argent, Mozilla n'en aura jamais assez. Ce qu'elle gagne, c'est pinuts par rapport à ce que dépense Microsoft ou Google en terme de développement et de marketing pour leurs navigateurs.
pour pouvoir exécuter le code en local, je ne sais pas ce que prévois HTML5
euh.. du code javascript ? Qu'embarque toute page web moderne ? Une fois chargé dans une page, le code javascript s'exécute à loisir. Le navigateur ne va pas tout arrêter parce qu'il n'y a plus de connexion...
je ne sais pas ce que prévois HTML5
plein de choses. mais bon, je n'ai plus le temps de te lister tout ça. cf le lien au dessus.
Google devrait se fader la création d'une interface en HTML5 ou XUL inclus dans l'extension pour Firefox
Pourquoi XUL ?? On parle de HTML là non ? Ce qu'a implémenté Mozilla, c'est en HTML. Si Google respecte ce que dit les specs concernant le offline, il ne devrait pas y avoir de problème.
Si Mozilla/Firefox n'est plus capable de s'adapter et d'innover,
La discussion ne porte pas sur la capacité d'innovation de Mozilla. Mozilla n'a pas attendu Chrome pour proposer un autre système d'extension, Jetpack, dont s'est largement inspiré Google pour son Chrome. (même si jetpack était sorti dans une version stable de firefox après la release de Google contenant son système d'extension, la faute à l'ancien cycle de release de Firefox, trop long)
je ne vois donc pas ce que ta question "en quoi est-ce le problème des autres navigateurs?" vient faire dans la discussion. Il n'y a pas de problème chez Mozilla.
la question de départ de la discussion était "pourquoi personne n'a râlé quand Mozilla a sorti son système d'extension qui n'était compatible avec aucun autre navigateur". J'ai expliqué les raisons, point barre. ça ne veut pas dire que Mozilla n'a rien fait pour améliorer les choses, bien au contraire.
je constate qu'une partie de l'argent du business modèle de Google finance et participe au succès de Firefox
Non, Google ne finance pas (à te lire, on dirait qu'ils font des donations à Mozilla). Google paye pour le trafic que lui apporte Firefox. Nuance. Mozilla n'a pas attendu l'argent de Google pour avoir du succès. C'est parce que Mozilla a eu du succès que Google a cet accord avec Mozilla. Rappel de leur accord : apport de trafic contre argent. Et Google, pour le moment, a tout intérêt à maintenir cet accord, car 25% des internautes, ça rapporte beaucoup d'argent au niveau de leurs pubs. Alors certes, cet argent gagné (et non pas reçu, nuance) par Mozilla, a permis d'améliorer encore plus le navigateur etc, et ça a fait boule de neige.
Tant que Google respecte les standards établis (comme la MoCo, tiens) et qui en plus donne accès à la quasi totalité du code de Chrome, ne devrait-on pas considérer que le problème (s'il y a) est du côté des concurrents incapables de s'adapter ou d'innover?
Euh.. non. Les concurrents ne contrôlent pas les applis de Google (qui tendent à enfermer l'utilisateur, même si tes oeillères t'empêchent de le voir). Donc ne peuvent imposer aux développeurs de chez google à utiliser les apis équivalentes qui existent dans les autres navigateurs. En effet, il y a une règle utilisée par tous les fabricants de navigateur (et même par MS depuis quelques temps). Toutes les APIs qui ne sont pas standardisées doivent être préfixées. Donc tout les trucs non standards de chrome commencent par "webkit" (ou -webkit- pour les css).
Mozilla et les autres ne vont pas implémenter tout les trucs en les nommant -webkit- pour faire plaisir à google, pour deux raisons : généralement, ce sont des fonctionnalités sous-spécifiées puisque toutes fraiches, ou alors dont les specs sont instables, en brouillons, donc pas évident de reproduire la fonctionnalité. Deuxièmement, cela n'aurait au final aucun intérêt, et ça revient au même qu'à la première guerre des navigateurs, et une horreur pour les développeurs : la même fonctionnalité, bien qu'ayant le même nom, ne fonctionnerait pas pareil d'un navigateur à un autre (les pauvres développeurs web ont déjà assez de problèmes avec les bugs des implémentations des fonctionnalités spécifiées stables).
Bref, pour les concurrents, ce n'est pas logique d'utiliser les mêmes noms que les APIs.
Au final, les developpeurs des applis google peuvent ne pas faire l'effort (et apparemment c'est le cas pour certaines applis), de rendre compatible leur appli avec les autres navigateurs (donc utiliser les API similaires en -moz- ou autre). Et ça tombe très bien de pas faire l'effort, ça force les gens à utiliser Chrome pour avoir une "meilleure expérience utilisateur".
faudra arrêter un peu avec ce délire anti-capitaliste
Faut arrêter de voir des délires anti-capitalistes partout. Mes propos sont là pour montrer la grande différence entre les buts de Google et ceux de Mozilla. Et que non, les trucs "proprio" de Mozilla ne sont pas là pour enfermer les utilisateurs (puisqu'elles ne proposent pas de services gratuit ou payant). Alors que ceux de google peuvent très bien se servir de leurs trucs "proprio" (=non encore standardisé) pour enfermer l'utilisateur.
à la différence de Google, Mozilla ne propose pas de services web (mail ou autre), il propose juste un navigateur. Mozilla n'a donc pas la possibilité "d'emprisonner" ses utilisateurs.
aujourd'hui ça l'est sous Chrome mais plus sous Firefox.
à moins d'avoir raté quelque chose, il y a toujours dans Firefox les API pour qu'une appli web puisse fonctionner en offline. ça fait parti de HTML5. à moins que tu parles de choses totalement propriétaire à Google..
mais si l'historique de Mozilla est si "lourd", en quoi c'est le problème des autres navigateurs?
Tu ne sembles pas avoir compris ce que j'ai voulu dire. Je reprend donc.
Google, à l'époque où il a demarré son Chrome, pouvait envisager d'utiliser HTML/JS pour ses extensions, car HTML avait déjà pas mal évolué, y compris dans webkit. Ce n'était pas le cas quand Firefox a démarré. C'est pour cela que personne n'a râlé sur le fait que Firefox utilisait des technos non web pour ses extensions (quoique, faire du XUL, c'est faire du XML(XUL), du CSS et du JS, le tout empacté dans un zip).
C'est vrai, Mozilla vie d'amour et d'eau fraîche. Et des $$$ de Google, accessoirement.
Ce que je voulais dire, c'est que le but de Mozilla, n'est pas de faire de l'argent (l'argent n'est qu'un moyen). elle n'a pas d'actionnaire, c'est une fondation, "non-profit".
Contrairement à Google, qui a pour but, elle, de gagner un maximum d'argent pour ses actionnaires. Et donc pour Google, ce qu'il faut, c'est de maintenir captif ses clients sur ses propres services et applis, et pour cela, leur navigateur est un excellent moyen. Puisqu'il suffit de fournir à leurs utilisateurs clients une expérience utilisateur plus agréables via Chrome quand ils utilisent leurs services.
Mozilla a pour but, bien au contraire, de faire en sorte que les internautes aient le choix, ne soient pas prisonnier dans un "silot". Bref, la mission de Mozilla est d'éviter que le web se transforme en Minitel 2.0. Et le moyen qu'elle utilise : promotion des standards du web, fourniture de logiciels qui respectent au mieux ces standards, faire standardiser au maximum les nouvelles technologies dont ont besoin les développeurs etc.
L'auteur reproche aux « App » de n'être que des sites web spécifiques à Chrome, mais ces sites sont le système d'extension de Google
Oui et non. Il faut distinguer app et extension. Les apps ne sont pas des extensions, mais des sites webs. Et par définition, les sites webs devraient être accessibles à tout navigateurs, puisqu'ils sont censés respecter les standards du web.
Or le problème, c'est que ces applis sont "optimisées" pour Chrome. Et il n'y a pas que les apps de leur appstore, mais aussi des services google. Tu n'as pas chrome ? tu n'as le droit qu'à un site dégradé.
C'est franchement dommage, d'autant plus que pour pas mal de chose, comme par exemple en CSS, il suffit de dupliquer certaines propriétés en remplaçant le préfixe.
personne n'a jamais reproché à Firefox d'avoir des extensions spécifiques qui ne sont pas utilisables sur Opera par exemple
Non, mais tu compares des choux et des carottes.
Le système d'extension de Firefox a plus de dix ans (il y était déjà dans les premières releases alpha de la suite Mozilla, même si il n'y avait pas la boite de dialogue pour les gérer).
Et une extension Firefox n'est pas un simple bout de code HTML/JS, pour la simple et bonne raison que ce qu'on pouvait faire avec HTML (la version 4 en l'occurrence), était plus que limité à l'époque. Donc il fallait que Mozilla fournisse un autre moyen d'étendre son navigateur. Et même aujourd'hui, ce qu'on pourrait faire avec une extension HTML/JS, reste limité par rapport à ce qu'on peut faire avec du XUL (puisque dans une extension Firefox, on a accès à une tonne d'API interne, on peut faire des composants binaires; aucune limite quoi).
Bref, tu oublies qu'il y a un historique, et ce n'est qu'aujourd'hui que l'on peut commencer à envisager de faire des choses puissantes avec les technologies HTML5.
Donc si personne n'a râlé contre Mozilla pour son système d'extension, c'est qu'il n'existait pas d'autres choix technologiques. Des trucs en HTML/JS n'étaient pas envisageables.
Depuis quelques années, il y a une volonté de la part de beaucoup d'acteurs, de pousser HTML pour faire des applis, et donc de le faire évoluer, parce que cela a une caractéristique intéressante : il suffit d'un browser pour l'exécuter, et donc tout le monde peut y accéder.
Google semble cependant dériver, à faire (ou à encourager à faire) de plus en plus de services et d'appli qui soient "optimisés pour Chrome". Si ça continue, avec la part de marché croissante, on va se retrouver comme en 2001 : un navigateur dominant, et des sites "optimisées" pour Chrome. Comme IE6.
"don't be evil", mais bon, leur stratégie semble être celle du loup dans la bergerie, "on suit les standards mais presque". Et si les autres ne suivent pas, tant pis pour eux, "et tant mieux pour nous, on va pouvoir canaliser les utilisateurs vers nos services, et donc gagner encore plus de millions".
Google n'est pas une entreprise philanthrope, faut se le rappeler.
oui, quand quelque chose est cassé, y a plusieurs fragments. logique. Mais ça ne fonctionne plus.
Or l'API ici fonctionne à priori, même si elle est séparée (split) en plusieurs éléments.
Quand une API (ou du code..) est "broken", en général, cela veut dire qu'elle est cassé. Elle ne fonctionne plus. Fais une recherche sur google avec "api broken", tu verras que ça ne parle que d'API qui ne fonctionnent plus.
Je ne pense pas qu'il faille dire "broken". Car broken, ça veux plutôt dire "cassé" au sens, "ça ne fonctionne plus". Je pense qu'il faudrait plutôt dire "API is split into..."
Oui mais non. Mercurial permet d'identifier un commit par deux choses : un hash effectivement, et son ordre sur le dépôt local (qui peut bien sûr ne pas être le même sur un clone). Sur une machine de build/release, qui a donc forcément un clone, elle pourrait très bien se basée sur ce numéro d'ordre.
hg tip --template "{rev}"
C'est ce que je fais pour faire les releases de snapshot du trunk de mes projets..
Tu n'as pas dis sur quelle plateforme tu as fait ces tests. Si c'est sur windows avec Direct2D, ton résultat avec canvas n'est pas normal, puisqu'une nouvelle lib graphique, Azure, a été inclus dans Firefox 7 pour ça.
Pour tout le reste (canvas sous linux/mac, et SVG partout), Firefox utilise Cairo comme lib graphique. Et Cairo ça sux un peu niveau performance. Depuis plusieurs mois donc, ils sont sur le développement de cette nouvelle lib Azure, mais pour le moment donc, seul le backend windows Direct2D est dispo.
Tu aimes le projet Mozilla ? Tu aimerais que ça bouge autrement ? Fais-toi plaisir, va contribuer.
Mozilla accueille des contributeurs à tout les niveaux : marketing, release, IT, localisation, ingénierie, dev des sites web etc... Y a de quoi faire, quel que soit ton profil et ton créneau. Va donc essayer de participer comme ça chez Chrome par exemple (ah ah !). Y a pas que le code dans un projet.
Si Mozilla a fait une erreur au niveau de leur Fast Release Cycle, c'est parce qu'il y a eu un manque d'études de toutes les conséquences, c'est sûr, mais c'est probablement aussi qu'il n'y avait pas assez de personnes pour leur dire avant, "hey, ho, attention, il va y avoir tel ou tel problème si vous prenez telle décision, voici ce que je propose". Parce que Mozilla ne peut pas être partout, dans toutes les entreprises, chez tous les particuliers, pour leur demander ce qu'ils utilisent et comment.
Il y a toujours des gens pour dire YavaitKa après la bataille, mais avant la bataille, chacun est dans son coin et attend.
Si les entreprises, qui pour beaucoup ont gueulé et je les comprends, avaient été plus à l'écoute de ce qui se passait chez Mozilla (même si c'est pas évident aussi je le reconnais), et qu'ils faisaient un peu plus de feedback, peut être que chez Mozilla ils auraient pris un peu plus conscience du problème. Mozilla ne peut pas non plus deviner tout ce qui se passe partout avec leurs produits, surtout en entreprise.
Rappel, Mozilla, ce n'est pas Microsoft ou Google. Ils n'ont pas une armée de commerciaux et de marketeux à "l'écoute" de leur "client" prospectant chez leurs clients.
La seule force de Mozilla, c'est vous, utilisateurs. Alors n'hésitez pas à aller contribuer, ne serait-ce qu'en allant participer aux discussions qui vous intéressent dans les newsgroup Mozilla.
Si vous êtes 50 à vous plaindre dans une discussion sur un futur projet, ça passera moins inaperçu que si il n'y a qu'un seul pauvre gars qui tente de se faire entendre au milieu de toutes ces discussions.
Tu te plains du manque de communication ? Bien. Alors, tu as le choix. Soit tu fais dons de quelques millions afin que Mozilla mettent des affiches 4x3 dans toutes les grandes villes comme Google a fait pour Chrome (on ne le voit pas trop en France, mais le budget marketing de Chrome est hallucinant aux US). Soit tu commences par ajouter dans ton agrégateur http://planet.mozilla.org , et tu seras alors au courant de beaucoup de chose. Et tu pourras alors réagir si tu vois qu'il y a un truc en préparation qui ne te semble pas judicieux.
Cette course à la numérotation m'embête au plus haut point, elle est inutile et néfaste pour les utilisateurs qui ne savent plus où ils en sont.
s/utilisateurs/geek
Les utilisateurs s'en fichent du numéro de version. Et ça ne gênent vraiment que les geeks : la preuve est dans les stats. Il n'y a pas eu de désertion massive depuis la 4.
Pour les entreprises, ça ne les gêne pas non plus. Ce qui les gêne, c'est qu'il n'y ait pas de LTS (appelée ESR chez Mozilla). Mais ça va être résolut d'ici la fin de l'année, avec des ESR de plus d'un an (54 semaines) avec une ESR par an. Firefox 10 ou 11 sera la prochaine ESR.
Notez également qu'au début 2012, les mises à jours seront silencieuses par défaut. L'utilisateur sera encore moins "ennuyé" par les numéros de version (si tant est qu'il l'était). Et je parie qu'il n'y aura pas plus de défection que ça. D'ailleurs l'augmentation fulgurante du nombre d'utilisateurs de chrome prouve bien que ces utilisateurs en ont rien à foutre du numéro de version et des mises à jour.
c'est plus facile de savoir où on en est par rapport aux versions majeures,
Justement, ce que tu n'as pas compris, c'est qu'il n'y a plus la notion de version majeure ou mineure.
les utilisateurs (et les développeurs web) n'ont pas à attendre 1 an ou 2 pour profiter des nouvelles améliorations.
au lieu de sortir des versions sans saveurs.
au niveau interface, c'était cosmétique jusqu'ici, mais tu auras des versions avec plus de changements visuels. Et tu les auras dés que leur développement sera terminé, tu n'auras pas à attendre 1 an ou 2 qu'une version "majeure" sorte. (Par ex, les nouveaux outils développeurs dans Fx 10).
On est vendredi, c'est la journée des Trolls. Par contre, on n'a jamais dit que c'était la journée du FUD.
Journal raté donc.
Tout ceux qui suivent d'assez près le projet Mozilla savent que tout le contenu de ce journal est rempli d'informations fausses et de raccourcis à la con aboutissant à des conclusions débiles.
alors qu'il y a quelques années mozilla disait que XUL était l'avenir
Ils n'ont jamais vraiment dit ça. Par contre, c'est peut être de ma faute si tu le penses, puisque c'est plus ou moins ce que je disais à l'époque sur xulfr.org et ailleurs, croyant au développement de XulRunner &co. Et puis patatra, un jour Mozilla annonça que XulRunner ne sera jamais un "produit" (ils l'ont fait parce que je pense qu'ils se rendaient compte que XulRunner prenait trop d'ampleur, et que ça allait gêner le développement de Firefox dans le futur).
Et comme toi je fus extrêmement déçu... XulRunner et XUL restera un truc de geek, pas une technologie utilisée massivement en dehors de Firefox et TB.
Si au contraire. Le terme Webapp est peut être utilisé à tord, mais dans le cas de B2G, ça ne veut pas dire hebergé sur un serveur. Une webapp au sens B2G, est une appli qui utilise les technos web, mais qui est packagée pour être installé sur le téléphone. Heureusement encore, parce que si il fallait obligatoirement une connectivité pour faire fonctionner la moindre appli :-)
Euh si.. Tout est en XUL dans seamonkey. Depuis 99, tous les produits Mozilla (ou dérivé) sont en XUL. (Mozilla suite, Firefox, Thunderbird, Sunbird...).
Kompozer est le descendant de Nvu, qui est un descendant de l'éditeur Composer, qui était fourni dans la suite mozilla. Donc eux aussi en XUL.
comme moins-value que, bah, le code est pas natif.
à l'heure actuel, les applis dans android sont en java. Donc déjà pas en code natif. y a probablement du JIT, mais bon, les applis web aussi c'est pareil, y a du JIT au niveau javascript (la lourdeur java en moins).
Bref, je ne vois pas de moins value là dedans.
La moins value que je vois (c'est mon opinion), c'est que developper une webapp va être probablement plus long, car on n'a pas forcément tous les widgets d'interface prêt à l'emploi que l'on dispose dans le toolkit d'android par exemple (bon, j'y connais pas grand chose à android non plus). à moins que Mozilla passe la seconde sur un remplaçant standardisé de XBL (permettant de développer des composants réutilisables).
De ce que j'ai compris : ils partent d'android pour ne pas avoir à démarrer from scratch et pouvoir aussi utiliser au minimum le téléphone pour tester les nouvelles api. Et petit à petit ils vont remplacer les applis natives par des webapp.
à priori, au final, il ne restera d'android pas grand chose, si ce n'est le noyau linux et ce qui va autour au niveau système. Si j'ai bien compris. :-)
[^] # Re: pas seulement
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Framablog : Google Chrome deviendra-t-il un nouveau IE6 ?. Évalué à 2.
c'est déjà arrivé hein, en particulier les projets qu'elle utilise ... (pour openSSH par ex..)
[^] # Re: pas seulement
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Framablog : Google Chrome deviendra-t-il un nouveau IE6 ?. Évalué à 3.
il s'est mal exprimé. Ce n'est pas un problème de gagner trop d'argent, mais le fait pour une fondation d'avoir des contrats commerciaux. Quand ceux-ci deviennent trop important, ça devient compliqué vis à vis du fisc. Enfin bon, je suis loin d'être expert en fiscalité américaine, mais ce que j'en ai compris.
D'où la création de la corp. C'est elle qui gère les contrats commerciaux et qui gèrent les équipes de dev/marketing etc.
De l'argent, Mozilla n'en aura jamais assez. Ce qu'elle gagne, c'est pinuts par rapport à ce que dépense Microsoft ou Google en terme de développement et de marketing pour leurs navigateurs.
[^] # Re: pas seulement
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Framablog : Google Chrome deviendra-t-il un nouveau IE6 ?. Évalué à 2.
gni ?? Ce qu'a implémenté Mozilla dès le début (et depuis longtemps), c'est spécifié dans HTML5 et autres webapi https://developer.mozilla.org/en/Apps/Using_apps_offline
euh.. du code javascript ? Qu'embarque toute page web moderne ? Une fois chargé dans une page, le code javascript s'exécute à loisir. Le navigateur ne va pas tout arrêter parce qu'il n'y a plus de connexion...
plein de choses. mais bon, je n'ai plus le temps de te lister tout ça. cf le lien au dessus.
Pourquoi XUL ?? On parle de HTML là non ? Ce qu'a implémenté Mozilla, c'est en HTML. Si Google respecte ce que dit les specs concernant le offline, il ne devrait pas y avoir de problème.
[^] # Re: pas seulement
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Framablog : Google Chrome deviendra-t-il un nouveau IE6 ?. Évalué à 0.
La discussion ne porte pas sur la capacité d'innovation de Mozilla. Mozilla n'a pas attendu Chrome pour proposer un autre système d'extension, Jetpack, dont s'est largement inspiré Google pour son Chrome. (même si jetpack était sorti dans une version stable de firefox après la release de Google contenant son système d'extension, la faute à l'ancien cycle de release de Firefox, trop long)
je ne vois donc pas ce que ta question "en quoi est-ce le problème des autres navigateurs?" vient faire dans la discussion. Il n'y a pas de problème chez Mozilla.
la question de départ de la discussion était "pourquoi personne n'a râlé quand Mozilla a sorti son système d'extension qui n'était compatible avec aucun autre navigateur". J'ai expliqué les raisons, point barre. ça ne veut pas dire que Mozilla n'a rien fait pour améliorer les choses, bien au contraire.
Non, Google ne finance pas (à te lire, on dirait qu'ils font des donations à Mozilla). Google paye pour le trafic que lui apporte Firefox. Nuance. Mozilla n'a pas attendu l'argent de Google pour avoir du succès. C'est parce que Mozilla a eu du succès que Google a cet accord avec Mozilla. Rappel de leur accord : apport de trafic contre argent. Et Google, pour le moment, a tout intérêt à maintenir cet accord, car 25% des internautes, ça rapporte beaucoup d'argent au niveau de leurs pubs. Alors certes, cet argent gagné (et non pas reçu, nuance) par Mozilla, a permis d'améliorer encore plus le navigateur etc, et ça a fait boule de neige.
Euh.. non. Les concurrents ne contrôlent pas les applis de Google (qui tendent à enfermer l'utilisateur, même si tes oeillères t'empêchent de le voir). Donc ne peuvent imposer aux développeurs de chez google à utiliser les apis équivalentes qui existent dans les autres navigateurs. En effet, il y a une règle utilisée par tous les fabricants de navigateur (et même par MS depuis quelques temps). Toutes les APIs qui ne sont pas standardisées doivent être préfixées. Donc tout les trucs non standards de chrome commencent par "webkit" (ou -webkit- pour les css).
Mozilla et les autres ne vont pas implémenter tout les trucs en les nommant -webkit- pour faire plaisir à google, pour deux raisons : généralement, ce sont des fonctionnalités sous-spécifiées puisque toutes fraiches, ou alors dont les specs sont instables, en brouillons, donc pas évident de reproduire la fonctionnalité. Deuxièmement, cela n'aurait au final aucun intérêt, et ça revient au même qu'à la première guerre des navigateurs, et une horreur pour les développeurs : la même fonctionnalité, bien qu'ayant le même nom, ne fonctionnerait pas pareil d'un navigateur à un autre (les pauvres développeurs web ont déjà assez de problèmes avec les bugs des implémentations des fonctionnalités spécifiées stables).
Bref, pour les concurrents, ce n'est pas logique d'utiliser les mêmes noms que les APIs.
Au final, les developpeurs des applis google peuvent ne pas faire l'effort (et apparemment c'est le cas pour certaines applis), de rendre compatible leur appli avec les autres navigateurs (donc utiliser les API similaires en -moz- ou autre). Et ça tombe très bien de pas faire l'effort, ça force les gens à utiliser Chrome pour avoir une "meilleure expérience utilisateur".
Faut arrêter de voir des délires anti-capitalistes partout. Mes propos sont là pour montrer la grande différence entre les buts de Google et ceux de Mozilla. Et que non, les trucs "proprio" de Mozilla ne sont pas là pour enfermer les utilisateurs (puisqu'elles ne proposent pas de services gratuit ou payant). Alors que ceux de google peuvent très bien se servir de leurs trucs "proprio" (=non encore standardisé) pour enfermer l'utilisateur.
[^] # Re: pas seulement
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Framablog : Google Chrome deviendra-t-il un nouveau IE6 ?. Évalué à 2.
à la différence de Google, Mozilla ne propose pas de services web (mail ou autre), il propose juste un navigateur. Mozilla n'a donc pas la possibilité "d'emprisonner" ses utilisateurs.
à moins d'avoir raté quelque chose, il y a toujours dans Firefox les API pour qu'une appli web puisse fonctionner en offline. ça fait parti de HTML5. à moins que tu parles de choses totalement propriétaire à Google..
[^] # Re: pas seulement
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Framablog : Google Chrome deviendra-t-il un nouveau IE6 ?. Évalué à -5.
il y a des exemples dans l'article. Et ce n'est pas exhaustif.
[^] # Re: pas seulement
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Framablog : Google Chrome deviendra-t-il un nouveau IE6 ?. Évalué à 6.
Tu ne sembles pas avoir compris ce que j'ai voulu dire. Je reprend donc.
Google, à l'époque où il a demarré son Chrome, pouvait envisager d'utiliser HTML/JS pour ses extensions, car HTML avait déjà pas mal évolué, y compris dans webkit. Ce n'était pas le cas quand Firefox a démarré. C'est pour cela que personne n'a râlé sur le fait que Firefox utilisait des technos non web pour ses extensions (quoique, faire du XUL, c'est faire du XML(XUL), du CSS et du JS, le tout empacté dans un zip).
Ce que je voulais dire, c'est que le but de Mozilla, n'est pas de faire de l'argent (l'argent n'est qu'un moyen). elle n'a pas d'actionnaire, c'est une fondation, "non-profit".
Contrairement à Google, qui a pour but, elle, de gagner un maximum d'argent pour ses actionnaires. Et donc pour Google, ce qu'il faut, c'est de maintenir captif ses clients sur ses propres services et applis, et pour cela, leur navigateur est un excellent moyen. Puisqu'il suffit de fournir à leurs
utilisateursclients une expérience utilisateur plus agréables via Chrome quand ils utilisent leurs services.Mozilla a pour but, bien au contraire, de faire en sorte que les internautes aient le choix, ne soient pas prisonnier dans un "silot". Bref, la mission de Mozilla est d'éviter que le web se transforme en Minitel 2.0. Et le moyen qu'elle utilise : promotion des standards du web, fourniture de logiciels qui respectent au mieux ces standards, faire standardiser au maximum les nouvelles technologies dont ont besoin les développeurs etc.
Je t'encourage à (re)lire le manifesto de Mozilla : http://www.mozilla.org/about/manifesto.html
[^] # Re: Ca m'inquiète un peu
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Framablog : Google Chrome deviendra-t-il un nouveau IE6 ?. Évalué à 6.
Oui, ils comblent les quelques retards qu'ils ont (ils sont en avancent sur pas mal de trucs, mais ça, tous les trolleurs l'oublient).
Et si vous trouvez que cela ne va pas assez vite, et que vous voulez aider mozilla à garder un web ouvert et gratuit pour tous, faites un don : https://donate.mozilla.org/page/contribute/openwebfund
# pas seulement
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Framablog : Google Chrome deviendra-t-il un nouveau IE6 ?. Évalué à 8.
Oui et non. Il faut distinguer app et extension. Les apps ne sont pas des extensions, mais des sites webs. Et par définition, les sites webs devraient être accessibles à tout navigateurs, puisqu'ils sont censés respecter les standards du web.
Or le problème, c'est que ces applis sont "optimisées" pour Chrome. Et il n'y a pas que les apps de leur appstore, mais aussi des services google. Tu n'as pas chrome ? tu n'as le droit qu'à un site dégradé.
C'est franchement dommage, d'autant plus que pour pas mal de chose, comme par exemple en CSS, il suffit de dupliquer certaines propriétés en remplaçant le préfixe.
Non, mais tu compares des choux et des carottes.
Le système d'extension de Firefox a plus de dix ans (il y était déjà dans les premières releases alpha de la suite Mozilla, même si il n'y avait pas la boite de dialogue pour les gérer).
Et une extension Firefox n'est pas un simple bout de code HTML/JS, pour la simple et bonne raison que ce qu'on pouvait faire avec HTML (la version 4 en l'occurrence), était plus que limité à l'époque. Donc il fallait que Mozilla fournisse un autre moyen d'étendre son navigateur. Et même aujourd'hui, ce qu'on pourrait faire avec une extension HTML/JS, reste limité par rapport à ce qu'on peut faire avec du XUL (puisque dans une extension Firefox, on a accès à une tonne d'API interne, on peut faire des composants binaires; aucune limite quoi).
Bref, tu oublies qu'il y a un historique, et ce n'est qu'aujourd'hui que l'on peut commencer à envisager de faire des choses puissantes avec les technologies HTML5.
Donc si personne n'a râlé contre Mozilla pour son système d'extension, c'est qu'il n'existait pas d'autres choix technologiques. Des trucs en HTML/JS n'étaient pas envisageables.
Depuis quelques années, il y a une volonté de la part de beaucoup d'acteurs, de pousser HTML pour faire des applis, et donc de le faire évoluer, parce que cela a une caractéristique intéressante : il suffit d'un browser pour l'exécuter, et donc tout le monde peut y accéder.
Google semble cependant dériver, à faire (ou à encourager à faire) de plus en plus de services et d'appli qui soient "optimisés pour Chrome". Si ça continue, avec la part de marché croissante, on va se retrouver comme en 2001 : un navigateur dominant, et des sites "optimisées" pour Chrome. Comme IE6.
"don't be evil", mais bon, leur stratégie semble être celle du loup dans la bergerie, "on suit les standards mais presque". Et si les autres ne suivent pas, tant pis pour eux, "et tant mieux pour nous, on va pouvoir canaliser les utilisateurs vers nos services, et donc gagner encore plus de millions".
Google n'est pas une entreprise philanthrope, faut se le rappeler.
Tout le contraire de la mission de Mozilla.
[^] # Re: L'api, elle est cassé
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Seeks en version stable 0.4. Évalué à 3.
oui, quand quelque chose est cassé, y a plusieurs fragments. logique. Mais ça ne fonctionne plus.
Or l'API ici fonctionne à priori, même si elle est séparée (split) en plusieurs éléments.
Quand une API (ou du code..) est "broken", en général, cela veut dire qu'elle est cassé. Elle ne fonctionne plus. Fais une recherche sur google avec "api broken", tu verras que ça ne parle que d'API qui ne fonctionnent plus.
# L'api, elle est cassé
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Seeks en version stable 0.4. Évalué à 5.
Juste un truc sans réèl importance au regard du travail fourni, mais qui m'a gêné.
Sur la page de l'api, http://seeks-project.info/wiki/index.php/API-0.4.0 , il est dit que "API is broken into plugin dependent fragments."
Je ne pense pas qu'il faille dire "broken". Car broken, ça veux plutôt dire "cassé" au sens, "ça ne fonctionne plus". Je pense qu'il faudrait plutôt dire "API is split into..."
my two cents :)
[^] # Re: Navigateur
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Premières impressions sur le Samsung Galaxy Note. Évalué à 2.
j'ai oublié http://fr.wikipedia.org/wiki/Compl%C3%A8tement
[^] # Re: Navigateur
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Premières impressions sur le Samsung Galaxy Note. Évalué à 3.
Eh bien non, les deux termes sont valables. Le vrai mot français étant justement "complètement". Complétion étant le mot dérivé de l'anglais.
http://fr.wikipedia.org/wiki/Compl%C3%A9tion
[^] # Re: Mise à jour
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Mozilla, son cycle de développement de 6 semaines et Eletrolysis. Évalué à 2.
Oui mais non. Mercurial permet d'identifier un commit par deux choses : un hash effectivement, et son ordre sur le dépôt local (qui peut bien sûr ne pas être le même sur un clone). Sur une machine de build/release, qui a donc forcément un clone, elle pourrait très bien se basée sur ce numéro d'ordre.
C'est ce que je fais pour faire les releases de snapshot du trunk de mes projets..
[^] # Re: A part le troll
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Mozilla, son cycle de développement de 6 semaines et Eletrolysis. Évalué à 3.
Tu n'as pas dis sur quelle plateforme tu as fait ces tests. Si c'est sur windows avec Direct2D, ton résultat avec canvas n'est pas normal, puisqu'une nouvelle lib graphique, Azure, a été inclus dans Firefox 7 pour ça.
Pour tout le reste (canvas sous linux/mac, et SVG partout), Firefox utilise Cairo comme lib graphique. Et Cairo ça sux un peu niveau performance. Depuis plusieurs mois donc, ils sont sur le développement de cette nouvelle lib Azure, mais pour le moment donc, seul le backend windows Direct2D est dispo.
les explications du pourquoi du comment :
- http://blog.mozilla.com/joe/2011/04/26/introducing-the-azure-project/
- http://www.basschouten.com/blog1.php/comparing-performance-azure-vs-cairo
Il y a eu aussi déjà pas mal d'explications là dessus sur linuxfr, faire une recherche...
[^] # Re: Troll^W FUD
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Mozilla, son cycle de développement de 6 semaines et Eletrolysis. Évalué à 0.
pourtant il est clair.
Tu aimes le projet Mozilla ? Tu aimerais que ça bouge autrement ? Fais-toi plaisir, va contribuer.
Mozilla accueille des contributeurs à tout les niveaux : marketing, release, IT, localisation, ingénierie, dev des sites web etc... Y a de quoi faire, quel que soit ton profil et ton créneau. Va donc essayer de participer comme ça chez Chrome par exemple (ah ah !). Y a pas que le code dans un projet.
Si Mozilla a fait une erreur au niveau de leur Fast Release Cycle, c'est parce qu'il y a eu un manque d'études de toutes les conséquences, c'est sûr, mais c'est probablement aussi qu'il n'y avait pas assez de personnes pour leur dire avant, "hey, ho, attention, il va y avoir tel ou tel problème si vous prenez telle décision, voici ce que je propose". Parce que Mozilla ne peut pas être partout, dans toutes les entreprises, chez tous les particuliers, pour leur demander ce qu'ils utilisent et comment.
Il y a toujours des gens pour dire YavaitKa après la bataille, mais avant la bataille, chacun est dans son coin et attend.
Si les entreprises, qui pour beaucoup ont gueulé et je les comprends, avaient été plus à l'écoute de ce qui se passait chez Mozilla (même si c'est pas évident aussi je le reconnais), et qu'ils faisaient un peu plus de feedback, peut être que chez Mozilla ils auraient pris un peu plus conscience du problème. Mozilla ne peut pas non plus deviner tout ce qui se passe partout avec leurs produits, surtout en entreprise.
Rappel, Mozilla, ce n'est pas Microsoft ou Google. Ils n'ont pas une armée de commerciaux et de marketeux
à "l'écoute" de leur "client"prospectant chez leurs clients.La seule force de Mozilla, c'est vous, utilisateurs. Alors n'hésitez pas à aller contribuer, ne serait-ce qu'en allant participer aux discussions qui vous intéressent dans les newsgroup Mozilla.
Si vous êtes 50 à vous plaindre dans une discussion sur un futur projet, ça passera moins inaperçu que si il n'y a qu'un seul pauvre gars qui tente de se faire entendre au milieu de toutes ces discussions.
Tu te plains du manque de communication ? Bien. Alors, tu as le choix. Soit tu fais dons de quelques millions afin que Mozilla mettent des affiches 4x3 dans toutes les grandes villes comme Google a fait pour Chrome (on ne le voit pas trop en France, mais le budget marketing de Chrome est hallucinant aux US). Soit tu commences par ajouter dans ton agrégateur http://planet.mozilla.org , et tu seras alors au courant de beaucoup de chose. Et tu pourras alors réagir si tu vois qu'il y a un truc en préparation qui ne te semble pas judicieux.
[^] # Re: Troll^W FUD
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Mozilla, son cycle de développement de 6 semaines et Eletrolysis. Évalué à 2.
s/utilisateurs/geek
Les utilisateurs s'en fichent du numéro de version. Et ça ne gênent vraiment que les geeks : la preuve est dans les stats. Il n'y a pas eu de désertion massive depuis la 4.
Pour les entreprises, ça ne les gêne pas non plus. Ce qui les gêne, c'est qu'il n'y ait pas de LTS (appelée ESR chez Mozilla). Mais ça va être résolut d'ici la fin de l'année, avec des ESR de plus d'un an (54 semaines) avec une ESR par an. Firefox 10 ou 11 sera la prochaine ESR.
Notez également qu'au début 2012, les mises à jours seront silencieuses par défaut. L'utilisateur sera encore moins "ennuyé" par les numéros de version (si tant est qu'il l'était). Et je parie qu'il n'y aura pas plus de défection que ça. D'ailleurs l'augmentation fulgurante du nombre d'utilisateurs de chrome prouve bien que ces utilisateurs en ont rien à foutre du numéro de version et des mises à jour.
Justement, ce que tu n'as pas compris, c'est qu'il n'y a plus la notion de version majeure ou mineure.
les utilisateurs (et les développeurs web) n'ont pas à attendre 1 an ou 2 pour profiter des nouvelles améliorations.
au niveau interface, c'était cosmétique jusqu'ici, mais tu auras des versions avec plus de changements visuels. Et tu les auras dés que leur développement sera terminé, tu n'auras pas à attendre 1 an ou 2 qu'une version "majeure" sorte. (Par ex, les nouveaux outils développeurs dans Fx 10).
Et puis bon, c'est pas sans saveur pour tout le monde hein:
- https://developer.mozilla.org/en/Firefox_5_for_developers
- https://developer.mozilla.org/en/Firefox_6_for_developers
- https://developer.mozilla.org/en/Firefox_7_for_developers
- https://developer.mozilla.org/en/Firefox_8_for_developers
Et il n'y aurait pas de travail de fond dans Mozilla ?
[^] # Re: Troll^W FUD
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Mozilla, son cycle de développement de 6 semaines et Eletrolysis. Évalué à 2.
Je l'ai bien lu. Même un vendredi, ça m'arrive de répondre aux trolls.
Mais là, ça manque vraiment trop de subtilité, c'est trop "voyant" :-p (de mon point de vue en tout cas)
# Troll^W FUD
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Mozilla, son cycle de développement de 6 semaines et Eletrolysis. Évalué à 6.
On est vendredi, c'est la journée des Trolls. Par contre, on n'a jamais dit que c'était la journée du FUD.
Journal raté donc.
Tout ceux qui suivent d'assez près le projet Mozilla savent que tout le contenu de ce journal est rempli d'informations fausses et de raccourcis à la con aboutissant à des conclusions débiles.
Je ne répondrais donc pas à ce truc.
[^] # Re: Régression
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche B2G : Mozilla « Boot To Gecko », un OS pour mobiles et tablettes. Évalué à 3.
Depuis quand on a besoin d'un serveur web pour afficher un fichier html ? ;-)
[^] # Re: Et sinon Gecko il est où ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche B2G : Mozilla « Boot To Gecko », un OS pour mobiles et tablettes. Évalué à 4.
Ils n'ont jamais vraiment dit ça. Par contre, c'est peut être de ma faute si tu le penses, puisque c'est plus ou moins ce que je disais à l'époque sur xulfr.org et ailleurs, croyant au développement de XulRunner &co. Et puis patatra, un jour Mozilla annonça que XulRunner ne sera jamais un "produit" (ils l'ont fait parce que je pense qu'ils se rendaient compte que XulRunner prenait trop d'ampleur, et que ça allait gêner le développement de Firefox dans le futur).
Et comme toi je fus extrêmement déçu... XulRunner et XUL restera un truc de geek, pas une technologie utilisée massivement en dehors de Firefox et TB.
[^] # Re: Régression
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche B2G : Mozilla « Boot To Gecko », un OS pour mobiles et tablettes. Évalué à 4.
Si au contraire. Le terme Webapp est peut être utilisé à tord, mais dans le cas de B2G, ça ne veut pas dire hebergé sur un serveur. Une webapp au sens B2G, est une appli qui utilise les technos web, mais qui est packagée pour être installé sur le téléphone. Heureusement encore, parce que si il fallait obligatoirement une connectivité pour faire fonctionner la moindre appli :-)
Donc installation, et donc mise à jour à faire. Et au niveau format de paquet, on peut imaginer que ça utilisera ça http://www.w3.org/TR/2011/REC-widgets-20110927/ . ou pas.
[^] # Re: Et sinon Gecko il est où ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche B2G : Mozilla « Boot To Gecko », un OS pour mobiles et tablettes. Évalué à 6.
Euh si.. Tout est en XUL dans seamonkey. Depuis 99, tous les produits Mozilla (ou dérivé) sont en XUL. (Mozilla suite, Firefox, Thunderbird, Sunbird...).
Kompozer est le descendant de Nvu, qui est un descendant de l'éditeur Composer, qui était fourni dans la suite mozilla. Donc eux aussi en XUL.
[^] # Re: Régression
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche B2G : Mozilla « Boot To Gecko », un OS pour mobiles et tablettes. Évalué à 3.
à l'heure actuel, les applis dans android sont en java. Donc déjà pas en code natif. y a probablement du JIT, mais bon, les applis web aussi c'est pareil, y a du JIT au niveau javascript (la lourdeur java en moins).
Bref, je ne vois pas de moins value là dedans.
La moins value que je vois (c'est mon opinion), c'est que developper une webapp va être probablement plus long, car on n'a pas forcément tous les widgets d'interface prêt à l'emploi que l'on dispose dans le toolkit d'android par exemple (bon, j'y connais pas grand chose à android non plus). à moins que Mozilla passe la seconde sur un remplaçant standardisé de XBL (permettant de développer des composants réutilisables).
[^] # Re: Concrètement ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche B2G : Mozilla « Boot To Gecko », un OS pour mobiles et tablettes. Évalué à 5.
De ce que j'ai compris : ils partent d'android pour ne pas avoir à démarrer from scratch et pouvoir aussi utiliser au minimum le téléphone pour tester les nouvelles api. Et petit à petit ils vont remplacer les applis natives par des webapp.
à priori, au final, il ne restera d'android pas grand chose, si ce n'est le noyau linux et ce qui va autour au niveau système. Si j'ai bien compris. :-)