Laurent J a écrit 2938 commentaires

> Le prix de l'entretien est quand même inférieur au prix de l'amortissement.

et bien justement, le prix d'entretien est énorme : c'est plusieurs centaine de milliers d'euros par kilomètre pour refaire juste l'enrobage (10 000 euros le métre, à vérifier).

Et je n'ai pas parlé non plus des travaux d'elargissements des voies, ou encore, chose que je viens de découvrir aussi : le prix de la concession à payer à l'etat..

la société concessionnaire de l'A6 ne possède pas non plus que l'A6, mais d'autres autoroute.

Enfin bref, va lire le rapport financier 2009 de ladite société : http://www.aprr.com/Templates/Rapport%20financier%201er%20se(...)

un resultat net de 149 millions environ, pour un CA de 1 milliard, c'est pas super énorme je trouve. je ne pense pas que si ils enlevaient les pages de l'A6, ils feraient encore des bénéfices.

(et puis va donc virer les péages, supprimant donc des dizaines d'emplois)

> On pourrait remplacer tout cela par un lancement de firefox avec une option en ligne de commande qui donnerait le chemin du profile, c'est tout


là je ne comprend pas ta phrase qui est en contradiction avec ce que tu dis plus haut : "le mode multi-profile ne sers à rien".

le fais de démarrer avec le profil de son choix en ligne de commande, existe depuis le debut, c'est le paramètre -Profile suivit du nom du profile.

Sinon, oui, le mode multi-profile sert à quelque chose, surtout aux dévelopeurs d'extensions, aux developpeurs de firefox, à ceux qui veulent tester les nightlies ou beta sans craindre de flinguer leur profil utilisé au quotidien avec leur firefox stable etc...

Et le retirer ne retirerait pas grand chose en terme de ligne de code....

Et d'ailleurs, je ne vois pas pourquoi tu parles de multi profile : ça n'a strictement rien à voir avec ce dont je parlais, avec la communications entre onglet....

Conçernant ton problème de connection via ssh, y a un paramètre : -no-remote, pour éviter que firefox utilise la dernière session lancée.

> Tout ce code pourrait être virer lui aussi car à mon sens il est totalement illogique et compliqué.

compliqué ? tu es aller voir le code en question ? à mon avis non, parce qu'il ne s'agit que de quelques ligne de bash dans le script de lancement !

ok, certes, je n'avais plus pensé au fait qu'effectivement, le son était généré par le programme de la ROM.

En fait, j'étais plus parti dans l'idée que dans un jeu web (autre qu'un similateur de console :-)), rien n'empêche d'avoir des balises audio pour chacun des effets sonores du jeu, et de faire des play() pause() sur ces balises au moment opportun dans le jeu.

je n'ai pas dit que Cairo était le seul coupable. J'ai parlé aussi du binding DOM <-> javascript de Gecko qui pouvait en être une des causes. Il y a aussi peut-être d'autres choses dans le layout engine qui sont aussi responsables (mais à priori, l'affichage d'un canvas est assez décoléré du reste de la page web).

Mais Cairo a quand même sa part de responsabilité je pense : cette lib est réputée pour avoir eu des problèmes de performances par le passé. ça s'est amélioré depuis mais c'est pas toujours folichon quand même dès qu'on pousse un peu..

>Pas de son bien sûr,

pourquoi bien sûr ? Et la balise audio, elle sert à quoi ? ;-) Elle est présente dans Firefox et Chrome...

Ce n'est pas parce que c'est fait en javascript, qu'il faut imputer les problèmes de perfs à l'implémentation javascript.

Déjà, Javascript, ce n'est qu'un langage. Prend la spec d'Ecmascript, et tu n'y trouveras nulle part référence à DOM, canvas etc. En d'autres terme, un moteur javascript, ça n'implémente que l'interprétation de la syntaxe JS, quelques objets de base (Math, Array, String, Number etc...), et tout le reste que l'on utilise très souvent en JS (comme l'objet window, le DOM etc), ce ne sont que des API implémentés dans des libs à coté (rien à voir avec le JS donc), et importé dans le langage JS

Bref, dans ce genre d'application très graphique, le javascript n'a que peu de part de responsabilité dans les problèmes de perfs. Surtout que TraceMonkey (moteur de Firefox), compile en code machine pur tout ce qui est calcul mathématique js avant exécution (en particulier dans les boucles).

Si on veut un responsable sur les perfs, et dans une appli web comme celle là, il faut se tourner donc vers le DOM, et plus particulièrement ici vers la balise canvas.

Chez Mozilla, on sait que la couche de binding DOM <-> javascript n'est pas des plus performantes, et dans le trunk, (et la branche Fx 3.6 je crois), il y a eu des améliorations assez significatives en ce sens.

Ensuite, canvas. Dans Firefox, canvas, ce n'est qu'une API haut niveau au dessus de la bibliothèque Cairo (http://cairographics.org/ ). Autant dire que les mesure de perfs purement graphiques sont à imputer à Cairo. Reste à savoir dans quel mesure Cairo contribue à la dégradation des perfs en globalité.


Pour conclure, ne pas confondre javascript et les dizaines de composants que contient un navigateur.

>C'est un peu comme l'histoire de l'A6 qui a déja été rentabilisée à plus de 100 fois sa valeur, mais qui pourtant ne baisse pas ses prix.

Tu as raison. Une autoroute, ça ne s'entretient pas, et depuis la construction, ils n'ont jamais fait de réfection de la chaussée, aménagé de nouvelles aires d'autoroute ou refaites celles existantes. Ils n'ont pas non plus de personnel (et le materiel qui va avec) pour nettoyer les bords de l'autoroute, surveiller et être là au moindre accident etc....

ne pas confondre thread et processus. Bien sûr que Firefox utilise des threads depuis des années : pour les requêtes réseaux, pour les traitements n'ayant pas une interaction directe avec l'affichage etc.

Utiliser des threads pour chaque onglet, ça n'apporterais rien : les threads sont dans le même processus d'exécution, donc si ça plante dans l'un, tout plante.

Par contre oui, un *processus* par onglet, ça apporte une sécurité dans l'execution. Et c'est effectivement ce qui est fait dans Chrome et bientôt dans Firefox (c'est en cours de dev). Mais bon, ça occupe aussi beaucoup plus de mémoire (Chrome occupe plus de mémoire que le FF actuel dans pas mal de cas), et ça complexifie les communications entre onglet, avec le reste du navigateur (stockage de l'historique, du bookmark, synchro des prefs etc etc...).

seul problème de ce type de FS : quand tu veux copier ton fichier vers une autre machine (linux, windows etc), tu perds toutes les métas datas.. Donc dans certains cas, des informations..

>Devra-t-on payer en supplément pour pouvoir utiliser le code-barre?

bah oui. Puisque si j'ai bien compris, la video/ le document est téléchargé sur ton téléphone -> tu bouffes ton forfait (même si c'est du "illimité", tu bouffes ton quota de BP -> tu arriveras plus vite aux limites de ton "illimité").

À moins que ces videos/documents téléchargés à partir d'un site spécifique ne soit pas pris en compte dans ton quota...

Enfin bon, nouveau service, donc forcément, tu le payes quelques part.

C'est déjà très correcte, ne serait-ce que pour développer. Pas besoin de s'acheter une licence super chère pour développer une appli sur base oracle pour un client.

Le fait que ce soit du raster ou des fichiers complexes n'est en aucun cas une raison de ne pas faire des sauvegardes automatiques, même à intervalle court.

Il suffirait juste d'enregistrer la pile d'undo (dans un fichier à part, "special anti crash"), et donc juste le type des actions avec leurs paramètres. À chaque fois, ça ne serait que quelques dizaines d'octets à sauvegarder dans ce fichier anti-crash (et bien sûr, on n'enregistre que les actions qui n'avaient pas été sauvée)..

Et ainsi à la restauration -> rejouer la pile d'undo sauvegardée.

Et si on veut éviter de se retrouver en sauvegarde avec une pile d'undo énorme, on pourrait sauvegarder le vrai xcf toutes les 10 minutes (ou selon le user), et ça, ça pourrait se faire aussi dans un thread, pour éviter de trop géner le user.

Bref, il y a des solutions qui pourraient être implémentées.

sur le blog d'apache

https://blogs.apache.org/infra/entry/apache_org_downtime_ini(...)

j'ai juste repondu avec le même "tact" que ta question :-p

Une bonne grosse boutade quoi (en plus pas originale, je l'avoue...).


>Donc si je te suis bien, je vais patcher chaque outil que j'utilise qui doit répondre a des besoins que je ne suis pas le seul a avoir

chaque outils, non, bien évidement (ai-je dis ça ?). Mais si une fonctionnalité manquante est est très importante pour toi, pourquoi pas ? Ou même encore, pourquoi pas payer un dev pour le faire ? (ta boite ou toi, si il y a les sous, mais pas le temps ou pas les compétences).

C'est comme ça que fonctionne la grande majorité des projets Open Source.

>Mac OS X qui propose déjà un profiler de code performant

bah à priori, ce profiler n'a pas l'air de convenir à la majorité des dev Mozilla qui bossent sous Mac. Donc ils ont payé un gars pour le faire.

Tu n'as plus qu'à espérer que des dev Mozilla passent sous un BSD en masse pour voir le portage arriver :-)

Mais, euh... je te conseille de trouver une autre solution que d'attendre après Mozilla ;-)

quand tu auras filé ton patch.

"une bonne partie des animations SVG/SMIL"

Tout n'est pas totalement fini c'est tout. Dans ce genre de truc, vaut mieux avoir un truc fini qu'un truc à moitié fini... En fait le coeur est là, mais y a pas tout exposé encore si j'ai bien compris.

Le fait d'utiliser un processus par tab peut jouer au niveau rapidité. Mais il n'y a pas que ça. L'interface de Firefox, c'est du XML + JS. ça demande donc un peu plus de temps à réagir que du pur natif.

Pour le chargement du navigateur, il y a des trucs un peu lourd dans Firefox, et ils sont en train d'améliorer tout les points noirs.

bah si y a beaucoup d'IPC à faire : mise à jour de l'historique, paramètrage du navigateur, communication avec le download manager, le security manager etc etc. Un tout petit exemple : dés que tu ouvre une url, faut que le navigateur aille informer tout les autres tabs, pour que les styles des liens en :visited soient mis à jour. Et des trucs comme ça, il y en a beaucoup.

Bref Il y a beaucoup de communication inter processus. Pour te faire une idée, voir le dev qu'il y a actuellement dans Firefox pour faire un processus par tab: https://wiki.mozilla.org/Content_Processes

Ils réutilisent d'ailleurs la couche IPC de chromium ;-)

Les points manquants de Firefox sur le test acid3 concernent majoritairement le support des animations SVG/SMIL. C'est pas la fin du monde :)

La prochaine version de Firefox fera mieux évidement, car une bonne partie des animations SVG/SMIL sont implémentées, mais pas activé par défaut pour le moment dans le futur Firefox 3.6 qui sortira dans 3 mois. (oui oui, dans 3 mois, en novembre 2009).

La nightly de FF3.6 avec la préférence svg.smil.enable à true : 97/100. sans la pref: 95/100.

un fabricant qui a une capitalisation boursière plus grosse que Google, c'est pas un grand fabricant ?

http://www.generation-nt.com/capitalisation-boursiere-apple-(...)


J'aimerai bien alors diriger une petite boite comme Apple...

> Il s'applique à tous les fichiers dont le format comprend des marqueurs (métacodes), donc XML mais aussi HTML et bien d'autres formats.


ben non justement, si j'ai bien compris le procédé. Le brevet explique une technique où le contenu est séparé de la structure. Tu le dis toi même : content et map sont séparés. Or en XML/HTML, le contenu est à l'intérieur même de ce qui décrit la structure (les balises formant la structure).

Et cela semble être confirmé par ce que je viens de lire un peu partout : ce n'est pas l'utilisation du format XML qui est remis en cause, mais la manière dont sont stockées certaines données dans le format XML de Microsoft (avec j'imagine, un truc du genre des données brutes dans une balise, et une map dans une autre).

Ce brevet n'en reste pas moins totalement ridicule.

note : je bosse une boite qui fait de la techno sur le zoom de document et d'images.

les niveaux de zooms sont prédéfinies ok, les tuiles sont bien entendu précalculés. Mais quand tu veux faire du zoom linéaire et non incrémentale, (donc, il faut étirer/rapetisser les tuiles au finale, quand le zoom est entre deux niveau de zoom), comme c'est le cas pour notre outils, bah tu as forcément à un moment ou à un autre des tuiles disjointes à l'affichage, à cause des arrondis. Il faut donc toujours qu'une tuile puisse déborder sur une autre, ne serait-ce que d'un pixel ou deux.

Quand tu as un affichage de zoom à des niveaux prédéfinis (on ne peux pas zoomer entre deux niveaux de zoom), oui, tu n'a pas besoin que les tuiles se chevauchent, puisque tu affiches alors les tuiles telles quel (même si tu fais une jolie transition quand tu passes d'un niveau de zoom à un autre, en étirant/rapetissant les tuiles temporairement. si il n'y a pas de jointure parfaite durant la transition, c'est pas grave, ça ne se verra pas.

Ben si, c'est du flash. les boutons sont en HTML, mais le player en lui même est bien en flash.. (ils pourraient utiliser la balise quand même...)

Et sinon, franchement, je ne suis pas fier que ce soit français. Vu la gueule du HTML (via firebug), à la place des développeurs, je me cacherai. Parce que par exemple, imbriquer neuf DIV pour enfin afficher le contenu principal de la page, avec en plus du style inline et des classes (les mêmes en plus) dans tout les sens, ça craint du boudin... Je plains ceux qui doivent le maintenir (quoique, si c'est ceux qui l'ont développé...)

Bref, leurs pages pourraient être bien plus light et compréhensibles... Deezer, au moins, le code est un peu mieux organisé.


(désolé, c'est mon coté critique dev web qui ressort)

LOL.


(ouai, je sais, avec ce LOL, je me grille encore plus, mais que voulez vous...)

non, pas comme des pavés. Parce que des pavés, ça se chevauche pas. Des tuiles, ça se chevauche. Et justement, dans le domaine du zoom, en général, on fait légèrement chevauché les images, pour compenser les arrondis dans les calculs de zoom/taille. bon, peut être pas sur google map ou mappy, vu qu'ils ont des niveaux de zoom déterminés (quoique, j'ai pas regardé le code en détails). Mais quand on a un système de zoom sans "échelons", on est obligé de les faire chevaucher sinon on peut avoir des images disjointes à certains niveau de zoom, et ça c'est moche :-).

Bref, des tuiles quoi..