Le Fire TV Stick 4K Select d'Amazon ne tourne pas sous Android. Il tourne sous Vega OS, un système maison basé sur Linux, et ça va foutre en l'air vos projets de player pour votre média center puisque les applications Android n'y ont plus cours, et que l'installation manuelle est verrouillée. Il n'y a donc plus de bascule "sources inconnues" planquée dans les réglages, comme sur les Fire TV sous Android. Rien que pour faire apparaître les options développeur, il faut d'abord enregistrer l'appareil auprès d'Amazon avec un compte développeur et même comme ça, aucun APK Android ne se lancera. Résultat, Kodi ne tourne pas ! L'application avait déjà été retirée du store d'app Amazon en 2015, mais on la réinstallait tous à la main sur les anciens sticks. Eh bien ce contournement n'est plus possible et côté Jellyfin, malheureusement, le projet n'a toujours pas sorti de client pour Vega OS. Bref, Amazon a verrouillé la machine au nom de la sécurité et de la chasse au piratage, comme prévu puisque je vous en parlais déjà en novembre dernier . Sauf que le même verrou bloque aussi la lecture des fichiers qui dorment par exemple sur votre NAS, même si vous les avez rippés vous-même, peu importe que ce soit le dernier Avatar ou une vidéo de vacances. Et ce n'est pas un accident de parcours sur un modèle d'entrée de gamme puisque sur sa page développeur , Amazon écrit qu'à partir du 4K Select, tous les futurs Fire TV Stick tourneront sous Vega, donc il n'y aura plus de retour arrière, désolé... Par contre, les modèles sous Fire OS restent en vente pour l'instant, et eux acceptent toujours l'installation manuelle. Donc si vous comptiez remplacer le vôtre un jour, vérifiez le nom exact de la référence avant de commander, c'est maintenant que ça se joue ! Sur un stick qui serait déjà passé à Vega, il reste toutefois Astra, un client tiers compatible Jellyfin et Emby, dispo sur le magasin Amazon mais limité à une lecture basique. Plex passe aussi, mais en H.264 seulement, sauf à transcoder côté serveur. Et de son côté l'équipe Jellyfin dit travailler sur un vrai client Vega sans annoncer de date... Voilà, donc pour le moment c'est compliqué avec Vega mais j'ai bon espoir que des bidouilles et nouveaux outils sortent dans les mois qui viennent. Source

La dernière release candidate de Linux 7.2 est bien plus "grosse" qu'elle ne devrait l'être à ce stade du cycle, mais cela n'a pas empêché Linus Torvalds de la publier dimanche en attribuant ce trop-plein aux outils IA qui relisent le code du noyau. "Je ne peux pas dire que la taille de tout ça m'enthousiasme, mais c'est comme ça : la nouvelle normalité, avec beaucoup de correctifs, dont beaucoup viennent de la revue par divers outils IA." Rien ne lui paraît effrayant pour autant, et il ne voit aucune raison de retarder la 7.2. Une grosse taille pour ce noyau, ça veut dire plus de 400 correctifs, signés par plus de 230 personnes alors que dans une Release Candidate en général, c'est le moment où le noyau est censé se calmer avant la sortie. Alors que là, ça ressemble plutôt à un nouveau début de cycle. Et ça tape de partout : Pilotes graphiques, son, réseau, systèmes de fichiers, code d'architecture. Les plus gros blocs viennent de s390 et zcrypt, de btrfs qui remet en place une infrastructure interne, et de correctifs netfilter ipset. Mais attention au contresens, parce que je l'ai vu passer sur certains tweets d'anti-IA. Torvalds parle de revue de code par des outils IA, et pas d'une IA qui écrirait le noyau à sa place. Sa position de fond, Vincent nous la racontait en juillet quand il envoyait les anti-IA forker le noyau. Ici, ça ne concerne que des outils qui relisent du code existant et signalent des trucs douteux. Après derrière, ce sont des humains qui trient. À titre d'exemple, l'un des correctifs de cette rc7 traite un use-after-free dans ptdump, l'interface qui affiche les tables de pages du noyau en clair pour repérer les problèmes de mémoire. C'est ce type de bug qui se transforme en faille et il était là depuis mars 2018 (depuis Linux 4.16). C'est Syzbot , le robot qui bombarde le noyau d'entrées tordues en continu, qui a levé le lièvre en juin dernier. David Carlier a écrit un premier correctif en s'aidant de Claude Opus 4.8 pour remonter la piste, et Lorenzo Stoakes, mainteneur de la gestion mémoire, l'a retravaillé avant qu'il parte dans la rc7. Il devrait ensuite être rétroporté vers les noyaux stables, donc vers les machines qui tournent aujourd'hui. Autre exemple, Greg Kroah-Hartman, qui traque déjà des bugs du noyau avec une IA locale , vient de faire retirer le pilote Moxa Intellio, soit près de 2200 lignes écrites en 1999 qui supporte certaines cartes série multiports. Alors pourquoi est-ce qu'il a fait ça ? Eh bien il écrit dans son patch que : "C'est un très vieux pilote, aucun matériel connu ne circule encore pour lui, et la société dit ne plus en avoir besoin, alors retirons-le puisque les LLM commencent à venir le titiller et à y trouver des choses "intéressantes" qui vont juste faire perdre du temps à tout le monde, vu qu'il ne sert plus...". Voilà donc un autre effet de l'analyse de code par IA. Elle oblige les mainteneurs de projet à tailler dans le gras pour virer du code obsolète que des modèles de langage viendraient renifler d'un peu trop près. Ça ne peut pas faire de mal. Pour moi, le vrai risque de ces outils sur un projet ouvert tient au volume. Un flot de signalements produits par des gens qui ne relisent pas ce qu'ils envoient, où plus personne ne distingue l'hallucination du vrai bug, et là ça partirait en eau de boudin. Mais comme le noyau, lui, garde des mainteneurs qui comprennent les tenants et les aboutissants de ce qu'ils lisent, ça se passe très bien. Même si la quantité de problèmes remontés surprend Linus. Voilà, si cette nouvelle version du noyau vous intéresse, sachez qu'elle devrait normalement sortir la semaine prochaine en version finale. Source