Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.

KULA - Le monitoring serveur Linux qui tient dans un seul binaire

Ouais, je sais, on est le 1er mai, et je suis pas censé bosser mais que voulez-vous on ne se refait pas ^^. Et si j'ai ouvert l'ordi ce matin, c'est pour vous parler de KULA !

KULA est un binaire tout simple qui permet de monitorer très facilement votre serveur Linux en temps réel, sans aucune dépendance. c0m4r , le dev derrière le projet, l'a codé en Go avec une obsession claire : Que ça marche partout sans rien installer à côté !

C'est vrai que les outils de monitoring temps réel sur Linux ont tendance à grossir avec le temps. Netdata est passé par exemple d'un script léger à une plateforme SaaS.

KULA veut faire exactement l'inverse ! Parce que si vous avez un VPS à 5 balles, un Raspberry Pi ou trois homelabs qui ronronnent dans le placard, c'est pas la peine de sortir un bazooka quand il y a ce petit binaire qui fait tout aussi bien.

Vous le posez sur la machine, vous lancez ./kula, et c'est plié ! Il y a même un installeur guidé en une commande (nia nia nia lisez le contenu du .sh avant de le lancer, nia nia nia, je me répète, je sais):

bash -c "$(curl -fsSL https://raw.githubusercontent.com/c0m4r/kula/refs/heads/main/addons/install.sh)"

Côté technique, le projet va chercher ses infos directement dans /proc et /sys toutes les secondes. Comme ça y'a pas besoin d'un programme "agent" séparé à installer, ni besoin de vous lancer dans du scraping HTTP. C'est juste KULA qui tourne en daemon et qui lit ce qui se passe au niveau du kernel.

Les données passent ensuite dans un moteur de stockage maison : un ring-buffer avec trois niveaux (1 seconde brut, 1 minute agrégé, 5 minutes agrégé), chacun ayant une taille max fixe (250 Mo, 150 Mo, 50 Mo par défaut). Et quand la limite est atteinte, les nouvelles données écrasent les vieilles. Comme ça l'usage disque est maîtrisé, et y'a pas besoin de faire de ménage.

Niveau métriques, c'est plutôt complet je trouve... CPU, GPU (VRAM, charge, conso), mémoire, swap, load average, processus par état, températures CPU/GPU/disque, batteries, entropie système, sync horloge. Le réseau remonte les débits par interface, les paquets par seconde, les erreurs, les drops, les retransmissions TCP, les connexions établies...etc.

Et côté disque c'est par composant : IOPS, lectures/écritures par seconde, octets/s, plus l'usage des systèmes de fichiers. Et bien sûr tout ce qui est containers Docker, podman, et même ces cgroups bruts dont vous êtes si fiers ^^, pour ceux qui font tourner des trucs sans Docker.

Et le truc auquel je ne m'attendais pas mais que j'aurais pu anticiper parce que c'est à la modeuuuuh, c'est l'assistant IA via Ollama. Vous configurez une instance Ollama locale, et le dashboard vous laisse causer à un modèle de votre choix qui peut analyser les courbes en cours, exporter du CSV par graphique, et même faire appel à une fonction get_metrics pour interroger les données en mode agent.

Tout ça en local bien sûr. C'est plutôt sympa pour debugger par exemple un pic de CPU récurrent à 3h du matin sans devoir vous taper des heures de graphes !

Le déploiement Docker c'est comme ça :

docker run -d --name kula --pid host --network host
 -v /proc:/proc:ro -v kula_data:/app/data c0m4r/kula:latest

Notez le paramètre --pid host et /proc:/proc:ro : car KULA a besoin de voir l'hôte et pas le container.

Bah ouais, c'est logique, sinon il va monitorer juste son propre container, ce qui n'a aucun intérêt, hein...

Notez que si vous êtes sur un VPS LXC mutualisé bas de gamme, certains hébergeurs restreignent l'accès à /proc du host... et là, malheureusement, KULA ne pourra remonter que ce qu'il voit ce qui est souvent pas grand-chose... sniiif.

Pour les puristes, y'a aussi des paquets .deb, .rpm, AUR pour Arch, et du multi-arch (amd64, ARM, RISC-V). Ça couvre à peu près tout ce qui se croise sur un homelab !

Et côté auth, c'est désactivé par défaut (le port par défaut est le 27960, pas le 80), mais quand vous l'activerez vous tomberez sur de l'Argon2id avec des jetons de session hashés en base.

Par contre, même si y'a quelques alertes internes (clock sync, low entropy, overload), vous n'aurez pas de notifications natives (pas de mail, ni Slack, ni webhook...etc). Et pas de support multi-node non plus puisque KULA monitore une machine à la fois.

Donc si vous avez 30 serveurs, faudra vous farcir 30 instances et 30 dashboards séparés. Pas glop ! Et bien sûr, c'est Linux only parce que tout repose sur /proc et /sys.

C'est encore un projet un peu jeune, donc à voir comment ça vieillit mais pour votre petit VPS perso d'amour ou une machine dans un setup d'auto-hébergement , c'est top pour esquiver à la fois htop qui est trop minimaliste et Grafana qui est trop usine à gaz.

Si vous voulez voir la démo, y'en a une ici : demo.kula.ovh !

Source

A Mouse You Can Squeeze Like a Stress Ball While You Work

The computer mouse hasn’t changed much in decades. Still mostly hard plastic, still shaped like a bar of soap, still asking your hand to grip something that gives absolutely nothing back. The rest of the desk setup has evolved, ergonomic chairs, standing desks, wrist rests, but the one device your hand touches for eight hours straight has remained stubbornly rigid and deeply uninteresting.

The PILLIGA mouse concept makes a fairly obvious argument for why that should change. Instead of hard plastic, the entire upper chassis is a squishy, flexible membrane packed with a viscous, translucent gel. It’s the same basic impulse that makes people reach for a stress ball mid-meeting, except it’s also the thing you need to get any work done.

Designer: Guillermo Gonzalez

The thinking behind it is straightforward enough. Deadline pressure builds, calls run long, and the urge to fidget becomes almost impossible to ignore. Rather than keeping a stress ball in the desk drawer as a separate ritual, the mouse folds that habit directly into the tool that’s already in your hand. You can squeeze, press, or knead the gel without ever lifting your hand off your workflow.

The dome shape isn’t just for show, either. It follows the natural arch of your palm rather than forcing your hand flat against a hard surface, and the gel underneath absorbs the kind of low-level muscular strain that builds up quietly over hours of clicking and scrolling. It’s the sort of ergonomic consideration that usually requires its own dedicated accessory, not just a different material.

The controls themselves are sensibly laid out. A flat circular interface sits embedded in the front of the mouse, cleanly split for left and right clicks, with a textured, rubberized scroll wheel running between them. A USB-C port at the front handles charging, keeping the wireless design intact without the inconvenience of a separate charging dock. The bottom carries the optical sensor and power switch.

What makes the PILLIGA mouse concept genuinely interesting is how far it extends color as a design element. The gel comes in several variants, from vivid green with gold flecks and a blue version scattered with purple glitter, to darker, more subdued options that look considerably more at home on a professional desk. Each colorway pairs with a matching base and click interface, making the whole thing feel deliberate.

That range matters. The more reserved colorways hint that this isn’t a novelty item for a niche corner of the internet; it works just as comfortably on a professional desk as it does on a creative’s workstation. The gel doesn’t make it look cheap. It makes it look like something designed by someone who gave serious thought to what a mouse should feel like.

Concepts like the PILLIGA are more useful as provocations than promises. Computer mouse design has been coasting on the same assumptions for decades, and the idea that your primary input device could also be physically satisfying to hold hasn’t come up often enough. The gel-filled body raises the question, and that’s honestly more than most peripheral design manages to do.

The post A Mouse You Can Squeeze Like a Stress Ball While You Work first appeared on Yanko Design.

The LEGO Metal Slug Diorama With Adjustable Cannons, POWs, and Mid-Air Grenades Is Here

By 1996, the arcade was dying. Virtua Fighter and Tekken had the crowds. Sega’s racing cabinets had the spectacle. The conventional wisdom was that 2D games were finished, and anyone still making pixel art sidescrollers was simply behind the curve. Then Nazca Corporation released Metal Slug on SNK’s Neo Geo hardware, and the conventional wisdom had to sit quietly in a corner for a while. The game’s hand-animated sprites moved with a fluidity that polygon games couldn’t touch, and the humor, panicking soldiers, grateful POWs tossing rocket launchers, a tank that waddled like a toy, made the whole thing feel alive in a way that pure technical showmanship never quite manages.

LEGO Ideas builder MagicBrick has captured a freeze-frame of that world in brick form, reconstructing the game’s iconic jungle mission with 2,701 pieces and 6 minifigures locked into a scene of swamp terrain, rebel soldiers, dense jungle vegetation, and the squat, waddling Super Vehicle-001 tank at the center of it all. It’s a dense, affectionate build made by someone who clearly lost many, many credits to this game, and it shows in every deliberately chosen detail, from the mid-jump Marco Rossi clutching a Heavy Machine Gun to the bearded POW standing by with a reward.

Designer: MagicBrick

The scene is structured like a freeze-frame from the game itself, which is exactly the right instinct. MagicBrick describes the goal as capturing “a dynamic instant where everything is in motion: jumps, actions, and interactions come together to recreate the fast-paced feeling typical of the game,” and the build delivers on that. Marco Rossi in his red jacket is airborne, Heavy Machine Gun in hand. Tarma Roving, yellow jacket, stands ready with a pistol and knife. Three Rebel Army soldiers in green uniforms and helmets fill out the opposition, armed with bazookas and rifles. The swamp base uses tiles in multiple shades to sell the terrain, jungle trees and palms crowd the background, and the brick-built backdrop reflects the arcade color palette of the original game rather than any attempt at realism. That last decision is a smart one. Metal Slug was never interested in realism, and neither is this.

The Super Vehicle-001 is the centerpiece, and MagicBrick has packed a surprising amount of function into a compact footprint. The rear cannons are adjustable, the tracks are functional, and antennas complete the silhouette. Scattered across the scene are the environmental details that will hit Metal Slug veterans like a reflex: ammo crates, yellow barrels, a hanging fish skeleton, a parachute, and both the Heavy Machine Gun and Rocket Launcher power-up pickups rendered in brick. My favorite touch, though, is the grenade sequence, a classic cartoon-logic arc of thrown grenades ending in a mid-air explosion, frozen in plastic at exactly the right moment of absurdity.

Topping the whole structure is the Metal Slug logo itself, rendered in a red-to-orange gradient that makes the build read as a display piece as much as a playset. It’s that combination of environmental storytelling, playable features, and genuine fan knowledge that separates builds like this from generic video game tributes.

LEGO Ideas is the platform where fan-designed MOCs (My Own Creations) gather community votes, with 10,000 supporters needed to trigger an official LEGO review and potential production as a retail set. MagicBrick’s Metal Slug submission hit 100 supporters almost immediately after going live and has been picking up Reddit traction since. If you grew up feeding tokens into a Neo Geo cabinet, head to the LEGO Ideas page and cast your vote here.

The post The LEGO Metal Slug Diorama With Adjustable Cannons, POWs, and Mid-Air Grenades Is Here first appeared on Yanko Design.

Piratage : Google, Cloudflare et Cisco contraints de bloquer des sites pirates en France

La cour d'appel de Paris vient de confirmer que les fournisseurs de DNS alternatifs doivent bloquer l'accès aux sites de streaming et d'IPTV pirates. Google, Cloudflare et Cisco ont perdu leur appel face à Canal+.

Cinq appels rejetés d'un coup

La cour d'appel de Paris a tranché cinq affaires distinctes dans lesquelles Canal+ demandait à Google (Google Public DNS), Cloudflare (1.1.1.1) et Cisco (OpenDNS) de bloquer des centaines de noms de domaine liés à du streaming illégal. Les trois entreprises avaient fait appel des ordonnances rendues en première instance par le tribunal judiciaire de Paris.

C'est la première fois qu'une cour d'appel française valide ce type de blocage DNS en s'appuyant sur l'article L.333-10 du Code du sport, qui permet aux détenteurs de droits d'exiger le blocage de domaines en cas de piratage grave et répété.

Les arguments qui n'ont pas fonctionné

Cloudflare et Cisco avaient plaidé que leurs services avaient une fonction "neutre et passive", comparable à un annuaire qui traduit des noms de domaine en adresses IP. La cour a estimé que cette neutralité était tout simplement hors sujet : ce qui compte, c'est la capacité technique à bloquer un accès, pas la nature du service.

Google a tenté un autre angle en expliquant que le blocage DNS était inefficace puisqu'il suffit d'un VPN pour le contourner. La cour a balayé l'argument en rappelant que tout système de filtrage peut être contourné, et que ça ne le rend pas inutile pour autant.

Cisco avait aussi chiffré le coût de mise en place à 64 semaines-personne de travail. Pas suffisant non plus pour convaincre les juges.

Canal+ continue de pousser

Cette décision s'ajoute à celle obtenue contre les fournisseurs de VPN fin 2025, quand NordVPN, ExpressVPN et d'autres avaient eux aussi été contraints de bloquer des sites pirates en France.

Canal+ verrouille progressivement tous les moyens de contournement. Et la chaîne ne compte visiblement pas s'arrêter là : le blocage d'adresses IP serait déjà en test, avec un premier essai lors de Roland-Garros.

Les frais de mise en place sont à la charge de Google, Cloudflare et Cisco.

Canal+ est en train de poser des briques une par une. D'abord les FAI, puis les VPN, maintenant les DNS. On imagine bien que le blocage IP est la prochaine étape.

Côté efficacité, ça reste un jeu du chat et de la souris, mais la justice française envoie un signal clair : si un service technique peut aider à bloquer du piratage, il devra le faire. Et à ses frais, en plus.

Source : Torrent Freak

❌