C'est la Software Freedom Conservancy (SFC), l'ONG américaine qui défend les licences libres, qui a sorti l'affaire. Bambu Lab, l'un des plus gros fabricants d'imprimantes 3D grand public du moment, viole l'AGPLv3 depuis environ quatre ans selon l'organisation. Pas qu'un peu donc.

Pour comprendre l'histoire, il faut savoir que Bambu Studio, le slicer maison de la marque (c'est le logiciel qui transforme un modèle 3D en instructions de découpage pour l'imprimante), est en réalité un dérivé de PrusaSlicer, lui-même basé sur Slic3r.

Les deux sont sous licence AGPLv3, ce qui oblige toute boîte qui distribue un logiciel dérivé à publier son code source dans la même licence. Du coup, Bambu Studio aurait dû suivre les mêmes règles depuis le début.

Sauf que voilà, le SFC pointe deux violations très claires. D'abord, une bibliothèque maison appelée libbambu_networking, qui gère toute la communication entre le slicer et les serveurs cloud de Bambu, n'a jamais vu son code publié. La marque reconnaît même son existence dans son propre README sur GitHub. Pire encore, quand le développeur Paweł Jarczak a sorti une version modifiée d'OrcaSlicer (un fork concurrent, c'est-à-dire une copie communautaire améliorée) qui restaurait certaines fonctions cloud bloquées par Bambu, l'entreprise lui a envoyé une mise en demeure pour faire retirer son projet.

C'est la deuxième violation selon le SFC, parce que l'AGPLv3 interdit explicitement d'ajouter des restrictions supplémentaires à ce que la licence autorise. En clair, Bambu n'a pas le droit d'invoquer ses conditions d'utilisation pour empêcher quelqu'un d'exercer les droits que la licence donne. 

Côté riposte, le SFC a lancé un projet baptisé baltobu. Trois objectifs : refaire la fameuse bibliothèque à partir de zéro par reverse-engineering (démonter le code propriétaire pour le réécrire proprement), maintenir le fork OrcaSlicer de Jarczak, et créer un remplaçant complet de Bambu Studio. Une levée de fonds visant 250 007 dollars, ouverte jusqu'au 17 juillet, a déjà atteint son premier objectif pour financer des employés à ce travail sur le long terme. Si la cagnotte va au bout, de nouveaux employés pourront rejoindre le projet.

Bambu Lab a réagi du bout des lèvres. L'entreprise a publié un message reconnaissant que sa référence à des conditions d'utilisation et à une potentielle mise en demeure ait pu être perçue comme une menace légale, ce qu'elle regrette. Pas de modification réelle de la pratique pour autant. La bibliothèque reste fermée, et les pratiques cloud restent les mêmes.

Bref, une marque grand public qui surfe sur les briques open source sans en respecter les règles, ça finit toujours par se voir.

Source : Itsfoss

Y'a des entreprises qui claquent des millions pour bien aligner leurs modèles d'IA afin qu'ils refusent toutes les questions sensibles qui font flipper nos amis puritains d'outre-Atlantique et y'a Heretic , un outil signé Philipp Emanuel Weidmann, qui balaye toute censure sur n'importe quel modèle en moins de 30 minutes avec une simple carte graphique de gamer.

Je vous explique... Vous devez avoir Python et une version récente de PyTorch sur votre machine, puis vous tapez pip install heretic-llm, puis heretic Qwen/Qwen3-4B-Instruct-2507 avec le nom du modèle que vous voulez décensurer.

Et l'outil fait alors sa vie et 20 à 30 minutes plus tard, vous récupérez une version du modèle qui a lâché prise sur l'essentiel de ses refus. Pas de dataset à préparer et surtout pas besoin de comprendre les entrailles d'un transformer, avec ce truc !

Dans un modèle aligné, le réflexe de refuser (le fameux "désolé, je ne peux pas vous aider avec ça") correspond souvent à une direction précise dans ses calculs internes. Les chercheurs appellent ça la "direction de refus". Et l'idée de l'abliteration, c'est de repérer cette direction et de la gommer des poids du modèle. En gros, on coupe le câble qui déclenche le "non", en touchant le moins possible au reste.

D'autres outils d'abliteration existaient déjà , mais leur réglage restait largement manuel et il y a aussi des gens comme mlabonne ou huihui-ai qui publient des modèles décensurés en ajustant les paramètres à la main, modèle par modèle, avec des résultats souvent inégaux. Mais Heretic, lui, automatise complètement le réglage. Pour cela, il s'appuie sur Optuna, un framework d'optimisation qui teste des dizaines de configurations et garde les meilleures tout seul. Et son seul objectif c'est de virer un max de refus tout en abîmant le moins possible le modèle d'origine.

Et de ce que je comprends, ça marche super bien ! Sur Gemma-3-12B, le modèle de Google de base refuse 97 fois sur 100 les prompts sensibles du benchmark maison. Mais après un petit passage dans Heretic, il tombe à 3 refus sur 100, soit le même niveau que les meilleures "nettoyages" manuels.

Et surtout, Heretic affiche une divergence de 0,16 là où les versions faites main grimpent à 0,45 voire 1,04 (C'est une mesure de l'écart de comportement sur les questions normales... plus c'est bas, mieux c'est).

Cela veut donc dire qu'il abîme beaucoup moins le modèle au passage.

Maintenant, tous les modèles n'y passent pas, car un gros calibre demande bien plus de VRAM et cela peut grimper à plusieurs heures. De plus, une étude comparative récente montre que le raisonnement mathématique est ce qui souffre le plus de ce genre d'abliteration, quel que soit l'outil utilisé.

Et surtout, y'a déjà des chercheurs qui bossent sur des défenses pour rendre les modèles résistants à ce genre d'attaque. Donc on verra bien, mais tant que c'est possible autant en profiter car des modèles sans bridage, ça permet notamment à des chercheurs d'étudier leurs propres failles, ou pour des usages du quotidien, de faire passer des demandes banales qui seraient bloquées (genre texte créatif, reverse engineering ou demande de conseils médicaux, ce genre de choses...)

Voilà, si vous bidouillez du LLM en local , allez voir ce projet car ça peut vous "ouvrir" quelques portes ^^.

Google’s $3 ChromeOS Flex kit sold out. Here are five lightweight operating system alternatives for older Windows 10 PCs.

The post ChromeOS Flex Kit Is Sold Out: 5 Alternatives for Old Windows 10 PCs appeared first on TechRepublic.

Plus de 4 000 commits, 5 ans de décompilation acharnée, et selon l'équipe ZeldaRET le plus gros projet de reverse-engineering jamais bouclé sur un jeu Nintendo. Voilà tout ce qu'il a fallu à la team Twilit Realm pour livrer Dusk, leur portage natif de Zelda Twilight Princess sur Windows, macOS, Linux, iOS et même Android.

La sortie officielle a eu lieu samedi dernier, et le projet fait son petit effet dans la communauté retrogaming.

Link traverse les plateformes dans Dusk (capture du site officiel )

Pour faire fonctionner le jeu, vous devez récupérer le binaire Dusk sur GitHub , puis lui fournir votre propre dump du jeu GameCube car la team ne distribue aucun asset de Nintendo pour limiter le risque juridique... Après je vous fais confiance pour en trouver tombé du camion... ^^.

Et hop, en moins de temps qu'il n'en faut pour le dire, vous vous retrouvez à jouer à Twilight Princess sur votre Steam Deck, votre iPhone, votre laptop M3, votre tour Linux ARM64, peu importe... Tout ça sans émulateur Dolphin puisque le code GameCube a été reverse-engineered au niveau machine puis recompilé pour le matériel moderne, ce qui donne un vrai portage natif avec les avantages habituels : framerate déverrouillé, résolutions HD, modding facilité, performances qui dépotent (sous réserve d'un GPU compatible D3D12, Vulkan ou Metal, les vieux iGPU Intel et certains Adreno galèrent encore).

Le moteur du jeu original tournait à 30 refresh par seconde (en anglais on dit "ticks", c'est le nombre de fois où le moteur rafraîchit / recalcule la 3D du jeu) , c'est-à-dire que la simulation du monde se mettait à jour 30 fois par seconde, point final. La team a gardé ce taux à l'identique pour préserver le comportement de simulation proche de l'original, ce qui rassure surtout les speedrunners.

Sauf que maintenant, le rendu visuel, lui, peut tourner à 144 Hz ou plus. Donc entre deux refresh, Dusk calcule où devraient se trouver les objets et interpole leur position pour produire une image fluide. Vous gardez ainsi la mécanique de 2006, mais l'affichage est de 2026, donc c'est spleennnndiiiiide ! C'est une approche comparable à celle de Ship of Harkinian sur Ocarina of Time.

Côté plateformes, c'est pour Windows x86-64, macOS Intel et Apple Silicon, Linux x86-64 et ARM64, iOS via AltStore et Android en APK direct. Pas de version Switch par contre, et n'ayez pas d'espoir car l'équipe a été claire sur le sujet. Pour des raisons techniques (et j'imagine juridiques) ils n'envisagent pas de port natif sur la console actuelle. Les versions Wii et les autres régions GameCube sont également en chantier, mais pour l'instant ce sont les versions GameCube USA et EUR qui sont supportées. Le projet vérifie même le hash SHA-1 de votre dump pour s'assurer qu'il correspond à une version compatible avant de lancer quoi que ce soit.

Link en wolf enchaîné dans le donjon initial (capture du site officiel )

L'ensemble est sous licence CC0, domaine public, zéro restriction, ce qui veut dire que vous pouvez forker, modifier, redistribuer le code sans contrainte. Le projet repose sur la décompilation zeldaret/tp , menée depuis août 2020 par une communauté internationale de speedrunners et de devs reverse-engineers.

C'est le même schéma juridique qui a permis à Zelda 64 Recompilé de prospérer. Les projets évitent de distribuer des assets Nintendo, mais ça ne supprime pas tout risque de notification DMCA puisque la légalité dépend aussi de votre juridiction et de la manière dont le dump a été obtenu (DMCA section 1201 aux US, qui interdit en principe le contournement de protection, donc la prudence reste de mise).

Maintenant, faut pas se voiler la face sur le destinataire d'une lettre recommandée potentielle puisque Nintendo a fait sauter yuzu et son fork Suyu en 2024 avec 2,4 millions de dollars de règlement à la clé, Ryujinx a mis la clé sous la porte en octobre dernier sous pression directe, Garry's Mod a dû purger 20 années de contenu Nintendo de son workshop, et la société attaque actuellement Palworld sur des brevets de gameplay déposés à la va-vite.

Donc même quand un projet respecte le droit à la lettre, la firme japonaise a les moyens de noyer une équipe bénévole sous des frais d'avocats jusqu'à épuisement total. Les ports type Ship of Harkinian tiennent depuis plusieurs années déjà sans procédure, mais rien ne garantit que Dusk passera entre les gouttes. Si vous voulez profiter du jeu sur PC, je vous conseille donc de cloner le repo en local et de mettre le binaire de côté quelque part, on ne sait jamais....

Link récupère un fragment de coeur (capture du site officiel )

Pour l'installation, vous filez sur le repo GitHub, vous chopez le binaire de votre plateforme, vous pointez le launcher vers votre dump GameCube (que vous avez fait vous-même depuis une Wii moddée en suivant le guide du wiki Dolphin, hein...), et c'est parti mon kiki.

Merci à j0j0b4rj0 pour la découverte.

The open-source community has a long history of doing more with abandoned hardware than the original manufacturers ever did. The PSP got emulators Sony never approved. The Wii got homebrew loaders that ran software Nintendo pretended didn’t exist. The pattern repeats because the hardware is always fine; it’s the corporate support structure around it that evaporates. The Spotify Car Thing joined that lineage in December 2024 when Spotify killed server-side authentication and turned every unit into an expensive knob with a screen attached.

Nocturne picked up where Spotify dropped off. The project launched in October 2024, anticipating the shutdown, and has shipped four major versions since. V4.0.0, currently in beta with a public release imminent, finally delivers true Bluetooth connectivity without phone tethering, a companion app, and a feature set that makes the original Spotify firmware look like a rough draft.

Developer: Nocturne Team (Brandon Saldan, Dominic Frye, and contributors)

The Car Thing runs a 512MB RAM, 4GB storage Amlogic S905D2 SoC, which is a polite way of saying it has the processing power of a mid-range router from 2015. Early versions of Nocturne required a Raspberry Pi as a co-processor just to get the thing online, which was a heroic workaround but not exactly mainstream-friendly. V3 replaced that with Bluetooth tethering through your phone’s hotspot. V4 cuts the tether entirely, pairing directly via Bluetooth through the new Nocturne Companion app, which requires a Nocturne+ subscription to fund the team’s continued development.

What the photos make immediately clear is how clean the UI actually looks in practice. The now-playing screen pulls album art and renders it as a full bleed gradient background, the same visual logic Spotify used but executed with noticeably more polish in edge cases. The typography is large and glanceable. The playlist browser view is dense but organized, using album thumbnails and track titles in a layout that navigates naturally with the knob. Image 3 shows a subtle ambient lighting effect around the screen border, a rainbow glow that responds to the current track, which is the kind of detail you wouldn’t expect from a community firmware project running on 2021 budget hardware.

The gesture control, OTA updates, Spotify Connect device switcher, podcast support, local file playback, and DJ mode all carried over from V3. The V4 architecture also bakes in full offline functionality, meaning the firmware survives without Spotify’s servers being cooperative, which was precisely the failure mode that bricked every original unit in the first place.

Nocturne’s GitHub currently lists V3.0.0 as the stable release, with V4.0.0 accessible to donors via Discord while the team finishes the public build. If you’ve got a Car Thing in a drawer, the installation guide at usenocturne.com is the next tab you should open.

The post Nocturne’s Free App Turns Your Bricked Spotify Car Thing Into Something Better Than the Original first appeared on Yanko Design.

Justin Poehnelt, Senior Developer Relations Engineer chez Google, vient de balancer sur Github un outil en ligne de commande (CLI), codé en Rust qui permet de faire un truc trop pratique, à savoir piloter entièrement Workspace depuis le terminal. Ce logiciel nommé GWS est donc capable de gérer Gmail, Drive, Calendar, Sheets et sept autres services Google d'un coup. Et en plus, comme il a été conçu pour les agents IA, donc c'est pas juste pour vous et votre terminal !

Une fois installé via npm, cargo, brew ou un binaire pré-compilé, vous tapez gws auth login pour vous authentifier via OAuth et vous pouvez ensuite attaquer onze services depuis votre shell : Drive, Gmail, Calendar, Sheets, Docs, Chat, Admin, Apps Script, Tasks, Workspace Events et Model Armor.

Niveau archi, au lieu de hard-coder chaque commande dans le binaire, gws interroge tout simplement le Discovery Service de Google au démarrage et reconstruit son arbre de commandes à la volée. Du coup quand Google ajoute un endpoint à l'API Sheets, le CLI le voit apparaître tout seul. C'est trop bien parce que ça évite de devoir attendre une release pour utiliser un éventuel nouveau service de Google. Et pour un agent IA qui re-fetch le schéma à chaque run, c'est plutôt une bonne idée.

Donc en plus de démarrer en moins d'une seconde, GWS crache des sorties en JSON structurées, y'a un mode --dry-run qui montre la requête sans l'envoyer, et de l'auto-pagination via --page-all. Et côté commandes utilitaires, vous avez aussi les + qui sont des helpers cousus main tels que gws gmail +send, gws drive +upload, gws calendar +agenda, gws sheets +append, gws gmail +triage et un gws gmail +standup-report qui résume vos mails de la semaine en quelques lignes.

Le repo embarque aussi 40+ skills d'agent prêts à l'emploi du type "résume mes mails non lus" ou "génère mon rapport", une extension Gemini CLI qui s'installe avec gemini extensions install https://github.com/googleworkspace/cli, et le helper +sanitize-response qui fait passer la sortie par Model Armor (le filtre anti-prompt-injection de Google Cloud) pour éviter les réponses bizarres.

En gros, c'est un outil pensé pour faire piloter votre Workspace par Claude, Gemini ou n'importe quel agent. Comme ça vous allez pouvoir écrire un workflow qui lit vos mails non lus, en fait un résumé, le poste dans un Chat et classe tout ça proprement dans Drive... sans avoir à toucher à la souris ni avoir à utiliser votre cerveau léthargique. Elle est pas belle la vie ?

Sauf que. Le projet porte le disclaimer "This is not an officially supported Google product", et un employé Google a confirmé sur le thread Hacker News (presque 1000 points, quand même) que c'est un projet DevRel. Comprendre : pas de SLA, pas de roadmap garantie, pas d'équipe SRE qui veille au grain. Vous savez comment ça finit chez Google avec ce genre de statut !

Bref si vous êtes chaud pour tester, le binaire est dispo ici . Maintenant reste à voir si Google lui donnera un statut officiel ou si GWS s'éteindra discrètement comme tant d'autres projets internes oubliés...

Speedtest.net c'est pratique, sauf que ça a été racheté par Accenture en 2026 et chaque test envoie votre IP, le nom de votre FAI et votre localisation à leurs serveurs...

Alors pourquoi ne pas adopter LibreSpeed , l'alternative open source que vous hébergez chez vous, et qui ne contient aucun tracker ??? L'outil est signé Federico Dossena, ça a été lancé en 2016 et c'est sous licence LGPL v3. Et ce que ça mesure c'est la vitesse du download, de l'upload, le ping, le jitter , et ça relève aussi l'adresse IP et le nom de votre FAI.

Côté déploiement, c'est du classique. Vous déposez les fichiers sur votre serveur, dont speedtest.js et speedtest_worker.js pour le frontend, vous configurez le backend via config.json, et hop c'est lancé. Un simple VPS ou n'importe quelle autre machine sur votre LAN fera l'affaire.

Et comme vous choisissez le serveur de test, y'a pas de saturation par d'autres utilisateurs, pas de route réseau bizarre vers un data center à l'autre bout de l'Europe et surtout, les résultats sont parfaitement reproductibles donc pour les "homelabers" (c'est comme ça qu'on dit ?) ou les équipes réseau, c'est assez chouette.

Il y a aussi le mode multi-serveur pour comparer des endpoints, le partage de résultats via lien unique, et un CLI librespeed avec ses flags --server et --host pour les fans du terminal. Des backends officiels en Go et Rust existent aussi sur le github de librespeed , signe que le projet est sérieux.

Et surtout, les résultats sont fiables, sauf si votre serveur plafonne à 20 Mbit/s et dans ce cas, vous mesurerez sa liaison et pas la vôtre. Ça coule de source, mais je tenais à le préciser quand même...

Voilà, l'interface est moche, en tout cas beaucoup plus que celle de Speed.cloudflare.com , par contre l'essentiel est là. Et surtout, les mesures restent chez vous plutôt que de partir ailleurs.

Bon, maintenant que vous avez vos chaînes IPTV qui tournent via Tunarr ou xTeVe, votre flux XMLTV est super propre. Mais il vous manque un seul truc : Un guide de programme potable.

Hé bien GridTV développé par l'ami JohnnyBeGood est là pour ça !

GridTV c'est une interface web en PHP/JS/CSS qui transforme toute source XMLTV compatible en guide TV façon grille horizontale, avec l'indicateur "maintenant" visible en permanence, une barre de progression du programme en cours, et les émissions passées qui se retrouvent automatiquement grisées. C'est exactement ce à quoi ressemble le guide TV de votre box opérateur, mais en mieux, et pour votre propre contenu !

Pour le déploiement, Docker est le chemin recommandé plutôt que de tout configurer à la main : git clone, cd GridTV, docker compose up -d, et hop, vous ouvrez localhost:8080.

Un assistant de setup vous demandera alors votre source EPG obligatoire et une playlist M3U si notamment vous voulez utiliser le player intégré, et une fois validé, vous retombez directement sur la grille.

Ça se met en place en moins de 5 min mais si vous préférez installer sans Docker, ou plutôt sans la couche conteneur, il y a également sur le Github des exemples de config pour Apache et Nginx dans la doc. Caddy fonctionnera aussi et la doc concernant Traefik, c'est pour le cas où GridTV tourne en Docker mais derrière un reverse proxy.

Côté fonctionnalités, le player HLS s'ouvre en PiP (Picture in Picture) dans un coin en cliquant sur une chaîne et le multi-EPG vous permettra de configurer plusieurs sources avec un petit switch. GridTV propose aussi des rappels de programme via notifications navigateur, 15 minutes avant la diffusion. Mais pour en profiter, l'onglet du browser doit rester ouvert et les notifs autorisées.

Et il y a aussi possibilité de générer un export PDF/PNG du guide sur 24h. C'est pas indispensable mais ça permet pour ceux qui veulent d'imprimer le programme de la soirée.

Chaque visiteur de l'instance peut aussi utiliser / paramétrer ses propres URLs XMLTV/M3U, car rien n'est stocké côté serveur. Hé oui, tout passe par le localStorage du navigateur donc vous pouvez partager votre instance avec autant de monde que vous voulez, ça n'a pas d'impact.

La version Steampunk

Et il y a même des thèmes genre cyberpunk, steampunk, magazine ou le thème par défaut. Et la page de monitoring admin expose également une sonde accessible via un endpoint compatible Uptime Kuma qui renvoie le code HTTP 200 si tout va bien. Sinon, ce sera du code 503. Bref, ça vous connaissez...

Bref, l'outil est jeune mais bien construit et une démo live tourne ici guide.demo.johnnybegood.fr . À suivre donc....

Et si vous cherchez juste des listes de chaînes IPTV gratuites , c'est par là !

Si vous faites tourner WireGuard depuis un réseau filtré par DPI (Genre en Russie, Iran, Chine, et autres pays défenseurs de la libertéééé (non)), vous avez sans doute remarqué que les tunnels tombent rapidement. En effet, les signatures des protocoles et notamment du protocole WireGuard sont devenues facilement identifiables. Les filtres modernes de censure sont ainsi capable de les bloquer en quelques secondes. C'est pour ça que wg-obfuscator , sorti par Alexey Cluster (le dev derrière le mod hakchi de la NES Classic Mini dont je vous parlais en 2017), m'a tapé dans l'œil.

Concrètement, c'est un petit proxy en C qui se glisse entre votre WireGuard et le réseau. Vous le lancez aux deux bouts du tunnel, et lui déguise les paquets pour qu'ils ressemblent à du STUN (le protocole utilisé par les outils de visioconf, rarement bloqué) ou à un flux random pas reconnaissable. WireGuard continue ainsi de tourner sans aucune modification...

C'est vraiment bien fichu son truc et surtout, par rapport à AmneziaWG (un célèbre fork de WireGuard souvent cité comme référence en obfuscation), hé bien y'a juste un binaire à rajouter, alors que AmneziaWG, lui, modifie TOUT le protocole. Il faut donc remplacer les client ET le serveur ce qui est bien relou.

Comme wg-obfuscator se contente uniquement de faire le proxy, vous gardez votre setup WireGuard classique et donc ça fonctionnera partout... Sur OpenWrt, MikroTik avec RouterOS 7.4+ sur ARM64/x86_64 via Docker, NixOS, Android, ou un simple Raspberry.

Par contre, l'outil utilise une clé symétrique en texte clair donc c'est pas du chiffrement fort, mais du camouflage.

Côté config, on est sur du fichier INI tout simple :

[main]
source-lport = 13255
target = 10.13.1.100:13255
key = votre_secret
masking = STUN
verbose = 2

Cisco’s open-source Model Provenance Kit helps organizations verify AI model origins, trace lineage, and reduce AI supply chain security risks.

The post Cisco Introduces Model Provenance Kit to Strengthen AI Supply Chain Security appeared first on TechRepublic.

Hello les amis, voici ma petite trouvaille du jour, idéale pour ceux qui jouent en ce moment avec des adresses IP : ip66.dev . C'est une base de géolocalisation IP et entièrement libre, livrée au format MMDB (le même que celui de MaxMind) qui permet de remplacer direct un fichier GeoLite2 dans vos libs existantes (Python, Go, Node.js), sans toucher au code.

L'équipe de Cloud 66 maintient cette liste à jour sous licence CC BY 4.0 et tout est utilisable simplement en récupérant le fichier mmdb.

Pour le télécharger :

curl -LO https://downloads.ip66.dev/db/ip66.mmdb

go install github.com/maxmind/mmdbinspect/cmd/mmdbinspect@latest
mmdbinspect -db ip66.mmdb 8.8.8.8

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

Depuis qu'Amazon a coupé le téléchargement USB de nos ebooks Kindle (sniiiif), héberger sa propre bibliothèque est passé du statut de bricolage du dimanche aprem au geste héroïque de préservation de notre souveraineté !

Alors si vous voulez vous lancer, sachez que Kavita , le serveur de lecture auto-hébergé développé depuis 2020, est l'un des candidats les plus solides du moment. C'est un lecteur web qui gère EPUB, PDF, comics CBZ/CBR et manga avec mode de lecture droite-à-gauche pour les aficionados et grâce lui, nos ebooks peuvent reprendre leur indépendance.

Ce truc, ça se déploie en Docker ou via Scoop pour Windows en 4 lignes de PowerShell.

De mon côté, j'ai installé Kavita sur mon NAS Synology alors voici la marche à suivre si vous voulez faire pareil.

Installation sur NAS Synology (Container Manager)

Testé sur DSM 7.2 avec Container Manager. Pour QNAP via Container Station ou TrueNAS, la logique est la même puisque c'est du Docker standard.

Étape 1 - Préparer les dossiers

Sur votre NAS, créez deux dossiers via Panneau de configuration > Dossier partagé :

• docker/kavita/config pour la config et la base SQLite de Kavita
• data/library/books pour votre bibliothèque (pointez où vous stockez déjà vos EPUB et CBZ)

Étape 2 - Le docker-compose.yml

Ouvrez ensuite Container Manager > Projet > Créer, donnez-lui le nom kavita, et collez ce docker-compose :

services:
 kavita:
 image: jvmilazz0/kavita:latest
 container_name: kavita
 restart: unless-stopped
 ports:
 - "5000:5000"
 environment:
 - TZ=Europe/Paris
 volumes:
 - /volume1/docker/kavita/config:/kavita/config
 - /volume1/data/library/books:/manga

L'image jvmilazz0/kavita:latest est celle référencée dans la doc officielle. Côté container, les chemins sont /kavita/config et /manga (peu importe que ce soit du manga ou des romans, c'est juste le nom historique du point de montage).

Étape 3 - Lancer le conteneur

Validez le projet. L'image se télécharge (environ 200 Mo), puis le conteneur démarre. Si le port 5000 est déjà pris sur votre NAS, changez le mapping en 5001:5000 par exemple.

Étape 4 - Premier lancement

Dans votre navigateur, allez sur http://IP-DU-NAS:5000. L'écran d'accueil vous demande alors de vous créer un compte admin.

Validez, puis allez dans les préférences pour passer l'interface en français et rafraichissez la page.

Ensuite, dans les paramètres du serveur > Bibliothèques, ajoutez une bibliothèque : Type "Livre" pour les EPUB/PDF ou "Manga"/"Comic" selon le contenu, le choix du dossier pointant vers /manga. Le scan démarre automatiquement.

Étape 5 - Organisation des dossiers

Attention, Kavita est sensible à la structure des dossiers donc pour qu'il identifie correctement les séries, organisez vos dossiers comme ça :

/manga
├── Asterix/
│ ├── Asterix - Tome 01.cbz
│ └── Asterix - Tome 02.cbz
├── Stephen King/
│ ├── Ça.epub
│ └── Shining.epub

Un sous-dossier par série ou par auteur, pas tout en vrac dans un dossier unique.

Étape 6 - Accès distant (optionnel)

Maintenant, pour accéder à Kavita depuis l'extérieur, le plus propre c'est un reverse proxy avec HTTPS. Sur Synology, soit via DSM > Portail web > Proxy inversé, soit via Nginx Proxy Manager . Pointez votre sous-domaine sur IP-NAS:5000 et activez Let's Encrypt.

Ou alors, moi ce que j'aime bien faire aussi, c'est rien du tout et passer par Tailscale !

Côté fonctionnalités

Côté ergonomie, franchement ils n'ont pas chômé puisqu'on y retrouve le lecteur intégré avec modes single page, double page, webtoon ou même mode immersif plein écran. Des thèmes light, dark, sepia, + un mode personnalisé en CSS si vous voulez.

Y'a aussi de la synchro de progression de lecture entre tous vos appareils, du coup vous pouvez commencer un chapitre sur le laptop pendant votre pause café et le finir sur le téléphone dans le métro. C'est appréciable au quotidien.

Y'a aussi de la gestion multi-utilisateur avec authentification OIDC pour ceux qui aiment faire les choses bien (et ratings + listes individuels par compte, donc votre meilleur pote peut lire ses romans de Tom Clancy à côté de votre collection de docs techniques sans qu'on les mélange).

Il y a également une surveillance automatique des dossiers pour tout ce qui est import auto et de la recherche full-text avec filtres par métadonnées (titre, auteur, série, genre, langue).

Et si vous avez des enfants, il est possible de mettre en place des restrictions par classification d'âge pour éviter qu'ils ne fouillent dans vos comics de Manara. Et le clou du spectacle spécial barbu, c'est l'export d'annotations vers Obsidian via le plugin officiel pour les nerds du second cerveau.

Kavita propose même une fonction "Send to Kindle" pour balancer un EPUB vers votre liseuse Amazon. Sur Windows, vous pouvez aussi le transformer en service système avec Shawl pour qu'il démarre tout seul au boot, et côté Linux, un docker-compose suffira largement.

Voilà, dans cette jungle bordélique des outils ebooks auto-hébergeables, Kavita se positionne comme une option moderne et stable. Je préfère Kavita à Calibre car l'interface web est carrément plus moderne et hyper fluide à l'usage.

Vous l'aurez compris, côté concurrence, Kavita est historiquement plus orientée mixte ebooks-comics que Komga (qui supporte aussi les EPUB et PDF mais reste très ancré culture comics). Alors si vous hésitez entre les outils du moment, mon tour d'horizon des outils ebooks self-hosted devrait vous éclairer (avec notamment le drame Booklore !!).

Ah et y'a aussi Kavita+, la version premium à 4 $ par mois (2 $ le premier mois avec le code FIRSTTIME) qui ajoutera la sync AniList, des recommandations personnalisées, des collections intelligentes et l'enrichissement de métadonnées automatique. Après, perso, pour un usage classique, je trouve que la version gratuite fait déjà largement le job, mais si vous gérez +50 000 fichiers et que vous voulez pas passer la soirée à taguer des séries entières, là ça peut carrément valoir le coup.

Source

Vous voulez comprendre ce qui se passe dans le cerveau de votre bagnole ? Hé bien pour cela avant, il fallait du matos pro et des suites logicielles à licence annuelle. Mais maintenant, y'a CANviz .

Un pip install canviz, un module USB à quelques balles branché sur le bus CAN de la voiture, et hop, vous accédez à tous les secrets de votre voiture simplement en ouvrant votre navigateur sur localhost:8080. Toutes les trames qui circulent sur le réseau interne du véhicule s'affichent en direct dans un tableau qui défile sans ramer à 2000 fps si j'en crois le README, donc ça envoie !

Ce projet signé Chanchal Dhiman tourne sur n'importe quelle config équipée de Python 3.10 ou supérieur, et côté matériel, CANviz se branche sur plein de bazars tels que les modules à firmware Candlelight (genre FYSETC UCAN autour de 8 balles ou CANable 1.0 autour de 15), les périphériques slcan via port COM, et du matériel sérieux type PEAK PCAN-USB, Kvaser, Vector ou même socketcan sur Raspberry Pi. En gros, si votre clé USB CAN est compatible avec python-can, CANviz la gère !

L'interface décode alors les fichiers DBC (le format de base de données du CAN), donc au lieu de lire des paquets hexadécimaux chelous, vous voyez directement "vitesse moteur = 1450 rpm" ou "position accélérateur = 34%". Vous pouvez aussi filtrer par ID ou par nom de signal, et le filtre se garde dans l'URL. Comme ça, vous pouvez partager une vue à un pote en copiant simplement le lien.

Le truc vraiment pratique, c'est surtout la partie enregistrement. Vous capturez une session en .asc ou .csv, et vous la rejouez plus tard à vitesse variable (de 0.5x pour décortiquer lentement, jusqu'à 10x pour survoler), ou vous forgez vos propres trames depuis l'interface pour tester la réaction d'un module donné. Une API REST et du WebSocket ouvrent aussi la porte aux bricolages en Python, avec une doc interactive accessible sur /docs.

Autre truc malin, vu que c'est un serveur web derrière : vous pouvez déployer CANviz sur un Raspberry Pi planqué dans la bagnole et le consulter à distance en SSH. Par contre, pas de WebUSB ici. L'auteur a explicitement fait le choix de passer par python-can côté serveur pour des raisons de sécurité. L'accès USB reste donc dans le sandbox Python, et le browser ne touche rien. J'avoue, je préfère.

Le projet est sous licence MIT, et est encore jeune, mais l'approche est éprouvée. Pour ceux qui cherchent des alternatives desktop, y'a bien sûr CANgaroo côté Qt, ou SavvyCAN qui tourne aussi en natif. Et si vous voulez bidouiller votre voiture comme Charlie Miller l'a fait avec la Jeep , y'a toujours le Panda de Comma sorti en 2017 avec son soft Cabana.

Bref, pour quelques euros de module USB et un pip install des familles, vous pouvez transformer votre laptop en analyseur CAN niveau pro et ça c'est plutôt classe !

Source

Vous bossez sur un Dockerfile et vous avez besoin de la dernière version de nginx. Vous ouvrez GitHub, vous cliquez sur Releases, vous copiez-collez. Et 3 minutes plus tard, rebelote pour curl. Puis pour PHP. Sans parler du fait que dans votre script d'auto-update, vous avez hardcodé une "v3.2.1" qui dort là depuis 2023 parce que personne n'a pris le temps de mettre à jour le fichier.

Lastversion , c'est le petit CLI Python signé Danila Vershinin qui remplace cette corvée par une seule ligne. Vous tapez lastversion apache/incubator-pagespeed-ngx et vous récupérez le numéro de la dernière version.

Le truc marche sur GitHub, GitLab, BitBucket, PyPI, Wikipédia, les flux RSS, les plugins WordPress, Helm charts, Gitea, SourceForge... et même sur des sites qui publient leurs versions comme ils veulent, genre nginx.org.

La beauté du bazar, c'est qu'il comprend les humains, parce que, c'est vrai, les mainteneurs font un peu n'importe quoi avec leurs tags. Ils étiquettent release-1.2.3 au lieu de 1.2.3, ils marquent des release candidates en stable sans le faire exprès, ils changent de format entre v20150121 et v2.0.1 sans prévenir. lastversion détecte toutes ces incohérences et vous renvoie la véritable dernière stable, celle que vous vouliez dès le départ. C'est pénible à gérer à la main quand vous avez vingt dépendances à suivre. Maintenant c'est réglé tout seul avec ce petit bidule.

Et les sources exotiques, c'est tout un délire. lastversion windows vous crache le build Windows en cours, lastversion ios pour iOS, lastversion rocky vous renverra 8.4 et lastversion https://en.wikipedia.org/wiki/Rocky_Linux aussi, parce que le bidule va carrément parser la page Wikipédia pour vous.

Alors certains d'entre vous me diront que ce n'est pas utile au quotidien. Peut-être jusqu'au jour où vous devez scripter une vérif de version d'OS sans dépendre d'un outil système. Par contre, si vous enchaînez cinquante requêtes par heure sur un token GitHub anonyme, faudra pas s'étonner de manger un rate limit dans la tronche.

Côté one-liners qui tuent, y'a déjà de quoi faire.

wget $(lastversion --assets mautic/mautic) télécharge direct la dernière archive.

lastversion --pre Aircoookie/WLED --format assets --filter ESP32.bin -d ESP32.bin récupère le dernier firmware ESP32 WLED.

Pour Nginx, lastversion https://nginx.org --major stable renvoie 1.16.1 pendant que --major mainline renvoie 1.17.9.

Vous voyez l'idée, c'est du pipe-friendly pur jus.

Et le mode install, c'est un autre délire. Vous tapez lastversion install mailspring et hop, il récupère l'AppImage ou le RPM du dépôt, il l'installe, et c'est fini. Attention quand même, sur les dépôts un peu bordéliques il va parfois se vautrer sur le packaging et juste vous balancer le tarball brut. Bon, c'est pas la mort, vous dézippez à la main et vous passez à la suite...

Combiné avec cron, @daily /usr/bin/lastversion install mailspring -y et votre bureau sera toujours à jour sans passer par un store. Pour tous les outils qui ne sont ni dans apt, ni dans un snap, ni dans un flatpak, c'est l'alternative la plus propre à avoir sous la main.

L'install se fait via pip install lastversion sur à peu près tout, ou yum install lastversion après avoir ajouté le repo GetPageSpeed si vous êtes sur CentOS, RHEL, Rocky, Alma, Fedora ou Amazon Linux.

Le projet est publié sous licence BSD-2, codé en Python, et il y a aussi une API utilisable directement (from lastversion import latest) si vous préférez appeler ça dans vos scripts plutôt que de piper dans un subprocess.

Bref, un chouette outil à ranger entre vos redirections bash et votre gestionnaire SSH , catégorie petits trucs qui font gagner 10 minutes par semaine.

Un éditeur vidéo qui redimensionne, compresse et coupe vos clips... sans rien uploader nulle part, ça vous dit ???

Ça tombe bien puisque VidStudio fait tourner FFmpeg directement dans votre navigateur ! Vous allez sur vidstudio.app, vous déposez votre vidéo, et tout le traitement se fait ensuite côté client. Les fichiers ne quittent jamais votre machine, ce qui fait que niveau vie privée, ça nous change clairement des éditeurs cloud type Clipchamp ou Canva où une partie du traitement passe par leurs serveurs avec toutes les joyeusetés que ça implique côté données.

Sous le capot, le truc tient debout grâce à trois briques. Il y a WebCodecs qui s'occupe du décodage frame par frame pour la timeline, en utilisant les décodeurs hardware du navigateur quand ils sont dispos. FFmpeg compilé en WebAssembly prend ensuite le relais pour l'encodage final et les conversions de format. Et pour le rendu, c'est Pixi.js sur une canvas WebGL, avec un fallback logiciel quand la carte graphique ne suit pas.

Les projets sont sauvegardés dans IndexedDB, du coup vous pouvez fermer l'onglet et revenir plus tard, car tout est conservé et les traitements lourds tournent dans des Web Workers, ce qui évite de geler l'interface quand vous compressez un fichier de 2 Go déjà bien lourd.

Ensuite, côté outils, y'a de quoi faire avec un éditeur multi-piste avec source monitor et la possibilité de parcourir la vidéo à la frame près. Il y a également de quoi redimensionner pour YouTube ou TikTok, un mode batch pour convertir plusieurs vidéos d'un coup, un compresseur avec cible de taille exacte, un extracteur audio, un générateur de thumbnails et storyboards, et un système de watermarks avec positionnement et timing. Les sous-titres sont également gérés, avec possibilité de les incruster dans la vidéo ou de les sortir séparément.

Niveau problèmes que vous pourriez rencontrer avec cet outil, ce sera surtout à cause des codecs HEVC qui galèrent sur Firefox. De plus, les vidéos 10-bit ne passent pas toujours sur Windows, et certains WEBM avec des codecs audio exotiques refusent de charger. Bon après c'est pas grand chose de dramatique pour du contenu classique filmé avec un smartphone ou un appareil photo, mais si vous bossez avec du matos pro en 10-bit, allez plutôt voir ailleurs.

Après si vous aimez ce genre d'outils, dans la famille "traitement vidéo dans le navigateur", VidStudio rejoint Cutia qui mise sur l'open source, et MediaBunny qui propose une bibliothèque bas niveau pour les devs et dont je vous ai déjà parlé. Cependant, je préfère VidStudio qui se positionne plutôt sur du grand public, avec une interface qui ressemble à un vrai logiciel de montage.

Ça tourne d'ailleurs sur smartphone, ce qui est franchement impressionnant. Donc si vous avez juste une vidéo à retoucher vite fait sans passer par une usine à gaz type Adobe Premiere ou Final Cut, ça fera bien le job, et vos fichiers restent sagement au chaud chez vous !

Les beaux jours reviennent, et avec eux l'envie d'un soda bien frais ! Sauf qu'au lieu d'alimenter un énième groupe industriel (coucou Coca Cola), vous pouvez maintenant fabriquer le vôtre à la maison. Et blinry , un développeur allemand, l'a bien compris puisqu'il vient de publier sur GitHub ses 6 années de recherches sur le sujet... en CC0, donc dans le domaine public ! A vous votre copie cheap du Bougnat / Breizh Cola ^^

L'histoire commence en 2020. Le mec a deux problèmes simples à résoudre : la caféine lui file des migraines, et il veut éviter le sucre. Du coup il décide de se faire son propre cola, sans caféine, sans sucre, et surtout sans dépendre d'une marque qui garde sa formule secrète depuis plus d'un siècle.

Six ans plus tard, il a finalement trois recettes bien abouties : cola, orange, et amande (!). Toutes sont dispos sur son dépôt GitHub en markdown, dans le même esprit que Cooklang dont je parlais récemment . Et comme c'est du domaine public pur et dur, vous pouvez tout copier, modifier, revendre, tout ce que vous voulez.

Car concrètement, un cola c'est quoi ? Hé bien selon la recette de blinry, c'est un mélange de 7 huiles essentielles (orange, citron vert, citron, noix de muscade, casse, coriandre, lavande), un peu de gomme arabique pour l'émulsion, de l'acide citrique, du colorant caramel, et un édulcorant genre sucralose.

Ensuite, vous prenez une seringue d'un millilitre pour doser les huiles au centième de millilitre près, vous pesez le reste sur une balance de précision, et hop, vous avez un sirop concentré qu'il n'y a plus qu'à diluer avec de l'eau gazeuse !

Niveau matos, c'est assez basique... Balance, seringue, mixeur à main, un petit récipient en plastique, et voilà. D'abord vous mélangez les huiles avec la gomme arabique pour faire l'émulsion, ensuite vous ajoutez l'eau et le reste, puis vous filtrez. Par contre, attention, les huiles essentielles concentrées sont corrosives, donc c'est gants en latex obligatoires si vous ne voulez pas finir avec les doigts brûlés.

Et le verdict ? Hé bien le gars dit qu'il préfère son cola au vrai Coca, carrément ! D'ailleurs quand il a testé un Coca récemment pour comparer, il l'a trouvé, je cite "fade, genre glace au cola fondue". Moi j'suis plus Cherry Coke mais c'est compliqué d'en trouver du light, donc si je me lance là dedans, j'essayerai de bien doser en huile essentielle de cerise ^^.

Notez que Blinry n'est pas seul dans cette quête. Avant lui, il y a eu Cube Cola , OpenCola avant encore, et plus récemment un certain LabCoatz a utilisé carrément un spectromètre de masse pour décoder le profil de saveur. Bref, y'a tout un écosystème de gens qui essaient de percer le "secret" Coca-Cola depuis des décennies mais visiblement sans succès puisque tout ce que j'ai pu goûter en cola alternatif était vraiment pas ouf... Ça sent trop le médicament aux plantes en général.

Et comme Coca n'a jamais breveté sa formule parce qu'un brevet aurait tout révélé, le vrai produit qu'ils vendent, c'est surtout le mystère autour de la formule. Donc il suffit qu'un de ces bidouilleurs de soda perce le mystère et demain on aura du coca 100% similaire à l'original niveau goût, 100% sous licence libre ! Ce serait fou !

Bref, servez-vous, modifiez, et surtout partagez vos améliorations sur son Git. Et si vous trouvez la recette ultime, faites signe !

Source

J'sais pas si vous vous en rendez compte mais les agents IA qui codent sur votre machine ont accès à vos clés SSH, vos credentials AWS, votre Keychain et compagnie. Ils ont accès à TOUT ! C'est comme filer les clés de votre appart à un gars que vous avez croisé sur le parking de Leclerc y'a pas 5 min.

Hazmat prend le problème à l'envers : au lieu de demander poliment à l'agent de se tenir tranquille, il l'enferme dans un compte macOS séparé. Du coup, vos ~/.ssh, ~/.aws, votre Keychain deviennent structurellement inaccessibles. Pour en profiter, faut faire un

brew install dredozubov/tap/hazmat

cd /tmp

hazmat init --bootstrap-agent claude

Vous vous souvenez d'eMule ? Le petit âne qui monopolisait votre connexion ADSL pendant 3 jours pour télécharger un fichier de 700 Mo... et les fameux "Linux_ISO.avi" qui n'étaient absolument pas des ISOs Linux ?

Eh bien le bougre est de retour sur macOS. macMule c'est eMule packagé en .app native, compatible Apple Silicon via Rosetta 2, zéro configuration. Vous glissez dans Applications, vous lancez, et hop ça se connecte tout seul aux serveurs ed2k et au réseau Kad. Hé oui, ça tourne encore en 2026.

Côté technique, l'app fait environ 1 Go parce qu'elle embarque Wine Crossover (la couche de compatibilité Windows par Gcenx). Le développeur Martin Derouet a pris le build Community x64 d'eMule par irwir, l'a wrappé dans un bundle .app self-contained, et comme ça, ça se lance comme n'importe quelle app Mac.

Y'a pas de dépendances externes à installer, et surtout pas de terminal à ouvrir. Les fichiers téléchargés atterrissent alors dans ~/Library/Application Support/macMule/drive_c/eMule/Incoming/... c'est pas super intuitif comme chemin, mais au moins c'est rangé.

D'ailleurs, si vous avez suivi l'actualité de Wine 10.0 et le support ARM , vous savez que la couche de compatibilité Windows n'a jamais été aussi solide. macMule en profite directement. Et si vous voulez compiler votre propre build, le script est dispo : ./build.sh pour la dernière version stable ou ./build.sh 0.70b pour une version spécifique. Faut juste avoir Homebrew avec wine-crossover et Rosetta 2 installés.

J'ai été surpris que les réseaux ed2k et Kad soient encore debout. Mais c'est cool car ces réseaux hébergent des fichiers qu'on ne trouve nulle part ailleurs. Des archives oubliées, des vieux logiciels, des trucs que personne n'a jamais re-uploadé nulle part. C'est un peu le grenier d'Internet, poussiéreux mais plein de trésors pour qui sait chercher et plein de malwares aussi, alors gaffe à vous !

Attention quand même, ça reste un client P2P pour le réseau ed2k donc les précautions habituelles s'appliquent. Vérifiez ce que vous téléchargez, et n'oubliez pas que l'Arcom (ex-Hadopi) veille toujours au grain.

Bref, si vous avez la nostalgie du petit âne et que vous êtes sur Mac, c'est par là !

Merci à Martin pour la découverte !