Sommaire

• • Son coût
  • L'usage
  • Le temps de charge
  • L'entretien
  • Satisfait

J'ai entendu sur France Inter que les ventes de voitures électriques stagnent. D'après une étude, cela serait dû à des croyances sur leur bilan écologique. Une berline avec 60 kWh de batterie, comparée à son équivalent thermique, produira deux fois moins de CO₂ durant sa vie, de l'usine à la casse. Oui, la batterie ajoute du CO₂ à la construction, comme toute augmentation de poids, mais cela n'efface pas du tout les gains suivants.

Je veux vous faire part de mon retour d'expérience après un an en berline électrique et plusieurs années en citadine électrique.
Coûts, autonomie et usage au quotidien

Son coût

Leur prix est souvent montré du doigt. Il y a un an (cela a changé depuis), un bonus écologique s'appliquait aux voitures de moins de 45 000 €. Chaque constructeur avait son modèle sous ce seuil. Cela donnait une facture de 36 à 40 000 €.

Cela représente le double du budget de ma précédente voiture d’il y a 12 ans, je n’étais pas prêt. Une voiture thermique équivalente était facturée 32 000 €, mais avec un entretien annuel à payer, plus l'essence. En 2 ou 3 ans, la différence de prix est effacée.

Les voitures sont simplement devenues plus coûteuses.

L'usage

Les berlines électriques, avec 60 kWh de batterie, sont assez imposantes : 1,7 à 2 tonnes, une garde au sol basse, et une largeur de plus de 2 m. Les batteries prennent de la place. Cela racle dans certaines rampes de parking ou au-dessus d’un gendarme couché avec 4 personnes.

Ces batteries offrent autour de 400 km d'autonomie. Cela varie avec le poids et l'aérodynamisme. La consommation varie entre 13 et 20 kWh aux 100 km. Pour information, il y a 10 kWh d’énergie thermique dans 1 l d’essence (12 pour le diesel, et 8 pour l’éthanol, l’E85).

Les batteries de 80 ou 100 kWh sont évidemment bien plus lourdes, offrent plus d’autonomie et se chargent un peu plus rapidement.

À l’usage, l’autonomie n’est pas le plus important. Seule la vitesse de charge l’est vraiment. 15 min pour gagner 300 km d’autonomie n’a rien à voir avec 45. Si on respecte l’arrêt de repos toutes les 2 h lors des longs trajets, on a besoin de 200 km d’autonomie plus une marge. Les 4 h 30 de charge de la citadine ne posent pas de souci la nuit, mais ce n’est pas viable sur la route.

Une voiture électrique consomme par km et selon sa vitesse. Les embouteillages ne consomment rien. Par contre, l’autoroute oui. Les véhicules avec un bon S.Cx ne voient pas de différence entre le 110 et le 130 km/h (donc pas les SUV).

Les montées consomment, mais pas les descentes ; en comptant les deux, cela revient presque à du plat.

Le GPS intégré de ma voiture estime correctement sa consommation. J’avais un peu peur du "km-marketing" (unité équivalente à 850 ou 900 m). Ainsi, les recharges sont proposées dans le trajet. La voiture anticipe en chauffant la batterie pour augmenter la vitesse de charge. D’ailleurs, à froid, la voiture désactive la récupération d’énergie, et on sent bien son poids au freinage.

En montagne, après une semaine de parking et un déneigement, la voiture a perdu 12 kWh de charge. À cause du froid, la charge au freinage était limitée, mais la descente n’a presque rien consommé (1 % en 30 minutes).

La voiture présente plein de statistiques autour de la consommation. Je n’ai pas encore pu vérifier si les pertes à l’arrêt sont comptées. J’aimerais pouvoir comparer les kWh rentrés depuis la prise aux kilomètres parcourus.

La voiture consomme à l’arrêt, souvent sous votre contrôle : surveillance (10 %/jour !), chauffage du matin (2 % ? Mais c’est trop bien), autodécharge.
Recharge, contraintes techniques et confort d’utilisation

Sur un long trajet, j’utilise l’application ABRP pour choisir les arrêts afin de manger pendant la recharge, à la bonne heure. L’application permet de choisir entre des arrêts courts fréquents ou plus espacés.

Elle peut aussi servir à vérifier qu’un trajet que vous comptez faire souvent est bien équipé en bornes.

Le temps de charge

J’ai déjà fait un voyage de 3000 km dans l’est sans souci pour recharger. Pour aller en montagne, j’ai rechargé avant de monter. Le pire que j’ai attendu, c’est 15 min pour avoir une borne de recharge, moins que mes pires souvenirs de file à la station-service.

Les prix vont de 0,30 à 0,60 €/kWh selon l’heure et le réseau utilisé, soit 20 € le plein. À la maison, cela revient à 7 € en tarif de nuit (7,60 € en tarif rouge heure creuse). Les plages horaires se programment facilement, mais un effort pourrait être fait pour que la voiture optimise seule le coût de la charge.

Cela ne m’est jamais arrivé de chercher une borne en centre-ville, mais je connais quelqu’un qui a tourné longtemps à Lyon car les places avec bornes étaient occupées par des voitures garées.

Pour le quotidien, le branchement à la maison est un confort par rapport au thermique. Je charge une fois et demie par semaine, en gros une nuit et le week-end (22 000 km/an). J’essaie d’avoir une charge complète par semaine pour que la batterie équilibre ses éléments — c’est une recommandation constructeur. Il n’est pas conseillé de charger à plus de 8 A (2 kW) depuis une prise classique : ce n’est pas fait pour une telle puissance en continu, et cela chauffe. Les rallonges sont proscrites car le câble a un capteur de température pour couper en cas de surchauffe : il ne peut pas détecter la température de l’autre côté.

À la maison, j’ai une prise simple spécifique Legrand de 13 A (3 kW), il existe maintenant des prises 16 A au même prix. Une borne 7 kW coûte de 500 à 1000 €.

Avec un peu d’anticipation, on gère deux véhicules sur cette prise.

Le câble classique 220 V fourni se comporte comme une borne de recharge. On devrait donc pouvoir intervertir les câbles des deux voitures, mais on n’a jamais essayé.

Vu que le câble est vu comme une borne, une borne communique avec la voiture. On branche donc le 220 V en premier et on le retire en dernier. Sinon, la voiture en déduit qu’il y a une coupure de courant. En pratique, cela ne change pas grand-chose.

Il n’y a plus que la norme de prise CCS type 2 (et le 220 V) qui est présente partout. Les superchargeurs rajoutent 2 fiches supplémentaires (1000 V) “CCS type 2 combo”, mais restent physiquement compatibles avec l’ancienne norme.

Une borne de recharge de base se limite à 32 A en triphasé pour certaines voitures (3×32×230) soit 22 kW. Le triphasé ou le 32 A n’est pas forcément supporté. Cela limite à 11 kW (3×16×230) ou 14 kW (64×220). Mais ces modes de charge ont peu d’intérêt à mes yeux : trop rapides pour une nuit, trop lents sur la route. En plus, il faut le compteur EDF et le contrat adaptés. Un gros rouleur avec une grosse batterie y trouvera peut-être un intérêt (>400 km/jour).

La puissance max de charge ne présume pas du temps de charge total. C’est uniquement le point de départ. Certaines voitures commencent à 250 kW mais baissent vite et sont plus lentes au 20%-80 % que des voitures dont le pic ne dépasse pas 170 kW. Il faut vraiment regarder le temps de charge réel d’un modèle (voiture-propre.fr) pour l’évaluer.

Les superchargeurs annoncent 150, 250, 400 kW. C’est le maximum pour une borne, mais aussi pour un groupe de 2 ou 4 bornes. Donc, vous êtes tranquilles à 140 kW sur la borne “3a” annoncée à 150, mais limitée par la voiture, puis une autre voiture se branche à la borne “3b” et vous tombez à 75 kW. La charge finit autour de 20 kW, donc cela ne double pas le temps de charge, mais on peut perdre 5 min.

Il est parfois difficile de connaître le prix d’une borne dans la rue : le tarif n’est jamais marqué dessus, seulement dans les applications. Il y a encore peu de bornes payables directement par carte bleue, et dans ce cas, vous ne connaissez pas le tarif appliqué. Pourquoi ne peut-on pas avoir le prix affiché et payer en CB ou autre carte, comme pour l’essence ?

Si on ne peut pas charger sa voiture chez soi, cela me semble problématique, surtout que les charges rapides usent la batterie plus rapidement.

Enedis commence à faire des accords avec les copropriétés pour mettre une prise et un compteur aux places de parking. Je pense que c’est vraiment le frein principal pour choisir un VE.

L'entretien

La voiture a beaucoup moins de rendez-vous techniques qu’une thermique, sa mécanique étant simple. Même les freins s’usent peu, le freinage par récupération d’énergie étant très puissant.

Il faut signaler l’absence de roue de secours. Si le cric est mal positionné, on pourrait percer la batterie et provoquer un incendie. Cela fait aussi du poids mort supplémentaire et de la batterie en moins. Beaucoup de constructeurs de voitures électriques ne la proposent pas.

Satisfait

Globalement, je n’ai pas envie de revenir en arrière. Les odeurs d’hydrocarbures ou d’échappement ne me manquent pas du tout. Le silence est appréciable, surtout à basse vitesse. Et les voitures sont performantes et amusantes à conduire.

Cet article relate un exemple avec deux voitures, j’imagine que l’on peut avoir des expériences différentes, que je vous propose de partager en commentaires.

• Source de composition de prix de CO₂ pour une voiture électrique et une voiture thermique - https://cumin.univ-lille.fr/fact-sheets/acv-des-vehicules-electriques-in-french
• ENEDIS : la recharge des véhicules dans les copropriétés - https://www.enedis.fr/mobilite-electrique-enedis-accompagne-la-recharge-des-vehicules-dans-les-coproprietes
• ABRP en ligne - https://abetterrouteplanner.com/
• Temps de charge d'une voiture ("Automobile propre") - https://www.automobile-propre.com/simulateur-temps-de-recharge-voiture-electrique/

Commentaires : voir le flux Atom ouvrir dans le navigateur

LinuxFr.org : seconde quinzaine de mars 2025

Deux cent cinquantième épisode dans la communication entre les différentes équipes de bénévoles autour du site LinuxFr.org : l’idée est de tenir tout le monde au courant de ce qui est fait par la rédaction, l’administration web et système, la modération, le développement, l’association, etc.

L’actu résumée ( [*] signifie une modification du sujet du courriel) :

Statistiques

Du 16 au 31 mars 2025

• 1263 commentaires publiés (dont 6 masqués depuis), comme suit :
  • 478 commentaires publiés sur les liens (dont 1 masqué depuis) ;
  • 555 commentaires publiés sur les journaux (dont 0 masqué depuis) ;
  • 50 commentaires publiés sur les dépêches (dont 3 masqués depuis) ;
  • 146 commentaires publiés sur les entrées de forum (dont 2 masqués depuis) ;
  • 29 commentaires publiés sur les sondages (dont 0 masqué depuis) ;
  • 4 commentaires publiés sur les entrées dans le système de suivi (dont 0 masqué depuis) ;
  • 1 commentaire publié sur les pages wiki (dont 0 masqué depuis) ;
• 745 étiquettes posées ;
• 72 comptes ouverts (dont 19 fermés depuis) ;
• 25 entrées de forum publiées (dont 3 masquées depuis) ;
• 98 liens publiés (dont 0 masqué depuis) ;
• 16 dépêches publiées ;
• 24 journaux publiés (dont 1 masqué depuis) ;
• 0 entrée nouvelle, 0 corrigée et 2 invalides dans le système de suivi ;
• 1 sondage publié ;
• 0 page wiki publiée (dont 0 masquée depuis).

Listes de diffusion (hors pourriel)

Liste ca@ – [restreint]

• [CA LinuxFr] Bilan moral 2023-2024

Liste linuxfr-membres@ – [restreint]

• R.A.S.

Liste moderateurs@ - [restreint]

• [Modérateurs] Description étrange lors d’une recherche
• [Modérateurs] Invitation au podcast "Hérétiques"
• [Modérateurs] Signature problématique sur LinuxFr.
• [Modérateurs] dépêche facebook d’Orfenor

Liste prizes@ - [restreint]

• R.A.S.

Liste redacteurs@ – [restreint]

• R.A.S.

Liste team@ - [restreint]

• [team linuxfr] [Huma] CR réunion du 04/02/2025 - Prépa Fête de l’Huma

Liste webmaster@ – [restreint]

• R.A.S.

Canal IRC adminsys (résumé)

• changement de DNS sur bak et slurp qui utilisaient les DNS FDN qui ont été fermés au public
• mise à jour des Xen de bak et slurp ?

Groupe Signal (résumé)

• renouvellement de la convention d’hébergement avec la Fondation Free
• conférence Sciences Po Paris « Quel avenir pour les réseaux sociaux ? » ( 1 , 2 , 3 , 4 , 5 , 6 , une captation vidéo a été faite). En particulier ce visuel ( source ) :
• Renforcement des protections des serveurs DNS récursifs ouverts de FDN (utilisés par deux de nos serveurs)
• Grammalecte en PLS
• « Python et Ruby boostent ton salaire » , attends mais alors si tu contribues à LinuxFr.org, ton salaire devient stratosphérique, vite une dépêche
• pénibles spammeurs casino/poker à IP indonésiennes qui n’utilisent que des IP et pas de noms de domaine, qui n’ont que des images hébergées par des CDN et autres hébergeurs gratos d’images, qui nous injectent des images, et qui viennent régulièrement (la liste de blocage fait désormais 1329 lignes, contre 1100 en octobre 2023)
• quels sujets à discuter pour l’assemblée générale à venir ?

Tribune de rédaction (résumé)

Du 16 au 31 mars 2025

• gestion des étiquettes
• corrections post-publication
• conversion de journal en dépêche
• gestion du spam
• idée de dépêche (faite depuis) : GIMP 3.0

Tribune de modération (résumé)

Du 16 au 31 mars 2025

• 92 messages sur 146 sont des notifications automatiques
  • 5 La dépêche a été mise à la une
  • 2 La dépêche a été refusée
  • 4 La dépêche a été supprimée en rédaction
  • 1 La page Mentions légales a été mise à jour
  • 6 Le commentaire a été masqué
  • 8 Le compte a été désactivé
  • 4 Le compte a été privé de tribune pendant 30 jours
  • 1 Le journal a été supprimé
  • 3 Le message a été supprimé
  • 4 Les commentaires ont été bloqués pendant 30 jours
  • 1 Le sondage a été accepté
  • 9 L’étiquette est désormais cachée, modifiée
  • 42 L’étiquette vient d’être créée
  • 2 Une image récente a été bloquée
• précision sur l’hébergement de nos serveurs à la Fondation Free
• processus de suppression technique d’un message de la tribune
• proposition d’entretien par un podcast hors thématique
• gestion d’une signature problématique
• du spam

Commits/pushs de code https://github.com/linuxfrorg/

img :

• Move app in /app, with configurable app:app user
• Bump versions golang, alpine, & golangci-lint (+ fixes related)

epub :

• Move app in /app, with configurable app:app user
• Bump versions golang, alpine, hurl, epubcheck & golangci-lint

admin. sys. :

• Add find_content script
• Update blocklist
• Change DNS servers on bak and slurp

Divers / TODO / pense-bête

• convoquer l’assemblée générale

Commentaires : voir le flux Atom ouvrir dans le navigateur

Aujourd'hui on va faire un peu d'archéologie informatique.

Je me suis penché il y a quelques temps sur l'histoire des circuits de génération vidéo utilisés dans le minitel. Il s'agit des composants TS9367, EF9566 ou EF9365. Ces troix sont des versions simplifiées d'une génération précédente qui nécessite deux composants: EF9340 et EF9341.

Ils sont tous fabriqués par Thomson Semiconducteurs (qui deviendra ensuite ST Microelectronics suite à sa fusion avec SGS) ou Thomson EFCIS (ce qui explique le préfixe EF).

Je me suis interrogé sur la provenance de ce circuit. Il présente des fonctionnalités assez avancées (caractères redéfinissables, décompression du flux de caractères, …) y compris des fonctions qui ne sont même pas utilisées par le Minitel.

Pourquoi Thomson s'est-il lancé dans la conception d'un tel circuit? Est-ce que c'était une commande spéciale des concepteurs du minitel? Par exemple, je sais que le circuit EF9369 (gestion d'une palette de 16 couleurs parmi 4096) était à l'origine un développement spécifique pour le Thomson TO9, mais que ensuite il a été mis en vente pour d'autres utilisations.

En cherchant un peu, j'ai découvert l'existence d'une autre série de circuits de chez Thomson. Il s'agit des EF9365 et EF9366. Ces derniers sont plus anciens (autour de 1978) et ne se limitent pas à des capacités alphanumériques. Ils proposent le tracé de lignes accéléré par le matériel, ce qui en fait peut-être les tout premiers GPUs intégrés (il existait déjà des solutions d'affichage graphique, mais pas sous forme d'un composant unique).

Ces deux derniers sont assez bien documentés. Nous avons non seulement les documentations techniques, mais aussi la thèse de Philippe Matherat qui les a conçus. Il s'agissait alors de remplacer les coûteux écrans Tektronix 4010 par de simples postes de télévision beaucoup moins chers.

Mais, dans cette famille, il y a encore un autre composant, le EF9364. C'est le tout premier de la famille et il propose un affichage en mode texte de 64x16 caractères. Pour ce composant, difficile de trouver de la documentation. Après avoir un peu fouillé les internets, j'ai fini par comprendre qu'il avait d'abord été commercialisé par la SESCOSEM (fusion des entreprises SESCO et COSEM, qui sera elle-même plus tard intégrée dans Thomson) sous la référence SF.F 96364 (pas facile tous ces changements de numéro).

La conception de composant date de 1976. À la même époque, Steve Wozniak est en train de concevoir l'Apple I et le Xerox PARC travaille sur la deuxième génération d'interpréteurs Smalltalk sur le Xerox Alto. C'est donc plutôt au tout début de la micro informatique, et il semble y avoir assez peu de composants existants avec des capacités similaires.

On trouve bien sûr déjà des terminaux permettant d'afficher du texte sur un écran, mais ils sont réalisés à partir de centaines de composants. Comment et pourquoi la SESCOSEM a eu l'idée de se lancer dans ce projet?

En lisant la th`se de Philippe Mathérat, j'ai vu qu'il parlait du travail d'un de ses collègues ou prédecesseurs, Jean Gastinel, qui avait vraissemblablement travaillé sur la conception de ce composant. Mais sa thèse n'était trouvable nulle part sur Internet. La seule façon d'y accéder est de consulter l'original.

Je me suis donc inscrit à la bibliothèque universitaire la plus proche de chez moi et leur ai demandé de me prêter ce document (grâce au système de prêt entre bibliothèques). Je n'ai pas été déçu par ma lecture.

Cette thèse présente non seulement la conception logique du composant, mais aussi:

• la technologie de réalisation des circuits intégrés (MOS canal N à triple implantation)
• la façon dont le composant a pu être réalisé plus rapidement à l'aide de "briques" réutilisables qu'on peut copier-coller, avec l'idée plus tard de réaliser un compilateur pour automatiser cette étape
• et aussi, de quelle fçon ce composant pourrait être utilisé.

L'idée du Minitel est déjà là. Il s'agit de se connecter à distance à des gros ordinateurs centralisés, à l'aide d'un terminal simple et peu coûteux. Le composant est donc prévu pour pouvoir s'associer directement à un modem et à un écran de télévision et un clavier ASCII. Le résultat est un boîtier contenant seulement 13 composants.

Les cas d'usage sont aussi déjà envisagés: consulter des horaires de train à distance, par exemple.

(Il faut mentionner qu'un service similaire existait déjà: le système TIC-TAC, qui permettait de se connecter à distance à un ordinateur pour accéder à l'aide d'un téléphone et d'un téléviseur à… une calculatrice. Projet qui a été mis en sommeil avec l'arrivée de calculatrices de poche bien plus simples à mettre en oeuvre).

L'histoire ne se déroulera pas tout à fait comme l'imaginait Jean Gastinel. Aujourd'hui, nous avons tous dans notre poche un ordinateur bien plus puissant que ce qu'il imaginait. Même pour le Minitel, la version qui sera commercialisée comportera un microprocesseur, permettant de faire quelques opérations logicielles en local dans le terminal.

Le composant EF9364 trouvera tout de même sa place auprès des premiers bricoleurs de micro ordinateurs ainsi que des radio amateurs. On peut citer par exemple l'Elekterminal du magasine Elektor ou les premières machines de SMT Goupil. Et, bien sur, le composant utilisé dans le Minitel prendra plus tard également place dans le Videopac+, le VG5000 et le Matra Alice, de belles réussites de la micro informatique Française. Les choses auraient donc été bien différentes sans cette thèse.

J'ai recopié tout le texte et numérisé les images si vous souhaitez la consulter. Il ne sera ainsi plus nécessaire de déranger l'original.

Je vous laisse avec le lien vers le texte complet de la thèse:

Jean Gastinel - Conception et intégration d'un terminal alphanumérique

Bonne lecture!

Commentaires : voir le flux Atom ouvrir dans le navigateur

Puisqu'on parle de calculatrices , de bidouillages , d' Open Source et d' Open Hardware , je crois bien que je vais craquer …

https://www.clockworkpi.com/picocalc

il y a des GPIO qui sont exposés:

• du STM32 qui gère le clavier (ad minima)
• du RaspberryPi Pico (ou autre).

… 75$ en boutique, 100$ tout compris et dans ta boîte à lettre dans quelques jours …

Arghh

… , j'ai presque craqué, mais comme il n'y a rien encore sur le Github de ClockWork , je patiente encore un peu.
D'une part, je suis curieux de voir la partie alimentation/charge du bidule et qui fait quoi entre le STM32 (j'y connais rien) et le reste. D’autre part j'ai confiance dans la pérennité du truc. En effet, on leur doit:

• uConsole , Github
• devTerm , Github
• gameShell , Github

qui sont tous bien documentés et toujours vendus en boutique .

Super cool, vive l'Open Source/Hardware. Je vais craquer, c'est sur …

Commentaires : voir le flux Atom ouvrir dans le navigateur

Sommaire

• Fichiers perdus
• Et maintenant ?
• Retirer les fichiers de programmation
• Compter les fichiers par type
  • Compter les fichiers dont le noms a été retrouvé
  • Ranger les fichiers par extension
• Supprimer les miniatures JPEG
• fclones pour trouver les fichiers redondants
• Retrait des dossiers vides
• Retrouver les fichiers récents
• Conclusion
  • Pensées pour la prochaine fois

Ce journal a d'abord été publié sur mon blog technique : https://grimoire.d12s.fr/2023/after_photorec.html#_version_fr

Vu qu'on a reparlé de Photorec récemment sur LinuxFr je m'étais noté de pousser ce retour d'expérience ici aussi.

Fichiers perdus

Lors du dernier Repair Café de Pougne-Hérisson un ami est venu m'apporter un disque dur USB d'1TO en m'expliquant que ce dernier n'était plus reconnu par ces ordinateurs, Windows ou Linux.

Matériel défectueux ? Je le branche, il se monte.

Ah… l'ami pensait l'avoir testé aussi sous Linux, mais le disque n'échoue à se monter que sous Windows du coup.

Bon, bah au moins c'est pas matériel.

Je lui montre alors le contenu du disque, il y a 3 dossiers vides (data, storage, work) que l'ami ne reconnait pas.

Je lui précise la date de création des dossiers : vendredi dernier à 18h43. Que faisait-il dans la nuit du vendredi en début de soirée ?

La mémoire lui revient, la famille voulait enregistrer un film via la nouvelle Box Canal+, or cette dernière réclamait un disque dur pour pouvoir enregistrer quelque chose. Il semble bien que la Box en question a juste formaté le disque qu'on lui présentait (en Ext4) sans prévenir suffisamment explicitement que les données seraient perdues.

Le disque n'était donc plus reconnus par les ordinateurs tournant sous Windows… et les fichiers furent joyeusement supprimés par la Box.

Bon, après une vérification via testdisk je me retrouvais à lancer photorec. Ça a pris 22h et je me suis retrouvé avec 432 GO de données, en 150 159 fichiers répartis en 238 dossiers.

Bien plus que ce que l'ami imaginais avoir comme données.

PS: Ce billet peut être vu comme un second épisode après le sauvetage précédent : Sauver les données d'une partition perdue .

Et maintenant ?

Rendu là, j'aimerai réduire cette masse de fichiers pour aider mon ami à l'explorer et y retrouver son travail récent. (il a d'autres sauvegardes, mais plus anciennes)

Lançons tout d'abord un ncdu pour voir ce qu'il peut nous en dire :

   53.9 GiB [#############] /recup_dir.233
   50.1 GiB [############ ] /recup_dir.232
   21.2 GiB [#####        ] /recup_dir.2
   16.7 GiB [####         ] /recup_dir.234
   15.9 GiB [###          ] /recup_dir.1
   13.7 GiB [###          ] /recup_dir.229
    8.1 GiB [#            ] /recup_dir.182
    8.1 GiB [#            ] /recup_dir.205
    6.6 GiB [#            ] /recup_dir.180
    6.3 GiB [#            ] /recup_dir.237
    6.1 GiB [#            ] /recup_dir.228
    5.9 GiB [#            ] /recup_dir.227
    5.2 GiB [#            ] /recup_dir.204
    5.2 GiB [#            ] /recup_dir.179
    5.0 GiB [#            ] /recup_dir.224
    4.9 GiB [#            ] /recup_dir.187
    4.7 GiB [#            ] /recup_dir.4
    4.5 GiB [#            ] /recup_dir.3
    4.2 GiB [#            ] /recup_dir.186
    4.1 GiB [             ] /recup_dir.222
    4.0 GiB [             ] /recup_dir.215
    […]

    Total disk usage: 431.7 GiB  Apparent size: 428.6 GiB  Items: 150 159

Je peux confirmer ce nombre de fichiers via :

$ rg -uuu --files --iglob * | wc -l
149682
$ python -c 'print(149682+(238*2))'  # adding folders
150158 <1>

Il semble que chaque dossier compte pour 2 items (tels que les compte ncdu ), et encore il en manque toujours 1…

Retirer les fichiers de programmation

En explorant quelques dossiers, je constate qu'il y a beaucoup de fichiers C et Python parmi les fichiers récupérés. Combien exactement ?

$ rg -uuu --files --iglob "*.c" Recup | wc -l <1>
21348

# Nombre de fichiers Pythons :
$ rg -uuu --files --iglob "*.py" Recup | wc -l
4363

photorec était configuré pour écrire dans le dossier Recup

Bon, alors je peux créer un dossier "poubelle" et y déclarer ces fichiers, mon amis n'est pas un programmeur.

$ mkdir poubelle
$ for a in `seq 238`; do mkdir "poubelle/recup_dir.$a"; done; <1>
$ rg -uuu --files --iglob "**py" . | xargs -I {} mv {} poubelle/{} <2>

Création de 238 sous dossiers dans "poubelle" folder.
Déplacement des fichiers Python.

Mais combien y a-t-il de langages de programmation représentés ?

$ for a in `rg --type-list | cut -f 1 -d ':'`; do echo "$a: `rg --files -t $a | wc -l`"; done; <1>

Pour chaque type de fichier reconnu par rg (169 en l'occurrence) afficher le nombre de fichier qu'rg peut en compter

fortran: 14 <1>
h: 1642
html: 292
java: 219
config: 3
pdf: 14536
perl: 12
php: 9
sh: 11
svg: 377
txt: 8645

Je n'ai gardé là que les types effectivement présents

Tiens, ça liste également des PDF mais pas d'ODT et puis on a pas les extensions fichiers exactes pour chaque type…

Compter les fichiers par type

Lançons nous dans un meilleur aperçu de la répartition des fichiers par type, en comptant les fichiers par type mime et par extension (du moins celle que photorec a attribué aux fichiers).

$ rg -uuu --files --iglob "*" Recup > 122552_filenames.txt  <1>

J'en étais encore à 122552 fichiers. La commande dura 15s.

Compter les fichiers dont le noms a été retrouvé

$ rg '.{42,}' 122552_filenames.txt > liste_fichiers_avec_nom.txt
$ wc -l liste_fichiers_avec_nom.txt
4566 <1>

Cela représente 3,7% des 122k fichiers restant

Voici quelques exemples de long nom de fichier à éviter quand même :

• Recup/recup_dir.10/f136265448.sqlite
• Recup/recup_dir.194/f936769224_ftyp.mov
• Recup/recup_dir.36/f179430256_PAY18E.pdf

---

Listons maintenant tous les fichiers par type mime et par extension :

$ file --mime-type -f 122552_filenames.txt > 122552_file_mime-types.txt <1>
$ sed -r 's/\s+/ /g' ../122552_file_mime-types.txt | cut -f 3,4,5,6,7 -d '.' | sort | uniq -c | sort -r -n > ../122552_file_ext_mime-type_summary.txt <2>

Bon là ça prend 2h sur ce disque dur à plateau d'une grande marque et relativement moderne
Cette ligne retire des espaces dans chaque ligne, puis retire le début de chaque ligne (jusqu'au 2e point), puis tri le fichier et compte les lignes identiques avant de les trier par nombre d'occurrences.

  72429 jpg: image/jpeg
  14544 pdf: application/pdf
   7513 txt: text/plain
   6576 png: image/png
   5198 odt: application/vnd.oasis.opendocument.text
   3430 mpg: video/mpeg
   1795 avi: video/x-msvideo
   1369 elf: application/x-sharedlib
   1219 mp3: audio/mpeg
   1199 apple: application/octet-stream
    739 txt: application/octet-stream
    […] <1>

Il y avait encore 77 types de fichiers à ce moment là (après le retrait des fichiers C, H, Python, Java et quelques autres).

On note qu'il est intéressant de retirer les fichiers elf et apple mais que le gros morceau reste les jpg .

Ranger les fichiers par extension

Un ami a utilisé ce billet de blog pour récupérer des fichiers perdus dans un Windows 11 sur support de stockage NVME. Il a décidé de s'arrêter à cette étape, après avoir rangé les 10k fichiers par extension. Voilà le script qu'il a utilisé :

#!/bin/bash

# Utilisation du premier argument comme répertoire source
source_dir="$1"

if [ -z "$source_dir" ]; then
    echo "Usage: $0 <source_directory>"
    exit 1
fi

# Fonction récursive pour traiter les fichiers d'un répertoire
process_directory() {
    local dir="$1"

    for ext in $(find "$dir" -type f | sed -n 's/.*\.\(.*\)/\1/p' | sort -u); do
        ext_dir="${ext}_files"
        # Création du répertoire d'extension s'il n'existe pas déjà
        mkdir -p "$ext_dir"

        # Déplacer les fichiers de l'extension vers le répertoire d'extension
        find "$dir" -type f -wholename "*.$ext" -exec mv {} "$ext_dir" \;
    done
}

# Appel initial pour le répertoire source
process_directory "$source_dir"

Supprimer les miniatures JPEG

Explorer un dossier au hasard pour voir ce qu'il contient comme images :

$ find . -name "*.jpg" | wc -l
89
find . -name "*.jpg" -size -35k | wc -l
68
find . -name "*.jpg" -size -50k | wc -l
69
find . -name "*.jpg" -size -100k | wc -l
71
find . -name "*.jpg" -size -150k | wc -l
78
find . -name "*.jpg" -size -1500k | wc -l
78
find . -name "*.jpg" -size -1800k | wc -l
79

On constate qu'il y a plein de petites images, principalement des miniatures de vraies photos, créées par divers logiciels (explorateur de fichier, visionneur de photo…) sur divers systèmes d'exploitation.

On remarque également qu'il y a un grand trou dans la répartition des images entre 150ko et 1500ko. Les photos plus grosses auront toutes les chances d'être des vraies. Pour ma part j'ai décidé de couper à 300ko :

find Recup -name "*.jpg" -size -300k | wc -l
43414
find Recup -name "*.jpg" -size -300k | xargs -I {} mv {} poubelle/{} <1>

Cela prend environ 1 minute

Arrivé là on en est à 72635 fichiers et 414 GO soit 50% du nombre de fichiers du départ mais toujours 96% de l'occupation disque.

fclones pour trouver les fichiers redondants

J'ai alors décidé d'essayer fclones pour tenter de trouver des fichiers qui seraient présents en plusieurs exemplaires parmi les fichiers restants.

$ fclones group --cache /tmp > /tmp/fclones.group.txt <1> <2>
fclones:  info: Found 48416 (149.9 GB) redundant files
$ fclones move poubelle < /tmp/fclones.group.txt
Deduplicating 17252 groups
fclones:  info: Processed 48416 files and reclaimed 149.9 GB space <3> <4>

L'option --cache permet de sauver l'index des hash de fichier sur le disque dur (ici rangé dans le dossier /tmp ), cela permettrait de le réutiliser si on avait à relancer la commande rapidement suite à une erreur, sans avoir à recalculer tous les hash
L'execution a pris 2h38
Cette dernière phase a pris 10 min
Il aurait probablement été préférable de faire des liens symboliques avant de déplacer les fichiers redondants

Nous voilà rendus à 24220 fichiers et 273 GO soit 16% du nombre initial de fichiers et 63% de la taille considérée.

Retrait des dossiers vides

Une partie rapide :

$ rmdir Recup/*
$ exa -l | wc -l
199 <1>

Donc 39 dossiers vides retirés (16%)

Retrouver les fichiers récents

Malheureusement photorec ne sait pas restaurer toutes les dates de création de fichier (mais, comme pour les noms, seulement celles retrouvables dans les métadonnées internes d'un fichier). Quand la date est inconnue, c'est la date du jour qui est utilisée.

Un tiers des documents ont pu être éliminés comme étant trop vieux (plus de 4 mois).

Voici la commande utilisée pour retrouver les fichiers récents :

$ find . -newermt $(date +%Y-%m-%d -d '4 months ago') -type f -print > recent_file_list.txt <1> <2>

Retrouver les fichiers qui ont moins de 4 mois
Environ 100k fichiers furent trouvés par les 150k du départ

On peut retirer de cette liste les fichiers datant du jour de la récupération pour une liste plus courte (et donc plus facile à consulter) :

$ find . -newermt $(date +%Y-%m-%d -d '4 months ago') ! -newermt $(date +%Y-%m-%d -d '1 week ago') -type f -print > liste_incomplete_fichiers_recents.txt <1>

Là on tombe à 453 fichiers ; 4 ODT ; 0 avec son nom d'origine

Vu que je suis reparti de la liste intégrale des fichiers, on peut en retirer tous les fichiers éliminés ou dédoublonnés :

$ for a in `cat ~/liste_des_fichiers_recents.txt` ; do if test -f $a; then echo $a >> ~/liste_des_fichiers_recents_existants.txt ; fi; done

On en arrive à 17 122 fichiers, dont 144 DOC, 76 ODT…

Conclusion

photorec est un outil très précieux mais il n'est pas facile de s'y retrouver dans tous les fichiers qu'il retrouve.

Dans ce billet, nous sommes passés de 150k à 17k fichiers récents et uniques retrouvés.

Nous avons vu que photorec peut vous aider à retrouver votre précieux rapport perdu sur un support mourant, mais il risque de le retrouver plusieurs fois, accompagné de toutes ses versions précédentes et/ou supprimées… vos photos serons sauvées, mais également leurs miniatures et même avec toutes les techniques illustrées ici pour raffiner les données récupérées, il vous faudra encore beaucoup de travail pour vous réapproprier cette montagne de fichiers

Pensées pour la prochaine fois

J'aurais pu commencer par faire une copie bit à bit du support via dd pour pouvoir éventuellement revenir à une étape précédente en cas de fausse manip.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Debian Trixie sera la prochaine version stable de debian dans quelque mois. Voici ma configuration, je fais surtout du web et de la gestion de projet.

Remarque: pendant l'installation, laissez la mot de passe Administrateur vide pour que sudo soit configuré correctement.

J'ai installé la version netinstall de trixie .

Puis:

sudo apt install -y transmission gnome-software-plugin-flatpak gnome-console curl git zsh
sudo apt remove -y firefox-esr
sudo flatpak remote-add flathub https://dl.flathub.org/repo/flathub.flatpakrepo
sudo flatpak install -y flathub com.discordapp.Discord
sudo flatpak install -y flathub org.mozilla.firefox
sudo flatpak install -y flathub org.pgadmin.pgadmin4
sudo flatpak install -y flathub io.neovim.nvim
gnome-software --mode=installed
flatpak run org.mozilla.firefox https://flathub.org/?category=popular


Remarque: Debian installe la version 0.9 de neovim , on veut la version 0.10 pour l'utiliser dans vscode.

Si besoin, installez ohmyzsh , chrome , vscode . Dans Chrome, installez vimium , ublock origin lite . Dans vscode: vscode-neovim .

Dans .zshrc :

alias vim=/var/lib/flatpak/app/io.neovim.nvim/x86_64/stable/active/export/bin/io.neovim.nvim
alias nvim=/var/lib/flatpak/app/io.neovim.nvim/x86_64/stable/active/export/bin/io.neovim.nvim


Vous pouvez explorer le magasin flatpack et installer les logiciels qui vous intéressent via le gestionnaire de logiciel de Gnome.

Install nodejs

Install nodejs ici .

Faites en sorte que les 3 dernieres lignes ajoutées a .bashrc soit aussi dans .zshrc .

Ouvrir une nouvelle console et:

nvm install --lts
npm install -g npm-check-updates npm tsx


Il est souvent necessaire de rajouter de la memoire a nodejs en ajoutant ceci a .zshrc :

export NODE_OPTIONS=--max_old_space_size=8192


Commentaires : voir le flux Atom ouvrir dans le navigateur

J'utilise Bitwarden pour la gestion familiale des mots de passe depuis plusieurs années, et globalement, c'est chouette. Je paye pour l'hébergement via les offres commerciales, mais on peut l'héberger soi-même, ou utiliser Vaultwarden qui est compatible avec le client officiel Bitwarden ¹ .

Une fonction très pratique est de pouvoir stocker les jetons TOTP pour la double authentification ² . Quand on y réfléchi un peu, on se trouve rapidement à considérer que c'est un peu faire non plus de l'authentification à 2 facteurs, mais plutôt à 1,5 facteurs… Tout est dans le même coffre-fort, même si l'accès à ce coffre est lui-même multifactoriel ³ .

On peut déblatérer des heures sur fond du sujet, c'est un équilibre entre niveau de sécurité et confort, chacun·e place le curseur où bon lui semble, parfois même en connaissance de cause.

J'utilisais donc prioritairement ma Yubikey pour la MFA, et les TOTP quand la Yubikey/Webauthn n'est pas supporté. N'ayant eu que récemment un smartphone, je stockais ces TOTP dans Bitwarden. Donc tous les œufs dans le même panier, d'une certaine manière.

Et puis cette année, j'ai remplacé mon Nokia 130 par un smartphone (à cause de l'Identité Numérique et France Connect+). Donc je me suis dit que je pouvais maintenant extraire les secrets TOTP et les avoir dans une application dédiée. Sur Android, il y a Aegis en licence GPL 3.0, mais sur iOS, ce n'est pas disponible. En cherchant, on tombe rapidement sur Google Authenticator, Twilio Authy, celui de Microsoft, etc… Tous propriétaires et avec des possibilités de sauvegarde et de transfert du contenu plutôt limitées. Par exemple pour Authy, il faut se créer un compte chez Twilio.

Et donc aujourd'hui, je découvre que l'entreprise Bitwarden a publié Bitwarden Authenticator il y a quelques mois, pour iOS et Android, en licence GPL 3.0.

La doc est claire : l'appli est indépendante du coffre-fort, et les sauvegardes se font via le système de sauvegarde du téléphone.

Donc bye bye Authy, bonjour Bitwarden Authenticator !

Tout petit regret, je me dis que peut-être Bitwarden (l'entreprise) aurait pu contribuer ou financer une version pour iOS de Aegis, ça aurait une belle collaboration.

Et toi, tu gères comment ta MFA dans ce monde de brutes ?

• Bitwarden Authenticator , et ses codes sources pour Android et iOS
• Aegis Authenticator et son code source pour Android
• Vaultwarden et son code source

Commentaires : voir le flux Atom ouvrir dans le navigateur

Ce navigateur est basé sur Firefox et sensé mieux protéger contre les atteintes à la vie privée durant le surf sur le web.

Mais il n’apparaît pas dans la liste des navigateurs testés sur https://privacytests.org

Le projet GNU ne distribue pas de binaires pour ce navigateur, mais le site web https://icecatbrowser.org en distribue pour Linux, avec des paquets Debian et une version générique portable pour les autres systèmes GNU/Linux, et aussi pour MacOS et Windows.

Apparemment, les binaires proposés par https://icecatbrowser.org sont gérés par un contributeur au projet GNU Icecat.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Un séisme cataclysmique fait trembler jusqu'aux fondations du web et ébranle tout le monde connu, les réseaux sociaux sont en feu, Stroustrup refuse de répondre au téléphone, tandis que nous attendons impatiemment une déclaration de nos dirigeants éclairés : le über geek JF Bastien vient de publier une proposition de changement du standard C++ décrétant qu'il y aurait exactement 8 bits dans un byte, prouvant au passage que les français étaient une fois de plus précurseurs en généralisant le terme octet.

Alors vous le savez sans doute, une immense majorité des architectures aujourd'hui font effectivement ce choix, et les compilos modernes sont construits sur ce modèle. L'argument de JF Bastien est donc que non seulement il n'existe presque plus de systèmes où ce n'est pas vrai, mais qu'en plus la minorité de développeurs qui pourraient travailler sur ces architectures n'ont aucun besoin d'un compilateur C++ moderne: "The question isn’t whether there are still architectures where bytes aren’t 8-bits (there are!) but whether these care about modern C++… and whether modern C++ cares about them."

Je sens confusément que je devrais avoir une opinion tranchée sur la question, il ne me reste plus qu'à déterminer laquelle.

Commentaires : voir le flux Atom ouvrir dans le navigateur