Il y a des contrôleurs mémoire qui font cette ré-écriture (opération dite de "scrubbing") automatiquement (sinon le handler EDAC devra s'en charger) quand une erreur détectée/corrigée à la volée sur un load (data) ou fetch (instruction).
Certains font même en sorte que des données (ou du code) peu utilisé ne passent pas au travers et que des erreurs single-bit/corrigibles soient alors "rattrapées par la patrouille", faute d'usage fréquent (détection/correction ne se font sinon que sur une lecture en mémoire rappelons le!), avant de potentiellement s'aggraver avec le temps en erreurs multi-bit alors non corrigibles: Cela s'appelle le "patrol scrub".
On peut aussi le faire en soft, mais que le matériel s'en charge est toujours mieux car cela n'occupe pas le processeur d'une part mais en prime le contrôleur mémoire est le mieux placé pour caser des tranches mémoire de lecture (et correction éventuelle) à un moment optimal/ou on a de la bande passante vers la DDR et donc ne pas impacter les perfs.
Pour ce patrol scrubbing, quand on l'active on a généralement un objectif de périodicité du parcours de la mémoire complet. Chez Intel c'est par défaut 24h par exemple.
Et même en cas d'erreur non corrigible, il est possible de pousser plus loin mais c'est alors des fonctionnalités OS: La zone est elle mappée par le kernel ou un process, donc utilisée? Si ce n'est pas le cas, aucun impact et on peut continuer. On peut aussi avoir encore une copie valide de la donnée, au hasard dans un cache (L1/L2 ou plateforme) et dans ce cas on a une copie valide à simplement flusher en mémoire. Au delà, si c'est dans un process applicatif on peut choisir de le tuer en moindre mal d'un reboot complet, qui dans les autres cas en règle générale s'imposera.
J'en retiendrais aussi les provisions patch/callback périodique qui ont été bien utiles pour la reproduction et le patch sans ajouter le risque de flinguer la ROM… a noter que les compilateurs peuvent proposer des possibilités de cet ordre (par exemple gcc et son -finstrument-functions permettant d'appeler une fonction d'instru, par défaut un simple retour à l'appelant, à chaque appel de fonction de son code ; impact perf mais en général dans ce contexte c'est pas forcément le principal souci).
Le truc qui fait bien tilter qd même: L'EDAC qui n'a eu qu'une revue de code (qui a dit que ça ne servait bien trop souvent qu'à se chamailler sur la forme sans trouver les pb de fond?) pour test par le fournisseur! Dans ce contexte, aie-aie-aie, mais je reconnais bien là les pratiques toujours en cours sur la gestion des soft "3rd party". Aie confiance, crois en moi ((c) Le Livre de la Jungle!)…
Les mecs n'ont pas trop cherché quand même car il y a forcément un moyen de tester cela (pour les propres besoins du fondeur), même si ici le processeur ne semblait pas implémenter une véritable injection d'erreur comme c'est le cas sur tout ce que j'ai pu voir (à base PPC/x86/ARM) comme contrôleur DDRx.
Surtout que 5000 pages, en fait, c'est pas grand chose de nos jours: Les premiers SoC PowerPC sur lesquels j'ai travaillé à la fin des années 90 (famille MPC860) devaient en être à peu près à ce chiffre pour la totalité du contenu des différents contrôleurs intégrés hors jeu d'instruction. Les derniers (famille QorIQ), on devait en avoir 1 de ce volume par IP conséquente intégrée (contrôleurs, différents accélérateurs, système de trace/debug intégré…) et peut-être 5 ou 6 en tout! Là clairement, le boulot de généraliste type support/validation devenait assez difficile sans un bon carnet d'adresse en interne et chez les FAE du fondeur.
Maintenant, les pb apparus après tout changement touchant au build (version, options), j'ai également qq souvenirs… Jusqu'à même tomber sur un errata processeur alors non documenté, via un changement dans l'allocation des registres généraux, qui faisait au gré des build parfois tomber dans une instruction qui fournissait un résultat dans le registre d'à côté de celui de l'opcode (correct) généré.
Actuellement, c'est les 1GB du PI3B qui gère la baraque… un peu à l'étroit car des tmpfs ajoutés et des modifs de config mémoire virtuelle (visant à regrouper au max les écritures) pour économiser la SD sont un peu consommateurs. Même dû récemment changer qq réglages de l'OOM-killer afin qu'il commence à faire du ménage moins vite.
Côté PC, je suis longtemps resté à 8GB, depuis 2012 en fait avec un barebone Shuttle toujours fonctionnel malgré ses 13 ans et qui n'a connu que win7 en double boot puis Debian seul, qui se satisfaisait toujours très bien de cette mémoire. Il a encore un lecteur/graveur optique donc je le conserve pour quand j'ai encore un truc pas rippé qui ressort d'un tiroir…
32GB sur un mini-PC acheté au printemps dernier, devenu machine principale, toujours sous Debian et avec la licence win11 incluse recyclée en VM (plus de double boot, vu le peu d'usage que j'ai de windows ces 15 dernières années).
Historiquement, 4kB sur le rebranding Matra d'un Tandy MC10 (Alice) qui fut mon 1er ordi. Avant un CPC6128 (128kB, l’opulence!) sur lequel j'avais fait mes premières armes de déplombage de jeux avec un pote de collège puis un PC monté en école d'ingé: 486DX33 avec 4MB de ram (luxe absolu!) et 130MB de HDD. Je suis ensuite resté presque 10 ans sans PC après mes études (être sur une Sun toute la journée me donnait guère envie de continuer le soir!) pour reprendre un laptop Toshiba (Core Duo) avec 1GB de ram et 100GB de HDD, qui m'aura bien fait chier malgré une marque réputée fiable entre l'écran tout juste hors garantie puis les défauts de brasure du GPU intégré: Après qq passages au four en sauvetage temporaire il avait fini à la déchetterie ce qui est unique chez moi: Même 2 netbook en machine d'appoint sont toujours là et fonctionnels ayant juste reçu une barrette de 2GB après achat. Hélas, les distros continuant à proposer une version 32b deviennent rares…
L'évolution actuelle des prix va j'espère inciter à en revenir à meilleure frugalité (de ma première machine à la dernière, on a un facteur dépassant 8M niveau évolution de la taille de RAM!)… et j'espère aussi contrarier les plans de Microsoft destiné à provoquer des changements de machine avec les requis win11 car prolonger les machines, au vu de l'explosion des coûts DDR et stockage, risque de s'imposer pour un nombre croissant d'utilisateurs. Si toutefois on n'en arrive pas à des mots d'ordre du genre "pour baisser le coût de la vie, cramez des DC": On parle beaucoup des besoins en DDR/Flash, mais la conso électrique pèse déjà dans certains pays lourdement sur les prix. Pas encore dans un pays de révolution plutôt que d'évolution comme le nôtre, mais cela viendra au vu du nb de projets en cours recyclant (avec le dixième d'emplois locaux, au mieux) opportunément d'anciens sites industriels bien raccordés électriquement.
Bin tu iras expliquer cela aux flics et vigiles de centres commerciaux pas loin des gares Transilien/RER, qui ont a gérer les bandes qui viennent faire de véritables pillages organisés réguliers… quand ils ne tombent pas sur ceux du quartier rival ayant eu la même idée, ou ayant simplement eu vent de la descente et ayant un contentieux à régler, auquel cas ça fini alors en baston!
Ta négation de la réalité va les distraire…
Ce qui est étonnant, c'est que celui qui a construit ces images de bootflash à base de coreboot ait eu les firmwares Intel non signés qui y entrent. Coreboot n'a normalement accès qu'au blob binaire permettant les inits de base (Plateforme/PCH, contrôleur DDR), ce qui correspond en fait au duo RC/MRC (Reference Code/Memory Ref. Code) qu'Intel fourni en version source uniquement aux membres de la triade AMI/Insyde/Phoenix, eh oui les bios sont une mafia :o)
Mais pour construire une image bios qui démarre, il faut aussi en 1er lieu le ME (management engine) voir des FW de contrôleurs "complexes" genre réseau typiquement.
Et le pb, c'est que ces FW sont signés à leur 1ère exécution avec l'ID unique du processeur… donc ou oublie de les récupérer sur un dump d'une mobo pour réutilisation sur une mobo identique!
Sans eux, c'est délicat… a moins que les Chromebooks soient gérés différemment, par exemple car gogole l'aura demandé et représentait un marché motivant Intel à déroger?
Le rapport, c'est quand même un peu cause => conséquence. Et, pour le côté a-prioris, il y a des très beaux immeubles dans de beaux quartiers… certes à distance idéale des TC (qui draine la racaille, désolé mais c'est une réalité) cad "ni trop près ni trop loin" et valent souvent, vu leur localisation, bien plus que ces pavillons que les "écolos chapelle indigéniste" fustigent: C'est vrai quoi, avoir un jardin, avec des nids pour les mésanges qui bouffent les processionnaires qui pullulent, s'occuper de placer des abris et nourrir une portée tardive de hérissons pour qu'elle passe l'hiver… C'est d'une classe que tout le monde n'a visiblement pas.
Maintenant, pour avoir vécu mes 20 premières années dans un quartier ayant pourri à vue d'oeuil entre la fin des années 70 et le début des années 80 jusqu’à l'apothéose d'avoir gagné la célébrité en ayant été le début des affaires de voiles islamiques dans l'enseignement, je vais te faire une confidence:
Avant, les gens jouaient avec la carte scolaire voir (en dernier recours quand les fins de mois sont déjà difficiles) envoyaient leurs enfants dans le privé pour éviter certains établissements ou ils ne voulaient pas voir leurs enfants. Pour la carte scolaire, on y a mis un coup d'arrêt.
Et il s'est passé quoi à ton avis: Tous ceux qui pouvaient quitter ces quartiers les ont quitté: Quand ce n'était déjà fait pour eux mêmes les enfants à scolariser ont été le déclic.
La conséquence, c'est que si la réputation d'un collège/lycée peut s'améliorer dans le temps (souvent avec un changement de proviseur d'ailleurs) entre l’aîné et le petit dernier… et faisait arrêter les jeux de cartes. Bin quand la part de gens qui se souciaient de leur progéniture un peu plus que la moyenne "allocations braguettes" est parti, c'est clairement pas pour revenir un jour!!! Ballot.
Je peux te dire que les bascules liées à la scolarité, ça fait tomber un quartier très bas très vite et qu'avec ces cartes scolaires qu'on a gravé dans le marbre illustrent fort bien le dicton "l'enfer est pave de bonnes intentions". Ici la limite est ce que leurs enfants c'est ce que les gens ont de plus précieux. Si cela t’arrive un jour et que tu es proprio, un conseil, n'attends pas 5 ans pour vendre ce sera déjà trop tard: C'est vraiment le signal qu'il faut se tirer encore plus vite que si on loue car dans ce 2nd cas on y laisse moins de plumes.
Quelques années plus tard j'ai pu voir les mêmes conséquences de décisions de ce genre dans le quartier pavillonnaire du (presque rural!) plateau de Vitry S/Seine. En prime ils ont désormais un beau tram qui a piqué la moitié des voies de l'ex N7 et vu fermer tous les sous terrains sous carrefours qui vous amenaient aux portes de Paris avec très peu de feux rouges.
Eux cumulent, niveau "rêve"… ou "fais de beaux cauchemars"?
Ces barrières mémoire, en général appelées d'une primitive assembleur inline, sont également très utilisées en programmation bas niveau.
Classiquement, quand on initialise un contrôleur matériel quelconque on a une tétrachiée de registres de configuration à initialiser avant de mettre un bit d'activation dans un registre de contrôle.
Et si l'ordre précis d'écriture de la tétra-chiée de configs contrôleur off n'importe généralement pas, tout ceci doit être fait avant que le bit d'activation qui va les faire prendre en compte par le matériel ne soit écrit.
C'est par exemple le rôle de la bien nommée instruction "eieio" sur PowerPC par exemple: https://en.wikipedia.org/wiki/Enforce_In-order_Execution_of_I/O
Il y avait d'autres primitives de synchronisation sur cette architecture, mais c'était la moins coûteuse en perf… car elle n'obligeait même pas à faire de suite les accès antérieurs. Juste que quand ce serait le cas, les accès qui suivraient le eieio seraient faite après ceux qui le précédaient.
Si on voulait pouvoir utiliser le matériel juste après (certitude que l'activation soit passée!), mieux valait avoir mis un "mbar 0" ou "msync" (selon les versions de PPC, c'est des alias) juste derrière l'écriture du bit d'activation :o)
Et au delà du load/store, on avait des primitives de synchro côté fetch aussi.
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.
[^] # Re: Pourquoi le matériel ne corrige pas directement la mémoire ?
Posté par lym . En réponse à la dépêche « It works on my satellite » ou l'histoire d'un bug dans l'espace. Évalué à 2 (+1/-0).
Il y a des contrôleurs mémoire qui font cette ré-écriture (opération dite de "scrubbing") automatiquement (sinon le handler EDAC devra s'en charger) quand une erreur détectée/corrigée à la volée sur un load (data) ou fetch (instruction).
Certains font même en sorte que des données (ou du code) peu utilisé ne passent pas au travers et que des erreurs single-bit/corrigibles soient alors "rattrapées par la patrouille", faute d'usage fréquent (détection/correction ne se font sinon que sur une lecture en mémoire rappelons le!), avant de potentiellement s'aggraver avec le temps en erreurs multi-bit alors non corrigibles: Cela s'appelle le "patrol scrub".
On peut aussi le faire en soft, mais que le matériel s'en charge est toujours mieux car cela n'occupe pas le processeur d'une part mais en prime le contrôleur mémoire est le mieux placé pour caser des tranches mémoire de lecture (et correction éventuelle) à un moment optimal/ou on a de la bande passante vers la DDR et donc ne pas impacter les perfs.
Pour ce patrol scrubbing, quand on l'active on a généralement un objectif de périodicité du parcours de la mémoire complet. Chez Intel c'est par défaut 24h par exemple.
Et même en cas d'erreur non corrigible, il est possible de pousser plus loin mais c'est alors des fonctionnalités OS: La zone est elle mappée par le kernel ou un process, donc utilisée? Si ce n'est pas le cas, aucun impact et on peut continuer. On peut aussi avoir encore une copie valide de la donnée, au hasard dans un cache (L1/L2 ou plateforme) et dans ce cas on a une copie valide à simplement flusher en mémoire. Au delà, si c'est dans un process applicatif on peut choisir de le tuer en moindre mal d'un reboot complet, qui dans les autres cas en règle générale s'imposera.
# Merci pour ce partage!
Posté par lym . En réponse à la dépêche « It works on my satellite » ou l'histoire d'un bug dans l'espace. Évalué à 4 (+3/-0). Dernière modification le 12 janvier 2026 à 11:06.
J'en retiendrais aussi les provisions patch/callback périodique qui ont été bien utiles pour la reproduction et le patch sans ajouter le risque de flinguer la ROM… a noter que les compilateurs peuvent proposer des possibilités de cet ordre (par exemple gcc et son -finstrument-functions permettant d'appeler une fonction d'instru, par défaut un simple retour à l'appelant, à chaque appel de fonction de son code ; impact perf mais en général dans ce contexte c'est pas forcément le principal souci).
Le truc qui fait bien tilter qd même: L'EDAC qui n'a eu qu'une revue de code (qui a dit que ça ne servait bien trop souvent qu'à se chamailler sur la forme sans trouver les pb de fond?) pour test par le fournisseur! Dans ce contexte, aie-aie-aie, mais je reconnais bien là les pratiques toujours en cours sur la gestion des soft "3rd party". Aie confiance, crois en moi ((c) Le Livre de la Jungle!)…
Les mecs n'ont pas trop cherché quand même car il y a forcément un moyen de tester cela (pour les propres besoins du fondeur), même si ici le processeur ne semblait pas implémenter une véritable injection d'erreur comme c'est le cas sur tout ce que j'ai pu voir (à base PPC/x86/ARM) comme contrôleur DDRx.
Surtout que 5000 pages, en fait, c'est pas grand chose de nos jours: Les premiers SoC PowerPC sur lesquels j'ai travaillé à la fin des années 90 (famille MPC860) devaient en être à peu près à ce chiffre pour la totalité du contenu des différents contrôleurs intégrés hors jeu d'instruction. Les derniers (famille QorIQ), on devait en avoir 1 de ce volume par IP conséquente intégrée (contrôleurs, différents accélérateurs, système de trace/debug intégré…) et peut-être 5 ou 6 en tout! Là clairement, le boulot de généraliste type support/validation devenait assez difficile sans un bon carnet d'adresse en interne et chez les FAE du fondeur.
Maintenant, les pb apparus après tout changement touchant au build (version, options), j'ai également qq souvenirs… Jusqu'à même tomber sur un errata processeur alors non documenté, via un changement dans l'allocation des registres généraux, qui faisait au gré des build parfois tomber dans une instruction qui fournissait un résultat dans le registre d'à côté de celui de l'opcode (correct) généré.
# Récent... et moins récent!
Posté par lym . En réponse au sondage Quelle quantité de RAM ai-je sur ma machine principale ?. Évalué à 3 (+2/-0).
Actuellement, c'est les 1GB du PI3B qui gère la baraque… un peu à l'étroit car des tmpfs ajoutés et des modifs de config mémoire virtuelle (visant à regrouper au max les écritures) pour économiser la SD sont un peu consommateurs. Même dû récemment changer qq réglages de l'OOM-killer afin qu'il commence à faire du ménage moins vite.
Côté PC, je suis longtemps resté à 8GB, depuis 2012 en fait avec un barebone Shuttle toujours fonctionnel malgré ses 13 ans et qui n'a connu que win7 en double boot puis Debian seul, qui se satisfaisait toujours très bien de cette mémoire. Il a encore un lecteur/graveur optique donc je le conserve pour quand j'ai encore un truc pas rippé qui ressort d'un tiroir…
32GB sur un mini-PC acheté au printemps dernier, devenu machine principale, toujours sous Debian et avec la licence win11 incluse recyclée en VM (plus de double boot, vu le peu d'usage que j'ai de windows ces 15 dernières années).
Historiquement, 4kB sur le rebranding Matra d'un Tandy MC10 (Alice) qui fut mon 1er ordi. Avant un CPC6128 (128kB, l’opulence!) sur lequel j'avais fait mes premières armes de déplombage de jeux avec un pote de collège puis un PC monté en école d'ingé: 486DX33 avec 4MB de ram (luxe absolu!) et 130MB de HDD. Je suis ensuite resté presque 10 ans sans PC après mes études (être sur une Sun toute la journée me donnait guère envie de continuer le soir!) pour reprendre un laptop Toshiba (Core Duo) avec 1GB de ram et 100GB de HDD, qui m'aura bien fait chier malgré une marque réputée fiable entre l'écran tout juste hors garantie puis les défauts de brasure du GPU intégré: Après qq passages au four en sauvetage temporaire il avait fini à la déchetterie ce qui est unique chez moi: Même 2 netbook en machine d'appoint sont toujours là et fonctionnels ayant juste reçu une barrette de 2GB après achat. Hélas, les distros continuant à proposer une version 32b deviennent rares…
L'évolution actuelle des prix va j'espère inciter à en revenir à meilleure frugalité (de ma première machine à la dernière, on a un facteur dépassant 8M niveau évolution de la taille de RAM!)… et j'espère aussi contrarier les plans de Microsoft destiné à provoquer des changements de machine avec les requis win11 car prolonger les machines, au vu de l'explosion des coûts DDR et stockage, risque de s'imposer pour un nombre croissant d'utilisateurs. Si toutefois on n'en arrive pas à des mots d'ordre du genre "pour baisser le coût de la vie, cramez des DC": On parle beaucoup des besoins en DDR/Flash, mais la conso électrique pèse déjà dans certains pays lourdement sur les prix. Pas encore dans un pays de révolution plutôt que d'évolution comme le nôtre, mais cela viendra au vu du nb de projets en cours recyclant (avec le dixième d'emplois locaux, au mieux) opportunément d'anciens sites industriels bien raccordés électriquement.
[^] # Re: rien de neuf malheureusement
Posté par lym . En réponse au journal Les irresponsables. Évalué à -1.
Bin tu iras expliquer cela aux flics et vigiles de centres commerciaux pas loin des gares Transilien/RER, qui ont a gérer les bandes qui viennent faire de véritables pillages organisés réguliers… quand ils ne tombent pas sur ceux du quartier rival ayant eu la même idée, ou ayant simplement eu vent de la descente et ayant un contentieux à régler, auquel cas ça fini alors en baston!
Ta négation de la réalité va les distraire…
[^] # Re: ====
Posté par lym . En réponse au journal Déverrouillage d'un Chromebook. Évalué à 2.
Ce qui est étonnant, c'est que celui qui a construit ces images de bootflash à base de coreboot ait eu les firmwares Intel non signés qui y entrent. Coreboot n'a normalement accès qu'au blob binaire permettant les inits de base (Plateforme/PCH, contrôleur DDR), ce qui correspond en fait au duo RC/MRC (Reference Code/Memory Ref. Code) qu'Intel fourni en version source uniquement aux membres de la triade AMI/Insyde/Phoenix, eh oui les bios sont une mafia :o)
Mais pour construire une image bios qui démarre, il faut aussi en 1er lieu le ME (management engine) voir des FW de contrôleurs "complexes" genre réseau typiquement.
Et le pb, c'est que ces FW sont signés à leur 1ère exécution avec l'ID unique du processeur… donc ou oublie de les récupérer sur un dump d'une mobo pour réutilisation sur une mobo identique!
Sans eux, c'est délicat… a moins que les Chromebooks soient gérés différemment, par exemple car gogole l'aura demandé et représentait un marché motivant Intel à déroger?
[^] # Re: rien de neuf malheureusement
Posté par lym . En réponse au journal Les irresponsables. Évalué à 0.
Le rapport, c'est quand même un peu cause => conséquence. Et, pour le côté a-prioris, il y a des très beaux immeubles dans de beaux quartiers… certes à distance idéale des TC (qui draine la racaille, désolé mais c'est une réalité) cad "ni trop près ni trop loin" et valent souvent, vu leur localisation, bien plus que ces pavillons que les "écolos chapelle indigéniste" fustigent: C'est vrai quoi, avoir un jardin, avec des nids pour les mésanges qui bouffent les processionnaires qui pullulent, s'occuper de placer des abris et nourrir une portée tardive de hérissons pour qu'elle passe l'hiver… C'est d'une classe que tout le monde n'a visiblement pas.
Maintenant, pour avoir vécu mes 20 premières années dans un quartier ayant pourri à vue d'oeuil entre la fin des années 70 et le début des années 80 jusqu’à l'apothéose d'avoir gagné la célébrité en ayant été le début des affaires de voiles islamiques dans l'enseignement, je vais te faire une confidence:
Avant, les gens jouaient avec la carte scolaire voir (en dernier recours quand les fins de mois sont déjà difficiles) envoyaient leurs enfants dans le privé pour éviter certains établissements ou ils ne voulaient pas voir leurs enfants. Pour la carte scolaire, on y a mis un coup d'arrêt.
Et il s'est passé quoi à ton avis: Tous ceux qui pouvaient quitter ces quartiers les ont quitté: Quand ce n'était déjà fait pour eux mêmes les enfants à scolariser ont été le déclic.
La conséquence, c'est que si la réputation d'un collège/lycée peut s'améliorer dans le temps (souvent avec un changement de proviseur d'ailleurs) entre l’aîné et le petit dernier… et faisait arrêter les jeux de cartes. Bin quand la part de gens qui se souciaient de leur progéniture un peu plus que la moyenne "allocations braguettes" est parti, c'est clairement pas pour revenir un jour!!! Ballot.
Je peux te dire que les bascules liées à la scolarité, ça fait tomber un quartier très bas très vite et qu'avec ces cartes scolaires qu'on a gravé dans le marbre illustrent fort bien le dicton "l'enfer est pave de bonnes intentions". Ici la limite est ce que leurs enfants c'est ce que les gens ont de plus précieux. Si cela t’arrive un jour et que tu es proprio, un conseil, n'attends pas 5 ans pour vendre ce sera déjà trop tard: C'est vraiment le signal qu'il faut se tirer encore plus vite que si on loue car dans ce 2nd cas on y laisse moins de plumes.
Quelques années plus tard j'ai pu voir les mêmes conséquences de décisions de ce genre dans le quartier pavillonnaire du (presque rural!) plateau de Vitry S/Seine. En prime ils ont désormais un beau tram qui a piqué la moitié des voies de l'ex N7 et vu fermer tous les sous terrains sous carrefours qui vous amenaient aux portes de Paris avec très peu de feux rouges.
Eux cumulent, niveau "rêve"… ou "fais de beaux cauchemars"?
# Fondamental aussi en logiciel de base...
Posté par lym . En réponse au journal Barrières mémoire et buffers circulaires - Un résultat inattendu. Évalué à 2.
Ces barrières mémoire, en général appelées d'une primitive assembleur inline, sont également très utilisées en programmation bas niveau.
Classiquement, quand on initialise un contrôleur matériel quelconque on a une tétrachiée de registres de configuration à initialiser avant de mettre un bit d'activation dans un registre de contrôle.
Et si l'ordre précis d'écriture de la tétra-chiée de configs contrôleur off n'importe généralement pas, tout ceci doit être fait avant que le bit d'activation qui va les faire prendre en compte par le matériel ne soit écrit.
C'est par exemple le rôle de la bien nommée instruction "eieio" sur PowerPC par exemple:
https://en.wikipedia.org/wiki/Enforce_In-order_Execution_of_I/O
Il y avait d'autres primitives de synchronisation sur cette architecture, mais c'était la moins coûteuse en perf… car elle n'obligeait même pas à faire de suite les accès antérieurs. Juste que quand ce serait le cas, les accès qui suivraient le eieio seraient faite après ceux qui le précédaient.
Si on voulait pouvoir utiliser le matériel juste après (certitude que l'activation soit passée!), mieux valait avoir mis un "mbar 0" ou "msync" (selon les versions de PPC, c'est des alias) juste derrière l'écriture du bit d'activation :o)
Et au delà du load/store, on avait des primitives de synchro côté fetch aussi.
[^] # Re: Linux prêt pour le desktop ?
Posté par lym . En réponse à la dépêche Interminable liste de terminaux. Évalué à 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.
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.
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é à 8.
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.
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.
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é à 8.
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.
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.
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.
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.
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.
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.
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.
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.
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.