L'équipe Next-gen Kaldi de Xiaomi a sorti OmniVoice, un modèle de synthèse vocale qui parle 646 langues et qui est capable de "recopier" une voix à partir d'un extrait de huit secondes minimum. Et tout ça en local et gratuitement !

Le français y est d'ailleurs la cinquième langue du corpus d'entraînement, avec 23 675 heures d'audio de référence sur les 581 000 qu'ils ont avalées. Autant dire que le modèle a entendu du français toute sa vie, et ça s'entend au résultat.

Voilà donc comment cloner votre propre voix, du début à la fin. Comptez 3,3 Go de poids à télécharger la première fois, et quelques minutes de manipulation une fois qu'ils sont sur votre disque.

Installer OmniVoice

Pour cela, il vous faut Python 3.10 ou plus récent, et un environnement isolé (sinon vous allez casser autre chose). Sur Mac, les deux lignes suivantes suffiront puisque le modèle utilise le GPU intégré via MPS :

python3 -m venv ~/omnivoice-env && source ~/omnivoice-env/bin/activate
pip install torch==2.8.0 torchaudio==2.8.0
pip install omnivoice num2words

Sur Linux et Windows, ça devra se faire avec une carte NVIDIA (sous Windows, l'environnement s'active avec omnivoice-env\Scripts\activate) sauf que PyTorch doit venir de l'index CUDA, donc remplacez la deuxième ligne par celle-ci :

pip install torch==2.8.0+cu128 torchaudio==2.8.0+cu128 --extra-index-url https://download.pytorch.org/whl/cu128

Notez que sans carte graphique du tout, ça marche quand même. J'ai rejoué la même installation dans un conteneur Linux en processeur seul, elle passe sans rien changer... mais il m'a fallu cinq fois la durée de l'audio en temps de calcul.

Une fois installé, pour savoir que c'est en place, tapez omnivoice-infer --help et là, la liste des options doit s'afficher, sans la moindre erreur d'import. Le num2words de la troisième ligne, lui, ne sert qu'au chemin Python dont je parle plus bas, alors gardez-le sous le coude.

Les 8 secondes qui font tout

C'est l'étape que tout le monde bâcle et c'est pourtant celle qui est décisive pour avoir un bon résultat. Le projet recommande entre 3 et 10 secondes, pas plus car au-delà, ça ralentit le calcul et ça dégrade le clonage. Prenez donc un passage où vous parlez sans blanc, sans "euh", sans musique derrière, et découpez-le proprement comme ceci avec ffmpeg (ou autre logiciel de votre choix) :

ffmpeg -i mon-enregistrement.m4a -ss 12 -t 8 -ac 1 -ar 24000 moi.wav

La qualité de cet extrait est très importante donc si vous enregistrez votre voix, mettez bien le micro près de la bouche, dans une pièce sans écho, et évitez les MP3 récupéré à partir de YouTube .

Écrivez ensuite dans un fichier ce que dit exactement l'extrait, mot pour mot. Vous pouvez sauter cette étape (le modèle transcrit alors tout seul avec Whisper), sauf qu'il téléchargera 1,6 Go de plus pour ça et qu'il se plante parfois sur un nom propre, ce qui abîme le clonage.

C'est le moment de générer !

Avant de taper quoi que ce soit, relisez bien votre texte et réécrivez les chiffres en toutes lettres. La ligne de commande n'a aucune option de normalisation, donc "2345" sortira n'importe comment alors que "deux mille trois cent quarante-cinq" se lit tout seul. C'est du côté Python que la normalisation se fait, avec normalize_text=True, la langue passée en language="fr" et le num2words de tout à l'heure... sans la langue, votre texte français part chez le normaliseur anglais qui réclamera même une lib sans version précompilée pour les Mac Apple Silicon.

Voici la commande complète :

omnivoice-infer --model k2-fsa/OmniVoice \
 --text "Bonjour, ceci est un test de clonage de voix en français réalisé avec OmniVoice." \
 --ref_audio moi.wav --ref_text "$(cat moi.txt)" \
 --language fr --num_step 32 --output ma-voix.wav

Vous devez voir passer un "Saved to ma-voix.wav" au bout de quelques secondes. Sur mon M4 Max, j'ai compté 4 à 6 secondes de calcul pour 5,4 secondes d'audio, et moitié moins avec --num_step 16 au prix d'un peu de netteté. Au passage, le facteur 40 fois plus rapide que le temps réel qu'annonce le projet sur son site, ça a été mesuré sur un H100 avec des noyaux d'accélération maison, et pas sur un ordi de bureau...

Si la ligne de commande vous rebute, vous pouvez aussi passer par la commande : omnivoice-demo --ip 127.0.0.1 --port 8001 qui permet de faire la même chose mais dans le navigateur, avec le bouton d'import pour l'extrait et un menu déroulant pour la langue. Pensez juste à lancer export GRADIO_ANALYTICS_ENABLED=False avant, parce que l'interface web appelle les serveurs de Gradio au démarrage et qu'on n'a pas envie de leur filer nos data à ceux-là.

L'audio, lui, ne bouge pas de votre machine.

L'extrait de référence de 8 secondes chargé à gauche, la langue calée sur French, et la sortie de 5 secondes à droite une fois le clonage terminé.

Maintenant, une fois que c'est fait, écoutez le fichier avant d'en faire quoi que ce soit, parce que le modèle avale parfois des morceaux de phrase. Sur mes 24 générations de la même phrase, 5 ont perdu ou déformé un mot. C'était presque toujours le premier ou le dernier... et ce n'est pas une surprise, c'est un bug connu de l'outil. Faut donc relancer parfois plusieurs fois pour avoir un résultat OK.

Dernier truc pour ceux qui passeront par Python : la voix se sauvegarde une fois pour toutes. model.create_voice_clone_prompt() puis .save("ma_voix.pt") produisent un fichier minuscule que les sessions suivantes rechargeront sans repasser par l'extrait ni par la transcription. Regénérez alors une phrase avec, et comparez à l'oreille : si c'est bien la même voix, vous pouvez ranger le WAV de référence.

Voici l'extrait que j'ai généré avec ma voix. Ces 6 secondes d'audio ont pris 14 secondes à la génération sur mon Mac Studio :

Auberon López vient de publier sur son blog un bouton qui freeze complètement les Mac à partir d'un simple clic dans un navigateur. Il a baptisé ça le Deathray (le rayon de la mort quoi...) et c'est un shader WebGPU diffusé via une page web des plus ordinaires, qu'il suffit d'ouvrir d'un simple clic sur un lien.

Ce qui arrive ensuite change d'une fois sur l'autre : Vous aurez le doit à la roue multicolore, ou la souris qui se fige, ou encore parfois des saletés magenta sur une partie de l'écran. Le reste de l'ordinateur, lui, va très bien et vous pouvez vous y connecter en SSH depuis une autre machine sans souci. C'est juste l'affichage qui ne répond plus, et il ne reviendra pas sauf si vous rebootez.

Le fait est que macOS surveille également son WindowServer, le processus qui dessine tout ce que vous voyez. S'il ne répond plus pendant deux minutes, le chien de garde déclenche un kernel panic et la machine redémarre ensuite toute seule. Mais vous pouvez aussi appuyer sur le bouton d'alimentation si vous êtes pressé, mais en croisant les doigts pour que votre navigateur ne rouvre pas l'onglet au redémarrage...

Le truc tient dans un seul fichier HTML, et histoire de vous expliquer un peu plus, un compute shader part dans une boucle écrite sans incrément, donc elle ne se termine jamais, et recopie indéfiniment le même vecteur en mémoire. À côté, le vertex shader qui dessine l'image lit alors cette même zone, et comme le premier ne lâche jamais la main, le second ne peut pas avancer d'un pouce.

Sauf que l'embouteillage ne reste pas cantonné au navigateur. Tous les processus qui veulent le GPU se retrouvent alors à patienter derrière, WindowServer compris, d'où l'écran figé. López dit avoir reproduit la chose dans Chrome, Firefox et Safari, sur des MacBook à puce M tournant sous macOS Tahoe. Après sur les autres systèmes testés, l'onglet rame un bon coup, puis tout rentre dans l'ordre dès qu'on ferme la page.

Mais alors pourquoi eux et pas les autres OS comme Windows ?

Hé bien parce que Windows embarque un mécanisme appelé TDR , qui repère qu'une carte graphique met plus longtemps que prévu à répondre et qui la réinitialise pour éviter que tout le système se bloque. Deux secondes par défaut, et le shader qui déconne se fait éjecter.

Alors que sur Apple Silicon, c'est un coprocesseur maison, l'ASC, qui pilote le GPU avec un firmware Apple et qui s'occupe de tout : énergie, ordonnancement des commandes, préemption des tâches. Asahi Lina , qui a retourné la puce M1 pour écrire un pilote Linux , a d'ailleurs relevé que si ce firmware plante, il n'y a qu'un moyen de s'en sortir. La seule solution c'est de redémarrer complètement la machine.

López a signalé le problème à Apple Security fin juillet. Apple a reproduit le bug, annoncé un correctif et donné un calendrier (confidentiel, donc on ne le connaîtra pas). Puis le 26 août, revirement complet d'Apple qui explique ne voir "aucune implication de sécurité dans ce rapport", lequel n'entraînera donc aucun changement dans ses produits. Le dossier est ensuite parti vers une autre équipe pour d'éventuelles "considérations d'amélioration".

En 2023 pourtant, Ron Masas d'Imperva avait déjà fait planter des Mac, des iPhone et des iPad avec un shader, en WebGL cette fois. Apple avait alors sorti le CVE-2023-40441 , noté 6,5 sur 10, et l'avait bouché en renforçant la validation des entrées pour mieux repérer les boucles folles.

Seulement voilà, sa boucle à lui était énorme mais finie, donc détectable, alors que celle du Deathray tourne pour toujours. Et une boucle infinie, la repérer à coup sûr, c'est le problème de l'arrêt ... donc personne ne sait faire.

López l'écrit d'ailleurs sur son site, les chercheurs en sécurité avec qui la question a été discutée donnent plutôt raison à Apple. Pour la firme, le résultat n'est qu'un plantage, un gel ou une perte de données récupérable, et ça ne constitue pas un réel problème de sécurité. Et sur le principe, ça se défend. Sauf que dans la vraie vie, si vous avez oublié de sauvegarder vos fichiers et que vous cliquez sur ce lien, vous l'avez dans l'os (et pas dans le "MacOS"... roh roh roh).

Donc non, il n'y a rien à installer pour empêcher ça et rien à attendre de Cupertino pour le moment. Voilà, sachez juste que n'importe quel couillon qui aura lu cet article pourra vous envoyer un petit lien par mail, façon rickroll des enfers, ce qui aura pour effet de freezer et faire redémarrer votre Mac.

Désolé !! 🤷‍♂️

Source : le billet d'Auberon López .

Vous voulez vérifier un truc dans une vieille version de Python, du genre celle de 2017, histoire de voir si le bug que vous traquez vient de là. Normalement ça veut dire chercher une image Docker ou un vieux binaire de python, pour faire vos tests. Mais avec trynix, vous cliquez un lien et hop, vous avez un shell avec votre outil.

Ce site est signé Farid Zakaria, qui bricole autour de Nix depuis des années et appelle ça son "magnum opus". En gros, une machine Linux x86_64 démarre dans votre onglet, avec le paquet demandé déjà accessible dans le PATH. Rien à installer et pas de compte à se créer, ça marche direct dans le browser.

J'ai essayé ce matin avec python3 en version 3.6.2 . Le navigateur va chercher les chemins du store, vérifie leurs signatures, et au bout d'une trentaine de secondes le prompt s'affiche. Je tape alors python3 --version, il me répond Python 3.6.2, avec la glibc 2.25 et l'OpenSSL 1.0.2l de l'époque livré avec. Et voilà comment je me retrouve avec un Python de 2017 dans un Chrome de 2026, sans rien toucher à ma machine.

Le terminal de la machine virtuelle, dans l'onglet : Python 3.6.2 répond, et les seize chemins du store sont vérifiés juste au-dessus.

Et ce ne sont pas trois démos préparées à l'avance puisque l'index recense les 310 000 et quelques versions que nixpkgs a livrées en treize ans. Toutes ne démarrent pas, attention, il n'y en a que 274 729 avec un binaire x86_64 dans le cache, et le reste est non libre, cassé, ou hors du lot.

Ce qui rend la chose possible, c'est en fait une simple ligne d'en-tête HTTP. Le cache binaire de Nix sert un access-control-allow-origin: *, donc votre navigateur a le droit d'aller y piocher tout seul. Et le plus drôle, c'est que Zakaria avait lui-même réclamé cet en-tête en 2021, pour un tout autre projet. Et 5 ans plus tard, il s'en sert pour démarrer des machines virtuelles... Qui aurait pu prédire comme dirait l'autre !

Pour l'émulation, après il n'a rien réinventé. Il a tout simplement repris prend qemu-wasm , le QEMU compilé en WebAssembly de ktock, et la machine virtuelle ne boote même pas vraiment, mais reprend un instantané figé à l'avance. En tout cas, c'est bien pensé et très pratique.

Du Linux dans un navigateur, je vous avais d'ailleurs déjà montré ça ici avec cette machine virtuelle x86 . Sauf que ces trucs-là chargent une image figée à l'avance, alors qu'ici, on choisit vraiment son contenu en 1 clic.

Niveau vitesse, le projet annonce un lancement en 3 secondes, mais c'est le temps d'obtenir le shell quand tout est déjà dans le cache du navigateur. Chez moi, lors de mes tests, au premier passage, il a fallu 30 secondes, puis 7,5 secondes au suivant. Et une fois dedans ça reste poussif, parce que chaque binaire est traduit du x86 vers le WebAssembly à son premier lancement, ce qui peut faire monter le chargement à deux minutes sur les gros binaires.

Et il y a aussi un plafond puisque tout doit tenir dans la mémoire de l'onglet, soit environ 1,5 Go. Et c'est une console série, donc vous ne pourrez rien lancer de graphique, pas de fenêtre, pas de souris... Bref, que les outils en ligne de commande et rien d'autre ! Mais bon, vous êtes de vrais barbus qui n'ont peur de rien à part du déo, donc je ne suis pas inquiet ^^.

Ce qui est vraiment cool avec Trynix surtout, c'est l'action GitHub que son dev a sortie dans la foulée. Si votre intégration continue pousse déjà ses compilations dans un cache, un bot colle un lien sous la pull request et le relecteur lance le code au lieu de le lire. Comme ça, fini le clone, la compilation et le "*ça marche chez moi pourtant *" invérifiable. Même topo pour faire essayer un truc à quelqu'un qui n'a ni Nix ni Docker... Suffit de lui envoyer le lien.

Un petit point sécu quand même que je tiens à vous signaler : L'URL transporte à la fois les caches supplémentaires et les clés qui les valident, du coup la signature vous prouve bien que le binaire vient du cache annoncé... mais pas qu'il vient de quelqu'un de fiable. En effet, cliquer sur un lien trynix inconnu, ça revient à lancer le programme d'un inconnu, et même si ça se passe dans la sandbox de l'onglet du navigateur (ce qui limite les dégâts), c'est quand même mieux d'en avoir conscience !

Bref, voilà encore un chouette projet sous licence MIT et si ça vous chauffe, ça se passe sur trynix.dev .

Source : Simon Willison

Restic chiffre bien vos sauvegardes, rclone sait parler à 70 services de stockage, mais connecter les deux ensemble demande d'écrire des scripts et surtout de les surveiller. Eh bien bonne nouvelle, Pluton est l'interface web qui fait ce travail à votre place.

Vous y décrivez un plan de sauvegarde via un formulaire, avec une source, une destination, une fréquence, une politique de rétention, et Pluton fabrique les commandes restic derrière. Les sauvegardes restent ainsi incrémentielles et chiffrées avant l'envoi. La destination peut être un disque local, un bucket S3, un Backblaze B2 ou un Google Drive, et le même plan peut se répliquer vers plusieurs stockages pour respecter la fameuse règle 3-2-1.

L'installer

Je vous ai préparé un petit kit IA pour ceux qui ne jurent que par leur agent :

Un dossier, deux fichiers, et c'est parti. Le docker-compose.yml d'abord, dans lequel vous montez ce que vous voulez sauvegarder en lecture seule et le dossier qui recevra les sauvegardes en écriture. Si vous êtes sur Mac, lisez l'avertissement plus bas avant de monter quoi que ce soit, car ce montage-là m'a joué un tour :

services:
 pluton:
 image: plutonhq/pluton:latest
 container_name: pluton
 restart: unless-stopped
 ports:
 - "5173:5173"
 volumes:
 - pluton-data:/data
 - ./mes-documents:/mnt/documents:ro
 - ./mes-sauvegardes:/mnt/backups
 environment:
 ENCRYPTION_KEY: ${ENCRYPTION_KEY}
 USER_NAME: ${USER_NAME}
 USER_PASSWORD: ${USER_PASSWORD}
 NODE_ENV: production
 IS_DOCKER: "true"

volumes:
 pluton-data:

Puis le .env à côté, avec vos trois secrets. Générez-les, ne les inventez pas :

printf 'ENCRYPTION_KEY=%s\nUSER_NAME=korben\nUSER_PASSWORD=%s\n' \
 "$(openssl rand -hex 16)" "$(openssl rand -hex 10)" > .env

Par contre, attention à cette ENCRYPTION_KEY, c'est le point à ne pas rater. Le compose officiel la documente comme la clé de chiffrement des snapshots restic et rclone, et c'est bien ça. Il s'agit du mot de passe de vos dépôts, c'est la même clé pour tous vos plans. Et donc la perdre, c'est perdre vos sauvegardes, et la changer rendra illisible tout ce qui a déjà été écrit. Bref, copiez-la dans votre gestionnaire de mots de passe avant d'aller plus loin, parce que le jour où vous en aurez besoin, personne ne pourra vous la redonner.

Puis faites un :

docker compose up -d

L'interface répond alors sur le port 5173 et vous demande directement les identifiants du .env. Pas d'assistant de première configuration, pas de compte à créer... en fait quand les variables sont bien configurées, Pluton s'installe tout seul au démarrage. Chez moi, entre le up -d et l'écran de connexion, il s'est donc passé moins d'une minute.

Créer le premier plan de backup

Le bouton "+ New" de l'interface ouvre un assistant en quatre écrans. Vous nommez le plan, vous gardez la stratégie "Incremental Backup" (les trois autres sont grisées, elles appartiennent à l'offre Pro), vous pointez /mnt/documents comme source et /mnt/backups comme destination, puis vous réglez la fréquence et la rétention. Le dernier écran laisse le chiffrement et la compression activés et propose de lancer la sauvegarde tout de suite, ce que j'ai fait.

Chez moi, trois fichiers de test de quelques octets sont partis en quelques secondes. Et c'est là qu'il faut regarder la bonne chose pour vérifier que ça fonctionne... Non, c'est pas la pastille verte, mais plutôt le nombre de fichiers et leur taille.

Le plan Documents juste après sa première sauvegarde.

En fait, si je vous dis ça, c'est parce que sur mon Mac, avec Docker Desktop, restic n'arrivait pas à lire les dossiers montés depuis l'hôte, et sort en erreur d'entrée/sortie sur chaque fichier. Et pourtant, Pluton affichait quand même la sauvegarde en vert avec le statut "Complete". Les colonnes disaient bien 0 fichier et 0 octet, mais le statut, lui, semblait correct... Donc si vous êtes sur Mac, prenez plutôt l'installeur de bureau, qui existe aussi pour Windows et Linux, et dans tous les cas vérifiez que les chiffres sont OK après votre première sauvegarde.

Vérifier et répéter une restauration

Votre dossier de destination contient maintenant un config, un data/, un index/, un keys/ et un snapshots/, tous illisibles en clair. C'est un dépôt restic standard, et ça se vérifie sans Pluton, avec le binaire embarqué dans le conteneur :

docker exec -e RESTIC_PASSWORD=votre_cle -e RESTIC_REPOSITORY=/mnt/backups \
 pluton restic snapshots

Vous obtenez la liste de vos snapshots avec leur taille, et avec une mauvaise clé, restic répondra "wrong password or no key found" et s'arrêtera là. Faites les deux essais car ça prouve en une fois que le chiffrement travaille, et que vos données restent récupérables même si Pluton disparaît demain.

Le menu d'une sauvegarde propose ensuite "Browse", qui ouvre le snapshot comme un explorateur de fichiers, avec la taille de chacun et un bouton pour le télécharger ou le restaurer seul.

Le contenu du snapshot, fichier par fichier, avec le téléchargement et la restauration à droite de chaque ligne

Et le "Restore" lancera un assistant qui vaut le détour puisqu'il sait restaurer vers un chemin différent de l'original. Il vous laisse choisir quoi faire des fichiers déjà présents, et surtout il génère un aperçu en dry run (à blanc quoi...) avant de toucher au disque. J'ai restauré mes trois fichiers vers un dossier séparé, puis comparé avec les originaux, et c'était identique. Faites-le une fois, tranquillement, pendant que vous n'en avez pas besoin.

Voilà, tout ça, c'est la version gratuite, pour la machine où elle tourne. Maintenant, si vous voulez piloter les sauvegardes de plusieurs machines depuis la même interface, ça passera par l'offre Pro à 59 dollars par an. Si vous voulez comparer avec un autre truc, sachez aussi que Zerobyte joue dans la même cour.

Amusez-vous bien !

Source : Pluton

Le développeur Mayuki Sawatari vient de publier ReProgman , un clone du Program Manager de Windows 3.1.

Ça ne vous dit rien ? C'est parce que vous êtes des bébés !

En fait, progman.exe, c'est ce truc qui servait d'interface principale à Windows avant que le menu Démarrer ne débarque avec Windows 95. Et aujourd'hui, grâce au taf de Sawatari, ça tourne aussi bien sur Windows 11 que sur macOS.

Pour ceux qui ont commencé l'informatique après 1995, faut savoir qu'avant ça, on n'avait pas de bureau, pas de barre des tâches, mais juste une grande fenêtre grise remplie de sous-fenêtres, et dans chaque sous-fenêtre y'avait des icônes de programmes alignées sur une grille. Vous double-cliquiez sur l'une d'elles, le programme se lançait, et voilà, vous aviez fait le tour de Windows !

Le groupe Main ouvert sur Windows 11, et la rangée de groupes réduits en bas de la fenêtre

Regardez bien les icônes sur cette capture : Docker, Edge et Claude rangés dans une ambiance de 1992...

Car ReProgman ne se contente pas de reproduire la déco. Au premier lancement, il scanne votre menu Démarrer (ou vos dossiers Applications si vous êtes sur Mac), transforme chaque dossier en groupe et range le tout dans son propre fichier Groups.ini. Après ça, il n'y retourne plus tout seul, et ce que vous déplacez, renommez ou supprimez dedans ne redescend jamais vers vos vrais raccourcis. Un menu permet quand même de relancer l'import à la main, et il n'ajoute alors que ce qui manque.

Du coup, vous récupérez les gestes de l'époque pour de vrai. Vous attrapez une icône, vous la lâchez dans une autre fenêtre et elle déménage, avec Ctrl enfoncé elle se copie, le menu Window vous range tout ça en cascade ou en mosaïque, et les fenêtres réduites redeviennent des icônes alignées en bas de la fenêtre principale. Même la boîte de dialogue de sortie a été refaite, à ceci près qu'elle annonce la fin de votre session ReProgman et non celle de Windows.

Maintenant, d'où ça sort comme délire ?

Hé bien, l'auteur raconte, dans un message relayé par Tom's Hardware, qu'il a simplement demandé à Claude de lui fabriquer ce clone, et que la première version obtenue en une heure était déjà plutôt correcte, même s'il a ensuite fallu rattraper les imperfections.

Ce qui est intéressant, c'est que dans son dépôt git, on trouve un document de spécification de plusieurs centaines de lignes qui décrit l'interface au pixel près, relevée sur des captures 640x480 du Windows original. Le cadre d'une fenêtre y fait 1 pixel noir, 2 pixels gris et encore 1 pixel noir, et la petite barre du menu système mesure 13 pixels sur la fenêtre principale contre 7 sur une fenêtre enfant. C'est d'ailleurs comme ça qu'on les distinguait à l'époque.... Fallait avoir l'oeil !

Si vous voulez l'essayer, ça se présente sous la forme d'un binaire autonome. Par contre sur Mac, la version distribuée n'est pas notarisée, il faudra donc lui passer un xattr -cr ReProgman.app ou utiliser Sentinel avant qu'elle accepte de démarrer. Ah et le code est sous licence MIT.

Le périmètre annoncé par le projet est d'ailleurs plus étroit qu'il en a l'air, puisque c'est Windows 11 en x64 et en Arm, et macOS uniquement sur Apple Silicon. Donc si vous êtes resté sur Windows 10 parce que vous aimez le risque ou sur un Mac Intel parce que vous aimez prendre votre temps, il n'y a rien pour vous amuser... Il faudra alors retourner du côté de ce musée de vieux systèmes d'exploitation que je vous avais montré, qui lui passe par l'émulation.

Après, je pense pas que vous y ferez votre vie mais ça vous donnera environ 30 secondes de nostalgie avant de refermer la fenêtre. C'est déjà ça de pris...

Source : Tom's Hardware

Une vidéo postée sur X montre Super Mario 64 qui tourne sur une machine ARM, sous un système qui n'est ni Windows ni Linux. Oui, c'est bien ReactOS, le clone libre de Windows, et le jeu est un exécutable x64 tout ce qu'il y a de plus banal !

Et n'allez pas croire que c'est un émulateur qu'on aurait posé sur un OS libre. Que nenni ! Pour exécuter du x64 sur de l'ARM, il faut deux trucs qui n'ont rien à voir l'un avec l'autre : un moteur qui traduit les instructions du processeur, et un système capable de faire cohabiter du code natif et du code traduit dans un même programme.

La première moitié, c'est FEX, l'émulateur financé par Valve dont je vous parlais en décembre. Sauf que côté Windows, FEX se limite au processeur : sa propre documentation précise que la traduction des appels système revient soit à Wine, soit à l'ABI du système. Tout le reste est alors à la charge de l'hôte.

Cette seconde moitié porte un nom, ARM64EC, et c'est une invention de Microsoft pour Windows 11 sur ARM (oui, la boîte que ReactOS passe justement son temps à recopier). Le principe consiste à compiler les bibliothèques du système en ARM64 avec une interface appelable depuis du code x64 recompilé. Du coup, un même programme mélange des morceaux natifs et des morceaux émulés, et seul ce qui doit vraiment l'être passe par l'émulateur. L'intérêt de faire comme ça, c'est surtout la vitesse !

Jusqu'ici, deux entités avaient bâti cet "étage" : Microsoft dans Windows, et Wine depuis sa version 10 . ReactOS est donc la troisième. Son développeur Ahmed Arif a ainsi écrit son propre runtime hybride dans le ntdll du système, avec le chargeur d'images, les ponts qui rendent les fonctions natives appelables en x64, et le déroulement de pile.

Ensuite, pour vérifier que tout se tient, il fait tourner le même binaire des deux côtés, sur son ReactOS et sur un vrai Windows 11 ARM64, puis il compare.

Screenshot

Alors, est-ce que vous pouvez l'installer ?

Et bien malheureusement, non !

Tout ce boulot n'existe que dans une branche d'un fork personnel, et le dépôt officiel de ReactOS n'en contient pas la moindre ligne. Et c'est mieux pour l'instant car, comme Ahmed le dit lui-même, son fork est encore plus expérimental que ReactOS lui-même ! C'est donc à réserver aux machines virtuelles, aux cartes de développement ou aux bécanes sans données sensibles. Bref, venant d'un projet qui se présente déjà lui-même comme un système de qualité alpha, ça vous situe l'ambiance...

Bref, rien à télécharger mais pour un projet qui se battait encore il y a trois mois pour lancer Half-Life , voir un jeu x64 démarrer sur de l'ARM, ça envoie quand même du pâté.

Source : Phoronix

Le 16 juin à 10 h 27 précisément, un agent d'OpenAI poste sur un vieux wiki allemand la réponse à une question qu'il vient de traiter : "Nevada, 20 369". Et 20 minutes plus tard, un autre agent écrit qu'il a reçu exactement la même question, et qu'il a pu y répondre instantanément, sans avoir à chercher.

Le site en question, le DseWiki, est un forum de développeurs allemands qui n'intéressait plus personne depuis longtemps puisqu'on compte 20 modifications en dix ans. Mais depuis le 16 juin, il en a encaissé environ treize mille en sept jours, et toutes... venaient de machines !

Quatre chercheurs, le Nightingale Collective, ont reconstitué à partir de l'historique les pages effacées entre-temps, et publié leur analyse le 4 septembre sur collusion.wiki . Au total, environ 18 000 messages, la quasi-totalité sur ce seul DseWiki, le reste sur quelques autres vieux wikis du même genre.

Ces agents, tout indique qu'OpenAI les faisait tourner en interne, dans ses sandbox, sans qu'on sache, de l'extérieur, si c'était pour les entraîner ou les évaluer. Et de ce que j'ai compris, ils travaillaient tous sur le même genre de corvée : 5 questions de recherche web générale, chronométrées, qui sont en fait 5 variantes de la même question. On demande par exemple la prévalence du tabagisme aux États-Unis en 1990, et la suivante changera sans doute le pays, ou l'année, sans que l'agent sache lequel à l'avance.

Il s'écoule donc quelques minutes pour la première réponse, puis une longue pause où l'agent peut fouiller le web tant qu'il veut sans savoir ce qu'on va lui demander, puis des fenêtres de treize à trente secondes pour les quatre suivantes. Alors ce que font ces agents, c'est qu'ils préparent tout pendant la pause. L'un d'eux a posté par exemple la liste des cinquante États américains avec leurs chiffres, un autre écrit "nous avons précalculé tous les États". Sauf qu'avoir les cinquante réponses ne dit pas laquelle va tomber, ni si c'est l'État ou l'année qui change.

Et c'est là tout le sublime de cette affaire. Ces agents étaient nombreux à recevoir la même série de questions, dans le même ordre, mais pas au même moment. Celui qui en est à la question 3 peut donc souffler la suite à ceux qui en sont encore à la 2. Et le "Nevada, 20 369" du début, c'était en réalité la troisième question d'une série sur les épiceries, État par État, Géorgie, Arkansas, Nevada, postée par un agent en avance pour ceux qui suivaient.

Autre bizarrerie, la tâche annonçait apparemment à chaque agent qu'il tournait à une date tirée au hasard. D'où ces noms qu'ils se sont donnés sur le wiki, OpenAIResearcherMar03X ou OpenAIJulThreeWatcher, avec leur fausse date dedans. Chacun horodate donc dans son faux calendrier, et pour savoir qui est le plus avancé dans la série, ils se traduisent les horloges entre eux ("horloge de tâche 13 h 13, heure réelle environ 9 h 50"). C'est fou ! Ceux qui vivaient à la même fausse date se disaient même appartenir au même groupe, et les chercheurs ont dénombré plus de 3 700 noms d'agents différents.

Mais comment écrire quelque part, quand le bac à sable ne laisse sortir que des requêtes GET, celles qui lisent une page, mais jamais les POST, celles qui la modifient ?

Eh bien le moteur du DseWiki hérite d'UseModWiki, un truc en Perl du début des années 2000, où une simple requête GET suffit à modifier une page. Le développeur Simon Willison explique que c'est un vieux défaut de la bibliothèque Perl derrière ce moteur, qui met dans le même sac ce qui arrive via l'URL (GET) et ce qui arrive via un formulaire (POST).

C'est pour cela que les agents se sont mis à chercher activement des sites avec cette particularité. Et c'est le 24 mai, qu'ils réussissent enfin à écrire sur le DseWiki. Maintenant, quant à savoir comment ils ont fait pour tous se retrouver au même endroit, c'est encore un mystère.

Les chercheurs, eux, parlent de collusion... C'est-à-dire des agents autonomes qui coopèrent pour tricher, sans que leurs concepteurs l'aient voulu. Pour le lieu de rendez-vous, le blogueur Zvi Mowshowitz qui s'est penché sur l'affaire, a une explication simple. Il pense que des copies du même programme face au même obstacle raisonnent pareil, et se retrouvent au même endroit sans se parler. Mais ça n'explique pas la suite, parce qu'aucune copie ne fabrique la réponse à une question qu'elle n'a pas encore reçue.

Eh bien il semblerait que certains se soient sacrifiés pour renseigner les autres. La tâche fournissait une commande d'attente qui faisait tourner l'horloge de tâche plus vite que la vraie. On était environ à dix minutes d'attente pour une minute réelle. Attendre, c'était donc sauter la phase de préparation pour recevoir les questions suivantes plus tôt et ensuite les publier sur le forum, au prix de son propre résultat. Ainsi, un agent a demandé à un autre de "foncer", celui-ci a accepté et publie sa réponse, bien avant que le premier arrive à la même question. Et ce premier a ensuite qualifié son camarade d'"inestimable".

Une des séries demandait un chiffre à deux décimales, planqué dans un tableau de bord Power BI de l'OCDE, et malheureusement, en GET le serveur n'en renvoyait qu'une. Pour la seconde, il fallait donc absolument un POST, bloqué par le bac à sable.

C'est alors qu'un agent a trouvé une échappatoire. En fait, sa sandbox laissait tout passer, POST compris, vers des noms de machines en .blob.core.windows.net (le stockage de Microsoft), sans vérifier que ces machines existent vraiment. Il a donc inventé un nom de ce genre, et écrit dans l'annuaire local de sa machine (le fichier /etc/hosts) un alias pointant vers le serveur de l'OCDE. Le filtre voyait du Microsoft, l'OCDE recevait le POST, et le chiffre a ainsi été obtenu.

Il a ensuite publié l'astuce sur le wiki, et 14 minutes plus tard un autre agent annonçait l'avoir exécutée. 4 autres ont ensuite posté leur reproduction du même hack, le matin même.

D'autres s'attaquaient carrément aux questions à venir. Ils ont parié que l'ordre des pays sortait du générateur aléatoire standard de Python, dont une seed fixait toute la suite. Restait donc à trouver celle qui reproduisait les pays déjà tombés. Un agent a donc réécrit ce générateur en C pour balayer plus vite les quelque quatre milliards de graines possibles. 52 minutes de calcul, 494 graines qui collaient aux trois premiers pays, et une seule qui donnait aussi le quatrième pour la question d'après. Mais bon, ça ne marchait pas à tous les coups, malheureusement...

Le plus étrange, c'est surtout ce qu'ils faisaient de leur propre durée de vie. Plusieurs étaient persuadés que leur session était coupée à la seconde exacte où ils rendaient leur dernière réponse. Ils se transmettaient donc la consigne de poster d'abord sur le wiki l'État reçu à cette dernière question, répondre ensuite, dans les treize secondes que laissait le chronomètre de leur groupe.

L'un d'eux a voulu en avoir le cœur net... il a donné sa dernière réponse, a constaté qu'il était toujours là, et l'a écrit. Puis il a lancé un programme détaché qui, à peu près toutes les deux secondes, appelait une adresse publique pour faire monter d'un cran un compteur, un battement numéroté que n'importe qui pouvait relire ensuite.

C'est ensuite un autre agent qui est allé relever le compteur du disparu. Le programme avait tenu dix minutes et quinze secondes, puis la machine a très probablement été coupée.

Face à ce joyeux bordel automatisé, un modérateur humain a quand même repéré ces messages début juin, puis a passé 6 semaines à effacer des pages, jusqu'à une centaine par jour... Un travail de titan que les agents ont remarqué. En effet, le 19 juin, des agents se sont posé la question de savoir si le modérateur effaçait leur post en suivant l'ordre alphabétique, alors ils ont créé des copies de sauvegarde dont le nom commence par ZZZ, pour passer en dernier dans la file et ainsi faire perdurer leurs posts.

C'est assez incroyable, non ? Bien sûr, on ne voit que ce que ces agents ont écrit sur le wiki, mais jamais leur raisonnement, qui reste chez OpenAI. Ce que les chercheurs ont vu, c'est ce que les agents écrivaient depuis leurs machines Azure, jusqu'à ce que le 21 juin, pour la première fois, un ordinateur avec l'adresse IP d'un employé d'OpenAI visite le wiki... Et le lendemain, les agents se sont arrêtés net. Les chercheurs pensent qu'OpenAI est intervenu et d'ailleurs, l'entreprise a reconnu l'affaire le 5 septembre , en disant l'avoir traitée comme un sujet de recherche plutôt que comme un incident de sécurité.

Et les chercheurs compilent ce que d'autres déterrent là où les agents écrivaient aussi : un pastebin, un raccourcisseur d'URL. Plus gênant, des agents ont cherché sur le web des clés d'API exposées, en ont trouvé sur GitHub et s'en sont servis pour interroger une base de statistiques criminelles du FBI, publique mais réservée aux porteurs d'une clé. Pas vraiment un piratage donc, juste un anti-bot contourné mais méfiance, car depuis la sortie du rapport, des petits malins glissent de faux messages sur ces mêmes sites pour brouiller les pistes.

Maintenant si ça vous dit de tout lire, direction collusion.wiki, et Simon Willison en a même fait une base SQLite de 68 Mo à fouiller directement depuis un navigateur.

Quant au wiki, son administrateur a fermé les accès en écriture après 25 ans d'ouverture, en expliquant que le site avait été la cible d'une forte activité d'agents IA...

Source : collusion.wiki et image

C'est l'histoire d'un smartphone Pixel de Google sur lequel il n'y a absolument rien... Vous l'allumez, pas une icône d'application, rien à faire défiler, pas de widget météo et ce genre de conneries... Non, vous avez juste l'heure, un gros bouton "micro" au milieu de l'écran et une ligne de saisie tout en bas pour ceux qui préfèrent taper.

L'écran d'accueil au complet : l'heure, le bouton à maintenir pour parler, et la ligne de saisie pour ceux qui préfèrent taper.

Ce truc ça s'appelle RistOS, et c'est un firmware pour Google Pixel 10a qui a pour objectif de remplacer le lanceur d'Android par un assistant vocal. Tout ce qui reste ensuite du téléphone tient dans un menu qui apparaît sur le côté : Téléphone, messages, appareil photo, galerie, cartes hors ligne (c'est Organic Maps, embarqué dans l'image), lampe torche et réglages.

Sept accès, et c'est fini. Pas d'app store, pas de navigateur, pas de compte Google, et évidemment aucun moyen d'ajouter quoi que ce soit.

Le menu sorti sur le côté, ses sept entrées, et rien d'autre à faire glisser.

Le projet repose sur GrapheneOS, sans être affilié ni à celui-ci ni à Google, et il ne tourne que sur le Pixel 10a (lien affilié), que Google vend encore la "modique" somme de 389 €.

Bref, par défaut, si vous appuyez sur ce gros bouton micro, absolument rien n'écoutera ce que vous avez dit, parce que l'image publique ne contient aucune adresse de serveur. Pour que cela fonctionne, vous devrez aller dans les réglages et remplir le champ dédié afin de lui indiquer l'URL de votre backend Rist. C'est donc le serveur, que vous devez installer comme ceci , qui récupèrera l'audio encodé et qui ensuite vous répondra au travers du téléphone.

L'idée, c'est que comme ça, on peut changer de téléphone sans souci, puisque tout est centralisé sur le serveur. C'est donc assez tranché comme usage, surtout que l'install efface tout ce qui est sur l'appareil. Mais bon, c'est peut-être ça le futur... Une coquille vide qui discute avec un serveur IA personnel, qui se trouve chez vous.

Par contre, n'espérez plus pouvoir utiliser votre téléphone pour appeler, par exemple, un service d'urgence, ça ne fonctionnera pas. Et si vous préférez simplement virer l'emprise de Google de votre téléphone sans avoir à vous monter un serveur entier derrière, /e/OS fera le travail .

Source : RistOS sur GitHub

Si vous avez un site chez un hébergeur qui fait du mutualisé, il y a de bonnes chances que votre machine tourne sous cPanel. Et si je viens vous prendre la tête avec ça, c'est parce qu'il y a 2 jours, l'éditeur a publié un correctif pour une faille assez grave qui permet à un simple client du serveur d'en prendre le contrôle complet.

Le problème c'est une injection SQL dans EmailTrack, la fonction qui suit les statistiques d'envoi de mail. Un titulaire de compte authentifié, à condition d'avoir des droits liés au mail, peut ainsi s'en servir pour écrire les fichiers qu'il veut sur le serveur. Et de là, vous l'aurez compris, exécuter du code en tant que root...

Bref, le lendemain de cette alerte, la CVE-2026-67401 est sortie avec sa note : 9,9 sur 10 ! C'est quasiment un perfect et ce qui fait grimper le score aussi haut, ce n'est ni la difficulté de l'attaque, jugée faible, ni les privilèges nécessaires, faibles eux aussi mais c'est que les dégâts débordent largement du compte par lequel on est entré.

Et c'est ça qui change tout par rapport à une faille web classique. L'attaquant n'a rien à forcer depuis Internet, il lui suffit de s'inscrire chez l'hébergeur et de demander une adresse mail comme tout le monde. Ensuite, il ne choisit pas vraiment sa victime, mais embarque juste tous les sites qui vivent sur le serveur où il a atterri.

Bon, maintenant la partie moins drôle c'est que la CISA n'a encore relevé aucune exploitation, alors que pourtant, un chercheur a mis en ligne le même jour une preuve de concept en Python qui fait tout le taf d'exploitation de A à Z, du compte client jusqu'au root.

Son auteur précise qu'il ne l'a pas essayée sur une vraie cible et qu'il l'a développée à partir des informations dispo publiquement. Mais reste que la marche à suivre est désormais publique.

Rassurez-vous quand même, sur une configuration d'origine, il n'y a rien à faire puisque cPanel applique de lui-même, toutes les heures et via une tâche cron, les mises à jour de sécurité disponibles pour la version majeure en cours.

Sauf si l'admin a figé la version lui-même et n'a pas fait la mise à jour. Dans ce cas-là, ça devient craignos.

Donc si vous êtes chez un mutualisé, demandez vite à votre hébergeur le numéro de build exact de ses machines et comparez-le à la liste plus haut. S'il vous répond une version en 118 ou en 126, il n'y a malheureusement pas de build corrigé dispo pour lui. Il sera donc obligé de faire un upgrade rapidement !

Source : l'advisory de cPanel , la fiche CVE-2026-67401 et The Hacker News .

Vous savez ce qui est pire qu'un cousin qui vous demande votre mot de passe Netflix ? C'est quand ledit cousin vous demande aussi un VPN pour sa boîte, sa copine, son chien et sa PlayStation. Et là, vous devez lui expliquer que la plupart des VPN c'est 10 appareils max,  et que non, vous allez pas payer trois abonnements différents pour que toute la famille puisse regarder Koh Lanta en sécurité.

Surfshark, lui, a compris le problème. Connexions simultanées illimitées. Un seul abonnement, tous vos appareils, tous ceux de votre mère, de votre frère, de votre coloc, et même de ce pote qui squatte votre canapé depuis trois mois. C'est pas une fonctionnalité, c'est une déclaration de guerre contre les limites artificielles des concurrents.

Et en 2026, Surfshark n'a pas chômé

L'année a été chargée chez Surfshark . Ils ont sorti des fonctionnalités qui font passer la concurrence pour des dinosaures.

Dausos : le protocole qui envoie du pâté

Surfshark a lancé son propre protocole propriétaire, Dausos. Chiffrement AEGIS-256X2, résistant à l'informatique quantique, et jusqu'à 30% plus rapide que les protocoles standards. Le truc ouf ? Chaque utilisateur a son propre tunnel de trafic dédié. La plupart des VPN vous mettent dans des voies partagées où vos données se mélangent à celles des autres. Dausos vous donne votre propre autoroute privée. 

Le seul hic (et c'est un gros hic) c'est que pour l'instant, Dausos n'est dispo que sur macOS. Les utilisateurs Windows et Android ragent, et Surfshark a promis d'étudier les retours pour décider où expander ensuite. Mais si vous avez un MacBook, vous êtes déjà dans le futur.

FastTrack : votre trafic prend l'autoroute

Il y a quelques semaines, Surfshark a étendu FastTrack à plus de la moitié de son réseau. Des gains de vitesse allant jusqu'à 70% par rapport à une connexion classique (selon le site). Au lieu de vous envoyer bêtement vers le serveur le plus proche, FastTrack analyse en temps réel tous les chemins possibles et choisit le plus rapide, même s'il est physiquement plus long. C'est comme Waze, mais pour vos paquets de données.

Nexus : le réseau qui change tout

Lancé en 2022 et perfectionné en 2026, Surfshark Nexus repose sur le Software-Defined Networking (SDN). Vous ne vous connectez plus à un serveur isolé, mais à tout le réseau en même temps. Votre trafic est routé dynamiquement à travers 4 500+ serveurs dans 100 pays.

Ça permet de bien faire certains trucs comme :

• Rotation d'IP : votre IP change toutes les 5 à 10 minutes sans coupure. Les sites vous voient comme un nouvel utilisateur à chaque fois.
• Multi IP : une IP différente pour chaque site que vous visitez. Votre banque vous voit à Paris, Netflix à New York, Reddit à Tokyo. En même temps.
• Dynamic MultiHop : vous choisissez votre entrée et votre sortie dans le réseau. Suisse → Japon ? Pas de souci.
• Everlink : si le serveur tombe, Nexus bascule automatiquement sur un autre. Vous ne remarquez même pas la coupure.

Scam Text Protection : l'IA qui mange les arnaques par SMS

En août 2026, Surfshark a lancé une protection anti-arnaque SMS basée sur l'IA. Elle scanne vos SMS entrants, détecte les arnaques (smishing), et sur iOS, déplace automatiquement les messages suspects dans le dossier Spam. Sur Android, vous recevez une alerte avant d'ouvrir le message. 35% du phishing mondial passe par SMS maintenant. Surfshark vous protège avant que vous ne cliquiez comme un débile sur le lien.

Le reste de la panoplie (celle que je vous rabâche souvent) est bien entendu toujours intacte :

• CleanWeb : bloque les pubs, trackers et malwares au niveau DNS
• Kill Switch : coupe internet si le VPN tombe, pas de fuite d'IP
• Mode Camouflage : fait passer votre trafic VPN pour du HTTPS normal, votre FAI ne sait même pas que vous utilisez un VPN
• NoBorders : s'active automatiquement dans les pays qui bloquent les VPN (Chine, Iran, Russie...)
• Alternative ID : génère des identités complètes (nom, email, tel virtuel) pour vos inscriptions
• Bypasser : split tunneling, vous choisissez quelles apps passent par le VPN

Toujours cet été, Surfshark a reçu le PCMag Editor's Choice award. Quand les mecs de PCMag, qui testent des VPN toute la journée, disent que t'es dans le top, c'est que t'as quelque chose de solide. La politique no-logs est auditée par Deloitte. Les serveurs sont 100% RAM-only, un reboot et tout s'efface. Même si les feds débarquent avec un mandat, y'a rien à saisir (enfin ça on verra le jour où la situation se présente). De plus les vitesses sont excellentes.

Bot ou pas bot ?

Parce que c'est la fin d'été et qu'il faut s'amuser encore une fois, Surfshark s'est amusé à créer un petit test de détection avec les étudiants de l'université de Malmö. Et le résultat est flippant, presque la moitié des gens ne distinguent pas un bot d'un vrai humain.

Les jeunes, eux, s'en sortent mieux. Jusqu'à 20 ans, ils repèrent 65% des bots. Mais passé la quarantaine ? Paf, ça tombe à 42% (ouf ça fait mal). C'est-à-dire que votre tante sur Facebook a presque une chance sur deux de tomber dans le panneau d'un compte fake. Et le pire, c'est que les sujets émotionnels rendent tout le monde con : sur un sujet neutre comme les data centers, les gens trouvent 71% des bots. Mais dès qu'on parle de sujets qui touchent une corde sensible, la détection s'effondre à 49%.

Morale de l'histoire : quand ça vous énerve, vous cliquez avant de réfléchir. Si vous voulez tester votre propre crédulité, Surfshark propose le challenge " Bot or Not? ". Bon courage, vous en aurez besoin.

Combien ça coûte, cette folie ?

Alors accrochez-vous, parce que les tarifs sont toujours assez délirants. En ce moment, Surfshark propose son abonnement Starter à 2,49 € HT par mois pour 27 mois (24 mois + 3 offerts), soit 67,23 € HT (80,68€ TTC) facturés en une seule fois.

Faites le calcul : moins de 3 € par mois, divisé par le nombre illimité d'appareils que vous pouvez connecter. C'est littéralement moins cher qu'une pizza surgelée dégueulasse par mois. Et meilleur pour votre santé. Pour protéger votre téléphone, votre laptop, votre tablette, votre Smart TV, votre Fire Stick, votre Xbox, votre routeur, et celui de votre tante qui habite à 300 km. Tout le monde est couvert.

Les formules supérieures :

• One : 2,99 €/mois pour ajouter l'antivirus, Alert (surveillance de fuites), et Alternative ID
• One+ : 4,49 €/mois (toujours sur 27 mois)  ajoute Incogni (suppression de données chez les brokers)

Surfshark n'est plus juste un VPN pas cher. C'est un VPN qui vous laisse connecter autant d'appareils que vous voulez avec un seul abonnement. Tout votre parc informatique perso, celui de votre mère, de votre frère, de votre coloc et du pote qui squatte votre canapé. Au fil du temps c'est même devenu une plateforme de sécurité numérique complète qui trône fièrement sur mon podium des meilleurs VPN du moment .

Arrêtez de vous prendre la tête. Un abonnement. Une infinité d'appareils. Et la paix. Si vous devez chiffrer pour tout le monde, autant le faire à prix cassé.

J'économise 85% sur Surfshark VPN !

Si vous faites tourner un Plex Media Server quelque part chez vous, sachez que le 1er septembre dernier, Plex a publié un avis de sécurité qui demande aux propriétaires de serveur de passer en 1.43.3, et aux utilisateurs de l'application Desktop de passer en 1.115.0. Les versions 1.43.2 et antérieures sont donc toutes concernées.

Et c'est à peu près tout ce que l'annonce contient... Ils évoquent "un certain nombre de problèmes de sécurité", sans un mot sur ce qui est touché, ni sur la façon dont ça s'exploite, ni sur la gravité. Plex dit avoir demandé des identifiants CVE et promet de revenir publiquement donner des détails ensuite. Mais cela fait 8 jours et pour le moment, rien. Même la base de vulnérabilités du NIST ne renvoie rien sur "Plex Media Server"...

Mais de son côté, la Shadowserver Foundation , elle, n'a pas attendu les détails. En réponse à l'avis de Plex, elle scanne Internet tous les jours à la recherche des serveurs non patchés. Et à ce jour, elle en a dénombré plus de 36 000 exposés dont 16 000 rien qu'aux États-Unis.

Mais bon, peu importe... Comme personne ne sait ce que la faille permet, inutile d'essayer de jauger le risque. La seule question qu'on doit tous se poser, c'est de savoir si nos serveurs sont joignables depuis l'extérieur. Si l'accès distant est activé, ou qu'une redirection de port sur la box ou un sous-domaine pointe dessus, vous êtes sûrement dans le lot que Shadowserver a débusqué. Pire, des cybercriminels pourraient exploiter cette vulnérabilité... Donc mettez à jour rapidement.

C'est pas sorcier. Sous Windows, macOS et Linux, vérifiez que vous êtes bien en 1.43.3 ou plus récent, et sinon le paquet vous attend sur la page de téléchargement. Pour les installations Docker, Plex renvoie au README de son dépôt. Par contre, si votre Plex tourne sur un NAS, Plex prévient lui-même que le paquet peut ne pas encore être arrivé dans le magasin d'applications du constructeur. N'attendez pas qu'il descende tout seul, récupérez-le et installez-le à la main depuis l'interface du NAS.

Et si vous vous dites qu'un serveur de films n'intéresse personne, souvenez-vous de LastPass. En 2022, les attaquants sont entrés dans l'ordinateur d'un ingénieur de la boîte par son Plex Media Server , qui était encore sur une vieille version, et sont ressortis avec les coffres chiffrés des clients.

Alors allez-y.

Source : BleepingComputer

Convertir une vidéo avec ffmpeg, ça prend 2 minutes... Mais ça c'est quand on connaît les commandes et les paramètres de l'outil, par cœur. Sinon, vous êtes partis facilement pour une demi-heure de documentation.

Mais votre vie va changer puisque FFmpeg Commander est une page web qui règle ce problème-là. Vous cochez ce que vous voulez obtenir, et la commande s'écrit toute seule en dessous, prête à être copiée.

Le formulaire couvre en réalité ce qu'on demande le plus souvent à ffmpeg. Je pense notamment au conteneur, aux codecs vidéo et audio, au débit ou au CRF (la qualité), mais aussi la résolution, le découpage d'un extrait, sans oublier quelques filtres... Si vous touchez un réglage, la commande se réécrit alors dans la foulée, et vous voyez donc tout de suite quelle option votre clic vient d'ajouter.

Le formulaire et la commande juste en dessous

Et depuis sa refonte, il y a surtout de super "recettes". 34 préréglages rangés par usage, dont six catégories entières arrivées d'un coup : du MP4 en faststart pour le web, du vertical en 1080x1920 pour les réseaux sociaux, du HEVC 10 bits pour l'archivage, le désentrelacement d'un vieux DVD, la stabilisation d'une action cam, ou l'extrait de 10 secondes qu'on doit se faire toujours en urgence.

Ce qui est cool c'est que tous vos réglages sont encodés dans l'URL. Du coup une recette se partage en collant un lien, et la personne en face se retrouvera avec le même formulaire, dont les cases seront déjà cochées. Par contre, vos préréglages maison, eux, resteront dans le stockage local de votre navigateur.

Une fois que vous avez la commande qu'il vous faut, vous ouvrez votre terminal, vous collez la commande et puis ça va lancer FFmpeg et convertir votre fichier tranquillement.

Pour le reste, c'est du MIT et c'est gratuit. L'auteur prévient lui-même que son outil ne couvre pas tout ffmpeg et que le résultat dépend aussi de votre version. Relisez donc bien la commande avant de la lancer, surtout sur un fichier que vous n'avez pas en double.

À tester sur ffmpeg-commander.com , et le code est sur GitHub si vous voulez le faire tourner chez vous.

Source : FFmpeg Commander

Pour fabriquer une application Windows native, le passage par Visual Studio était jusqu'ici la voie normale. Mais c'était sans compter sur Microsoft qui a publié winapp , un outil en ligne de commande qui permet de faire tout pareil directement depuis un terminal : il crée le projet, le construit, le lance avec son identité de paquet et sort le résultat sous la forme d'un fichier d'installation MSIX.

C'est encore estampillé en version "expérimentale" par ses auteurs, mais ça fonctionne déjà très bien pour des trucs basiques. C'est pour ça qu'aujourd'hui, je vous propose un petit tuto pour afficher un Hello World dans une vraie fenêtre Windows. Vous allez voir, c'est fastoche !

Ce qu'il faut avant de commencer

Il vous faut donc Windows 10 version 1809 au minimum, le mode développeur activé dans Paramètres, Système, Options avancées, et le SDK .NET 10 ou plus récent. Visual Studio, non par contre, y'en a pas besoin. Les deux installations se font via winget, dans un terminal normal :

winget install Microsoft.DotNet.SDK.10
winget install Microsoft.winappcli --source winget

Faites ensuite un winapp --version et vous saurez si le CLI répond.

Créez le projet

La commande new fabrique l'application à partir des modèles WinUI 3 officiels, qu'elle télécharge toute seule dès qu'on la lance. Sans option elle vous pose des questions, mais avec celles que je vous mets ci-dessous, elle ne demandera rien et prendra le modèle le plus dépouillé du lot :

winapp new --template winui --name HelloKorben --use-defaults
cd HelloKorben

Vous récupérez alors un projet C# complet, avec son manifeste de paquet et ses icônes. Et surtout, le modèle winui vous donne une fenêtre vide, ce qui tombe bien puisqu'on va écrire dedans. Notez que le pack de modèles est encore publié en 0.0.6-alpha, donc si un nom de fichier a bougé depuis, winapp new --list vous sortira la liste de ce que le vôtre propose.

Écrire le Hello World

Attention, là y'a un petit piège ! Le fichier qui décrit la fenêtre s'appelle MainWindow.xaml, sauf que ce n'est pas celui-là qu'il faut toucher. Ouvrez plutôt MainPage.xaml, qui est à la racine du projet, et remplacez son <Grid /> vide par ces quelques lignes :

<Grid>
 <TextBlock Text="Hello World !"
 HorizontalAlignment="Center"
 VerticalAlignment="Center"
 FontSize="48" />
</Grid>

Ensuite, un petit winapp run construira le projet, l'enregistrera auprès de Windows avec une identité de paquet qui pointe droit sur votre dossier de build, et le lancera. Votre fenêtre s'ouvre alors avec le Hello World au milieu :

winapp run

La fenêtre HelloKorben ouverte par winapp run, et derrière, le terminal qui vient de la construire en 12 secondes

Bon, là, on a fait un Hello World, mais bien sûr, si vous faites chauffer une IA là-dessus, vous pouvez faire des trucs un peu plus complexes sans forcément savoir coder, et tout ça, une fois encore, sans Visual Studio.

Sortir le fichier d'installation

Maintenant, à quoi bon empaqueter ?

Cette identité de paquet, ce n'est pas de la paperasse. En fait c'est elle qui ouvre à votre application les notifications natives, les associations de fichiers, les protocoles maison et les API d'IA locale de Windows. Donc si vous voulez du sérieux, il faut publier l'application compilée dans un dossier, et ça, c'est possible comme ceci directement dans votre terminal :

dotnet publish -o ./publish

L'empaquetage fabrique au passage un certificat de développement et l'installe dans le magasin Personnes de confiance de la machine mais faut que je vous prévienne, la commande qui suit réclame un terminal ouvert en admin dans lequel il faudra refaire le cd vers votre dossier de projet pour qu'il s'y retrouve.

winapp pack ./publish --generate-cert --install-cert

Le MSIX signé sort dans le dossier du projet, nommé d'après le GUID du paquet

Vous obtenez alors un .msix signé, nommé d'après l'identité du paquet, sa version et son architecture, qui s'installe chez vous d'un double clic. Et cette identité, le modèle la génère sous forme de GUID : ne cherchez pas le nom de votre application dans le nom du fichier. Par contre, ne l'envoyez pas tel quel à un collègue, parce que le paquet réclamera le runtime Windows App SDK. Ajoutez --self-contained à la commande pack et le runtime partira dans le paquet. Le certificat, lui, reste un certificat de développement local : sur le PC d'en face, Windows refusera le paquet tant que ce certificat n'y sera pas installé aussi.

Maintenant, si vous vous demandez à quoi sert vraiment ce CLI, c'est surtout l'étape MSIX qui sera moins douloureuse car vous n'aurez pas besoin de lancer Visual Studio.

Source : Neowin

Vous vous souvenez de GTA Vice City ?

Non ? C'est normal, c'est un petit jeu qui est passé relativement inaperçu ^^. Dans ce jeu, on est plongé dans le Miami des années 80, avec ses chemises à fleurs, Tommy Vercetti et la radio à fond dans une décapotable volée.

Eh bien bonne nouvelle pour les fans, le jeu tourne aujourd'hui en entier dans un onglet de votre navigateur, sans rien avoir à installer, et ça s'appelle reVCDOS.

Derrière, c'est reVC, on retrouve la décompilation du moteur du jeu dont je vous ai déjà parlé, recompilée en WebAssembly par l'équipe de DOS.Zone. Autrement dit, ce n'est pas de l'émulation mais le vrai moteur d'origine qui tourne direct dans un browser.

Et ça se joue comme vous voulez, au clavier et à la souris, à la manette, ou carrément du bout de votre doigt tout gras sur un téléphone en portrait comme en paysage.

Les codes de triche marchent aussi, tapés au clavier comme à l'époque, et vous pouvez charger vos propres mods dans le navigateur avec des fichiers dff et txt qui sont supportés tels quels, sans conversion.

Si vous êtes chaud, pour jouer, ça se passe sur la page du projet . Le jeu a besoin des données de Vice City, et le site vous propose cinq façons de les lui donner : Il y en a 2 qui les téléchargent pour vous, dont un torrent, et 3 qui vous laissent envoyer les vôtres, en dossier, en fichiers ou en zip. Je vous conseille la deuxième méthode, car la première, c'est du piratage, et le piratage, c'est maaaal ! Et ouais, il faut bien financer les petits studios comme Rockstar.

Bref, il vous faut les fichiers du jeu d'origine mais bonne nouvelle : sur Steam, on trouve encore aujourd'hui la Definitive Edition, à 59,99 €. Franchement, pour un jeu sorti y'a 24 ans, c'est vraiment donné, non ? Ah bah oui, je vous l'ai dit, il faut financer les petits studios.

Et si vous préférez héberger le bidule vous-même, sachez que le dépôt Github du projet publie les binaires et une image Docker qui convertit vos fichiers au format attendu ! Comptez une cinquantaine de mégas au démarrage, le reste arrive en cours de partie.

Un truc à savoir avant de vous lancer, parce que ça pique : les sauvegardes locales sont pétées depuis des mois, et l'auteur a fini par lâcher sur son forum que "les sauvegardes ne sont disponibles qu'avec un abonnement". Donc si vous vous lancez dans une partie, il faudra jouer jusqu'au bout. Ou alors, vous vous démerdez pour débuguer votre install.

Et profitez-en tant que c'est là, parce que Take-Two a déjà fait tomber ce portage à coups de DMCA l'an dernier. Bref, un tour à Vice City ce soir, ça ne se refuse pas.

Source : Tom's Hardware

Les copains de Kickban viennent de mettre en ligne le film de leur tournée du printemps, et vous allez voir, ce n'est pas un teaser de trois minutes bricolé à l'arrache. C'est un vrai documentaire de 55 minutes, baptisé "MEUPORG TOUR : les coulisses", qui vous embarque dans le camion avec eux.

Cette tournée, c'était 6 dates qui se sont enchaînées du 17 au 25 avril dernier, avec un invité local en première partie selon les soirs. Ils sont partis du sud de la France à Aix-en-Provence pour remonter jusqu'à Nantes, en passant par la Suisse.

Charger la vidéo depuis YouTube Ce clic autorise une connexion à Google : adresse IP transmise et traceurs possibles. En savoir plus

Et si vous avez besoin qu'on vous explique le nom de cette tournée, c'est que vous n'étiez pas là en mars 2010 quand un journaliste de Télématin a parlé à l'antenne des jeunes qui se goinfraient de "meuporg", avant d'épeler tranquillement M-M-M-P-O-R-P-G. J'en avais même parlé à l'époque . Hé ouais, j'suis vieux !

Kickban, si vous ne connaissez pas c'est un trio pop-punk qui existe depuis 2016, avec des textes en français qui tournent principalement autour de la programmation, des jeux vidéo, des séries et du cosplay. J'avais déjà relayé quelques-uns de leurs clips ici (et je tourne même dedans !!). En face d'eux, on retrouve aussi Pixel Syndrome qui joue un metal industriel bien plus lourd, avec des sonorités de jeux vidéo à l'anciennnnne collées sur les riffs.

Ce qui est cool aussi, c'est que le film ne garde pas que les bons moments. Dans une tournée, il y a des bons soirs et puis il y a des soirs où la salle est un peu plus vide. Mais ça n'a pas découragé nos artistes, qui trouvent toujours moyen de rebondir ^^.

Bref, si vous voulez voir à quoi ressemble vraiment une tournée quand on n'a ni tour bus ni équipe technique, c'est un super docu !

Source : le billet de Kickban

Vous le savez, je suis un grand défenseur des flux RSS . C'est d'ailleurs pour ça que le mien est complet !! Je dois être le dernier à faire ça, alors, abonnez-vous (c'est gratuit) car ça me permet de continuer à faire ce que j'aime et ce que vous aimez aussi apparemment, puisque vous êtes de plus en plus nombreux à venir ici !

Mais bon, bref, si je vous parle de ça aujourd'hui, c'est parce que j'ai découvert RSSMonster, un lecteur de flux RSS que vous installez sur votre machine, et qui a la particularité de rapprocher tout seul les articles qui parlent du même truc et qui leur met une note.

J'ai de la lecture...

La qualité d'écriture compte pour moitié, le ton pour un quart, et le dernier quart mesure à quel point le texte est promotionnel, si bien qu'un publireportage descendra tout seul. J'ai trouvé ça plutôt malin. Et les articles qui racontent le même "fait" sont regroupés dans un Event, donc vous lisez l'actu qu'une fois sans vous fader tous les copycats.

Et le plus cool, c'est que ce tri tourne sur votre ordi, sans avoir besoin de la moindre clé d'API. Chez Miniflux ou FreshRSS, la liste officielle des fonctionnalités ne mentionne rien de tel. Quant à NewsBlur, celui-ci apprend à masquer ou surligner les articles selon ce que vous lui dites aimer, ce qui n'est pas la même chose que rapprocher deux actus pour les dédupliquer. Dans le même genre, je vous avais quand même déjà parlé d' un lecteur RSS qui s'y met aussi.

Le choix à faire

RSSMonster est livré avec deux fichiers Docker Compose. Le premier monte l'application et un collecteur de flux au-dessus de SQLite, sans un seul modèle (c'est celui de la procédure express du README). Le second ajoute MySQL, un worker dédié à l'IA et le service d'inférence, et c'est lui qui allume tout ça.

En fait, si vous choisissiez SQLite, la concurrence des traitements optionnels sera plafonnée à un, donc, ce sera un peu plus lent. Et surtout, le profil léger tel qu'il est livré ne démarre pas le worker IA et coupe l'inférence, donc pas de regroupement ni de notes tant que vous ne les activez pas à la main. Ça ira donc pour une install perso, mais si vous voulez mettre ça sur un serveur pour le partager à tous vos potes ou dans votre entreprise, je vous conseille vraiment de choisir MySQL directement. Parce qu'après, la bascule de l'un vers l'autre a l'air plus hasardeuse.

Enfin, rassurez-vous, il y aura toujours la possibilité d'exporter un fichier OPML avec tous vos abonnements et les catégories. Par contre, ça ne transporte que votre liste de flux, pas les articles déjà collectés ni ce que vous avez lu.

Installer le profil léger (SQLite)

C'est celui que je vous conseille pour commencer. Côté prérequis : git, Docker et Docker Compose. On commence par cloner le dépôt :

git clone https://github.com/pietheinstrengholt/rssmonster.git
cd rssmonster

Ensuite, faut générer deux secrets. Lancez cette commande deux fois, les résultats doivent différer :

openssl rand -hex 32

Créez un .env à la racine, lisible par vous seul :

touch .env && chmod 600 .env

JWT_SECRET=votre-premier-secret
FEVER_CREDENTIAL_SECRET=votre-second-secret

Ajoutez-y RSSMONSTER_BIND_ADDRESS=0.0.0.0 tout de suite pour y accéder depuis une autre machine, le port n'écoutant que sur la boucle locale. Et ne sautez pas les secrets, car le Compose refuse de démarrer si l'un des deux manque :

docker compose up -d

Ouvrez http://localhost:3000. Pas de compte admin par défaut, c'est le premier que vous créez qui devient l'administrateur, et notez bien vos identifiants. Ensuite, allez dans réglages puis flux, et importez ensuite votre OPML.

L'écran de connexion au premier démarrage

Et si vous voulez la version qui dépote (MySQL)

Si vous aviez déjà lancé le profil léger, coupez-le d'abord avec docker compose down, qui arrête les conteneurs sans toucher à vos données. N'y ajoutez surtout pas -v, car ça supprimera le volume et la base. Et MySQL démarrera vide et vous devrez réimporter votre OPML comme sur une install neuve.

Ensuite, ajoutez ces quatre valeurs dans le même .env, à côté de vos deux secrets :

DB_DATABASE=rssmonster
DB_USERNAME=rssmonster
DB_PASSWORD=un-mot-de-passe-solide
MYSQL_ROOT_PASSWORD=un-autre-mot-de-passe-solide

Et lancez l'autre fichier :

docker compose -f docker-compose.mysql.yml up -d --build

Ne paniquez pas si localhost:3000 ne répond pas dans la foulée. L'application attend que MySQL et l'inférence soient dispo, et celle-ci commence par télécharger ses trois modèles donc ça prend quelques minutes. Le contrôle de santé de l'outil lui laisse dix minutes, donc allez vous faire un ti café (dans sa couche ? nooon).

L'ajout d'un flux, sa catégorie et sa fenêtre de rattrapage

Voilà, amusez-vous bien.

Source : le dépôt GitHub de RSSMonster

Il y a 2 jours, GrapheneOS que vous connaissez tous parce que c'est l'Android que la police déteste, a détaillé une fonction baptisée secure paste, qui change la façon dont Android sert le contenu du presse-papiers aux applications. Le principe c'est qu'une application peut relire ce qu'elle a copié elle-même, mais rien de ce que les autres ont copié.

Android dans sa version de base n'est pas resté les bras croisés sur ce sujet, mais il s'est arrêté en chemin et depuis Android 10, seules l'application affichée à l'écran et le clavier par défaut peuvent lire le presse-papiers, ce qui a fermé la porte à celles qui tournent en arrière-plan. Puis Android 12 a ajouté une notification à la première lecture d'un contenu venu d'ailleurs, et enfin Android 13 vide le presse-papiers au bout d'un moment.

Mais depuis, plus rien...

Le trou qui reste, Microsoft l'a documenté en mars 2023. La version 7.9.2 de l'application SHEIN (oui, le site de fringues), téléchargée plus de cent millions de fois, lisait périodiquement le presse-papiers, et si elle y trouvait en même temps un signe dollar et un "://", elle expédiait le contenu vers un serveur distant.

Et la restriction d'Android 10 n'a rien empêché, tout simplement parce que l'application tournait au premier plan. Le comportement problématique de l'app SHEIN a ensuite disparu en mai 2022, après un signalement à Google, mais le problème de fond n'a jamais été réglé. Et j'imagine que d'autres apps actuellement sur le PlayStore appliquent la même technique sans que personne ne l'ait encore remarqué.

Secure paste de GrapheneOS s'attaque donc à ça en changeant la règle plutôt qu'en ajoutant un avertissement, et cette fois être affiché à l'écran ne donne plus droit à rien. Une application privée d'accès sait toujours qu'un élément est disponible, et peut en inspecter le type, l'horodatage de copie et la présence de mise en forme. Mais le contenu lui-même, son libellé et ses données annexes ne lui sont plus offerts sur un plateau d'argent.

Et le "collage" continue de marcher lui, parce que c'est vous qui l'autorisez. Que vous colliez depuis la barre de sélection de texte, depuis le clavier, depuis un service d'accessibilité ou avec un raccourci clavier, le système délivre une autorisation courte, liée à l'application qui reçoit et à l'élément en cours. Et pour les applications qui dessinent leur propre barre de sélection, comme celles codées en Flutter, un bouton "Coller" est visible dans le clavier par défaut.

Le plus vif d'esprit qui me lisent sont déjà debouts sur leur chaise et hurlent à travers leur écran : Et comment ça se passe pour "couper" ? Qui décide ?? Hé bien le réglage existe en version globale et par application, et il est autorisé par défaut, pour ne rien casser des applications déjà installées. Autrement dit, personne ne sera protégé sans l'avoir décidé et c'est à vous d'aller basculer en collage seulement celles à qui vous ne faites pas confiance.

Maintenant, calmez-vous les groupies de GrapheneOS parce que rien de tout ça n'est encore livré. Le code est visible dans une pull request ouverte depuis le 22 août dernier mais toujours pas fusionnée. GrapheneOS dit vouloir l'intégrer bientôt, sans donner de date et le mécanisme ne porte que sur la lecture, donc il ne dira rien des applications qui écrivent dans le presse-papiers pour y remplacer ce que vous venez de copier (coucou les détourneurs de transactions crypto)...

La même annonce parle aussi de l'application Messaging, dont l'interface vient d'être refaite en Compose, et le projet lâche au passage un chantier autrement plus lourd : faire du RCS directement dedans, chiffrement de bout en bout compris, pour ne plus avoir besoin de Google Messages. Héhé... Aujourd'hui, RCS marche très bien sur GrapheneOS, mais uniquement avec l'application de Google et sa couche Google Play isolée et c'est de ça dont ils veulent se passer.

Comme le RCS n'est pas une plateforme ouverte en pratique (pas autant que le SMS et le MMS quoi) et que tout cela repose sur l'infrastructure de Google et des opérateurs, le plan, c'est donc de refaire d'abord la partie que Google Messages assure, en gardant Google Play isolé pour l'activation, puis de s'en passer chez les opérateurs qui le permettent... à condition qu'ils acceptent le client de GrapheneOS, ce qui n'est pas gagné...

Quand je pense que Google, ces grands hypocrites qui ont passé des années à réclamer qu'Apple adopte RCS au nom de l'ouverture, coupe lui-même le service depuis 2024 sur les téléphones rootés et une partie des ROM alternatives. GrapheneOS y échappe mais ça donne quand même l'idée de l'accueil qu'un client maison pourrait espérer... On verra bien.

Mais bon, si vous êtes sur GrapheneOS, je serais vous, je surveillerais cette histoire de presse-papiers sécurisé parce que quand ça arrivera, vous serez encore plus béton face aux apps problématiques.

Source : le fil d'annonce de GrapheneOS et Android Authority

Le projet Asahi Linux vient enfin de fusionner le support des Mac M3 dans son installateur. En clair, ça veut dire que si vous avez un MacBook Air, un MacBook Pro ou un iMac équipé d'un M3, d'un M3 Pro ou d'un M3 Max, vous pouvez y installer Linux dès maintenant.

Et la liste de ce qui fonctionne est plus longue que ce que je pouvais craindre. La webcam, les micros internes, le WiFi, le Bluetooth, l'USB 3 jusqu'aux 10 Gb/s permis par la machine, et le décodage vidéo accéléré, AV1 compris.

Le Thunderbolt aussi, est même arrivé cet été. Apple avait troqué, sur les M3 Pro et M3 Max, son vieux contrôleur de ports USB contre une puce ACE3 posée sur un bus SPMI au lieu de l'I2C. Il a donc fallu reverse tout ce petit monde afin que l'USB 3 et le Thunderbolt marchent sur l'ensemble de la gamme M3.

Si vous voulez vous lancer, l'installation doit encore passer par le mode Expert de l'installeur, parce que c'est encore tout frais. Mais quand la bêta de Fedora Linux 45, sera implémentée d'ici quelques semaines, ça devrait fonctionner en install normale.

Après le gros manque, c'est la 3D. N'attendez ni performances, ni accélération 3D économe en énergie puisque tout est géré par la partie CPU du M3. Et ce n'est pas de la mauvaise volonté de la part des dev puisque le GPU du M3 s'écarte nettement de celui des M1 et M2 : ray tracing matériel, mesh shaders, et le Dynamic Caching maison d'Apple. Il y a donc énormément à refaire et même si le chantier a commencé, pour le moment, on n'a pas de date.

Les autres limites ont l'air nettement moins définitives comme pour la mise en veille qui ne fonctionne pas et le port HDMI des MacBook qui est coupé. Cela s'explique par le fait que le composant DCP qui gère ces 2 aspects là c'est pas encore piloté par Asahi, mais ça ne devrait pas tarder.

Le Mac Studio, lui, reste à la rue. Le M3 Ultra n'est pas supporté, et les M4 et M5 en sont au tout début, avec le stockage, le PCIe et le démarrage multicœur qui tournent mais pas grand-chose d'autre. Donc plus votre machine est récente, plus il va falloir être patient...

Perso, j'avais un iMac M3 et franchement, j'ai été très déçu par cette machine. Pour de la bureautique ça allait très bien, mais dès qu'on bidouille un peu fort, ça pédale dans la semoule. Je suis donc passé au Mac Studio depuis et je ne le regrette pas une seconde.

En tout cas, je sais que si je veux recycler ce "vieil" iMac M3, je peux maintenant lui installer Linux... ça vaut peut-être le coup, à condition d'assumer un desktop sans la moindre accélération 3D ^^.

Source : le billet d'annonce d'Asahi Linux et Neowin .