Il semble se passer quelque chose de grave dans l'écosystème open-source de Ruby, notamment au niveau des Ruby Gems.
Malheureusement je ne connais pas suffisamment Ruby pour en comprendre les tenants et aboutissants, mais cet article factuel devrait vous aider à y voir plus clair.
Il semble se passer quelque chose de grave dans l'écosystème open-source de Ruby, notamment au niveau des Ruby Gems.
Malheureusement je ne connais pas suffisamment Ruby pour en comprendre les tenants et aboutissants, mais cet article factuel devrait vous aider à y voir plus clair.
Pour en avoir testé quelques uns, je trouve que les lecteurs de livres audio, c’est jamais très pratique à utiliser. Heureusement, je viens de découvrir Lue , un lecteur d’e󠄳󠅕󠄐󠅤󠅕󠅨󠅤󠅕󠄐󠅕󠅣󠅤󠄐󠅣󠅟󠅥󠅣󠄐󠅓󠅟󠅠󠅩󠅢󠅙󠅗󠅘󠅤󠄐󠅔󠅕󠄐󠄻󠅟󠅢󠅒󠅕󠅞󠄞󠅙󠅞󠅖󠅟books qui lit vos livres à voix haute directement dans le terminal.
Bah oui, moi j’adore mon terminal.. Pas besoin de cliquer, pas d’interface laggy, pas de pub ni d’abonnement premium… On lance juste une commande et hop, la lecture du livre se lance. C’est ça que j’aime, quand la tech me fout la paix et fonctionne bien !
Le truc cool avec Lue, c’est que l’outil utilise Edge TTS de Microsoft par défaut. Oui, Microsoft qui fait un truc bien et gratuit, c’est foufou, mais en gros, ça permet de récupérer les voix ultra réalistes utilisées dans Edge sans payer un centime et sans même avoir Windows. Après si vous êtes un parano de la vie privée, vous pouvez aussi utiliser Kokoro TTS qui tournera à 100% en local sur votre machine.
Pour installer Lue, il vous faut d’abord FFmpeg, espeak et Antiword. Sous Mac c’est donc brew install ffmpeg espeak antiword``, et sous Linux sudo apt install ffmpeg espeak antiword, et sous Windows… bah vous allez sur le site de FFmpeg, espeak et antiword et vous galérez un peu comme d’hab.
Et après, c’est tout simple :
Connexionpip install git+https://github.com/superstarryeyes/lue.git
Et voilà, vous êtes prêts à transformer votre terminal en studio d’enregistrement de livres audio. Pour lancer la lecture d’un bouquin, c’est aussi simple que :
lue votre-livre.epub
Perso, j’aime beaucoup la synchronisation mot par mot que permet l’outil… Car pendant que la voix lit, le texte se surligne en temps réel dans le terminal. C’est hypnotisant, on dirait un karaoké pour rats de bibliothèques. Après vous pouvez mettre en pause avec p, ajuster la vitesse de lecture, naviguer dans les phrases avec j et k. C’est comme vim mais pour les oreilles.
Alors je sais que le TTS c’est pas toujours foufou, mais je vous invite à en tester plusieurs pour trouver celle qui vous plait le plus. Moi ma préférée, c’est fr-CH-ArianeNeural qui est hyper propre et assez classe. Vous pouvez lancer une lecture avec la voix comme ceci :
lue --voice "fr-CH-ArianeNeural" livre.epub
Voici la liste complète des voix disponibles que vous pouvez utiliser :
Et Lue lit vraiment tout : EPUB, PDF, TXT, DOCX, HTML, RTF, et même le Markdown. La lecture PDF c’est particulièrement bien foutue parce qu’il retire automatiquement les numéros de page et les en-têtes qui pourrissent toujours la lecture audio.
Voilà, Lue c’est un coup de cœur car on commence vraiment à s’habituer à des services IA avec des technologies de synthèse vocale qui rivalisent avec des vrais humains, mais c’est souvent caché derrière des APIs payantes et des interfaces merdique. Et là arrive un développeur qui dit “non mais attendez, c’est quoi ce bordel ?? Je vais vous faire un truc simple qui marche”.
Et hop !
La progression de lecture est même sauvegardée automatiquement. Vous fermez votre terminal en plein milieu du chapitre 12, vous relancez le lendemain, et hop, ça reprend pile où vous en étiez. Très cool, hein ?
Bref, si vous êtes du genre à préférer la ligne de commande aux interfaces clinquantes, ou si vous voulez juste écouter vos ebooks sans vous prendre la tête, allez tester Lue dispo sur GitHub .
Et encore un article un peu technique pour finir la journée en beauté ! Si je vous disais que votre serveur Linux pouvait gérer 10 exaoctets de données sans broncher ? Vous ne me croiriez pas je pense… D’ailleurs c’est quoi 10 exaoctets ?? Et bien ça correspond à 10 millions de To. C’est pas mal hein ?
Hé bien c’est exactement ce que permet de gérer TernFS, le système de fichiers qu’XTX Markets vient de libérer après trois ans d’utilisation intensive. XTX Markets est une boîte d’algo-trading qui brasse 250 milliards de dollars par jour et j’avoue que c’est un joli cadeau de presque-Noël qu’elle vient de nous faire…
D’après ce qu’ils expliquent sur leur site , NFS et les autres solutions classiques ne tenaient plus la charge face à leurs 650 pétaoctets de données utilisées leur machine learning. Alors ils ont fait ce que font les vrais geeks, ils ont codé leur propre solution… et après trois ans de production sans perdre “un seul octet”, ils ont tout balancé en en open source sur GitHub .
Le truc génial avec TernFS, c’est qu’il a été pensé pour les fichiers immuables, vous savez, ces gros datasets de plusieurs gigaoctets qu’on écrit une fois et qu’on relit des milliers de fois pour entraîner des modèles. Pas de modification après création, pas de prise de tête avec les locks et la cohérence. C’est simple et efficace.
L’architecture repose sur quatre composants principaux qui bossent ensemble : les metadata shards (256 shards logiques pour gérer les métadonnées), le CDC (Cross-Directory Coordinator) pour les opérations entre répertoires, les block services pour stocker les données, et un registry pour orchestrer tout ce petit monde. Le tout communique en UDP/TCP avec du Reed-Solomon pour l’erasure coding et du CRC32-C pour vérifier l’intégrité. Bref, ça semble être du solide.
Et les chiffres qu’ils donnent sur leur production sont assez dingues. Ils parlent de 500+ pétaoctets répartis sur 30 000 disques durs et 10 000 SSD, dans 3 datacenters différents, avec des débits qui montent à plusieurs téraoctets par seconde en vitesse de pointe. Et leur système gère ça tranquille, avec du multi-région natif et une tolérance aux pannes qui ferait pâlir d’envie n’importe quel admin sys.
Si ça vous chauffe, pour installer TernFS, c’est du classique. Vous clonez le repo, vous lancez ./build.sh alpine ou ./build.sh ubuntu selon votre distrib, et c’est parti. Il y a un module kernel Linux pour gratter les perfs maximales et toucher les étoiles, mais vous pouvez aussi utiliser FUSE si vous préférez rester en userspace. Ils ont même implémenté une API S3 pour ceux qui veulent migrer depuis AWS sans tout réécrire.
git clone https://github.com/XTXMarkets/ternfs
cd ternfs
./build.sh alpine
# Et pour tester en local
./scripts/ternrun
Par contre, attention aux limitations ! Car TernFS n’est pas du tout fait pour les petits fichiers (genre les millions de fichiers de 1KB d’un projet Node.js). C’est vraiment optimisé pour du gros volume du style datasets ML, logs d’applications, archives, ce genre de trucs. Et y’a pas de système de permissions intégré non plus, car ils ont préféré garder ça basique et laisser chacun implémenter sa propre couche de sécurité.
Ils ont mis au point également un système de “block proofs” où chaque bloc de data a une preuve cryptographique qui permet de vérifier que le client n’a pas corrompu les données avant de les écrire. Ça évite qu’un client bugué ou malveillant ne pourrisse tout le filesystem. Ils ont aussi un système de “scrubbing” automatique qui détecte et remplace les secteurs défaillants sur les disques.
Chouette non ?
D’après Bloomberg , XTX Markets investit actuellement 1 milliard d’euros dans de nouveaux datacenters en Finlande. Avec leurs 25 000 GPUs (dont 10 000 A100 et 10 000 V100) et maintenant TernFS en open source, ils montrent surtout qu’ils ne rigolent pas avec l’infrastructure. C’est pas pour rien qu’ils arrivent à traiter un trillion d’enregistrements par jour pour leurs algos de trading.
Leur code est disponible sous double licence à savoir GPLv2+ pour le core et Apache 2.0 avec exception LLVM pour les bibliothèques client et les définitions de protocole. Ça permet d’intégrer TernFS dans à peu près n’importe quel projet, commercial ou non.
Bref, si vous gérez des pétaoctets de données et que ZFS commence à tirer la langue, TernFS vaut vraiment le coup d’œil. Reste à voir si d’autres géants du big data vont l’adopter ou si ça restera un outil de niche pour les vraiment gros volumes, mais avec l’explosion du Machine Learning et des LLMs, je parie qu’on va en entendre parler de plus en plus…
Et si votre serveur Linux était comme un appart en coloc où tout le monde partage la même cuisine, le même salon, les mêmes chiottes ?? Forcément, ça finit toujours mal avec quelqu’un qui monopolise les toilettes pendant que vous avez une urgence en spray, un autre fait crasher la machine à laver avec ses expérimentations douteuses de voyage dans le temps, et au final personne n’est content.
Hé bien figurez-vous qu’un développeur nommé Cong Wang de Multikernel Technologies vient de proposer une solution radicale qui consiste à donner à chaque processus son propre kernel Linux, avec ses propres core CPU, comme des colocataires qui auraient enfin chacun leur studio…
Selon le patch soumis sur la Linux Kernel Mailing List (LKML), cette architecture “multikernel” permettrait de faire tourner plusieurs noyaux Linux indépendants sur la même machine physique. C’est pas vraiment de la virtualisation classique façon VMware ou KVM, mais c’est plutôt comme si vous découpiez votre ordinateur en tranches et que chaque tranche vivait sa vie. Le truc marrant, c’est que Cong Wang n’est pas un petit nouveau qui débarque avec ses idées folles. Le bonhomme a déjà contribué à plus de 1000 patches au noyau Linux et il maintient le sous-système de traffic control . Autant dire qu’il sait de quoi il parle quand il touche au code du noyau.
D’ailleurs cette idée de séparer les kernels rappelle furieusement le projet Barrelfish que Microsoft Research et l’ETH Zurich avaient lancé il y a quinze ans. À l’époque, ils voulaient traiter l’OS comme un système distribué où chaque core CPU aurait son propre kernel qui communique avec les autres par messages. Sauf que voilà, c’était trop tôt. Les processeurs n’avaient pas assez de cores pour qu’on puisse se permettre ce genre de luxe, et puis franchement, qui avait besoin de ça en 2009 ?
Aujourd’hui avec nos CPU à 128 cores et nos problèmes de sécurité qui explosent, l’idée prend soudainement tout son sens.
Selon Phoronix et les patches sur la LKML, l’implémentation de Wang utilise kexec, ce mécanisme qui permet normalement de redémarrer directement dans un nouveau noyau sans repasser par un reboot. Sauf qu’ici, au lieu de remplacer le noyau existant, on en charge plusieurs qui vont cohabiter. Chaque kernel se voit attribuer ses propres cores CPU et ils communiquent entre eux via un système d’interruptions inter-processeurs (IPI) spécialement conçu pour l’occasion. Et dans les 7 patches proposés en RFC, Wang prévoit des mécanismes de surveillance pour gérer tous ces petits mondes parallèles.
Et pendant que Cong Wang bricolait son multikernel dans son coin, les géants du cloud comme Amazon, Microsoft et Google ont développé en parallèle une technologie appelée KHO ( Kexec HandOver ) qui permet de préserver l’état système lors du changement de kernel. En gros, ils veulent pouvoir mettre à jour le noyau Linux de leurs serveurs sans perdre les VMs qui tournent dessus. Sauf que si le multikernel de Wang fonctionne vraiment, ça pourrait rendre leur stack de virtualisation complètement obsolète.
Car pourquoi s’embêter avec des hyperviseurs complexes quand on peut juste donner à chaque workload son propre kernel ?
Le plus drôle dans tout ça, c’est que Wang admet candidement dans son RFC que pour l’instant, ça marche “que sur sa machine de dev avec des paramètres hardcodés”.
Maintenant si cette techno décolle, on pourrait voir des trucs assez dingues. Genre un kernel temps réel qui gère les processus critiques pendant qu’un kernel classique s’occupe du reste. Ou alors des kernels spécialisés pour différents types de workloads : un pour le machine learning, un pour les bases de données, un pour le réseau. Vous pourriez même imaginer des kernels avec différents niveaux de sécurité du genre un kernel ultra-paranoia pour vos données sensibles et un kernel plus relax pour Netflix. Et le plus beau c’est que si un kernel plante, les autres continuent de tourner tranquillement.
C’est comme avoir plusieurs systèmes de secours intégrés directement dans la machine.
Mais attention, on parle quand même d’une RFC, et pas encore d’un truc prêt pour la prod. La communauté des barbus du noyau va probablement passer des mois à débattre de chaque ligne de code, et c’est tant mieux parce que toucher à l’architecture fondamentale de Linux, c’est pas comme patcher un bug dans Firefox. Si ça merde, c’est potentiellement des millions de serveurs qui partent en vrille.
Au final, que ce patch soit accepté ou pas, ça montre surtout que Linux continue d’évoluer de manière radicale pour toujours aller plus loin ! Et si vous l’évolution de ce projet, tout se passe sur la LKML .
SwitchToOpen a pour ambition de devenir une référence centralisée d’outils open source, permettant aux particuliers, professionnels et organisations de s’affranchir des solutions propriétaires dans de nombreux domaines : cybersécurité, infrastructure, bureautique, développement, gestion, etc.
Quelques exemples de projets web qui s'affichent comme « open source » alors qu'ils dépendent de leur propre code sous licence propriétaire non ouverte, avec les réponses des auteurs lorsque cette question leur a été posée.
Un service auto-hébergeable pour faire votre propre Netflix à la maison avec vos fichiers : interface moderne et réactive, applications disponibles (desktop, Kodi, Android, etc.), reprise des films ou épisodes là où on en était, récupération automatique des méta-données (sélection manuelle du bon film si confusion, ou édition manuelle), possibilité d'ajouter des sous-titres externes si le conteneur média n'en contient pas, transcodage (très important si codecs variés et pas forcément reconnus sur tous les appareils), limitation de bande-passante, etc.