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. :-)
Est-il beaucoup plus compliqué d'embarquer un webkit qu'un gecko ?
Je pense que tu veux dire l'inverse. Oui, gecko est plus compliqué à embarqué que webkit. En même temps, gecko est plus fait pour embarquer (cf xulrunner), que pour être embarqué. Et puis l'API d'embedding a été supprimé recement car plus maintenue et super trop obsolète. Une discussion a eu lieu sur gecko embedding au mozcamp de ce week end, avec notamment des packageurs linux (dont Glandium, pour Debian, packageur officiel pour les softs mozilla). Est ce qu'il y a un intérêt à refaire une API embedding ? qui a besoin d'embedding etc. Si vous vous sentez concerné, allez en discuter sur les newsgroup de mozilla (voir google groups)
mais là si on pense au "support" de XUL, on se dit que Mozilla n'a malheureusement jamais su faire de ses produits une vrai plateforme
Ce n'est pas une question de n'avoir pas su faire, c'était une question de volonté, une question politique produit. La principale raison : si ils avaient voulu faire de la plateforme un vrai produit (genre promouvoir XulRunner etc), ils auraient été obligé de gelée un certain nombre d'API, ils auraient eu plus de boulot parce qu'il y aura fatalement eu des choses à développer et à corriger qui n'ont pas de rapport avec Firefox. Or, la guerre des navigateurs sévi, le web se propriétise de plus en plus et Firefox est devenu le fer de lance de Mozilla. C'est LE produit par lequel Mozilla peut se faire entendre, peut promouvoir un web libre et ouvert (cf le manifesto mozilla). Ne pas supporter officiellement la plateforme gecko (par XulRunner etc), permet aux développeurs mozilla de faire évoluer gecko dans la direction qu'ils veulent, en toute liberté, en cassant tout ce qu'ils veulent casser quand c'est nécessaire.
Quand je dis plateforme, je parle bien de la plateforme gecko, XUL. Ce que Mozilla promeut par contre bien évidement, c'est la plateforme "web", qui est la couche au dessus si on peut dire. Et qui fait abstraction au final du navigateur (en théorie :)). On le voit d'ailleurs avec B2G : utilisation des technos web partout.
Je reviens du meeting mozcamp qui a eu lieu à Berlin ce week-end dernier, regroupant bon nombre de contributeurs européens et africains.
Et nous avons eu droit à une conf sur B2G, avec demo etc. (Sachant que je suis bien pote avec les deux français qui font parti de l'équipe B2G, Vivien et Mounir, j'ai déjà eu droit à une démo il y a quelques semaines déjà :) (ouai, je crâne grave))
Ce qu'il faut savoir donc :
Mozilla est déjà en relation avec des fabricants, qui sont très intéresses pour avoir une alternative à android.
Si la roadmap est tenu (hum), il y aura des téléphones B2G à la fin 2012
Dans le projet B2G, il y a deux projets en gros :
les API web, qui vont taper dans le système
l'interface.
L'interface sera interchangeable, personnalisable à donf par les utilisateurs ou fabricants, et pour cause : tout sera en HTML. Donc si pour le moment ça ressemble à de l'android, ça pourrait ne plus l'être dans quelques mois, ou en tout cas, des alternatives seront possibles.
le but est de permettre d'avoir des applis webphone qui soient interopérable entre webphone "html" (il y a des specs aux W3C pour les paquets webapp, je suppose qu'ils vont reprendre ça, je ne sais pas). Pas besoin de SDK apple ou windows qui coute la peau des fesses, pas besoin d'apprendre un enième langage si vous faites déjà du web. Et pas obligé de passer par un trucstore pour installer l'appli (comme les app d'android).
le but aussi est de fournir une alternative d'os qui ne soit pas dépendant obligatoire d'un fournisseur (google ou apple par ex) pour tout ce qui est données persos etc.. Les autres projets mozilla qui sont en cours et concernant le respect de la vie privée etc serviront dans B2G à priori.
pour le moment, B2G marchouille (avec pleins de bug, c'est encore super experimental) : on peut envoyer et recevoir des SMS, on peut émettre et recevoir un appel (un bug empêche pour le moment de raccrocher :-) ).
il y a encore pas mal de dépendance avec des composants android, mais ça disparaitra à l'avenir, (pour n'avoir au final qu'un linusque et un gecko avec les libs qui vont bien)
Et petit rappel : c'est un projet libre !!! Vous pouvez y contribuer !! C'est l'occasion de faire du html hard core (cool ! plus besoin de se préoccuper d'une compatibilité avec tel navigateur, vous pouvez utiliser les dernières fonctionnalités CSS et HTML sans retenu !), l'occasion de faire de la prog système (développement des apis entre autre), ou encore l'occasion de proposer des solutions qui permettent d'améliorer l'expérience utilisateur, ou encore qui permettent d'avoir une interface "différente".
Que le travail soit de fond ou pas, c'est toujours bien que l'utilisateur en profite le plus rapidement possible.
Tu oublie les développeurs web aussi. Même si dans la 8, il n'y a pas de révolutions, quand il y a des nouvelles fonctionnalités intéressantes, c'est sympa de savoir qu'on va pouvoir les utiliser rapidement, parce que la majorité des internautes auront un navigateur à jour dans une période qui se comptent en quelques semaines, plutôt qu'en mois ou années. Et c'est d'autant plus vrai que c'est la course avec les autres browsers.
Et avoir telle ou telle fonctionnalité, ça peut changer pas mal de chose dans un projet, parce que ça peut permettre probablement d'économiser du temps à trouver une alternative, ou ça peut permettre d'ouvrir de nouvelles perspectives au niveau applicatif (par exemple, l'arrivée du drag'n drop de fichiers, et la manipulation des fichiers avec FileReader, il y a quelques temps, sont des trucs qui permettent de changer la done en matière d'interface de publication de données, de photos...).
il y a surtout un problème d'utilisation du logiciel.
Apparemment, de ce que j'ai vu, les personnes qui ont rapporté ce genre de chiffres (100,150..) sont des power users.
Je pense au contraire que ce sont des personnes qui utilisent au maximum le navigateur : utilisation de panorama, utilisation de l'autocomplétion dans la barre d'adresse pour retrouver rapidement le tab ouvert etc...
Et puis quand tu codes et que tu as souvent besoin d'accéder à de la doc, à un navigateur web de code source (genre, quand tu es dev Mozilla, http://mxr.mozilla.org ), ou à un bug tracker etc, le nombre de tab peut vite augmenter, pour éviter d'avoir à relancer un moteur de recherche, ou à recharger les pages. Car ce genre de chose c'est plus lent que d'activer un tab...
perso, je peux arriver à 40-50 tabs quand je suis en mode dev.
Bref, le nombre de tab ne présage à mon avis pas d'un problème d'utilisation de logiciel. Surtout qu'il y a pas mal d'extensions qui permettent de gérer toutes ces tabs, dont celle qui a été intégré dans Firefox, "panorama".
oui le multi-process, ça ne fait pas tout, et c'est l'une des raisons je crois de leur non-empressement à l'activer. Ils préfèrent mettre leur energie sur la réduction de la mémoire et la correction des crash.
Oui en effet :-), mais j'imagine que sur mobile il y avait d'autres contraintes (que je ne connais pas) qui rendait avantageux le multi process (plus de vélocité ? ce qui est important sur ces petits processeurs).
Tu remarqueras aussi que sur un mobile, tu ne vas pas lancer 30 tab. Donc la consommation mémoire au finale, ne va pas être beaucoup plus importante.
Par contre, sur le desktop, tu arrives vite à 30-40 voir 200 tabs pour certains. Et dans ces conditions en effet, la consommation mémoire explose, on le voit avec chrome. C'est probablement aussi une des raisons qu'ils ne se pressent pas trop pour la version desktop. Ils travaillent pas mal plutôt en ce moment à réduire la consommation mémoire sur pas mal d'endroits dans Gecko : projet memshrinck ?
C'est déjà le cas depuis de nombreuses années. Sous windows tu as le selecteur de windows, sous mac, celui du mac, et sous linux, celui de gtk. Si tu es sous kde, compile toi une version avec le support qt au lieu de gtk. (le port qt existe, mais il n'y a pas de build officiel, vu qu'il ne doit pas être super super stable). Si tu es sur un autre desktop linux, bah tant pis. fait un patch.
Mais pour FireFox, c'est différent: le projet Electrolysis n'est toujours pas intégré,
Euh... si. La version mobile est multi process au niveau des tabs. Comme je dis dans un commentaire plus bas, ce n'est pas activé pour la version desktop, car il y a encore pas mal de boulot à faire au niveau du code de l'interface. Et il y a un autre souci qui ralentit cette migration : la manière d'accéder à une page html pour une extension classique (non jetpack) change radicalement. Si ils activent ça tout de suite (dans l'hypothèse où le code de l'interface est adapté), ça va être plein d'extensions qui vont être incompatible du jour au lendemain.
Donc, la nouvelle API pour dialoguer avec une page html d'un onglet est en place depuis pas mal de temps maintenant, les extensions peuvent donc commencer à migrer leur code pour l'utiliser. Le jour où electrolysis sera activé, elles fonctionneront donc sans modification.
Pour Firefox Mobile, c'est déjà opérationnel, d'une part parce que le code à migrer au niveau de l'interface du navigateur même était moins important, mais aussi parce que le nombre d'extensions était largement moins important. Il y a aussi des contraintes liés aux mobiles qui ont fait que c'était une des priorités aussi du projet Firefox Mobile.
Et sinon, dans le projet Firefox, il n'y a pas qu'Electrolysis, il y a plein d'autres choses à faire qui sont tout aussi importantes, même si ça l'est moins aux yeux des geeks qui veulent du multi process.
Alors.. Il doit y avoir un problème de vocabulaire. Parce que Firefox est multithreadé depuis.. euh.. ah ba depuis avant sa naissance (Netscape 6, Mozilla suite..). Heureusement en effet qu'une requête réseau, entre autre chose, se fait toujours en arrière plan...
Par contre, oui, Firefox (version desktop) n'est toujours pas multi-processé. Il y a juste deux process : un pour les plugins web (flash et consort), et un autre pour le reste.
Et ce dont tu parles, c'est de vouloir un process par tab. Ce n'est pas le cas pour la version desktop en effet. Encore pas mal de boulot pour adapter tout le code de l'interface qui fait le lien entre le contenu html et les elements extérieurs à la page (historique, bookmarks, les élements de l'interfaces etc...).
Par contre, la version mobile est multi processé sur les onglets (comme il y a moins de code au niveau de l'interface, ca a été plus rapide à faire).
Enfin la création d'entreprise est toujours aussi galère et chargée,
Quand nous avons crée notre boite avec mes associés, on a trouvé une solution : tout refiler au cabinet comptable. C'est lui qui a fait toutes les démarches d'immatriculation de la boite, urssaf et cie. On a juste eu à faire les statuts, à aller à la banque pour ouvrir un compte, et à signer les papiers que le comptable nous refilait (1). Résultat : on a été "opérationnel" très rapidement. On a pu se concentrer tout de suite sur notre métier à nous.
Alors bien sûr, ça a un coût. Mais bien moindre, beaucoup moindre même, que si on avait fait ça nous même. Car, bien évidement, totalement novice en trucs administratifs et comptabilité, on y aurait passé des journées entières. Et c'est autant de journées en moins à facturer à des clients. Au final, le montant de ces journées non facturées aurait été beaucoup plus important que ce que nous ont coûté les démarches faites par le cabinet comptable.
Et puis moi je dis, la compta, l'administratif tout ça, c'est un métier, et c'est pas le mien. Donnons ça aux gens dont c'est le métier. Effets collatéraux : avec un cabinet comptable, il y a moins de chances de passer à coté de trucs importants à faire, moins d'erreurs, donc moins de risque d'avoir des pénalités ou autres trucs désagréables (qui bouffent eux aussi au final du temps et de l'argent).
Conclusion : Ne vous retenez pas de vous lancer à cause des démarches administratives ! Allez-y ! (avec un bon cabinet comptable)
(1) bon c'est vrai qu'il y a quand même d'autres trucs chiants qu'il faut faire soi-même : inscription RSI (securité sociale), CIPAV (retraite) etc... Mais tout le reste que peux faire le comptable, c'est toujours ça de gagné et ça enlève une grosse épine du pied.
C'est dingue, "in" au lieu du caractère ":" et "foreach" au lieu de "for" devient plus lisible ?
Pour moi oui. Le ":", si on ne sait pas ce qu'il représente, on comprend mal ce que fait ce for particulier. Je n'ai pas compris ce que ton truc faisait aux premiers abords (bien ayant fait du C++ pendant de longues années), alors que l'exemple du C#, j'ai tout de suite compris (bien que n'ayant jamais fait du C#).
Pour toi c'est lisible, parce que tu connais cette syntaxe particulière. Pour les autres, c'est beaucoup moins évident.
Il est plus facile de comprendre un truc qui se rapproche du langage naturel, qu'un truc s'exprimant par signe cabalistique.
Par exemple, un programme perl, c'est souvent incompréhensible pour quelqu'un n'ayant jamais fait de perl. Alors que du python ou du php, c'est un peu plus lisible, parce que la syntaxe comprenant moins de signes "bizarres".
Par contre si j'ai compris, les données sont chiffrées à l'envoi donc même si elles sont hébergées chez Mozilla, ils n'y ont pas accès. Bon par contre, pas d'accès en version-web ce qui aurait pu pallier l'absence de plugin pour les autres navigateurs.
Comment veux-tu qu'ils proposent une version web, si ils n'ont pas accès aux données puisqu'elles sont chiffrées ?
[^] # 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. :-)
[^] # 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é à 7.
Je pense que ce que tu cherches, c'est ça : http://www.mozilla.org/projects/mozilla-based.html ;-)
De rien.
Je pense que tu veux dire l'inverse. Oui, gecko est plus compliqué à embarqué que webkit. En même temps, gecko est plus fait pour embarquer (cf xulrunner), que pour être embarqué. Et puis l'API d'embedding a été supprimé recement car plus maintenue et super trop obsolète. Une discussion a eu lieu sur gecko embedding au mozcamp de ce week end, avec notamment des packageurs linux (dont Glandium, pour Debian, packageur officiel pour les softs mozilla). Est ce qu'il y a un intérêt à refaire une API embedding ? qui a besoin d'embedding etc. Si vous vous sentez concerné, allez en discuter sur les newsgroup de mozilla (voir google groups)
Ce n'est pas une question de n'avoir pas su faire, c'était une question de volonté, une question politique produit. La principale raison : si ils avaient voulu faire de la plateforme un vrai produit (genre promouvoir XulRunner etc), ils auraient été obligé de gelée un certain nombre d'API, ils auraient eu plus de boulot parce qu'il y aura fatalement eu des choses à développer et à corriger qui n'ont pas de rapport avec Firefox. Or, la guerre des navigateurs sévi, le web se propriétise de plus en plus et Firefox est devenu le fer de lance de Mozilla. C'est LE produit par lequel Mozilla peut se faire entendre, peut promouvoir un web libre et ouvert (cf le manifesto mozilla). Ne pas supporter officiellement la plateforme gecko (par XulRunner etc), permet aux développeurs mozilla de faire évoluer gecko dans la direction qu'ils veulent, en toute liberté, en cassant tout ce qu'ils veulent casser quand c'est nécessaire.
Quand je dis plateforme, je parle bien de la plateforme gecko, XUL. Ce que Mozilla promeut par contre bien évidement, c'est la plateforme "web", qui est la couche au dessus si on peut dire. Et qui fait abstraction au final du navigateur (en théorie :)). On le voit d'ailleurs avec B2G : utilisation des technos web partout.
# Quelques compléments
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é à 10.
Hello,
Je reviens du meeting mozcamp qui a eu lieu à Berlin ce week-end dernier, regroupant bon nombre de contributeurs européens et africains.
Et nous avons eu droit à une conf sur B2G, avec demo etc. (Sachant que je suis bien pote avec les deux français qui font parti de l'équipe B2G, Vivien et Mounir, j'ai déjà eu droit à une démo il y a quelques semaines déjà :) (ouai, je crâne grave))
Ce qu'il faut savoir donc :
Et petit rappel : c'est un projet libre !!! Vous pouvez y contribuer !! C'est l'occasion de faire du html hard core (cool ! plus besoin de se préoccuper d'une compatibilité avec tel navigateur, vous pouvez utiliser les dernières fonctionnalités CSS et HTML sans retenu !), l'occasion de faire de la prog système (développement des apis entre autre), ou encore l'occasion de proposer des solutions qui permettent d'améliorer l'expérience utilisateur, ou encore qui permettent d'avoir une interface "différente".
[^] # Re: Firefox 9
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 8 est disponible. Évalué à 7.
Que le travail soit de fond ou pas, c'est toujours bien que l'utilisateur en profite le plus rapidement possible.
Tu oublie les développeurs web aussi. Même si dans la 8, il n'y a pas de révolutions, quand il y a des nouvelles fonctionnalités intéressantes, c'est sympa de savoir qu'on va pouvoir les utiliser rapidement, parce que la majorité des internautes auront un navigateur à jour dans une période qui se comptent en quelques semaines, plutôt qu'en mois ou années. Et c'est d'autant plus vrai que c'est la course avec les autres browsers.
Et avoir telle ou telle fonctionnalité, ça peut changer pas mal de chose dans un projet, parce que ça peut permettre probablement d'économiser du temps à trouver une alternative, ou ça peut permettre d'ouvrir de nouvelles perspectives au niveau applicatif (par exemple, l'arrivée du drag'n drop de fichiers, et la manipulation des fichiers avec FileReader, il y a quelques temps, sont des trucs qui permettent de changer la done en matière d'interface de publication de données, de photos...).
[^] # Re: Firefox 9
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 8 est disponible. Évalué à 9.
Apparemment, de ce que j'ai vu, les personnes qui ont rapporté ce genre de chiffres (100,150..) sont des power users.
Je pense au contraire que ce sont des personnes qui utilisent au maximum le navigateur : utilisation de panorama, utilisation de l'autocomplétion dans la barre d'adresse pour retrouver rapidement le tab ouvert etc...
Et puis quand tu codes et que tu as souvent besoin d'accéder à de la doc, à un navigateur web de code source (genre, quand tu es dev Mozilla, http://mxr.mozilla.org ), ou à un bug tracker etc, le nombre de tab peut vite augmenter, pour éviter d'avoir à relancer un moteur de recherche, ou à recharger les pages. Car ce genre de chose c'est plus lent que d'activer un tab...
perso, je peux arriver à 40-50 tabs quand je suis en mode dev.
Bref, le nombre de tab ne présage à mon avis pas d'un problème d'utilisation de logiciel. Surtout qu'il y a pas mal d'extensions qui permettent de gérer toutes ces tabs, dont celle qui a été intégré dans Firefox, "panorama".
[^] # Re: Toujours pas de multithread
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 8 est disponible. Évalué à 3.
oui le multi-process, ça ne fait pas tout, et c'est l'une des raisons je crois de leur non-empressement à l'activer. Ils préfèrent mettre leur energie sur la réduction de la mémoire et la correction des crash.
[^] # Re: Firefox 9
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 8 est disponible. Évalué à 7.
Oui en effet :-), mais j'imagine que sur mobile il y avait d'autres contraintes (que je ne connais pas) qui rendait avantageux le multi process (plus de vélocité ? ce qui est important sur ces petits processeurs).
Tu remarqueras aussi que sur un mobile, tu ne vas pas lancer 30 tab. Donc la consommation mémoire au finale, ne va pas être beaucoup plus importante.
Par contre, sur le desktop, tu arrives vite à 30-40 voir 200 tabs pour certains. Et dans ces conditions en effet, la consommation mémoire explose, on le voit avec chrome. C'est probablement aussi une des raisons qu'ils ne se pressent pas trop pour la version desktop. Ils travaillent pas mal plutôt en ce moment à réduire la consommation mémoire sur pas mal d'endroits dans Gecko : projet memshrinck ?
[^] # Re: Amélioration du sélecteur de fichiers
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 8 est disponible. Évalué à 0.
C'est déjà le cas depuis de nombreuses années. Sous windows tu as le selecteur de windows, sous mac, celui du mac, et sous linux, celui de gtk. Si tu es sous kde, compile toi une version avec le support qt au lieu de gtk. (le port qt existe, mais il n'y a pas de build officiel, vu qu'il ne doit pas être super super stable). Si tu es sur un autre desktop linux, bah tant pis. fait un patch.
[^] # Re: Firefox 9
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 8 est disponible. Évalué à 9.
Euh... si. La version mobile est multi process au niveau des tabs. Comme je dis dans un commentaire plus bas, ce n'est pas activé pour la version desktop, car il y a encore pas mal de boulot à faire au niveau du code de l'interface. Et il y a un autre souci qui ralentit cette migration : la manière d'accéder à une page html pour une extension classique (non jetpack) change radicalement. Si ils activent ça tout de suite (dans l'hypothèse où le code de l'interface est adapté), ça va être plein d'extensions qui vont être incompatible du jour au lendemain.
Donc, la nouvelle API pour dialoguer avec une page html d'un onglet est en place depuis pas mal de temps maintenant, les extensions peuvent donc commencer à migrer leur code pour l'utiliser. Le jour où electrolysis sera activé, elles fonctionneront donc sans modification.
Pour Firefox Mobile, c'est déjà opérationnel, d'une part parce que le code à migrer au niveau de l'interface du navigateur même était moins important, mais aussi parce que le nombre d'extensions était largement moins important. Il y a aussi des contraintes liés aux mobiles qui ont fait que c'était une des priorités aussi du projet Firefox Mobile.
Et sinon, dans le projet Firefox, il n'y a pas qu'Electrolysis, il y a plein d'autres choses à faire qui sont tout aussi importantes, même si ça l'est moins aux yeux des geeks qui veulent du multi process.
[^] # Re: Toujours pas de multithread
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 8 est disponible. Évalué à 8.
Alors.. Il doit y avoir un problème de vocabulaire. Parce que Firefox est multithreadé depuis.. euh.. ah ba depuis avant sa naissance (Netscape 6, Mozilla suite..). Heureusement en effet qu'une requête réseau, entre autre chose, se fait toujours en arrière plan...
Par contre, oui, Firefox (version desktop) n'est toujours pas multi-processé. Il y a juste deux process : un pour les plugins web (flash et consort), et un autre pour le reste.
Et ce dont tu parles, c'est de vouloir un process par tab. Ce n'est pas le cas pour la version desktop en effet. Encore pas mal de boulot pour adapter tout le code de l'interface qui fait le lien entre le contenu html et les elements extérieurs à la page (historique, bookmarks, les élements de l'interfaces etc...).
Par contre, la version mobile est multi processé sur les onglets (comme il y a moins de code au niveau de l'interface, ca a été plus rapide à faire).
[^] # Re: La technique c'est saaaale
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Hacker le développement des entreprises. Évalué à 6.
Quand nous avons crée notre boite avec mes associés, on a trouvé une solution : tout refiler au cabinet comptable. C'est lui qui a fait toutes les démarches d'immatriculation de la boite, urssaf et cie. On a juste eu à faire les statuts, à aller à la banque pour ouvrir un compte, et à signer les papiers que le comptable nous refilait (1). Résultat : on a été "opérationnel" très rapidement. On a pu se concentrer tout de suite sur notre métier à nous.
Alors bien sûr, ça a un coût. Mais bien moindre, beaucoup moindre même, que si on avait fait ça nous même. Car, bien évidement, totalement novice en trucs administratifs et comptabilité, on y aurait passé des journées entières. Et c'est autant de journées en moins à facturer à des clients. Au final, le montant de ces journées non facturées aurait été beaucoup plus important que ce que nous ont coûté les démarches faites par le cabinet comptable.
Et puis moi je dis, la compta, l'administratif tout ça, c'est un métier, et c'est pas le mien. Donnons ça aux gens dont c'est le métier. Effets collatéraux : avec un cabinet comptable, il y a moins de chances de passer à coté de trucs importants à faire, moins d'erreurs, donc moins de risque d'avoir des pénalités ou autres trucs désagréables (qui bouffent eux aussi au final du temps et de l'argent).
Conclusion : Ne vous retenez pas de vous lancer à cause des démarches administratives ! Allez-y ! (avec un bon cabinet comptable)
(1) bon c'est vrai qu'il y a quand même d'autres trucs chiants qu'il faut faire soi-même : inscription RSI (securité sociale), CIPAV (retraite) etc... Mais tout le reste que peux faire le comptable, c'est toujours ça de gagné et ça enlève une grosse épine du pied.
[^] # Re: danger firefox
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Fin de la vie privée sur Google Search ? Au revoir.. Évalué à 2.
Pourquoi danger "firefox" ? Ça le fait dans tout les navigateurs. Vérifiez avant d'accuser.
[^] # Re: c++11
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Grande braderie chez O'Reilly !. Évalué à 5.
Pour moi oui. Le ":", si on ne sait pas ce qu'il représente, on comprend mal ce que fait ce for particulier. Je n'ai pas compris ce que ton truc faisait aux premiers abords (bien ayant fait du C++ pendant de longues années), alors que l'exemple du C#, j'ai tout de suite compris (bien que n'ayant jamais fait du C#).
Pour toi c'est lisible, parce que tu connais cette syntaxe particulière. Pour les autres, c'est beaucoup moins évident.
Il est plus facile de comprendre un truc qui se rapproche du langage naturel, qu'un truc s'exprimant par signe cabalistique.
Par exemple, un programme perl, c'est souvent incompréhensible pour quelqu'un n'ayant jamais fait de perl. Alors que du python ou du php, c'est un peu plus lisible, parce que la syntaxe comprenant moins de signes "bizarres".
# le beurre et l'argent du beurre
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Comment remplacer son minitel 2.0 ?. Évalué à 3.
Comment veux-tu qu'ils proposent une version web, si ils n'ont pas accès aux données puisqu'elles sont chiffrées ?