Il y a des problèmes qui n'existent pas, et des gens qui les résolvent quand même... Ray Foss en fait partie. Ce dernier a fait en sorte que sa Steam Controller flambant neuve rampe toute seule jusqu'à son chargeur, sans qu'il ait à lever le petit doigt. Et pour cela, il a codé son Triton Auto-Charge Vision Tracker qui tourne entièrement dans le navigateur et qui est utilisable par tous !

Le principe est bien tordu... Vous collez une webcam au-dessus de votre bureau, vous ouvrez la page, et vous cliquez sur trois points à l'écran : le palet de charge, l'avant de la manette, l'arrière. À partir de là, la vision par ordinateur suit la manette en temps réel pendant que le code pilote ses deux petits moteurs de vibration internes.

Petit rappel si vous aviez hiberné, Valve a ressorti sa Steam Controller en mai dernier, des années après avoir lâché la première. Elle se recharge sur un palet magnétique, et c'est pile poil cette dernière étape que Foss a automatisée. La Steam Controller, c'est aussi la manette dans laquelle Valve a planqué un cri Wilhelm , et visiblement elle attire les bidouilleurs.

En pulsant ces moteurs de façon asymétrique, autour de 70 Hz, la page fait littéralement ramper la manette sur le bureau et la réoriente petit à petit vers le palet. C'est le principe de ces bristlebots faits avec une brosse à dents et un moteur vibreur de téléphone, sauf qu'ici les moteurs étaient prévus pour faire vibrer la manette dans vos jeux, et surement pas pour la balader sur le bureau...

Pas d'install, pas de pilote à régler non plus, c'est la page qui se connecte directement à la manette via WebHID, la même techno qui permet déjà de tester son matos gaming dans le navigateur , à condition d'être sur Chrome ou Edge parce que Firefox et Safari boudent toujours cette API.

L'interface de l'outil, avec les points de repère à placer sur la manette et le palet.

Au passage, elle lit la batterie de la manette et vous affiche le pourcentage et même le voltage de la cellule, histoire de confirmer que le contact magnétique se fait bien.

Foss a aussi prévu un mode approche en douceur qui réduit de moitié la fréquence des vibrations quand la manette arrive tout près du palet, pour qu'elle se pose dedans au lieu de le percuter. Enfin, en théorie, parce qu'il prévient lui-même que l'amarrage n'est pas garanti.

La vraie limite du truc, c'est que le calage des points de repère reste assez pénible à faire.

Ça ne sert strictement à rien, mais c'est marrant. Le projet est en open source sur GitHub si vous voulez tenter le coup chez vous.

Source

Monter une vraie IA à la maison, c'est vite une galère. Vous achetez une super machine puis vous collez dessus toute votre liste au père Noël (Chat local, reco vocale, génération d'image, RAG et compagnie) et vous voilà à empiler des dockers à n'en plus finir. Eh bien Light Heart Labs en a eu marre de ces bricolages et nous a pondu Dream Server, un outil qui câble tout ce petit monde à votre place !

Une seule commande et c'est parti mon kiki (Linux et macOS) :

curl -fsSL https://raw.githubusercontent.com/Light-Heart-Labs/DreamServer/main/dream-server/get-dream-server.sh | bash

Ou Windows :

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
git clone https://github.com/Light-Heart-Labs/DreamServer.git
cd DreamServer
.install.ps1

Ça va lancer le script qui va ensuite tout paramétrer tout seul et choisir le modèle d'IA qui collera le plus à votre matériel, et cela que vous ayez une RTX 4090, un Mac M4 avec mémoire unifiée ou encore une puce AMD Strix Halo voire un vieux PC sans GPU.

Edit : un lecteur m'a remonté un piège si vous êtes sous Linux configuré en français (ou n'importe quelle locale qui écrit les décimales avec une virgule). Le script génère tout seul les valeurs de votre fichier .env en suivant le format de nombres de votre système, et il vous colle des 16,0 au lieu de 16.0. Du coup l'install se vautre avec une erreur dans le genre COMFYUI_CPU_LIMIT: expected number, got '16,0'. La parade, confirmée par un des auteurs, c'est de relancer l'installeur en forçant la locale C (celle qui met des points à la place des virgules) :

LC_ALL=C ./install.sh

Ensuite, pendant que le LLM se télécharge à fond les ballons, un autre petit modèle de 1,5 milliards de paramètres en backup afin que vous puissiez quand même "discuter" avec votre Dreamserver.

Le rôle de Dreamserver c'est donc juste de prendre toutes les briques de l'IA pour vous en faire un truc clé en main. Open WebUI pour le chat, llama-server pour l'inférence, Whisper et Kokoro pour la voix, ComfyUI pour les images, Qdrant pour le RAG, SearXNG pour la recherche web sans mouchard, et bien sûr n8n pour brancher tout ça à vos automatisations.

Et une fois que c'est en route, suffit de lancer la commande dream et là vous pourrez tout faire.

Par exemple dream status pour visualiser l'état des services et du GPU, dream model swap T3 pour changer de "palier" sur votre matos, dream enable n8n pour activer une extension ou encore dream mode hybrid pour avoir de l'inférence en local avec possibilité de basculer sur une IA dans le cloud via une API.

Dreamserver reste un orchestrateur, et pas un moteur IA magique, donc si vous adorez tout assembler vous-même, vous n'avez clairement pas besoin de ça. Par contre, si vous vous en foutez, et que vous voulez juste votre IA qui tourne ce soir, ça vous fera gagner des heures de bidouille.

Faut dire qu'à mesure que l'IA devient une infrastructure de base, dépendre à 100% d'un abonnement cloud qui peut tripler ses tarifs ou couper votre accès du jour au lendemain, ça craint un peu. Donc je pense qu'on est tous bien contents d'avoir des solutions clé en main comme celle-ci.

Si ça vous tente, c'est sur le dépôt de Dream Server .

Y'a un truc dont on parle pas assez dans le milieu tech je trouve, et pourtant tout le monde le constate : Une grande partie des communautés autour du logiciel libre, de Linux, du dev...etc sont devenues des endroits franchement hostiles. Des clubs fermés, peuplés quasi exclusivement de mecs, qui passent leur temps à expliquer aux autres qu'ils sont de gros nuls, qu'ils posent des questions de noobs, ou encore qu'ils ne tapent pas sur leur clavier comme il faut et j'en passe... Oui je parle bien entre autres du fameux barbu Linux qui vous toise parce que vous utilisez Ubuntu et pas Arch que vous avez compilé à la main.

Et le pire, c'est que tout ça est documenté et chiffré, et même reconnu par les pontes du milieu eux-mêmes ! Vous allez voir...

Prenez Linus Torvalds par exemple. C'est le créateur de Linux et pendant des années, il a insulté publiquement des développeurs sur la mailing list du kernel, leur balançant que leur code était une honte et compagnie. En septembre 2018, il a toutefois fini par mettre les choses à plat dans un mail d'excuses où il écrit noir sur blanc que ses attaques étaient "non professionnelles et injustifiées", et qu'il voulait s'excuser auprès des gens que son comportement avait blessés et je cite, "possiblement complètement chassés du développement du kernel". Il a même pris une pause pour aller se faire aider à comprendre ses émotions. Si même le mec au sommet de la pyramide reconnaît qu'il a fait fuir des contributeurs à coups de mépris, vous imaginez un peu l'ambiance qui grouille en dessous...

D'ailleurs, trois ans plus tôt, en 2015, une développeuse majeure du kernel avait déjà claqué la porte. Sarah Sharp, celle qui maintenait le pilote USB 3.0, était pourtant loin d'être une débutante. Dans son billet Closing a door , elle explique notamment qu'elle n'arrive plus à contribuer à une communauté où elle était respectée pour ses compétences mais jamais respectée en tant que personne.

Violence verbale, blagues sexistes et homophobes, voilà tout ce qu'elle subissait. Et en 2015, malheureusement, elle criait vraiment dans le désert. Personne ne l'a écouté et il aura fallu attendre 2018 et les excuses de M. Torvalds pour capter qu'il y avait un sérieux problème.

Je vous ai dit aussi que j'avais des chiffres, alors les voilà... En 2017, une étude publiée dans PeerJ a analysé plus de 3 millions de pull requests sur GitHub et le résultat bien que fascinant m'a déprimé. Le code proposé par des femmes est accepté à un taux plus élevé que celui des hommes, environ 79% contre 75%. SAUF quand leur genre est identifiable. Cela veut dire que quand on sait que c'est une femme, on accepte moins son code, alors même qu'en moyenne il est meilleur. Affreux non ?

La même année, l'enquête Open Source Survey de GitHub plantait également le décor en annonçant qu'il y avait environ 95% d'hommes, 3% de femmes et 1% non binaire parmi les contributeurs (le 1% restant c'est l'arrondi, btw). Et tristement, les femmes rapportaient bien plus souvent du langage qui les mettait mal à l'aise, et des remarques stéréotypées ("Pas mal pour une femme !", "T'es blonde ou quoi ?", ce genre de saloperies sexistes).

Voilà où en est la belle méritocratie du logiciel libre !

Et du côté de l'entraide soi-disant légendaire, c'est pas plus glorieux. Stack Overflow, le site où des millions de devs vont chercher de l'aide tous les jours, a carrément publié en 2018 un mea culpa officiel . Leur responsable "culture" y écrit que trop de gens vivent Stack Overflow comme un endroit hostile ou élitiste, en particulier les codeurs débutants, les femmes et les personnes de couleur.

Le vrai problème, selon lui, ce n'est pas la communauté, c'est qu'on a appris aux utilisateurs à dire aux autres ce qu'ils font de travers sans jamais leur apprendre à le faire correctement. C'est ce bon vieux RTFM de connard balancé à la gueule des débutants qui après n'osent plus poser de question.

Et tout ça, ça coûte cher, figurez-vous. Oui, oui, la Tech Leavers Study du Kapor Center , en 2017, a chiffré à 16 milliards de dollars par an le coût du turnover provoqué par une culture de travail injuste dans la tech. Les femmes, les minorités, les gens qui ne rentrent pas dans le moule, bah ils se barrent. Une autre enquête, Elephant in the Valley , montrait même que 60% des femmes de la Silicon Valley qui avaient +10 ans d'expérience avaient subi des avances sexuelles non désirées.

Bon, maintenant je vais quand même vous parler de moi, parce que tout ça, je le constate aussi depuis vingt ans.

Pour ma part, si je me suis retiré des réseaux sociaux, et je parle même des réseaux plus barbus, les Mastodon et compagnie censés être plus sains, c'est à cause de ça. Cette hostilité permanente, ce besoin maladif de certains de vous expliquer pourquoi vous avez tort, pourquoi votre choix technique est nul, pourquoi vous n'êtes pas un "vrai". Et si j'ai fermé mes commentaires il y a des années, c'est exactement pour la même raison. Pas parce que je ne voulais plus discuter avec vous, mais parce que je ne voulais plus servir de défouloir à une poignée de types qui confondent intelligence et agressivité.

Sachez que sur cette planète, 100% des problèmes que j'ai eus (et que j'ai encore) dans ma vie perso comme dans ma vie pro, ont été causés par des hommes. Pas 90%. 100% ! Et à chaque fois que quelqu'un m'a défendu, m'a tendu la main, m'a aidé quand j'étais au sol, c'était dans 80% des cas des femmes. Alors je le dis tout simplement, merci à elles, vraiment, du fond du cœur.

Donc voilà, messieurs les toxiques de la tech, sachez-le, je vous évite du mieux que je peux, parce que vous n'êtes pas les personnes ouvertes et sympathiques que vous pensez être. J'ai toujours refusé de rentrer dans vos cases et je pense que pour votre bien et celui du Monde en général, ce serait chouette à un moment d'arrêter de vous comporter en boy's club de connards, et surtout arrêter de croire que la tech vous appartient et que tous ceux qui ne pensent pas comme vous méritent de se faire détruire en place publique.

Et aux femmes, aux noobs, aux curieux, et à tous ceux qui ne sont pas ces clones qui se marrent à chaque blague sexiste, sachez que la tech, elle est à tout le monde.

Elle l'a toujours été d'ailleurs.

Franchement, je vous le dis, moi je trouve ça triste parce que ce milieu, moi je l'aime, j'y suis depuis le tout début, probablement bien avant eux et le voir se transformer en cour de récré pour mecs aigris incapables de gérer leurs émotions, et voir surtout que ça empire d'année en année, bah ça me fout le cafard.

Ah et si mon article vous a donné la rage et que vous voulez me casser la gueule, c'est probablement parce que vous vous êtes bien bien reconnu en 4K UHD Dolby Atmos avec les sous-titres et que vous venez de comprendre que vous n'êtes pas ce gars altruiste que vous pensez être... Déso / pas déso 😘 hein.

Contrairement à ce que dit Yann Barthès, on n'est pas tous égaux face à la canicule. Et l'autre truc face auquel on n'est pas tous égaux non plus, c'est le déverrouillage biométrique de son ordi. On les connaît les Linuxiens qui regardent avec jalousie leur collègue sous Windows qui déverrouille sa machine d'un simple coup d'œil à la webcam. Eux, ils sont obligés de taper leur mot de passe de 56 caractères et ça leur fout la rage, alors ils vont sur Reddit pour dire du mal de tous ceux qui n'ont pas de restes de frites collés dans la barbe.

Mais je vais apaiser cette haine en vous parlant aujourd'hui de BioPass , un projet open source signé thaitran24 et phucvinh57, deux devs réunis sous la bannière TickLabVN.

Ce qu'ils veulent faire, c'est amener enfin sous Linux l'équivalent de Windows Hello. BioPass vous connecte à votre session, à un sudo ou à tout service qui passe par PAM avec votre visage ET votre empreinte digitale.

Jusqu'ici la référence sur Linux c'était Howdy , qui fait du visage uniquement, en ligne de commande, et que les développeurs eux-mêmes décrivent comme un peu à l'abandon (sur openSUSE le paquet n'est carrément plus maintenu). C'était chiant à configurer en plus, alors que BioPass lui, propose une vraie interface graphique pour gérer tout ça.

Le module qui parle à PAM est écrit en C++17 et fait tourner trois modèles en local via ONNX Runtime : YOLO pour détecter le visage, EdgeFace pour le reconnaître, et MobileNetV3 pour l'anti-spoofing. Les devs ont d'ailleurs viré les grosses dépendances type PyTorch et OpenCV au profit d'ONNX, histoire de garder un truc léger.

Au moment où votre OS réclame une authentification, BioPass le voit et démarre un processus isolé nommé biopass-helper qui s'occupe de la capture de votre minois et de l'inférence derrière pour vous reconnaître.

Et puis surtout, le point qui compte vraiment quand on parle biométrie c'est que tout reste en local. Y'a vraiment aucune empreinte de votre doigt ou cartographie de nos tronches de cakes qui partent faire du tourisme chez AWS ou Azure.

BioPass gère bien la détection de fausse présence avec une caméra infrarouge (supportée depuis la version 1.1), et la dernière mouture exige même que toutes les méthodes anti-spoofing activées valident, mais sans caméra IR, en se reposant sur le seul modèle d'IA, un visage peut potentiellement se laisser amadouer par une photo bien placée.

Ça reste le talon d'Achille classique de la biométrie, et on a déjà vu pire ailleurs, genre Windows Hello dont le visage devenait copiable sur une clé USB , ou ce laptop Dell qu'on déverrouillait avec un oignon , donc prenez-le plutôt comme un outil de confort plutôt que pour quelque chose qui renforce la sécu de votre Linux.

Pour tester, il y a des paquets .deb et .rpm sur les releases GitHub, et un paquet AUR biopass-bin pour les gens sous Arch. Ah et il vous faudra un capteur d'empreintes pour la partie doigt. Une webcam classique suffit pour la reconnaissance faciale, mais sans caméra infrarouge l'anti-spoofing reste encore une fois, fragile donc gardez ça en tête.

Le projet est sous licence MIT, et la prochaine grosse étape annoncée c'est carrément l'authentification vocale.

Krystian Pierz, un développeur polonais qui se planque derrière le pseudo Kruszoneq, en a eu marre de se galérer à chaque fois pour faire des clés USB bootable pour Mac, alors il a sorti macUSB , une app Mac native (du vrai Swift, pas un machin Electron quoi) qui fait tout le sale boulot à votre place. C'est gratuit, le code est ouvert, et surtout c'est notarisé par Apple, donc pas besoin de bidouiller la sécurité de votre Mac avec Sentinel pour la lancer.

Et ça se fait en trois clics. Vous balancez votre image (un .dmg, un .app d'installation macOS, ou même un .iso), vous désignez votre clé USB, et macUSB se débrouille pour calculer le checksum, détecter la version et l'architecture, formater le support dans le bon système de fichiers et écrire le tout en vous affichant la vitesse en temps réel. Pas de Terminal, pas de commande à rallonge à recopier sans se tromper d'un espace, et surtout l'Utilitaire de disque qu'on déteste tous reste fermé.

Le vrai exploit de Kruszoneq c'est surtout qu'il a réussi à régler les cas de figure où createinstallmedia, l'outil officiel d'Apple, se crashait comme une merde. Je pense que si vous avez déjà essayé de vous faire une clé Monterey ou Big Sur depuis un Mac Silicon par exemple, pour réparer un autre Mac Intel, vous avez dû vous galérer avec des erreurs de validation et autres messages d'erreur pour cause d'architecture incompatible.

Bah macUSB contourne tout ça tout seul comme un grand, et répare même les certificats expirés des installeurs High Sierra et Mojave sans rien vous demander.

Pour situer le progrès, la méthode "propre" côté Apple ressemble à ça :

sudo /Applications/Install macOS Sequoia.app/Contents/Resources/createinstallmedia --volume /Volumes/MaCle

...et encore, à condition d'avoir déjà récupéré le bon installeur dans l'App Store. Je ne vous parle même pas de l'époque où il fallait extraire à la main le fichier InstallESD.dmg planqué dans le paquet de l'installeur (j'expliquais déjà ce bricolage en 2011 pour OSX Lion ). Alors que macUSB, lui, embarque un téléchargeur qui va chercher les installeurs directement sur les serveurs d'Apple. Vous n'avez plus rien à préparer en amont.

L'outil sait donc préparer des clés USB de macOS Tahoe (la version 26, celle de cette année) jusqu'à Tiger 10.4 sorti en 2005, PowerPC compris. Oui, vous pouvez ressusciter un iMac G5 depuis votre MacBook M4. Pour les collectionneurs de vieilles machines, les labos qui gardent des Macs d'époque, ou juste pour remettre d'aplomb un ordi que vous comptez revendre, c'est du bonbon ^^.

Et la v2.3, sortie hier, en remet une couche côté Windows puisqu'elle sait également préparer des clés Windows 10 et 11 en contournant le check TPM 2.0 (le compte Microsoft obligatoire avec la connexion Wi-Fi forcée pendant l'installation, argh !). Et elle écrit aussi les images Linux en .iso et en .img. Après si c'est juste faire une clé Windows depuis votre Mac que vous cherchez, WinDiskWriter fait déjà très bien le job, mais macUSB a l'avantage de tout regrouper au même endroit.

Côté prérequis, votre Mac doit donc tourner au minimum sous Sonoma 14.6 (Apple Silicon ou Intel), et il faudra lui accorder l'accès complet au disque dans les réglages système, rien d'anormal puisqu'il écrit directement sur vos volumes. Une fois ça réglé, vous récupérez le .dmg sur la page des releases GitHub , ou vous l'installez en une ligne avec Homebrew :

brew install --cask macusb

C'est super impressionnant pour un projet développé par une seule personne et qui plus est n'a que 6 mois d'existence. Bref, si vous avez un Mac à réinstaller, un vieux coucou à dépanner ou une machine à remettre d'aplomb avant de la revendre, foncez !

Afska, le développeur derrière une flopée d'outils pour Game Boy Advance, a eu avec son studio [r]labs une idée géniale ! Ça s'appelle EmuDevz, et c'est un jeu vidéo dans lequel vous devez coder votre propre émulateur NES. Et pas en cliquant sur des boutons comme un loser, hein mais en pissant du vrai code pour le processeur, la puce graphique et la puce audio de la console de Nintendo.

Le bidouilleur Starlarkus vient de sortir son nouveau projet, le GB-Link USB V2 qui n'est ni plus ni moins qu'un petit adaptateur permettant de brancher une VRAIE Game Boy sur le net.

Le truc se fait passer pour un câble link tout ce qu'il y a de plus normal, et la console n'y voit que du feu. D'un côté y'a le port link de la Game Boy, de l'autre un port USB-C que vous branchez sur un ordi ou un smartphone Android. Et là, tout passe ensuite par le navigateur en WebUSB. Vous ouvrez une page web et vous pouvez retrouver un autre joueur et enfin échanger des Pokemon comme en 1999 ou vous mettre sur la gueule avec un Tetris, tout ça à distance.

Un dev prénommé Yllan vient de sortir OS9Map , une application qui affiche OpenStreetMap directement sur Mac OS 9. Oui, je parle bien du système d'exploitation de 1999 qui ronronnait sur nos vieux PowerPC.

Pour l'installer, c'est un bon vieux fichier .sit à décompresser (StuffIt Expander sur la machine d'époque, The Unarchiver si vous passez par un Mac moderne), et il vous faudra un PowerPC sous OS 9 avec 16 Mo de RAM (32 recommandés) et une connexion qui passe par Open Transport. Une fois lancé, vous avez alors une recherche d'adresses qui tape dans Nominatim, le moteur de géocodage d'OpenStreetMap, et vous pouvez mettre vos endroits favoris en signets pour y revenir d'un clic depuis le menu. Bref, un vrai petit client carto !

Et c'est là que je trouve ça beau puisque 16 Mo de RAM pour afficher une carte mondiale interactive, c'est très peu. Pour vous situer, un seul onglet Chrome aujourd'hui c'est plusieurs centaines de Mo, donc faut saluer l'exploit d'Yllan.

Maintenant si l'idée d'une carte minimaliste vous parle, dans le genre bien dépouillé j'avais aussi joué avec MapSCII qui balance le monde entier en ASCII dans un terminal. OS9Map joue dans une autre cour, mais on retrouve un peu la même philosophie.

Le truc qui rend tout ça possible, c'est évidemment OpenStreetMap qui propose toutes ses données en accès libre ! Alors rien que pour ça, merci à OpenStreetMap et ses contributeurs.

Et puis si vous n'avez plus de PowerPC qui traîne au grenier, vous pouvez quand même goûter à OS 9 dans votre navigateur via Infinite Mac .

OS9Map est en version 1.0.0 et se télécharge gratuitement sur le site de yllan .

À tous les nostalgiques de la Nintendo 64 et notamment de Super Mario 64, j'ai un petit truc cool à vous montrer. Tobi Friedly vient de sortir un portage du jeu sur Nintendo DS, et pas n'importe lequel, puisque celui-ci tourne sur la vraie console de 2004, et pas seulement sur la DSi qui embarquait quatre fois plus de mémoire vive. Et comme si ça suffisait pas, il y a même mis un mode deux joueurs.

C'est vrai que le truc qui coince d'habitude, c'est que la DS originale n'a pas assez de RAM pour charger toute la ROM du jeu d'un coup. Tobi a donc contourné le problème en faisant streamer les assets à la demande via NitroFS , le système de fichiers des cartouches DS.

Du coup, au lieu de tout balancer en mémoire d'un bloc, le jeu va piocher les niveaux et les textures au fur et à mesure qu'il en a besoin. C'est grâce à cette méthode ingénieuse qu'il a pu débloquer son portage sur la vraie DS, là où le portage précédent de Hydr8gon restait coincé sur DSi faute de place.

C'est d'ailleurs grâce au boulot de Hydr8gon que Tobi a construit le sien, en le modifiant et en l'adaptant suffisamment pour qu'il tourne sur tous les modèles de DS.

Au passage il a rebouché aussi deux bugs qui traînaient, et maintenant le jeu est finissable à 120 étoiles, et le son fonctionne enfin (avant c'était silence radio). La stabilité générale a aussi pris un bon coup de polish.

Le mode multijoueur, lui, réclame deux DS, chacune avec sa propre copie du jeu. C'est du coop local, parfait pour explorer le château à deux ou juste pour déconner ensemble, entre moustachus, dans un niveau de Mario.

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 ^^.

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.

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

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