Depuis Firefox 57 Quantum (encore lui !), les installations par défaut de Firefox présentent une barre unifiée pour l'adresse et la recherche (cette présentation reste optionnelle pour les profils créés antérieurement).
Elle est optionnelle pour n'importe qui à priori. Il suffit de mettre la préférence "browser.search.widget.inNavBar" à true pour retrouver la séparation entre adresse et recherche.
Mais ma voiture semblait bouder certains morceaux, de manière reproductible, sans que je ne comprenne le problème : on entendait une saccade 3, 4, 10 fois sur certains fichiers
Est ce que lesdits morceaux ne dépasseraient-ils pas une certaine taille de fichiers ? Et est-ce que la coupure arrive à intervalle régulier ?
Je verrais bien la lecture interrompue par l'obligation de lire le fichier morceau par morceau quand le fichier ne tiens pas en entier dans un buffer, avec un code de gestion de ce buffer totalement merdique.
Pour moi, le RGPD, c'est de la poudre aux yeux et n'empêchera en rien la tracking publicitaire, la revente/vole d'information, le profiling… Enfin tout les trucs que nous subissons dès qu'on se connectent à Internet.
Certes, ça n'empeche pas, mais ça devient illégal si l'utilisateur n'a pas donné son consentement. Depuis quelques semaines je vois passer sur twitter des faire-parts de décès de startup dont le business plan reposait sur la revente des données personnelles.
Bref, il va y avoir un peu de ménage, et c'est pas plus mal.
Moi il m'en faut 5 à 10 de plus, le temps que mes scripts Ansible terminent d'installer les paquets nécessaires et de configurer le reste ;-) (Bien sûr, n'est pas compris là dedans le temps de reinstallation du $HOME qui serait nécessaire si ma partition home avait été flinguée).
Pas plus tard qu'hier, j'ai réinstallé mon laptop pro pour passer à kubuntu 18.04 : en 30 min j'étais opérationnel.
D'ailleurs, depuis que j'ai mes scripts Ansible, je ne m'embête plus à faire des upgrades de distro, ça prend moins de temps de tout reinstaller que de faire l'upgrade. Et ça permet de faire le ménage (genre les paquets que j'installe "pour voir" et que j'oublie de virer).
Nous expliquions déjà dans la nouvelle sur GEGL que le traitement en graphe signifie que le traitement d'image non-destructif sera bientôt possible.
Ouaaah. Ça fait des années que j'attends ça ! Je n'ai jamais compris pourquoi ça n'avait jamais été une priorité pour les développeurs de Gimp, alors que c'est ce genre de fonctionnalité manquante qui empêchent clairement de se passer de Photoshop.
Mozilla s’intéresse à l'internet. Voir ses combats sur la privacy, sur la neutralité du net etc..
Et Thunderbird continue a être maintenu. Une équipe a été reformée il y a quelques mois, avec des développeurs payés à plein temps. Voir mon message plus bas.
Tes problèmes de performances sont liés au fait que tu as énormément de message. Au premier chargement, vu le nombre de message, c'est quand même normal que ça prenne du temps. Et sachant que l'interface c'est du XUL (html++) + jS + CSS, ça peut effectivement freezer l'interface par moment.
La comparaison avec les web mail est complètement débile. Un web mail, ça ne charge que les entêtes de quelques messages. Et la recherche dans les messages est faite coté serveur, et qui peut prendre énormément de ressources mais tu ne le vois pas parce que tu n'as pas ces grosses boites grises très bruyantes et qui chauffent beaucoup sur ton bureau. Quand une recherche est faite dans Gmail, c'est un datacenter que tu fais travailler (attention, je ne dis pas que tu fais travailler TOUT le datacenter, mais que tu as à ta disposition la capacité de calcul d'un datacenter).
Thunderbird pourrait, certes, faire du lazy-loading pour afficher la liste de message, ce qui pourrait limiter les freezes au chargement complet d'un compte. Mais pour faire tout un tas d'opération, il doit tout de même télécharger au moins les entêtes de tes milliers de messages : il en a besoin par exemple quand tu veux trier tes messages selon le sujet, l'expediteur etc (en cliquant sur l'un des entêtes de colonne de la liste). Il a besoin aussi d'avoir la liste complète pour qu'il puisse effectuer des recherches, puisque il doit indexer les messages. Le protocole IMAP ne prevoit pas de fonction de recherche, celle-ci ne peut donc se faire coté serveur.
Après tu signales plein de problèmes de messages ou autre. Mais si tu as interrompu brutalement le processus de chargement (ou de suppression de messages etc) en tuant TB, faut pas t'étonner : les fichiers de la base de messages de TB ont certainement été mal fermé, ou partiellement enregistrés. Et donc index et fichiers corrompus… La seule solution simple dans ton cas, c'est de supprimer complètement ton profile (~/.thunderbird) et de reconfigurer ton compte, en étant patient pour le premier chargement.
J'utilise TB depuis de nombreuses années (pour le pro et le perso), et je gère une quinzaine de boites aux lettres, stockées chez différents hébergeurs, pour un total de 5 Go de messages. Je n'ai pratiquement jamais de problème. Sauf effectivement, j'ai eu des problèmes de freeze les quelques fois où j'ai dû recrée un profile et donc dû charger d'un coup mes milliers de messages. La recherche aussi n'est pas si terrible que ça.
Maintenant, par "hygiène" et par souci d'efficacité, je fais le ménage régulièrement dans les messages (suppression pure et simple ou déplacement dans une boite d'archives pour les plus vieux messages). Je classe aussi mes messages dans des sous-dossiers (merci Imap), ce qui évite qu'il y ait des milliers de messages dans un seul dossier. Cela limite donc les temps de chargements, quel que soit le client mail (TB, webmail ou autre) utilisés.
Alors, un point sur la technologie utilisée par Thunderbird.
Disclamer : j'ai longtemps contribué à Firefox, et j'ai, à titre professionnel, développé des extensions pour Thunderbird ou un client mail basé sur TB avec une interface différente.
Le coeur de Thunderbird, c'est le même que celui de Firefox : Gecko. Gecko est un moteur de rendu XML/XUL/HTML + JS + CSS. Il sert tout autant à afficher une interface utilisateur que du contenu web. L'interface utilisateur est donc programmée avec le langage XUL, qui est, si l'on peut dire, du HTML++++. Avec bien sûr du JS pour le comportement et du CSS pour le design.
Donc non, ça n'utilise pas la même UI, mais plutôt les mêmes technos.
Les composants IMAP, POP, SMTP et tout ce qui gère des boites mails, etc sont développés par contre en C++.
En ce qui concerne les threads : tout comme Firefox, l'UI fonctionne dans le thread principal, d'où effectivement des "freezes" si des composants liés à l'interface passent trop de temps à faire des choses. C'est le cas par exemple lorsqu'on configure un compte mail qui a déjà des giga octets de messages : il faut les charger (ça prend du temps, surtout si on a une connexion pourrie), et comme la liste des messages dans l'UI est mis à jour au fur et à mesure du chargement, ça peut effectivement freezer (malgré l'utilisation de techniques de traitements par lot pour éviter de rafraichir l'interface à chaque message chargé).
Dans Firefox, dans le passé, on avait aussi ce problème, en particulier lorsqu'un site faisait de la merde en JS. Mais maintenant que les onglets sont dans des process séparés, ce n'est plus le cas.
Et sinon la bonne nouvelle.
Une équipe de développeurs dédiés à Thunderbird a était recrée il y a quelques mois, et est chapeauté par la fondation Mozilla (et non la corpo, qui s'occupe de Firefox). Pour l'instant ils sont quelques uns dans l'équipe, mais ils sont en processus de recrutement.
Bref, le projet Thunderbird n'est plus abandonné par Mozilla. Les futures chantiers dans Thunderbird va être de refaire des composants comme le carnet d'adresse, d'améliorer l'interface, de faire du nettoyage dans le code, et bien d'autres choses, entre autre de refaire petit à petit l'interface en HTML. En effet, depuis qu'il n'y a plus le système d'extensions XUL dans Firefox, Mozilla est en train de "tuer" XUL et toutes les technos connexes dans Gecko. Par exemple, les "overlays xul" ont disparus, et ils sont en train de faire le ménage et de supprimer XBL, qui est l’ancêtre des web components (le shadow dom a été inventé chez Mozilla, et on l'utilise depuis 20 ans avec XBL ;-) ).
Cette disparition de XUL ne va pas se faire du jour au lendemain, ça va mettre quelques années. Mais les conséquences pour Thunderbird commencent dés maintenant à se faire sentir pour les développeurs. Il va falloir qu'ils suivent le rythme et remplacer l'utilisation des technos qui disparaissent par d'autres.
Non, c'est Linus Torvalds qui a créé git, le 3 avril 2005. Voici les premiers commits qui ont été créé dés qu'il a pu versionner les sources de git avec git, c'est à dire 4-5 jours après avoir débuter le développement de Git.
La première contribution a eu lieu au 49ieme commit, le 12 Avril. Le lendemain, Junio Hamano proposait lui aussi son premier patch. C'est le mainteneur officiel de Git. Quant à Shawn Pearce, il a commencé à contribuer en février 2006.
Suite à ton message, j'ai installé kdevelop et le plugin php fourni dans ma distrib (kubuntu) et voulu essayer de faire du debuggage de php, et je n'ai pas trouvé comment faire. le bouton debug de la barre d'outils me fait un message d'erreur comme quoi le debuggage est seulement supporté pour les applications python.
Il faut installer quelque chose de spécifique ? Comment fait-tu fonctionner xdebug dans kdevelop ?
Sauf si ladite adresse n'est utilisée que pour le site en question, je ne suis pas sûr qu'éviter de laisser une adresse mail sur un site va t'éviter du spam. Les spammeurs ont maintenant tellement d'autres moyens plus pratique de la récupérer (que d'avoir un crawler qui tourne h24), via des listings issue de leaks, de la revente de données entre boites etc…
Et puis de nos jours, les filtres anti-spam fonctionnent plutôt bien coté serveur. Si en plus on utilise un client mail desktop qui va affiner le filtrage comme Thunderbird… Perso, je gère une dizaine de boite mails dans Thunderbird, et je ne vois pratiquement plus de spam dans mes inbox (par contre mes dossiers spam sont bien remplis).
alors très rapidement tu va devoir gérer les mises à jour, la sécurité, les cassages non prévus, etc. toi-même.
Par défaut, Firefox et Thunderbird vanilla se mettent à jour automatiquement. Et pas besoin d'attendre que le paquet de la distro soit mis à jour par le mainteneur du paquet.
Tes arguments ne sont valables que pour les logiciels qui n'incluent pas de système de mise à jour, ou qui sont installés sans passer par un dépôt tiers.
Et pour les cassages, je ne vois pas en quoi un logiciel utilisateur va casser quoi que ce soit. Ok pour une lib vanilla ou un environnment comme KDE ou GNOME que l'on met à jour indépendement de la distro. Mais pour le reste… Comme je le disais dans un autre commentaire, chez moi le paquet libreoffice de la distro est instable, alors que le paquet vanilla fonctionne parfaitement.. Comme quoi..
Je confirme : le paquet Ubuntu de LibreOffice est un cauchemar. Chez moi, ça plante régulièrement, en particulier lors de la sauvegarde, ce qui rend le logiciel inutilisable. Et pourtant ça fait des années que c'est comme ça, parce que bien sûr, à chaque réinstall de mon système, je m'obstine à utiliser les paquets de la distrib. Du coup je me rabat toujours sur les paquets vanilla, et ça fonctionne correctement :)
D'ailleurs je fais de même pour Firefox (et Thunderbird). C'est peut-être la raison pour laquelle je n'ai jamais ces problèmes de lenteur ou de mémoire qu'observent les autres utilisateurs de Firefox.
Bref, je comprend moi aussi que les développeurs de certains logiciels ne veulent pas qu'on build un soft avec des modifications tout en gardant le nom protégé. Pour des logiciels complexes, changer de version de lib peut rendre le logiciel instable.
Maintenant il faut aussi que les développeurs upstream mettent un peu d'eau dans leur vin, en acceptant des patchs qui permettent de corriger des problèmes avec tel ou tel lib ou système. Ça ne peut qu'être bénéfique pour tout le monde.
Sans avoir beaucoup fouillé la doc, il semble que Wapiti se base sur un parser xml (ou html5) pour "naviguer" sur les pages.
Du coup, vu que de plus en plus de sites génèrent des pages (et donc des formulaires) de manière dynamique en JS, je ne vois pas comment Wapiti peut détecter des failles sur ces sites, puisqu'il n'execute pas le javascript. À moins qu'il y ait des modules proposant de surfer avec un navigateur headless (phantomjs, firefox --headless, ou via Selenium..) ?
Yep mais du coup tu ne vérifies pas ce que ton navigateur sert à ses clients. :)
s/navigateur/serveur je suppose ? ;-)
Certes, mais normalement, il n'y a qu'un fichier cert pour le domaine en question sur la machine. Si le serveur ne le trouve pas, il ne voudra pas démarrer, et la vérification par http ne garanti pas que le nouveau est bien pris en compte, sauf si tu mémorises via ton script le nombre de régénération effectuées et mis en place des alertes si ce nombre devient anormalement élevé sur une période de 90 jours.
Qui plus est, sur une infra digne de ce nom, tu as déjà des sondes qui vérifient tes services web, donc qui te remontent les problèmes de connexions foireuses causés par des certificats invalides ;-)
Sinon, dans la même logique, pas besoin de vérifier le fichier : il « suffit » d'exécuter certbot (ou un de ses amis) pour que le certificat soit à jour. :)
Quand tu héberges plusieurs domaines, ce n'est pas trop recommandé, d'une part parce que cela va provoquer des rechargements intempestifs de la config du serveur web, et d'autres parts parce que tu as des quotas au niveau de letsencrypt. Certes, ils sont assez élevés pour un usage normal, mais ce n'est pas une raison d'entamer ton quota et de participer un peu plus à la charge des serveurs letsencrypt (ne pas abuser d'un service gratuit permet de faire en sorte qu'il reste gratuit et qu'il ne réduise pas les quotas)
C'est valable si on n'a pas accès au serveur. Mais dans le cas présent, la vérification se fait sur le serveur qui stocke le certificat, donc plutôt que de faire une requête HTTP, autant lire directement le fichier du certificat, ça sera plus rapide
DOMAIN_CRT=/chemin/vers/fichier.crt
ENDDATE=$(openssl x509 -in $DOMAIN_CRT -noout -enddate | cut -d= -f2-)
DAYSREMAINING=$(( (`date -d "$ENDDATE" +%s` - `date -d "00:00" +%s`) / (24*3600) ))
if [ $DAYSREMAINING -lt 5 ]
then
# il reste moins de 5 jours, renouvelons
...
fi
Il n'utilise pas le client letsencrypt "officiel", mais acme_tiny, beaaaaaauuuucoup moins usine à gaz, et qui s'intègre plus facilement dans des infra configurées automatiquement.
Je ne sais pas si c'est toujours le cas, mais à l'époque où j'ai voulu utiliser le client letsencrypt officiel, celui-ci arrêtait complètement le serveur web, pour démarrer le sien, afin que les serveurs letsencrypt fasse leur vérification. Ce qui était absolument inacceptable pour l'infra que je configurais.
Avec des outils légers comme acme_tiny, il y a juste un alias .well-known à configurer dans le serveur web, et à faire un reload une fois le certificat regénéré. Et optionnellement à ajouter une petite vérification de la validité du certificat dans le script que tu installes en cron.
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)
# Séparer champs url et champs de recherche
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Optimiser la recherche Web dans Firefox. Évalué à 3.
Elle est optionnelle pour n'importe qui à priori. Il suffit de mettre la préférence "browser.search.widget.inNavBar" à true pour retrouver la séparation entre adresse et recherche.
[^] # Re: bobo tête
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche RGPD et logiciels libres pour accompagner les mises en conformité. Évalué à 3.
Tu es sûr ? parce qu'une bonne partie d'entre elles contiennent le nom, voir le prénom, et donc des informations personnelles…
# Histoire de buffer ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Défragmenter une partition FAT32 sous Linux …. Évalué à 4.
Est ce que lesdits morceaux ne dépasseraient-ils pas une certaine taille de fichiers ? Et est-ce que la coupure arrive à intervalle régulier ?
Je verrais bien la lecture interrompue par l'obligation de lire le fichier morceau par morceau quand le fichier ne tiens pas en entier dans un buffer, avec un code de gestion de ce buffer totalement merdique.
[^] # Re: bobo tête
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche RGPD et logiciels libres pour accompagner les mises en conformité. Évalué à 3.
Certes, ça n'empeche pas, mais ça devient illégal si l'utilisateur n'a pas donné son consentement. Depuis quelques semaines je vois passer sur twitter des faire-parts de décès de startup dont le business plan reposait sur la revente des données personnelles.
Bref, il va y avoir un peu de ménage, et c'est pas plus mal.
[^] # Re: Les données du /home sont souvent les moins protégées
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal [MaVie] La grosse gaffe du jour ..... Évalué à 2.
Moi il m'en faut 5 à 10 de plus, le temps que mes scripts Ansible terminent d'installer les paquets nécessaires et de configurer le reste ;-) (Bien sûr, n'est pas compris là dedans le temps de reinstallation du $HOME qui serait nécessaire si ma partition home avait été flinguée).
Pas plus tard qu'hier, j'ai réinstallé mon laptop pro pour passer à kubuntu 18.04 : en 30 min j'étais opérationnel.
D'ailleurs, depuis que j'ai mes scripts Ansible, je ne m'embête plus à faire des upgrades de distro, ça prend moins de temps de tout reinstaller que de faire l'upgrade. Et ça permet de faire le ménage (genre les paquets que j'installe "pour voir" et que j'oublie de virer).
# traitement d'image non-destructif
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10 roule au GEGL. Évalué à 4.
Ouaaah. Ça fait des années que j'attends ça ! Je n'ai jamais compris pourquoi ça n'avait jamais été une priorité pour les développeurs de Gimp, alors que c'est ce genre de fonctionnalité manquante qui empêchent clairement de se passer de Photoshop.
[^] # Re: Je comprends pas
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Thunderbird, mon premier contact est une déception !. Évalué à 6.
Mozilla s’intéresse à l'internet. Voir ses combats sur la privacy, sur la neutralité du net etc..
Et Thunderbird continue a être maintenu. Une équipe a été reformée il y a quelques mois, avec des développeurs payés à plein temps. Voir mon message plus bas.
# normal...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Thunderbird, mon premier contact est une déception !. Évalué à 10.
Tes problèmes de performances sont liés au fait que tu as énormément de message. Au premier chargement, vu le nombre de message, c'est quand même normal que ça prenne du temps. Et sachant que l'interface c'est du XUL (html++) + jS + CSS, ça peut effectivement freezer l'interface par moment.
La comparaison avec les web mail est complètement débile. Un web mail, ça ne charge que les entêtes de quelques messages. Et la recherche dans les messages est faite coté serveur, et qui peut prendre énormément de ressources mais tu ne le vois pas parce que tu n'as pas ces grosses boites grises très bruyantes et qui chauffent beaucoup sur ton bureau. Quand une recherche est faite dans Gmail, c'est un datacenter que tu fais travailler (attention, je ne dis pas que tu fais travailler TOUT le datacenter, mais que tu as à ta disposition la capacité de calcul d'un datacenter).
Thunderbird pourrait, certes, faire du lazy-loading pour afficher la liste de message, ce qui pourrait limiter les freezes au chargement complet d'un compte. Mais pour faire tout un tas d'opération, il doit tout de même télécharger au moins les entêtes de tes milliers de messages : il en a besoin par exemple quand tu veux trier tes messages selon le sujet, l'expediteur etc (en cliquant sur l'un des entêtes de colonne de la liste). Il a besoin aussi d'avoir la liste complète pour qu'il puisse effectuer des recherches, puisque il doit indexer les messages. Le protocole IMAP ne prevoit pas de fonction de recherche, celle-ci ne peut donc se faire coté serveur.
Après tu signales plein de problèmes de messages ou autre. Mais si tu as interrompu brutalement le processus de chargement (ou de suppression de messages etc) en tuant TB, faut pas t'étonner : les fichiers de la base de messages de TB ont certainement été mal fermé, ou partiellement enregistrés. Et donc index et fichiers corrompus… La seule solution simple dans ton cas, c'est de supprimer complètement ton profile (~/.thunderbird) et de reconfigurer ton compte, en étant patient pour le premier chargement.
J'utilise TB depuis de nombreuses années (pour le pro et le perso), et je gère une quinzaine de boites aux lettres, stockées chez différents hébergeurs, pour un total de 5 Go de messages. Je n'ai pratiquement jamais de problème. Sauf effectivement, j'ai eu des problèmes de freeze les quelques fois où j'ai dû recrée un profile et donc dû charger d'un coup mes milliers de messages. La recherche aussi n'est pas si terrible que ça.
Maintenant, par "hygiène" et par souci d'efficacité, je fais le ménage régulièrement dans les messages (suppression pure et simple ou déplacement dans une boite d'archives pour les plus vieux messages). Je classe aussi mes messages dans des sous-dossiers (merci Imap), ce qui évite qu'il y ait des milliers de messages dans un seul dossier. Cela limite donc les temps de chargements, quel que soit le client mail (TB, webmail ou autre) utilisés.
[^] # Re: Mes retours, un peu plus positifs
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Thunderbird, mon premier contact est une déception !. Évalué à 10.
Alors, un point sur la technologie utilisée par Thunderbird.
Disclamer : j'ai longtemps contribué à Firefox, et j'ai, à titre professionnel, développé des extensions pour Thunderbird ou un client mail basé sur TB avec une interface différente.
Le coeur de Thunderbird, c'est le même que celui de Firefox : Gecko. Gecko est un moteur de rendu XML/XUL/HTML + JS + CSS. Il sert tout autant à afficher une interface utilisateur que du contenu web. L'interface utilisateur est donc programmée avec le langage XUL, qui est, si l'on peut dire, du HTML++++. Avec bien sûr du JS pour le comportement et du CSS pour le design.
Donc non, ça n'utilise pas la même UI, mais plutôt les mêmes technos.
Les composants IMAP, POP, SMTP et tout ce qui gère des boites mails, etc sont développés par contre en C++.
En ce qui concerne les threads : tout comme Firefox, l'UI fonctionne dans le thread principal, d'où effectivement des "freezes" si des composants liés à l'interface passent trop de temps à faire des choses. C'est le cas par exemple lorsqu'on configure un compte mail qui a déjà des giga octets de messages : il faut les charger (ça prend du temps, surtout si on a une connexion pourrie), et comme la liste des messages dans l'UI est mis à jour au fur et à mesure du chargement, ça peut effectivement freezer (malgré l'utilisation de techniques de traitements par lot pour éviter de rafraichir l'interface à chaque message chargé).
Dans Firefox, dans le passé, on avait aussi ce problème, en particulier lorsqu'un site faisait de la merde en JS. Mais maintenant que les onglets sont dans des process séparés, ce n'est plus le cas.
Et sinon la bonne nouvelle.
Une équipe de développeurs dédiés à Thunderbird a était recrée il y a quelques mois, et est chapeauté par la fondation Mozilla (et non la corpo, qui s'occupe de Firefox). Pour l'instant ils sont quelques uns dans l'équipe, mais ils sont en processus de recrutement.
Bref, le projet Thunderbird n'est plus abandonné par Mozilla. Les futures chantiers dans Thunderbird va être de refaire des composants comme le carnet d'adresse, d'améliorer l'interface, de faire du nettoyage dans le code, et bien d'autres choses, entre autre de refaire petit à petit l'interface en HTML. En effet, depuis qu'il n'y a plus le système d'extensions XUL dans Firefox, Mozilla est en train de "tuer" XUL et toutes les technos connexes dans Gecko. Par exemple, les "overlays xul" ont disparus, et ils sont en train de faire le ménage et de supprimer XBL, qui est l’ancêtre des web components (le shadow dom a été inventé chez Mozilla, et on l'utilise depuis 20 ans avec XBL ;-) ).
Cette disparition de XUL ne va pas se faire du jour au lendemain, ça va mettre quelques années. Mais les conséquences pour Thunderbird commencent dés maintenant à se faire sentir pour les développeurs. Il va falloir qu'ils suivent le rythme et remplacer l'utilisation des technos qui disparaissent par d'autres.
Ça bouge donc du coté de Thunderbird ! \o/
[^] # Re: Célébrité anonyme.
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche La communauté Git en deuil de Shawn Pearce. Évalué à 10.
Non, c'est Linus Torvalds qui a créé git, le 3 avril 2005. Voici les premiers commits qui ont été créé dés qu'il a pu versionner les sources de git avec git, c'est à dire 4-5 jours après avoir débuter le développement de Git.
La première contribution a eu lieu au 49ieme commit, le 12 Avril. Le lendemain, Junio Hamano proposait lui aussi son premier patch. C'est le mainteneur officiel de Git. Quant à Shawn Pearce, il a commencé à contribuer en février 2006.
[^] # Re: Kdevelop
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Quel IDE pour quel langage. Évalué à 3.
Suite à ton message, j'ai installé kdevelop et le plugin php fourni dans ma distrib (kubuntu) et voulu essayer de faire du debuggage de php, et je n'ai pas trouvé comment faire. le bouton debug de la barre d'outils me fait un message d'erreur comme quoi le debuggage est seulement supporté pour les applications python.
Il faut installer quelque chose de spécifique ? Comment fait-tu fonctionner xdebug dans kdevelop ?
[^] # Re: Vous reprendrez bien un peu de spam ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Framasoft annonce la sortie de Framasite. Évalué à 3.
Sauf si ladite adresse n'est utilisée que pour le site en question, je ne suis pas sûr qu'éviter de laisser une adresse mail sur un site va t'éviter du spam. Les spammeurs ont maintenant tellement d'autres moyens plus pratique de la récupérer (que d'avoir un crawler qui tourne h24), via des listings issue de leaks, de la revente de données entre boites etc…
Et puis de nos jours, les filtres anti-spam fonctionnent plutôt bien coté serveur. Si en plus on utilise un client mail desktop qui va affiner le filtrage comme Thunderbird… Perso, je gère une dizaine de boite mails dans Thunderbird, et je ne vois pratiquement plus de spam dans mes inbox (par contre mes dossiers spam sont bien remplis).
[^] # Re: Impolitesse ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Petit guide à l'usage des développeurs de LL qui souhaitent se tirer dans le pied. Évalué à 2.
Par défaut, Firefox et Thunderbird vanilla se mettent à jour automatiquement. Et pas besoin d'attendre que le paquet de la distro soit mis à jour par le mainteneur du paquet.
Tes arguments ne sont valables que pour les logiciels qui n'incluent pas de système de mise à jour, ou qui sont installés sans passer par un dépôt tiers.
Et pour les cassages, je ne vois pas en quoi un logiciel utilisateur va casser quoi que ce soit. Ok pour une lib vanilla ou un environnment comme KDE ou GNOME que l'on met à jour indépendement de la distro. Mais pour le reste… Comme je le disais dans un autre commentaire, chez moi le paquet libreoffice de la distro est instable, alors que le paquet vanilla fonctionne parfaitement.. Comme quoi..
[^] # Re: Impolitesse ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Petit guide à l'usage des développeurs de LL qui souhaitent se tirer dans le pied. Évalué à 2.
Il est vrai que je suis sous Kubuntu.
[^] # Re: Impolitesse ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Petit guide à l'usage des développeurs de LL qui souhaitent se tirer dans le pied. Évalué à 5. Dernière modification le 14 février 2018 à 10:38.
Je confirme : le paquet Ubuntu de LibreOffice est un cauchemar. Chez moi, ça plante régulièrement, en particulier lors de la sauvegarde, ce qui rend le logiciel inutilisable. Et pourtant ça fait des années que c'est comme ça, parce que bien sûr, à chaque réinstall de mon système, je m'obstine à utiliser les paquets de la distrib. Du coup je me rabat toujours sur les paquets vanilla, et ça fonctionne correctement :)
D'ailleurs je fais de même pour Firefox (et Thunderbird). C'est peut-être la raison pour laquelle je n'ai jamais ces problèmes de lenteur ou de mémoire qu'observent les autres utilisateurs de Firefox.
Bref, je comprend moi aussi que les développeurs de certains logiciels ne veulent pas qu'on build un soft avec des modifications tout en gardant le nom protégé. Pour des logiciels complexes, changer de version de lib peut rendre le logiciel instable.
Maintenant il faut aussi que les développeurs upstream mettent un peu d'eau dans leur vin, en acceptant des patchs qui permettent de corriger des problèmes avec tel ou tel lib ou système. Ça ne peut qu'être bénéfique pour tout le monde.
# Scanner "statique" : intérêt limité ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Wapiti 3.0.0 : Nouvelle version du scanneur de vulnérabilités Web. Évalué à 2. Dernière modification le 16 janvier 2018 à 13:23.
Sans avoir beaucoup fouillé la doc, il semble que Wapiti se base sur un parser xml (ou html5) pour "naviguer" sur les pages.
Du coup, vu que de plus en plus de sites génèrent des pages (et donc des formulaires) de manière dynamique en JS, je ne vois pas comment Wapiti peut détecter des failles sur ces sites, puisqu'il n'execute pas le javascript. À moins qu'il y ait des modules proposant de surfer avec un navigateur headless (phantomjs, firefox --headless, ou via Selenium..) ?
[^] # Re: Probablement pas mieux mais très répendu
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Vérification des certificats X.509 sur le point d'expirer. Évalué à 1.
s/navigateur/serveur je suppose ? ;-)
Certes, mais normalement, il n'y a qu'un fichier cert pour le domaine en question sur la machine. Si le serveur ne le trouve pas, il ne voudra pas démarrer, et la vérification par http ne garanti pas que le nouveau est bien pris en compte, sauf si tu mémorises via ton script le nombre de régénération effectuées et mis en place des alertes si ce nombre devient anormalement élevé sur une période de 90 jours.
Qui plus est, sur une infra digne de ce nom, tu as déjà des sondes qui vérifient tes services web, donc qui te remontent les problèmes de connexions foireuses causés par des certificats invalides ;-)
Quand tu héberges plusieurs domaines, ce n'est pas trop recommandé, d'une part parce que cela va provoquer des rechargements intempestifs de la config du serveur web, et d'autres parts parce que tu as des quotas au niveau de letsencrypt. Certes, ils sont assez élevés pour un usage normal, mais ce n'est pas une raison d'entamer ton quota et de participer un peu plus à la charge des serveurs letsencrypt (ne pas abuser d'un service gratuit permet de faire en sorte qu'il reste gratuit et qu'il ne réduise pas les quotas)
[^] # Re: Probablement pas mieux mais très répendu
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Vérification des certificats X.509 sur le point d'expirer. Évalué à 3.
C'est valable si on n'a pas accès au serveur. Mais dans le cas présent, la vérification se fait sur le serveur qui stocke le certificat, donc plutôt que de faire une requête HTTP, autant lire directement le fichier du certificat, ça sera plus rapide
[^] # Re: Rien à faire
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Vérification des certificats X.509 sur le point d'expirer. Évalué à 3.
Il n'utilise pas le client letsencrypt "officiel", mais acme_tiny, beaaaaaauuuucoup moins usine à gaz, et qui s'intègre plus facilement dans des infra configurées automatiquement.
Je ne sais pas si c'est toujours le cas, mais à l'époque où j'ai voulu utiliser le client letsencrypt officiel, celui-ci arrêtait complètement le serveur web, pour démarrer le sien, afin que les serveurs letsencrypt fasse leur vérification. Ce qui était absolument inacceptable pour l'infra que je configurais.
Avec des outils légers comme acme_tiny, il y a juste un alias .well-known à configurer dans le serveur web, et à faire un reload une fois le certificat regénéré. Et optionnellement à ajouter une petite vérification de la validité du certificat dans le script que tu installes en cron.
[^] # 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.