Ldfa

J'utilise Debian Linux sur tous les serveurs que je possède (5 mini PC et 5 Raspberry dans mon Homelab) ou loue (2 serveurs dédié chez OVH), pour la sécurité et la stabilité, depuis plusieurs années. J'utilise Linux Mint sur mon PC portable pour la simplicité et les performance sur vieux modèle. J'utilise GLF OS en double boot sur mon PC principal, pour jouer principalement. Je pense avoir essayé toutes les distributions Linux existantes. La 1ère version de Linux que j'ai installé était une Slackware en version 0.1 sur un Amaiga 500 équipé d'un 68030, dans les années 90...

Pour en apprendre plus sur la musique du groupe Angine de poitrine.

Je ne connaissais pas et c'est après avoir découvert les vidéos du groupe Angine de poitrine que je l'ai découverte !

@Morgan12 pour lancer ce nouveau sujet de discution qui m'intéresse particulièrement.

Je termine encore Platine cette semaine ici aussi.

Je termine encore Platine cette semaine.

Mistral Vibe serait le plus respectueux : https://www.clubic.com/actualite-619279-cocorico-le-francais-mistral-ai-est-le-vrai-bon-eleve-sur-la-collecte-des-donnees-catastrophe-pour-meta-ai.html

Korben Publié le 29 juin 2026 Par Korben, Manuel Dorne korben.info Environ 3 minutes de lecture Je ne suis pas très client des livres audio parce que mon cerveau, en général, part faire des trucs dans son coin et je me retrouve à rien écouter du tout. Je préfère un petit podcast où ça rigole qu'une œuvre littéraire qui demande de la concentration. Mais je sais que vous appréciez beaucoup les livres audio et il arrive très souvent qu'un bouquin n'ait pas sa version audio. Un vieux roman qui n'est plus édité, un PDF technique, une fanfiction de 800 pages, un article de korben.info ou juste un truc que personne chez Audible ne prendra le temps d'enregistrer parce que ça n'intéresse que vous. Mais youpi, Finrandojin, un internaute, en a eu marre d'attendre l'audiobook de ses rêves et a codé Alexandria, un générateur de livre audio qui tourne 100% en local sur votre ordi. Vous balancez un fichier .txt, .md ou .epub, dans l'appli, puis un LLM découpe le texte et annote chaque ligne avec le personnage qui parle et la manière dont il le dit, puis le moteur Qwen3-TTS joue le tout en local comme une vraie troupe de doubleurs professionnels. Et le résultat est assez propre, même si ça ne vaut pas encore un vrai enregistrement fait par un vrai humain. M'enfin, faute de mieux, pourquoi pas ! Et surtout, ce LLM qui fait le découpage, vous le branchez où vous voulez. En local via LM Studio ou Ollama, ou dans le cloud avec OpenAI ou n'importe quelle API compatible. Ensuite, une fois le script annoté, Alexandria vous propose 9 voix pré-entraînées avec contrôle de l'émotion et du ton. Vous pouvez aussi cloner une voix à partir de 5 à 15 secondes d'échantillon, ou carrément en fabriquer une à partir d'une simple description écrite. Vous tapez par exemple "Une voix masculine chaude et grave, au ton calme et posé" (c'est ma voix quoi...lol) et hop, il vous la fabrique. La fonctionnalité de génération de personnas fait également gagner un temps de dingue puisqu'en un clic, le LLM analyse le bouquin, invente une description de voix pour chaque personnage, génère l'audio de référence et assigne tout automatiquement. Et pour les obsédés du détail, il y a même un éditeur web où vous regénérez n'importe quelle ligne individuellement, du training LoRA pour vous fabriquer des voix persistantes, et un export en MP3 en pistes séparées pour bidouiller ça ensuite dans Audacity, ou en M4B chapitré qui rentre direct dans Audiobookshelf, Apple Books ou VLC. Et tout ça bien sûr, dans une dizaine de langues, français compris. Alexandria exigera par contre une carte graphique avec 8 Go de VRAM au minimum, 16 et plus si vous voulez du débit correct. Et si vous êtes sur Mac, mauvaise nouvelle, l'accélération MPS d'Apple Silicon n'est pas encore supportée, donc ça tournera en mode CPU, donc ce sera lent. Mais c'est pas très grave, vous lancez la génération, et vous retournez lire d'autres articles sur mon site pour passer le temps. Même galère aussi pour les gens qui ont de l'AMD sous Windows. Les chanceux par contre, ce sont les possesseurs de NVIDIA sous Windows ou Linux et les AMD sous Linux. Maintenant si vous tenez juste à faire parler votre Mac sans y passer trois heures par chapitre , vous serez mieux servi ailleurs qu'avec Alexandria. Pour l'installation, le plus simple passe par Pinokio en deux clics, et si vous n'avez pas le GPU qui va bien, il y a un notebook Google Colab pour tourner sur un T4 gratuit dans le navigateur. Comptez quand même un téléchargement de 3,5 Go pour les modèles TTS à la première utilisation, ils ne sont pas inclus dans l'install. Vous l'aurez compris, c'est du DIY un peu gourmand en GPU, mais pour tous vos ebooks à écouter qui n'auront jamais de narrateur, ça ouvre les perspectives ! Le code est sous licence MIT et je vous invite quand même à tester avec un chapitre avant de vous lancer dans un roman entier. Source Afficher l’article complet

Je me suis permis également de poster l'annonce sur le FI qui est moribont depuis quelques temps... https://forum.maxthon.com/d/5573-maxthon-pc-7528600

Changements principaux : - Correction d'un problème empêchant la synchronisation des notes Maxnote présentant des structures particulières. - Correction d'un problème empêchant la prise en compte simultanée des modifications effectuées dans la barre latérale de Maxnote et dans la fenêtre contextuelle des notes. - Correction d'un problème d'affichage avec Uumail dans la barre latérale. - Correction d'un problème de sécurité lié aux vérifications d'autorisations lors de la consultation de mots de passe en texte clair dans Passkeeper. - Correction d'un problème empêchant la fonction « Enregistrement rapide d'image » d'enregistrer une image avec un nom de fichier vide.

Maxthon 7.5.2.8600 Bêta pour Windows est sorti aujourd'hui, il apporte son lot de nouvelles fonctionnalités, d'améliorations et de corrections de bugs. Téléchargement : https://github.com/maxthon/Maxthon/releases/tag/7.5.2.8600 Les changements en français sont là. Vous pouvez également vous abonner au groupe Telegram NBdomain & MX6 pour faire remonter vos demandes d'améliorations et bugs rencontrés. Source : https://forum.maxthon.com/d/5573-maxthon-pc-7528600

Geeek.org Publié le 27 juin 2026 Par Ludovic Toinel geeek.org Environ 11 minutes de lecture J'ai pour habitude de présenter mon portfolio comme tout le monde : une page, une bio, quelques liens. Cette fois, j'ai eu envie de quelque chose de moins sage. Terminal.com[1] est un portail personnel qui prend la forme d'un terminal en plein écran : vous y arrivez, une fausse connexion SSH s'établit, le motd s'affiche, et la main vous est rendue. À partir de là, tout se visite à la commande. Au départ, l'objectif était purement esthétique : retrouver l'allure d'un terminal phosphore, écran vert type CRT avec sa pluie de caractères façon Matrix, ou monochrome ambré, scanlines, grain et curseur qui clignote. Puis le projet a dérivé vers quelque chose de plus intéressant : reproduire le fonctionnement réel d'un shell, entièrement côté navigateur, et lui greffer une capacité d'intelligence artificielle locale. C'est cette seconde partie qui m'a occupé le plus longtemps, et dont je veux vous parler ici. Tester directement, sans rien installer (un navigateur récent compatible WebGPU suffit) : Démo complète du terminal : https://ludovic.toinel.com/ webllmfit, pour savoir quels modèles votre machine peut charger : https://ludovic.toinel.com/webllmfit/ miaougpt, le chatbot : https://ludovic.toinel.com/miaougpt/ denree, l'agent autonome (alias ?) : https://ludovic.toinel.com/denree/ glaude, l'usine à sites façon 1997 : https://ludovic.toinel.com/glaude/ Un shell complet, sans serveur Le site est statique. Il est construit avec Astro[2] et Tailwind CSS, sans framework JavaScript côté client pour le rendu : tout le poids fonctionnel tient dans un moteur de shell maison. Le point que je trouve le plus satisfaisant, cela reste le faux système de fichiers. Ce n'est pas une simulation en mémoire : c'est une véritable arborescence sur disque, dans un dossier root/, que le build parcourt pour générer l'arbre de fichiers et le registre des commandes. Chaque commande est un simple fichier Markdown dans root/bin/. Pour comprendre comment, il faut s'arrêter une seconde sur une notion que peu de monde connaît en dehors des habitués des générateurs de sites statiques : le frontmatter. Le frontmatter, c'est un petit bloc de métadonnées placé tout en haut d'un fichier texte, délimité par deux lignes de trois tirets, et rédigé le plus souvent en YAML sous forme de paires clé/valeur. Le corps du document vient ensuite. Cette convention, héritée d'outils comme Jekyll puis reprise par Hugo, Astro et beaucoup d'autres, permet au générateur de lire le titre, la date ou les tags d'un article sans que ces informations ne se mélangent au contenu lui-même. La plupart des gens qui écrivent en Markdown ignorent jusqu'à son existence, alors qu'ils en croisent presque à chaque fois qu'ils touchent à un site statique. Dans Terminal.com, je détourne ce mécanisme pour décrire mes commandes. Le frontmatter porte le nom, la description, d'éventuels alias, une page de manuel, et un bloc js qui est exécuté si la commande est dynamique. Une commande sans js affiche simplement son corps Markdown. Voici par exemple la commande date au complet : --- name: date desc: date et heure js: | ctx.line(new Date().toString()); --- Ajouter une commande revient donc à déposer un fichier Markdown, et le moteur la découvre toute seule. Ce bloc js reçoit un objet ctx qui expose tout ce dont une commande a besoin : les arguments, des fonctions d'affichage, des aides de temporisation, la saisie interactive, la navigation dans l'arborescence, et les mutations persistantes du système de fichiers (les mkdir, touch et rm sont conservés par navigateur dans le localStorage). Côté commandes intégrées, j'ai cherché à couvrir l'essentiel d'un shell : navigation et manipulation de fichiers (ls, cd, cat, tree, find, grep), identité système (whoami, uname, su, theme), réseau (nslookup, ping, checkip, weather), un peu de crypto pour le plaisir (base64, sha256sum, et même un hashcat qui force du MD5 en multicœur via les Web Workers), sans oublier l'historique persistant, l'autocomplétion au Tab et l'édition de ligne à la Ctrl+A/E/U/K/W. Il y a aussi une commande msg qui m'envoie une notification Web Push, pratique pour recevoir un mot d'un visiteur même sans onglet ouvert. Un point de vigilance côté sécurité : les commandes dynamiques s'exécutent via AsyncFunction, donc une forme d'eval. La politique de sécurité de contenu déployée est une couche de durcissement, pas un bac à sable, puisqu'elle doit autoriser unsafe-eval pour le moteur. Il ne faut donc charger que des commandes de confiance. C'est un compromis assumé pour un portail personnel mono-auteur. Le pari : embarquer un LLM dans le terminal La vraie originalité du projet, cela tient au mécanisme de chargement de LLM. J'utilise WebLLM[3], le moteur d'inférence du projet MLC qui exécute des modèles de langage directement dans le navigateur, accéléré par WebGPU[4], sans serveur et sans appel réseau pour l'inférence. L'API est compatible OpenAI, ce qui simplifie beaucoup l'intégration. Plutôt que de laisser chaque commande gérer son moteur dans son coin, j'ai centralisé toute la mécanique dans un module unique, propriétaire exclusif du moteur WebLLM. C'est le seul endroit qui télécharge les poids, conserve le moteur résident, lance les générations et comptabilise les tokens. Les commandes ne touchent jamais directement au moteur : elles passent par une façade qui leur fournit la demande de consentement et la barre de progression dans le terminal. L'état courant (modèle chargé, tokens consommés en entrée et en sortie, progression du téléchargement) vit sur un emplacement global et alimente un widget en haut à droite de l'écran. D'où viennent les modèles, et comment ils sont chargés Le moteur WebLLM lui-même, je l'héberge sur mon propre serveur, dans un fichier /vendor/web-llm-<version>.js d'environ 6 Mo. Il n'est pas embarqué dans la page : je le charge à la demande, par import dynamique, la toute première fois qu'une commande réclame un modèle, puis je le conserve pour la durée de la session. Tant que vous ne touchez à aucune commande d'IA, rien n'est téléchargé. Le catalogue des modèles, lui, est celui que WebLLM fournit par défaut, à savoir son registre prebuiltAppConfig. Lorsque vous confirmez un modèle, le moteur va chercher deux choses sur le réseau : les poids quantifiés, au format MLC, depuis Hugging Face (l'organisation officielle mlc-ai[5]), et la bibliothèque de calcul compilée pour WebGPU, un fichier WebAssembly fourni par le projet MLC. Une fonction de rappel sur la progression alimente la barre que vous voyez défiler dans le terminal. Les deux ressources sont ensuite rangées dans le cache du navigateur. Le second chargement du même modèle devient donc instantané et fonctionne hors ligne. Point important pour la confidentialité : ce téléchargement initial est le seul moment où le navigateur sort sur le réseau. L'inférence, elle, se déroule intégralement en local, sans le moindre appel vers un serveur. Quelques détails d'implémentation dont je suis assez content : Aucun modèle n'est chargé par défaut. Au premier usage, la commande propose un modèle et vous demande de confirmer son téléchargement. Rien ne part sans votre accord. Le module choisit automatiquement la bonne quantification selon votre carte graphique : il interroge l'adaptateur WebGPU et retient q4f16 si la fonctionnalité shader-f16 est disponible, sinon q4f32. Et si un GPU annonce le support f16 mais échoue à compiler les shaders, il bascule en q4f32 en repli. Les modèles sont mis en cache dans le navigateur. Une fois téléchargé, un modèle est réutilisé instantanément, y compris hors ligne, et je fournis de quoi lister et purger ce cache via la commande llm. Le modèle résident est partagé. Si vous l'avez chargé pour une commande, les deux autres le réutilisent sans rien retélécharger. Reste une question très concrète : quel modèle votre machine peut-elle réellement charger ? J'y réponds avec une commande dédiée, webllmfit, inspirée de llmfit.org, dont je vous parlais dans un précédent article, mais branchée sur le vrai catalogue WebLLM. Elle sonde les capacités WebGPU de la machine (l'adaptateur, le support de shader-f16, les tailles maximales de buffers) ainsi qu'une estimation de la mémoire disponible, puis croise ces informations avec la VRAM requise et les fonctionnalités exigées par chaque modèle. Chacun reçoit alors un verdict : FIT lorsqu'il tient confortablement, TIGHT lorsqu'il passe de justesse, NO lorsqu'il est trop gros ou réclame une fonctionnalité GPU absente. La liste est triée pour faire remonter en premier le plus gros modèle exécutable. Le budget mémoire reste une estimation, car les navigateurs n'exposent pas la VRAM totale, mais cela donne une idée fiable avant de lancer un téléchargement de plusieurs gigaoctets. Et pour piloter tout cela à la main, il y a la commande llm, qui sert de console au module central. Sans argument, elle affiche le modèle actuellement chargé et les tokens consommés en entrée et en sortie. llm --list énumère les modèles conseillés, llm --load <id> en charge un explicitement, et llm --unload libère la mémoire GPU. C'est aussi par elle que l'on change de modèle en cours de route, ou que l'on gère le cache du navigateur : llm --cache liste ce qui est stocké, llm --rm supprime un modèle et llm --rm-all vide tout. Les opérations de cache ne réclament d'ailleurs pas WebGPU et fonctionnent dans n'importe quel navigateur. L'argument qui me plaît le plus dans cette approche : vos échanges avec le modèle ne quittent jamais votre machine. Pas de serveur d'inférence, pas de clé d'API, pas de donnée envoyée ailleurs. Trois exemples de commandes pour démontrer les capacités de WebLLM Pour montrer ce que cette base permet, j'ai écrit trois commandes très différentes, du chatbot trivial à l'agent autonome. miaougpt, le chatbot de terminal miaougpt est le cas le plus simple : un chat en mode terminal. Vous écrivez, l'assistant répond, jeton par jeton en streaming. Il a une légère personnalité féline, glisse un miaulement de temps en temps, et répond dans votre langue. J'y ai ajouté la synthèse vocale via la Web Speech API : /voice fr-FR fait lire les réponses à voix haute. Le modèle par défaut est un Qwen2.5 1.5B, suffisant pour discuter. Denree, l'agent autonome appelé par "?" Denree est l'expérience la plus ambitieuse : une architecture d'agent capable de piloter les commandes du shell. Le nom est un clin d'œil à la Denrée, l'extraterrestre de La Soupe aux Choux[6]. Vous lui donnez un objectif en langage naturel, et il demande au modèle de choisir, étape par étape, quelle commande lancer. Il exécute la commande, lit sa sortie, la réinjecte dans le contexte, et recommence jusqu'à produire une réponse finale. Je l'ai associé à l'alias ?, donc on l'appelle très naturellement : ? comment créer un fichier ? quelle est mon ip Faire raisonner correctement un petit modèle de 1,5 milliard de paramètres a demandé plusieurs astuces que je détaille volontiers, parce que ce sont elles qui font la différence entre un agent qui boucle et un agent qui répond : À chaque tour, la décision du modèle est contrainte en JSON par génération guidée par schéma. L'agent ne part jamais en vrille : il renvoie toujours soit une commande à lancer, soit rien. Un mini-RAG lexical, un BM25 allégé en JavaScript pur sur les pages de manuel, sélectionne les commandes les plus pertinentes pour l'objectif et injecte leur syntaxe exacte dans le contexte. Un petit modèle devine très mal les options d'une commande ; lui rappeler le bon SYNOPSIS évite la majorité des boucles. La réponse finale n'est pas demandée au modèle pendant la boucle, mais extraite par une étape de synthèse séparée à partir des sorties réellement obtenues, avec une consigne stricte de ne rien inventer ni convertir. C'est ce qui rend le résultat fiable malgré la taille du modèle. Une liste d'interdiction protège l'utilisateur : les commandes à effet de bord ou de contrôle (rm, su, sudo, msg, open, et les commandes d'IA elles-mêmes) sont bloquées pour l'agent. Glaude, la note d'humour Glaude est plus léger, et complètement assumé comme tel. C'est une parodie de Claude Code, incarnée par le Glaude, le paysan bourbonnais du même film. Il en reprend l'allure, bannière, boîte d'accueil, invite ›, mais sa spécialité est de pondre des sites web volontairement hideux et flashy : fonds fluo, dégradés arc-en-ciel, Comic Sans, balises <marquee>, texte qui clignote, emojis partout. L'esthétique GeoCities de 1997, en somme. Au lancement, il amorce un projet sous votre répertoire personnel, comme le ferait un vrai agent de code, écrit un index.html de départ, puis vous laisse lui décrire la page. Un /show ouvre un faux navigateur pour admirer le carnage, et un /download empaquette le tout en archive ZIP, le tout en JavaScript pur. Il s'appuie sur des modèles Qwen2.5-Coder. En synthèse Ce projet m'a surtout servi de terrain d'apprentissage sur l'IA locale. Faire tourner un modèle dans un onglet est désormais réaliste : WebGPU est disponible par défaut dans les versions récentes des principaux navigateurs, même s'il reste prudent de détecter sa présence et de prévoir un repli. Les modèles de quelques milliards de paramètres restent modestes, et c'est précisément ce qui rend l'exercice formateur : pour qu'un agent soit utile à cette échelle, il faut compenser par l'ingénierie, la contrainte de format, le RAG sur la documentation, la séparation entre décision et synthèse. J'attends d'ailleurs avec une certaine impatience le courriel triomphant de la personne persuadée d'avoir piraté mon serveur parce qu'elle a vu défiler la connexion SSH, tapé quelques commandes et décroché un prompt root avec un su. Je la remercie par avance pour son rapport : ce shell n'est qu'une simulation, il tourne intégralement dans son propre navigateur, et derrière, il n'y a justement aucun serveur à compromettre. Le tout est sous licence MIT et le dépôt est conçu pour être réutilisable : l'identité et la configuration tiennent dans un seul fichier, et le contenu visitable vit dans l'arborescence root/. Si vous voulez en faire votre propre portail terminal, ou simplement aller demander à Denree quelle est votre adresse IP, le code et la démo sont en ligne. Notes et références Terminal.com, dépôt du projet sur GitHub : https://github.com/ltoinel/Terminal.com ↩︎ Astro, le générateur de site statique utilisé : https://astro.build ↩︎ WebLLM, moteur d'inférence LLM dans le navigateur (projet MLC, licence Apache 2.0) : https://github.com/mlc-ai/web-llm ↩︎ WebGPU, l'API d'accès au GPU dans le navigateur (documentation MDN) : https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API ↩︎ Hugging Face, organisation officielle mlc-ai, où sont publiés les modèles au format MLC chargés par WebLLM : https://huggingface.co/mlc-ai ↩︎ La Soupe aux choux, film de Jean Girault (1981), d'où sont tirés le Glaude et la Denrée : https://fr.wikipedia.org/wiki/La_Soupe_aux_choux ↩︎ Afficher l’article complet

Bonjour, je pense que cet article devrait pouvoir t'aider : https://www.seomix.fr/prix-site-wordpress/

Je termine encore Platine cette semaine ici aussi.

Je termine encore Platine cette semaine.