rsync est un logiciel libre de synchronisation distante de fichiers (remote synchronisation), très utilisé et fréquemment évoqué sur LinuxFr.org. Ce logiciel a connu une polémique récente sur l’utilisation de LLM pour son développement et maintenant les versions concernées sont arrivées dans Debian, non seulement les versions futures de la distribution mais également la version courante. Et la suite de la dépêche de s’interroger sur les conséquences ou non de ce (peut-être) notable événement. Et plus largement sur le clivage autour de l’intelligence artificielle générative.

Le 20 mai 2026, la version 3.4.3 a été publiée, amenant des correctifs sécurité et des corrections de bugs. Et très vite les critiques sont arrivées (par exemple le 29 mai le bug Debian Consider reverting to pre-LLM version (considérer un retour à une version pré-LLM) ou le 30 mai un ticket GitHub Please Do Not Vibe Fuck Up This Software (quelque chose comme merci de ne pas sIAloper ce logiciel) attribuant les problèmes à l’intelligence artificielle ; ceci a entraîné une réponse du mainteneur Andrew Tridgell rsync and outrage expliquant s’être aidé de LLM pour réécrire sa suite de tests (du shell au Python). Et les régressions constatées n’étaient pas liées à l’IA au final.

Dès le 20 mai, la première version post-polémique atteignait les dépôts Debian de développement ([2026-05-20] Accepted rsync 3.4.3+ds1-2 (source) into unstable). Et en août la version 3.5 y est entrée ([2026-08-17] Accepted rsync 3.5.0+ds1-1 (source) into unstable).

En juillet et août 2026 a eu lieu un scrutin pour les personnes développant la distribution Debian sur l’usage des LLM (voir les annonces, discussions, résultats et conséquences 1, 2, 3). Le choix s’est porté sur un « usage responsable de l’IA générative ».

Le 15 septembre, le mainteneur Debian du paquet rsync a annoncé que « pour corriger 33 CVE, [il a] décidé de passer à la version 3.5.0 plutôt que de rétroporter toutes les corrections individuellement » (ce qui entraîne des changements de comportement, est annoncé à la mise à jour du paquet et a amorcé la réflexion qui a donné lieu à cette dépêche).

Verra-t-on un basculement majeur vers autre chose que rsync des réfractaires à l’IA ? Est-ce un non-événement ? Est-ce le premier de nombreux cas où des paquets embarquant des modifications faites par un LLM (sont arrivées et) arriveront dans Debian ?

D’une part, la fracture sur le sujet est palpable : ainsi le sondage StackOverflow 2025 rapportait 20% de défavorables à l’IA, 60% de favorables et 20% d’incertains/indifférents, mais avec 33% de confiance dans l’IA et 46% de défiance, et 32% d’utilisateurs de l’IA et 38% de réfractaires à l’idée. Le sondage State of Devs 2026 donne un 50/50 sur les avis positifs ou négatifs sur l’IA, sur l’effet sur l’état mental de l’IA, et classe en premier comme risques l’impact environnement, la perte d’emploi, la montée de l’IA slop, les effets cognitifs et l’usage militaire. Même le sondage State of IA 2026 est révélateur : les utilisateurs d’IA amplifient leur usage, avec de plus en plus d’agentique, tout en reconnaissant une addiction, une capacité à se faire traire financièrement (pour le dire grossièrement) et une montée des risques. Dit autrement tout en se traitant parfois qui de mormons passéistes rétrogrades qui de moutons suivistes antéchristiques (termes non contractuels), tout le monde reconnaît la complexité et la multiplicité des risques.

D’autre part, la capacité à faire autrement est assez réduite : forker une Debian en Devuan pour se passer de Systemd est « relativement » facile, on remplace un seul logiciel et les alternatives pré-existaient. Vouloir éviter d’être teinté par une GPL comme certains projets BSD reste faisable (il suffit d’une alternative à chaque logiciel GPL, et visiblement c’est plus ou moins le cas). Mais vouloir éviter tout logiciel libre ayant eu une contribution LLM est-il encore possible ? Est-on seulement capable de lister les logiciels concernés ? Et existe-t-il encore une alternative non-teintée à chacun d’entre eux ? Ne serait-ce pas aussi dur que par exemple vouloir faire du logiciel propriétaire sans jamais utiliser un seul logiciel libre quand ceux-ci sont omniprésents, en particulier dans le développement logiciel ?

Bref, est-on à une croisée des chemins ? Ou déjà bien engagé sur une route (et laquelle) ? La réponse est laissée en exercice au lectorat (moi à la base je voulais juste mettre à jour des Debian).

En ce mardi 15 septembre, la communauté du Projet Fedora sera ravie d'apprendre la disponibilité de la version Beta de Fedora Linux 45.

Malgré les risques concernant la stabilité d’une version Beta, il est important de la tester ! En rapportant les bogues maintenant, vous découvrirez les nouveautés avant tout le monde, tout en améliorant la qualité de Fedora Linux 44 et réduisant du même coup le risque de retard. Les versions en développement manquent de testeurs et de retours pour mener à bien leurs buts.

La version finale est pour le moment fixée pour le 20 octobre, 27 octobre ou le 3 novembre.

Sommaire

• Expérience utilisateur
• Gestion du matériel
• Internationalisation
• Administration système
• Développement
• Projet Fedora
• Tester

Expérience utilisateur

• L'environnement de bureau GNOME est proposé dans sa version 51 ;
• Les versions atomiques bénéficient de l'interface web d'Anaconda pour l'installation du système ;
• Ces mêmes versions peuvent bénéficier de l'installation distante via HTTPS ;
• En cas de certaines erreurs fatales du noyau, le QR code d'erreur généré redirige vers le site https://drm-panic.fedoraproject.org/ pour expliquer plus simplement l'erreur rencontrée ;
• Passage des utilitaires KWallet et GNOME Keyring à oo7 pour l'accès et la gestion des données privées, comme les mots de passe ;
• Amélioration de bash-color-prompt pour rendre la personnalisation du prompt plus simple ;
• L'aide de LibreOffice repose maintenant sur des pages web ouverts depuis un navigateur externe ;
• Les dictionnaires fournis par le projet LibreOffice peuvent être installés en lieu et place de ceux du projet hunspell dont ils dérivent.

Gestion du matériel

• mkosi-initrd est proposé comme alternative à dracut pour générer des fichiers initrd pour être évalué avant un éventuel remplacement.

Internationalisation

• L'outil d'aide à la saisie IBus évolue à la version 1.5.35 ;
• Mise à jour de fontconfig à la version 2.18.

Administration système

• NetworkManager prend en charge les réseaux IPv6-mostly ;
• Par défaut et pour des raisons de sécurité, l'API noyau ptrace n'autorisera plus certains accès à moins d'installer certains logiciels comme un débogueur qui peuvent en avoir besoin ;
• Les utilitaires chpasswd et newusers utilisent dorénavant PAM pour valider les droits et si les mots de passe sont conformes à la politique de sécurité du système ;
• Les consoles virtuelles passent de fbcon à kmscon ;
• Déplacement des fichiers des dépôts du répertoire /etc/yum.repo.d vers le répertoire /usr/share/dnf5/repos.d ;
• Anaconda prend en charge le gestionnaire de stockage Stratis ;
• Le logiciel Ignition gère le format de configuration généré par l'outil Butane ;
• L'API noyau de cryptographie à destination de l'espace utilisateur est désactivé ;
• L'outil d'authentification authselect ne prend plus en charge les profils NIS ;
• L'utilitaire des paquets rpm passe à la version 6.1 ;
• Ce dernier rend obligatoire la vérification des signatures des paquets avant leur installation ;
• La bibliothèque de sécurité OpenSSL est mise à jour vers la version 4.0 ;
• Le gestionnaire de conteneurs podman est proposé dans sa 6e version ;
• La version par défaut du gestionnaire de base de données MySQL pointe vers la version 9.7 au lieu de la version 8.4 ;
• La version par défaut du gestionnaire de base de données MariaDB pointe vers la version 12.3 au lieu de la version 11.8.

Développement

• La chaine de compilation GNU progresse avec GCC 16.2, binutils 2.47, glibc 2.44 et gdb 17.2.
• La chaine de compilation LLVM version 23 est proposée ;
• Le langage Python rampe vers la version 3.15
• La bibliothèque python-dateutil est marquée comme dépréciée en vue d'une suppression future ;
• L'utilitaire Python setuptools est proposé avec la version 82 ;
• Le langage Go saute vers sa version 1.27 ;
• Le langage Perl brille dans sa version 5.44 ;
• L'interpréteur Lua est mis à jour vers la version 5.5 ;
• La boîte à outils Ruby en Rails roule vers sa version 8.1 ;
• Le générateur de protocoles protobuf passe à la version 6 ;
• Le langage fonctionnel Erlang évolue vers la version 27 ;
• La bibliothèque d'analyse de données Pandas pousse à sa version 3 ;
• La bibliothèque xmlsec parse sa version 1.3 ;
• L'environnement de développement de Free Pascal nommé Lazarus dispose d'une interface graphique GTK3, Qt5 ou Qt6, en plus de GTK2 jusqu'alors proposée ;
• La configuration des pilotes ODBC, pour la création d'API pour les gestionnaires de base de données, a été scindée pour améliorer la modularité de ce fichier ;
• Nodejs a maintenant des métapaquets versionnés pour toutes les versions disponibles dans Fedora Linux.

Projet Fedora

• Les images atomiques sont construites avec l'utilitaire image-builder ;
• Le paquet libgit2 bénéficiera de plusieurs paquets avec des versions distinctes pour pouvoir les installer en parallèle ;
• Les variables non standards de CMake sont supprimées de la macro %cmake ;
• Ajout de la macro %openpgpverify pour effectuer les vérifications de signatures avec Sequoia en remplacement de %gpgverify qui utilise GnuGP.

Tester

Durant le développement d'une nouvelle version de Fedora Linux, comme cette version Beta, quasiment chaque semaine le projet propose des journées de tests. Le but est de tester pendant une journée une fonctionnalité précise comme le noyau, Fedora Silverblue, la mise à niveau, GNOME, l’internationalisation, etc. L'équipe d'assurance qualité élabore et propose une série de tests en général simples à exécuter. Suffit de les suivre et indiquer si le résultat est celui attendu. Dans le cas contraire, un rapport de bogue devra être ouvert pour permettre l'élaboration d'un correctif.

C'est très simple à suivre et requiert souvent peu de temps (15 minutes à une heure maximum) si vous avez une Beta exploitable sous la main.

Les tests à effectuer et les rapports sont à faire via la page suivante. J'annonce régulièrement sur mon blog quand une journée de tests est planifiée.

Si l'aventure vous intéresse, les images sont disponibles par Torrent ou via le site officiel.

Si vous avez déjà Fedora Linux 44 ou 43 sur votre machine, vous pouvez faire une mise à niveau vers la Beta. Cela consiste en une grosse mise à jour, vos applications et données sont préservées.

Nous vous recommandons dans les deux cas de procéder à une sauvegarde de vos données au préalable.

En cas de bogue, n'oubliez pas de relire la documentation pour signaler les anomalies sur le BugZilla ou de contribuer à la traduction sur Weblate. N'oubliez pas de consulter les bogues déjà connus pour Fedora 44.

Bons tests à tous !

De nombreux organisateurs, organisatrices et associations tech (59 actuellement) ont cosigné une lettre ouverte lancée par l'Association française des utilisateurs de PHP (AFUP) pour alerter sur la crise que traverse les événements techniques : « Budgets sponsoring resserrés, achats de billets en baisse, adhésions associatives en recul : partout, les mêmes signaux d’alerte s’allument et l’inquiétude s’installe au sein des organisations. »

Les signataires appellent les entreprises et les professionnels du secteur à : sponsoriser les événements techniques et à les placer dans leur stratégie, à sanctuariser des places pour les équipes, et à adhérer aux associations organisatrices.

« Ce n’est pas une question de générosité, mais d’investissement direct dans la compétence, l’attractivité et la résilience de vos propres équipes techniques. Nous avons conscience que la situation économique est difficile, mais nous faisons appel à toutes et à tous pour que l’écosystème survive, les événements tech en sont un pilier. »

« Derrière ces trois constats [le début d'une transformation qui touche tout le monde, une formation que rien ne remplace, remettre l'humain au centre] se joue une question plus large : quel écosystème technique voulons-nous : un quotidien dicté par nos outils, ou un secteur qui continue à se construire collectivement ? Ce choix se fait dès aujourd’hui, dans les décisions budgétaires de chaque entreprise. »

Message l'AFUP en mars : « Nous avons perdu 40% de nos financements pour l’AFUP Day 2026 par rapport à 2025. D'autres événements techniques annoncent également leurs difficultés. Du côté des billetteries de l'AFUP Day 2026, elles affichent un retard de 50% par rapport à la même période en 2025. »

Amélie Benoit (BDX I/O) : « On oublie parfois que sponsoriser un événement, c’est aussi apporter une visibilité durable et un soutien incommensurable à tout un écosystème tech local. Sans ce soutien, les événements vont tout simplement mourir. Et il n’y aura possiblement plus d’événements lorsqu’elles auront des besoins de visibilité et de recrutement. »

Arch Linux est une distribution très connue pour être une bonne base permettant de créer son propre système Linux personnalisé de fond en comble. La possibilité d’y ajouter des logiciels libres peu connus du grand public via l' AUR est l’une des grandes forces d’Arch Linux.

J’ai donc une vision personnelle assez précise du bureau Linux idéal, et je souhaite la partager ici en vous présentant un projet sur lequel je travaille depuis un peu moins d’un an, presque non-stop. Ma propre distribution Linux : SlyOS, un système d'exploitation libre distribué sous licence GPLv3.

Par exemple, voici quelques logiciels disponibles dans l'AUR : DeaDBeeF, Cine, Warehouse, Carburetor, …

Arch Linux est aussi une distribution valorisée par son choix presque illimité d'environnements de bureau. En effet, on peut prendre l'exemple de mon expérience personnelle sur ce point.

J’ai tout d'abord commencé par découvrir GNOME. Son interface m’a immédiatement convaincu et il reste aujourd’hui l’un de mes environnements de bureau préférés. La principale réserve que j’ai à son sujet concerne sa dépendance trop marquée à plusieurs composants de systemd (j’expliquerai plus tard dans la dépêche ce qui me tracasse vraiment à ce sujet).

J’ai ensuite essayé plusieurs environnements de bureau moins répandus, notamment Pantheon. Je reste particulièrement attaché à son interface, mais j’ai fini par l’abandonner en raison de bugs que j’ai rencontrés avec le compositeur Gala, ainsi que des difficultés liées à la transition de X11 vers Wayland. Cette transition a notamment retiré Plank, que j’appréciais beaucoup, sans vraiment lui apporter de remplaçant…

Ou encore moins connu : herbstluftwm que j'aimais beaucoup mais que j'ai fini par abandonner aussi à cause du manque d'outils de personnalisation sur X11 pour un gestionnaire de fenêtre si minimal.

J'ai aussi testé plein d'autres gestionnaires de fenêtre et de d'environnements de bureau tels que Cinnamon, Xfce, Hyprland, Fluxbox, LXQt, MATE, Sway, IceWM…

Avec le temps, j'ai façonné quelques opinions sur les différentes options que nous propose la communauté. Par exemple, cela peut en affecter certains, mais j’essaie d’éviter Qt au maximum et de privilégier GTK. Ma position concerne principalement le modèle économique de Qt : je ne reproche pas à un projet libre de chercher à se financer, mais Qt repose notamment sur les revenus provenant de logiciels propriétaires et de licences commerciales (proposant des offres payantes sur son site web). Je préfère donc soutenir des projets qui privilégient d’autres modèles, comme les dons, à l’image de ce qui existe autour de GTK. Ma position peut paraître controversée, notamment parce que l’écosystème Linux dépend lui aussi largement de grandes entreprises (comme Google, ou même Microsoft qui détient GitHub). Je ne prétends donc pas pouvoir éviter toute dépendance de ce type, mais j’essaie, autant que possible, de privilégier des logiciels et des projets capables de subsister sans être directement financés par le logiciel propriétaire.

De même, je n’aime pas vraiment systemd car c'est de plus en plus un programme qui obtient le monopole, avec une étendue de fonctionnalités et une complexité qui s'éloignent du principe KISS. Surtout que récemment, systemd a été au cœur de débats controversés, notamment à travers une proposition de vérification de l’âge intégrée directement à celui-ci. Le problème n’est pas uniquement l’existence de ce champ optionnel (birthDate), mais le fait que systemd puisse devenir un point central pour intégrer ce type de mécanisme à l’avenir. C'est pourquoi je préfère limiter les composants centraux aux fonctions dont le système a réellement besoin.

Cette problématique de vérification d'âge ne se limite d'ailleurs pas à systemd : le plus gros problème actuel est aussi xdg-desktop-portal. Mais il est à l'heure actuelle compliqué de changer cela, puisque xdg-desktop-portal est une dépendance presque cruciale dans Arch Linux. Un paquet alternatif contenant un patch pourrait être envisageable dans le dépôt de SlyOS via notamment l'alternative de xdg-desktop-portal Ageless Linux, mais je n'ai pas vraiment le temps d'accomplir cela pour l'instant.

J'ai dû parfois remettre en question certaines de mes opinions comme ma préférence à X11. Cela a par exemple opéré quand j'ai découvert niri et la stabilité et fluidité de Wayland nettement supérieure à X11.

SlyOS est basé sur Arch Linux et construit à l’aide d’archiso. Le projet a commencé comme une expérience personnelle pour en apprendre davantage sur Linux. Je me suis rendu compte par la suite qu’il y avait un réel intérêt à proposer ma vision du bureau Linux parfait, car je ne l’avais étrangement vue nulle part ailleurs (par défaut dans un système d'exploitation).

Je sais que les concepts revendiqués par une distribution peuvent paraître flous ou consensuels (moderne, léger, simple à utiliser, intuitive, personnalisable, performant, stable, respectant le principe KISS), mais dans SlyOS, chacun de ces principes correspond à des choix concrets et justifiés qui permettent à SlyOS d'être une distribution :

• Moderne : SlyOS propose niri, un gestionnaire de fenêtres entièrement basé sur Wayland, relativement récent, qui a déjà fait ses preuves (notamment par sa popularité en croissance exponentielle) et qui bénéficie d’un développement actif.

• Légère : la version minimale de SlyOS contient moins de 700 paquets, tandis que la version complète en contient moins de 850. Les ISO sont nettement plus légères que celles de nombreuses distributions x86_64, réduisant les composants susceptibles de poser problème, sans pour autant supprimer les fonctionnalités essentielles.

• Simple d’utilisation et intuitive : SlyOS propose un programme d’accueil dès le live ou après l'installation, présentant les raccourcis principaux. Le système peut être utilisé sans ligne de commande grâce à Pamac. Le bureau minimal et l'accès aux paramètres permettent à un débutant de prendre le système en main rapidement.

• Performante et stable : SlyOS utilise le noyau linux-cachyos-lts pour un bon compromis performances/stabilité. La consommation de RAM au démarrage est très basse grâce à un nombre limité de services en arrière-plan grâce à l'esprit minimaliste de SlyOS.

• Personnalisable : SlyOS s’appuie sur des outils Wayland comme Ironbar, Wofi, Hyprlock ou Vibepanel. Ils offrent un environnement complet tout en laissant une grande liberté de modification (ils peuvent être désinstallés et remplacés). Le choix de niri facilite également cette personnalisation profonde puisque largement reconnu dans le domaine du "Rice".

• Respectueuse de la vie privée : remplacer systemd par OpenRC est une première marche vers une meilleure protection de la vie privée dans un système Linux. De plus, SlyOS contient LibreWolf, un navigateur axé sur la vie privée bloquant le pistage, ainsi que les extensions uBlock Origin (bloqueur de pubs et traqueurs efficace) et Decentraleyes (empêche le suivi par les CDN en servant les ressources localement). Il intègre aussi le DNS Mullvad Base qui chiffre vos requêtes DNS pour empêcher les écoutes et les fuites de données vers votre FAI.

• Suivre le principe KISS en évitant systemd (plus d'informations ici) : SlyOS utilise OpenRC, un système d'initialisation qui suit une approche plus modulaire et plus proche du principe KISS que systemd, régulièrement critiqué pour son poids et sa complexité. Ce choix permet d'éviter de renforcer la position dominante de systemd tout en limitant les risques de dérive (comme l'intégration d'un champ birthDate).

À ses débuts, la distribution ne respectait pas entièrement tous ces critères. Elle utilisait GNOME / MATE, avec systemd ainsi que le noyau linux-cachyos-lts.

La distribution ressemblait à ceci à ses débuts, dans sa version 0.1 « Dxtrus » (pour "dexterous" en anglais) :

Depuis, le projet a considérablement évolué et est progressivement devenu un système plus complet et abouti, illustrant concrètement la direction prise par SlyOS. La version 0.2 « Invativ » (pour "innovative" en anglais) utilise désormais :

• niri comme gestionnaire de fenêtres
• OpenRC comme système d’initialisation
• ReGreet, une interface de connexion en GTK4 écrite en Rust pour greetd
• Le noyau linux-cachyos-lts
• Plymouth pour afficher un écran graphique lors du démarrage et de l’arrêt du système

Voici à quoi ressemble la distribution depuis :

La distribution inclut également un centre de contrôle appelé Thymbr, qui permet de configurer de nombreux aspects du système depuis une interface centralisée. Cela rend SlyOS bien plus intuitif et simple d’utilisation, bien que le caractère intuitif se juge surtout à l'utilisation.

Le site web du projet est disponible ici

Je vous conseille d’y jeter un coup d’œil. Le site propose une version française et fournit des explications plus approfondies sur le projet, notamment à travers les principes présentés sur la page d’accueil ainsi que la FAQ, accessible dans la catégorie « Aide ». Le meilleur moyen de se faire une opinion reste de tester SlyOS, par exemple dans une machine virtuelle.

La configuration archiso est disponible sur Codeberg : https://codeberg.org/Minaucro/SlyOS

Je travaille à rendre SlyOS pratique, optimisé, simple et performant, selon ma propre vision d’un système d’exploitation Linux destiné aux ordinateurs de bureau. Le projet est encore en développement, mais il est déjà suffisamment mature pour être testé et utilisé au quotidien.

Merci d’avoir pris le temps de me lire.

---

SlyOS a été créé par Minaucro (slyos@minaucro.fr).

Les employés de chez Xilinx aiment à raconter qu'ils sont les inventeurs du FPGA. Avec leurs glorieux XC2064 ils auraient été les inventeurs du concept et les premiers à en commercialiser.

Deux ingénieurs de xilinx en plein placement-routage du XC2064 ?

En est-on si sûr ?

Tout d’abord revenons à la définition d’un FPGA :

Field Programmable Gate Array

Littéralement: Grille de portes programmable sur le champ.

Les FPGA sont des composants munis d’éléments logiques plus ou moins complexes dont les connexions ne sont pas figées. Les connexions peuvent être re-programmées pour modifier l’architecture électronique du système en fonction du besoin sans avoir à démonter l’appareil à chaque fois.

L’aspect programmable ne doit pas être vu dans le sens d’un programme que l’on télécharge dans une mémoire pour qu’il soit exécuté par un processeur. Non, le bon mot serait plutôt configurable ou re-câblable (quel beau mot) au besoin.

Dans un FPGA moderne, les blocs que l’on peut connecter sont des éléments logiques (LUT), des multiplexeurs, des multiplieurs, des additionneurs, les sérialiseurs/dé-sérialiseur (serdes) sans oublier les blocs de mémoires ram (BRAM). Des PLL viennent en renfort pour générer des horloges pour cadencer tout ce bazar.

Plan du Gatemate A1 de Colognechip, les entrées sorties sont à la périphérie et les blocs logique au centre

Le « re-câblage » (on parle plutôt de configuration) est effectué en téléchargeant un fichier appelé bitstream dans la mémoire RAM ou flash du FPGA.

Mais alors revenons à l'ENIAC. Cette machine est considérée comme le premier ordinateur électronique. Quand on pense ordinateur vient tout de suite l’idée d’un processeur qui exécute des instructions enregistrées dans une mémoire.

Ça n’est pourtant pas le cas des débuts de l’ENIAC qui est conçu pour faire des calculs très rapidement, notamment pour calculer des tables de tir de missiles (pour tuer des gens). Et à chaque nouveau calcul il faut le re-câbler.

Les blocs que l’on peut connecter sont des multiplieurs, des additionneurs, des tables de fonctions (à roulettes) ainsi que des imprimantes et des lecteurs de cartes perforées pour les entrées/sorties.

Plan de l’ENIAC, il y quelques similitudes avec un FPGA. Cependant les blocs sont à l’extérieur et le multiplexage et les entrées sorties se font au centre. (sources https://historyofinformation.com)

Pour re-câbler l’ENIAC point de bitstream mais des équipes de câbleuses qui reconfigurent la machine pour lancer un nouveau calcul histoire de faire péter une bombe plus fort (nucléaire) ou de bien atteindre la cible avec un canon.

Câbleuses en pleine action, maintenant on télécharge un bitstream (source sigarch)

Mais, attendez, cette description ressemble furieusement à la description d’un FPGA non ?

Et oui, Xilinx n’a qu’à bien se tenir, le premier ordinateur électronique était également le premier FPGA de l’histoire. D’autres ont fait le lien également.

Peut-être pourrait-on l’inclure dans les outils de synthèse libre comme Yosys ?

Pas sûr.