Aujourd'hui, on va aller un peu plus loin que les simples bidouilles habituelles car je vais vous présenter Reinstall, un outil qui va peut-être vous changer la vie si vous gérez des serveurs distants.
Vous connaissez la chanson... vous avez un VPS sous Debian et vous voulez passer sous Arch pour faire votre malin. Sauf que pour opérer ce changement, c'est la galère assurée !! Faut passer par l'interface web de l'hébergeur, booter sur une ISO via une console VNC qui rame sa maman, et prier pour que le réseau revienne après le reboot.
Eh bien ça c'est terminé grâce à ce script Reinstall. Vous lui balancez une commande, le script s'occupe de tout, et hop, votre serveur redémarre sur le nouvel OS de votre choix. Pas besoin d'accès IPMI, pas besoin de supplier le support technique, ça marche tout seul.
Et ça supporte pas mal d'OS... Côté Linux, y'a 19 distributions majeures : Alpine, Debian (de 9 à 13), Ubuntu (de 16.04 à 25.10), toute la famille Red Hat (AlmaLinux, Rocky, Oracle), Fedora, Arch, Gentoo, NixOS... Bref, y'a tout ce qu'il faut.
Et le truc qui va plaire à ceux qui font du cloud, c'est également le support de Windows. En effet, le script permet d'installer Windows Vista, 7, 8.1, 10, 11 et même Windows Server 2025.
Et rassurez-vous, il n'utilise pas des images bricolées par on ne sait qui, mais les ISO officielles de chez Microsoft. Lui se content d'injecter automatiquement les drivers VirtIO pour que ça tourne comme un charme sur n'importe quel cloud (AWS, GCP, Oracle Cloud...).
Aussi, le point le plus chiant quand on réinstalle un serveur distant, c'est la config réseau. Si on se loupe, on perd l'accès SSH et c'est fini. Reinstall gère ça intelligemment puisqu'il détecte votre IP (statique ou dynamique), gère l'IPv6, les passerelles exotiques et même les serveurs ARM.
Ce qu'il vous faut avant de tout casser
RAM : 256 Mo pour Alpine/Debian, 1 Go pour Windows.
Disque : 1 Go pour Linux, 25 Go minimum pour Windows.
Accès : Un accès root/admin sur la machine actuelle.
Temps estimé : Environ 5 à 15 minutes selon la vitesse de connexion de votre serveur.
Un petit avertissement quand même... Ce script ne gère pas les conteneurs type OpenVZ ou LXC. Faut que ce soit une vraie VM (KVM, VMware, Hyper-V) ou un serveur bare-metal.
Le tuto ! Le tuto !
C'est là que ça devient drôle. Pour installer un nouveau Linux (disons Debian 13) depuis votre système actuel, il suffit de faire un petit :
# Télécharger le script
curl -O https://raw.githubusercontent.com/bin456789/reinstall/main/reinstall.sh
# Lancer la réinstallation
bash reinstall.sh debian 13 --password "VotreMotDePasse"
Le script tourne même depuis Windows (via un .bat) si vous voulez faire l'inverse et repasser sous Linux.
Perso, je trouve ça quand même génial pour tester des trucs sans passer des plombes à configurer des ISO. Ça dépanne grave quand on veut repartir on une base saine en un clin d'œil. D'ailleurs, si vous avez besoin de sécuriser vos serveurs après l'install, j'avais parlé de
Fail2Ban
il y a quelques temps, et c'est toujours une bonne idée. Et si vous avez peur de perdre vos données, jetez un œil à
Restic
pour vos backups.
Bref, si vous gérez des VPS et que vous en avez marre des consoles web préhistoriques, foncez tester ce truc (sur une machine de test d'abord, hein, venez pas pleurer après).
Bon, je vous laisse… Je vais aller me faire un petit café !
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…
Liste de contrôle d’accès NT. Issu de la documentation de CFEngine 1.6, sorti en 2000.
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.
Architecture simplifiée de Puppet telle que présentée en 2010.
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.
Template CloudFormation créant une instance EC2. Exemple donné début 2011, quelques semaines après le lancement du service.Exemple de configuration Terraform que HashiCorp donnait en 2014, peu après le lancement du produit.Playbook Ansible donné en référence en 2015, juste avant que la start-up se vende à Red Hat.
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.
La recette IaC déclinée sur l’observabilité…
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é.
… avec un bouquet d’abstractions
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.
Des stacks open source aux plates-formes d’observabilité
À 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).
Accepter la codebase comme « source de vérité »
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 ».
Dans cet article, l'ingénieur Alberto Donini présente une méthode innovante, la « méthode d'érosion relative » (MER), qu'il a mise au point pour déterminer la date de construction de structures anciennes.
Il applique cette méthode à la pyramide de Khéops sur le plateau de Gizeh. Est-il possible que la datation archéologique actuelle de ce monument égyptien antique soit incorrecte ?
Est-il également possible que les dates alternatives proposées par divers chercheurs soient tout aussi incorrectes ? Pour répondre à ces questions, l'auteur analyse la pyramide de Khéops sous un angle non conventionnel afin de déterminer la période la plus probable de sa construction.
La REM est basée sur le rapport entre deux types d'érosion affectant le même type de roche au même endroit : l'un avec une date connue et l'autre avec une date à déterminer. Ce rapport est ensuite utilisé pour calculer l'âge du bloc de pierre examiné.
Ces conclusions sont préliminaires et feront l'objet d'études plus approfondies grâce à des mesures supplémentaires, étendues à toutes les structures et bâtiments du plateau de Gizeh. Il est toujours possible d'améliorer la précision des mesures, la détermination des volumes érodés et la précision globale des résultats.
Alberto Donini a l'intention de poursuivre ses recherches et invite les archéologues du monde entier à collaborer à de futures études.
La REM n'a pas pour but de déterminer une date de construction précise pour un bâtiment ancien, mais plutôt d'identifier un intervalle temporel et de lui attribuer une probabilité. Bien que les fourchettes de dates obtenues soient larges, les conclusions indiquent une faible probabilité pour la datation archéologique officielle de 2 560 avant J.-C.
Pour ces raisons, il est probable que les pyramides d'Akhet Khufu (G1) remontent à environ 23 000 avant J.-C. Il est donc plausible que le pharaon Khéops ait simplement rénové la pyramide de Khufu, s'attribuant la paternité de celle-ci.
Sur la base de ce rapport préliminaire sur les mesures d'érosion relative (MER) effectuées sur la pyramide de Khéops, on peut conclure qu'il existait en Égypte, environ 20 000 ans avant Jésus-Christ, une civilisation capable de construire au moins la pyramide de Khéops (G1).
La grande pyramide de Gizeh, ou pyramide de Khéops, serait-elle plus ancienne qu'on ne le pense ? Une nouvelle étude de l'Université de Bologne, publiée jeudi 29 janvier, vient relancer le débat. L'ingénieur italien Alberto Donini y remet en question la datation qui situe sa construction vers 2 560 avant notre ère, sous le règne du pharaon Khéops. Il estime que l'érosion visible à la base du monument pourrait indiquer une origine antérieure, qui remonterait "possiblement jusqu'à la fin du Paléolithique".
L'usure observée dans certains recoins correspondrait à plus de 5 700 ans d'exposition, mais d'autres points indiqueraient plus de 20 000 ans, et parfois plus de 40 000 ans, avec une moyenne "autour de 22 900 avant notre ère".
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.
Cilium, une couche d’abstraction devenue référente
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 frameworkBPF 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.
Et vint l’observabilité
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.
S’économiser l’instrumentation… dans certains cas
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.
Des programmes composables et portables
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.
Ce programme eBPF basique (codé en C) écrit un message dans le noyau.
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.
Une fondation où convergent les Big Tech
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.
Architecture cible d’eBPF pour Windows
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.
Bon, faut qu’on cause ! Il existe aujourd’hui beaucoup de distributions d’inspiration ou conçues depuis le début sur ce qu’on appelle l’immuabilité (on est en France, on parle français, Rognotudju !). Découvrons Talos, cette nouvelle distribution dédiée au déploiement et à la gestion de clusters Kubernetes … L’immuabilité est le terme à la mode depuis […]
Avec la carte Raspberry Pi AI HAT+ 2, la Fondation Raspberry Pi introduit une carte HAT+ intégrant l’accélérateur Hailo-10H et 8 Go de mémoire dédiée, conçue exclusivement pour le Raspberry Pi 5. Connectée en PCIe Gen 3, elle vise l’exécution locale de modèles d’IA sans dépendre du cloud. Dans ce premier article, je vous présente […]
An important update to Google Maps has started to be rolled out by Google with the goal of enhancing overall usability and simplifying navigation on iOS and Android smartphones. These modifications show Google’s continued focus on improving the Maps experience, especially through interface design and more user-friendly instructions, even though the company still keeps Waze as a supplementary navigation option. Version 25.49 of Google Maps brings a revamped settings menu […]
En philosophie de l'esprit, en neurosciences et en psychologie, la relation causale entre la conscience phénoménale, la pensée et les états cérébraux a toujours fait l'objet de débats. D'une part, le monisme matériel considère la conscience et l'esprit comme de purs épiphénomènes cérébraux.
L'un de ses raisonnements les plus rigoureux repose sur le « principe de la lésion avec perte de fonction », selon lequel, étant donné que les lésions cérébrales et les modifications neurochimiques entraînent des troubles cognitifs et/ou des états de conscience altérés, il n'y a aucune raison de douter de l'identité entre l'esprit et le cerveau.
D'autre part, le dualisme ou l'idéalisme (sous une forme ou une autre) considèrent la conscience et l'esprit comme autre chose que le seul produit de l'activité cérébrale, soulignant la nature ineffable, indéfinissable et apparemment non physique de nos expériences qualitatives subjectives et de leur dimension mentale.
Nous passons ici en revue plusieurs découvertes neuroscientifiques qui remettent en question l'idée selon laquelle l'expérience phénoménale serait une propriété émergente de l'activité cérébrale, et qui soutiennent que la prémisse du monisme matériel repose sur un sophisme logique de corrélation-causalité.
Si ces découvertes (pour la plupart ignorées), considérées séparément, pourraient en principe être reformulées dans un paradigme physicaliste, elles corroborent tout aussi bien, lorsqu'elles sont considérées dans une perspective intégrale, une ontologie qui postule que l'esprit et la conscience sont des phénomènes primaires.
HP came to CES to with the HyperX OMEN Max 16, claiming it is the world’s most powerful 16-inch gaming laptop with a fully internal cooling system. According to HP, the system is engineered to deliver up to 300W of sustained total platform power in Intel-based configurations, enabled by a 460W gallium nitride power adapter. The emphasis during the briefing was clear: this is not a thin-and-light performance spike machine, […]
Connexion
