Si vous avez déjà branché un stockage externe sur votre Nextcloud et regardé occ files:scan ramper en mode larve durant des plombes lors d'une indexation, vous connaissez le coupable.

C'est évidemment un dossier node_modules qui contient des dizaines de milliers de tout petits fichiers, qui se fait indexer dans la base de Nextcloud, faisant tout ramer jusqu'à l'infini (ou presque...).

Heureusement, Marc Palaus a repris le vieux plugin files_excludedirs (lancé à l'origine par Roeland Jago Douma, puis passé de fork en fork) et l'a remis d'aplomb pour Nextcloud 32 à 34. Le taf de ce plugin c'est tout simplement d'ordonner à Nextcloud d'ignorer purement et simplement les dossiers que vous lui indiquez.

Donc si vous lui donnez ce pattern, il esquivera tout ce qui correspond :

occ config:app:set files_excludedirs exclude \
--value '[".snapshot","node_modules","cache/*/tmp"]'

Un tableau JSON, un pattern par entrée, et vous pouvez glisser des wildcards comme cache/*/tmp pour taper plusieurs sous-dossiers d'un coup.

Ensuite, pour voir ce qui tourne, occ config:app:get files_excludedirs exclude. Ou si vous préférez cliquer, l'app propose aussi un menu Exclude Directories dans les réglages admin, avec un bouton Preview Changes pour voir ce que vous allez virer avant de valider.

Pour les fichiers qui n'ont pas encore été indexés, c'est nickel donc. Mais pour ceux qui sont déjà dans la base, cette exclusion les rendra inaccessibles mais ils seront toujours là à traîner dans les résultats de recherche.

Alors pour les dégager pour de bon, voici quelle ligne de commande vous devez lancer :

occ files_excludedirs:clean-cache --dry-run

J'ai mis un dry-run en paramètre, parce que ça permet de faire tourner ça à blanc sur quelques résultats, sans flinger la mauvaise arborescence. Mais une fois que vous êtes chaud patate et sûr de vous, vous devrez relancer la même commande sans le --dry-run.

Notez que si vous montez par exemple un partage genre "Shared/Holiday" directement à la racine d'un utilisateur, vos fichiers ont un chemin du style photo.jpg, et pas Shared/Holiday/photo.jpg. C'est le chemin complet qu'il faudra viser donc...

En tout cas, j'ai été surprise d'apprendre qu'exclure des dossiers du scan, c'est une demande qui traîne sur le tracker Nextcloud depuis l' issue #6888 publiée en 2017... Ça existait pourtant côté ownCloud. Dommage quoi.

Pour installer ce plugin, vous récupérez l'archive sur la page Releases, vous décompressez dans nextcloud/apps, vous activez depuis l'admin. Ou alors un petit git clone + un composer install pour la version source et le tour est joué !

Et si la lourdeur de Nextcloud vous gonfle plus globalement, il y a des alternatives plus légères comme OpenCloud .

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 .

Si vous faites tourner un petit serveur gratuit chez Oracle, je vous invite prestement, comme dirait Godefroy, à aller vérifier votre compte. Car oui mes amis, Oracle vient de diviser par deux son offre "Always Free" sur les machines ARM, et ils l'ont fait sans prévenir personne. Bouuuuuh ! Cela veut dire que leur fameuse bécane gratuite à 4 cœurs ARM (Ampere A1) et 24 Go de RAM, celle que la moitié de la communauté self-hosting fait tourner pour héberger son site web, son VPN ou son petit lab , est officiellement passée à 2 OCPU et 12 Go de mémoire .

La tristesse m'envahit... snif.

Cela veut donc dire que si vous avez une instance configurée en 4 OCPU / 24 Go, vous êtes dorénavant au-dessus de la limite gratuite. Vous devrez donc rapidement la redimensionner à 2 OCPU / 12 Go, et ça, ça prend 5 à 10 minutes.

Pour ce faire, il faudra vous rendre sur l'affreux dashboard d'Oracle Cloud. Vous ouvrez alors votre instance, Actions puis More actions puis Edit. Vous dépliez la ensuite la section Shape du VM.Standard.A1.Flex, vous mettez 2 OCPU et 12 Go, vous sauvegardez et vous validez le reboot comme des bonhommes, lol.

Ouais, faut redémarrer le VPS, puis se reconnecter dessus en SSH, et c'est réglé. Le guide de Viren070 détaille ce redimensionnement vers 2 OCPU pas à pas si vous voulez être un peu plus tenu par la main.

Et si vous ne touchez à rien parce que balek frrr ??? Et bien si votre compte est en Pay-As-You-Go, tout ce qui dépassera la nouvelle limite gratuite risque de vous être facturé, d'après les retours d'utilisateurs qui ont contacté le support Oracle. Et si vous êtes sur un compte purement gratuit, c'est l'instance elle-même qui peut être stoppée ou récupérée par Oracle. Bref, dans les deux cas, mieux vaut s'en occuper soi-même que de découvrir le problème en mode facture surprise ou disparition de serveur.

Je trouve quand même que le plus gênant dans cette histoire, c'est le silence d'Oracle. Ils n'ont fait aucune annonce ni aucun mail aux clients. Les gens s'en sont rendus compte simplement parce que la page de doc a changé... D'ailleurs, au moment où j'écris ces lignes, le simulateur de coûts d'Oracle affiche encore 0 € pour une instance 4 OCPU / 24 Go, ce qui me laisse penser que la facturation réelle pourrait se déclencher possiblemenet un peu plus tard.

Personne ne sait exactement quand le couperet tombera en fait et c'est ça le souci...

Petite précaution au passage, si vous redimensionnez, sur ARM, Oracle est en permanence à court de capacité... Donc quand vous éteignez votre instance pour la reconfigurer, rien ne vous garantit que vous récupérerez vos cœurs au reboot. Ils peuvent très bien partir à quelqu'un d'autre donc si vous tenez plus à votre machine qu'à vos propres gosses, passez le compte en Pay-As-You-Go avant de la redimensionner. Cela vous permettra de réduire le risque de le voir se faire dégommer.

Et voilà comme un bout d'offre "Always Free" (ce qui veut dire en français, "Toujours gratuit", je me permets de le souligner en toute subtilité QUAND MÊME) vient de prendre fin... Après c'est un peu logique parce que 4 cœurs ARM offerts à vie, c'était plutôt généreux dans le monde dans lequel on vit.

Mais bon, diviser leur offre par deux sans prévenir, en laissant notamment les comptes Pay-As-You-Go se prendre potentiellement une claque en facture alors qu'ils n'ont pas été prévenu, c'est pas un move que la communauté des adorateur du grand Oracle va apprécier je pense...

Bref, si vous avez une instance ARM chez Oracle, allez la vérifier maintenant parce que 5 petites minutes de resize aujourd'hui valent mieux qu'une facture surprise demain...

Source

Si vous hébergez vos propres services derrière une IP dynamique, vous connaissez sans doute des outils merveilleux comme DynDNS, NoIP, ou encore Cloudflare DDNS.

Sauf que dès que votre homelab mélange du Docker, du Proxmox et un cluster Kubernetes, ça devient vite le bordel à maintenir ! Mais Maxfield Allison, un contributeur du projet OPNsense, qui visiblement en avait marre lui aussi de gérer tout ça à la mimine, nous a pondu dnsweaver .

dnsweaver, ça fait pas repousser les cheveux sur les sysadmins (désolé ^^) mais c'est un outil en Go qui peut se lancer comme un service et qui se configure avec la clé API de votre Cloudflare (ou d'un autre provider) pour mettre à jour sa zone DNS. Comme ça, quand l'un de vos conteneurs démarre avec un label Traefik, hop, l'enregistrement DNS apparaît automatiquement. Et quand vous le virez, il disparaît.

C'est génial parce que ça vous permet de ne plus jamais toucher à votre zone DNS à la main.

Et une fonctionnalité incroyable de dnsweaver, c'est le split-horizon DNS qui permet de donner accès à votre réseau local et à ses services depuis n'importe où sur Internet, mais avec la bonne tête selon d'où vous vous connectez. Vous aurez grâce à ça, votre bitwarden.maison.fr qui pointe vers le 192.168.1.10 quand vous êtes chez vous sur le réseau local, et vers votre IP publique quand vous tapez la même adresse depuis l'extérieur. Comme ça, plus la peine de maintenir 2 configs séparées qui finiront toujours par diverger à un moment...

Et dnsweaver ne se contente pas d'un seul fournisseur et ça c'est cool. Comme ça, si vous voulez allier la puissance des services de Cloudflare (pour le cache, la sécurité, la protection DDoS...etc.) à, par exemple, un Technitium perso pour votre réseau interne, bah c'est possible ! dnsweaver pousse comme ça vers 7 backends en parallèle: Technitium, Cloudflare, Pi-hole, AdGuard Home, dnsmasq, le bon vieux RFC 2136 (pour BIND, PowerDNS ou le DNS de Windows Server) et même un webhook pour brancher un truc maison.

Côté détection, vous aurez capté, ça va lire les labels Traefik, Caddy ou nginx-proxy sur vos conteneurs Docker, les annotations Ingress sur Kubernetes, et côté Proxmox il récupère vos VMs (via l'agent QEMU) comme vos conteneurs LXC. Très cool donc pour les furieux qui gèrent plein d'instances sur différents serveurs !!

Pour l'installer, maintenant vous avez le choix: Soit vous passez par l'image Docker maxamill/dnsweaver, le registre ghcr.io ou un chart Helm si vous êtes plutôt team Kubernetes. Vous lui passez les credentials de vos providers (via des secrets Docker ou Kubernetes, et pas en clair dans un fichier qui traîne comme un gros nooooobbzzzz) et vous le laissez tourner. Il expose même des métriques Prometheus, du coup vous le surveillez comme le reste de votre stack.

Alors oui, je saiiiis, ExternalDNS fait déjà ce genre de boulot, sauf que c'est du Kubernetes only. Alors que dnsweaver, lui, avale les trois plateformes d'un coup, ce qui colle pile poil à l'ADN même du homelab bordélique que vous avez chez vous ^^.

Le projet est encore assez récent et porté par une seule personne mais ça évolue à une vitesse impressionnante (déjà des dizaines de versions livrées en quelques mois), alors je vous recommande de tester ça quand vous aurez 5 min (pas en prod tout de suite par contre, promettez le moi, bande de fifous !!)

Voilà, si gérer votre DNS maison vous bouffe un temps de dingue, dnsweaver est à envisager (pas comme votre cousin.e, donc... )

Grasp , c'est une alternative décentralisée à GitHub, signée DanConwayDev, le dev derrière ngit. Ça carbure à Nostr , le protocole décentralisé de fiatjaf, et l'idée avec ce truc, c'est que votre identité de dev, ce n'est plus un compte avec un email et un mot de passe, mais juste une paire de clés cryptographiques qui ne dépend de personne. Vous publiez votre code depuis le terminal, sans avoir à vous inscrire nulle part et pi c'est tout !

Vous me connaissez, j'adore fureter à la recherche de petits outils cools à partager avec vous, et niveau décentralisation, celui-là vaut le détour. Pour tester, ça se passe avec l'outil nak . Vous créez votre dépôt, vous le synchronisez, vous poussez comme ceci :

nak git init --owner <votre-clé-npub> --identifier mon-projet --name "Mon Super Projet" --description "Mon premier repo Grasp"
nak git sync
nak git push

Pour cloner le dépôt de quelqu'un d'autre, c'est nak git clone <npub-du-maintainer>/mon-projet, et pour lui envoyer un patch, nak git patch send HEAD^. Pas de fork ni de pull request à remplir dans une interface pour contribuer au code des autres... C'est beau non ?

Derrière, tout repose sur Nostr et sa spec NIP-34 qui transforme un dépôt, une issue ou un patch en messages signés que n'importe quel serveur peut relayer. Du coup chaque état de votre code est signé par votre clé, et comme ça, vos dépôts migrent d'un serveur à l'autre sans rien perdre. Impecc si vous ne faites pas confiance aux hébergeurs.

La vraie différence avec un Forgejo ou un Gitea que vous auto-hébergez, c'est donc que vous ne créez pas un compte sur chaque instance. Votre identité Nostr vous suit partout, une seule clé pour tous les serveurs ! À ne pas confondre par contre avec Radicle , qui fait du P2P local-first avec son propre protocole gossip et Git en natif (et pas sur IPFS, contrairement à ce qu'on lit souvent, le vrai GitHub-sur-IPFS ce serait plutôt GitLike ).

Grasp, lui, parie sur l'interopérabilité : plusieurs clients, plusieurs serveurs, un seul standard, et tout communique.

Et l'écosystème est déjà bien debout avec ngit-grasp comme serveur de référence, pyramid pour gérer une communauté, viewsource.win pour visualiser le code dans le navigateur, et gitworkshop.dev pour une interface complète façon GitHub.

Maintenant ce n'est pas non plus la solution miracle, car c'est encore un peu trop jeune à mon goût... Mais c'est à tester car le jour où l'un de ces frontends web deviendra vraiment carré et grand public, il pourrait bien venir taquiner GitHub, et ça, c'est plutôt une bonne nouvelle...

Comme beaucoup d'âmes en peine, vous utilisez les messages enregistrés sur Telegram comme un gros dépotoir pour stocker tous vos fichiers en vrac ?

C'est pas con, mais pour retrouver un PDF précis ou streamer une vidéo là-dedans, c'est vite la galère... Mais no stress, aujourd'hui, on va voir comment s'en sortir.

L'idée c'est d'utiliser l'infrastructure de Telegram pour transformer votre compte en un espace de stockage personnel organisé. Et pour cela, il existe une application, développée en Tauri avec du Rust et du React, qui se nomme Telegram Drive et qui se connecte directement à votre compte et affiche une interface d'explorateur de fichiers classique. Vos canaux privés et vos messages enregistrés deviennent alors de simples dossiers et voilà comment Telegram devient enfin une alternative intéressante aux solutions de stockage en ligne traditionnelles.

Gardez cependant en tête qu'il s'agit d'une zone grise. En effet, l'utilisation de l'API de Telegram pour du stockage massif enfreint en théorie leurs conditions d'utilisation, et vous risquez de voir votre compte suspendu en cas d'abus.

Côté fonctionnalités, l'outil propose donc du drag-and-drop pour uploader vos fichiers, une grille capable de gérer des milliers d'éléments sans ramer, et de l'affichage de vignettes pour vos images.

Le truc sympa, c'est surtout la possibilité de streamer vos vidéos et vos fichiers audio directement depuis l'application sans les télécharger, ou encore de lire vos PDF grâce à un lecteur intégré. Notez que le système respecte la limite classique imposée par Telegram, à savoir 2 Go par fichier pour les comptes gratuits et jusqu'à 4 Go si vous êtes abonné Premium.

Maintenant, pour organiser vos dossiers, il vous faudra créer un canal privé pour chacun d'eux afin de structurer au mieux le bazar. Et pour les bidouilleurs qui aiment automatiser leurs flux de travail avec des scripts, l'outil propose même une API REST locale sécurisée.

Niveau réseau, l'application intègre des optimisations pour les connexions instables ou lentes, notamment un module spécifique pour régler la taille des blocs de transfert, sans oublier le support des proxys SOCKS5 et MTProto, donc ça fonctionnera au top, que vous soyez en 4G dans le métro ou sur un Wifi pourri.

Pour faire tourner le client sur votre ordi, le projet propose des exécutables pour Windows, macOS et Linux. Ah et y'a même une version pour Android. Maintenant, si vous préférez compiler les sources à la main, il faudra installer Rust avant de lancer la compilation via npm.

Ensuite, pour connecter l'application au réseau, il faudra récupérer vos propres identifiants API (API ID et API Hash) auprès de Telegram et ensuite, cette configuration restera stockée localement sur votre machine dans un bon vieux fichier config.json.

Perso, je trouve que détourner Telegram en espace de stockage personnel est une idée plutôt cool. L'avantage, c'est que vos données transitent directement de votre machine vers les serveurs de la messagerie, sans passer par un serveur tiers ou un conteneur Docker hébergé ailleurs. Mais après, c'est comme d'hab, ça ne vous appartiendra plus vraiment... Poutine va kiffer vos photos de vacances ^^

Mais le mieux pour se faire un avis reste de l'essayer, comme d'hab !

Merci à Camille Roux pour le lien !

Vous connaissez le duo Prometheus et Grafana ? C'est le grand classique pour surveiller ses serveurs, mais configurer tout ce bazar et le garder propre, c'est vite l'enfer. Alors pour ceux qui veulent juste garder un oeil sur leur homelab plutôt que de perdre le peu de cheveux qu'il leur reste à configurer Grafana durant des heures, j'ai trouvé pour vous Beszel .

Beszel est un outil de monitoring de serveurs ultra-léger et surtout super simple à mettre en place. Le projet est tout récent et développé en Go, ce qui permet d'avoir des binaires minuscules et une consommation de ressources ridicule

Donc si vous cherchez un outil de monitoring Linux self-hosted aussi simple à prendre en main que Kula dont je vous ai déjà parlé, ça vaut le coup d'aller jeter un oeil.

La mécanique de Beszel repose sur deux morceaux, à savoir le hub et l'agent. Le hub, c'est l'interface web construite au-dessus de PocketBase, qui sert de tableau de bord centralisé quant à l'agent, lui, il tourne discrètement sur chaque machine à surveiller et remonte les métriques au hub. "Discrètement", ça veut dire qu'il consomme à peine 10 à 15 Mo de RAM donc c'est parfait pour le faire tourner sur une vieille machine ou un tout petit Raspberry Pi sans que ça tousse-tousse !

Le truc vraiment cool aussi, c'est la gestion native des conteneurs Docker. Au lieu de simplement suivre l'état général comme avec un outil de suivi des processus classique (je pense à pstop par exemple), il liste chaque conteneur et affiche sa consommation individuelle en CPU, mémoire et réseau. Donc pour tous ceux qui auto-hébergent des dizaines de services, c'est un pur bonheur.

Côté métriques, y'a aussi tout ce qu'il faut pour ne rien louper. L'outil permet de suivre la consommation CPU, la mémoire (incluant le swap et le ZFS ARC), l'espace disque, les entrées/sorties réseau, la moyenne de charge et même la température des composants. En 15 secondes, tout s'affiche proprement.

Il gère aussi des trucs plus poussés comme la santé des disques via les données S.M.A.R.T., l'état de la batterie et même la consommation de vos cartes graphiques Nvidia, AMD ou Intel. Attention, pour le S.M.A.R.T. et le GPU par contre, il faudra que vous installiez les utilitaires système correspondants sur la machine hôte (smartmontools, nvidia-smi...) pour que l'agent puisse remonter les infos.

Et la configuration ? Hé bien c'est un simple fichier docker-compose.yml et voilà c'est plié !

Lors du premier lancement du hub, vous devrez vous créer un compte administrateur, puis cliquer sur "Ajouter un système", et l'interface vous génèrera une clé publique. Il suffira ensuite de filer cette clé à votre agent via sa variable d'environnement (dans son docker-compose.yml, par exemple) et les deux copains commenceront à causer. C'est pas plus compliqué que ça ! Même un notaire pourrait le faire ^^.

Le hub intègre également une gestion multi-utilisateur bien foutue puisque chaque utilisateur peut avoir accès à ses propres machines, tandis que l'administrateur peut décider de partager certains systèmes. Si vous voulez sécuriser le tout, l'outil supporte aussi de nombreux fournisseurs OAuth2 et OIDC comme Google, GitHub ou Keycloak, et vous pouvez même couper complètement la connexion par mot de passe.

Beszel s'occupe aussi des sauvegardes automatiques de vos données de surveillance, en local ou directement sur un stockage compatible S3. Et pour les alertes, pas de panique, car l'outil est compatible avec Shoutrrr . Cela vous permettra de configurer des notifications par Discord, Telegram, Teams ou mail si le CPU s'affole ou si un disque commence à saturer.

Par contre, si vous cherchez un outil d'analyse de logs complet ou de détection de bug réseau ultra-précis, laissez tomber car c'est pas la "mission de vie" de Beszel. Sauf si bien sûr, vous le couplez avec un autre outil. Après pour le reste, c'est parfait.

Vous pouvez tester la version v0.18.7 en vous rendant sur le site officiel .

Si vous avez un homelab, il vous arrive peut-être parfois de vous retrouver en galère parce qu'en essayant de caser un énième serveur dans votre baie, vous réalisez, trop tard, qu'il vous manque deux unités ou que le switch est monté à la mauvaise profondeur. Heureusement, Gareth Evans, un dev qui devait galérer avec exactement le même souci, a sorti Rackula , un outil open source qui vous laisse dessiner le rack de votre homelab en glisser-déposer, avant de sortir la carte bleue.

Vous attrapez des équipements à la souris, vous les empilez dans votre rack virtuel, et vous voyez immédiatement ce qui rentre ou pas. Et c'est plutôt joli puisque les façades des machines qu'on peut voir dans l'outil ne sont pas des dessins génériques. Elles viennent de la NetBox devicetype-library , la grosse base communautaire qui référence les vraies façades avant de tout un tas de matos (Dell, Ubiquiti, Supermicro…). Grâce à ce truc, votre rack virtuel ressemblera donc à votre vrai rack, et pas à un schéma chelou fait en Lego.

Pour l'installer, rien de plus simple. Soit vous passez par la démo web, soit vous l'auto-hébergez en une commande Docker :

docker run -d -p 8080:8080 ghcr.io/rackulalives/rackula:latest

Votre designer de rack tournera alors sur le port 8080. Ce qu'il vous faut donc, c'est juste un endroit pour faire tourner Docker , genre un VPS, un NAS Synology , un Raspberry Pi ou une VM Proxmox ... Bref ce que vous avez déjà sous la main.

Une fois votre baie dessinée, vous l'exportez en PNG, PDF ou SVG, ou vous partagez carrément un lien (ou un QR code) à vos potes. C'est pratique pour par exemple documenter une install ou frimer avec votre setup. Côté technique, c'est codé en Svelte et en TypeScript, et sous licence MIT, donc gratuit et bidouillable à volonté !!

Avant ça, je me souviens, pour documenter un rack ou un réseau, on se débrouillait avec Visio (qui se souvient ??), voire plus récemment avec un vieux template draw.io un peu cheap, ou pire, une photo floue prise au téléphone.

Avec Rackula, le boulot est propre !

Faut juste pas se tromper sur ce que c'est. Rackula. Pour être clair, c'est un outil de visualisation, et pas un DCIM complet. Donc si vous voulez gérer vos adresses IP, votre inventaire ou calculer la conso électrique et le refroidissement de votre baie, il faudra rester sur du NetBox ou du RackTables, un peu plus lourds à déployer. N'oubliez pas non plus que par défaut (tant que vous n'avez pas activé le mode API avec authentification quoi...), tous les schémas que vous créez restent dans le local storage de votre navigateur. Donc si vous videz votre cache, tout partira dans les limbes du grand vide cosmique numérique.

Ce projet est porté par un seul dev assisté de Claude, qui l'assume tranquillement dans ses commits, et y'a même déjà des tutos pour l'installer sur NAS Synology et UGREEN qui traînent sur le net.

Bref, Rackula, c'est l'outil idéal pour ceux qui aiment empiler du serveur et qui veulent un plan propre de leur baie sans se ruiner. Indispensable si vous vous auto-hébergez.

Et merci à j0j0b4rj0 pour le lien !

Monter son propre serveur Git, ça rime souvent avec déployer une usine à gaz bourrée d'options qu'on n'utilisera jamais. Heureusement, Soft Serve prend le contre-pied total de tout ça ! Ce serveur Git self-hosted de charmbracelet (la bande derrière Bubble Tea, Glow, Freeze et Gum) fait sa vie dans le terminal et se pilote via SSH.

Un coup de brew install charmbracelet/tap/soft-serve (ou Docker, ou go install), vous lancez soft serve et hop, vous voilà avec un serveur Git complet qui tourne grâce à un seul binaire. Pour parcourir vos dépôts, pas besoin de navigateur, vous vous connectez juste en SSH et une petite interface en mode texte s'ouvre direct dans votre terminal. Genre ssh git.chezvous.net, et vous voilà en train de naviguer dans l'arborescence, lire les fichiers avec coloration syntaxique, fouiller les commits. Le tout sans quitter le shell !

Créer un dépôt, ça se fait en une ligne :

ssh -p 23231 localhost repo create mon-projet

git remote add origin ssh://localhost:23231/mon-projet
git push origin main

Un iPhone 8 qui dormait dans un tiroir. Hemant Kumar, ingénieur logiciel basé au Canada, l'a ressorti, branché sur un panneau solaire et transformé en serveur de reconnaissance de texte qui tourne sans la moindre interruption depuis maintenant plus d'un an, sans box, sans prise murale, juste le soleil.

L'OCR, c'est la reconnaissance optique de caractères. La techno qui lit une photo et en ressort le texte, brut, copiable. Tout passe par Apple Vision (pas le casque), cette brique d'analyse d'images qu'Apple intègre gratuitement à chaque iPhone et chaque Mac depuis des années et qui exécute ses calculs en local, directement sur le téléphone, sans jamais expédier la moindre image vers un quelconque serveur dans le cloud.

L'appli qui pilote l'ensemble est minuscule. Un programme écrit avec les outils maison d'Apple, réglé sur le mode de reconnaissance le plus précis, correction linguistique activée, et conçu pour ne faire que ça.

Les compteurs, eux, sont énormes. 83 418 requêtes traitées. 48 Go d'images avalées. Et des pointes à plus de 1 000 demandes dans une seule journée quand le projet qui l'alimente tourne à plein régime.

Côté alimentation, l'iPhone est raccordé à une station portable EcoFlow River 2 Pro de 768 Wh, rechargée par un panneau solaire de 220 W posé dehors, et un petit mini PC fait l'aiguilleur en récupérant les requêtes d'un autre projet de Hemant pour les transmettre au téléphone via Tailscale, ce réseau privé qui relie vos appareils entre eux comme s'ils partageaient le même wifi.

Le plus dur n'a pas été le serveur. C'était d'empêcher iOS de mettre l'iPhone en veille et de tuer le programme au bout de quelques minutes, ce que le système fait par défaut pour préserver la batterie.

Et la batterie, justement. Plus d'un an de fonctionnement non-stop, et elle tient encore 76% de sa capacité d'origine, ce qui n'a rien d'évident pour une cellule de 2017.

L'économie, elle, est dérisoire. Environ 10 dollars par mois face à un serveur classique, soit deux à trois ans pour rentabiliser le panneau. Personne ne se lance là-dedans pour le portefeuille.

Le sens du projet est ailleurs. Un appareil promis au tiroir, voire à la benne, se retrouve à abattre un boulot bien réel, en silence et au soleil, là où la plupart d'entre nous auraient simplement sorti la carte bleue pour un service d'OCR hébergé dans le cloud.

Bref, un iPhone 8 qui bosse très bien à la retraite.

Source : Terminal Bytes