Ne pas oublier que la majeure partie de la mémoire occupée par un navigateur, est utilisée par… les sites webs. Si un site web charge 10Mo de scripts JS qui font des allocations mémoires dans tous les sens, ou qui génèrent des dizaines de milliers d’éléments HTML (ce qui arrive très très vite quand on consulte des files de messages comme un mur facebook ou sa page twitter), forcément, au bout d'un moment, une page web peut prendre plusieurs dizaines, voir centaines de Mo.
Chez moi par exemple, au chargement de ma page twitter (116 requêtes et 8Mo de fichiers chargés !), le JS prend 34 Mo en mémoire (donné par l'onglet mémoire des devtools). Avec les objets DOM, la mémoire graphique du rendu graphique et tout ce qui est lié à la page web, la page prend au moins 139 Mo ! (chiffre donné par le about:memory). Si je commence à scroller, le total monte vite.
Pour la page de l'agenda google, c'est 77 requêtes pour 4.3 Mo de fichiers chargés, totalisant 45 Mo d'occupation mémoire par le JS et 61 Mo au total .
Multipliez ça par le nombre d'onglets…
Sans parler de la mise en cache des différents éléments. Chaque navigateur a sa propre stratégie de mise en cache, qui peut occuper pas mal de mémoire, en particulier pour accélérer les actions de navigations retour/avance. Et la mise en cache peut se paramétrer dans les préférences.
Allez jeter un coup d'oeil au about:memory, ça vaut le coup.
Intéressant ton script. On pourrait je pense l'améliorer.
Prochaines étapes :
générer une page HTML au lieu d'un PDF.
rajouter quelques scripts avec Django pour que chacun puisse ajouter sa propre trombine
Rajouter un système de commentaires pour chaque trombine..
Puis trouver un nom au site, du genre… euh… "Livre de visages" ?
Non pas assez vendeur…
En anglais, voyons… "Book of Faces" ?
Non trop long.. Ah tient, "FaceBook" !
À part la trahison de son oncle, Ben n'a pas grand chose pour expliquer son attirance.
Bah quand même : il semble avoir grandit loin de ses parents et cela l'a manifestement perturbé. Résultat il a une rancœur envers eux. Il ne veut donc pas leur ressembler, devenir comme eux. Il veut se montrer à lui-même qu'il peut faire "beaucoup mieux", avec donc, et on l'apprend maintenant, avoir le pouvoir ultime. Il a eu cette opportunité d'être pris sous l'aile de Snoke, qui l'encourage dans une voie : "Enfin un qui le comprend". Son père tente de le raisonner. Il le tue. Il est à deux doigts de tuer sa mère. Il finit par comprendre qu'il n'est qu'une marionnette de Snoke : il le tue.
Bref, pour moi, il y a suffisamment de raisons et de circonstances pour expliquer ses gestes, ses actes et son attirance pour le coté obscure. Il a peut-être moins de raison qu'Anakin pour basculer du coté obscure, mais ça reste suffisamment plausible. Je dirais même qu'il y a plus de subtilités psychologiques dans l'histoire de Ben, ce qui rend son histoire moins évident à comprendre. Ceci expliquant cela.
Et je trouve que l'acteur a très bien joué ce personnage. On voit que le personnage a gagné en maturité par rapport à l'épisode précédent (peut-être que l'acteur s'est amélioré également ?), il fait bien ressentir cette lutte contre le coté clair, contre tout idées qui l’empêcheraient d'atteindre son objectif, qui était finalement à porter de main.
Après avoir lu cette phrase, je me suis dis, chouette, il va proposer un truc plus simple à déployer, et utilisable partout ?
J'ai déchanté quand j'ai lu "écrite en C" puis je me suis effondré quand je suis aller voir les sources : il faut aller chercher plusieurs libs dépendantes à droite et à gauche, lancer les compilations une à une.. Il n'y a même pas un beau makefile qui te fasse tout ça sans effort. Et je n'ai pas vu de paquets debian (ou pour une autre distro) quelque part.
Très sérieusement, ton idée de projet fait vraiment envie, parce qu'on manque de solutions de ce genre, et il a l'air bien architecturé (chiffrage coté client etc). Mais l'avoir fait en C, c'est juste un barrière énorme de mon point de vue, à la diffusion et aux contributions. Laissons le C aux applications systèmes, merci, et faisons des applications web avec des technologies faites pour ça. (Tu aurais fait ça en Rust encore, j'aurais été plus indulgent…).
Et cela nécessite d'avoir un serveur dédié. Ça ne cible que les geeks qui ont les moyens donc. Dommage.
Il fonctionne très bien sous KDE. Mais il n'est pas vraiment intégré.
L'intégration dans un environnement de bureau consiste à utiliser les fonctionnalités de ce bureau. Quelques exemples :
le plus évident : reprendre le thème et l'aspect graphique. Facile si l'application utilise le toolkit QT pour son interface.
Utilisation des boites de dialogues natives pour l'ouverture/l'enregistrement des fichiers (dans Firefox, tu verras celles fournies par GTK ou une "faite maison", même si tu es sous KDE).
Idem pour les boites de dialogues d'impression, pour la configuration réseau..
utilisation du coffre fort des mots de passe du bureau pour le stockage des mots de passe (kwallet pour KDE)
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).
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.
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.
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 ?)
À 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.
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.
[^] # Re: Firefox sur AMD 3000+
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Fini Firefox, vive Midori !. Évalué à 7.
Ne pas oublier que les sites web aussi ! Et ça, les navigateurs n'y peuvent pas grand chose…
Utiliser un bloqueur de pub/tracker aide à limiter grandement les ressources utilisées.
[^] # Re: Qupzilla, Midori, Opera
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Fini Firefox, vive Midori !. Évalué à 10.
Ne pas oublier que la majeure partie de la mémoire occupée par un navigateur, est utilisée par… les sites webs. Si un site web charge 10Mo de scripts JS qui font des allocations mémoires dans tous les sens, ou qui génèrent des dizaines de milliers d’éléments HTML (ce qui arrive très très vite quand on consulte des files de messages comme un mur facebook ou sa page twitter), forcément, au bout d'un moment, une page web peut prendre plusieurs dizaines, voir centaines de Mo.
Chez moi par exemple, au chargement de ma page twitter (116 requêtes et 8Mo de fichiers chargés !), le JS prend 34 Mo en mémoire (donné par l'onglet mémoire des devtools). Avec les objets DOM, la mémoire graphique du rendu graphique et tout ce qui est lié à la page web, la page prend au moins 139 Mo ! (chiffre donné par le about:memory). Si je commence à scroller, le total monte vite.
Pour la page de l'agenda google, c'est 77 requêtes pour 4.3 Mo de fichiers chargés, totalisant 45 Mo d'occupation mémoire par le JS et 61 Mo au total .
Multipliez ça par le nombre d'onglets…
Sans parler de la mise en cache des différents éléments. Chaque navigateur a sa propre stratégie de mise en cache, qui peut occuper pas mal de mémoire, en particulier pour accélérer les actions de navigations retour/avance. Et la mise en cache peut se paramétrer dans les préférences.
Allez jeter un coup d'oeil au about:memory, ça vaut le coup.
# Page web
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal [pub] trombilinux : un script python pour créer des trombinoscopes. Évalué à 2.
Intéressant ton script. On pourrait je pense l'améliorer.
Prochaines étapes :
Puis trouver un nom au site, du genre… euh… "Livre de visages" ?
Non pas assez vendeur…
En anglais, voyons… "Book of Faces" ?
Non trop long.. Ah tient, "FaceBook" !
Oh ! Wait…
[^] # Re: Stars Wars, yeux d'enfants, yeux d'adultes
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Parlons un peu de Star Wars VIII - Les derniers Jedi (Attention : SPOILERS). Évalué à 3.
Bah quand même : il semble avoir grandit loin de ses parents et cela l'a manifestement perturbé. Résultat il a une rancœur envers eux. Il ne veut donc pas leur ressembler, devenir comme eux. Il veut se montrer à lui-même qu'il peut faire "beaucoup mieux", avec donc, et on l'apprend maintenant, avoir le pouvoir ultime. Il a eu cette opportunité d'être pris sous l'aile de Snoke, qui l'encourage dans une voie : "Enfin un qui le comprend". Son père tente de le raisonner. Il le tue. Il est à deux doigts de tuer sa mère. Il finit par comprendre qu'il n'est qu'une marionnette de Snoke : il le tue.
Bref, pour moi, il y a suffisamment de raisons et de circonstances pour expliquer ses gestes, ses actes et son attirance pour le coté obscure. Il a peut-être moins de raison qu'Anakin pour basculer du coté obscure, mais ça reste suffisamment plausible. Je dirais même qu'il y a plus de subtilités psychologiques dans l'histoire de Ben, ce qui rend son histoire moins évident à comprendre. Ceci expliquant cela.
Et je trouve que l'acteur a très bien joué ce personnage. On voit que le personnage a gagné en maturité par rapport à l'épisode précédent (peut-être que l'acteur s'est amélioré également ?), il fait bien ressentir cette lutte contre le coté clair, contre tout idées qui l’empêcheraient d'atteindre son objectif, qui était finalement à porter de main.
# En C quoi...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Hutch, gestionnaire de mots de passe. Évalué à 5.
Après avoir lu cette phrase, je me suis dis, chouette, il va proposer un truc plus simple à déployer, et utilisable partout ?
J'ai déchanté quand j'ai lu "écrite en C" puis je me suis effondré quand je suis aller voir les sources : il faut aller chercher plusieurs libs dépendantes à droite et à gauche, lancer les compilations une à une.. Il n'y a même pas un beau makefile qui te fasse tout ça sans effort. Et je n'ai pas vu de paquets debian (ou pour une autre distro) quelque part.
Très sérieusement, ton idée de projet fait vraiment envie, parce qu'on manque de solutions de ce genre, et il a l'air bien architecturé (chiffrage coté client etc). Mais l'avoir fait en C, c'est juste un barrière énorme de mon point de vue, à la diffusion et aux contributions. Laissons le C aux applications systèmes, merci, et faisons des applications web avec des technologies faites pour ça. (Tu aurais fait ça en Rust encore, j'aurais été plus indulgent…).
Et cela nécessite d'avoir un serveur dédié. Ça ne cible que les geeks qui ont les moyens donc. Dommage.
[^] # Re: un moteur de supercar dans une 4L en route pour la casse
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Un nouveau moteur de rendu ultra‐rapide pour Firefox : Quantum Render. Évalué à 4. Dernière modification le 07 décembre 2017 à 10:12.
Il fonctionne très bien sous KDE. Mais il n'est pas vraiment intégré.
L'intégration dans un environnement de bureau consiste à utiliser les fonctionnalités de ce bureau. Quelques exemples :
Et d'autres choses que je n'ai pas en tête.
[^] # Re: un moteur de supercar dans une 4L en route pour la casse
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Un nouveau moteur de rendu ultra‐rapide pour Firefox : Quantum Render. Évalué à 5.
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.
[^] # Re: Ca change !
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Un nouveau moteur de rendu ultra‐rapide pour Firefox : Quantum Render. Évalué à 4.
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).
[^] # Re: Aigreur, quand tu nous tiens
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal ils l'ont voulu, ils l'ont obtenu, et ils l'ont dans le baba.... Évalué à 3.
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
[^] # Re: Conclusion vendredesque
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Un nouveau moteur de rendu ultra‐rapide pour Firefox : Quantum Render. Évalué à 4.
Bah c'est plus ou moins le cas : l'interface de Firefox c'est du XML, Javascript, CSS… ;-)
[^] # Re: Extensions
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Le Firefox nouveau est arrivé !. Évalué à 10.
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.
[^] # Re: O Fortuna !
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 3.
C'est le même principe qu'un parser SAX. Tu aurais pu en utiliser un plutôt que de réinventer la roue ;-)
[^] # Re: Non, ils ne sont pas mauvais
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 4.
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.
[^] # Re: 5G pour 3.7G ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Installer Debian 9.2.1 Stretch depuis le disque dur avec une image ISO et GRUB2, sans clé USB ni DVD. Évalué à 3.
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.
[^] # Re: Intérêt ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 6.
Oui. Mais pour cela il faut :
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.
# Non, ils ne sont pas mauvais
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 10.
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…
[^] # Re: Linky : le truc qu’on essaie d’imposer dans tous les foyers.
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Dérive du tout connecté. Évalué à 7.
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.
[^] # Re: Léger ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi Jabber n'a pas plus de succès, même chez les informaticiens?. Évalué à 2.
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.
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 ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Pourquoi Jabber n'a pas plus de succès, même chez les informaticiens?. Évalué à 0.
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…
[^] # Re: Hou là, ça ne nous rajeunit pas...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche CD amorçable GNUSTEP 2.5.1 (AMD64) et 2.6 (Raspberry Pi). Évalué à 9.
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".
[^] # Re: Linux monte ou le bureau baisse?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 3% d'ordinateurs personnels sous Linux. Évalué à 3.
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.
[^] # Re: Linux monte ou le bureau baisse?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 3% d'ordinateurs personnels sous Linux. Évalué à 4.
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).
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.
[^] # Re: Formulaire
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Un nouveau visualiseur de PDF sous Linux. Évalué à 3.
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)
# Sauvegarde, oui, durable, non
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 2.
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.
# Des branquignoles
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Panne du système 3D Secure… pour cause de non renouvellement de nom de domaine. Évalué à 10.
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.