Le MCP est l’USB-C de l’IA, et c’est la seule révolution qui compte vraiment
![]()
Utilisez-vous Google News (Actualités en France) ? Vous pouvez suivre vos médias favoris. Suivez Frandroid sur Google News (et Numerama).
![]()
Utilisez-vous Google News (Actualités en France) ? Vous pouvez suivre vos médias favoris. Suivez Frandroid sur Google News (et Numerama).
Nvidia attire l’attention des joueurs PC sous Linux après la publication de plusieurs offres d’emploi très explicites.
Cet article Nvidia recrute pour booster le jeu sous Linux a été publié en premier par GinjFo.
Linux 7.0-rc1 assure une prise en charge initiale de Nova Lake, Diamond Rapids et Zen 6 et de nouvelles fonctions côté performances.
Cet article Linux 7.0-rc1 est là avec le support de Nova Lake et Zen 6 a été publié en premier par GinjFo.
AsteroidOS , c'est une distro Linux open source qui tourne... sur des montres connectées ! Oui oui, du manchot au poignet et l'idée en fait, c'est de virer WearOS et toute la télémétrie Google qui va avec, pour le remplacer par un OS libre sans tracking ou de compte à se créer.
Ce projet existe depuis 2015 et supporte aujourd'hui une trentaine de montres (LG Watch, Huawei Watch, TicWatch, Asus Zenwatch, Fossil Gen 4/5/6...). Vous flashez votre tocante connectée, et vous récupérez un OS avec agenda, météo, chronomètre, boussole, moniteur cardiaque, contrôle musical et même un petit jeu. Le tout en Qt/QML, avec des cadrans communautaires et un affichage permanent !
Côté vie privée , c'est même le JOUR ET LA NUIT avec WearOS donc pour ceux qui flippent que leur montre balance tout à Mountain View, c'est plutôt rassurant.
Pour la synchro avec votre téléphone, y'a également AsteroidOSSync sur F-Droid ou Gadgetbridge . Si vous hésitez, sachez que Gadgetbridge est plus maintenu et plus universel. Ça couvre l'essentiel et si vous avez les chocottes, un mode dual-boot permet de tester sans virer WearOS.
Attention par contre, c'est pas la fête du slip non plus car y'a pas de store d'apps (faut pousser les APK en ligne de commande via ADB), pas de réponse aux appels depuis le poignet, et les apps WearOS ne tournent évidemment pas dessus. A moins que votre montre soit dans la liste officielle, n'y pensez même pas ! Faut aimer bidouiller, en fait mais ça, je sais que vous adorez ^^.
Et grâce à cet OS, vous atteindrez peut-être les 48h d'autonomie annoncées sur le site. Après faut voir en vrai évidemment... mais pour une distro communautaire portée par des passionnés depuis 11 ANS quand même, c'est honnête.
Merci à l'ami Lorenper pour la découverte !




KDE Plasma 6.6 apporte un gestionnaire de connexion inédit, de l’OCR dans l’outil de capture d’écran et de nombreuses améliorations pour les joueurs.
Cet article KDE Plasma 6.6 débarque, quelle amélioration change réellement l’expérience ? a été publié en premier par GinjFo.
Sur le marché des PCs, Windows profite d'une position dominante depuis des décennies. Pourquoi Linux n'arrive pas à percer ?
Cet article Pourquoi Windows domine toujours Linux sur le marché des PC ? a été publié en premier par GinjFo.
Vous trouvez que votre Linux met 3 plombes à démarrer et vous regardez l'écran de boot défiler en vous demandant ce qui peut bien prendre autant de temps ? ...
Vous trouvez que votre Linux met 3 plombes à démarrer et vous regardez l'écran de boot défiler en vous demandant ce qui peut bien prendre autant de temps ?
Hé bien bonne nouvelle los amigos del manchos, si vous utilisez une distribution basée sur systemd (comme Debian, Ubuntu, Fedora, Arch, et compagnie), il existe un outil natif déjà installé qui permet de diagnostiquer tout ça : systemd-analyze
Ce truc c'est un peu le médecin légiste de votre démarrage système. Il dissèque chaque étape, identifie les unités qui traînent la patte, et vous permet de comprendre où part votre précieux temps. Pour ceux qui débarquent, systemd est le système d'initialisation adopté par la plupart des distributions modernes, et il permet justement de lancer plein de trucs en parallèle pour gagner du temps.
Pour commencer, la commande de base c'est tout simplement :
systemd-analyze time
Elle vous sort un récapitulatif du temps passé dans chaque phase, généralement le kernel, l'initrd (le RAM disk initial), et l'espace utilisateur. Selon votre configuration, vous pourriez aussi voir passer le firmware ou le bootloader. Ça donne un truc du genre "Startup finished in 2.5s (kernel) + 19s (initrd) + 47s (userspace)". Déjà là, vous savez si le problème vient de votre noyau ou de vos services.
Mais le truc vraiment cool pour fouiller un peu plus dans le détail, c'est :
systemd-analyze blame
Cette commande vous balance la liste des unités systemd, triées par le temps qu'elles ont mis à s'initialiser. C'est un peu comme un classement des cancres de la Ve République. Vous voyez direct qui sont les boulets qui ralentissent tout le monde. Genre ce service réseau qui attend 20 secondes une connexion qui n'arrivera jamais, ou ce truc de logs qui prend son temps pour se réveiller.
Attention quand même, y'a un petit piège car un service qui met 10 secondes à démarrer ne signifie pas forcément que votre boot est rallongé de 10 secondes. Pourquoi me diriez-vous ? Hé bien parce que systemd lance plein de trucs en parallèle. Un service peut donc prendre son temps tranquille pendant que d'autres bossent en même temps sans bloquer personne.
Pour vraiment piger ce qui coince sur le chemin critique, lancez plutôt :
systemd-analyze critical-chain
Ça, c'est le top car ça vous montre la chaîne critique, c'est-à-dire la séquence exacte d'événements qui détermine vraiment votre temps de démarrage final. Vous voyez exactement quelles unités sont sur le chemin et lesquelles attendent les autres. Le temps après le "@" indique quand l'unité est devenue active, et le temps après le "+" montre combien de temps elle a pris pour démarrer. C'est bien plus fiable que blame pour identifier les vrais goulots d'étranglement.
Et si vous êtes du genre visuel, y'a même :
systemd-analyze plot > boot.svg
Et avec ça, hop, ça génèrera un magnifique graphique SVG qui représentera la chronologie de votre séquence de boot. Vous pourrez ensuite l'ouvrir dans votre navigateur et voir en un coup d'oeil ce qui démarre quand et combien de temps ça dure. C'est super pratique pour épater la galerie ou juste visualiser l'ordre de lancement.
Maintenant, une fois que vous avez identifié les coupables, comment on fait pour accélérer tout ça ?
Déjà, vous pouvez désactiver les services dont vous n'avez pas besoin avec :
sudo systemctl disable nom-du-service
Gardez en tête que disable supprime seulement le lancement automatique au boot, mais n'empêche pas une activation indirecte via une dépendance ou un socket. Si vous voulez vraiment qu'un service ne démarre plus jamais, utilisez mask. Et surtout, ne désactivez pas n'importe quoi comme un bourrin, hein ! Je vous connais ! Non, non, avant de toucher à un service, vérifiez d'abord ce qui en dépend :
systemctl list-dependencies nom-du-service
Car si vous cassez un truc important, votre système risque de ne plus démarrer correctement. Donc si vous n'êtes pas sûr, gardez vos mimines dans vos poches. D'ailleurs, si vous bidouillez vos fichiers d'unité (comme pour automatiser Shiori par exemple), sachez que vous pouvez aussi les vérifier pour débusquer les erreurs avec :
systemd-analyze verify /chemin/vers/unite.service
C'est super pratique pour éviter les mauvaises surprises au prochain redémarrage. Voilà et si vous cherchez d'autres astuces pour optimiser votre machine Linux , n'hésitez pas à jeter un oeil à mon article sur TLP.
Ah j'oubliais, y'a aussi la commande systemd-analyze security qui permet d'analyser le niveau d'exposition sécurité de vos services. Elle attribue un score heuristique d'exposition basé sur les options de durcissement (hardening) actives. Plus le score est bas, mieux le service est protégé contre d'éventuelles failles. C'est donc un excellent point de départ pour identifier les services qui mériteraient un peu plus de love côté isolation.
Bref, cet analyseur de démarrage c'est vraiment l'outil indispensable pour qui veut comprendre et optimiser son boot Linux. C'est natif, c'est puissant, et ça vous évite de passer des heures à chercher pourquoi votre machine met autant de temps que vous à se réveiller le matin ^^.

Pourquoi les protections anti-triche des jeux (surtout l'apanage des titres compétitifs) ne peuvent fonctionner sur Linux, et donc Steam Deck.
GNOME 50 entre en bêta publique avec gel des fonctionnalités. Voici une bilan des avancées et des nouveautés les plus importantes.
Cet article GNOME 50 propose Wayland par défaut, VRR natif et de nombreuses améliorations a été publié en premier par GinjFo.