Des brevets bien réels, des idées totalement improbables, et une créativité humaine qui ose absolument tout.
L’article Inventions insolites : quand l’ingéniosité humaine flirte joyeusement avec l’absurde, rédigé par Nathalie Kleczinski, est apparu en premier sur NeozOne.
ooooh y a de bonnes astuces que je ne connaissais pas. C'est encore plus puissant que je le croyais SQLite.
Pas besoin de scripts ; juste des fichiers de configuration décrivant l’état des hôtes.
Telle était la promesse de CFEngine lorsqu’il émergea dans les années 90. Avec son langage dédié, l’outil devait faciliter la maintenance des environnements BSD et System V (UNIX) en les organisant en classes. Il s’agissait déjà de répondre à la fragmentation des systèmes d’information…
Dans les années 2000, Puppet et Chef sont arrivés sur le même créneau, chacun avec son langage basé sur Ruby. L’un et l’autre fonctionnaient en mode pull, le client contactant régulièrement le serveur pour récupérer la configuration. On ne parlait pas encore de DevOps, mais d’automatisation du travail des sysadmins.
Au début des années 2010, AWS pousse le templating JSON/YAML avec CloudFormation. Ansible décline le concept en playbooks. Terraform l’adopte avec son propre langage (HCL) et le porte à l’échelle de déploiements multifournisseurs.
Face aux limites des langages dédiés et de l’option « tout YAML » apparaissent des outils comme Pulumi, qui adaptent les langages impératifs (Go, Python…) à la gestion d’infrastructure.
Avec ce bagage, l’approche « as code » s’est développée sur d’autres pans des systèmes informatiques : documentation, sécurité, politiques organisationnelles… ou encore observabilité. Dashboards, alertes, logs, traces, métriques, SLO/SLI, etc. deviennent autant d’éléments « codifiés » sur le même plan que l’infra ; et, in fine, déployés en parallèle, avec un repo Git comme « source de vérité ».
Corollaire de cette convergence, l’observability as code (OaC) porte globalement les mêmes promesses que l’infrastructure as code (IaC). À commencer par les bénéfices de l’automatisation.
Sur le papier, outre la réduction du potentiel d’erreurs humaines, on a des configurations reproductibles favorisant la cohérence entre environnements et la mise à l’échelle dans le contexte d’architectures dynamiques (microservices, workloads IA). On crée par ailleurs une boucle de rétroaction avec l’IaC, en bénéficiant de la traçabilité de Git – lequel permet aussi, en théorie, une reconstruction rapide de la stack d’observabilité.
En parallèle de leurs API, les principales solutions d’observabilité sont pilotables via Terraform, grâce à un provider. Elles proposent aussi d’empaqueter des configurations en charts Helm et d’utiliser des CRD pour définir des artefacts en tant qu’objets Kubernetes standards.
À cheval entre ces deux univers, il y a le projet Upjet. Celui-ci transforme les providers Terraform en providers Crossplane, tout en générant les contrôleurs de réconciliation et la documentation API avec des exemples de manifestes.
Du côté de Grafana, on expérimente actuellement une fonctionnalité Git Sync. Elle assure une synchronisation bidirectionnelle l’UI et le Git, avec la possibilité d’imposer que les changements réalisés sur l’interface passent par des PR. Pour le moment, certains artefacts ne sont pas pris en charge (alertes, panels…) et seul GitHub est géré (authentification par PAT uniquement).
Grafana a aussi, dans sa boîte à outils, un SDK Foundation orienté sur les langages à typage fort (on définit des dashboards en chaînant des appels de méthodes). Il a également une bibliothèque qui met en œuvre Jsonnet. Cette extension de JSON a été influencée par plusieurs langages de configuration utilisés chez Google. Elle facilite les regroupements logiques de configurations avec ajustement des variables à la volée pour contextualiser les artefacts.
À partir de Jsonnet, Prometheus a créé les mixins. Ce format encapsule des alertes/règles et des dashboards Grafana en compagnie du code avec lequel ils sont déployés.
Autre langage qui a ses racines chez Google : CUE (Configure, Unify, Execute). Il s’est en l’occurrence inspiré du langage utilisé pour configurer Borg, le prédécesseur de Kubernetes. En son cœur, une technique communément exploitée en linguistique informatique pour gérer grammaires et lexiques : l’unification de graphe. Types et valeurs sont fusionnés en un seul concept et ordonnés en une hiérarchie unique.
Associatif, CUE est aussi commutatif et idempotent : peu importe leur ordre, les valeurs produisent toujours le même résultat. On s’en servira typiquement pour la validation de schémas ou de données. Les types agissent alors comme des contraintes, réconciliables depuis plusieurs sources sans avoir à effectuer d’importations.
À petite échelle, un pattern traditionnel de déploiement de l’OaC repose sur la pile open source* Prometheus/Grafana/Loki/Jaeger. Souvent en monorepo avec un dossier pour les artefacts d’observabilité, un déploiement Helm ou CI/CD simple et une synchro par Git Sync ou API/webhooks.
À un deuxième niveau, chaque équipe possède son repo et sa configuration d’observabilité (« You build it, you run it »). Le déploiement peut impliquer Kustomize. Cet outil de gestion intégré à Kubernetes se distingue de Helm en permettant de surcharger toute valeur d’une configuration de base.
À ce même niveau, on voit souvent apparaître une gestion GitOps (réconciliation automatisée avec Flux ou Argo CD). Et le recours au collecteur OpenTelemetry pour standardiser la collecte sans modifier la couche d’instrumentation.
Viennent ensuite les plates-formes d’observabilité. À ce niveau, les identités machine se généralisent dans les pipelines. Et, avec elles, les systèmes de promotion automatisée, le contrôle de cardinalité (liste blanche de tags, politiques d’échantillonnage avec des outils comme Cribl et Vector) voire l’exploitation d’eBPF.
« Tout le monde échantillonne la data. La seule raison pour laquelle on le fait, c’est le coût de stockage », explique à ce sujet Stéphane Estevez, EMEA Market Advisor observabilité chez Splunk. Sa société, poursuit-il, a l’avantage de la taille : « Par rapport à nos concurrents, nos économies d’échelle ne sont pas les mêmes. On peut se permettre d’être compétitif tout en garantissant toutes les données ».
Vodafone en est arrivé à ce dernier stade. Il a plus précisément mis en place des modules d’observabilité Terraform. Ses développeurs consomment en self-service (ils n’ont qu’à déclarer les variables) et peuvent les modifier par PR.
Vu le nombre de développeurs, de services et d’artefacts d’observabilité, il a fallu diviser le fichier d’état (Terraform mettait sinon 17 minutes à s’exécuter).
Que ce soit pour créer un dashboard lors d’un incident ou modifier des seuils afin de « faire taire » des alertes, dans une approche OaC, l’utilisation de l’UI soulève la question de la réconciliation avec la partie as code. Une des réponses consiste à n’autoriser que ce qui passe par cette dernière, au minimum en production. Une autre, à verrouiller les états pour éviter les corruptions.
« Si on pousse la logique OaC, il faut accepter que la source de vérité, c’est ce qui est dans la codebase », confirme Pejman Tabassomi, Field CTO EMEA de Datadog.
Quant à enrichir l’OaC avec du machine learning, ce n’est pas forcément si évident. IBM, qui a son Cloud Pak for AIOps (évolutions des outils de Tivoli), en témoigne par la voie d’Éric Cattoir. L’intéressé fait partie d’une équipe technique au niveau EMEA couvrant les sujets regroupés sous la marque IT Automation. « On a essayé de faire des modèles basés sur l’analyse des logs, explique-t-il. On s’est aperçu que cette fonctionnalité dépend beaucoup de la structure et de la stabilité des fichiers. Chez certains clients, ça a nécessité beaucoup de rééducation des modèles, car il y avait trop de variabilité entre leurs systèmes ».
* Dans le domaine de l’open source, le projet Perses, en sandbox à la CNCF, pousse une spécification ouverte pour la visualisation des données d’observabilité. Pour le moment, métriques Prometheus, traces Tempo, logs Loki et profilage Pyroscope. Il inclut un vérificateur statique, un opérateur Kubernetes et un CLI pour réaliser des actions dans les pipelines CI/CD. Des SDK Go et CUE implémentent l’approche « as code ».
Illustration principale © Aryan – Adobe Stock
The post De l’infra à l’observabilité, mille et une nuances « as code » appeared first on Silicon.fr.
Yop !
Si vous avez la sensation que votre Windows 11 est devenu une espèce de panneau publicitaire géant bourré d'IA dont vous ne voulez pas, j'ai ce qu'il vous faut !!
Satya Nadella (le patron de Microsoft) a récemment parlé de "Slop" (ça veut dire bouillie) à propos de l'IA générative dans un billet de blog, mais ironiquement, c'est exactement ce que beaucoup reprochent à son OS aujourd'hui. A savoir que c'est devenu une accumulation de fonctionnalités imposées...
Sauf que voilà, pour nous, ça reste du gras qui peut ralentir certaines machines et polluer l'expérience. J'ai d'ailleurs passé pas mal de temps aujourd'hui sur un PC Windows 11 à essayer de virer manuellement des soft inutiles... Une tannée.
Hé bien, notre ami builtbybel (le créateur du génial FlyOOBE ) est de retour avec un nouvel outil baptisé Winslop.
L'objectif c'est de passer le Karcher sur la façade de votre OS pour virer tout ce qui ne sert à rien. En fait c'est un fork de son ancien projet CrapFixer, mais remis au goût du jour pour s'occuper spécifiquement des nouveautés un peu trop envahissantes de Redmond.
Concrètement, Winslop s'attaque à quatre types de "Slop" (et c'est un sacré paquet de trucs) :
Ce que je trouve top avec cet outil, c'est qu'il n'y a pas de magie. Vous récupérez l'archive sur GitHub (c'est une app portable), vous dézippez, vous lancez l'exécutable (en tant qu'administrateur pour que tout fonctionne), il scanne votre système, et il vous propose une liste de trucs à virer. Hop, vous cochez, vous appliquez, et c'est réglé.
Et là, vous me dites "Ouiiii mais euuuh si ça casse tout ?". Hé bien sachez les chers amis, Winslop met un point d'honneur à la réversibilité ! Donc normalement y'aura pas de soucis, mais je préfère être clair avec vous... Quand on touche aux entrailles de Windows, même Dieu ne peut pas savoir ce qui va arriver.
Donc, comme je le pête et le répète jamais assez, faites une sauvegarde ou un point de restauration avant de toucher à quoi que ce soit. On n'est jamais à l'abri d'un clic malheureux ou d'une mise à jour Windows qui n'aime pas qu'on lui grattouille les fichiers système. J'ai déjà eu le tour avec un script PowerShell obscur que j'avais lancé en mode yolo, et croyez-moi, je m'en suis mordu les doigts.
Voilà, donc à tous ceux qui se demandent comment supprimer les bloatwares sur Windows 11 sans y passer l'après-midi, Winslop est une solution géniale pour faire le ménage. Ça redonnera un peu d'air à votre ordi.
Windows 11 c'est un peu comme ce cousin relou qui s'incruste à tous les repas de famille avec ses nouvelles idées géniales qui ne marcheront jamais.
Entre Recall qui capture tout ce qui passe à l'écran (avec les polémiques qu'on connaît...), les "recommandations" publicitaires qui s'invitent dans le menu Démarrer et les mises à jour qui font parfois des siennes, la coupe est pleine pour les utilisateurs de Windows !
Du coup, comme tout le monde est en train de se barrer, ceux qui ont du budget vers Apple et ceux qui en ont moins, vers Linux, Microsoft semble enfin avoir une petite prise de conscience. Ah bah c'est pas trop tôt les copains… 😉
Hé oui, l'OS de Microsoft se traîne une réputation un peu moche depuis son lancement. J'ai même vu des tests, certes un peu biaisés sur du vieux matos genre ThinkPad X220 avec un vieux HDD pourri, montrer des performances moins bonnes par rapport à ce bon vieux Windows XP, sans parler d'une interface inconsistante et des exigences matérielles qui ont laissé un sacré paquet de machines sur le carreau.
Bref, c'est pas la joie.
Mais heureusement, Pavan Davuluri le président de Windows et du hardware chez M$, a décidé de siffler la fin de la récré. Pour cette année 2026, Redmond lance une grande opération baptisée "swarming" (un essaimage en gros) pour s'attaquer frontalement aux bugs les plus relous.
L'idée, c'est de redonner un peu de lustre à la bête et surtout de reconstruire cette confiance qui s'est évaporée plus vite qu'une cartouche de clopes dans un festival punk.
Microsoft veut donc se concentrer sur la performance brute, la fiabilité de l'interface et arrêter de nous gonfler avec des trucs dont personne ne veut. Pour ceux qui se demandent quels sont les principaux problèmes de Windows 11, la liste est longue : plantages de l'explorateur, barre des tâches capricieuse, ou encore les récents soucis de boot après la mise à jour de janvier 2026 sur certains systèmes.
Perso, je trouve ça un peu culotté de nous promettre la lune maintenant que le mal est fait et que tout le monde ou presque se soit vu migrer de force. D'ailleurs, si vous hésitez encore, sachez que le support officiel de Windows 10 s'est terminé le 14 octobre 2025 et que si vous y êtes encore, le support étendu (ESU) est la seule bouée de sauvetage officielle que vous avez.
Côté pratique, si vous voulez aider Microsoft à ne pas (trop) se louper, le meilleur moyen reste de passer par le Feedback Hub (Win + F) pour remonter chaque bug que vous croiserez. Et surtout, avant de laisser l'OS se mettre à jour tout seul, assurez-vous d'avoir une sauvegarde de vos fichiers importants sur un disque externe ou un NAS.
Voilà, moi maintenant, j'attends de voir si le tir est vraiment rectifié parce que bon, entre les promesses sur le gaming (DirectStorage, tout ça) et la réalité des perfs, y'a souvent un gouffre. Sans oublier les effets de bord cata à chaque patch... Argh... !
Je leur souhaite le meilleur avec ce "swarming" et en attendant, gardez un œil sur vos mises à jour et croisez les doigts pour que votre PC reste en forme.
L’expérience Guardian Angel est une démarche expérimentale de science participative visant à explorer les effets potentiels de l’observation différée sur la trajectoire de vie des participants. Elle repose sur une capsule scellée, un protocole de suivi sur deux ans et un engagement volontaire dans un cadre éthique fort.
L’expérience Ange Gardien vise une recherche rigoureuse sur les liens entre conscience, temporalité et bien-être. Une participation financière modérée est demandée pour garantir la qualité scientifique, la sécurité des données et la crédibilité du protocole. Cette contribution favorise un engagement responsable des participants sur deux ans, limite les participations non sérieuses et assure la fiabilité des données collectées dans cette démarche de science participative.
Capturer sélectivement des paquets réseau sans tout transmettre vers l’espace utilisateur : telle fut la première raison d’être de BPF (Berkeley Packet Filter). C’était dans les années 90, sur les systèmes UNIX-BSD. La technologie permettait, à l’appui d’un jeu d’instructions virtuel RISC-like et d’un interpréteur, d’injecter des programmes dans le noyau pour en étendre les capacités à l’exécution.
Les premiers usages au-delà du réseau avaient émergé au début des années 2010. À commencer par l’outil seccomp-bpf, servant à filtrer les syscalls. Les travaux de modernisation lancés dans ce contexte aboutirent à eBPF (extended BPF). Cette nouvelle incarnation fut intégrée à Linux en 2014. À la clé, entre autres, des instructions et des structures de données supplémentaires, davantage de registres, un compilateur JIT et des points d’attache additionnels pour les programmes. La promesse demeurait : apporter de l’extensibilité au kernel sans passer par des modules ou changer le code source.
Sur ce socle, des projets sont d’abord nés dans le domaine du traçage. Des couches d’abstraction ont pris corps en parallèle, comme la boîte à outils BCC (BPF Compiler Collection), associant front-end Python/Lua et back-end C pour faciliter l’écriture de programmes. Tandis que le compilateur fut intégré dans LLVM.
Facebook fut l’un des premiers à industrialiser eBPF, avec un équilibreur de charge L4 pour ses datacenters : Katran, aujourd’hui open source. La possibilité d’attacher eBPF très en amont sur le chemin de réception – en l’occurrence, au niveau du piote NIC – permet d’effectuer le load balancing à la source, sans NAT (paquets traités avant interception par le noyau).
Google a quant à lui contribué à faire avancer les choses dans le champ de la sécurité. Dans le cadre de l’extension de son offre Kubernetes vers les infrastructures sur site (sous les marques Anthos et GDC), il a donné naissance au framework BPF LSM. Celui-ci adapte le principe des modules de sécurité à l’écosystème eBPF, en permettant d’utiliser les mêmes hooks (points d’attache) que SELinux.
Pour rendre la technologie plus accessible, le projet Cilium fut lancé en 2016. Avec, pour le porter, une société aujourd’hui référente dans l’écosystème eBPF : Isovalent, qui appartient à Cisco depuis 2024. Il assurait initialement la mise en réseau de conteneurs. Dans ces environnements où les adresses IP tournent beaucoup, ses tables de hachage en ont fait une alternative plus « élastique » à Iptables/netfilter.
Après la mise en réseau vint l’observabilité, favorisée par la multiplicité des points d’attache exploitables. En plus de ceux prédéfinis (appels système, entrées/sorties de fonctions, tracepoints…), on peut utiliser des sondes noyau (kprobes) et utilisateur (uprobes). Mais aussi des fonctions arbitraires, en les étiquetant. L’exécution est orientée événements : les programmes eBPF se déclenchent lorsque le noyau ou une application passe par ces hooks.
Ce modèle ouvre la porte à la collecte de données sans instrumentation (pas de modification du code des applications ou des agents d’observabilité) et consommant potentiellement moins de ressources système. Cilium l’implémente via une plate-forme intégrée : Hubble, qui cartographie les services et donne une visibilité des flux grâce aux identités de workloads. Il y a ajouté une brique pour sécuriser l’exécution : Tetragon, qui met en œuvre des politiques de contrôle d’accès sur les fonctions noyau, les syscalls, etc.
Datadog aussi a un usage assez transversal d’eBPF : analyse de performance des applications (Universal Service Monitoring), visibilité sur le trafic réseau (Cloud Network Monitoring), détection des menaces (Workload Protection), supervision d’intégrité des fichiers (application de règles pour limiter les envois)…
« Sans eBPF, on aurait probablement besoin de consentir un effort de modification de la configuration des agents », fait remarquer Pejman Tabassomi, Field CTO EMEA, concernant le monitoring réseau. Sur la partie APM (surveillance des performances des applications), l’approche traditionnelle d’instrumentation « permet d’aller loin dans les détails, mais c’est contraignant parce qu’on est dépendant d’un framework ou d’un runtime », explique l’intéressé. eBPF « permet d’arriver à un objectif par tout à fait identique mais comparable, sans avoir à recourir à une librairie », déclare-t-il.
Pas tout à fait identique, donc. « Il y a une sorte de compromis entre le niveau d’introspection et la facilité de mise en œuvre », résume Pejman Tabassomi. Il l’illustre par un cas d’observation des temps de réponse entre deux services. Pour mesurer le nombre et la durée des appels, eBPF peut suffire. En revanche, s’il y a besoin de comprendre les lignes de code qui peuvent poser problème, les appels de fonctions et de méthodes qui sont en cause, « à ce moment-là, on va plutôt faire de l’APM. » Non sans surveiller des initiatives communautaires tel le profiler de code en cours de développement dans l’univers OpenTelemetry.
Chez Splunk, « l’histoire avec eBPF a démarré lors du rachat de Flowmill » en 2020, fait savoir Stéphane Estevez, EMEA Market Advisor pour l’observabilité. Cet outil de monitoring réseau a alimenté la stratégie « full OpenTelemetry » de l’éditeur. « Être chez Cisco nous a donné l’accès à Isovalent pour l’observabilité et la sécurité », précise Stéphane Estevez. Tetragon, par exemple, alimente des dashboards TCP et DNS dans la composante Network Explorer.
Chez IBM, Instana est le principal terrain d’implémentation d’eBPF. La technologie présente une utilité particulière pour la détection des crashs système, selon Éric Cattoir, membre d’une équipe au niveau EMEA qui couvre les sujets regroupés sous la bannière IT Automation. En écho à Pejman Tabassomi, il déclare, sur le volet instrumentation : « Ça rend la vie plus facile pour notre produit : on a moins à suivre l’évolution des technologies (nouvelles versions de langages, de compilateurs…) ». Instana a toujours eu une approche d’auto-instrumentation, rappelle-t-il, « mais c’est difficile à mettre en place pour certains langages : eBPF facilite cela en permettant d’obtenir de manière standard des informations de profilage ».
On trouve aussi de l’eBPF dans le produit SevOne (observabilité réseau), pour la couche overlay de Kubernetes.
Avec les années, les programmes eBPF sont devenus composables : ils peuvent appeler des fonctions (forme de gosub)… et d’autres programmes en remplaçant le contexte d’exécution (goto). Un mécanisme CO-RE (« Compile Once, Run Everywhere ») a été instauré à partir d’un format spécifique de métadonnées (BTF, BPF Type Format) pour procurer une portabilité entre les versions du kernel. Et des passerelles se sont créées avec l’espace utilisateur, à travers une des structures de données que gère eBPF : les magasins clé-valeur dits maps. Des outils sont par ailleurs apparus pour exécuter des programmes en userspace (rBPF, uBPF, bpftime). Ils ont accompagné l’émergence de langages de jaut niveau tel bpftrace – inspiré de DTrace, avec LLVM en back-end et BCC pour interagir avec le sous-système eBPF.
Sauf à activer le mode sans privilèges avec accès limité au noyau, les processus qui chargent des programmes eBPF doivent s’exécuter en mode admin ou avoir la capacité CAP_BPF. La mémoire est protégée en lecture seule et les accès sont masqués pour limiter les effets secondaires observables de l’exécution spéculative. Si une entité tente de modifier le programme, le noyau plante.
Le code passe dans tous les cas par un vérificateur statique. Lequel contrôle, en particulier, que le programme est d’une complexité finie, qu’il se terminera bien et qu’il n’entraînera pas de deadlock ni d’accès mémoire hors limites. Dans la pratique, l’outil reste sujet aux faux positifs. Jusqu’à Linux 5.3, les boucles étaient d’ailleurs proscrites dans les programmes eBPF, le vérificateur étant jugé capable de les évaluer efficacement.
Depuis 2021, il existe une Fondation eBPF. Google, Meta et Isovalent en sont membres platine. CrowdStrike – qui exploite la techno pour détecter les mouvements de données non autorisés – l’est aussi. Ainsi que Huawei, Intel, Microsoft – qui développe eBPF pour Windows tout en l’exploitant en remplacement du fournisseur d’événements AuditD dans Defender pour Linux – et Red Hat. Datadog est membre argent. Netflix, qui avait pris très tôt le train eBPF, l’est aussi.
Conjointement aux initiatives du marché, cette fondation soutient des projets académiques, à l’instar d’eBPF Governor, alternative aux sous-systèmes de gestion de l’alimentation sur Linux. Des recherches sont également en cours sur la vérification formelle des programmes, en complément à la réécriture du vérificateur en Rust.
Plusieurs projets devenus référents dans l’écosystème eBPF sont maintenant sous l’aile de la CNCF (Cloud Native Computing Foundation). Outre Cilium, on peut citer Falco (détection de menaces), confié en 2018 par Sysdig. Dans le champ de l’observabilité, il y a Pixie, que New Relic a reversé à la CNCF en 2021, quelques mois après en avoir fait l’acquisition (il en propose aujourd’hui une version SaaS).
Pièce maîtresse du réseau mondial de Cloudflare, eBPF a aussi investi les clouds hyperscale. À l’instar de Google sur GKE, AWS s’en sert sur son Kubernetes managé (Caretta pour la cartographie réseau, Hubble pour l’analyse du trafic). Il l’a aussi intégré dans CloudWatch (composante Network Flow Monitor) et de GuardDuty (EC2 Runtime Monitoring). Microsoft l’exploite pour contourner Iptables sur les data planes de offre AKS (Azure Kubernetes Services).
Pour le monitoring, Dynatrace a choisi de s’appuyer sur Inspektor Gadget, framework CNCF qui encapsule les programmes eBPF sous forme d’images OCI. Il le met à contribution dans un module de découverte de services.
Chez Elastic, eBPF alimente le profilage continu, ainsi que la protection de Linux et de Kubernetes dans le cadre de l’offre SIEM/XDR.
Illustration principale © kwanchaift – Adobe Stock
The post Observabilité : eBPF, un atout dans la main des DevOps appeared first on Silicon.fr.
Alors là, on touche au sublime les amis ! Parce que si vous pensiez avoir tout vu en matière de boot insolite, genre clé USB, PXE, disquette 5 pouces 1/4... Pffff, vous n'êtes qu'une bande de petits joueurs.
Jozef Bogin, ce bidouilleur de génie , que dis-je, ce GOAT, a réussi à faire booter un IBM PC (le modèle 5150, une légende !!) directement depuis... un disque vinyle. Oui, un bon vieux 45 tours.
Regardez-moi ça comme c'est beau :
Pour réussir ce tour de force, il a gravé une image disque de 64 Ko (contenant un noyau FreeDOS minimal) sous forme de signal audio analogique sur le disque. Grâce à une ROM personnalisée (une puce 2364 insérée dans le socket d'extension du BIOS) qui remplace le code de boot habituel, le PC récupère le son via son interface cassette. Les routines du BIOS se chargent ensuite de la démodulation du signal pour charger le tout en RAM. C'est un peu comme émuler une disquette avec une clé USB , mais en version hardcore analogique.
Techniquement, c'est un boulot de dingue. Il a dû adapter l'égalisation audio pour compenser la courbe RIAA du vinyle, gérer les niveaux au millimètre et coder ce fameux bootloader spécifique pour que la magie opère.
Perso, je trouve ça assez poétique et le son n'est pas sans rappeler celui de nos bons vieux modem 56k. Bref, si vous avez une platine et un PC IBM 5150 qui traînent, vous savez ce qu'il vous reste à faire.
Pour les autres, la vidéo suffira largement ^^.
Connexion