Ce n'est pas FF qui ne passe pas acid3.
Lance avec un profil vierge et tu auras 100%.
Ce sont des addons qui bloquent des trucs et font baisser le test.
J'ai pareil ici sur un FF 102, 97% dans le profil général avec pas mal d'addons sécurité, vie privée et pratiques, mais 100% sur un profil vierge (mon profil vierge a quand même uBlock Origin, donc cet addon indispensable n'est pas bloquant).
Ça peut aussi être des paramètres de sécurité FF, par exemple activer le mode HTTPS-only fait passer à 99%.
Il y a une différence entre un « standard » ou une « bonne pratique » et dire « jetez vos trucs has-been et passez à ce truc top-moumoute moderne qui résout… un problème… peut-être ».
LSB n'a jamais été qu'un guide de bonne pratiques qui a été suivi jusqu'à un certain point par les gens qui voulaient bien le suivre.
Alors le monsieur il fait un billet d'humeur, bah je fais une réponse d'humeur, et parfois les mots sont un poil hyberboliques.
Et alors ?
Je n'essaie de convaincre personne, même pas l'auteur.
flatpack a une logique uniformisante : un gestionnaire de paquet unique en toutes circonstances, non ?
La logique hégémonique vient des gens qui disent qu'on devrait tout virer pour mettre ça à la place.
L'un sans l'autre, à la rigueur, je m'en fous, les deux c'est un brin agressif, hautain genre vous êtes tous has-been.
J'ai mis comme titre une citation du texte : « Unless the packager works around that ». Parlant de différents logiciels ayant besoin de différentes versions d'une dépendance.
On peut donc résumer à ça :
Dans l'enfer actuel des dépendances bordéliques de certaines applications graphiques modernes, le boulot du packager peut devenir compliqué, alors tout ce qui existait avant (le système de package traditionnel) c'est de la merde, faut gicler et utiliser flatpack (ou Nix, soyons ouverts d'esprits) !
Bon, sinon, historiquement, avoir plusieurs versions d'une même dépendance, ça a rarement été un gros problème.
Par exemple :
libpng.so -> libpng16.so
libpng14.so.14 -> libpng14.so.14.22.0
libpng14.so.14.22.0
libpng16.so -> libpng16.so.16.37.0
libpng16.so.16 -> libpng16.so.16.37.0
libpng16.so.16.37.0
Voilà, problème résolu.
Ou encore, les passages de qt4 à qt5 puis qt6, c'est toujours bien transparent, avec plusieurs versions installées en même temps, et chaque logiciel qui sait de laquelle il a besoin.
J'ai quand même envie de dire : « avant » les gens qui faisaient des bibliothèques (ou dépendances, appelez ça comme vous voulez), se foulaient à essayer de faire que ça marche, et qu'on puisse avoir assez facilement en parallèle deux versions différentes lors d'une rupture assez forte de l'api/abi. Ce qui n'a pas toujours été fait de façon propre, et qui a parfois été fait de façon tellement propre qu'on en a voulu aux auteurs de faire chier avec deux versions majeures d'un outil…
Aujourd'hui :
* On laisse faire le gestionnaire de spaghettis, qui tire les dépendances automagiquement, sans se poser de question, et puis comme ça marche pas, on invente des systèmes pour cloisonner tout ça parce que c'est devenu le bordel.
* Alors comme on met du bordel dans des petites boîtes, on se dit qu'un système composé de petites boîte, c'est propre et bien rangé.
* Et on a bien caché le bordel derrière les petites boîtes.
* Et on va considérer que la façon plus propre de faire d'« avant » c'est has-been, faut aller de l'avant et accepter d'avoir de la merde bien rangée.
En tant que vieux con, j'aime bien la sobriété d'avant : se faire chier à inventer des systèmes de bibliothèques partagées, chargées au lancement du programme si elles n'ont pas déjà été chargée par ailleurs, partager l'espace disque, et la mémoire système aussi, pour éviter d'avoir douze fois exactement la même chose, et donc de gaspiller des ressources pour rien.
Mais clairement ce n'est pas à la mode, et il faudrait tout conteneuriser, pour que chaque élément de notre OS embarque dans sa petite boîte l'intégralité de ses dépendances.
Et sous prétexte que ce mode de fonctionnement permettrait d'isoler les différents outils les uns des autres, jusqu'au très bas niveau de l'OS, ça devrait améliorer la sécurité globale du système.
Franchement, je comprends l'argument pour un serveur sur lequel n'importe qui va essayer de faire tourner n'importe quoi n'importe comment.
Mais pour un poste de travail ?
Parce que l'exemple c'est un conflit de nom d'exécutable sur un logiciel pas terriblement libre d'édition de code !
Sous Slackware on a trois paquets dosbox différents, qui naturellement ont tous le même binaire dosbox.
Et ça fonctionne très bien : dosbox est la version stable officielle, dosbox-dev la version de développement à partir des sources (ça a été très utile il y a quelques années quand la dernière version stable avait plus de 8 ans), et dosbox-x, un fork avec des fonctionnalités différentes.
Franchement, le taf du packageur n'est pas mortel hein, renommer les binaires, ya plus complexe…
J'ai quand même envie de lui répondre : « tu te fous de la gueule de qui ? Sérieux ? ».
Mais en vrai, je crois qu'on ne parle pas tous de la même chose. Pas exactement en fait.
Parce qu'il faut bien comprendre à quoi sert une distribution, pourquoi il y en a plusieurs, pourquoi il y en a autant.
Une distribution : c'est une série de choix.
Voilà, c'est tout.
Une distribution ce n'est pas la possibilité de tout faire en toutes circonstances, selon tous les choix possibles et imaginable : elle fait des choix pour toi ta distribution.
Pas tous : tu peux largement la paramétrer, comme la langue, parfois l'environnement graphique (si tu choisis kubuntu c'est pour avoir KDE par exemple, pas pour utiliser Enlightenment).
La majorité des distribs ne te laissent pas le choix du système d'init (quel qu'il soit), ou du serveur audio. C'est pas si souvent qu'on peut basculer facilement entre X.org et Wayland, en général soit une distrib est restée sous X.org, soit elle est passée sous Wayland.
Des choix, que des choix fait pour toi, pour te simplifier la vie.
Un système via conteneurs type flatpak, ou mieux Nix, c'est s'affranchir de la distribution, c'est vouloir fonctionner partout en dehors de toute distribution, c'est faire des choix à la place de la distribution, et donc au final à ta place, puisque ces choix seront fait quelle que soit ta propre distribution.
C'est une logique hégémonique et uniformisante en réalité.
Et ça ne révolutionne strictement rien, il est toujours possible pour un logiciel d'embarquer ses propres versions de certaines bibliothèques, sans soucis, sans flatpak, le système de bibliothèque partagée a résolu ce problème depuis des décennies (cf LD_LIBRARY_PATH), et c'est un peu pour ça que des jeux proprios binaires assez vieux tournent encore, et sans flatpack ou conteneurs…
Bref, encore un type qui chouine sur la non uniformité de l'écosystème Linux, mais sans dire directement « à quoi ça sert d'avoir autant de distrib ? ».
Yth, ça sert à ce que je m'en fous de ton avis, j'utilise mon PC comme je veux, et ça te regarde exactement autant que ce qu'il se passe dans mon assiette, dans ma douche, ou dans mon lit.
Tu peux chiffrer la communication avec un outil comme stunnel.
C'est un bête tunnel SSL/TLS, ta socket locale se connecte localement à stunnel en clair, stunnel local se connecte à stunnel distant en chiffré, et stunnel distant se connecte à ta socket distante localement, en clair.
Et hop, rien ne circule en clair sur le réseau :)
Ça peut servir à faire du mySQL distant, chiffré, sans ouvrir mySQL sur le réseau par exemple.
Les seuls mails que je reçois avec une mise en page vraiment pétée sont ceux incluant des URLs à rallonge, et définis en tant que HTML.
Là, le client mail sur smartphone fait un rendu HTML et rétréci l'affichage pour t'afficher l'URL en entier, c'est illisible.
Le même en texte t'afficherait l'URL sur plusieurs lignes.
La coupure à 78 caractères n'est pas dans tous les mails textes, et va péter un peu la mise en page sur smartphone, tout en laissant lisible, mais bizarre. C'est moche, on est d'accord, gênant parfois.
Quand aux vrais mails enrichis de partout en HTML, très souvent sur smartphone, l'affichage est bien pété, parce que c'est loin d'être toujours pensé pour les écrans peu larges…
Les problèmes du HTML sont multiples, ceux du texte, bah il y en a un.
Alors des sites web avec un travail fait pour différencier le contenu intéressant du reste, une utilisation technique des balises HTML pour les personnes mal-voyantes, etc, oui, on est parfaitement d'accord.
Et du web pur-texte sans aucun système d'enrichissement du texte, même Gemtext/Gemini ne fait pas ça, ça n'aurait pas tellement de sens.
Mais qui va faire ça dans un email ?
Qui a déjà fait ça dans un email ?
Qui a déjà vu ça dans un email ?
Le HTML dans un email ça sert à :
- rajouter du *gras*, de l'/italique/, _souligner_, ou -barrer- ;
- mettre un peu de couleur ;
- faire des liens dont on ne voit pas directement l'URL, mais un texte plus propre et explicatif (idéal pour le phishing) ;
- intégrer une image au milieu du texte plutôt qu'en pièce jointe affichée à la fin du texte ;
- faire d'immondes publipostages ;
- rajouter des signatures de merde avec des images (en texte il y a l'ASCII-Art pour faire de la merde, ça prend autant de place mais moins d'octets, zéro partout, la balle au centre).
Y'a-t-il d'autres cas d'usage réellement utiles ou utilisés ?
Ah bah c'est une question facile ça :
Le format texte, c'est le seul des deux où tu vois directement ce que l'expéditeur a envoyé en entier, sans rien de caché, sans ressources externes qui pourraient foirer, sans dépendre d'un moteur de rendu.
Ou alors tu lis tes mails en HTML par le code source, là tu as le contrôle.
À la réception, tu contrôles vachement mieux ce que tu reçois quand tu le reçois au format texte !
C'est nettement plus simple pour les lecteurs d'écran pour personnes aveugles. Tu peux choisir tes couleurs (texte/fond) de façon générale et sans risquer qu'elles soient pourries, ce qui est utile pour les personnes mal-voyantes, ou atteintes de dyschromatopsie.
C'est lisible sur liseuse ebook connectée à internet, ça se lit aussi bien sur smartphone, écran large, ou notifications système.
Tu choisis si tu veux un affichage monospace ou avec la police que tu veux avec ligatures et tout, bref c'est du texte, tu en fais ce que tu veux.
Gérer du texte c'est toujours moins contraignant que de gérer de l'HTML.
Après, tu peux chipoter sur ces histoires de sauts de ligne, mais en pratique ça ne t'affectera que si ton affichage fait moins de 78 de large (ce qui peut arriver).
Après, si ton client mail gère les mails HTML, il gérera aussi bien les mails texte, avec les mêmes avantages que cités plus haut, donc clairement tu en fera « plus » avec un client mail qui gère le HTML.
En fait, on est en train de parler de mails presque uniquement textuels, envoyés et écrits par des gens pour des gens.
Alors que la critique du mail HTML vient plus des abus et détournements liés au fait qu'il a été jugé plus simple de mélanger client mail et moteur HTML pour faire du mail enrichi.
Je loue l'initiative de ne pas réimplémenter la roue (pourtant retaillée de nombreuses fois depuis avec les bbcode, markdown, et autres syntaxes web non-HTML pour du rendu HTML, mais ça n'est pas le sujet).
Par contre il convient de ne pas se voiler la face sur les conséquences…
Des publipostages souvent assimilables à du spam, lourds avec des traqueurs dans tous les coins, des failles de sécurité à gogo (au fil des âges, pas forcément aujourd'hui, on parle aussi du passif), et une possible perte totale de compatibilité avec le format texte initial (ici on parle de certains mails HTML totalement illisibles sur un client texte).
Après, c'est cool d'avoir du style, de la mise en page, des images etc, dans un mail.
Mais clairement, ça pose infiniment plus de problème que le texte pur.
Et, en pratique, on se passe très bien du HTML dans les mails, la plupart des gens ne voient pas d'autre différence que le fait que l'image lourdingue de leur signature saute lors de mes réponses.
Tu veux dire que ça se comporte comme prévu, c'est à dire qu'un retour à la ligne est un retour à la ligne ?
C'est tout l'intérêt du format texte.
Après, si tu veux laisser le client destinataire gérer la mise en page c'est aussi assez facile, tu règles ton propre éditeur local à la largeur qui te convient, et tu ne sautes pas de ligne en fin de ligne, seulement en fin de paragraphe.
Et chez le client, ça sautera naturellement les lignes en fonction de la largeur de son propre affichage.
C'est sûr que si tu sautes une ligne pour rester sous 80 de large (ou 78), et que le destinataire avec un écran peu large n'en met que 50, ça va lui faire des lignes à 50 puis 30 coupées avant la fin avant de retourner à 50 puis 30, moche et bizarre.
Mais c'est comme les « sites webs optimisés pour le 1024x768 », tu forces la mise en page, donc tu ne laisses pas faire le client, donc ça foire.
T'as tout pareil avec un ordre de grandeur en plus en HTML hein, et depuis toujours, alors même que ça a été pensé à l'origine pour régler ce problème précis et laisser la gestion de la mise en page au client !
Bref, faire du mail textuel ça fonctionne, et on pourrait faire du texte enrichi, mais il aurait fallut un sous-ensemble assez strict du HTML dès l'origine pour que ça fonctionne bien.
Là on a des clients lourds qui intègrent un moteur de rendu HTML (ou plutôt l'inverse : un moteur de rendu HTML utilisé comme client mail, comme les webmails ou même thunderbird), ce qui est salement overkill pour de la transmission de texte enrichi.
… plus sérieusement, ici le sujet ce sont les logiciels libres.
Un lien youtube qui ne concerne pas, de manière générale, les logiciels libres, ça nécessite autre chose que juste un lien et un titre.
En fait ça nécessite un journal, que tu décrives de quoi il s'agit et pourquoi c'est une bonne chose à ton idée.
En l'état c'est juste du spam :(
Et du spam sur youtube en plus !
Return-Path: <expéditeur>
Delivered-To: <destinataire>
Received: from <machine client>
by <serveur SMTP et du blabla>
for <destinataire>;
Tue, 30 Aug 2022 09:50:58 +0000 (UTC)
Date: Tue, 30 Aug 2022 11:50:57 +0200
From: <expéditeur>
To: <destinataire>
Subject: Sujet
Message-Id: <un ID de message>
Organization: <organisation, configurée dans le client mail>
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-slackware-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Corps
Du
Message
Voilà à quoi ça ressemble et ya pas de base64 dedans.
Il s'agit d'un dump caviardé du mail tel que reçu sur le serveur final (auto-mailé via SMTP perso, donc ya qu'un seul SMTP dans la boucle).
Pas de raison d'encoder en base64, le texte, bah c'est du texte et voilà.
Les entêtes c'est « Entete: », une par ligne.
Tu sautes une ligne et le contenu texte commence, sans rien de plus.
Si tu as des accents, donc que le US-ASCII ne suffit pas, ça change tout seul la fin comme ça :
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Ùn méssâgë ên UTF-8
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.
[^] # Re: Moteur!
Posté par Yth (Mastodon) . En réponse au lien Ladybird: un nouveau brouteur multiplateforme. Évalué à 9. Dernière modification le 14 septembre 2022 à 08:46.
Ce n'est pas FF qui ne passe pas acid3.
Lance avec un profil vierge et tu auras 100%.
Ce sont des addons qui bloquent des trucs et font baisser le test.
J'ai pareil ici sur un FF 102, 97% dans le profil général avec pas mal d'addons sécurité, vie privée et pratiques, mais 100% sur un profil vierge (mon profil vierge a quand même uBlock Origin, donc cet addon indispensable n'est pas bloquant).
Ça peut aussi être des paramètres de sécurité FF, par exemple activer le mode HTTPS-only fait passer à 99%.
[^] # Re: Unless the packager works around that
Posté par Yth (Mastodon) . En réponse au lien Traditional Packaging is not Suitable for Modern Applications. Évalué à 5.
Il y a une différence entre un « standard » ou une « bonne pratique » et dire « jetez vos trucs has-been et passez à ce truc top-moumoute moderne qui résout… un problème… peut-être ».
LSB n'a jamais été qu'un guide de bonne pratiques qui a été suivi jusqu'à un certain point par les gens qui voulaient bien le suivre.
Alors le monsieur il fait un billet d'humeur, bah je fais une réponse d'humeur, et parfois les mots sont un poil hyberboliques.
Et alors ?
Je n'essaie de convaincre personne, même pas l'auteur.
[^] # Re: Unless the packager works around that
Posté par Yth (Mastodon) . En réponse au lien Traditional Packaging is not Suitable for Modern Applications. Évalué à 4. Dernière modification le 13 septembre 2022 à 08:55.
flatpack a une logique uniformisante : un gestionnaire de paquet unique en toutes circonstances, non ?
La logique hégémonique vient des gens qui disent qu'on devrait tout virer pour mettre ça à la place.
L'un sans l'autre, à la rigueur, je m'en fous, les deux c'est un brin agressif, hautain genre vous êtes tous has-been.
[^] # Re: Unless the packager works around that
Posté par Yth (Mastodon) . En réponse au lien Traditional Packaging is not Suitable for Modern Applications. Évalué à 2.
Je dirais juste que ça fait longtemps qu'il n'y a plus eu de Core Dumped.
# Unless the packager works around that
Posté par Yth (Mastodon) . En réponse au lien Traditional Packaging is not Suitable for Modern Applications. Évalué à 10. Dernière modification le 11 septembre 2022 à 19:03.
J'ai mis comme titre une citation du texte : « Unless the packager works around that ». Parlant de différents logiciels ayant besoin de différentes versions d'une dépendance.
On peut donc résumer à ça :
Dans l'enfer actuel des dépendances bordéliques de certaines applications graphiques modernes, le boulot du packager peut devenir compliqué, alors tout ce qui existait avant (le système de package traditionnel) c'est de la merde, faut gicler et utiliser flatpack (ou Nix, soyons ouverts d'esprits) !
Bon, sinon, historiquement, avoir plusieurs versions d'une même dépendance, ça a rarement été un gros problème.
Par exemple :
libpng.so -> libpng16.so
libpng14.so.14 -> libpng14.so.14.22.0
libpng14.so.14.22.0
libpng16.so -> libpng16.so.16.37.0
libpng16.so.16 -> libpng16.so.16.37.0
libpng16.so.16.37.0
Voilà, problème résolu.
Ou encore, les passages de qt4 à qt5 puis qt6, c'est toujours bien transparent, avec plusieurs versions installées en même temps, et chaque logiciel qui sait de laquelle il a besoin.
J'ai quand même envie de dire : « avant » les gens qui faisaient des bibliothèques (ou dépendances, appelez ça comme vous voulez), se foulaient à essayer de faire que ça marche, et qu'on puisse avoir assez facilement en parallèle deux versions différentes lors d'une rupture assez forte de l'api/abi. Ce qui n'a pas toujours été fait de façon propre, et qui a parfois été fait de façon tellement propre qu'on en a voulu aux auteurs de faire chier avec deux versions majeures d'un outil…
Aujourd'hui :
* On laisse faire le gestionnaire de spaghettis, qui tire les dépendances automagiquement, sans se poser de question, et puis comme ça marche pas, on invente des systèmes pour cloisonner tout ça parce que c'est devenu le bordel.
* Alors comme on met du bordel dans des petites boîtes, on se dit qu'un système composé de petites boîte, c'est propre et bien rangé.
* Et on a bien caché le bordel derrière les petites boîtes.
* Et on va considérer que la façon plus propre de faire d'« avant » c'est has-been, faut aller de l'avant et accepter d'avoir de la merde bien rangée.
En tant que vieux con, j'aime bien la sobriété d'avant : se faire chier à inventer des systèmes de bibliothèques partagées, chargées au lancement du programme si elles n'ont pas déjà été chargée par ailleurs, partager l'espace disque, et la mémoire système aussi, pour éviter d'avoir douze fois exactement la même chose, et donc de gaspiller des ressources pour rien.
Mais clairement ce n'est pas à la mode, et il faudrait tout conteneuriser, pour que chaque élément de notre OS embarque dans sa petite boîte l'intégralité de ses dépendances.
Et sous prétexte que ce mode de fonctionnement permettrait d'isoler les différents outils les uns des autres, jusqu'au très bas niveau de l'OS, ça devrait améliorer la sécurité globale du système.
Franchement, je comprends l'argument pour un serveur sur lequel n'importe qui va essayer de faire tourner n'importe quoi n'importe comment.
Mais pour un poste de travail ?
Parce que l'exemple c'est un conflit de nom d'exécutable sur un logiciel pas terriblement libre d'édition de code !
Sous Slackware on a trois paquets dosbox différents, qui naturellement ont tous le même binaire dosbox.
Et ça fonctionne très bien : dosbox est la version stable officielle, dosbox-dev la version de développement à partir des sources (ça a été très utile il y a quelques années quand la dernière version stable avait plus de 8 ans), et dosbox-x, un fork avec des fonctionnalités différentes.
Franchement, le taf du packageur n'est pas mortel hein, renommer les binaires, ya plus complexe…
J'ai quand même envie de lui répondre : « tu te fous de la gueule de qui ? Sérieux ? ».
Mais en vrai, je crois qu'on ne parle pas tous de la même chose. Pas exactement en fait.
Parce qu'il faut bien comprendre à quoi sert une distribution, pourquoi il y en a plusieurs, pourquoi il y en a autant.
Une distribution : c'est une série de choix.
Voilà, c'est tout.
Une distribution ce n'est pas la possibilité de tout faire en toutes circonstances, selon tous les choix possibles et imaginable : elle fait des choix pour toi ta distribution.
Pas tous : tu peux largement la paramétrer, comme la langue, parfois l'environnement graphique (si tu choisis kubuntu c'est pour avoir KDE par exemple, pas pour utiliser Enlightenment).
La majorité des distribs ne te laissent pas le choix du système d'init (quel qu'il soit), ou du serveur audio. C'est pas si souvent qu'on peut basculer facilement entre X.org et Wayland, en général soit une distrib est restée sous X.org, soit elle est passée sous Wayland.
Des choix, que des choix fait pour toi, pour te simplifier la vie.
Un système via conteneurs type flatpak, ou mieux Nix, c'est s'affranchir de la distribution, c'est vouloir fonctionner partout en dehors de toute distribution, c'est faire des choix à la place de la distribution, et donc au final à ta place, puisque ces choix seront fait quelle que soit ta propre distribution.
C'est une logique hégémonique et uniformisante en réalité.
Et ça ne révolutionne strictement rien, il est toujours possible pour un logiciel d'embarquer ses propres versions de certaines bibliothèques, sans soucis, sans flatpak, le système de bibliothèque partagée a résolu ce problème depuis des décennies (cf LD_LIBRARY_PATH), et c'est un peu pour ça que des jeux proprios binaires assez vieux tournent encore, et sans flatpack ou conteneurs…
Bref, encore un type qui chouine sur la non uniformité de l'écosystème Linux, mais sans dire directement « à quoi ça sert d'avoir autant de distrib ? ».
[^] # Re: Pourquoi ne pas avoir choisit Intel ??
Posté par Yth (Mastodon) . En réponse au lien La NASA sélectionne RISC-V. Évalué à 7.
La chaleur est importante : comme elle ne s'évacue pas dans le vide, elle s'accumule, et pshiiiit…
[^] # Re: Nan mais...
Posté par Yth (Mastodon) . En réponse au lien Le retour d'e-penser. Évalué à 3.
Lapin ! Compris ?
[^] # Re: Réseau local sûr
Posté par Yth (Mastodon) . En réponse à la dépêche Oubliez les web services, utilisez des tubes nommés. Évalué à 10.
Tu peux chiffrer la communication avec un outil comme stunnel.
C'est un bête tunnel SSL/TLS, ta socket locale se connecte localement à stunnel en clair, stunnel local se connecte à stunnel distant en chiffré, et stunnel distant se connecte à ta socket distante localement, en clair.
Et hop, rien ne circule en clair sur le réseau :)
Ça peut servir à faire du mySQL distant, chiffré, sans ouvrir mySQL sur le réseau par exemple.
[^] # Re: vraiment?
Posté par Yth (Mastodon) . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à 4.
Les seuls mails que je reçois avec une mise en page vraiment pétée sont ceux incluant des URLs à rallonge, et définis en tant que HTML.
Là, le client mail sur smartphone fait un rendu HTML et rétréci l'affichage pour t'afficher l'URL en entier, c'est illisible.
Le même en texte t'afficherait l'URL sur plusieurs lignes.
La coupure à 78 caractères n'est pas dans tous les mails textes, et va péter un peu la mise en page sur smartphone, tout en laissant lisible, mais bizarre. C'est moche, on est d'accord, gênant parfois.
Quand aux vrais mails enrichis de partout en HTML, très souvent sur smartphone, l'affichage est bien pété, parce que c'est loin d'être toujours pensé pour les écrans peu larges…
Les problèmes du HTML sont multiples, ceux du texte, bah il y en a un.
[^] # Re: vraiment?
Posté par Yth (Mastodon) . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à 5.
Alors des sites web avec un travail fait pour différencier le contenu intéressant du reste, une utilisation technique des balises HTML pour les personnes mal-voyantes, etc, oui, on est parfaitement d'accord.
Et du web pur-texte sans aucun système d'enrichissement du texte, même Gemtext/Gemini ne fait pas ça, ça n'aurait pas tellement de sens.
Mais qui va faire ça dans un email ?
Qui a déjà fait ça dans un email ?
Qui a déjà vu ça dans un email ?
Le HTML dans un email ça sert à :
- rajouter
du *gras*, de l'/italique/, _souligner_, ou -barrer-;- mettre un peu de couleur ;
- faire des liens dont on ne voit pas directement l'URL, mais un texte plus propre et explicatif (idéal pour le phishing) ;
- intégrer une image au milieu du texte plutôt qu'en pièce jointe affichée à la fin du texte ;
- faire d'immondes publipostages ;
- rajouter des signatures de merde avec des images (en texte il y a l'ASCII-Art pour faire de la merde, ça prend autant de place mais moins d'octets, zéro partout, la balle au centre).
Y'a-t-il d'autres cas d'usage réellement utiles ou utilisés ?
[^] # Re: vraiment?
Posté par Yth (Mastodon) . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à 3.
Ah bah c'est une question facile ça :
Le format texte, c'est le seul des deux où tu vois directement ce que l'expéditeur a envoyé en entier, sans rien de caché, sans ressources externes qui pourraient foirer, sans dépendre d'un moteur de rendu.
Ou alors tu lis tes mails en HTML par le code source, là tu as le contrôle.
À la réception, tu contrôles vachement mieux ce que tu reçois quand tu le reçois au format texte !
C'est nettement plus simple pour les lecteurs d'écran pour personnes aveugles. Tu peux choisir tes couleurs (texte/fond) de façon générale et sans risquer qu'elles soient pourries, ce qui est utile pour les personnes mal-voyantes, ou atteintes de dyschromatopsie.
C'est lisible sur liseuse ebook connectée à internet, ça se lit aussi bien sur smartphone, écran large, ou notifications système.
Tu choisis si tu veux un affichage monospace ou avec la police que tu veux avec ligatures et tout, bref c'est du texte, tu en fais ce que tu veux.
Gérer du texte c'est toujours moins contraignant que de gérer de l'HTML.
Après, tu peux chipoter sur ces histoires de sauts de ligne, mais en pratique ça ne t'affectera que si ton affichage fait moins de 78 de large (ce qui peut arriver).
Après, si ton client mail gère les mails HTML, il gérera aussi bien les mails texte, avec les mêmes avantages que cités plus haut, donc clairement tu en fera « plus » avec un client mail qui gère le HTML.
[^] # Re: vraiment?
Posté par Yth (Mastodon) . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à 3.
En fait, on est en train de parler de mails presque uniquement textuels, envoyés et écrits par des gens pour des gens.
Alors que la critique du mail HTML vient plus des abus et détournements liés au fait qu'il a été jugé plus simple de mélanger client mail et moteur HTML pour faire du mail enrichi.
Je loue l'initiative de ne pas réimplémenter la roue (pourtant retaillée de nombreuses fois depuis avec les bbcode, markdown, et autres syntaxes web non-HTML pour du rendu HTML, mais ça n'est pas le sujet).
Par contre il convient de ne pas se voiler la face sur les conséquences…
Des publipostages souvent assimilables à du spam, lourds avec des traqueurs dans tous les coins, des failles de sécurité à gogo (au fil des âges, pas forcément aujourd'hui, on parle aussi du passif), et une possible perte totale de compatibilité avec le format texte initial (ici on parle de certains mails HTML totalement illisibles sur un client texte).
Après, c'est cool d'avoir du style, de la mise en page, des images etc, dans un mail.
Mais clairement, ça pose infiniment plus de problème que le texte pur.
Et, en pratique, on se passe très bien du HTML dans les mails, la plupart des gens ne voient pas d'autre différence que le fait que l'image lourdingue de leur signature saute lors de mes réponses.
[^] # Re: Si je comprends
Posté par Yth (Mastodon) . En réponse au lien Cosmopolitan : la libc pour faire des exécutables multi OS (et même sans OS). Évalué à 2.
La compilation se fait en statique, si c'est bien fait ça te fait un gros binaire, mais ya pas de libs externes.
[^] # Re: vraiment?
Posté par Yth (Mastodon) . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à 6.
Tu veux dire que ça se comporte comme prévu, c'est à dire qu'un retour à la ligne est un retour à la ligne ?
C'est tout l'intérêt du format texte.
Après, si tu veux laisser le client destinataire gérer la mise en page c'est aussi assez facile, tu règles ton propre éditeur local à la largeur qui te convient, et tu ne sautes pas de ligne en fin de ligne, seulement en fin de paragraphe.
Et chez le client, ça sautera naturellement les lignes en fonction de la largeur de son propre affichage.
C'est sûr que si tu sautes une ligne pour rester sous 80 de large (ou 78), et que le destinataire avec un écran peu large n'en met que 50, ça va lui faire des lignes à 50 puis 30 coupées avant la fin avant de retourner à 50 puis 30, moche et bizarre.
Mais c'est comme les « sites webs optimisés pour le 1024x768 », tu forces la mise en page, donc tu ne laisses pas faire le client, donc ça foire.
T'as tout pareil avec un ordre de grandeur en plus en HTML hein, et depuis toujours, alors même que ça a été pensé à l'origine pour régler ce problème précis et laisser la gestion de la mise en page au client !
Bref, faire du mail textuel ça fonctionne, et on pourrait faire du texte enrichi, mais il aurait fallut un sous-ensemble assez strict du HTML dès l'origine pour que ça fonctionne bien.
Là on a des clients lourds qui intègrent un moteur de rendu HTML (ou plutôt l'inverse : un moteur de rendu HTML utilisé comme client mail, comme les webmails ou même thunderbird), ce qui est salement overkill pour de la transmission de texte enrichi.
# Nan mais...
Posté par Yth (Mastodon) . En réponse au lien Le retour d'e-penser. Évalué à 7.
… plus sérieusement, ici le sujet ce sont les logiciels libres.
Un lien youtube qui ne concerne pas, de manière générale, les logiciels libres, ça nécessite autre chose que juste un lien et un titre.
En fait ça nécessite un journal, que tu décrives de quoi il s'agit et pourquoi c'est une bonne chose à ton idée.
En l'état c'est juste du spam :(
Et du spam sur youtube en plus !
[^] # Re: vraiment?
Posté par Yth (Mastodon) . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à 2. Dernière modification le 30 août 2022 à 12:02.
Voilà à quoi ça ressemble et ya pas de base64 dedans.
Il s'agit d'un dump caviardé du mail tel que reçu sur le serveur final (auto-mailé via SMTP perso, donc ya qu'un seul SMTP dans la boucle).
Pas de raison d'encoder en base64, le texte, bah c'est du texte et voilà.
Les entêtes c'est « Entete: », une par ligne.
Tu sautes une ligne et le contenu texte commence, sans rien de plus.
Si tu as des accents, donc que le US-ASCII ne suffit pas, ça change tout seul la fin comme ça :
[^] # 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.