Laurent J a écrit 2932 commentaires

Nan mais le monsieur parle pas de bug. Il parle de pouvoir compiler Firefox avec QT plutôt qu'avec GTK, et que Firefox s'intègre mieux dans KDE. D'ailleurs le bug n'a pas 10 ans, mais 16. https://bugzilla.mozilla.org/show_bug.cgi?id=140751

Mais bon Mozilla ne peut pas s'occuper de tous les toolkits de la planète, surtout ceux utilisés par 0,01% des utilisateurs. Dont je fais parti d'ailleurs, je suis un indécrottable utilisateur de KDE depuis les distro Mandrake.

À noter qu'il fut un temps où il y avait, c'est vrai, un port QT de Firefox, dans le dépôt Mozilla mais il est toujours resté expérimental, parce que d'une part, il a été fait dans le cadre d'un port de Fennec (la toute première version mobile de Firefox) sur des mobiles Nokia si je me rappelle bien, et donc ne prenait pas en charge ce qui était spécifique au Desktop; D'autre part ce port était peu maintenu, et surtout n'a pas attiré les contributeurs. Pas de contributeurs. Pas de chocolat.

Sans parler que, pour l'intégration de KDE, il y a des soucis : il faut que Firefox puisse détecter qu'il est dans un environement KDE ou pas, pour pouvoir utiliser les différents composants de KDE, tout en intégrant un fallback si jamais le binaire téléchargé est executé dans un autre environnement. Ce qui semble ne pas être une chose facile sans des hacks à la con : https://bugzilla.mozilla.org/show_bug.cgi?id=528510#c5 . Il est en effet hors de question de compiler en statique le coeur de KDE dans Firefox :). Il y a d'ailleurs apparemment le même souci avec Gnome: il n'y a pas de véritable intégration dans Gnome, malgré l'utilisation de GTK dans la version linux de Firefox.

Le moteur CSS n'est pas un moteur de rendu graphique. Le moteur CSS parse le CSS et fait les calculs de propriétés CSS pour chaque élément, en appliquant toutes les règles des fichiers CSS qu'on lui donne.

Bref, il n'utilise pas le GPU.

Le nouveau moteur CSS de Firefox améliore les perfs, dans le sens où il parallélise au maximum les calculs de propriétés. Du coup, le thread principal est moins sollicité pour le CSS. Et c'est là où tu as raison : comme le JS est exécuté dans le thread principal, le JS profite de plus de temps d’exécution (en schématisant grandement).

Bien sûr que si.

Bien sûr que non.

Parce que sinon ça provoque des retards en chaîne. Si un train B doit attendre 10 minutes un train A en retard, ça voudrait dire alors qu'un train C pour la correspondance suivante, devra attendre 10 minutes aussi, et peut être bien plus parce que le train B peut avoir aussi des problèmes qui aggrave son retard. Etc..

À ton avis, combien de personnes seront en retard "parce qu'il faut attendre le train précédent" ? Au final tout le monde.

L'heure c'est l'heure, point.

D'autant plus qu'un train en retard, ne retarde pas seulement ses passagers, mais aussi tous les autres trains qui empruntent la même ligne (toute ou en partie). De par sa nature, la gestion d'un réseau ferré est complexe et les horaires doivent être respecter sinon c'est la catastrophe. Il y a quelques années, la SNCF avait décidé de faire des gros changements d'horaires. Il leur a fallu plusieurs mois de calcul pour établir ces nouveaux horaires sur la France entière.

Une petite idée sur la complexité des horaires : https://www.sciencesetavenir.fr/decryptage/comment-fixe-t-on-les-horaires-de-trains-en-france_36583

Bah c'est plus ou moins le cas : l'interface de Firefox c'est du XML, Javascript, CSS… ;-)

J'entends les remarques sur les actions obsolète, moi je trouve bien qu'on me dise les permissions demandées pour chaque extension. Avant, toute les extensions avaient accès à tout, sans dire ce qu'ils utilisent comme informations.

C'est normale, l'ancien système d'extension XUL n'avait pas de système de sandbox. Une extension n'était pas cloisonnée. En clair, elle faisait partie intégrante de l'interface de Firefox. Elle avait donc accès à tout Gecko, à toutes ces API haut niveau mais aussi bas niveau. Elle pouvait TOUT modifier : ajouter ce qu'elle voulait dans l'interface, où elle voulait, remplacer des composants techniques. Elle pouvait accéder au système, lancer des exécutables, accéder à n'importe quel fichier que l'utilisateur avait accès etc. Impossible donc pour Firefox d'établir une liste d'autorisation.

Il y avait une amélioration du système d'extension, Jetpack, où le code principal de l'extension était exécuté dans une sandbox, avec une API proposée qui faisait abstraction des composants internes de Firefox, mais il y avait quand même une porte de sortie pour accéder directement aux composants internes, donc continuer à faire ce qu'on voulait. L'avantage de jetpack est que cela permettait déjà d'identifier les problèmes des extensions, en terme de mémoire (celle de la sandbox). Et de préparer au nouveau système d'extension dans la logique (puisque la nouvelle API n'est plus du tout la même).

Bref, c'était génial pour un développeur, il n'y avait aucune limite. C'est grâce à ça qu'on a eu effectivement Firebug et bien d'autres extensions surpuissantes que l'on aura plus jamais dans un navigateur. Mais aussi grâce à cette liberté qu'on a eu des extensions qui faisaient de la m**de volontairement (genre celles qui installent des toolbars qu'on veut pas) ou non (codée avec les pieds, n'utilisait pas forcément les bonnes API ou encore faisait des trucs synchrones qui bloquait l'interface).

Le nouveau système est une vrai sandbox. Pas moyen de "s'échapper". On n'a que l'API qui est proposée dans la sandbox pour réaliser notre extension. Je crois même que l'extension est lancée dans son propre thread, (en tout cas, il y a la possibilité pour Firefox, c'est architecturé pour), et donc n'a pas d'impact directe sur l'interface principale (freeze &co).

Les utilisateurs vont y gagner en robustesse et en performance.

J'ai d'abord mis en place un système de callbacks. Le parsage était assuré par une fonction à laquelle je passais en paramètre, en plus du flux contenant les données à parser, une classe abstraite, dont une des méthodes virtuelles était appelée par le parser à chaque fois qu'il rencontrait un token, la méthode appelée dépendant de la nature du token rencontré.

C'est le même principe qu'un parser SAX. Tu aurais pu en utiliser un plutôt que de réinventer la roue ;-)

Un parser SAX ne fait pas d'appel récursif, et surtout, au final tu n'a pas de représentation en mémoire de la totalité du contenu JSON. Ton JSON peut faire 40To, avoir 15 millions de niveaux, ton occupation mémoire ne sera au maximum que celle de la plus "grosse" feuille (dans le cas de JSON donc, que la taille de la plus grosse valeur de type chaîne).

Bien sûr, si tu utilises un parser de type SAX pour tout charger en mémoire, autant utiliser un parser classique, puisqu'on se retrouve à avoir les mêmes problèmes.

Seulement le vendredi pour ce genre de "blagues". Parce qu'on sait que le vendredi (=trolldi), ce genre d'affirmation, "c'est pour rire" (aka white troll). Les autres jours, c'est forcément de la mauvaise foi ou une attaque délibérément hostile, (aka black troll) et ne fait rire que son auteur.

Je vais donner un cas très typique d'utilisation d'un fichier JSON avec un arbre très profond : Utiliser un fichier json pour encoder un arbre très profond, tout simplement.

Oui. Mais pour cela il faut :

• soit assez de mémoire pour que tout le contenu encodé (ou décodé pour les parseurs) tienne d'un seul tenant
• soit utiliser des encodeurs/parseurs qui au lieu de stocker le résultat final en mémoire, le fasse vers d'autres types de sorties (disques dur, flux réseaux …). C'est à ça que sert les parseurs SAX dans le monde XML (voir mon commentaire plus bas)

J'étais bien content que chromium et firefox étaient suffisamment bien fait pour s'en accommoder,

Non. Correction : tu étais bien content d'avoir suffisamment de mémoire (et de swap) pour pas que ça plante.

Que ce soit Chrome ou Firefox, quand y a plus de mémoire pour créer des noeuds DOM afin de représenter ton HTML à l'écran, et bien… il n'y a plus de mémoire. Et ça te pète à la figure ou ça t'affiche rien. point barre.

Quand on veut parser des JSON représentant un arbre de grande profondeur ou un grand volume de données, on ne veut, à priori, pas tout charger en mémoire, parce qu'on sait qu'à un moment ou à un autre, ça va aboutir à des problèmes de mémoire, quelque soit la manière dont on implémente le parseur (ou alors il s'agit probablement d'un autre souci d'organisation des données, comme évoqué plus haut).

Qu'on déteste XML ou pas, il faut savoir qu'on a très vite rencontré le même souci en XML. Quand on parse du XML, on ne veut pas toujours une représentation en mémoire du document complet (c'est à dire avoir un DOM). On veut simplement pouvoir lire le XML, pour en extraire des données (et pas forcément toutes) et faire des traitements ou les stocker quelque part, au fur et à mesure de la lecture du XML. En clair, avoir comme objectif technique, une occupation mémoire de complexité O(1).

C'est pourquoi il a été inventé le parser SAX, qui permet de lire le XML de manière séquentielle, et donc de traiter les données de manière séquentielle. C'est un parser "bas niveau", en ce sens qu'il ne fait pas de représentation mémoire de ce qu'il lit. Il détecte et renvoi juste chaque token du format. Une sorte de parser qui fait du streaming. À noter d'ailleurs que bon nombre de parser DOM se basent sur un parser SAX…

Bref, la plupart des parsers JSON auxquels tu penses sont des équivalents des parser DOM pour XML. Ils ne sont pas du tout mauvais. Ils ne sont juste pas adaptés à des cas d'utilisation comme le tient. Ce que tu voudrais c'est plutôt un parser JSON de plus bas niveau, comme les parsers SAX pour XML. Une petite recherche sur le web (ex: "SAX for JSON") te renverra quelques projets en ce sens ;-)

D'ailleurs y a des projets du même type pour YAML et certainement d'autres formats de données…

La plupart des arguments de ces sites ne valent pas grand choses, au niveau technique en tout cas. L'histoire des "mauvaises ondes", c'est du pur délire, et il a été démontré que la "nocivité" était moindre que celle du wifi ou encore de la TNT (voir par exemple le dossier de canardpc. C'est bizarre, ils ne demandent pas le retrait des antennes TNT… Si ces gens ne veulent pas de rayonnement électromagnétique, il faut qu'ils aillent vivre dans une grotte à l'abri du soleil, au fond d'un désert. Et sans électricité bien sûr.

Bref leurs discours est totalement décrédibilisé à mes yeux, à cause leurs argumentations techniques à deux balles qui n'ont aucun cohérence scientifique. Le reste de l'argumentation, plutôt politique on va dire, fait vraiment penser à des théories du complot.

un message minimal c'est

Tu oublie l'entête XML, la balise stream et tout ses namespaces. Et je ne parle pas du protocole de transport si on communique pas directement sur les ports XMPP (HTTP entre autre…)

Et donc non, ce n'est pas léger. Le XML n'est pas léger. Si c'était le cas, il n'y aurait pas eu d'autres formats créés pour les échanges de données, comme YAML ou JSON. Oui, XMPP c'est puissant, extensible etc. Mais cela a une contrepartie : ce n'est pas léger. Et ce sera toujours moins léger qu'un protocole proposant les mêmes fonctionnalités mais communiquant avec un format binaire.

IRC n'est peut être pas le bon exemple pour comparer. Alors prenons ICQ par exemple. Pour envoyer ton message d'exemple, avec un ICQ ça prend 32 octets + longueur du message (6) soit 38 octets. Avec XMPP, il faut 54 octets rien que pour ta balise message, sans compter l'en tête XML, la balise stream, les éventuels caractères blanc entre les balises etc.

je n'ai pas compris le rapport avec la XEP-0001 par contre

Elle définit que le schema XML du protocol, donc que celui-ci repose sur XML et pas sur autre chose à priori (à moins qu'il y ait une autre XEP qui propose une alternative à XML ?)

Léger

XMPP ? Léger ? Seriously ?

À moins que ça ait changé depuis la dernière fois (il y a longtemps) que je me suis renseigné, mais je me souviens de structures XML bien verbeuses (1) . Pour envoyer un simple message, le volume de XML est bien souvent plus grand que la taille du message en lui-même.

Rien avoir avec la réelle légèreté d'un protocole comme IRC.

Alors ok, je comprend bien les avantages de XML et je n'ai rien contre l'utilisation de XML, même pour XMPP, mais faut arrêter de dire que c'est léger. C'est probablement le protocole de messagerie le plus lourd en terme de bande passante.

[1] en fait, c'est toujours le cas, la XEP-0001 est toujours active…

-client mail lourd: qui utilise encore ça?

J'ai plusieurs boites mails chez différents fournisseurs, tant pour ma vie perso que pour ma vie pro. Je sais qu'il y a des fournisseurs qui proposent via leur client web d'accéder à différentes boites. Mais ce n'est pas pour moi. Je n'ai pas envie de donner tous mes logins/mots de toutes mes boites mails à un même prestataire.

Bref, j'utilise Thunderbird, et ça me va très bien. D'un coup d'oeil je vois les nouveaux messages de toutes les boites aux lettres (ce qui est fastidieux si je devais ouvrir un onglet pour chaque boite mail). Et je peux même consulter tout mes mails en offline :-p

Et il permet de consulter les newsgroup. Je ne vois pas pourquoi je m'en priverai, puisqu'il est déjà ouvert.

Pour le FTP, je suis bien obliger de l'utiliser, quand des hébergeurs ne proposent que ça pour accéder aux fichiers, en particulier pour les offres lowcost (et je n'ai pas toujours le choix des hébergeurs, quand c'est un choix du client/ami/association).

Bref, oui, il y en a qui utilisent encore des clients "lourds".

Et attention, tu vas pleurer : j'utilise toujours IRC (avec irssi). Et non, je n'utilise pas Slack et cie. Ce sont des applications web, donc soit disant "client legers", mais en fait, ça bouffe énormément de ressources (vu la tonne de JS, d'images et j'en passe). Les ressources prises par irssi sont ridicules à coté (et sans avoir tous les gadgets inutiles de Slack & co). On se demande alors qui est vraiment le "client lourd".

je soupçonne que le taux de foyer comptant un ordinateur à la maison soit en baisse

Peut être. Ou alors il y a de moins en moins de raison à renouveler le matériel, parce que la puissance des PC fait que ça tient la route plus longtemps, surtout avec le nombre grandissant d'appli qui migrent vers le web, et donc plus besoin de mettre à jour, d'avoir plus de puissance etc… Bref, le matos devient obsolète moins rapidement.

À mon avis de plus en plus de gens n'auront plus qu'une tablette à la maison.

Bof. Pour consulter, c'est bien. Pour faire d'autres taches comme rédiger des rapports, une lettre aux impôts ou autre, c'est vraiment pas pratique (et pourtant j'ai une tablette avec clavier).

Franchement, quel est l'intérêt aujourd'hui d'avoir un PC à la maison, hormis pour des tâches bien spécifiques ?

Demande par exemple à tous les étudiants. À tout ceux qui gèrent une association.

Maintenant, faudrait savoir ce que tu entends par "taches bien spécifiques". Parce qu'au final ton terme ça peut tout recouvrer.

Libre Office ? Pour modifier des PDF, c'est assez pratique. Je ne sais pas si la restitution est toujours fidèle mais pour des documents pas trop complexe, en tout cas, ça fonctionne. (pas testé avec des formulaires)

Je suis étonné des mauvaises notes de certains commentaires que je trouve pourtant pertinent, en l’occurrence ceux qui expliquent qu'une vraie sauvegarde, c'est une copie sur un disque différent, voir sur un disque distant etc..

Il est probable que ceux qui pensent qu'ils ont tord, ou qu'ils sont trop paranoïaques, n'ont jamais eu de problèmes serieux de pertes de données sur une machine, et n'ont jamais réfléchi à l'impact sur leur vie pro et/ou perso de la suppression de tels ou tels fichiers. Ils devraient donc s'en inquiéter, parce que la chance que ça arrive, augmente avec le temps, c'est statistique.

Et puis, même si il faut "calibrer" la solution de sauvegarde avec le degré de criticité des données, quand on perd des données non critiques, sans sauvegarde, cette perte reste quand même super chiante.

Perso, j'ai fait en sorte que je puisse être opérationnel (professionnellement) en moins d'une heure max après la récupération d'un laptop qui fonctionne (suite à un vol, au crash d'un disque, suppression involontaire de donnée). Ce temps correspond au temps d'installation d'une distro + configuration du système avec Ansible + restauration des données. Ce qui nécessite donc une sauvegarde distante et non locale.

Franchement, ça ne m'étonne pas d'Atos. Leur "kit" de paiement en ligne est un truc infame à intégrer dans une appli et à installer sur un serveur, qui date de plus de 16 ans. Oh il a certainement dû un peu évoluer, mais c'est une API toujours aussi dégueulasse : faut appeler un binaire avec 50 paramètres. Et croisez les doigts pour avoir un noyau compatible, et pas trop récent.
En tout cas, c'était encore cette situation il y a 1-3 ans (je sais plus) la dernière fois que j'ai regardé, et j'avais été moyennement surpris de constater que ça n'avait pas bougé depuis la dernière fois, en 2001-2002, où j'avais utilisé leur merde.

Le web a évolué, eux non. Et la doc est tout aussi immonde, avec des exemples de codes dignes de débutants.

Bref, un truc qu'ils doivent retoucher une fois tout les 5 ans. Alors oublier de renouveler un nom de domaine, c'est finalement "normal".

Et si vous pensez que je suis un peu dur : le nom de domaine a été renouvelé seulement pour un an. un an. Pour un truc quand même critique. Faut croire que le réserver pendant 5 ans, histoire d'être tranquille, c'était trop pour eux… Faut s'attendre à ce que ça pète à nouveau dans un an.

Ok, bon, on peut se dire, tous les ans, c'est bien, ça entretien "la pression", ça évite d'oublier qu'il y a un nom de domaine à renouveler. Ou pas.

Franchement, je ne vois aucun, mais alors aucun, intérêt de faire du C pour développer une interface graphique (et pourtant, j'en ai bouffé du C dans ma jeunesse).

Ou alors va falloir m'expliquer là…

C'est pas parce que Gnome est en C qu'il faut tout faire en C (d'ailleurs il y a de fortes chances que Gnome n'aurait pas été en C si le projet démarrait avec les technos d'aujourd'hui). On a aujourd'hui des langages bien plus efficace en terme de productivité, en terme de sécurité et de stabilité, avec lesquels donc on a moins à penser aux risques de buffer overflow, à la gestion de pointeurs, de leaks mémoire etc.

Le C, ça reste valable pour tout ce qui est programmation système très bas niveau. Et encore, avec des langages comme Rust, ça se discute de mon point de vue, si on veut un truc un minimum robuste sans décupler les temps de dev et de formation (parce que faire un truc potable en C nécessite quand même pas mal d’expérience pour pas tomber dans tous les pièges amenant à des trous de sécu, fuites mémoire et j'en passe).

Mais pour faire de la programmation dans les couches hautes, en particulier les interfaces, non. Faut arrêter là. À part quelques cas très spécifiques (par ex, faire une interface pour une machine embarquée très peu performante), je ne vois pas ce qu'apporterait un langage comme C. C'est comme si on demandait de creuser un trou avec un baton alors que depuis quelques temps on a inventé la pelle pour ça (et maitrisé la fabrication de l'acier), voir même les pelleteuses.

D'après le New York Times c'est plus subtile que ça : la plupart des documents sont des vrais, mais sans intérêts et ces boites étaient alimentées régulièrement (à partir de messages d'autres boites mails). Et le staff communiquait via ces autres boites mails ou d'autres systèmes.

C'est pour cela que la plupart des documents sont tout à fait crédibles, mais aussi tout à fait inutiles pour quelqu'un qui voudrait nuire.

Suffit d'aller lire ;-)

Notre objectif à long terme est de collecter tous les logiciels disponibles publiquement sous forme de code source, avec l’historique de leur développement, de les dupliquer massivement pour garantir leur préservation, et de les partager avec tous ceux qui en ont besoin.

Euh… je ne sais pas si tu as bien lu mon commentaire, mais on est d'accord hein…

Il y a juste le fait que l'utilisation de l'expression "navigateur n'y voit que du feu" n'est pas adéquate. Ça ne veut pas trop dire grand chose. Il me semble en effet qu'un navigateur n'est pas un être vivant, il n'a pas d'yeux, il ne voit pas, il se contente de traiter les données (certes, insuffisamment dans le cas présent). Bref, une histoire de français quoi.

Firefox et Chrome n'y voit que du feu

Non, ce ne sont pas les navigateurs qui n'y voient que du feu : ils ne font qu'afficher le nom de domaine et le certificat qui va avec.

C'est l'utilisateur qui n'y voit que du feu. Malheureusement.

Après faudrait que les navigateurs détectent ce genre de tromperies, afin d'en avertir l'utilisateur. Mais là ce n'est pas évident.

Notez qu'il restera une différence si le site d'origine a un certificat validé manuellement (Extended Validated Certificate), puisqu'alors le nom du propriétaire du site apparait à coté de l'URL. Et que pour avoir un EVC, il faut montrer patte blanche (en théorie, il faut fournir de la paperasse pour prouver que l'on possède le nom de domaine). Mais il restera des utilisateurs qui ne feront pas gaffe (surtout si ils ne sont jamais allés sur le vrai site).

Tizen, la moins pire des solutions ? t'es sûr ?

Tizen est définitivement hors concours pour moi. Je parierai plus sur Plasma mobile.