Posté par lym .
En réponse à la dépêche Interminable liste de terminaux.
Évalué à 2 (+2/-1).
Dernière modification le 20 octobre 2025 à 10:41.
Car ça permet de travailler en graphique à distance quasiment comme si on était sur la machine sans se traîner la lourdeur d'un bureau complet à travers un VNC/RDP.
Si on choisit un applicatif X léger (terminal, éditeur graphique simple/"indie" ne traînant pas toutes les dépendances d'un DE), c'est très utile.
Il existe même des machines installées headless (car pas de sortie vidéo, ou non utilisée), sur lesquelles du X11 distant est la seule manière de travailler sans ouvrir une tétrachiée de connections dans des terminaux séparés se limitant à des outils texte: On colle sur ces systèmes le paquet xvfb (X11 frame buffer, un paquet minimaliste par ailleurs utilisé en test) et roule.
Tous les cas d'usage que wayland n'a pas voulu voir sans même parler, plus encore à l'heure actuelle, de ne pas avoir construit une nouveauté autour de la pile réseau tout en se permettant de critiquer l'ancêtre qui assurait sur ce point dès les origines à une époque ou les usages réseau étaient pourtant bien moins développés.
Sinon, on peut en effet installer les machines en mode lourdingue avec des DE même sans besoin afin de tirer un bureau complet en bitmap compressé pour utiliser un truc qui a oublié un pan complet dès la spécification avec des auteurs qui s'en tamponnent et se demandent pourquoi leur bidule mets 15 ans à commencer à être accepté…
Dingue d'avoir à expliquer des évidences pareilles.
Je plussoie pour urxvt (aka rxvt-unicode). Sa légèreté fait qu'il couche très bien avec ssh en X11 forwarding (je sais , wayland toussa… mais ça critique l'ancêtre sans assurer un fonctionnement à travers le réseau et c'est quand même incroyable de ne pas avoir cela). Maintenant avec la fibre presque partout on sent moins la différence avec un classique Xterm, mais en ADSL l'ouverture de urxvt était dans la seconde tandis qu'une Xterm c'était 10s.
Je trouve donc aussi dommage qu'il ne soit pas cité même si pas très activement maintenu, mais bon, pourquoi toucher à ce qui fait le job?
L'occasion de découvrir des nouveautés, toutefois…
Bah, ça fait un moment que Korben fait globalement dans le "QUIC & Dirty" niveau publications…
J'ai été un lecteur régulier, mais plus depuis sans doute 10 ans… jusqu'à ce que cette news me rappelle sa simple existence et que je retourne y voir: Clairement, il reste au top de la modernité et semble avoir carrément refilé les clefs du site à une IA?!!
La bascule de ces systèmes s'est faite autour de 2005 (+- 2 ans selon les industriels): On est passé de RTOS type vxWorks à des Linux (alors patché RT) très (puis moins) minimalistes bien entendu sans UI.
2 raisons à cela:
-Linux (boite blanche préférée des chercheurs/universitaires) était toujours le 1er servi pour les nouveaux protocoles réseau et leurs évolutions… et les télécoms tout entiers basculaient hors de trucs conceptuellement intéressants (le dernier en date aura été ATM avec l'UMTS) mais n'ayant jamais percé ailleurs avec à la clef des composants chers (un switch ATM, ouille!), jamais bien déverminés car peu d'utilisateurs, puis une fois dans leur vie commerciale personne ne savait gérer cela pour en tirer le meilleur! A la fin, Ethernet killed'em all, même si la qualité de service y est venu aux forceps et sur le tard il était bien plus économique et simple de surdimensionner en mode désormais switché pour ne jamais avoir de congestion, avec pléthore de gens sachant installer/gérer.
-Moins de besoin RT dur, du fait des évolutions protocolaires et matérielles le code "machine à laver" est passé un peu plus côté DSP (voir carrément dans de la logique programmée de FPGA): Donc les patch full preempt RT suffisaient côté processeur généraliste, voir même un noyau vanilla non patché RT et en faisant de l'affinité CPU on collait le code "machine à laver" dans une scheduler propriétaire séparé tournant à côté selon les choix/habitudes des industriels. On a bien vu des hyperviseurs passer, mais jamais s'imposer dans les choix architecturaux contrairement au monde serveur.
Et, pour en revenir à ma préoccupation, il y a encore pas mal de systèmes (3G voir début 4G) tournant sur des SoC genre PowerQUICC III (de chez Motorola semi-conducteur devenu Freescale puis NXP) avec un unique coeur e500… qui doit transpirer un peu désormais, mais ils sont seront sans doute encore là pour 5 à 10 ans avec un suivi qui demeure.
Dans cet ordre d'idée, il y a encore 2 ans je voyais au grès de mes ballades en campagne/zone peu dense, au pied des antennes de sites relais, des armoires de matériel GSM sur lequel je bossais 25 ans plus tôt et devaient encore contenir des cartes à base de MPC860, qu'un Raspberry PI même 1er du nom ferait passer pour un dinosaure. Mais eux tournaient encore sous vxWorks!
Le FW dans le matériel existe encore… mais quand on peut s'en passer c'est une flash économisée et tout ce qui va avec niveau conception (économie côté PCB, fabrication, test), voir un truc qui peut poser des pb de fiabilité en moins.
Et quand il existe encore, c'est souvent une version assez ancienne voir bugguée: Le BT d'un PI3B quand raspbian avait changé les chemins d'accès aux FW il y a qq années était ainsi devenu hautement instable!
Donc mieux vaut la version à jour chargée au démarrage en remplacement de la "golden" collée à fabrication du composant.
Il semble un peu déçu du nouveau compromis choisi par Debian, mais il faut bien se rendre compte qu'ils n'avaient en fait plus trop le choix: Séparer proprement ce qui était libre, tout en permettant de l'installer si on le souhait explicitement, imposait des médias d'installation ne contenant que des composants "free"…
Si côté vidéo on a des modes de compatibilité/anciens qui permettent généralement une installation sans pilotes libres, a une époque ou bien des cartes réseau et la quasi totalité de celles sans fil, avec des laptops dont le filaire disparaît, requièrent de charger un firmware non libre au démarrage pour pouvoir fonctionner… Debian refusant de les inclure devenait donc difficile à installer sur bien des machines, tout cela pour que derrière les utilisateurs ajoutent le côté "non-free" pour pouvoir tout simplement utiliser ce qu'ils ont acheté.
Leur position est donc pragmatique et on peut dire qu'ils ont lutté longtemps pour ne pas en arriver là…
Vu de haut, on peut quand même se poser la question de l'intérêt de supprimer 1000 lignes de code sur les dizaines de millions du noyau, avec une pénalité de 5% pour des systèmes monoprocesseur qui ne sont certes plus si fréquents… sauf dans l'embarqué, avec des systèmes rentrant dans des infra télécoms et autres trucs à maintenir sur des décennies et qui tournent presque tous sous Linux.
Et là, comme initialement ces systèmes sont taillés pour une charge à 70/80% à la sortie commerciale (faut pas gâcher… sinon un concurrent arrivera à mieux se placer côté prix!) pour monter progressivement jusqu'à plus de 90% avec les ajouts en cours de vie. Eh bien 5%, cela peut sembler peu mais pour beaucoup de ces systèmes suivant les noyaux LTS cela peut ne plus passer. Combiné à un raccourcissement du support de ces noyaux, ce n'est donc pas une très bonne nouvelle.
Ce serait vraiment une très mauvaise nouvelle que Google fasse cela… Surtout qu'avoir toujours eu cette liberté était assez rafraîchissant par rapport à iOS et possiblement un facteur de choix.
Car les téléphones basés AOSP restreignent pas mal le choix d'une part et en prime, à une époque ou les applis banque/double auth dispo uniquement sur le store deviennent quasi inévitables.
Mais perso, en dehors de quelques passages obligés du genre, tout vient de F-Droid.
Un peu étonné que VLC reste si utilisé: Il fut le lecteur audio/vidéo (même si en audio, j'ai jamais décroché de Audacious en interface classique avec son affichage analyseur de spectre vintage style chaine HiFi Technics des années 80… rhaaa, lovely!) se démerdant de quasiment tout ce qui existe en formats/types de flux assez unique en son genre, mais d'autres l'ont depuis rejoint… voir dépassé.
S'il m'arrivait d"avoir de plus en plus de vidéos non lisibles voir qui plantaient ce lecteur, ce qui sonné le glas chez moi fut le fait qu'il soit désormais généré, sur Debian et dérivées, sans le support RTSP à cause d'un pb de licence de la librairie tierce utilisée. Bien tenté d'utiliser un snap mais stabilité désastreuse et lenteurs au lancement, impression d'être chez Microsoft avec chaque soft qui traîne ses dépendances en quasi doublons faute de gestion de paquets intelligente et centralisée, avec des mainteneurs derrière qui remontent ou corrigent les petits soucis éventuellement liés à des versions pas exactement égales à celles testées/utilisées dans les projets tiers…
Comme je ne pouvais me passer du RTSP pour mes cams IP, j'ai alors dû chercher des alternatives et MPV me semble avoir repris un flambeau qui fut celui de VLC: Un truc léger qui lit tout ce qu'on lui donne sans jamais poser de pb de stabilité.
Niveau dépendances, quand on installe MPV sur une Debian à l'origine installé de manière très minimaliste en netinstall, on ne tire que 13 dépendances, essentiellement celles de ffmpeg qui n'est dans ce cadre même pas déjà présent et Python/Lua utilisés par des intégrations externes.
Si on veut y ajouter VLC, on s'en paie 34 de plus alors que le build Debian est depuis 2 versions majeures élagué en fonctionnalités et une tétrachiée de dépendances ne rends clairement pas un projet aisé à maintenir dans le temps…
Peut-être un support un peu plus vaste côté OS pour VLC mais MPV tourne sur au moins Linux/MacOS/Windows (on ajoute les BSD et même Haiku pour VLC, pour MPV a priori pas de BSD ce qui vu d'où vient MacOS parait étrange) côté desktop et il est dispo au moins via F-Droid côté mobile (iOS??? Pas assez pomme pour être client chez eux, mais pour VLC c'est le cas).
J'ai aussi tenté de comprendre ce qui était permis et… a priori c'est totalement limité au bénévolat. Rien sur la gestion plus globale d'une assoc, gérer plus globalement ses membres et leurs actions, une compta voir une interface de paiement des cotisations/dons+bons de défiscalisation annuels et autres paperasseries réellement chronophages.
En plus la doc est écrite en écriture (dite) inclusive imprononçable (et mon credo là dessus, c'est que le rôle premier de l'écriture est de permettre de poser sur papier ce qui s'énonce!): Tous les atours d'un projet politiquement correct pompant de la subvention pour un service même pas digne d'une feuille de tableur bien faite, même si j'espère bien entendu me tromper.
Je pense qu'il vaut mieux partir des dépots source histoire d'avoir les bonnes versions pour ne pas poser de pb au load de modules tiers, patchs Debian éventuels et la config kernel de base à utiliser au make à modifier (make menuconfig) côté CONFIG_X86_64 et tout ce qui en dépends.
Même si en choisissant bien sa version noyau sur kernel.org et en récupérant le /boot/config-XXX-amd64 d'une machine Debian cela devrait pour l'essentiel fonctionner.
Dans les distro basées sur un compte admin qui est en fait sudoer, le compte root s'active d'un "sudo passwd root". Dès que le compte root à un mdp il est utilisable.
Utilisateur/groupe, tout est en fait déjà là et on ne saurait s'en passer de toutes manières.
Il est même assez conseillé de faire cette activation, surtout si on a fait les choses comme il faut à l'install avec une partition home séparée (voir sur un stockage différent): Le "home" du compte root étant /root il sera accroché à la partition racine et donc fonctionnel pour se tirer d'affaire si la partition home a un problème suite à un arrêt brutal (même si un FS journalisé permet généralement de s'en sortir) ou autre: C'est quand même plus simple quand il s'agit de comprendre/résoudre un pb que de devoir utiliser un live-USB et savoir monter les FS à vérifier niveau intégrité, logs…
Mon fixe passé de 12 à 13 me pose également des pb de suspend, avec assez fréquemment des messages pointant la feature lockdown du kernel (pourtant pas nouvelle) qui semble s'activer dès lors que le secure boot est utilisé… Et qui n'est alors pas désactivable entièrement. Cela semble s'ajouter à d'autres problèmes causés par systemd qui refuse aussi le suspend quand certains applicatifs (réseau en particulier) sont lancés, alors qu'avant c'était possible et n'a jamais posé de pb… Cela reprenait juste son cours au réveil.
Exemple de config lockdown sur un système non secure-boot:
Mais sur un système avec secure-boot on sera par défaut à "confidentiality" sans retour en arrière possible et dans ce cadre un swap non chiffré suffit à prévenir le suspend… alors que mon système n'a pas de partition swap, n'en faisant plus sur des machines 100% SSD! A croire que ce cas n'est pas prévu, si toutefois un âne n'a pas décidé que si l'utilisateur ne faisait pas de swap à l'installation on lui créait un fichier destiné à cet usage derrière son dos… A voir, mais ça fait juste hautement chier de chercher des parades à des trucs qu'on évitait sans pb avant.
En secure boot donc, tout au plus peut-on configurer via la kernel-cmdline/grub d'être, au plus permissif, à "integrity" au boot: La désactivation ne sera pas acceptée! Mais de quoi je me mêle? Si un attaquant est déjà root il aura bien plus simple à faire qu'aller lire un swap en clair merde!
Et, niveau config toujours, si sur le runtime qui suit on passe pour test à "confidentiality" via le sysfs ci dessus, effet cliquet: Pas de retour en arrière possible sur le runtime courant, obligé de rebooter.
C'est vraiment une feature assez détestable, comme tout ce qui devient impossible à régler/tester en root. Il y a un moment ou il va falloir que Linux cesse d'évoluer vers des modes prétendument "foolproof" en singeant un android et autres OS qui donnent l'impression qu'on ne possède pus réellement ce qu'on a pourtant acheté.
Hello, niveau compatibles Salae et soft à mettre derrière, des recommandations peut-être? Au boulot, j'ai ponctuellement utilisé pour voir ce qui se passait au démarrage sur des boot flash SPI (et aussi ce que le ME Intel y faisait avant même le laché de reset du côté x86) et j'avais bien apprécié leur matos… bien trop cher pour un usage perso!
"l’IA, mise dans un scénario d’embauche, discrimine… contre les hommes blancs : « When these biases emerge, they consistently favor Black over White candidates and female over male candidates across all tested models and scenarios ». De manière intéressante, la chaîne de pensée n’offre aucune indication de discrimination."
C'est un peu inattendu, mais qqpart c'est sans doute aussi le reflet du DEI omniprésent en entreprise depuis 1 ou 2 décennies. Voir le signe que c'est devenu excessif.
Il serait intéressant de mettre en scénario des suspects dans un commissariat, voir qui est "embauché" en GAV!
J'ajouterais que les Xeon ont un controleur DDR, au delà du support ECC, qui assure un point de fonctionnement qui me semble bien plus fiable que d'autres gammes Intel pour en avoir utilisé en embarqué. Je ne dirais pas que l'ECC n'y est pas utile, mais dans mon expérience beaucoup moins que sur des base Atom qui ont aussi été diffusées pour ce type d'usage: Là, clairement, on a des retours pas fameux et l'ECC ne suffit pas à cacher la misère. On sent vraiment qu'on n'a pas eu le même soin sur cet aspect tiré par le marché serveur.
En prime, on a bcp de fautes multiples (donc non corrigibles à la volée, malgré un support du patrol-scrub dans les 2 cas): En général, avoir une statistique de multiples fautes devant les simples (corrigibles) pointe vers un problème à gérer… le boitier additionnel qui stocke la redondance/ECC (car oui, ajouter un boitier/du matériel, peut entâcher la fiabilité. On garde cependant le bénéfice de l'attribution de la faute de manière plus certaine que partir en exceptions variées/multiples ne pointant pas directement un pb mémoire)!!!
Le BIOS (en réalité le MRC, ou Memory Reference Code de la plateforme fourni par Intel) va s'adapter à ce qu'il a niveau barettes: Elles intègrent une SPD qui est lue par le code qui va faire l'initialisation DDR et lui exposent son interfaçage, ses timings, support ECC….
Le point le plus problématique, ce serait que le BIOS ne reconnaisse pas le CPU changé. Même si c'est base sur la même plateforme (et donc RC Intel), on a toutes chances d'être bridé aux seuls ID des variantes CPU commercialisées à date d'achat de la machine et ça ne démarrera pas avec une variante diffusée plus tard.
Bref, toujours faire une MAJ vers le dernier BIOS fourni par le fabricant si on a une version antérieure avant de changer un CPU.
Possible qu'il y ait ce type de compromis technico-financier. Mais juste après l'article et l'outil de Next permettant de comparer sur sa conso réelle les différentes offres, la possibilité d'interdire ce type de comparaison facilement n'est pas à exclure: Enedis est sans doute resté assez proche d'EDF, qui lui fournit la quasi totalité de l'électricité, les autres fournisseurs étant globalement des coucous profitant d'un système censé faire émerger de la concurrence (en coûtant à EDF qui le répercute, ce qui le handicape) un peu comme cela avait été fait dans les télécoms (en moins bien: Les tarifs au lieu de baisser montent fortement).
Ce qui est assez insupportable, en prime, c'est de voir des API changées sans préavis: Cf les psychodrames en septembre dernier sur les forums domotique quand EDF a stoppé une API ouverte sur les jours Tempo et qu'il a fallu trouver autre chose… chez Enedis! Et là, niveau frugalité, on est passé d'une info couleurs Jour+Lendemain et décompte année Tempo en cours chez EDF à charger l'année complète chez Enedis (et scripter ses compteurs)! Sans compter s'emmerder à refaire ses scripts.
Je ne crois pas avoir eu de pb de C/C via bouton milieu en ssh, l'utilisant bcp en X11 forwarding (une autre tare rhédibitoire de Wayland, pour moi, que de ne pas être construit autour du réseau et de régresser sur des cas d'usage dont j'aurais du mal à me passer) j'étendrais ce constat à tout applicatif distant.
Ca marche juste comme en local, avec bien entendu de la latence selon la connexion réseau.
En tout cas, ce mode de C/C m'a permis de tester la solidité de qq claviers quand je suis contraint à utiliser un windows: C'est vraiment gravé dans le dur de mon cerveau reptilien et quand c'est pas là je retourne un peu à l'état sauvage en actions et jurons!
Posté par lym .
En réponse au journal De la nostalgie du 486.
Évalué à 2.
Dernière modification le 03 juin 2025 à 10:13.
Parcours comparable: Matra Alice (clone de Tandy MC10), CPC6128 avec du hack de jeu également (à une époque ou faire un défaut sur un secteur de disquette, en guise de système anticopie, se faisait par transparence… ou patcher un sautage de la routine de test anti-copie se faisait facilement avec qq rudiments d'assembleur)…
Puis pause (avec qd même un peu de jeu, Genre Flight Simulator à 1 image/s sur l'Apple II des voisins!) de qq années avant assemblage d'un PC base 486DX33 (avec 4Mo de ram et 130Mo de HDD!) en école d'ingé avec des éléments achetés groupés directement à l'importateur taïwanais via le BDE: C'était pas mal de pouvoir bosser un peu chez soi au lieu des salles de l'école pas toujours calmes. En dehors du cadre études, la claque DOOM qu'on est nombreux à avoir connu après un Wolfenstein déjà pas mal, essais d'une RH offert par une revue: Ce plaisir de voir un prompt root à soi pour la première fois… mais c'était pas super niveau support matériel (jamais pu faire marcher le graphique) et ramait pas mal vs DOS+Win 3.1 installés. Il est tombé dans l'oubli, avec qq essais de connection modem analogique via Free, vers 1998.
Puis ensuite, jusque début 2006, je n'ai eu que des PC (et internet) au boulot. L'arrivée des enfants fin 2005 m'avait fait acheter un "transportable" Toshiba Core2Duo et prendre un abo ADSL chez Télé2 ayant de la famille outre-mer qui voulait faire de la visio et Skype marchant, il faut le dire, vraiment bien malgré les réseaux de l'époque surtout quand il s'agissait de passer mers et océans. La photo passée au numérique avait aussi participé à imposer un PC perso. Il a eu du XP+Ubuntu de la 5.X à la 10.04 (après, Ubuntu a commencé à me faire passer plus de temps à virer la mauvaise graisse après install que mettre l'originale Debian minimaliste et ajouter ce dont j'avais réellement besoin, sans compter leurs interfaces graphiques mal branlées).
Ce transportable s'étant révélé peu fiable (dalle KO juste après les 2 ans de garantie, remplacée chèrement puis 3 ans après le GPU Nvidia au BGA visiblement mal brasé imposant de démonter/passer la mobo au four de plus en plus souvent), passage à un barebone Shuttle avec un Core i3 gen3 qui fonctionne encore (il a été ma machine principale pendant 13 ans, avec initialement un double boot win7+Ubuntu et au fil du temps simple boot Debian qui a vu 6 versions passer), je suis passé le mois dernier sur un mini-PC chinois (tout alu, il semble qualitatif, à confirmer dans la durée) basé 6800H (coucou AMD, bye Intel!) en simple boot Debian 12 et le win12 pro préinstallé recyclé en VM, vu qu'a part pour les MAJ du GPS de la bagnole ou des éphémérides GPS de l'APN je n'ai plus aucun usage de windows.
Des noms comme double space et autre Silicon Graphics ne s'oublient pas: La claque dans les labos CNRS de l'école, ça donnait envie de jouer à juste ouvrir et refermer des fenêtres tellement c'était beau vs les Sun à dispo des étudiants ; Sun que j'ai ensuite eu au boulot jusque vers 2005, ou un PC Linux avec une VM Windows (remplacant la Sun pour le dév et le PC Windows pour la bureautique qui trônaient sur tous les bureaux de R&D, désormais remplacés par des laptops windows accédant à des VM cloudifiées)…
J’ajouterais en ces temps pré-internet, ou la poste allait plus vite que les rares modem, "DP-Tool-Club" qui permettait de commander ses disquettes garnies des shareware et freeware de son choix (et chopper ses 1ers virus, l'occasion de les édudier!).
En parallèle, il y a eu un EeePC901 qui fonctionne toujours, 2 mini PC Asrock pour les enfants à partir de la 5ème, 1 Thinkpad X260 acheté d'occase quand le EeePC a commencé à être trop juste (usage vacances), 2 laptops Dell achetés aussi d'occase pour les enfants devenus étudiants: Les laptops grand public sont devenus n'importe quoi niveau construction et je suis passé aux gammes pro reconditionnées: C'est moins cher et s'upgrade/répare toujours au besoin tot en ne faisant pas trop (encore, hélas ca vient) d'économie sur la connectique complète (réseau filaire, USB en nb suffisants) imposant de trimballer tout cela via une rustine USB-C, ce qui a mon sens casse totalement le concept de la machine tout en 1 qui se suffit à elle même.
Ca fait donc 8 machines perso et 12 en comptant les achats pour les enfants.
Niveau smartphones je suis aussi économique avec un GSM Nokia indestructible de 1999 à 2008, puis un E72 nokia jusqu'en 2018. Passage à Android avec un Samsung Xcover 4 qui a fait 2 batteries avant de recycler il y a peu (bloqué à android 9, de plus en plus d'app incompatibles)… quasiment le même avec 2x plus de mémoire/stockage et l'USB-C devenu plus pratique pour la charge que Micro USB: L'ancien Xcover 4s (maj arrêtées à android 11, pas le perdreau de l'année mais déjà bien moins d'incompatibilités) de ma femme qui l'a changé pour du neuf.
J'éviterais d'évoquer le nb de smartphones côté enfants devenus adultes: Ça fait peur, surtout qu'ils ne sont pas vraiment les pires vs leurs proches/amis et je ne loupe jamais une occasion de leur renvoyer les piques qu'ils peuvent adresser au niveau des générations antérieures qui leur laissent une planète soit disant pourrie etc etc…
J'ajouterais que les seules explications que je voit à ces résultats d'enquête, c'est que les gens achètent aussi des voitures qui leur vont (il y a 25/30 ans, en tête de bouchon roulant, vous aviez quasiment 1 chance sur 2 d'avoir une BX avec une file qui s'impatientait derrière! Plus récemment, la Modus a été un véritable appeau à paresseux semblant tombés de leur branche…). Si le client type Prius veut un déplaçoir, il en a en effet pour son argent.
S'il recherchait une certaine modernité, le tableau de bord joliment animé du fonctionnement du système hybride devait lui plaire.
Ne pas sous-estimer non plus la faculté des gens qui ont acheté un truc (ici avec alors un surcoût notable et en espérant se refaire sur la durée) à le défendre, même si c'est pas fameux. Puis faudrait pas décourager la clientèle occase sur laquelle il faudra bien compter un jour! Syndrome de Stockholm de l'acheteur, version intéressée, en qqsorte.
Un conseil, essayez ce genre de véhicule et sur un parcours varié. Idéalement, le louer pour un WE d'escapade peut éviter une erreur… Rien ne vaut son propre avis.
Au moins la C3 ne faisait pas la surprise de ne subitement plus rien avoir dans le sac quand la motorisation combinée ne fait plus (et pas longtemps) illusion, ce que j'avais trouvé carrément dangereux pour ma part.
Pour la Réunion, j'y ait eu de la famille pendant 15 ans et j'y allais 3 semaines tous les 2 ans en moyenne: J'ai eu pas mal de petits modèles en loc, le plus souvent de la 106 puis de la Clio, en petites motorisations essence (le gazole était réputé de mauvaise qualité à la Réunion, import raffiné direct des pays producteurs les plus proches, donc exit le couple du diesel à cylindrée égale) de base (atmo) 1.1 ou 1.4 et aucune ne m'a posé problème à faire avancer sans se trop traîner. Et en descente le frein moteur toujours utilisable évitait de sursolliciter dangereusement le système de freinage.
Si je dis que ce modèle fut un très mauvais souvenir, c'est pas en comparant à des bombinettes. Vraiment, cette bagnole est tout juste bonne à faire le taxi en zone urbaine sans gros relief et pour un chauffeur n'aimant aussi sans doute pas trop conduire!
Au passage WLTP les consos thermiques ont pris 1 à 1.5l/100km selon les modèles: On s'est dans mon expérience perso, qui n'est pas vraiment de l'éco-conduite (et faire le boulet qui emmerde le monde dès qu'on est pas seul) mais avec quand même un effort d'anticipation/restitution (utilisation de la coupure d'injection = km gratis et moins d'usure du freinage), retrouvé assez proche de la réalité.
Note aussi que je bannis les SUV de mes choix, évitant le pb d'une aérodynamique dégradée (et même à Cx comparable, le SCx se prends toujours les 20% de surface frontale en plus d'un SUV vs berline/break), car je continue à rouler vite dès que possible (en ne dépassant désormais les +40km/h ou cela commence à faire cher que dans les coins ou aucun piège n'est possible, cependant) et que l'impact serait vraiment la cata: On voit d'ailleurs beaucoup moins de SUV en Allemagne que chez nous, au passage, AMHA c'est l'effet autoroutes illimitées (dès que 3 voies au moins et hors urbain) qui, plus encore que pour moi, exclu ce choix.
Et au rayon grand bénéficiaire de l'arnaque, un Cayenne Hybride plug-in s'est retrouvé entre 3 et 4l/100km selon version/motorisation (et surtout, qu'on choisisse le V6 ou le V8): Bon courage pour espérer rester sous les 4 à 5x ces chiffres!
A mon sens, le VE n'aurait jamais dû dépasser le 2nd véhicule (inter-)urbain sans gros besoin d'autonomie et ne tombant pas dans le cercle vicieux du poids. Il aurait toujours été temps d'aller au délà si les batteries progressaient vraiment, au point de se retrouver avec un produit 'perte d'autonomie' X 'temps du plein' plus proche d'un thermique…
Le problème, c'est qu'en auto les constructeurs poussent toujours la nouveauté par le HdG plus rentable (à commencer par Tesla avec la model S). Si on avait des politiques réfléchis, on aurait subventionné ce qui avait du sens en faisant une légistation type key-cars (spécificité japonaise) version électrique. Largement rechargées à domicile, il y aurait eu la possibilité de réduire/étaler l'impact infrastructure de recharge/production electrique qui coûte cher. Et la pollution est surtout un pb en ville.
Là on fout du fric par les fenêtres, carrément piqué au voisin via les bonus, pour une chimère qui a passer à l'échelle amènerait a multiplier par 10 ou 15 le nb de points de charge rapide vs pompes actuelles (3 fois moins d'autonomie et 4 à 5 fois plus de temps du plein, le produit traduisant le besoin est dans ces fourchettes) sur les grands axes voie rapide/autoroute (en ville une part de charge domicile réduit le besoin et la conso n'explose pas).
Niveau critère de décision, l'économique compte beaucoup et ça va pas en s'arrangeant avec l'inflation de ces dernières années: Moins d'aides, les ventes s'écroulent.
Globalement, pour un usage au long cours le VE ne tient pas la route et plus il y en aura plus le pb sera insoluble.
"Avant", c'est il y a un an pour un fiasco engagé il y a 3 ans, de l'histoire ancienne pour vous? Bin voyons!!! Je me demande quel progrès vraiment significatif permettrait actuellement au nouveau PDG de Hertz d'y aller? "Once bitten", comme ils disent là bas…
Plus encore pour de la loc qu'un véhicule perso, le client veut de la disponibilité et pas une régression d'un facteur au delà de 10 sur le produit 'perte d'autonomie' X 'temps du plein'.
Et a devoir dans ce cadre compter à 100% sur les charges rapides (on loue rarement à domicile et même les locs de vacances ont commencé la chasse aux pillards de kWh), ne même pas avoir d'avantage économique en prime!
[^] # Re: Linux prêt pour le desktop ?
Posté par lym . En réponse à la dépêche Interminable liste de terminaux. Évalué à 2 (+2/-1). Dernière modification le 20 octobre 2025 à 10:41.
Car ça permet de travailler en graphique à distance quasiment comme si on était sur la machine sans se traîner la lourdeur d'un bureau complet à travers un VNC/RDP.
Si on choisit un applicatif X léger (terminal, éditeur graphique simple/"indie" ne traînant pas toutes les dépendances d'un DE), c'est très utile.
Il existe même des machines installées headless (car pas de sortie vidéo, ou non utilisée), sur lesquelles du X11 distant est la seule manière de travailler sans ouvrir une tétrachiée de connections dans des terminaux séparés se limitant à des outils texte: On colle sur ces systèmes le paquet xvfb (X11 frame buffer, un paquet minimaliste par ailleurs utilisé en test) et roule.
Tous les cas d'usage que wayland n'a pas voulu voir sans même parler, plus encore à l'heure actuelle, de ne pas avoir construit une nouveauté autour de la pile réseau tout en se permettant de critiquer l'ancêtre qui assurait sur ce point dès les origines à une époque ou les usages réseau étaient pourtant bien moins développés.
Sinon, on peut en effet installer les machines en mode lourdingue avec des DE même sans besoin afin de tirer un bureau complet en bitmap compressé pour utiliser un truc qui a oublié un pan complet dès la spécification avec des auteurs qui s'en tamponnent et se demandent pourquoi leur bidule mets 15 ans à commencer à être accepté…
Dingue d'avoir à expliquer des évidences pareilles.
[^] # Re: Linux prêt pour le desktop ?
Posté par lym . En réponse à la dépêche Interminable liste de terminaux. Évalué à 2 (+1/-0).
Je plussoie pour urxvt (aka rxvt-unicode). Sa légèreté fait qu'il couche très bien avec ssh en X11 forwarding (je sais , wayland toussa… mais ça critique l'ancêtre sans assurer un fonctionnement à travers le réseau et c'est quand même incroyable de ne pas avoir cela). Maintenant avec la fibre presque partout on sent moins la différence avec un classique Xterm, mais en ADSL l'ouverture de urxvt était dans la seconde tandis qu'une Xterm c'était 10s.
Je trouve donc aussi dommage qu'il ne soit pas cité même si pas très activement maintenu, mais bon, pourquoi toucher à ce qui fait le job?
L'occasion de découvrir des nouveautés, toutefois…
[^] # Re: C'est drôle les tendances
Posté par lym . En réponse au journal SSH3 n’est pas la suite d’SSH. Évalué à 4 (+3/-0).
Bah, ça fait un moment que Korben fait globalement dans le "QUIC & Dirty" niveau publications…
J'ai été un lecteur régulier, mais plus depuis sans doute 10 ans… jusqu'à ce que cette news me rappelle sa simple existence et que je retourne y voir: Clairement, il reste au top de la modernité et semble avoir carrément refilé les clefs du site à une IA?!!
[^] # Re: Monoprocesseur
Posté par lym . En réponse à la dépêche Sortie du noyau Linux 6.17. Évalué à 4 (+3/-0).
La bascule de ces systèmes s'est faite autour de 2005 (+- 2 ans selon les industriels): On est passé de RTOS type vxWorks à des Linux (alors patché RT) très (puis moins) minimalistes bien entendu sans UI.
2 raisons à cela:
-Linux (boite blanche préférée des chercheurs/universitaires) était toujours le 1er servi pour les nouveaux protocoles réseau et leurs évolutions… et les télécoms tout entiers basculaient hors de trucs conceptuellement intéressants (le dernier en date aura été ATM avec l'UMTS) mais n'ayant jamais percé ailleurs avec à la clef des composants chers (un switch ATM, ouille!), jamais bien déverminés car peu d'utilisateurs, puis une fois dans leur vie commerciale personne ne savait gérer cela pour en tirer le meilleur! A la fin, Ethernet killed'em all, même si la qualité de service y est venu aux forceps et sur le tard il était bien plus économique et simple de surdimensionner en mode désormais switché pour ne jamais avoir de congestion, avec pléthore de gens sachant installer/gérer.
-Moins de besoin RT dur, du fait des évolutions protocolaires et matérielles le code "machine à laver" est passé un peu plus côté DSP (voir carrément dans de la logique programmée de FPGA): Donc les patch full preempt RT suffisaient côté processeur généraliste, voir même un noyau vanilla non patché RT et en faisant de l'affinité CPU on collait le code "machine à laver" dans une scheduler propriétaire séparé tournant à côté selon les choix/habitudes des industriels. On a bien vu des hyperviseurs passer, mais jamais s'imposer dans les choix architecturaux contrairement au monde serveur.
Et, pour en revenir à ma préoccupation, il y a encore pas mal de systèmes (3G voir début 4G) tournant sur des SoC genre PowerQUICC III (de chez Motorola semi-conducteur devenu Freescale puis NXP) avec un unique coeur e500… qui doit transpirer un peu désormais, mais ils sont seront sans doute encore là pour 5 à 10 ans avec un suivi qui demeure.
Dans cet ordre d'idée, il y a encore 2 ans je voyais au grès de mes ballades en campagne/zone peu dense, au pied des antennes de sites relais, des armoires de matériel GSM sur lequel je bossais 25 ans plus tôt et devaient encore contenir des cartes à base de MPC860, qu'un Raspberry PI même 1er du nom ferait passer pour un dinosaure. Mais eux tournaient encore sous vxWorks!
[^] # Re: Debian et non-free
Posté par lym . En réponse à la dépêche 40 ans pour l'informatique libre | Entretien avec Richard Stallman. Évalué à 2 (+1/-0).
Le FW dans le matériel existe encore… mais quand on peut s'en passer c'est une flash économisée et tout ce qui va avec niveau conception (économie côté PCB, fabrication, test), voir un truc qui peut poser des pb de fiabilité en moins.
Et quand il existe encore, c'est souvent une version assez ancienne voir bugguée: Le BT d'un PI3B quand raspbian avait changé les chemins d'accès aux FW il y a qq années était ainsi devenu hautement instable!
Donc mieux vaut la version à jour chargée au démarrage en remplacement de la "golden" collée à fabrication du composant.
# Debian
Posté par lym . En réponse à la dépêche 40 ans pour l'informatique libre | Entretien avec Richard Stallman. Évalué à 3 (+2/-0).
Il semble un peu déçu du nouveau compromis choisi par Debian, mais il faut bien se rendre compte qu'ils n'avaient en fait plus trop le choix: Séparer proprement ce qui était libre, tout en permettant de l'installer si on le souhait explicitement, imposait des médias d'installation ne contenant que des composants "free"…
Si côté vidéo on a des modes de compatibilité/anciens qui permettent généralement une installation sans pilotes libres, a une époque ou bien des cartes réseau et la quasi totalité de celles sans fil, avec des laptops dont le filaire disparaît, requièrent de charger un firmware non libre au démarrage pour pouvoir fonctionner… Debian refusant de les inclure devenait donc difficile à installer sur bien des machines, tout cela pour que derrière les utilisateurs ajoutent le côté "non-free" pour pouvoir tout simplement utiliser ce qu'ils ont acheté.
Leur position est donc pragmatique et on peut dire qu'ils ont lutté longtemps pour ne pas en arriver là…
# Monoprocesseur
Posté par lym . En réponse à la dépêche Sortie du noyau Linux 6.17. Évalué à 7 (+6/-0).
Vu de haut, on peut quand même se poser la question de l'intérêt de supprimer 1000 lignes de code sur les dizaines de millions du noyau, avec une pénalité de 5% pour des systèmes monoprocesseur qui ne sont certes plus si fréquents… sauf dans l'embarqué, avec des systèmes rentrant dans des infra télécoms et autres trucs à maintenir sur des décennies et qui tournent presque tous sous Linux.
Et là, comme initialement ces systèmes sont taillés pour une charge à 70/80% à la sortie commerciale (faut pas gâcher… sinon un concurrent arrivera à mieux se placer côté prix!) pour monter progressivement jusqu'à plus de 90% avec les ajouts en cours de vie. Eh bien 5%, cela peut sembler peu mais pour beaucoup de ces systèmes suivant les noyaux LTS cela peut ne plus passer. Combiné à un raccourcissement du support de ces noyaux, ce n'est donc pas une très bonne nouvelle.
[^] # Re: Avis F-Droid
Posté par lym . En réponse à la dépêche Android n’autorisera plus que les applications des développeurs autorisés. Évalué à 1 (+0/-0).
Bin tout est dit…
# Balle dans le pied...
Posté par lym . En réponse à la dépêche Android n’autorisera plus que les applications des développeurs autorisés. Évalué à 3 (+2/-0).
Ce serait vraiment une très mauvaise nouvelle que Google fasse cela… Surtout qu'avoir toujours eu cette liberté était assez rafraîchissant par rapport à iOS et possiblement un facteur de choix.
Car les téléphones basés AOSP restreignent pas mal le choix d'une part et en prime, à une époque ou les applis banque/double auth dispo uniquement sur le store deviennent quasi inévitables.
Mais perso, en dehors de quelques passages obligés du genre, tout vient de F-Droid.
# VLC..
Posté par lym . En réponse à la dépêche Revue de presse de l’April pour la semaine 38 de l’année 2025. Évalué à 4 (+3/-0).
Un peu étonné que VLC reste si utilisé: Il fut le lecteur audio/vidéo (même si en audio, j'ai jamais décroché de Audacious en interface classique avec son affichage analyseur de spectre vintage style chaine HiFi Technics des années 80… rhaaa, lovely!) se démerdant de quasiment tout ce qui existe en formats/types de flux assez unique en son genre, mais d'autres l'ont depuis rejoint… voir dépassé.
S'il m'arrivait d"avoir de plus en plus de vidéos non lisibles voir qui plantaient ce lecteur, ce qui sonné le glas chez moi fut le fait qu'il soit désormais généré, sur Debian et dérivées, sans le support RTSP à cause d'un pb de licence de la librairie tierce utilisée. Bien tenté d'utiliser un snap mais stabilité désastreuse et lenteurs au lancement, impression d'être chez Microsoft avec chaque soft qui traîne ses dépendances en quasi doublons faute de gestion de paquets intelligente et centralisée, avec des mainteneurs derrière qui remontent ou corrigent les petits soucis éventuellement liés à des versions pas exactement égales à celles testées/utilisées dans les projets tiers…
Comme je ne pouvais me passer du RTSP pour mes cams IP, j'ai alors dû chercher des alternatives et MPV me semble avoir repris un flambeau qui fut celui de VLC: Un truc léger qui lit tout ce qu'on lui donne sans jamais poser de pb de stabilité.
Niveau dépendances, quand on installe MPV sur une Debian à l'origine installé de manière très minimaliste en netinstall, on ne tire que 13 dépendances, essentiellement celles de ffmpeg qui n'est dans ce cadre même pas déjà présent et Python/Lua utilisés par des intégrations externes.
Si on veut y ajouter VLC, on s'en paie 34 de plus alors que le build Debian est depuis 2 versions majeures élagué en fonctionnalités et une tétrachiée de dépendances ne rends clairement pas un projet aisé à maintenir dans le temps…
Peut-être un support un peu plus vaste côté OS pour VLC mais MPV tourne sur au moins Linux/MacOS/Windows (on ajoute les BSD et même Haiku pour VLC, pour MPV a priori pas de BSD ce qui vu d'où vient MacOS parait étrange) côté desktop et il est dispo au moins via F-Droid côté mobile (iOS??? Pas assez pomme pour être client chez eux, mais pour VLC c'est le cas).
[^] # Re: A quoi ça ressemble
Posté par lym . En réponse à la dépêche Sortie de la version 2 de Bénévalibre. Évalué à -2 (+5/-7).
J'ai aussi tenté de comprendre ce qui était permis et… a priori c'est totalement limité au bénévolat. Rien sur la gestion plus globale d'une assoc, gérer plus globalement ses membres et leurs actions, une compta voir une interface de paiement des cotisations/dons+bons de défiscalisation annuels et autres paperasseries réellement chronophages.
En plus la doc est écrite en écriture (dite) inclusive imprononçable (et mon credo là dessus, c'est que le rôle premier de l'écriture est de permettre de poser sur papier ce qui s'énonce!): Tous les atours d'un projet politiquement correct pompant de la subvention pour un service même pas digne d'une feuille de tableur bien faite, même si j'espère bien entendu me tromper.
[^] # Re: fin du support 32 bits
Posté par lym . En réponse à la dépêche Debian GNU/Linux 13 : prêt pour le service. Évalué à 1 (+0/-0).
Je pense qu'il vaut mieux partir des dépots source histoire d'avoir les bonnes versions pour ne pas poser de pb au load de modules tiers, patchs Debian éventuels et la config kernel de base à utiliser au make à modifier (make menuconfig) côté CONFIG_X86_64 et tout ce qui en dépends.
Même si en choisissant bien sa version noyau sur kernel.org et en récupérant le /boot/config-XXX-amd64 d'une machine Debian cela devrait pour l'essentiel fonctionner.
[^] # Re: fin du support 32 bits
Posté par lym . En réponse à la dépêche Debian GNU/Linux 13 : prêt pour le service. Évalué à 2 (+2/-1).
Dans les distro basées sur un compte admin qui est en fait sudoer, le compte root s'active d'un "sudo passwd root". Dès que le compte root à un mdp il est utilisable.
Utilisateur/groupe, tout est en fait déjà là et on ne saurait s'en passer de toutes manières.
Il est même assez conseillé de faire cette activation, surtout si on a fait les choses comme il faut à l'install avec une partition home séparée (voir sur un stockage différent): Le "home" du compte root étant /root il sera accroché à la partition racine et donc fonctionnel pour se tirer d'affaire si la partition home a un problème suite à un arrêt brutal (même si un FS journalisé permet généralement de s'en sortir) ou autre: C'est quand même plus simple quand il s'agit de comprendre/résoudre un pb que de devoir utiliser un live-USB et savoir monter les FS à vérifier niveau intégrité, logs…
[^] # Re: fin du support 32 bits - meme question
Posté par lym . En réponse à la dépêche Debian GNU/Linux 13 : prêt pour le service. Évalué à 5 (+4/-0).
Mon fixe passé de 12 à 13 me pose également des pb de suspend, avec assez fréquemment des messages pointant la feature lockdown du kernel (pourtant pas nouvelle) qui semble s'activer dès lors que le secure boot est utilisé… Et qui n'est alors pas désactivable entièrement. Cela semble s'ajouter à d'autres problèmes causés par systemd qui refuse aussi le suspend quand certains applicatifs (réseau en particulier) sont lancés, alors qu'avant c'était possible et n'a jamais posé de pb… Cela reprenait juste son cours au réveil.
Exemple de config lockdown sur un système non secure-boot:
cat /sys/kernel/security/lockdown
[none] integrity confidentiality
On est alors en "none"=lockdown inactif.
Mais sur un système avec secure-boot on sera par défaut à "confidentiality" sans retour en arrière possible et dans ce cadre un swap non chiffré suffit à prévenir le suspend… alors que mon système n'a pas de partition swap, n'en faisant plus sur des machines 100% SSD! A croire que ce cas n'est pas prévu, si toutefois un âne n'a pas décidé que si l'utilisateur ne faisait pas de swap à l'installation on lui créait un fichier destiné à cet usage derrière son dos… A voir, mais ça fait juste hautement chier de chercher des parades à des trucs qu'on évitait sans pb avant.
En secure boot donc, tout au plus peut-on configurer via la kernel-cmdline/grub d'être, au plus permissif, à "integrity" au boot: La désactivation ne sera pas acceptée! Mais de quoi je me mêle? Si un attaquant est déjà root il aura bien plus simple à faire qu'aller lire un swap en clair merde!
Et, niveau config toujours, si sur le runtime qui suit on passe pour test à "confidentiality" via le sysfs ci dessus, effet cliquet: Pas de retour en arrière possible sur le runtime courant, obligé de rebooter.
C'est vraiment une feature assez détestable, comme tout ce qui devient impossible à régler/tester en root. Il y a un moment ou il va falloir que Linux cesse d'évoluer vers des modes prétendument "foolproof" en singeant un android et autres OS qui donnent l'impression qu'on ne possède pus réellement ce qu'on a pourtant acheté.
# Compatibles Salae
Posté par lym . En réponse au journal Remise en route d'un analyseur logique Philips PM3580. Évalué à 1 (+0/-0).
Hello, niveau compatibles Salae et soft à mettre derrière, des recommandations peut-être? Au boulot, j'ai ponctuellement utilisé pour voir ce qui se passait au démarrage sur des boot flash SPI (et aussi ce que le ME Intel y faisait avant même le laché de reset du côté x86) et j'avais bien apprécié leur matos… bien trop cher pour un usage perso!
# Etrange...
Posté par lym . En réponse à la dépêche Nouvelles sur l’IA de juillet 2025. Évalué à 1.
"l’IA, mise dans un scénario d’embauche, discrimine… contre les hommes blancs : « When these biases emerge, they consistently favor Black over White candidates and female over male candidates across all tested models and scenarios ». De manière intéressante, la chaîne de pensée n’offre aucune indication de discrimination."
C'est un peu inattendu, mais qqpart c'est sans doute aussi le reflet du DEI omniprésent en entreprise depuis 1 ou 2 décennies. Voir le signe que c'est devenu excessif.
Il serait intéressant de mettre en scénario des suspects dans un commissariat, voir qui est "embauché" en GAV!
[^] # Re: RAM
Posté par lym . En réponse au journal Améliorer / upgrader son Lenovo M73 Tiny -> xeon 1275L. Évalué à 3.
J'ajouterais que les Xeon ont un controleur DDR, au delà du support ECC, qui assure un point de fonctionnement qui me semble bien plus fiable que d'autres gammes Intel pour en avoir utilisé en embarqué. Je ne dirais pas que l'ECC n'y est pas utile, mais dans mon expérience beaucoup moins que sur des base Atom qui ont aussi été diffusées pour ce type d'usage: Là, clairement, on a des retours pas fameux et l'ECC ne suffit pas à cacher la misère. On sent vraiment qu'on n'a pas eu le même soin sur cet aspect tiré par le marché serveur.
En prime, on a bcp de fautes multiples (donc non corrigibles à la volée, malgré un support du patrol-scrub dans les 2 cas): En général, avoir une statistique de multiples fautes devant les simples (corrigibles) pointe vers un problème à gérer… le boitier additionnel qui stocke la redondance/ECC (car oui, ajouter un boitier/du matériel, peut entâcher la fiabilité. On garde cependant le bénéfice de l'attribution de la faute de manière plus certaine que partir en exceptions variées/multiples ne pointant pas directement un pb mémoire)!!!
[^] # Re: RAM
Posté par lym . En réponse au journal Améliorer / upgrader son Lenovo M73 Tiny -> xeon 1275L. Évalué à 3.
Le BIOS (en réalité le MRC, ou Memory Reference Code de la plateforme fourni par Intel) va s'adapter à ce qu'il a niveau barettes: Elles intègrent une SPD qui est lue par le code qui va faire l'initialisation DDR et lui exposent son interfaçage, ses timings, support ECC….
Le point le plus problématique, ce serait que le BIOS ne reconnaisse pas le CPU changé. Même si c'est base sur la même plateforme (et donc RC Intel), on a toutes chances d'être bridé aux seuls ID des variantes CPU commercialisées à date d'achat de la machine et ça ne démarrera pas avec une variante diffusée plus tard.
Bref, toujours faire une MAJ vers le dernier BIOS fourni par le fabricant si on a une version antérieure avant de changer un CPU.
[^] # Re: La raison est sans doute ailleurs
Posté par lym . En réponse au journal L'informatique manque de frugalité. Évalué à 3. Dernière modification le 03 juin 2025 à 11:00.
Possible qu'il y ait ce type de compromis technico-financier. Mais juste après l'article et l'outil de Next permettant de comparer sur sa conso réelle les différentes offres, la possibilité d'interdire ce type de comparaison facilement n'est pas à exclure: Enedis est sans doute resté assez proche d'EDF, qui lui fournit la quasi totalité de l'électricité, les autres fournisseurs étant globalement des coucous profitant d'un système censé faire émerger de la concurrence (en coûtant à EDF qui le répercute, ce qui le handicape) un peu comme cela avait été fait dans les télécoms (en moins bien: Les tarifs au lieu de baisser montent fortement).
Ce qui est assez insupportable, en prime, c'est de voir des API changées sans préavis: Cf les psychodrames en septembre dernier sur les forums domotique quand EDF a stoppé une API ouverte sur les jours Tempo et qu'il a fallu trouver autre chose… chez Enedis! Et là, niveau frugalité, on est passé d'une info couleurs Jour+Lendemain et décompte année Tempo en cours chez EDF à charger l'année complète chez Enedis (et scripter ses compteurs)! Sans compter s'emmerder à refaire ses scripts.
[^] # Re: wl-clipboard
Posté par lym . En réponse au journal Enfin une utilité au presse-papier synchrone de X11. Évalué à 4.
Je ne crois pas avoir eu de pb de C/C via bouton milieu en ssh, l'utilisant bcp en X11 forwarding (une autre tare rhédibitoire de Wayland, pour moi, que de ne pas être construit autour du réseau et de régresser sur des cas d'usage dont j'aurais du mal à me passer) j'étendrais ce constat à tout applicatif distant.
Ca marche juste comme en local, avec bien entendu de la latence selon la connexion réseau.
En tout cas, ce mode de C/C m'a permis de tester la solidité de qq claviers quand je suis contraint à utiliser un windows: C'est vraiment gravé dans le dur de mon cerveau reptilien et quand c'est pas là je retourne un peu à l'état sauvage en actions et jurons!
# Ça rajeunit pas!
Posté par lym . En réponse au journal De la nostalgie du 486. Évalué à 2. Dernière modification le 03 juin 2025 à 10:13.
Parcours comparable: Matra Alice (clone de Tandy MC10), CPC6128 avec du hack de jeu également (à une époque ou faire un défaut sur un secteur de disquette, en guise de système anticopie, se faisait par transparence… ou patcher un sautage de la routine de test anti-copie se faisait facilement avec qq rudiments d'assembleur)…
Puis pause (avec qd même un peu de jeu, Genre Flight Simulator à 1 image/s sur l'Apple II des voisins!) de qq années avant assemblage d'un PC base 486DX33 (avec 4Mo de ram et 130Mo de HDD!) en école d'ingé avec des éléments achetés groupés directement à l'importateur taïwanais via le BDE: C'était pas mal de pouvoir bosser un peu chez soi au lieu des salles de l'école pas toujours calmes. En dehors du cadre études, la claque DOOM qu'on est nombreux à avoir connu après un Wolfenstein déjà pas mal, essais d'une RH offert par une revue: Ce plaisir de voir un prompt root à soi pour la première fois… mais c'était pas super niveau support matériel (jamais pu faire marcher le graphique) et ramait pas mal vs DOS+Win 3.1 installés. Il est tombé dans l'oubli, avec qq essais de connection modem analogique via Free, vers 1998.
Puis ensuite, jusque début 2006, je n'ai eu que des PC (et internet) au boulot. L'arrivée des enfants fin 2005 m'avait fait acheter un "transportable" Toshiba Core2Duo et prendre un abo ADSL chez Télé2 ayant de la famille outre-mer qui voulait faire de la visio et Skype marchant, il faut le dire, vraiment bien malgré les réseaux de l'époque surtout quand il s'agissait de passer mers et océans. La photo passée au numérique avait aussi participé à imposer un PC perso. Il a eu du XP+Ubuntu de la 5.X à la 10.04 (après, Ubuntu a commencé à me faire passer plus de temps à virer la mauvaise graisse après install que mettre l'originale Debian minimaliste et ajouter ce dont j'avais réellement besoin, sans compter leurs interfaces graphiques mal branlées).
Ce transportable s'étant révélé peu fiable (dalle KO juste après les 2 ans de garantie, remplacée chèrement puis 3 ans après le GPU Nvidia au BGA visiblement mal brasé imposant de démonter/passer la mobo au four de plus en plus souvent), passage à un barebone Shuttle avec un Core i3 gen3 qui fonctionne encore (il a été ma machine principale pendant 13 ans, avec initialement un double boot win7+Ubuntu et au fil du temps simple boot Debian qui a vu 6 versions passer), je suis passé le mois dernier sur un mini-PC chinois (tout alu, il semble qualitatif, à confirmer dans la durée) basé 6800H (coucou AMD, bye Intel!) en simple boot Debian 12 et le win12 pro préinstallé recyclé en VM, vu qu'a part pour les MAJ du GPS de la bagnole ou des éphémérides GPS de l'APN je n'ai plus aucun usage de windows.
Des noms comme double space et autre Silicon Graphics ne s'oublient pas: La claque dans les labos CNRS de l'école, ça donnait envie de jouer à juste ouvrir et refermer des fenêtres tellement c'était beau vs les Sun à dispo des étudiants ; Sun que j'ai ensuite eu au boulot jusque vers 2005, ou un PC Linux avec une VM Windows (remplacant la Sun pour le dév et le PC Windows pour la bureautique qui trônaient sur tous les bureaux de R&D, désormais remplacés par des laptops windows accédant à des VM cloudifiées)…
J’ajouterais en ces temps pré-internet, ou la poste allait plus vite que les rares modem, "DP-Tool-Club" qui permettait de commander ses disquettes garnies des shareware et freeware de son choix (et chopper ses 1ers virus, l'occasion de les édudier!).
En parallèle, il y a eu un EeePC901 qui fonctionne toujours, 2 mini PC Asrock pour les enfants à partir de la 5ème, 1 Thinkpad X260 acheté d'occase quand le EeePC a commencé à être trop juste (usage vacances), 2 laptops Dell achetés aussi d'occase pour les enfants devenus étudiants: Les laptops grand public sont devenus n'importe quoi niveau construction et je suis passé aux gammes pro reconditionnées: C'est moins cher et s'upgrade/répare toujours au besoin tot en ne faisant pas trop (encore, hélas ca vient) d'économie sur la connectique complète (réseau filaire, USB en nb suffisants) imposant de trimballer tout cela via une rustine USB-C, ce qui a mon sens casse totalement le concept de la machine tout en 1 qui se suffit à elle même.
Ca fait donc 8 machines perso et 12 en comptant les achats pour les enfants.
Niveau smartphones je suis aussi économique avec un GSM Nokia indestructible de 1999 à 2008, puis un E72 nokia jusqu'en 2018. Passage à Android avec un Samsung Xcover 4 qui a fait 2 batteries avant de recycler il y a peu (bloqué à android 9, de plus en plus d'app incompatibles)… quasiment le même avec 2x plus de mémoire/stockage et l'USB-C devenu plus pratique pour la charge que Micro USB: L'ancien Xcover 4s (maj arrêtées à android 11, pas le perdreau de l'année mais déjà bien moins d'incompatibilités) de ma femme qui l'a changé pour du neuf.
J'éviterais d'évoquer le nb de smartphones côté enfants devenus adultes: Ça fait peur, surtout qu'ils ne sont pas vraiment les pires vs leurs proches/amis et je ne loupe jamais une occasion de leur renvoyer les piques qu'ils peuvent adresser au niveau des générations antérieures qui leur laissent une planète soit disant pourrie etc etc…
[^] # Re: Que faire après plusieurs mauvaises expériences ?
Posté par lym . En réponse au journal 1 an en véhicule électrique uniquement. Évalué à 1.
J'ajouterais que les seules explications que je voit à ces résultats d'enquête, c'est que les gens achètent aussi des voitures qui leur vont (il y a 25/30 ans, en tête de bouchon roulant, vous aviez quasiment 1 chance sur 2 d'avoir une BX avec une file qui s'impatientait derrière! Plus récemment, la Modus a été un véritable appeau à paresseux semblant tombés de leur branche…). Si le client type Prius veut un déplaçoir, il en a en effet pour son argent.
S'il recherchait une certaine modernité, le tableau de bord joliment animé du fonctionnement du système hybride devait lui plaire.
Ne pas sous-estimer non plus la faculté des gens qui ont acheté un truc (ici avec alors un surcoût notable et en espérant se refaire sur la durée) à le défendre, même si c'est pas fameux. Puis faudrait pas décourager la clientèle occase sur laquelle il faudra bien compter un jour! Syndrome de Stockholm de l'acheteur, version intéressée, en qqsorte.
Un conseil, essayez ce genre de véhicule et sur un parcours varié. Idéalement, le louer pour un WE d'escapade peut éviter une erreur… Rien ne vaut son propre avis.
[^] # Re: Que faire après plusieurs mauvaises expériences ?
Posté par lym . En réponse au journal 1 an en véhicule électrique uniquement. Évalué à 1.
Au moins la C3 ne faisait pas la surprise de ne subitement plus rien avoir dans le sac quand la motorisation combinée ne fait plus (et pas longtemps) illusion, ce que j'avais trouvé carrément dangereux pour ma part.
Pour la Réunion, j'y ait eu de la famille pendant 15 ans et j'y allais 3 semaines tous les 2 ans en moyenne: J'ai eu pas mal de petits modèles en loc, le plus souvent de la 106 puis de la Clio, en petites motorisations essence (le gazole était réputé de mauvaise qualité à la Réunion, import raffiné direct des pays producteurs les plus proches, donc exit le couple du diesel à cylindrée égale) de base (atmo) 1.1 ou 1.4 et aucune ne m'a posé problème à faire avancer sans se trop traîner. Et en descente le frein moteur toujours utilisable évitait de sursolliciter dangereusement le système de freinage.
Si je dis que ce modèle fut un très mauvais souvenir, c'est pas en comparant à des bombinettes. Vraiment, cette bagnole est tout juste bonne à faire le taxi en zone urbaine sans gros relief et pour un chauffeur n'aimant aussi sans doute pas trop conduire!
[^] # Re: 40500 km
Posté par lym . En réponse au journal 1 an en véhicule électrique uniquement. Évalué à 1.
Au passage WLTP les consos thermiques ont pris 1 à 1.5l/100km selon les modèles: On s'est dans mon expérience perso, qui n'est pas vraiment de l'éco-conduite (et faire le boulet qui emmerde le monde dès qu'on est pas seul) mais avec quand même un effort d'anticipation/restitution (utilisation de la coupure d'injection = km gratis et moins d'usure du freinage), retrouvé assez proche de la réalité.
Note aussi que je bannis les SUV de mes choix, évitant le pb d'une aérodynamique dégradée (et même à Cx comparable, le SCx se prends toujours les 20% de surface frontale en plus d'un SUV vs berline/break), car je continue à rouler vite dès que possible (en ne dépassant désormais les +40km/h ou cela commence à faire cher que dans les coins ou aucun piège n'est possible, cependant) et que l'impact serait vraiment la cata: On voit d'ailleurs beaucoup moins de SUV en Allemagne que chez nous, au passage, AMHA c'est l'effet autoroutes illimitées (dès que 3 voies au moins et hors urbain) qui, plus encore que pour moi, exclu ce choix.
Et au rayon grand bénéficiaire de l'arnaque, un Cayenne Hybride plug-in s'est retrouvé entre 3 et 4l/100km selon version/motorisation (et surtout, qu'on choisisse le V6 ou le V8): Bon courage pour espérer rester sous les 4 à 5x ces chiffres!
A mon sens, le VE n'aurait jamais dû dépasser le 2nd véhicule (inter-)urbain sans gros besoin d'autonomie et ne tombant pas dans le cercle vicieux du poids. Il aurait toujours été temps d'aller au délà si les batteries progressaient vraiment, au point de se retrouver avec un produit 'perte d'autonomie' X 'temps du plein' plus proche d'un thermique…
Le problème, c'est qu'en auto les constructeurs poussent toujours la nouveauté par le HdG plus rentable (à commencer par Tesla avec la model S). Si on avait des politiques réfléchis, on aurait subventionné ce qui avait du sens en faisant une légistation type key-cars (spécificité japonaise) version électrique. Largement rechargées à domicile, il y aurait eu la possibilité de réduire/étaler l'impact infrastructure de recharge/production electrique qui coûte cher. Et la pollution est surtout un pb en ville.
Là on fout du fric par les fenêtres, carrément piqué au voisin via les bonus, pour une chimère qui a passer à l'échelle amènerait a multiplier par 10 ou 15 le nb de points de charge rapide vs pompes actuelles (3 fois moins d'autonomie et 4 à 5 fois plus de temps du plein, le produit traduisant le besoin est dans ces fourchettes) sur les grands axes voie rapide/autoroute (en ville une part de charge domicile réduit le besoin et la conso n'explose pas).
Niveau critère de décision, l'économique compte beaucoup et ça va pas en s'arrangeant avec l'inflation de ces dernières années: Moins d'aides, les ventes s'écroulent.
Globalement, pour un usage au long cours le VE ne tient pas la route et plus il y en aura plus le pb sera insoluble.
[^] # Re: Que faire après plusieurs mauvaises expériences ?
Posté par lym . En réponse au journal 1 an en véhicule électrique uniquement. Évalué à -1.
"Avant", c'est il y a un an pour un fiasco engagé il y a 3 ans, de l'histoire ancienne pour vous? Bin voyons!!! Je me demande quel progrès vraiment significatif permettrait actuellement au nouveau PDG de Hertz d'y aller? "Once bitten", comme ils disent là bas…
Plus encore pour de la loc qu'un véhicule perso, le client veut de la disponibilité et pas une régression d'un facteur au delà de 10 sur le produit 'perte d'autonomie' X 'temps du plein'.
Et a devoir dans ce cadre compter à 100% sur les charges rapides (on loue rarement à domicile et même les locs de vacances ont commencé la chasse aux pillards de kWh), ne même pas avoir d'avantage économique en prime!