Quand même il ne faut pas confondre HTML et liens.
C'est quand même devenu assez standard de détecter les liens dans du texte et de les rendre cliquable.
Que ce soit avec des logiciels de chat, ou des clients mail textuels, où même la console texte de ton Linux préféré, et j'en passe, on n'a vraiment pas besoin de gérer les mails en HTML pour avoir des liens sur lesquels il suffit de cliquer comme partout ailleurs.
Le mail en HTML n'apporte pas les liens, ni les liens cliquables, mais tout le reste : les CSS, les ressources externes, les rendus foireux, etc.
Sylpheed ou claws-mail, sont des clients mails très efficaces mais qui de base ne font que du texte.
J'utilise personnellement Sylpheed, et je ne parlerai pas des différences avec Claws.
Si tu reçois un mail en HTML pur, il est transformé en texte, parfois avec plus ou moins de succès, mais en général c'est lisible sauf pour les publipostages bien pourris.
De toute façon Sylpheed n'affiche que du texte.
Les liens sont correctement pris en compte et cliquable, que le mail soit texte ou qu'on ait une balise A du HTML (dans ce cas il affiche bien le contenu de la balise, et on clique vers son HREF, comme un lien classique).
Ensuite on peut voir la liste des pièces jointes, et les mails texte et HTML sont présentées comme des pièces jointes particulières, donc si tu as un mail avec les deux versions, tu peux afficher l'une ou l'autre (et parfois avoir dans la version texte : ton client gère pas le HTML, dégage s'il-te-plaît).
Mais aussi, comme avec n'importe quelle pièce jointe, tu peux l'ouvrir dans un outil externe, et donc ouvrir ton mail en HTML dans un vrai navigateur web, si vraiment tu en as besoin.
Dans la très grande majorité des cas, tout fonctionne au poil. Les seuls mails posant des soucis étant les publipostage souvent très surchargés en HTML, et régulièrement sans version texte associée (aaah, les promos GoG…). Ou les mails pro à la con genre réunion Teams, ou ticket Jira, qui sont aussi assez généralement mal foutus (mais lisible, en général on voit bien les liens, et on peut cliquer sur le truc important sans lire le contenu généré et inutile)…
Et au final, vivre dans un monde où ton client mail ne gère pas plus le HTML que ça, bah ça marche pas mal. C'est toujours rapide parce qu'il n'y a jamais de rendu web, et donc les ressources externes (un des vrais drames des mails en HTML), bah il ne cherche même pas à savoir, ça ne sert à rien.
En ce qui concerne la réponse en haut ou en bas, franchement ça dépend.
Si c'est une conversation standard en texte, en général je simplifie le message reçu en ne gardant que ce à quoi je réponds, et je poste en dessous, mais ce sont des efforts, il faut que la conversation mérite toute cette attention.
S'il s'agit d'une discussion de groupe où tout le monde réponds au dessus, je fais comme tout le monde et je réponds au dessus.
Et si c'est une réponse express, je réponds en dessous sans dire bonjour ni rien en mode Crocker.
Bref, c'est pas si difficile le mail en texte, mais je conseille d'utiliser un outil qui ne fait que ça.
Je trouve le côté bâtard de Thunderbird assez pénible, et lourd, quand on l'utilise en mode pur texte et pas HTML (bâtard parce qu'on utilise un outil pensé pour rendre du HTML mais en fallback texte).
À voir ce que donne l'expérience Allemande : 9€ par mois pour un accès illimité au réseau ferroviaire.
C'est pas gratuit, ça peut suffire ?
Là ils ont des soucis parce que l'offre a trop de succès, donc les train sont surchargés, mais c'est lié à un changement majeur dans l'usage des transports en commun, ça devrait se tasser en quelques années.
Faut pas se leurrer, ça sera pas mieux en France si on a une offre dans le même genre.
Mais ce n'est pas grave, ça devrait malgré tout avoir un impact immédiat - en négatif, donc positif ;) - sur l'utilisation de la voiture ! Donc aussi de dépendance aux importations de pétrole.
C'est une question de choix politique, d'avenir de notre pays.
Voiture neuve à 10k€, déjà 150kkm, ça fait 1€ pour 15km.
Je compte bien réussir à l'amener à 300kkm, mais on n'en est pas là. Elle date de 2012 donc 10 ans d'âge.
Consommation : 5,5l/100km, diesel, en ce moment à 1,8€/l.
Assurance : 450€/an, on va faire une règle de trois pour ramener le tarif actuel au kilométrage moyen annuel sur 10 ans, on a 1€ pour 33km, disons 30km.
Le trajet en question fait 60km, donc :
- 4€ de voiture neuve.
- 2€ d'assurance.
- 3,3l ~ 6€ d'essence.
Donc 12€ hors entretient (là c'est plus difficile à calculer, j'ai pas trop d'idée).
On pourrait rajouter 5€ d'autoroute en prenant l'autoroute, qui fait gagner 10 minutes, n'évite pas les embouteillages, fait plus de km, donc coûte plus cher, j'évite en général.
Bref, ça nous fait le prix du billet de train à 11€50.
Sachant qu'il faut rejoindre la gare avant de prendre le train, 15km. Vélo (c'est pas plat du tout), voiture, stop, covoiturage ? La plupart ont un coût…
Alors, on est d'accord que sur le pur trajet du train en lui-même, le train est moins cher que de prendre la voiture, mais je me place justement dans le cas dont je parle plus haut, à savoir pas de transports en communs efficaces pour rejoindre la gare la plus proche.
Si le trajet est régulier, il y a des abonnements, c'est rentable, mais justement, si le trajet est irrégulier, l'abonnement ne vaut pas le coût.
C'est un simple exemple, qui ne vaut pas généralité, mais on est ici face à une situation de défaut majeur des transports en communs :(
Heureusement ce n'est pas non plus partout pareil.
L'intermédiaire se développe, avec le covoiturage surtout.
Pas assez vite, pas assez bien.
Dans mon coin, prendre le train pour aller à la grande ville d'à-côté, c'est plus cher que de prendre la voiture seul, et les gares sont toutes sur l'axe entre deux grandes villes, mais dès que tu t'éloignes, c'est mort : tu as au mieux un car le matin et un le soir.
Même pas une ligne de car un peu plus régulière pour aller à la gare la plus proche : ils vont vers les grandes villes, avec deux horaires dans la journée.
Alors avec train+vélo, pour une personne en forme, on élargit le rayon, ou alors stop/covoiturage plus train, mais il n'y a pas réellement d'offre pertinente.
Et encore une fois, au prix du train, la solution rentable avec plein d'avantages annexes reste la voiture…
C'est clairement un échec des politiques de mobilité de la région, qui ne s'intéressent pas à ce problème.
Ah bah je serais ravi que ça soit une option dans la majeure partie des cas oui !
Après, selon l'usage, si tu as besoin d'une mobilité fine avant et après un long trajet, le train n'est pas toujours la solution la plus simple.
Mais les transports en communs en France - hors grandes villes et banlieues - sont pourris par le TGV qui fait… de longs trajets entre grandes villes efficacement, mais ne sert presque à rien entre deux. Et la politique ayant été de mettre en avant le TGV et de virer les petites lignes, des coins qui furent desservis par le train ne le sont plus que par les voitures.
Ça a existé avant que la voiture ne se démocratise, ça peut se reconstruire. Mais sans vraie offre de transports en communs, c'est pas pour demain. Je crains qu'on ne voie le règne de la voiture électrique arriver bien avant le retour généralisé des transports en commun…
Ça pourrait être relativement simple d'avoir des routes dédiées à des véhicules autonomes : si tu n'as pas à gérer l'humain c'est plus simple.
Et tu pourrais très bien avoir un véhicule qui te fait tes 800km d'autoroute autonome sans que tu n'aies à regarder la route, et tu prends en manuel avant et après.
Les étapes intermédiaires, comme décrites ici avec des automatisation mais pas partout, pas tout le temps - ou pire mixtes, avec de l'autonome et du manuel mélangés - posent pas mal de problèmes.
De mon côté je passe largement à côté de tout ça, ma caisse ayant l'ouverture/fermeture centralisée, c'est à dire qu'on ouvre ou ferme toute la voiture en tournant la clé côté conducteur.
Et rien que ça a déjà posé problème, le mécanisme ayant pété dans la portière, pendant la période de garantie heureusement.
Bon après il y a la direction assistée et l'ABS, mais aucun des deux ne remplace une action manuelle par une automatique, ça optimise simplement l'action.
J'ai eu l'occasion de tester le régulateur de vitesse sur une Kangoo, et j'apprécie aussi sur l'autoroute, mais pas toujours, question d'habitude je suppose.
Bref, je serais absolument ravi d'avoir une voiture autonome, qui m'amène voir mon employeur directement, pendant que je termine ma nuit ou bouquine un truc. Mais l'étape intermédiaire entre ma voiture actuelle et la science-fiction, je vais surtout la vivre en télétravail…
Ah ouais, chaud en 1911 c'est 14 jours à plus de 30° à Paris !
Aujourd'hui ça fait un peu rêver de n'avoir que ça…
Des maximales à 38° ?
Aujourd'hui on commence à titrer dans les journaux à partir de 42°, en dessous c'est banal…
T'en as un autre d'épisode documenté de ville qui prend feu parce que la température atteint les 50°, au Canada ? Parce que c'était l'été dernier, et ça m'a quand même l'air d'une sacrée première historique…
Alors ça ne rentre pas dans tes critères, puisqu'il s'agit d'un dédié, et qu'il faut donc tout paramétrer soi-même.
Mais pour 2€22/mois (1€85HT) tu as un dédié avec 1 CPU x86_64, 1Go de RAM et 10Go de disque dur, les Stardust qu'on trouve dispos sur le datacenter Amsterdam 1.
C'est ce que j'ai trouvé de moins cher en dédié.
Avec 10Go système inclus, tu as quand même de la marge, le système doit prendre à l'installation autour de 1Go.
Et tu peux facilement prendre plus si tu as besoin, pour pas super cher tant que ça reste petit, par exemple tu passes à 4€32 TTC si tu rajoutes un stockage secondaire de 30Go.
Mais je trouve que le vrai intérêt de la chose c'est bien la conf minimale de base à terriblement peu cher.
Si tu rajoutes un nom de domaine, que tu peux par exemple prendre en .ovh à 3€HT par an, tu as un total impressionnant de 30€23 TTC à l'année.
L'app Anvil, via l'éditeur, est apparemment versionnée avec git automatiquement et tu peux la cloner, donc derrière coder avec ce que tu veux, et ne pas utiliser leur éditeur.
Donc je suppose que tu peux te passer totalement de l'éditeur, mais peut-être après une petite période d'apprentissage.
Du wifi pour télécharger tes cartes et applications avant de partir à l'aventure.
Mais après tu es autonome avec le GPS qui ne fait que de la réception, et tes cartes en local sur l'appareil.
Pas de traçage : pour OSM tu as des applis sur fdroid (OsmAnd~ ou Organic Maps par exemple), et tu peux avoir un téléphone lineageOS sans google apps.
Ben ouais, et si t'as une alerte de méga-accident de la route deux kilomètres plus loin : l'alerte casse-pied sur ton téléphone qui te force à ralentir, voir les autres voitures autour de toi ralentir aussi, ça peut ne pas être inutile…
Difficile de prévoir quand et comment ça sera vraiment efficace, en tout cas pas avant d'avoir des retours pratiques sur le terrain, de choses qui se sont bien ou mal passées.
Donc, si j'analyse bien - un peu en diagonale - l'intrusion dans la vie privée est devenue telle que comme on te traque à coup sûr et qu'on sait parfaitement qui tu es, magique ya plus besoin de captcha ?
Le fait de poster à zéro et d'être masqué par défaut pour un nouvel arrivant, quand je vois ça (du haut de ma colline de karma accumulé au fil des âges), ben ça me perturbe.
Ce n'est en effet pas super accueillant…
Mais c'est quoi ces commentaires de cours de récré ?
C'est quoi « un ami noir » ? « Un ami trans » ?
Tous mes amis/ies sont des êtres humains, ils/elles sont tous/toutes issus/ues de métissages complexes, et d'origines très très variées si on remonte simplement à quelques générations.
Leurs identités de genre, leurs orientations sexuelles sont variées, et chacun fait comme bon lui semble.
Alors oui, les premières fois que j'ai croisé ma voisine trans, je lui ai trouvé un physique inhabituel, j'ai fini par piger d'où ça venait, et voilà.
Mais sérieux : ça veut dire quoi « j'ai un ami noir » ?
Vraiment ?
C'est quoi ces conneries ?
Et puis c'est quoi noir ?
Au fil des époques, des pays, il y a eu plein de définitions, incompatibles les unes avec les autres, toutes ségrégationnistes et discriminatoires, et aucune de convaincante.
Si je vais avec mes enfants au musée de l'apartheid à Johannesburg, mes mômes entre du côté noir et moi du coté blanc, et personne ici - personne - ne les qualifieraient de noirs, ni même ma femme d'ailleurs, mais la règle était brutale : mes propres enfants auraient été moins égaux que moi en ce lieu en cette époque !
Faut arrêter les âneries hein, on est en France en 2021, il n'y a pas de définition légale du terme « noir », et donc les seuls utilisations que tu peux en faire sont obligatoirement floues et sans autre substance que de dire de quelqu'un qu'il est blond, brun, roux, châtain, grand, petit, etc…
Ben je ne sais pas, j'ai quand même le sentiment que les messages mal construits, agressifs, qui n'apportent rien d'autre que d'entretenir des flame wars, ou qui sont simplement trollesques, sont fortement « inutilisés », alors que des messages, même contradictoires, ou pas spécialement bien-pensants, mais correctement argumentés, respectueux des interlocuteurs, et lisibles, sont « pertinentés ».
Comme d'hab ce n'est pas toujours le cas, et il peut être difficile dans un débat de ne pas « moinsser » son « adversaire » même si sa contribution est objectivement pertinente.
En tout cas, je ne trouve pas que le système soit en l'état une forte boucle de renforcement de préjugés.
Plutôt un outil pour concentrer des contenus construits, réfléchis, et argumentés par opposition aux (pseudo-)arguments assénés sans être étayés.
J'ai souvent vu des débats non enflammés, contradictoires, où les parties se sont quittées sans s'être mises d'accord, mais où les contributions n'étaient pas spécialement « inutilisées », et où tout se déroulait dans le respect mutuel.
Alors bon, une boucle de rétro-action qui renforce le respect mutuel et les contenus non écrit à l'emporte-pièce, j'ai du mal à être contre, mais j'ai peut-être un biais personnel à ce niveau…
Où tu apprends que vers l'an 2000 on trouvait encore des femmes qui bossaient dans le domaine, depuis 40 ans, donc en fin de carrière, mais pas grand monde entre deux.
On peut largement supposer que les recrutements de femmes ont été fortement réduits, mais pas obligatoirement que celles qui étaient déjà là aient été mises à la retraite.
Et comme le nombre d'emplois a explosé, les postes occupés par des hommes bien sûr, aujourd'hui tu peux encore les chercher les femmes dans le milieu, un peu comme de chercher des orchidées dans un champs de pissenlits. Il y en a oui, en cherchant. Mais pas de loin…
Et il va falloir encore longtemps avant que les équipes mixtes soient quelque chose d'habituel.
Rappel des épisodes précédents : le benchmark avec ab donne 3400 req/s en fournissant les images dans la réponse, et seulement 2800 req/s avec la redirection 302, avec 21Mo de RAM utilisée.
En utilisant le serveur gunicorn (simplement en mettant server="gunicorn", workers=5 dans l'appel à bottle.run()) on monte à 14000 req/s, la machine ayant 4 cœurs, augmenter le nombre de workers au delà de 5 ne fait absolument rien gagner. Mais là on est à 30Mo de RAM pour le master, et 21Mo de RAM pour chacun des 5 workers. Rapide mais on le paye !
J'ai tenté de mettre l'application bottle derrière apache et le mod_wsgi (processes=5 threads=2), on est à 12000 req/s, les processus mod_wsgi font 23Mo de RAM chacun, on est quasiment à la vitesse et aux ressources de gunicorn mais avec le reste des possibilités d'apache, si on en a besoin.
Et puis j'ai poussé un petit peu, tester les différents serveurs disponibles comme backend de bottle, il y en a plein.
Et je suis tombé sur bjoern, qui utilise la libev, bibliothèque C de gestion d'évènements, très - très - rapide.
On monte à 17000 req/s, en monothread et 20Mo de RAM.
C'est assez bluffant par rapport à toutes les autres solutions, surtout par rapport aux 3400 du serveur par défaut !
Mais bon, en fait, pourquoi pas lancer l'application bjoern 5 fois et utiliser un load-balancer devant ?
lighttpd fait ça très bien et on est à 13000 req/s, honorable, mais sans intérêt.
Alors on va utiliser un vrai load-balancer : haproxy !
Et donc 5 backend appli standalone avec bjoern, un haproxy en round-robin devant, on passe à 19500 req/s !
On a le même score avec 4 backend, la machine a 4 cœurs, fait tourner haproxy et aussi l'outil de benchmark, on sature sans surcharger le nombre de backend.
Si on descends à 2 backend, on monte à 19700 req/s, à 3 backend on est à 19800 req/s.
On s'y attends un peu : 5 processus qui bossent (3 backends bottle/bjoern, haproxy, et ab pour les tests) sur 4 cœurs c'est en général ce qui optimise le plus, mais c'est assez marginal.
Bien sûr, là on est à 3*20Mo+8Mo = 68Mo.
En bref haproxy ça déchire, on le savait déjà, on le constate encore, 8Mo de RSS, c'est tout mini.
Et le serveur WSGI bjoern est très impressionnant dans l'écosystème WSGI.
Et on descends pas en dessous de 20Mo de RAM pour un processus Python.
Et le Bottle.redirect() est plus lent, avec 3*bjoern+haproxy on est à 15000 req/s, c'est naze.
Conclusion, fournir le fichier directement et ne pas faire de redirection 302 (de toute façon, derrière, côté navigateur, on fait deux requêtes, c'est atroce), utiliser bjoern en server WSGI, et si on vaut load-balancer entre plusieurs serveurs, dégainer haproxy.
Yth.
Pour info le /etc/haproxy/haproxy.cfg utilisé est le suivant (les timeout servent pas dans notre cas, mais haproxy geint si on les met pas) :
À noter que la version qui précharge n'a pas besoin d'un serveur de fichiers statiques à côté, c'est complètement autonome, et peut tourner en frontal ou directement derrière un haproxy, sans nginx/apache/etc.
Si j'utilise par exemple waitress comme serveur python (serveur multi-thread) on reste à 21Mo en RSS mais on passe à 313Mo en VSZ !
Et c'est plus lent (2800/2400 req/s)
Avec gunicorn (pre-fork) on va plus vite, 3500/3000 req/s et la RAM monte : on a deux processus, un master et un worker, qui font 25Mo+22Mo en RSS (et 30+30 en VSZ), mais comme on le voit, il prefork un seul worker.
Si on met worker=10, par exemple, on est à 14000/10000 req/s, mais comme prévu, on a 10 workers, donc 25+220Mo de RAM, ça fait pas mal, mais ça "scale" :)
Yth, bon si j'arrêtais de procrastiner hein ?
PS : pour changer de serveur c'est assez simple run(host='localhost', port=8080, server='gunicorn', workers=10)
Avec un truc en bottle vite fait, je monte à 3400 req/s pour fournir le fichier directement, sans redirection, alors que je suis à 2800 req/s pour la redirection.
Le serveur par défaut est mono-thread, mais utiliser des trucs multi-thread ou asynchrones, ne change pas grand chose vu la simplicité des traitements.
Après plusieurs benchmark ab comme dans le journal sur chaque serveur, la RAM utilisée est de 21Mo pour chacun (25,3Mo en VSZ, 20,8Mo en RSS).
Je suis surtout surpris du fait que la redirection soit plus lente.
Peut-être qu'en balançant manuellement les headers ça irait plus vite que le Bottle.redirect().
Pourtant je ne fais plus aucune IO disque après le démarrage, dans les deux cas, ça devrait être relativement équivalent.
Bref, après, c'est difficile de comparer les chiffres bruts alors qu'on n'est pas sur la même machine.
Bon, j'ai pas envie de troller Apple plus que de raison, mais c'est un grand classique de la comm Apple de s'attribuer des évolutions technologiques.
La souris n'a pas été inventée par Apple, le smartphone non plus, l'USB non plus, le baladeur mp3 non plus, ni les laptop ultra-légers, ultra-plats, ni la recharge par induction, ni les formes arrondies, ni…. etc.
Alors parfois ce sont effectivement des produits Apple qui ont en premier atteint assez massivement le grand public, mais ils n'en sont pas très souvent réellement à l'origine.
Bilan : 1 personne qui a de l'humour et 3 qui ont été plus lent à coder ce truc avec leur langage de prédilection.
Mais plus sérieusement, mon message indiquait que la rapidité d'écriture du code, sa lisibilité, sa maintenabilité, et même sa concision, sont aussi à prendre en compte dans un projet.
Les perfs brutes, ça sert là où ça sert.
Si tu dois faire des calculs matriciels complexes, numpy est un bon candidat.
Si tu cherches à faire du polling sur une base redis pour lancer un traitement spécifique derrière en fonction des données disponibles, tu vas pas faire ça en C, le python va prendre 5 lignes, et comme le programme passera sa vie en select les ressources seront négligeables.
Si tu veux importer et convertir des fichiers XML vers une base de donnée postgreSQL, franchement, si tu n'y arrives pas en bash (parce que le XML c'est pénible), le python va être royal pour ça.
Pour recoder le système de package de ta distrib, ne sort pas le Go, modernise ton bash et utilise du Python, ou du Ruby si tu connais mieux, le gain potentiel en perf ne vaudra pas la complexité comparative de maintenance.
Mais si tu veux concurrencer l'Unreal Engine, non, fais pas ça en python, choisi plutôt du Rust (par exemple), ou un langage qui va te fournir des primitives efficace pour gérer tes fils d'exécutions parallèles, ta mémoire, tes transferts de mémoire, tes traitements massivement parallélisable sur le GPU, etc.
Le Python n'est pas le meilleur langage pour ça.
Mais bigre, pour du backend web ou de l'API, sérieux, si je ne refais plus jamais du PHP ou du node.js ça sera déjà trop tôt, c'est tellement plus agréable, et rapide, de le faire en Python !
[^] # Re: vraiment?
Posté par Yth (Mastodon) . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à 10.
Quand même il ne faut pas confondre HTML et liens.
C'est quand même devenu assez standard de détecter les liens dans du texte et de les rendre cliquable.
Que ce soit avec des logiciels de chat, ou des clients mail textuels, où même la console texte de ton Linux préféré, et j'en passe, on n'a vraiment pas besoin de gérer les mails en HTML pour avoir des liens sur lesquels il suffit de cliquer comme partout ailleurs.
Le mail en HTML n'apporte pas les liens, ni les liens cliquables, mais tout le reste : les CSS, les ressources externes, les rendus foireux, etc.
# Sylpheed
Posté par Yth (Mastodon) . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à 10.
Sylpheed ou claws-mail, sont des clients mails très efficaces mais qui de base ne font que du texte.
J'utilise personnellement Sylpheed, et je ne parlerai pas des différences avec Claws.
Si tu reçois un mail en HTML pur, il est transformé en texte, parfois avec plus ou moins de succès, mais en général c'est lisible sauf pour les publipostages bien pourris.
De toute façon Sylpheed n'affiche que du texte.
Les liens sont correctement pris en compte et cliquable, que le mail soit texte ou qu'on ait une balise A du HTML (dans ce cas il affiche bien le contenu de la balise, et on clique vers son HREF, comme un lien classique).
Ensuite on peut voir la liste des pièces jointes, et les mails texte et HTML sont présentées comme des pièces jointes particulières, donc si tu as un mail avec les deux versions, tu peux afficher l'une ou l'autre (et parfois avoir dans la version texte : ton client gère pas le HTML, dégage s'il-te-plaît).
Mais aussi, comme avec n'importe quelle pièce jointe, tu peux l'ouvrir dans un outil externe, et donc ouvrir ton mail en HTML dans un vrai navigateur web, si vraiment tu en as besoin.
Dans la très grande majorité des cas, tout fonctionne au poil. Les seuls mails posant des soucis étant les publipostage souvent très surchargés en HTML, et régulièrement sans version texte associée (aaah, les promos GoG…). Ou les mails pro à la con genre réunion Teams, ou ticket Jira, qui sont aussi assez généralement mal foutus (mais lisible, en général on voit bien les liens, et on peut cliquer sur le truc important sans lire le contenu généré et inutile)…
Et au final, vivre dans un monde où ton client mail ne gère pas plus le HTML que ça, bah ça marche pas mal. C'est toujours rapide parce qu'il n'y a jamais de rendu web, et donc les ressources externes (un des vrais drames des mails en HTML), bah il ne cherche même pas à savoir, ça ne sert à rien.
En ce qui concerne la réponse en haut ou en bas, franchement ça dépend.
Si c'est une conversation standard en texte, en général je simplifie le message reçu en ne gardant que ce à quoi je réponds, et je poste en dessous, mais ce sont des efforts, il faut que la conversation mérite toute cette attention.
S'il s'agit d'une discussion de groupe où tout le monde réponds au dessus, je fais comme tout le monde et je réponds au dessus.
Et si c'est une réponse express, je réponds en dessous sans dire bonjour ni rien en mode Crocker.
Bref, c'est pas si difficile le mail en texte, mais je conseille d'utiliser un outil qui ne fait que ça.
Je trouve le côté bâtard de Thunderbird assez pénible, et lourd, quand on l'utilise en mode pur texte et pas HTML (bâtard parce qu'on utilise un outil pensé pour rendre du HTML mais en fallback texte).
[^] # Re: 3008 & Cactus de loc
Posté par Yth (Mastodon) . En réponse au journal SmartCar. Évalué à 5.
À voir ce que donne l'expérience Allemande : 9€ par mois pour un accès illimité au réseau ferroviaire.
C'est pas gratuit, ça peut suffire ?
Là ils ont des soucis parce que l'offre a trop de succès, donc les train sont surchargés, mais c'est lié à un changement majeur dans l'usage des transports en commun, ça devrait se tasser en quelques années.
Faut pas se leurrer, ça sera pas mieux en France si on a une offre dans le même genre.
Mais ce n'est pas grave, ça devrait malgré tout avoir un impact immédiat - en négatif, donc positif ;) - sur l'utilisation de la voiture ! Donc aussi de dépendance aux importations de pétrole.
C'est une question de choix politique, d'avenir de notre pays.
[^] # Re: 3008 & Cactus de loc
Posté par Yth (Mastodon) . En réponse au journal SmartCar. Évalué à 6.
Voiture neuve à 10k€, déjà 150kkm, ça fait 1€ pour 15km.
Je compte bien réussir à l'amener à 300kkm, mais on n'en est pas là. Elle date de 2012 donc 10 ans d'âge.
Consommation : 5,5l/100km, diesel, en ce moment à 1,8€/l.
Assurance : 450€/an, on va faire une règle de trois pour ramener le tarif actuel au kilométrage moyen annuel sur 10 ans, on a 1€ pour 33km, disons 30km.
Le trajet en question fait 60km, donc :
- 4€ de voiture neuve.
- 2€ d'assurance.
- 3,3l ~ 6€ d'essence.
Donc 12€ hors entretient (là c'est plus difficile à calculer, j'ai pas trop d'idée).
On pourrait rajouter 5€ d'autoroute en prenant l'autoroute, qui fait gagner 10 minutes, n'évite pas les embouteillages, fait plus de km, donc coûte plus cher, j'évite en général.
Bref, ça nous fait le prix du billet de train à 11€50.
Sachant qu'il faut rejoindre la gare avant de prendre le train, 15km. Vélo (c'est pas plat du tout), voiture, stop, covoiturage ? La plupart ont un coût…
Alors, on est d'accord que sur le pur trajet du train en lui-même, le train est moins cher que de prendre la voiture, mais je me place justement dans le cas dont je parle plus haut, à savoir pas de transports en communs efficaces pour rejoindre la gare la plus proche.
Si le trajet est régulier, il y a des abonnements, c'est rentable, mais justement, si le trajet est irrégulier, l'abonnement ne vaut pas le coût.
C'est un simple exemple, qui ne vaut pas généralité, mais on est ici face à une situation de défaut majeur des transports en communs :(
Heureusement ce n'est pas non plus partout pareil.
[^] # Re: 3008 & Cactus de loc
Posté par Yth (Mastodon) . En réponse au journal SmartCar. Évalué à 4.
L'intermédiaire se développe, avec le covoiturage surtout.
Pas assez vite, pas assez bien.
Dans mon coin, prendre le train pour aller à la grande ville d'à-côté, c'est plus cher que de prendre la voiture seul, et les gares sont toutes sur l'axe entre deux grandes villes, mais dès que tu t'éloignes, c'est mort : tu as au mieux un car le matin et un le soir.
Même pas une ligne de car un peu plus régulière pour aller à la gare la plus proche : ils vont vers les grandes villes, avec deux horaires dans la journée.
Alors avec train+vélo, pour une personne en forme, on élargit le rayon, ou alors stop/covoiturage plus train, mais il n'y a pas réellement d'offre pertinente.
Et encore une fois, au prix du train, la solution rentable avec plein d'avantages annexes reste la voiture…
C'est clairement un échec des politiques de mobilité de la région, qui ne s'intéressent pas à ce problème.
[^] # Re: 3008 & Cactus de loc
Posté par Yth (Mastodon) . En réponse au journal SmartCar. Évalué à 6.
Ah bah je serais ravi que ça soit une option dans la majeure partie des cas oui !
Après, selon l'usage, si tu as besoin d'une mobilité fine avant et après un long trajet, le train n'est pas toujours la solution la plus simple.
Mais les transports en communs en France - hors grandes villes et banlieues - sont pourris par le TGV qui fait… de longs trajets entre grandes villes efficacement, mais ne sert presque à rien entre deux. Et la politique ayant été de mettre en avant le TGV et de virer les petites lignes, des coins qui furent desservis par le train ne le sont plus que par les voitures.
Ça a existé avant que la voiture ne se démocratise, ça peut se reconstruire. Mais sans vraie offre de transports en communs, c'est pas pour demain. Je crains qu'on ne voie le règne de la voiture électrique arriver bien avant le retour généralisé des transports en commun…
[^] # Re: 3008 & Cactus de loc
Posté par Yth (Mastodon) . En réponse au journal SmartCar. Évalué à 6.
Ça pourrait être relativement simple d'avoir des routes dédiées à des véhicules autonomes : si tu n'as pas à gérer l'humain c'est plus simple.
Et tu pourrais très bien avoir un véhicule qui te fait tes 800km d'autoroute autonome sans que tu n'aies à regarder la route, et tu prends en manuel avant et après.
Les étapes intermédiaires, comme décrites ici avec des automatisation mais pas partout, pas tout le temps - ou pire mixtes, avec de l'autonome et du manuel mélangés - posent pas mal de problèmes.
De mon côté je passe largement à côté de tout ça, ma caisse ayant l'ouverture/fermeture centralisée, c'est à dire qu'on ouvre ou ferme toute la voiture en tournant la clé côté conducteur.
Et rien que ça a déjà posé problème, le mécanisme ayant pété dans la portière, pendant la période de garantie heureusement.
Bon après il y a la direction assistée et l'ABS, mais aucun des deux ne remplace une action manuelle par une automatique, ça optimise simplement l'action.
J'ai eu l'occasion de tester le régulateur de vitesse sur une Kangoo, et j'apprécie aussi sur l'autoroute, mais pas toujours, question d'habitude je suppose.
Bref, je serais absolument ravi d'avoir une voiture autonome, qui m'amène voir mon employeur directement, pendant que je termine ma nuit ou bouquine un truc. Mais l'étape intermédiaire entre ma voiture actuelle et la science-fiction, je vais surtout la vivre en télétravail…
[^] # Re: Éco-anxieux
Posté par Yth (Mastodon) . En réponse au journal Le ministère du futur. Évalué à 10.
Ah ouais, chaud en 1911 c'est 14 jours à plus de 30° à Paris !
Aujourd'hui ça fait un peu rêver de n'avoir que ça…
Des maximales à 38° ?
Aujourd'hui on commence à titrer dans les journaux à partir de 42°, en dessous c'est banal…
T'en as un autre d'épisode documenté de ville qui prend feu parce que la température atteint les 50°, au Canada ? Parce que c'était l'été dernier, et ça m'a quand même l'air d'une sacrée première historique…
# Scaleway, instances à pas cher.
Posté par Yth (Mastodon) . En réponse au journal Bloguer pour pas trop cher, avec du logiciel libre et sobrement, en 2022. Évalué à 10.
Alors ça ne rentre pas dans tes critères, puisqu'il s'agit d'un dédié, et qu'il faut donc tout paramétrer soi-même.
Mais pour 2€22/mois (1€85HT) tu as un dédié avec 1 CPU x86_64, 1Go de RAM et 10Go de disque dur, les Stardust qu'on trouve dispos sur le datacenter Amsterdam 1.
C'est ce que j'ai trouvé de moins cher en dédié.
Avec 10Go système inclus, tu as quand même de la marge, le système doit prendre à l'installation autour de 1Go.
Et tu peux facilement prendre plus si tu as besoin, pour pas super cher tant que ça reste petit, par exemple tu passes à 4€32 TTC si tu rajoutes un stockage secondaire de 30Go.
Mais je trouve que le vrai intérêt de la chose c'est bien la conf minimale de base à terriblement peu cher.
Si tu rajoutes un nom de domaine, que tu peux par exemple prendre en .ovh à 3€HT par an, tu as un total impressionnant de 30€23 TTC à l'année.
[^] # Re: Bon je vais quand même en dire un peu plus ...
Posté par Yth (Mastodon) . En réponse au journal Anvil le retour . Évalué à 4.
L'app Anvil, via l'éditeur, est apparemment versionnée avec git automatiquement et tu peux la cloner, donc derrière coder avec ce que tu veux, et ne pas utiliser leur éditeur.
Donc je suppose que tu peux te passer totalement de l'éditeur, mais peut-être après une petite période d'apprentissage.
[^] # Re: Chiffrefête
Posté par Yth (Mastodon) . En réponse au lien Jeu mobile: Gao & Blaze - avez-vous quelque chose à cacher?. Évalué à 4.
Du wifi pour télécharger tes cartes et applications avant de partir à l'aventure.
Mais après tu es autonome avec le GPS qui ne fait que de la réception, et tes cartes en local sur l'appareil.
Pas de traçage : pour OSM tu as des applis sur fdroid (OsmAnd~ ou Organic Maps par exemple), et tu peux avoir un téléphone lineageOS sans google apps.
[^] # Re: galère ce truc
Posté par Yth (Mastodon) . En réponse au lien Six questions sur FR-Alert, le système d’alerte d’urgence qui arrive sur nos smartphones. Évalué à 3.
Ben ouais, et si t'as une alerte de méga-accident de la route deux kilomètres plus loin : l'alerte casse-pied sur ton téléphone qui te force à ralentir, voir les autres voitures autour de toi ralentir aussi, ça peut ne pas être inutile…
Difficile de prévoir quand et comment ça sera vraiment efficace, en tout cas pas avant d'avoir des retours pratiques sur le terrain, de choses qui se sont bien ou mal passées.
# Une nouvelle étape du capitalisme de surveillance..?
Posté par Yth (Mastodon) . En réponse au lien Le captcha ou le jeton de vie privée. Évalué à 6.
Donc, si j'analyse bien - un peu en diagonale - l'intrusion dans la vie privée est devenue telle que comme on te traque à coup sûr et qu'on sait parfaitement qui tu es, magique ya plus besoin de captcha ?
Bigre, c'est violent…
[^] # Re: Passionnant
Posté par Yth (Mastodon) . En réponse au lien comment détruire son industrie de la tech. Évalué à 3.
Le fait de poster à zéro et d'être masqué par défaut pour un nouvel arrivant, quand je vois ça (du haut de ma colline de karma accumulé au fil des âges), ben ça me perturbe.
Ce n'est en effet pas super accueillant…
[^] # Re: Passionnant
Posté par Yth (Mastodon) . En réponse au lien comment détruire son industrie de la tech. Évalué à 5.
Mais c'est quoi ces commentaires de cours de récré ?
C'est quoi « un ami noir » ? « Un ami trans » ?
Tous mes amis/ies sont des êtres humains, ils/elles sont tous/toutes issus/ues de métissages complexes, et d'origines très très variées si on remonte simplement à quelques générations.
Leurs identités de genre, leurs orientations sexuelles sont variées, et chacun fait comme bon lui semble.
Alors oui, les premières fois que j'ai croisé ma voisine trans, je lui ai trouvé un physique inhabituel, j'ai fini par piger d'où ça venait, et voilà.
Mais sérieux : ça veut dire quoi « j'ai un ami noir » ?
Vraiment ?
C'est quoi ces conneries ?
Et puis c'est quoi noir ?
Au fil des époques, des pays, il y a eu plein de définitions, incompatibles les unes avec les autres, toutes ségrégationnistes et discriminatoires, et aucune de convaincante.
Si je vais avec mes enfants au musée de l'apartheid à Johannesburg, mes mômes entre du côté noir et moi du coté blanc, et personne ici - personne - ne les qualifieraient de noirs, ni même ma femme d'ailleurs, mais la règle était brutale : mes propres enfants auraient été moins égaux que moi en ce lieu en cette époque !
Faut arrêter les âneries hein, on est en France en 2021, il n'y a pas de définition légale du terme « noir », et donc les seuls utilisations que tu peux en faire sont obligatoirement floues et sans autre substance que de dire de quelqu'un qu'il est blond, brun, roux, châtain, grand, petit, etc…
C'est quoi « grand » ? « petit » ?
[^] # Re: Passionnant
Posté par Yth (Mastodon) . En réponse au lien comment détruire son industrie de la tech. Évalué à 3.
Ben je ne sais pas, j'ai quand même le sentiment que les messages mal construits, agressifs, qui n'apportent rien d'autre que d'entretenir des flame wars, ou qui sont simplement trollesques, sont fortement « inutilisés », alors que des messages, même contradictoires, ou pas spécialement bien-pensants, mais correctement argumentés, respectueux des interlocuteurs, et lisibles, sont « pertinentés ».
Comme d'hab ce n'est pas toujours le cas, et il peut être difficile dans un débat de ne pas « moinsser » son « adversaire » même si sa contribution est objectivement pertinente.
En tout cas, je ne trouve pas que le système soit en l'état une forte boucle de renforcement de préjugés.
Plutôt un outil pour concentrer des contenus construits, réfléchis, et argumentés par opposition aux (pseudo-)arguments assénés sans être étayés.
J'ai souvent vu des débats non enflammés, contradictoires, où les parties se sont quittées sans s'être mises d'accord, mais où les contributions n'étaient pas spécialement « inutilisées », et où tout se déroulait dans le respect mutuel.
Alors bon, une boucle de rétro-action qui renforce le respect mutuel et les contenus non écrit à l'emporte-pièce, j'ai du mal à être contre, mais j'ai peut-être un biais personnel à ce niveau…
[^] # Re: Passionnant
Posté par Yth (Mastodon) . En réponse au lien comment détruire son industrie de la tech. Évalué à 5.
Si tu veux des infos sur la situation actuelle ou récente en France, la dernière émission de Libre à Vous en parle pas mal, cf cette dépêche :
https://linuxfr.org/news/la-diversite-de-genre-emission-libre-a-vous-du-7-juin-2022-podcasts-et-references
Où tu apprends que vers l'an 2000 on trouvait encore des femmes qui bossaient dans le domaine, depuis 40 ans, donc en fin de carrière, mais pas grand monde entre deux.
On peut largement supposer que les recrutements de femmes ont été fortement réduits, mais pas obligatoirement que celles qui étaient déjà là aient été mises à la retraite.
Et comme le nombre d'emplois a explosé, les postes occupés par des hommes bien sûr, aujourd'hui tu peux encore les chercher les femmes dans le milieu, un peu comme de chercher des orchidées dans un champs de pissenlits. Il y en a oui, en cherchant. Mais pas de loin…
Et il va falloir encore longtemps avant que les équipes mixtes soient quelque chose d'habituel.
Et ça n'a, biologiquement, aucun sens.
[^] # Re: En Python (Flask)
Posté par Yth (Mastodon) . En réponse au journal Le taptempo du web. Évalué à 6.
Alors pour faire suite à mon commentaire originel que vous trouverez avec le code python en Bottle ici :
https://linuxfr.org/users/spacefox/journaux/java-presque-9-000-requetes-par-seconde-avec-8-mo-de-ram#comment-1893297
Rappel des épisodes précédents : le benchmark avec ab donne 3400 req/s en fournissant les images dans la réponse, et seulement 2800 req/s avec la redirection 302, avec 21Mo de RAM utilisée.
En utilisant le serveur gunicorn (simplement en mettant
server="gunicorn", workers=5dans l'appel àbottle.run()) on monte à 14000 req/s, la machine ayant 4 cœurs, augmenter le nombre de workers au delà de 5 ne fait absolument rien gagner. Mais là on est à 30Mo de RAM pour le master, et 21Mo de RAM pour chacun des 5 workers. Rapide mais on le paye !J'ai tenté de mettre l'application bottle derrière apache et le mod_wsgi (processes=5 threads=2), on est à 12000 req/s, les processus mod_wsgi font 23Mo de RAM chacun, on est quasiment à la vitesse et aux ressources de gunicorn mais avec le reste des possibilités d'apache, si on en a besoin.
Et puis j'ai poussé un petit peu, tester les différents serveurs disponibles comme backend de bottle, il y en a plein.
Et je suis tombé sur bjoern, qui utilise la libev, bibliothèque C de gestion d'évènements, très - très - rapide.
On monte à 17000 req/s, en monothread et 20Mo de RAM.
C'est assez bluffant par rapport à toutes les autres solutions, surtout par rapport aux 3400 du serveur par défaut !
Mais bon, en fait, pourquoi pas lancer l'application bjoern 5 fois et utiliser un load-balancer devant ?
lighttpd fait ça très bien et on est à 13000 req/s, honorable, mais sans intérêt.
Alors on va utiliser un vrai load-balancer : haproxy !
Et donc 5 backend appli standalone avec bjoern, un haproxy en round-robin devant, on passe à 19500 req/s !
On a le même score avec 4 backend, la machine a 4 cœurs, fait tourner haproxy et aussi l'outil de benchmark, on sature sans surcharger le nombre de backend.
Si on descends à 2 backend, on monte à 19700 req/s, à 3 backend on est à 19800 req/s.
On s'y attends un peu : 5 processus qui bossent (3 backends bottle/bjoern, haproxy, et ab pour les tests) sur 4 cœurs c'est en général ce qui optimise le plus, mais c'est assez marginal.
Bien sûr, là on est à 3*20Mo+8Mo = 68Mo.
En bref haproxy ça déchire, on le savait déjà, on le constate encore, 8Mo de RSS, c'est tout mini.
Et le serveur WSGI bjoern est très impressionnant dans l'écosystème WSGI.
Et on descends pas en dessous de 20Mo de RAM pour un processus Python.
Et le Bottle.redirect() est plus lent, avec 3*bjoern+haproxy on est à 15000 req/s, c'est naze.
Conclusion, fournir le fichier directement et ne pas faire de redirection 302 (de toute façon, derrière, côté navigateur, on fait deux requêtes, c'est atroce), utiliser bjoern en server WSGI, et si on vaut load-balancer entre plusieurs serveurs, dégainer haproxy.
Pour info le /etc/haproxy/haproxy.cfg utilisé est le suivant (les timeout servent pas dans notre cas, mais haproxy geint si on les met pas) :
Et le code final bottle, avec exactement deux dépendances python : bottle et bjoern
[^] # Re: télétravail
Posté par Yth (Mastodon) . En réponse au sondage Quelle est la fréquence de nettoyage de vos périphériques d'entrée ?. Évalué à 3.
En télétravail, je dépoussière en profondeur à la queue de chat.
[^] # Re: C'est beaucoup ?
Posté par Yth (Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 6.
À noter que la version qui précharge n'a pas besoin d'un serveur de fichiers statiques à côté, c'est complètement autonome, et peut tourner en frontal ou directement derrière un haproxy, sans nginx/apache/etc.
Si j'utilise par exemple waitress comme serveur python (serveur multi-thread) on reste à 21Mo en RSS mais on passe à 313Mo en VSZ !
Et c'est plus lent (2800/2400 req/s)
Avec gunicorn (pre-fork) on va plus vite, 3500/3000 req/s et la RAM monte : on a deux processus, un master et un worker, qui font 25Mo+22Mo en RSS (et 30+30 en VSZ), mais comme on le voit, il prefork un seul worker.
Si on met worker=10, par exemple, on est à 14000/10000 req/s, mais comme prévu, on a 10 workers, donc 25+220Mo de RAM, ça fait pas mal, mais ça "scale" :)
PS : pour changer de serveur c'est assez simple
run(host='localhost', port=8080, server='gunicorn', workers=10)[^] # Re: C'est beaucoup ?
Posté par Yth (Mastodon) . En réponse au journal Java : presque 9 000 requêtes par seconde avec 8 Mo de RAM. Évalué à 6.
Avec un truc en bottle vite fait, je monte à 3400 req/s pour fournir le fichier directement, sans redirection, alors que je suis à 2800 req/s pour la redirection.
Le serveur par défaut est mono-thread, mais utiliser des trucs multi-thread ou asynchrones, ne change pas grand chose vu la simplicité des traitements.
Et la version courte :
Après plusieurs benchmark ab comme dans le journal sur chaque serveur, la RAM utilisée est de 21Mo pour chacun (25,3Mo en VSZ, 20,8Mo en RSS).
Je suis surtout surpris du fait que la redirection soit plus lente.
Peut-être qu'en balançant manuellement les headers ça irait plus vite que le
Bottle.redirect().Pourtant je ne fais plus aucune IO disque après le démarrage, dans les deux cas, ça devrait être relativement équivalent.
Bref, après, c'est difficile de comparer les chiffres bruts alors qu'on n'est pas sur la même machine.
[^] # Re: encore ?
Posté par Yth (Mastodon) . En réponse au lien Python 3.11, plus rapide pour de vrai de vrai. Évalué à 3.
Ah, je connaissais pas cette notation, merci !
[^] # Re: Nokia et l'évolution des connecteurs "Apple"
Posté par Yth (Mastodon) . En réponse au journal L'Union européenne va imposer l'USB-C !. Évalué à 9.
Bon, j'ai pas envie de troller Apple plus que de raison, mais c'est un grand classique de la comm Apple de s'attribuer des évolutions technologiques.
La souris n'a pas été inventée par Apple, le smartphone non plus, l'USB non plus, le baladeur mp3 non plus, ni les laptop ultra-légers, ultra-plats, ni la recharge par induction, ni les formes arrondies, ni…. etc.
Alors parfois ce sont effectivement des produits Apple qui ont en premier atteint assez massivement le grand public, mais ils n'en sont pas très souvent réellement à l'origine.
[^] # Re: encore ?
Posté par Yth (Mastodon) . En réponse au lien Python 3.11, plus rapide pour de vrai de vrai. Évalué à 5.
Ah non, tu as mis le code dans la ligne de commande, à la rigueur :
Plus réaliste !
Bravo, le shell gagne donc encore haut la main !
[^] # Re: encore ?
Posté par Yth (Mastodon) . En réponse au lien Python 3.11, plus rapide pour de vrai de vrai. Évalué à 6.
Bilan : 1 personne qui a de l'humour et 3 qui ont été plus lent à coder ce truc avec leur langage de prédilection.
Mais plus sérieusement, mon message indiquait que la rapidité d'écriture du code, sa lisibilité, sa maintenabilité, et même sa concision, sont aussi à prendre en compte dans un projet.
Les perfs brutes, ça sert là où ça sert.
Si tu dois faire des calculs matriciels complexes, numpy est un bon candidat.
Si tu cherches à faire du polling sur une base redis pour lancer un traitement spécifique derrière en fonction des données disponibles, tu vas pas faire ça en C, le python va prendre 5 lignes, et comme le programme passera sa vie en select les ressources seront négligeables.
Si tu veux importer et convertir des fichiers XML vers une base de donnée postgreSQL, franchement, si tu n'y arrives pas en bash (parce que le XML c'est pénible), le python va être royal pour ça.
Pour recoder le système de package de ta distrib, ne sort pas le Go, modernise ton bash et utilise du Python, ou du Ruby si tu connais mieux, le gain potentiel en perf ne vaudra pas la complexité comparative de maintenance.
Mais si tu veux concurrencer l'Unreal Engine, non, fais pas ça en python, choisi plutôt du Rust (par exemple), ou un langage qui va te fournir des primitives efficace pour gérer tes fils d'exécutions parallèles, ta mémoire, tes transferts de mémoire, tes traitements massivement parallélisable sur le GPU, etc.
Le Python n'est pas le meilleur langage pour ça.
Mais bigre, pour du backend web ou de l'API, sérieux, si je ne refais plus jamais du PHP ou du node.js ça sera déjà trop tôt, c'est tellement plus agréable, et rapide, de le faire en Python !