xryl669 a écrit 106 commentaires

Le bit est incompressible

Ouais, sauf en informatique quantique. Et dans certains films aussi.

Les fixer sur son tableau de chasse, s'entend.

Le gars dans l'article l'a tenté pour son extension. En gros, il a mis en quarantaine le site "youtube.com". Son extension a été désactivée sur le site, mais pas uBlock origin. C'est à dire que Mozilla outrepasse ta configuration avec une liste inconnue d'extensions.

Pire, si l'extension est mise sur la barre d'outils (à côté de l'adresse bar) comme la majorité des extensions font, il n'y a aucun signal visuel que l'extension est désactivée (comme par exemple, mettre l'icône en grisé, ou mettre une barre diagonale rouge sur l'icône).

Dit différemment, si tu as mis un uBlock Origin et qu'il prend l'envie à Mozilla d'interdire cette extension sur youtube, elle peut le faire, et tu n'en saura rien. (Bon, exemple douteux, vu que quand UBO n'est pas là, tu le vois direct sur le web).

Imagine pour un NoScript, DoNotTrack, StopTheMadness ou autre…

What ? Tu as une source ?

https://lapcatsoftware.com/articles/2023/7/1.html

Oui. Ceci dit, les autres navigateurs proposent quasiment la même chose, même sous Android.

Pour Tor ou I2P, c'est pas possible sur Android. Le mode privé, c'est autant privé que les autres. Pocket, c'est pas libre, c'est gratuit seulement.

Après chacun ses besoins, je dis pas.

Personnellement, j'évite de mettre tous mes œufs dans le même panier, la synchro des mots de passes c'est Bitwarden sur mon NAS. Pour les marques pages, j'ai ma solution perso sur mon NAS aussi. Jamais je ne voudrais synchroniser mes onglets, le problème étant que j'ai du mal à les fermer, je vais pas m'alourdir avec ceux des autres machines en plus.

C'est bien de faire la liste des ajouts et corrections de bugs mais il faut également parler de ce qui a été enlevé aussi, comme par exemple, les extensions sous Android. Impossible d'installer une extension hors de la liste de …. roulements de tambours… 18 extensions certifiées par Mozilla.

Pour moi, le seul intérêt de Firefox sous Android, c'est de pouvoir avoir les extensions. Il est pas plus rapide que Chrome, pas plus ergonomique (voire un peu moins). Le fait d'enlever les extensions, c'est un coup de couteau dans le dos. Déjà que le passage aux webextensions…

En installant une version nightly et en bidouillant (procédure assez complexe), on se rend compte que l'on peut facilement faire marcher les autres extensions, ce n'est donc pas une raison technique qui justifie ce choix. Quelle est la raison?

Sans parler de la récente orientation de Mozilla de désactiver certaines extensions suivant le site web où vous êtes…

Je reste toujours fidèle à Firefox sur mes périphériques, mais c'est plus par conviction que par choix logique et justifiable. J'espère sérieusement que ça va changer dans les mois qui viennent et que certaines killer features vont revenir sur Firefox…

Espressif, le firmware n'est pas ouvert, tu te trompes, tu confonds avec esp-idf qui est ouvert, mais qui se repose sur:
1. Le code en ROM (vérifie les scripts de l'éditeur de lien, tu verras, en gros, la libc est en ROM, la gestion des MMU est en ROM, etc…)
2. Des librairies statique en .a précompilés (pour le WIFI, le Bluetooth, le SOC, l'implémentation bas niveau de FreeRTOS, etc…) qui seraient, sous linux, des binaires firmwares.

Mais après tout, on s'en fiche un peu qu'il soit ouvert, vu que tu peux pas le modifier de toute façon (tu peux pas changer l'architecture du CPU, ni le hardware, ni le plan mémoire, ni…). C'est une plateforme très ouverte et documentée par rapport à la concurrence, type STM32 ou autre, mais certainement pas libre.

RISC-V sur ESP32-C est pas plus ouvert que le Tensilica LX7 des ESP32-S.

Je pense pas que device tree ait le moindre lien avec UEFI. Le device tree, c'est juste une description, binaire, de ce que la machine a comme périphériques. Le device tree n'a aucun "driver", aucun code, rien n'est exécuté sur/avec le device tree.
Le device tree est utilisé par linux, une fois démarré pour savoir quel driver installer et lancer (il faut donc qu'ils soient compilé dans l'image Linux, ou via des modules dans le initrd / rootfs).

L'UEFI, c'est un OS avant l'OS. Il implémente un mini OS suffisant pour démarrer un vrai OS (et accessoirement, valider que le vrai OS est bien celui qui est autorisé). C'est, fonctionnellement, comme u-boot, pas étonnant que u-boot ait implémenté les API UEFI.

Les drivers de ce mini OS sont spécifiques à ta machine, il n'est pas question d'avoir tous les drivers du monde comme linux, il faut juste pouvoir faire les opérations de base, c'est à dire pouvoir charger des données d'un support de stockage, démarrer la mémoire et le CPU, accessoirement afficher quelque chose (via un écran ou un port série ou le réseau) et passer la main.

Quelque soit la machine, l'API de ces drivers est standardisée en UEFI (contrairement à u-boot, où c'est de l'open source, comprendre: chacun sa sauce), donc c'est plus simple pour les vendeurs d'OS et les fabricants de matériels. C'est inutile pour une carte avec un microcontrolleur où les composants physiques sont connus et fixes (ici, u-boot suffit avec ses drivers spécifiques), mais pour un PC où chaque composant provient d'un fabricant différent inconnu avant l'assemblage (mémoire, carte réseau, GPU, etc…), c'est indispensable.

un compilateur ne sait pas si ta boucle est faite 10,100,10 000 fois.

D'ailleurs son code C est tronqué ,quand il deplit il fait 8 fois, mais le compilateur comment il sait qu'il peut déplier 8 fois ?

Beh si, il sait justement. Le loop unrolling, c'est pas fait sur le compteur de boucle for i = O; i < N; i++), mais sur le nombre d'ALU disponible sur le CPU, on le nombre d'exécution qui peuvent se faire en parallèle (SIMD). À la limite, il peut aussi déplier sur la taille du cache et du prefetcher (si la boucle touche une zone de 16 octets, il va déplier suffisamment pour les 4 itérations rentrent dans une ligne de caches de 64 octets).

De toute façon, le compilateur va convertir ton code en une sorte d'arbre logique des opérations à effectuer sur les données, et le backend va essayer de mapper ces opérations le mieux possible sur l'architecture binaire cible. Et le gros problème, c'est justement de décrire cette architecture cible en étant le plus efficace (et juste!) possible.

L'itanium est arrivé trop tôt et le soft était pas prêt à utiliser cette architecture. Les algorithmes SIMD/vectorisés sont arrivés des années plus tard.

De plus, c'est quasi impossible de faire un processeur efficace avec de multiples instructions/cycle sans avoir de out of order ou au moins une sorte de microcode. Les dépendances sont simplement insolvables sans résoudre l'ordre d'accès aux données (sequential memory access synchronization) sur un vecteur de plusieurs opérations, ce que le compilateur ne fourni pas (sauf en C++ pour les atomiques, mais c'est tout).
Donc, au niveau du processeur, si tu as la séquence de code:

A = B
B++
C = D
D = B
A += C

Bien que toutes ces opérations soient indépendantes les unes des autres (sauf la dernière), le processeur ne peut pas faire A = B en même temps que B++ car l'accès et le stockage à B doit être synchronisé sur ses ALU. Avec le OutOfOrder, il peut réordonner (A=B, C=D) et (B++, D=B) s'il le veut et s'affranchir de la synchronisation des caches pour saturer ses unités d'exécution.

Le compilateur ne peut pas changer l'ordre non plus (à la limite le C=D peut remonter) car le D=B a un effet observable donc B doit être calculé. Je ne parle même pas des atomiques/volatiles.

Ici avec 2 unités d'exécutions, tu ne peux pas faire moins que 4 cycles (A = B, puis B++, puis (C=D, D=B), puis A+=C) sans OoO, vue les dépendances.

Je parle ici de l'aspect implémentation et pas mathématique évidemment.

J'ai beaucoup de mal avec une nouvelle architecture "exotique", aussi bien soit elle. Car faire tourner une nouvelle ISA sur un FPGA, j'ai un peu l'impression que c'est facile (Leon, Microblaze, Pico8/32, RISC-V).

Le problème, paradoxalement, c'est pas le hard du CPU, c'est le hard complet (avec les devices, type bus SPI pour la flash du boot, PCIe, USB, etc…) et évidemment le soft.

Le soft, c'est réussir à faire intégrer le générateur de code pour l'architecture dans GCC et/ou LLVM (chose qui est déjà très compliquée à réaliser, ça ne s'écrit pas avec le dos d'une cuillère), mais s'assurer que ça fonctionne avec tous les paquets nécessaires pour un OS.

Un raspberry-pi like, c'est avoir un CPU avec tous les périphériques nécessaires à booter linux (c'est à dire flash NOR ou SPI + gestionnaire d'interruption + MMU complexe + DMA + …), mais également tous les périphériques nécessaires à l'OS (sortie vidéo, réseau, IO pour l'IHM, powersaving, encodage et décodage video, GPU, etc…) et pouvoir compiler, sans erreur, tous les paquets d'une distribution type debian (donc avec du C/C++, mais aussi du Java, du Rust, du Go, … autant de compilateur à implémenter).

Déjà, avec le tsunami RISC-V, c'est pas gagné, alors avec une ISA toute neuve sans une masse d'implémentation, je pense que c'est mort…

À la limite, une carte type "Arduino" avec un microcontrolleur sans OS, pourquoi pas. Mais même dans ce cas, tous les périphériques d'un microcontrolleur sont à implémenter, et c'est pas un Freecore qui va fournir cette implémentation.

Visiblement, sous Wayland, la pipette utilise une fonction qui retourne l'échantillonnage (triplet de couleur) du buffer de donnée image, et donc ni sa position, ni l'application concernée.

Impossible donc pour Gimp de savoir que l'utilisateur a cliqué sur une image de Gimp (qui peut être mise à l'échelle par Wayland d'ailleurs (ce qui est très souvent le cas en 4K), donc avoir subit une interpolation. Bref, l'interface "sécurité" de Wayland qui isole les applications / le gestionnaire de fenêtre joue parfaitement son rôle, si bien que le résultat est inutile.

Dans un monde pro, par exemple sur Apple, tu peux avoir un échantillonnage des pixels, et il est associé aux informations de profil de couleur (ce qui est, à la fois sécure et correct). Mais Wayland est très basique (trop) et visiblement, le bât blesse ici car l'information est manquante. Si en plus il faut attendre que ce soit aux clients de Wayland de faire le calcul de ceci, c'est mort avant plusieurs années, si jamais c'est fait un jour. Normalement, avec un bon protocole de fenêtre, chaque fenêtre/buffer pourrait avoir son propre profil de couleur et ce serait au gestionnaire de fenêtre de faire la conversion finale pour avoir la même chose sur un écran calibré donné. Typiquement, c'est ce que tu as dans Final Cut par exemple, lorsque tu preview un rush UHDTV sur un écran sRGB. L'image est très sombre (voire noire) sans ajustement de profil, pourtant elle est parfaitement visible dans la fenêtre de preview sous MacOS. Mais imagine la galère entre une fenêtre Gtk dans un environnement KDE qui n'ont aucune notion du profil des images/buffer.

Je me suis déjà fait avoir une fois en travaillant sur un RAW pour impression avec une forte dynamique sur MacOS, qui rendait nickel sur l'écran du Mac calibré et qui, une fois imprimé en tableau pour un client, était tout écrasé. L'imprimeur n'a jamais voulu reconnaître qu'il ne prenait pas en compte le profil de couleur de l'image fournie seulement du sRGB par défaut (lequel ?). Bref, j'aurais dû convertir l'image avant l'export en sRGB type Windows et là, peut être que j'aurais eu les bonnes dynamiques.

Moi aussi, un langage descriptif de l'interface (type QML) ça me botte.

Jusqu'à ce que l'on réalise qu'il n'est pas dynamique, il faut le compiler sur l'hôte pour que ça donne l'UI (contrairement à QtQuick/QML).

Du coup, pour moi, ça perd pas mal d'intérêt.

Pourquoi ne pas faire un éditeur graphique (c'est quand même beaucoup plus simple à utiliser) s'il faut compiler de toutes façons ?

Là où ça aurait vraiment été super classe, c'est une description de l'UI (en JSON, ou même comme ils ont fait), que l'on peut changer au runtime, avec un lien entre les widgets et les signaux générés (et gérés dans le code compilé, lui). Histoire de pouvoir, par exemple, modifier le fichier, l'uploader sur la cible et zou le nouvel UI apparaît.

Sur un processeur embarqué, c'est gagner un temps fou de développement, car il suffit simplement d'avoir un système de fichier et un serveur web (très simple sur ESP32, Pi et autre) au lieu d'avoir à générer un binaire monstrueux, faire un OTA et attendre que ça reboote pour voir le résultat.

Après, il y a la solution demo "web", c'est pas mal, mais moins pratique qu'un éditeur graphique au final.

J'ai aussi un peu de mal avec le rust et l'embarqué, le support de rust dans l'embarqué, c'est quand même pas trop top en ce moment, mais ça s'améliore… C'est surtout le manque de bibliothèques qui m'empêche d'utiliser rust et si le système en dépend, ça fait un langage de programmation en plus à gérer dans la chaîne de compilation déjà complexe d'un projet embarqué.

Je ne vois aucun lien vers le code source pour MediaInfo. La page dit bien que c'est open source, mais ça doit être une licence en open source si tu les trouves, ou un truc comme ça.

Exactement. La vrai différence entre le natif et le pas natif, c'est que le natif utilisant les fonctions du système, s'intègre parfaitement avec toutes les fonctions du système, comme le lecteur audio TTS pour ceux qui ont des soucis à la lecture (et STT pour les inputs), l'IME, les gestionnaires de mots de passe, le presse papier, le bon skin quelque soit le thème choisi, le dictionnaire et la correction automatique, le ClearView dépendant de l'écran choisi, les bonnes fontes, etc…

Et là, je ne parle que des zones de texte, mais le même problème s'applique au checkbox, les progress bars, qui peuvent et sont automatisées (il y a des utilitaires qui surveillent les progress bars et peuvent éteindre l'ordi lorsqu'elle est arrivé à complétion sous Windows).

Le pire, c'est que le web comme vous dîtes, est super bien intégré avec les widgets natifs, justement et que quasiment tout ce que j'ai cité là au dessus fonctionne dans un navigateur, et sous Electron / Tauri et autre.

Bref, pour faire un soft cross platform qui fonctionne le mieux pour tous, la solution Electron ou Tauri, ou, à la limite, iced sous Rust qui utilise tous le modèle DOM (qui est donc super connu, débuggé, sans surprises et facile à recruter pour les développeurs).

Je pense donc qu'un nouvel entrant dans ce but, c'est mort né (sauf peut être si basé sur Servo histoire d'avoir une taille de binaire non délirante et de pas avoir 10 versions de webkit installé sur une machine).

Il reste donc l'interface graphique pour l'embarqué (où LVGL existe avec Squareline comme éditeur graphique et générateur de code), et l'immediate mode type egui sous Rust (qui présente les mêmes défauts que Slint, mais c'est plus ancien et mieux intégré, la plupart des bugs sont résolus)

Contrairement à ce qui est écrit, l'interface est tout sauf native. C'est du dessiné, comme GTK, QT et autre.

Par exemple, faîtes un click droit sur une zone texte, et vous n'aurez pas le menu classique de copier/coller des zones de texte.

Il émule l'UI native, pour ressembler à l'interface de l'hôte. Mais ça foire complètement sur les hôtes qui ne sont un minimum customisés. Donc sous Linux avec ses 10000 environnements graphiques, vous aurez du pseudo GTK, thème de base. Sous windows, faut pas avoir choisi un thème sombre, etc…

Sur le web, les zones textes ne supportent pas le copier/coller, les IME, etc..
Sur la version mobile de la démo web (et que sur celle-ci, pourquoi?) il utilise un truc pas kocher du tout: il met un < input > caché sous le canvas de dessin. Il donne le focus à l'input lorsqu'une zone de texte est sélectionné, pour faire apparaître le clavier virtuel.

Sauf que c'est toujours le même input quelque soit la zone de texte dans l'interface, donc exit tous les automatismes, genre gestionnaire de mots de passe, autofill, etc…

En gros, sauf pour l'embarqué, c'est assez inutile. Et pour l'embarqué, il y a LVGL qui est quand même LA référence.

Ça utilise weboob (web out of browser), qui est techniquement un web scraper. C'est à dire que ça simule un utilisateur qui se connecte via l'interface web de la banque.

Attention à ne pas les mettre à jour, car avec les derniers firmwares, l'imprimante ignorera la calibration de position des toner pour les cartouches compatibles.

J'ai la mienne depuis 2010, aucun problème, utilisée quotidiennement. Mise à jour par ma fille parce que l'imprimante lui disait de le faire.

Bam, impossible d'avoir une impression correcte depuis, les couleurs sont nickel en haut de page, mais bavent en bas. Impossible de recalibrer, l'imprimante ignore le résultat de la calibration puisque j'ai des toner compatibles.

Il faudrait revenir à une version antérieure du firmware, sauf que je ne sais plus quelle version elle avait.

Bref, manœuvre douteuse de la part de Brother qui fait que plus personne dans mon entourage n'achètera cette marque à l'avenir. Bravo Brother qui préfère avoir 0% de énormément que 80% de beaucoup!

Je plussois. Entre l'article qui confond puissance (W) et consommation (J), et le préjugé sur le temps de chauffe, je ne peux que conseiller à l'auteur de comprendre que 1000W pendant 1ms consomme moins que 10W pendant 1s.

De plus, ceux qui ont démonté une telle imprimante verront que ce n'est pas le laser qui est utilisé pour chauffer (car là, le laser, ça a un rendement pourri, 30% au maximum), mais une bête lampe à incandescence emprisonnée dans une tube en métal peint en noir (appelé fuser)

Sur les nouvelles imprimantes "laser", ils utilisent maintenant des diodes (plus du laser, car meilleur rendement)

Par contre, dans les nouvelles versions de firmware de Brother sur les imprimantes lasers, ils ont désactivé la calibration de position des têtes d'impressions pour les cartouches compatibles. Résultat, ça marche avec des cartouches compatibles (10x moins chères) mais les couleurs bavent (et ceux malgré les multiples tentatives de calibration réalisées dans le menu ou à la main suivant la procédure de maintenance). Il faut donc récupérer la puce des toners officiel et remplacer la puce des cartouches compatibles (ce que, si vous avez, comme moi, utilisé pendant des années des cartouches compatibles, vous n'avez plus).

C'est pas de l'obsolescence programmée (illégal) car l'imprimante fonctionne toujours un petit peu, mais je pense que vu le prix de l'imprimante laser où le principe est n'est pas de payer l'imprimante via ses cartouches, c'est une honte.

Ce qui fait que je ne conseille ni n'achète plus de Brother, ni HP. Dommage car elles sont increvables.

Les données (chunks/multichunks) sont immutables. C'est uniquement l'index qui mute et qui est ensuite recopié sur le serveur/répertoire à distance (puis swappé/rename avec le précédent de manière atomique).
Donc c'est assez sûr en fait, tu ne peux avoir de corruption à aucun moment sur le répertoire de backup.

En cas de corruption du support de stockage, détecté par un checksum/hash qui ne colle pas, vu que l'index contient toutes les révisions précédentes, au pire tu retrouveras une version précédente.

Par contre, en cas de corruption du support de stockage sur les données, là, je n'ai pas de protection (type Reed Solomon, ECC, Turbocodes). Vu que j'utilise des machines en RAID1, je me dis que c'est peu probable que ça arrive pile sur 2 disques au même endroit en même temps. Il faudrait ajouter de la redondance idéalement…

Pardon, j'aurais du dire sur la même architecture, plutôt que la même machine. C'est pas une archive, c'est un backup. Typiquement si tu as un problème (disque, machine qui crame), tu va changer le matériel défectueux et restaurer ta sauvegarde. Personnellement, vu que je sauvegarde /etc avec, je me vois mal changer d'architecture entre la restauration et la sauvegarde.

Si tu veux passer sur un nouveau type d'architecture, c'est possible, mais il faut lancer une VM pour faire tourner Frost dans l'ancien endianness, restaurer puis re-sauvegarder hors de la VM. Je n'en ai jamais eu la demande, je pense que c'est juste un problème théorique qui a aucune utilité pratique.

Dans la pratique, je suis passé d'un backup en ARM64 vers AMD64 sans problème lorsque j'ai changé mon NAS. Architecture différente mais compatible en endianness.

Borg est apparu après que j'ai commencé Frost.

J'ai d'ailleurs une issue encore ouverte qui me demande de comparer avec Frost.
Donc pour résumer à ce que j'ai compris:

1. Borg fait de la déduplication comme Frost, en utilisant un rolling checksum (type Adler32 chez Frost, ppargon je crois chez Borg)
2. Borg est écrit en python (Frost est natif, non interprété) avec le code de la crypto en C/Cython, Frost utilise OpenSSL et est donc accéléré en HW si disponible.
3. Borg compresse en LZ4, Zlib, Zstd (Frost, c'est seulement en Zlib et BSC, une sorte de LZMA 2x plus efficace). J'avais des plans pour implémenter Zstd, mais finalement, BSC, ça marche suffisamment bien, j'ai eu la flemme de changer.
4. Chaque chunk de données est identifié par son checksum, un hash SHA1 (soit 24 octets) chez Frost, la corruption est très improbable. Chez Borg, c'est un SHA256 (soit 32 octets). Je m'attends à ce que l'index chez Borg soit au moins 33% plus gros.
5. Borg v2 fait de l'authenticated encryption (AES_OCB/AEAD) alors que Frost fait du Encrypt en AES_CTR then MAC.
6. Les 2 fournissent un "driver" FUSE pour monter les archives
7. Borg ne fait pas de mmap sur ses index, et donc il faut avoir suffisamment de mémoire vive pour charger l'index en entier dans la mémoire. Ce qui limite, AMHA, à environ 100k fichiers par Go de mémoire sur Borg. Frost n'a pas ce problème.
8. Borg est beaucoup plus maintenu, il a en place une sorte d'organisation qui peut recevoir des dons (support pour les personnes en difficulté). Frost, c'est pas le cas.
9. Borg fonctionne à la fois comme serveur et comme client, il peut être appelé par SSH pour gérer l'envoi et la réception de chunks/multichunks. Ce qui nécessite une bonne connexion de données, pour la sauvegarde à distance et surtout la possibilité de lancer un processus sur un serveur distant. Frost lui travaille au niveau du système de fichier, donc il est indépendant du serveur et se base sur FUSE pour monter un serveur distant localement. Typiquement, ça veut dire que Frost fonctionnera sur de l'Amazon S3, du SSH/SFTP, du FTP, du Webdav, car il existe des "drivers" FUSE pour chacun de ces formats.
10. De plus, Frost utilise un index des fichiers local donc démarre beaucoup plus rapidement la sauvegarde, comparé à Borg qui doit le télécharger à chaque backup. Pour donner un ordre d'idée de la taille de l'index, il fait 1.7GB pour un backup de 136G (compressé) depuis 7 ans.

Voilà.

Bon, comme tu l'as vu toi même, effectivement, l'idée c'est de mmaper un fichier (quitte à le réagrandir avec ftruncate), et de créer directement les structures de données dans l'espace mémoire mappé du fichier (en C++ avec le placement new, je ne sais pas en Rust comment faire). Ce qui évite toute copie de données (vu que tu travailles directement dans le fichier) mais ça nécessite de ne pas avoir de pointeur mais des index dans d'autres conteneur (ce qui n'est pas plus mal en fait, ça rend le code beaucoup plus stable).

Du coup, lors d'une itération de ton archive, tu peux directement "pointer" sur les données précédentes, que tu n'as même pas besoin de lire physiquement. Ce n'est pas le cas en mode "read" où tu dois charger tout l'index en mémoire pour le modifier.

Évidemment, le prix à payer, c'est la portabilité, c'est à dire que sur les machines big endian (est-ce que ça existe encore ces choses ?) ne peuvent pas lire une archive LE, car il faut swapper les entiers avant de les utiliser. Mais pour une solution de backup, vu que tu restaures l'archive sur la même machine que tu sauvegardes, l'endianness ne change pas, ce n'est pas un problème.

Je fais effectivement un diff inversé (pas sur les données, seulement sur l'index), comme git pack car à chaque fois que tu lances un backup, c'est beaucoup plus rapide que d'avoir à reconstituer l'index à partir de la genèse. Donc, oui, je modifie l'index en fin de backup en stockant la version la plus récente comme une nouvelle itération, comprendre la hiérarchie complète des fichiers, à la fin de l'index avec un lien vers l'index de la version précédente. Puis dans le header de l'archive, je change le pointeur du catalogue vers la dernière version.

J'ai également une fonction de purge qui élimine les révisions les plus anciennes (probablement la fonction la plus dure à coder pour un système de backup qui déduplique).

La documentation du format est dans le header "Frost.hpp" vers la ligne 268.

C'est assez marrant en soi, car ton projet ressemble beaucoup à ce que j'avais fait avec Frost. Le programme est un logiciel de backup avec déduplication basée sur le contenu (donc capable de détecter l'ajout d'un caractère dans un fichier texte et de ne stocker qu'un bloc autour du changement).

Et on retrouve les mêmes idées que pour Jubako, notamment pour le format d'archive.
J'avais commencé avec du SQLite3 pour l'index (ce que tu appelles Directory + Metadata) mais c'était vraiment trop lent lorsque le nombre de fichier devenait grand (et ce, malgré les index dans SQLite).

Du coup, j'ai créé une archive à la mano, qui est mmappée, et modifiable par génération (c'est à dire que la nouvelle génération peut soit référencer la précédente, soit l'écraser totalement ou partiellement, suivant ce qui est le plus efficace).

Elle fonctionne en gros comme Jubako, mes ContentPack c'est des fichiers indépendants (qui sont compressés, coupés en bloc de taille fixe, puis chiffrés) et mon fichier d'index qui contient les Directory + Metadata (comme c'est du backup, j'y stocke toutes les métadonnées POSIX).

Ça fait 7 ans, utilisé quotidiennement sur 34To et je ne regrette pas du tout d'y avoir investi du temps, c'est super efficace, ça m'a sauvé plus d'une fois.

Si je peux de donner des conseils sur l'évolution du format, il faut absolument regarder du côté des structures mmapables (le gain de performance est délirant) et du stockage de différences (je détecte les différences via un rolling checksum à points de division fixe, ce qui permet de s'adapter à de nombreux formats, comme le texte ou les formats binaires). Ainsi, tu peux découper tes content pack en fonction du contenu (et en virant donc tous ce qui se déduplique facilement). Tu peux aussi gérer l'ajout dans un conteneur, simplement en stockant la différence avec la version présente dans le conteneur.

Dans mon cas, je recalcule toujours la différence entre la version actuelle et la dernière version et je modifie la dernière version pour arriver à la version actuelle, ce qui est beaucoup plus efficace que le contraire.

Si tu affiches l'extension sous forme d'icônes, alors il ne sert à rien de la répéter dans le nom du fichier.
Aussi, je suppose que chaque fichier étant représenté comme un lien, en cliquant dessus on le télécharge ?
Si oui, le bouton Download ne sert à rien.
Le bouton Rename ou Delete devrait utiliser des icônes. Idéalement, ces icônes ne doivent pas être visible par défaut car ce sont des actions "à effet", il faudrait 2 clics pour effacer un fichier ou le renommer. Peut être en mettant ces icônes dans une sorte de menu accordéon, ça pourrait le faire.

Regarde un peu ce genre d'interface:
https://tinyfilemanager.github.io/demo/
https://filegator.io/
https://filerun.com/demo
https://larsjung.de/h5ai/demo/header%20and%20footer/
https://www.filestash.app/ (en mode liste)

Après, vu l'état du code, c'est déjà un cauchemar à lire, sans la gestion des erreurs.

Pourquoi? Parce que ce genre de code spaghetti n'a pas été pensé comme il le faut.
D'ailleurs, exception ou pas, tu as une boucle infinie dans ton code (si getc() > 2 ou al).

Si c'est un parseur que tu veux, tu ne fais pas "en série", sauf cas très simple, mais "en parallèle" avec une gestion d'état. Et là, magie, le code devient beaucoup plus simple à écrire et parser, exceptions ou pas.

State get(State s) 
{
   int c = getc();
   if (c == EOF)        return EOF;

   // Logique du parseur ici
   switch(s) 
   {
   case Start: /* Transition de start à XXX */ 
      if (c == 1)       return ActionA; 
      else if (c == 2)  return NeedMoreInput; 
      return ActionD;
   case NeedMoreInput: /* Transition de start à ActionB ou C */
      if (c==0)         return ActionB; 
      return ActionC;
   default: return EOF;
   }
}

void parse() {
  enum State s = Start;
  while (true) {
    s = get(s);
    // Action du parseur ici
    switch(s) {
       case ActionA : actionA(); break;
       case ActionB : actionB(); break;
       case ActionC : actionC(); break;
       case ActionD : actionD(); break;
       case EOF : return;
    }
  } 
}

Utiliser des exceptions pour faire du retour de fonction, c'est créer 2 chemins (ou plus), là où il n'y en avait qu'un avant. Tu fais ça sur 10 niveaux, tu as maintenant 1024 chemins (ou plus) à tester et valider (donc 10x plus de code de test à écrire). Je te souhaite bien du courage.

Après, si une exception ne fuite pas vers le haut (difficile en général à réaliser), alors oui, les exceptions peuvent être utiles pour simplifier le code, mais il n'y a, dans ce cas, quasiment jamais d'avantage par rapport à des retours normaux bien gérés.
Par contre, avec l'aide de macro simples (remplaçant le try), tu peux capturer un callstack et là oui, c'est super bien pour retrouver le problème et simplifie fortement le code de log (uniquement à destination d'un développeur, car pour le pékin moyen, le log c'est mieux).