❌

Vue normale

Reçu hier — 16 février 2026 ⏭

Systemd-analyze - L'outil indispensable pour accélérer son boot Linux

✇Korben
Par : Korben
16 février 2026 à 09:46

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 ^^.

Ubuntu 26.04 « Resolute Raccoon » dévoile sa mascotte officielle

✇Le Crabe Info
Par : Pierre Caer
16 février 2026 à 09:37
Canonical vient de lever le voile sur la mascotte officielle d’Ubuntu 26.04 LTS « Resolute Raccoon ». Ce nouveau visage de la distribution Linux adopte le style géométrique minimaliste qui caractérise l’identité visuelle d’Ubuntu depuis plusieurs versions. Une tradition bien ancrée chez Ubuntu, qui attribue depuis toujours un nom de code animalier à chacune de ses versions. … Lire la suite

Source

GNOME 50 propose Wayland par défaut, VRR natif et de nombreuses améliorations

✇GinjFo » Actualités
Par : Jérôme Gianoli
16 février 2026 à 09:35

GNOME 50GNOME 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.

Reçu — 15 février 2026 ⏭

Linux 7.0 se profile : un changement de numéro « cosmétique », mais un tournant très réel avec Rust

✇BlogNT : Le Blog des Nouvelles Technologies dédié au Web, aux nouvelles technologies et au développement Web
Par : Yohann Poiron
15 février 2026 à 07:50

Le noyau Linux s’apprête à changer de décennie… au moins dans la manière dont on le nomme. Après la sortie de Linux 6.19, Linus Torvalds a confirmé que la prochaine branche s’appellera Linux 7.0 — non pas pour célébrer une refonte spectaculaire, mais parce que les numéros « deviennent trop grands » à ses yeux. Une décision fidèle à […]

L’article Linux 7.0 se profile : un changement de numéro « cosmétique », mais un tournant très réel avec Rust est apparu en premier sur BlogNT : le Blog des Nouvelles Technologies.

Reçu — 12 février 2026 ⏭

Linus Torvalds critique les nouvelles fonctionnalités de Linux 7.0

✇Informaticien.be
Par : none@none.com (Nic007)
12 février 2026 à 14:55
La communauté open source est de nouveau en émoi. Linus Torvalds a rejeté un ensemble de modifications du sous-système MMC prévu pour le noyau Linux 7.0. Lors d'une discussion publique, il a qualifié ces propositions de « pure camelote » et de « camelote non testée », et a annoncé qu'il ne les intégrerait pas à la prochaine version du système. Les propos acerbes ne sont pas nouveaux de sa part, mais cette fois-ci, il s'agit d'un fragment de code gérant la mémoire flash et la communication avec de nombreux appareils populaires, ce qui n'a pas forcément été bien accueilli par la communauté et les développeurs. Les auteurs du correctif prévoyaient de nombreuses mises à jour, notamment l'ajout d'identifiants pour les nouveaux chipsets NXP IW61x prenant en charge le Wi-Fi sur SDIO. La prise en charge des appareils commercialisés après 2025 était également prévue. Le package comprenait également des modifications relatives au mécanisme d'effacement sécurisé et de TRIM pour certaines cartes eMMC Kingston, une prise en charge étendue du processeur mobile MediaTek MT8189 dans le pilote mtk-sd, ainsi que des refontes du code des composants SHDCI et DW_MMC. Du point de vue des fabricants de matériel, il s'agissait d'une étape indispensable avant la prochaine version majeure du noyau. Torvalds ne remettait pas en cause le principe même du développement du sous-système. Ses principales réserves concernaient la préparation des modifications. Il estimait que les auteurs n'avaient pas effectué les tests nécessaires sur la branche linux-next, utilisée pour la vérification de la compatibilité et la détection des conflits. Lors de leur échange, il a relevé des erreurs précises. Après l'intégration de certains codes, la compilation du noyau a échoué. Pour le responsable du projet, il s'agit d'une limite à ne pas franchir. Le créateur de Linux dirige le développement du système depuis le début des années 1990. Au fil des décennies, il a habitué la communauté à un langage direct et à la dénonciation publique des erreurs. Ces dernières années, ces situations sont devenues de plus en plus fréquentes, suscitant à chaque fois un débat sur la culture d'entreprise au sein de l'un des projets informatiques les plus importants au monde. De nombreux développeurs acceptent ces règles strictes, tandis que d'autres font état de découragement et d'épuisement professionnel. Malgré ces divergences, l'autorité de Torvalds en matière technique demeure incontestable, notamment lorsqu'il s'agit de signaler des bogues susceptibles de bloquer la mise en production d'un système. Cette fois, la colère de Torvalds semble justifiée. Parmi ses critiques acerbes adressées aux auteurs du correctif, il a pointé du doigt plusieurs bogues spécifiques engendrés par ces mises à jour. Si le code proposé est intégré au noyau, la compilation échouera. Le chef de projet a clairement indiqué qu'il ne souhaitait plus recevoir de propositions des auteurs du paquetage défectueux dans le cadre du cycle de développement de Linux 7.0. Les modifications ont été reportées à la phase d'intégration de la version 7.1. Les développeurs devraient les présenter après une série complète de tests réalisés conformément aux procédures en vigueur. Le calendrier de publication prévoit la sortie de Linux 7.0 au printemps 2026. Une nouvelle discussion sur le sujet sera ouverte peu après. Pour les entreprises qui attendent de nouvelles fonctionnalités, cela implique un délai de plusieurs semaines et la nécessité d'assurer la maintenance de leurs solutions existantes. (Lire la suite)
Reçu — 11 février 2026 ⏭

Medulla

✇Les bons liens du Gégé...
10 février 2026 à 14:30

Medulla est une plateforme complète de gestion informatique pensée pour simplifier, automatiser et sécuriser l’ensemble des opérations liées à un parc informatique, qu’il soit en entreprise, en télétravail ou distribué sur plusieurs sites.
— Permalien

Reçu — 10 février 2026 ⏭
Reçu — 9 février 2026 ⏭

Linus Torvalds appuie sur le bouton de réinitialisation. Linux 7.0 arrive.

✇Informaticien.be
Par : none@none.com (Nic007)
9 février 2026 à 16:46
Linus Torvalds a annoncé que la prochaine version du noyau sera numérotée 7.0. C'est un rituel pour la communauté open source depuis des années, mais chaque changement du premier chiffre déclenche une vague de commentaires, d'analyses et de blagues. Cette décision s'inscrit dans la convention bien établie qui consiste à terminer une série autour du nombre dix-neuf. C'était le cas pour les lignes 3.x, 4.x, 5.x et maintenant 6.x. Tout porte à croire que cette pratique perdurera. La numérotation est devenue prévisible à partir de la série 3.x. Après dix-neuf versions, la 4.0 est arrivée. Entre-temps, Torvalds s'adonnait à quelques plaisanteries. La version 3.11 a été surnommée « Linux pour groupes de travail », un clin d'œil au nom historique de Windows 3.11. Lors de la transition depuis la série 4.x, le créateur du noyau a même évoqué la version 4.21, mais a finalement opté pour la 5.0. Il a expliqué qu'il n'avait plus assez de doigts ni d'orteils pour compter davantage. Il a souligné à plusieurs reprises que le changement d'un grand nombre n'avait aucune signification particulière et ne représentait pas une avancée technologique majeure. Un schéma similaire se répète. La série 6.x touche à sa fin, et Torvalds a admis que ces grands nombres commençaient à le désorienter. La suite est donc logique. Ce changement de numéro attire l'attention, mais pour les administrateurs et les développeurs, le contenu est plus important. La prochaine version inclut des solutions attendues de longue date par les opérateurs de centres de données et les développeurs d'infrastructures virtuelles. Les observateurs de Phoronix soulignent le lancement de l'outil Live Update Orchestrator. Ce mécanisme permet d'effectuer des mises à jour du noyau tout en maintenant les machines virtuelles en fonctionnement. Il prend également en charge la communication chiffrée entre les périphériques PCIe et les environnements virtuels. Comme d'habitude, la prise en charge des dernières fonctionnalités des processeurs Intel et AMD a été étendue. Des améliorations sont également apportées à l'architecture RISC-V et aux puces conçues en Chine. Des pilotes, des composants de gestion de l'alimentation et des composants d'optimisation des performances du système de fichiers sont en cours de développement. L'une des modifications les plus discutées concerne la couche réseau. La suppression d'un bloc occupé spécifique vise à influer sur la vitesse à laquelle les tampons de transmission sont vidés. Des débits de données nettement supérieurs ont été observés dans certains scénarios de test. Bien que ces différences soient imperceptibles pour l'utilisateur final, les opérateurs de grandes installations et les fournisseurs de services cloud suivent de près ces évolutions. Chaque détail de cette partie de l'architecture a un impact sur les coûts de maintenance de l'infrastructure. (Lire la suite)
Reçu — 7 février 2026 ⏭
❌