Nasra's games

A short blog about games and Linux

Je reprend ici une documentation que j'avais déjà faite en septembre 2024.

Fonctionnement de SecureBoot

Dans les années 2010, les bootkits (pour “boot rootkit”) sont des menaces informatiques dangereuses. Ce sont des logiciels malveillants capables de corrompre le démarrage du système d’exploitation, de se charger très tôt (avant l'OS) et avoir des privilèges d’exécution très bas. Ils peuvent donc prendre la main sur un système informatique bien avant les antivirus pour contrôler entièrement le système. Ainsi, les attaquants gagnent en persistance sur l’appareil.

Schéma d'exécution de SecureBoot

Pour se protéger des bootkits, l’UEFI apporte entre autre le mécanisme de SecureBoot (démarrage sécurisé). SecureBoot est un mécanisme de vérification pour garantir que le code lancé par le firmware est fiable avec des clés de chiffrement.

Parcours de validation des clés

SecureBoot ne permet donc pas de lancer les pilotes tiers non singés ! Tiens ! Sans désactiver SecureBoot (ce qui poserait des soucis de sécurité)... il est possible d'utiliser des pilotes propriétaires sur Linux, en recréant des clés MOK de sécurité ! Si vous possédez du matériel Razer c'est indiqué dans leur documentation.

La solution !

Vérifier si SecureBoot est présent : mokutil --sb-state Recréer les clé SecureBoot : sudo update-secureboot-policy --enroll-key (si cela ne fonctionne pas faire : sudo update-secureboot-policy --new-key )

Configurer SecrureBoot Entrer un mot de passe temporaire Configurer SecrureBoot Mot de passe temporaire Redémarrer le PC Au démarrage, il vous propose cet écran, choisissez le second choix Enroll MOK.

Enroll MOK Entrer le mot de passe temporaire, le PC va redémarrer...

Et les pilotes Nvidia seront lancés... et les souris Razer aussi (et tout le matériel qui demande des autorisations spécifiques) !

Victory

#Nvidia #Mint #SecureBoot #Razer #Linux


Je vous en ai parlé précédemment, mais je n'appréciais pas trop la “hype” autour de Wayland en 2022/2023 ni le forçage de certaines distributions pour son adoption par les utilisateurs (en enlevant la possibilité de repasser sous X11 ou en la complexifiant...). Bref, heureusement, les choses évoluent, Wayland semble de plus en plus mature (pour un projet aussi ancien et crucial pour les environnements Linux, c'est bien !).

GIMP, vers la 3.0

Principal soucis de Wayland c'est celui des applications graphiques professionnelles. GIMP, Inkscape, Scribus, Krita... sont des logiciels très complexes au développement parfois chaotique avec de petites équipes.

Les développeurs de GIMP ont pu, pour la sortie très attendue de la version 3.0 de leur logiciel, travailler avec les équipes derrière Wayland pour ajouter des protocoles manquants pour la prise en charge de tablettes et de dispositifs de pression (pour le dessin). Et c'est une chouette évolution de Wayland et de leurs équipes sur ce sujet ! Là où ils étaient assez obtus dans leur développement (ne voulant pas développer de nouveaux protocoles, renvoyant la faute sur les développeurs d'applications ou de compositeurs graphiques...).

Belle avancée que voici et nous attendons encore plus la version finale de GIMP 3.0 !

Gamescope et le Variable Refresh Rate (ou VRR)

Le VRR c'est la possibilité d’adapter le rafraîchissement d'une à image à l'affichage. Une application, typiquement un jeu vidéo, va être rendu à 60 images / secondes, avec un écran ayant une vitesse de rafraîchissement de 144Hz cela va donner des potentiels déchirement d'image. Certains jeux ont des chutes de performances selon le rendu de certaines scènes, d'autres vont pouvoir adapter leur rendu en temps réel aux images par seconde souhaitées.

La fréquence de rafraîchissement variable (VRR) permet à une console de jeu ou à un PC de synchroniser l’envoi des images vidéo avec l’écran, ce dernier adaptant sa propre fréquence de rafraîchissement en temps réel pour correspondre à celle de la source. L’objectif est d’éviter le chevauchement d’image, afin d’offrir plus de fluidité et de supprimer les déchirements d’images.

C'est aussi une technologie qui permet de limiter la latence entre les commandes envoyées et leur résultat à l'écran.

Le VRR est supporté par Xorg depuis 2021 sur les cartes Intel, AMD et Nvidia (grâce à G-Sync).

Gamescope, un petit utilitaire de Valve très utile pour le jeu vidéo commence à prendre en charge le VRR pour un rendu agnostique (ne dépendant pas, dans le jeu et de la présence de la possibilité dans ses options) du VRR.

Nvidia

Ah Nvidia et ses pilotes propriétaires... toute une histoire avec Linux ! À tel point que certains responsables se sont souvent énervés contre la fermeture de l'entreprise aux technologies Linux.

Et bien, depuis quelques années, Nvidia semble avancer dans la bonne direction. déjà, le support d'un module open-source dans les pilotes Nvidia permet d'éviter les fameux écrans noirs habituels des utilisateurs avancés de Linux (quand on change pour un kernel trop récent ou patché à la main par exemple). Et depuis peu, lors de la dernière conférence de Nvidia, les développements autour de Wayland se sont accélérés. À tel point qu'ils recommandent maintenant des distributions avec Wayland et Vulkan par défaut pour les compositeurs.

Espérons qu'avec toutes ces avancées, Wayland puisse rattraper Xorg dans ses fonctionnalités.

#wayland #xorg #gimp #nvidia #valve #steamdeck #gamescope


Je n'ai pas souvent l'occasion de toucher à un Linux Mint, mais j'ai dû aider une personne avec son PC portable. Petit contexte : cette personne passe de Win 11 à Linux Mint, son PC dispose d'un GPU Nvidia 1050.

Contexte et premiers conseils

On migre tout ce qu'on peut sur des services cloud (kDrive, Nextcloud...), on vérifie que les logiciels qu'il utilise sont possibles sur Linux.

On passe sur une nouvelle installation mais par sécurité, on change physiquement de disque NVMe. Il range son disque Windows 11 dans une boîte et il le remplace par un nouveau disque NVMe, acheté pour la migration, pour installer Linux Mint. Ça permet de garder les données et une roue de secours au cas où, et ça rassure !

Installation

Après avoir confectionné la clé USB d'installation de Linux Mint sous Windows (héhé). On éteint le PC, débranche la batterie, ouvre le PC, enlève la batterie, on remplace le disque par le neuf, on rebranche, revisse le tout et on allume !

On sélectionne la clé USB pour le démarrage, et on installe Linux Mint ! On connecte les services cloud (kDrive, Nextcloud...), on se connecte aux service de Firefox pour retrouver mots de passe et marque-pages...

Bref, tout fonctionne bien !

Premiers soucis

Deux choses ne fonctionnent pas dès la remise en route : La souris Razer et l'affichage de son second écran externe sur le port HDMI.

Razer et OpenRazer

On se concentre sur la souris (pas cool au quotidien), on installe OpenRazer, on regarde comment ça fonctionne. On n'y arrive pas, mais on voit bien qu'il peut y avoir un soucis avec SecureBoot. Par soucis de “pouvoir retrouver Windows 11 un jour”, on ne le désactive pas et on passe notre chemin ! (même si on aurait dû creuser le truc...). Parce que, notamment pour la personne, ce n'est pas son soucis le plus bloquant pour son activité.

Écran externe

Là, on rentre dans le dur du sujet. Premier soucis, les pilotes Nvidia : ils sont installés mais ne semblent pas fonctionnels. Pire, on ne les retrouve pas dans les pilotes utilisés alors qu'ils sont bien installés dans la logithèque, qu'on a bien nvidia-settings d'installé...

Réinstallation des pilotes, redémarrage... rien n'y fait ! Quelque soit le pilote installé, on ne voit pas les settings complets dans nvidia-settings (un signe qu'il y a un soucis) et bien entendu, l'écran externe, branché en HDMI, ne fonctionne pas.

Nomodeset

Je me rappelle de mes anciennes expériences avec les pilotes Nvidia, notamment sur ma GTX970, il fallait utiliser le nomodeset=1 dans les paramètres de démarrage du noyau... sudo nano /etc/default/grub Puis ajouter le paramètre nomodeset=1 à la fin de la ligne (avant les “) : GRUB_CMDLINE_LINUX_DEFAULT="quiet" –> non, ce n'est pas ça... :(

Bug avec le noyau 6.8

Linux Mint 22 est livré avec la série 6.8 des noyaux Linux. Apparemment, un bug affecte le noyau 6.8 et les pilotes propriétaires Nvidia...

Ce bug cause des problèmes sur l'application d'affichage et peut-être également à d'autres endroits. C'est un problème d'Ubuntu en amont. Jusqu'à la publication d'un correctif, voici la solution de contournement. Ajouter la ligne : ACTION=="add", SUBSYSTEM=="module", KERNEL=="nvidia_drm", TEST=="/sys/devices/platform/simple-framebuffer.0/drm/card0", RUN+="/bin/rm /dev/dri/card0" Au fichier suivant : /lib/udev/rules.d/71-u-d-c-gpu-detection.rules –> toujours pas :(

Résolution !

Retour sur SecureBoot

Dans les années 2010, les bootkits (pour “boot rootkit”) sont des menaces informatiques dangereuses. Ce sont des logiciels malveillants capables de corrompre le démarrage du système d’exploitation pour se charger très tôt et avoir des privilèges d’exécution très bas. Ils peuvent donc prendre la main sur un système informatique bien avant les antivirus pour contrôler entièrement le système. Ainsi, les attaquants gagnent en persistance sur l’appareil.

Pour se protéger des bootkits, l’UEFI apporte entre autre le mécanisme de SecureBoot (démarrage sécurisé). SecureBoot est un mécanisme de vérification pour garantir que le code lancé par le firmware est fiable avec des clés de chiffrement.

Et donc la solution ! SecureBoot qui ne permet pas de lancer les pilotes tiers non singés ! Tiens ! Sans désactiver SecureBoot (ce qui permet de repasser sous Win 11 si nécessaire)... il est possible d'utiliser des pilotes propriétaires sur Linux, en recréant les clés de sécurité ! C'est la même solution qu'on aurait dû essayer depuis le début ! Comme quoi, il fallait creuser le truc !

Je vous donne la solution !

Vérifier si SecureBoot est présent : mokutil --sb-state Recréer les clé SecureBoot : sudo update-secureboot-policy --enroll-key (si cela ne fonctionne pas faire : sudo update-secureboot-policy --new-key ) Entrer un mot de passe temporaire Redémarrer le PC Au démarrage, il vous propose cet écran, choisissez le second choix Enroll MOK. Entrer le mot de passe temporaire, le PC va redémarrer...

Et l'écran sera reconnu ! (le souris aussi au passage ;) )

#Nvidia #Mint #SecureBoot #Razer #Linux


Vous me citerez beaucoup de noms, celui qui reviendra le plus souvent sera Ubuntu. Et c'est normal ! La boîte derrière Ubuntu, Canonical a longtemps trusté les campagnes de communication des distributions Linux. Au début des années 2000, au temps où l'ADSL ou la fibre étaient rares, les distributions Linux étaient principalement distribuées sur des CD dans des magazines spécialisés (et parfois moins spécialisés), puis des DVD jusque dans les années 2010. Depuis, avec la crise de la presse spécialisée, ce sont les sites officiels des distributions qui sont mis en avant pour télécharger les ISO (images disques) des distributions à graver sur CD/DVD et sur clé USB.

Qu'est-ce que ça a changé ?

À mon sens, les distributions Linux sont devenues moins “grand public”. Si dans les années 2000, il suffisait d'acheter un magazine dans un commerce pour installer ou tester Linux sur sa machine, dans les années 2020, il faut s'y connaître un peu plus : savoir ce qu'est qu'une image ISO, savoir “graver” une clé USB bootable avec un logiciel spécialisé… Cela entraîne deux choses : une baisse des utilisateurs réellement débutants et des utilisateurs un peu plus avancés (les années aidant). Alors oui, si aujourd'hui, démarrer sur un DVD ou une clé USB nécessite un petit passage dans le bios pour démarrer sa distribution, sachez qu'à l'époque, vous branchiez votre clé USB ou vous insériez votre CD/DVD et le PC démarrait automatiquement dessus ou vous le proposait au démarrage (pas de “secureboot” relou). Et aujourd'hui, “aller sur un site” suppose que vous cherchiez ce site. Et souvent, les endroits où l'on parle de distributions Linux, ce sont les sites spécialisés, qui attirent des publics déjà sensibilisés.

Comment mesurer la popularité d'une distribution?

Quelles sources de données ?

Il ne suffit pas de faire une recherche Google pour savoir quelle est la distribution la plus populaire. La recherche sur Google ou sur les tendances de recherches comme Trends montre en grande partie les stratégies de communication. Sans les statistiques de Google, pourrait-on se baser sur les statistiques de vues des sites des distributions ? Une entreprise comme Canonical utilise des Google adwords, par exemple, pour augmenter l'efficacité de sa présence, notamment pendant la sortie de versions majeures d'Ubuntu.

On est loin des moyens des communautés de développeurs bénévoles d'une Linux Mint, ou même d'une petite entreprise comme Tuxedo. La présence sur le moteur de recherche ne veut absolument pas dire qu'il y a une grosse communauté, mais juste que la campagne de communication de l'entreprise lui permet plus de visibilité sur le moteur de recherche.

Qu'est-ce que nous analysons ?

Une communauté d'utilisateurs de distributions

Distrowatch est un site qui recense les distributions et se propose de les classer selon celles qui font l'actualité. Le site est une bonne source d'information sur la myriade de distributions existantes. Son principal biais est qu'il analyse sa propre communauté. C'est la communauté du site qui classe les distributions les plus intéressantes (en nombre de vues d'articles, de commentaires...). Si cela peut donner une idée de certaines distributions populaires, le classement de ce site ne mesure en fait que ce que sa communauté a choisi.

Les statistiques basées sur les navigateurs

Statcounter est un site de statistiques se basant sur les “user agent” des navigateurs. Il permet de se faire une idée des proportions en % de tel ou tel système d'exploitation utilisé. Si le site permet de se donner une idée des tendances du marché, ses chiffres sont régulièrement contestés et nous pouvons, par exemple, nous poser des questions sur la probité des chiffres recueillis dans des pays où le réseau est censuré (Chine par exemple).

Les chiffres de la communauté de développeurs, communautés d'entraides…

Un site comme Github permet de connaître les membres d'une équipe de développement (publiée, avec leur activité), Gitlab a les mêmes statistiques et d'autres logiciels comme Redmine peuvent aussi être utilisés.

La taille de la communauté d'entraides est un bon indicateur des utilisateurs. Un groupe de 150 000 personnes qui s'échangent des bonnes astuces sur Ubuntu implique forcément que soit les membres utilisent quotidiennement la distribution soit sont très intéressés par celle-ci (et qu'ils vont y passer tôt ou tard). Là, il s'agit d'identifier les communautés les plus importantes (groupes Facebook, boucles Telegram, forums, canaux IRC, Matrix, Discord...). Les communautés d'utilisateurs sont aujourd'hui éparpillées. Si dans les années 2000, les sites et forums étaient les principales sources pour mesurer la puissance d'une communauté, aujourd'hui, on a les groupes Facebook, les chaînes Youtube, les mentions sur TwiX, les hashtag et tout ce que j'ai cité plus haut...

Petit biais cependant, la plupart de ces canaux ont des utilisateurs inscrits mais peu actifs, des groupes de discussion ayant plus de 2300 utilisateurs peuvent n'avoir qu'une vingtaine d'utilisateurs actifs. Par exemple, les bons taux d'engagement mesurés sur les réseaux sociaux sont ceux-ci : * 1% sur Facebook * 2-3% sur Linkedin * 5% sur instagram

Les communautés d'utilisateurs sont un enjeu important pour les marques, surtout celles qui vendent des services !

Les distributions Linux

Dans notre domaine, les distributions Linux, il y a peu de centralisation de données, peu de statistiques réelles, il faudrait pour cela des chiffres de vente, de téléchargement, des chiffres de télémétrie… mais tous ces chiffres sont ceux des développeurs de ces distributions. Nous n'avons pas la possibilité de les confronter avec la réalité des usages. Nous pouvons pré-supposer qu'ils sont honnêtes, je préfère, pour ma part, douter de chiffres annoncés et peu vérifiables (surtout peu vérifiables).

Des distributions Linux, il y en a beaucoup, mais les plus connues se divisent entre des familles. * La famille Debian, dont sont issues Ubuntu, Mint, ElementaryOS, PopOS... * La famille RedHat avec Fedora, Mageia, CentOS... * La famille Arch, avec Manjaro notamment… * La famille Suse, avec OpenSuse On pourrait rajouter les Slackware, Gentoo ou autres mais partons du principe que ces distributions sont moins utilisées, peu vues même en magazine papier à l'époque. Elles gardent un vrai point d'intérêt, des communautés très accueillantes et parfois une popularité importante dans certains pays (Slackware en Allemagne, par exemple).

Comment analyser ?

  • Première étape, un vrai recensement des communautés et des canaux de discussions/partages.
  • Deuxième étape, compter les utilisateurs totaux dans chaque canal de discussion/partage.
  • Troisième étape, rassembler les informations par distributions mesurées.
  • Quatrième étape, pondérer les résultats avec les biais énoncés plus haut. Appliquer, par exemple, une règle de 90 ou 80% d'utilisateurs non actifs (à vérifier selon les contextes, dans des communautés de passionnés, ces chiffres peuvent être différents).
  • Cinquième et dernière étape, publier !

Conclusion

Analyser les usages est une question régulièrement posée dans les sciences sociales. Une loi a été promulguée, mais comment est-elle appliquée ? Une entreprise communique sur les actions de formation à destination de ses employés, combien de personnes cela concerne-t-il et pour quelles formations ? Une entreprise communique sur ses chiffres de vente, sont-ils honnêtes et vérifiables ?

Dans notre domaine, les distributions Linux, il y n'a pas de chiffres de vente de licences qu'on pourrait recouper avec les chiffres de vente des magasins (par exemple). Les chiffres annoncés sont ceux régulièrement retenus. Dans les jeux vidéo, certains constructeurs comptaient le nombre de consoles vendues comme étant celles distribuées aux points de vente... Un journaliste, peu amène, pourra conclure que puisqu'il y a 20 million de comptes sur Instagram, 15 million sur WhatsApp et 50 million de comptes sur Facebook, qu'il y a 95 million d'utilisateurs d'applications du groupe Meta … en France… pour une population de 68 million… (déjà entendu sur une chaîne de tv spécialisée “économie”)...

Soyons donc honnêtes envers nous-même et les communautés d'utilisateurs de distributions Linux ! Nous pouvons aussi additionner tous les chiffres des distributions pour donner à voir une partie (majoritaire ?) des utilisateurs Linux !

#Linux #Distributions


Quand il s'agit de créer des ressources audio sur Linux, vient tout de suite la question des logiciels. Oui, la plupart des gros logiciels du marché ne sont pas disponibles sur Linux. Vous ne pourrez pas faire tourner FLStudio, ni Ableton Live ou Logic Pro et encore moins Cubase, mais vous aurez -beaucoup- d'autres choix !

Les DAW

Pour Digital Audio Workstation, ce sont des logiciels de composition audio, faisant appel à des plugins pour les effets et le rendu sonore. Il est aussi possible d'ajouter des enregistrements, des échantillons sonores.

Ardour

Waveform

Presonus Studio One

Bitwig

Renoise

Reaper

Les plugins et instruments virtuels !

Alors, au départ je voulais vous faire une liste comme pour les DAW, puis je me suis dit, ce sera pour un prochain article... puis, je suis tombé sur cette perle : https://amadeuspaulussen.com/blog/2022/favorite-music-production-software-on-linux Je n'ai rien à ajouter !

Enfin si ! Quelques ressources en plus : * LinuxDAW * KVRAudio

Et dernière chose avant que vous ne commenciez, certains logiciels sous Linux permettent de faire tourner grâce à Wine-ASIO les plugins VST créés pour Windows, donc n'hésitez pas à tester avec Carla par exemple :


Traduction d'un site très utile pour mieux comprendre le fonctionnement de la RAM sous Linux ! Scoop ! C'est différent de Windows !

Photo de barrettes de RAM

Que se passe-t-il ?

Comme tous les systèmes d'exploitation modernes, Linux emprunte de la mémoire inutilisée pour la mise en cache du disque. Cela donne l'impression que vous avez accès à de la mémoire “gratuite”, mais vous ne l'avez pas. Tout va bien.

Pourquoi fait-il cela ?

La mise en cache du disque rend le système beaucoup plus rapide et plus réactif. Il n'y a pas d'inconvénients, à l'exception des nouveaux utilisateurs qui ne sont pas familiers avec le concept d'une cache de système de fichiers. Il ne retire généralement pas la mémoire des applications.

Et si je veux exécuter plus d'applications ?

Si vos applications veulent plus de mémoire, le noyau va juste reprendre un morceau que le cache disque a emprunté. Le cache de disque peut toujours être remis aux applications immédiatement. Le système n'est pas à court de RAM.

Ai-je besoin de plus d'échanges (swap) ?

Probablement pas ; la mise en cache sur disque emprunte principalement la RAM que les applications ne veulent pas actuellement. Si les applications veulent plus de mémoire, le noyau le reprendra du cache disque. Linux peut pousser la mémoire d'application dans l'échange si cette mémoire est plus souvent accessible que le cache de système de fichiers, mais cela améliorera généralement les performances, et non pas les détériorer.

Comment puis-je empêcher Linux de faire ça ?

Vous ne pouvez pas complètement désactiver la mise en cache de disque (mais vous pouvez ajuster la gestion du fichier d'échange “swapinesss” de Linux). La seule raison pour laquelle quelqu'un veut désactiver la mise en cachet de disques, c'est parce qu'il pense qu'il enlève la mémoire de ses applications, ce qui n'est pas le cas. Les caches de disques rendent les applications plus rapides et se lancent plus facilement, mais il ne leur enlève JAMAIS la mémoire. Donc, il n'y a absolument aucune raison de le désactiver.

Si, cependant, vous avez besoin d'effacer rapidement de la RAM pour une raison quelconque, comme l'étalonnage du démarrage à froid d'une application non encadrée, vous pouvez forcer Linux à supprimer de manière non destructive des caches en utilisant echo 3 | sudo tee /proc/sys/vm/drop-caches

Pourquoi les commandes top et free disent-ils que si peu de RAM est libre si c'est le cas ?

Ce n'est là qu'une différence de terminologie. Vous et Linux êtes d'accord pour dire que la mémoire prise par les applications est “utilisée” (used), alors que la mémoire qui n'est pas utilisée pour quoi que ce soit est “libre” (free).

Mais comment comptez-vous la mémoire qui est actuellement utilisée pour quelque chose, mais qui peut encore être mise à disposition des applications ?

Vous pouvez compter cette mémoire comme “libre” (free) et/ou “disponible” (available). Linux le compte plutôt comme “disponible” :

Mémoire qui est Vous l'appelleriez Linux l'appelle
Utilisés par les applications Utilisé Utilisé
Utilisés, mais peuvent être disponibles Libre (ou disponible) Disponible
N'est pas utilisé pour quoi que ce soit Libre Libre

Ce “quelque chose” est (à peu près) ce que les commandes “top” et “free” appellent “tampons” et “cachés” (ou buffer/caches). Puisque votre terminologie et celle de Linux diffèrent, vous pourriez penser que vous êtes à court de RAM quand vous ne l'êtes pas.

Comment puis-je voir combien de RAM libre j'ai vraiment ?

Pour voir combien vos applications pourraient utiliser sans échanger, exécuter gratuitement -m et regardez la colonne “disponible” :

$ free -m

total used free shared buff/cache available
Mem: 1504 636 13 0 855 792
Swap: 2047 6 2041

(Sur les installations d'avant 2014, regardez plutôt la colonne “free” dans la ligne “–/– buffers/cache” à la place.)

Les chiffres se comprennent en MiB. Si vous regardez simplement “free”, vous penserez que votre RAM est pleine à 99% alors qu'elle n'est vraiment qu'à 42%.

Pour une description plus détaillée et technique de ce que Linux compte comme “available”, voir ce lien.

LinuxAteMyRAM

Quand devrais-je commencer à m'inquiéter ?

Un système Linux sain avec plus qu'assez de mémoire montrera, après un certain temps, le comportement attendu et inoffensif suivant :

  • la mémoire free est proche de 0
  • la mémoire available (ou “free + buffers/cache”) a suffisamment de place (par exemple, 20% du total)
  • le swap used ne change pas

Signes d'avertissement d'une situation de mémoire réelle que vous voudrez peut-être examiner :

  • la mémoire available (ou “free + buffers/cache”) est proche de zéro
  • les majorations ou fluctuations de swap used
  • dmesg | grep oom-killer montre le OutOfMemory-killer au travail

Comment puis-je vérifier ces choses ?

Voir cette page pour plus de détails et comment vous pouvez expérimenter le cache disque pour montrer les effets décrits ici. Peu de choses vous font apprécier la mise en cachette de disques plus que la mesure d'une accélération de l'ordre de la magnitude sur votre propre matériel.

Traduction basée sur : LinuxAteMyRam.com est présenté par VidarHolen.net. Ce site est accessible depuis GitHub où vous pouvez déposer vos commentaires.


Tout pour bien s'enregistrer ! Voici un article pour mieux comprendre l'enregistrement audio et son matériel. Tout le matériel fonctionne avec Linux, bien entendu !

Définitions

  • Une carte son : c'est une puce qui traite exclusivement du flux audio. Aujourd'hui tous les PC ont des cartes son interne (celle de la carte mère) qui sont d'assez bonne qualité.
  • Interface audio : c'est une carte son, externe, souvent de meilleure qualité que la carte son interne du PC qui va gérer l'audio. Généralement, elles gèrent 2 entrées audio (soit 1 entrée stéréo, soit 2 entrées mono).
  • Table de mixage : c'est un dispositif qui permet d'avoir de multiples entrées sonores pour les renvoyer vers des haut-parleurs, un casque, un PC... Certaines tables de mixage disposent d'une puce de traitement audio (elles sont reconnues comme carte son externe).
  • Entrées / Sorties : une entrée audio permet au son d'arriver dans un dispositif. Il existe des entrées mono (principalement les micro voix, les micro pour instruments) et des entrées stéréo (le PC, une console de jeux...). La stéréo c'est deux pistes, une à gauche, une à droite. La sortie audio permet au son de sortir d'un dispositif (haut parleur / casque).
  • Jack : Le format des prises audio historique ! Il permet de transporter des signaux mono, stéréo, ou stéréo+micro. il y a les jack 6.35, 3.5 ou 2.5 mm.
  • XLR : Format de prise audio mono professionnel. Très solide et adapté à de nombreuses utilisations (micro, instruments...)

Podcast, usages et matériel

Tout dépend de votre budget ! Un PC vous permet d'avoir accès à une carte son interne avec des entrées (micro) et sorties (casque). Pour démarrer, tester, ça vous permet de bien débuter. Première chose, oubliez Amazon, les fiches produits ne sont pas fiables, préférez des vendeurs spécialisés ou connus pour leur sérieux.

Casques / Micro intégré

Prenez un casque/micro de bonne qualité pour avoir un rendu acceptable. J'allais dire que c'est le premier investissement valable à faire.

Pour que votre casque puisse être inclus dans des prochaines mises à jour de votre installation, je vous recommande de prendre des casques avec la possibilité de les connecter en prise jack. Il y a quelques éléments à prendre en compte. La plage de fréquences, en Hz pour les basses et en kHz pour les fréquences plus aiguës. Plus elle sera étendue, plus votre casque pourra restituer de fréquences. Exemples de casque/micro intéressants :

En règle générale, le reste de la gamme BeyerDynamic fait partie des meilleurs casques mais ils n'ont pas de micro intégré. On peut aussi citer Sennheiser comme marque de confiance, surtout sur les casques “pro”. Toute la gamme des Cloud Alpha est un gage de confiance aussi et est très adaptée au gaming et voix pour des prix accessibles.

Oubliez les casques 7.1, la plupart sont des casques stéréo avec des effets ajoutés soit de manière matérielle (avec une puce audio), soit de manière logicielle (avec le logiciel intégré qui n'est pas disponible sur toutes les plate-formes, très rarement avec Linux). Et oubliez la connexion Bluetooth, si elle peut être présente, ce sera un gadget (ou pour des raisons pratiques si vous jouez sur une console), il y a trop de latence potentielle.

Interface audio / table de mixage

Pour aller plus loin dans la qualité et dans les possibilités, vous pouvez investir dans une interface audio professionnelle. Attention, je ne parle pas d'interfaces audio chez Wish pour 10€ ! Quelques marques se détachent de part leur solidité et leurs qualités sonores : Focursite, Arturia, Presonus, Yamaha, BOSS, Behringer. L'avantage d'une table de mixage est qu'elle vous permet d'intégrer du son d'autre source audio (console, lecteur audio, instrument de musique, autre micro...). Dans la liste qui suit, s'il y a des tables de mixage, ce sont celles qui disposent d'une puce audio, elles font aussi office d'interface audio et sont donc reconnues comme une carte son externe. Exemples d'interfaces audio / tables de mixage

Micro

Le micro est un composant essentiel. Votre voix sera captée au mieux grâce à un micro directif et performant. Là aussi, tout dépend de votre budget. Il y a quelques éléments à prendre en compte. La plage de fréquences, en Hz pour les basses et en kHz pour les fréquences plus aiguës. Plus elle sera étendue, plus votre micro pourra capter de fréquences. La sensibilité en dB, au plus elle est faible, au plus elle captera d'éléments. Préférez les micro au format XLR plutôt qu'USB. Exemples de micro intéressants :

Pack spécial Podcast

Vous pouvez trouver de bonnes affaires dans les pack proposés par les vendeurs. Les pack spécial podcast vous assurent d'avoir un matériel uniforme en terme de performances.

Pour moi, la combinaison ultime c'est cela :

  • Micro : Shure SM7B (588€)
  • Casque : Beyerdynamic DT 990 PRO (149€)
  • Interface Audio : Yamaha AG06 MK2 WH (229€)

MAJ pour le support des interfaces audio !

Grâce à un don de Focusrite, le noyau Linux 6.8 supportera plus d'interfaces de la marque, notamment les gen v4 !

Logiciels et effets

OBS pour le streaming

On ne le présente plus, mais juste pour rappeler qu'OBS est une référence et que c'est un logiciel libre ! ;) https://obsproject.com/fr/

Carla et des plugin audio

Il est aussi possible d'améliorer le son avant la diffusion. Carla et des plugins audio sont la combinaison la plus efficace ! Et surtout ça évite de devoir traiter le son par la suite ! Carla permet de faire les connections audio entre les plugins et les entrées sons et on peut l'utiliser dans toute sorte de logiciels audio.

Dans l'ordre, on peut appliquer les traitements assez récurrents qu'on trouve dans les studios pro :

  • le debess atténue les consonnes sifflantes (les “ssss”) de la voix,
  • l'équaliseur change la couleur de la voix (plus de graves, de medium...),
  • la reverb pour donner l'illusion d'être dans un (petit ou grand) volume, ou pour corriger quelques soucis,
  • le limiteur va couper le son s'il est trop bas,
  • et enfin le compresseur va remonter la voix quand elle est faible et la descendre quand elle trop forte.

–> Carla : https://kx.studio/Applications:Carla

Ardour

La rolls des logiciels libres d'enregistrement audio. Vous pourrez enregistrer une émission en différé, c'est le top du top ! Attention, il est nécessaire d'avoir de solides bases (ou connaissances) en audio pour bien démarrer ! Ardour est un logiciel professionnel !

https://ardour.org/

#ardour #audio #OBS #Streaming #Focusrite #Shure #Beyerdynamics #RØDE #Yamaha #Presonus #Casque #Podcast #Micro #Linux


Dans les communautés linuxiennes, il y a quelques débats animés sur certains sujets (cela va parfois jusqu'aux insultes ou aux attaques ad hominem), voici celui sur la transition entre X11 et Wayland.

De quoi s'agit-il ?

Ici, il va être question de la manière d'afficher des informations sur votre PC, de gérer différents système d'entrées (clavier, souris...).

X.org, l'ancien

X est un système de fenêtrage né en 1984 qui gère l'écran, la souris et le clavier (et divers autres comme les tablettes graphiques par exemple). X11 est la version “11”. Schéma client-serveur de X Window (source : Wikipédia) Pour bien comprendre X, il s'agit d'un fonctionnement client-serveur. Le serveur X dispose de l'écran, de la souris, du clavier. Les clients (applications) lui demandent d'utiliser le matériel et l'affichage avec Xlib. Parmi les clients de X, le gestionnaire de fenêtres va gérer l'affichage, la sélection ou le redimensionnement des fenêtres…

Bibliothèques pour la programmation de X (source : Wikipédia) X est ancien, et différentes voies s'élèvent pour le remplacer. Il existe aussi différents soucis, notamment de sécurité (une application demandant un accès clavier est visible pour d'autres applications) et d'autres liés à la structure même de Xorg (les différentes extensions dont la plupart ne sont plus utilisées mais dont le code, ancien, reste toujours présent et demande toujours des dépendances).

Qu'un nouveau protocole d'affichage existe, c'est une bonne chose, une évolution importante notamment dans le support de technologies récentes. Puisque X11 est ancien, difficile à maintenir à jour, très complexe pour les développeurs...

Wayland, le protocole au développement chaotique

La première version de Wayland date de 2008. Si Xorg est âgé de 40 ans, Wayland en est déjà a 15 ans. La faute à un développement chaotique, une gouvernance “à la Gnome” (ils sont les meilleurs et les autres ce ne sont que des abrutis barbus utopistes)...

Wayland est conçu pour être léger et efficace, visant à réduire la latence et à améliorer les performances globales par rapport à Xorg. Il y parvient en éliminant certaines des fonctionnalités héritées et des mécanismes obsolètes présents dans Xorg, ce qui entraîne des interfaces utilisateur plus réactives.

Wayland a été construit avec la sécurité à l'esprit à partir de zéro. Il adopte une architecture plus sécurisée, mettant en œuvre des contrôles plus stricts sur la communication des processus et l'isolement des applications les unes des autres. Cette conception aide à atténuer certaines vulnérabilités et rend plus difficile pour les logiciels malveillants de compromettre le système.

Malheureusement, il n'y a pas de compositeur unique universellement utilisé. Chaque environnement de bureau fait le sien et, par conséquent, ce qui fonctionne dans l'un peut ne pas fonctionner dans un autre.

Pourquoi il y a débats ?

Je ne dis pas que Wayland c'est de la “merde”, mais plutôt que ce n'est pas encore prêt à être conseillé à un débutant. Xwayland, la couche qui doit permettre une compatibilité parfaite entre les applications développées avec Xorg et l'environnement Wayland ne tient pas ses promesses. Les spécifications de Wayland sont parfois de réels freins à des fonctionnalités importantes pour beaucoup d'utilisateurs (gestion des couleurs par exemple). La nouveauté de Wayland fait que toutes les applications doivent, à un moment ou un autre, se poser la question de migrer vers Wayland. Cela pose des problèmes pour des équipes de développement qui n'ont pas forcément anticipé ce genre de travail supplémentaire. Et justement, quand je vois le soucis de Discord, je ne suis pas sûr que cette boîte investisse plus d'énergies pour supporter Wayland dans un futur proche (on espère hein, mais ça reste de l'espoir). Ces développements supplémentaires, les utilisateurs vont les subir, soit en attendant que des applications, serveurs graphiques ou applications migrent, soit en se passant d'applications importantes dans leur quotidien (qui imagine utiliser son service de visio sans partage d'écran ?). Sur un marché restreint mais en devenir comme Linux, c'est un sacré handicap.

RedHat, Gnome, imposer une nouvelle technologie pour accélérer son développement.

Wayland n'est pas prêt en décembre 2023. Beaucoup de fonctionnalités manquent ou sont encore en phase de développement, pire, certaines vont devoir “hacker” le fonctionnement de Wayland pour être implantées... comme ce fut le cas avec Xorg...

Mais Wayland est poussé/financé par RedHat. Les développeurs de RedHat ont travaillé pendant des années sur Xorg, et depuis peu, presque tous ont migré vers le développement de Wayland. Gnome souhaite supprimer le support de Xorg par défaut (pour la faire réapparaître, il faudra ajouter 8 lignes de codes dans un fichier de configuration). Et Ubuntu suit le mouvement en annonçant que leur prochaine version LTS (en avril 2024) sera disponible par défaut avec Wayland.

La démarche est claire : faire migrer de force les utilisateurs pour faire bouger les développeurs, et ce, même si toutes les fonctionnalités de Xorg ne sont pas implantées dans Wayland (la gestion des couleurs par exemple).

Et clairement, ce management ne passe pas. Exemples.

GIMP

Le logiciel phare de retouche photo du monde Linux souffre depuis des années d'un développement lent. Depuis 2, 3 ans, son développement s'est accéléré (avec le passage annoncé en GTK3). Mais cette dynamique est fragile. Xwayland ne permettant pas une compatibilité efficiente avec la version de GIMP actuelle. Tous les développeurs de GIMP doivent bosser sur la version Wayland, et ils le font depuis au moins 2020. Et malheureusement, le protocole ne supporte pas encore la gestion de couleur, le drag and drop entre différentes fenêtres, une gestion unifiée des fenêtrages d'une application, le support matériel pour des dispositifs de pointage importants (stylets à pression, tablette graphique, écrans tactiles...).

Dans cette affaire, ce n'est pas seulement le développement lent de GIMP qu'il faut pointer mais bien la gouvernance de Wayland qui fait comme bon leur semble sans consulter toutes les parties concernées et qui force une migration alors que le protocole manque de fonctionnalités essentielles. Ce n'est pas aux développeurs de GIMP d'écrire les protocoles manquants (pas le temps, pas les compétences...).

PCSX2

C'est un émulateur de console PS2. Le seul valable et surtout celui qui est le plus utilisé. La version Linux fonctionne bien, surtout depuis l'ajout du rendu Vulkan (elle était en-dessous de la version Windows depuis des années). Les problèmes sont nombreux et dû au manque de support de nombreuses fonctionnalités dans GTK. Les autres DE ne semblent pas avoir ces soucis. Explications techniques ici

Alors Wayland ou pas ?

Pas encore ! Il est certain que Wayland sera à terme, le remplaçant idéal pour X11. Pour le moment, quand on passe à Wayland, on dégrade son expérience Linux. Des outils pro comme Krita avec la gestion de couleur, c'est nécessaire pour de nombreux projets, et pas seulement avec Krita, mais toute la chaîne graphique sous Linux : Inkscape, Scribus, GIMP, LibreOffice, Blender... Le support de matériel de pression, le multi-fenêtrage ce sont des fonctionnalités importantes (et bien d'autres sont listées ici). Alors, oui si vous n'utilisez pas ces logiciels, vous allez me dire que ce n'est pas grave, pour vous Wayland fonctionne bien... Pour le moment, si vous n'avez pas de carte graphique Nvidia, que vous n'utilisez pas le partage d'écran, que vous ne faites pas de la vidéo en direct ni que vous utilisiez des applications en multi-fenêtrage vous ne devriez pas avoir de problèmes. Bref, si vous êtes le mouton à cinq pattes qui n'a pas de soucis et qui remplace ses applications utilisées par d'autres, bin, tant mieux pour vous.

Pourquoi cela fait rager des gens ?

Parce que le nombre d'utilisateurs Linux est déjà restreint (2% sur la plate-forme Steam) et que les restreindre encore plus à cause d'une “mise à jour technique” (parce que c'est comme cela que c'est compris par des utilisateurs lambda), c'est encore plus se tirer une balle dans le pied. Changer d'application parce qu'elle ne fonctionne plus à cause du changement de serveur graphique c'est autant un obstacle qu'une ineptie pour les utilisateurs qui se détourneront de Linux et retourneront soit chez Win-IA-dows, soit chez App-$-le.

Petit rajout de dernière minute : Linux Mint n'incorporera Wayland définitivement qu'en 2026.

In terms of timing we don’t think we need Wayland support to be fully ready (i.e. to be a better Cinnamon option for most people) before 2026 (Mint 23.x)

https://blog.linuxmint.com/?s=wayland&submit=Search

#Wayland #Xorg #X11 #Mint #Ubuntu #Fedora


Lors d'un “débat” (plutôt une série de mauvaises compréhensions), j'ai pu dire que Gnome et les extensions ça n'a jamais été une lune de miel, voir même que certains développeurs avaient pensé à supprimer cette possibilité.

Précisions utiles : Je suis un utilisateur de distributions Linux depuis 2003-2004. Au départ avec Slackware, puis Kubuntu, Xubuntu et Ubuntu. Aujourd'hui, après un passage par ElementaryOS, je suis sous PopOS. Mon expérience avec Gnome est celle d'un utilisateur qui a connu Gnome 2, puis le lancement (plutôt calamiteux) de Gnome 3 et les différents projets qui ont suivi (Mate, Cinnamon).

Aux origines de Gnome 3

En 2008, Gnome 3 est dans toutes les têtes des développeurs. Le nouveau DE (Environnement de Bureau) doit succéder à Gnome 2, implanté dans beaucoup de distributions Linux (Ubuntu étant l'une des plus populaires). Ce DE, plutôt léger même à son époque, satisfaisait beaucoup de besoins des utilisateurs. Le blog de Owen Taylor parle bien de cette époque notamment avec son article “Implementing the next GNOME shell”. Fin 2008, lors du GUIHackfest de Boston, Vincent Untz dévoile un concept d'interface :

Dans son article, nous pouvons voir plusieurs discussions menées et quelques décisions sur le développement de Gnome 3 :

  1. Le “menu” Activités permet d'avoir un seul endroit pour les applications en cours et celles à lancer. L'idée est de fusionner la vue avec le raccourcis “ALT-TAB” et le menu “Applications”, et tous les panneaux d'informations.
  2. Javascript, un langage populaire pour permettre l'engagement de la communauté dans le développement de Gnome. Javascript permet aussi de modifier le Shell. C'est la vision des “applets”, la même que celle de Gnome 2 ou de XFCE.
  3. Clutter, pour gérer la gestion des fenêtres et remplacer GTK+. À cette époque, Clutter est en phase de développement intense et utilise le GPU (OpenGL).
  4. Metacity, le gestionnaire de fenêtres de Gnome 2, est un héritage important pour l'équipe.

Déjà, si nous regardons les commentaires de l'article d'Owen, on peut voir que le choix de Javascript n'est pas le plus populaire, Python commence à être très utilisé parmi les communautés de développeurs. Il y a aussi des craintes concernant l'utilisation du GPU dans le rendu de Clutter.

Il faut dire que nous sommes en pleine période “Compiz”. Le rendu GPU est devenu populaire grâce à ces effets qui impressionnent et donnent à voir la puissance des distributions Linux.

Les extensions, une déception conceptuelle pour les développeurs, une popularité importante

Jiri Eischmann, dans son article “Story of Gnome Shell Extensions” parle de cet historique.

Dès le lancement de Gnome 3, le choix des extensions en Javascript se révèle payant. De nombreux développeurs s'impliquent pour apporter des extensions au bureau de Gnome. Mais les choix de design de l'équipe (plutôt radicaux) sont mis à mal par ces extensions. De plus, les développeurs d'extensions ne s'impliquent pas dans le développement de Gnome, mais restent sur leurs projets sans s'impliquer davantage.

L'équipe décide de leur donner plus de visibilité en apportant Gnome Extensions pour rationaliser tout cela avec des connecteurs dans les navigateurs Firefox et Chrome. Cette application est séparée du reste des paramètres de Gnome. Le développeur Tobias Bernard pense même que cette application doit rester comme telle, car c'est juste un hack :

“If you make extension installation/management nicer that makes them seem like even more of a supported feature, rather than the hack it is...”

En 2012, Gnome 3 devient de plus en plus instable à cause de certaines extensions. En 2016, avec l'introduction de Wayland, l'équipe a pu penser que cela allait être mieux (séparations des processus), mais la conception même de Gnome (Mutter / Shell dans un même processus) faisait que si un des composants plantait, les deux plantaient.

L'article date de 2018 et Jiri Eischmann fait le constat amère que les extensions apportent plus de problèmes d'instabilités qu'autre chose au projet :

“desktop crashes caused by GS extensions are by far the most frequent problem I’ve seen recently”.

C'est bien à cette époque que certains développeurs posent la question du support des extensions dans Gnome. À chaque version de Gnome (3.36, 3.38...) beaucoup d'extensions deviennent incompatibles.

Entre désactivation après survenue d'un bug (avec la fermeture de la session utilisateur), rendre incompatibles la plupart des extensions en mettant en place une API ou une autre solution de séparation entre Mutter et Shell (une solution complexe en ces temps de cohabitation entre X11 et Wayland) la décision, à l'époque, n'est pas de faire de choix radical.

JohnMacHugh sur le wiki de Gnome en parle aussi en ces termes.

Il faut bien comprendre ici que le débat à propos des extensions n'est pas le même que celui des thèmes. Il s'agit d'un enjeu entre un langage populaire (Javascript) aux débuts de Gnome 3 qui rend les choix de l'équipe incohérents et instables et une popularité, bienvenue, héritée des “applet” de Gnome 2 / XFCE.

L'équipe de Gnome n'apprécie pas que ses décisions de design ne soient pas respectées. On le voit lorsqu'il est question de “theming” avec le site “StopThemingMyApp”

Une intégration en cours de rationalisation

Comme dit plus haut, l'application qui gère les extensions dans Gnome est en dehors des paramètres du bureau de Gnome. Certaines distributions (PopOS) ont décidé d'inclure ces paramètres dans les paramètres globaux au mépris des choix de la communauté de Gnome. Quelques tensions plus tard et quelques débats sur le theming font que PopOS décide de ne plus continuer avec Gnome pour ses prochaines versions : ils développent leur propre DE, Cosmic, codé en langage RUST.

Canonical ayant abandonné son interface Unity dans Ubuntu. Sa distribution phare utilise Gnome (comme à l'ancien temps de Gnome 2). Il est important de voir ici que Ubuntu utilise des extensions “maison” directement implantées (app indicator par exemple). C'est aussi un point de débat dans la communauté de développeurs de Gnome.

Tobias Bernard en parle dans son article “Community Power Part 4: The GNOME Way” :

“Every preference has a cost, and this cost rises exponentially as you add more of them. This is why we avoid preferences as much as possible, and focus on fixing the underlying problems instead.”

Et la partie concernant les extensions illustre bien le propos :

“Shell extensions are always going to be a niche thing. If you want to have real impact your time is better invested working on apps or GNOME Shell itself.”

Si vous voulez vous investir efficacement dans Gnome, votre temps sera mieux dépensé si vous développez des applications plutôt que des extensions.

Conclusion

L'équipe de Gnome a certainement besoin de clarifier ses positions concernant ce sujet. Autant les choix de design sont des choix à mettre en débat, mais ils s'imposent à tout utilisateur de Gnome. Les extensions, quant à elles, montrent une dynamique d'un développement communautaire. À l'instar de sites comme gnome-look, les choix de l'équipe de Gnome sont mis à mal par les thèmes, les extensions instables... Et ce, même si Allan Day a pu mettre en avant “The Gnome Way”, aujourd'hui, 6 ans après et avec le développement intense des différentes versions de Gnome, la question des extensions demeure et de ses incompatibilités avec.

#GNOME #Extensions


Voici quelques astuces pour analyser son temps de démarrage avec systemd (présent dans beaucoup de distributions). Une autre méthode existe avec bootchart (je pourrai mettre à jour ce tuto).

Systemd

Systemd est arrivé depuis les années 2010 (2012 pour Arch, 2014-2015 pour les Debian/Ubuntu) pour la gestion du système et des services sur les distributions Linux. Il permet de voir ce qui prend du temps au démarrage par exemple. C'est très utile, pas seulement pour comparer sa qué... ses performances, mais aussi pour savoir si un service démarré sur votre distribution prend beaucoup de temps où ralenti votre système. Par exemple, si vous installez Apache, PHP ou MySQL, votre distribution va bien ralentir au démarrage car elle devra lancer ces éléments surtout présents et utiles sur des serveurs web (pas forcément votre besoin de gamer).

Analyser

Voici la commande : systemd-analyze

qui renvoie chez moi ça : nasra@pop-os:~$ systemd-analyze Startup finished in 9.360s (firmware) + 524ms (loader) + 4.469s (kernel) + 4.411s (userspace) = 18.765s graphical.target reached after 4.375s in userspace

Ok, là j'ai un découpage du temps entre les firmwares, le loader, le kernel (et ses différents modules), le temps utilisateur (les applications démarrées lors de l'ouverture de la session de mon DE) et le dernier temps celui qui m'annonce mon temps de boot avant d'avoir affiché mon interface graphique (celle de mon login). Ces temps là changent selon les DE, les modules installés ou non dans le kernel, les services démarrés lors du login.

Analysons plus finement

La commande suivante analyse tous les éléments du démarrage : systemd-analyze blame

qui renvoie cela chez moi : nasra@pop-os:~$ systemd-analyze blame 3.425s NetworkManager-wait-online.service 3.369s plymouth-quit-wait.service 2.542s fwupd-refresh.service 549ms apt-daily-upgrade.service 534ms apt-daily.service 463ms ua-timer.service 440ms man-db.service 419ms networkd-dispatcher.service 363ms accounts-daemon.service 289ms logrotate.service 274ms udisks2.service 252ms dev-sdc3.device 197ms systemd-cryptsetup@cryptswap.service 162ms dpkg-db-backup.service 158ms user@1000.service 151ms ModemManager.service 112ms upower.service 109ms boot-efi.mount

Ici j'ai un module NetworkManager-wait-online.service qui prend 3,425s à démarrer. Parfois ce module peut prendre plus de temps (dans une configuration réseau par exemple).

La commande systemd-analyze critical-chain

Permet de mieux identifier les services en question. Elle renvoie cela chez moi : nasra@pop-os:~$ systemd-analyze critical-chain The time when unit became active or started is printed after the "@" character. The time the unit took to start is printed after the "+" character. graphical.target @4.375s └─lactd.service @4.374s └─multi-user.target @4.373s └─plymouth-quit-wait.service @962ms +3.369s └─systemd-user-sessions.service @955ms +4ms └─network.target @944ms └─NetworkManager.service @839ms +101ms └─basic.target @838ms └─dbus-broker.service @816ms +20ms └─dbus.socket @805ms └─sysinit.target @803ms └─cryptsetup.target @760ms └─systemd-cryptsetup@cryptswap.service @563ms +197ms └─dev-disk-by\x2duuid-287ac1e1\x2def46\x2d4d0e\x2d9d7d\x2d6cb19af5b144.device @535ms

Exporter ses résultats

Petit bonus pour la route, vous pouvez exporter vos résultats en .svg 🙂 systemd-analyze plot > boot_analysis.svg

systemd boot analysis

#Systemd #Ubuntu #PopOS