Google Maps a discrètement mis en place un affichage limité pour les personnes non connectées, privant les utilisateurs d’une partie importante des informations disponibles sur la plateforme. Le changement a été repéré depuis peu par des utilisateurs sur Reddit, sans qu’aucune annonce officielle n’ait été faite par Google. …
Aimez KultureGeek sur Facebook, et suivez-nous sur Twitter
N'oubliez pas de télécharger notre Application gratuite iAddict pour iPhone et iPad (lien App Store)
L’article Google Maps retire plusieurs fonctions pour les utilisateurs non connectés est apparu en premier sur KultureGeek.
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.
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.
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 :
Connexion# 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"
Si vous voulez tenter l'aventure Windows :
bash reinstall.sh windows --image-name "Windows 11 Enterprise LTSC 2024" --lang fr-fr
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é !
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.
J'étais passé à côté ! Je peux enfin installer ByPass Paywalls Clean sur Firefox mobile. Je suis joie !
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.
