Nasra's games

Ubuntu

Petit article de présentation de Rhino Linux, une distribution à part dans le paysage des distributions basées sur Debian/Ubuntu.

Rolling Release ?!?

D'abord, un peu de définition !

Dans le domaine du développement logiciel, l'approche rolling release (littéralement « publication roulante », soit « publication continue ») fait référence à un système de développement logiciel en continu, par opposition au système par version, où l'on ne procède à des mises à jour en production qu'à la fin du cycle de développement d'une version du logiciel ou du système tout entier. Il est notamment utilisé par certaines distributions GNU/Linux. Un système rolling release est généralement implémenté par la mise en œuvre de petites et fréquentes mises à jour. Cependant, appliquer des mises à jour régulières ne signifie pas nécessairement faire usage d'un système en rolling release. Pour qu'une telle dénomination s'applique, les développeurs doivent utiliser une méthode de travail avec une branche unique, par opposition à des versions spécifiques à une étape du cycle (par exemple versions de développement, de test et de production). Dans un système de rolling release les mises à jour sont généralement fournies via un gestionnaire de paquets à travers une connexion internet.

Source : Wikipédia

Donc, si on résume, une distribution rolling release c'est une distribution où vous avez les dernières versions des logiciels et paquets disponibles, tout le temps, presque en temps réel avec les sorties des logiciels.

Avantages et inconvénients

Quelques avantages et inconvénients des rolling releases !

Avantages

Les avantages sont nombreux, notamment avoir les derniers kernels système permet d'avoir un support matériel au top ! Les dernières avancées en terme de pilotes, de gestion graphique sont très utiles pour les joueurs. Vous avez aussi accès aux derniers correctifs de sécurité en direct ! Les dernières évolutions en terme d'interfaces graphiques (Gnome, KDE...) sont directement accessibles !

Inconvénients

Le fait d'avoir les toutes dernières versions des logiciels et applications vous demande de faire des mises à jours régulières. Les logiciels ou paquets ne sont pas suffisamment testés pour être mentionnés “stables” et peuvent causer des soucis de compatibilité, des bugs... Il faut donc savoir mettre les mains dans le moteur et savoir s'en sortir ! Les dernières versions peuvent aussi contenir des failles de sécurité (rapidement corrigées, mais vous êtes un peu le cobaye)...

De la difficulté entre récence et sécurité

Les distributions rolling release (comme les distributions à base de Arch) ont souvent des “garde-fous” temporaires. Soit les paquets ne sont pas intégrés tout de suite dans la distribution, ils sont testés avant par l'équipe, soit on procède à une version “testing” de la distribution (et on s'éloigne de la définition de rolling release) avec déploiement général.

En terme de sécurité, il vaut mieux avoir un système stabilisé, connu, et patché qu'un système trop récent. C'est notamment le cas des distributions Debian : stables mais pas récentes en terme de version de kernel, de paquets...

Toute la complexité et le dilemme des distributions Linux (et plus largement de chaque projet informatique) c'est de pouvoir proposer des mises à jour récentes (mais pas trop) et de la sécurité (mais pas trop ancienne).

Rolling Release, un modèle de développement

Les fans d'Arch Linux jugent généralement Debian et son monde comme quelque chose d'un peu archaïque. Debian étant une des premières distributions Linux (fin 1993), elle profite de l'expérience de nombreuses personnes. Elle est connue, et sa communauté permet son intégration dans énormément d'infrastructures réseaux. Ubuntu profite de cet éco-système pour se développer.

De l'autre côté, Fedora propulsée par RedHat offre des possibilités qui se rapprochent le plus possible des rolling release sans en être. C'est un modèle de développement : la communauté et Fedora “testent”, c'est déployé dans CentOS Stream, qui reteste, puis dans RHEL, la distribution payante pour les professionnels qui veulent du sécurisé et stable.

Rhino Linux, comme un entre-deux

L'avantage de Rhino Linux c'est de prendre les avancées de la communauté d'Arch, d'y intégrer leur fonctionnement (le gestionnaire de paquets Pacstalls) et de l'adapter au monde Debian/Ubuntu qui adore le versioning de ses distributions (experimental, testing, stable, intermediaire, LTS...).

Autre avantage de Rhino Linux, celui de proposer Unicorn, un fork de XFCE pensé pour la modernité.

Le but de cet article n'est pas de vous faire passer à Rhino Linux, mais juste de vous découvrir cette distribution, et d'en profiter pour parler de rolling release ! Donc, testez et vérifiez si cela correspond à vos envies de distribution !

#RhinoLinux #Ubuntu #RollingRelease

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

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

L'utilisation de PPA permet, dans le monde d'Ubuntu et ses dérivées (Mint, PopOS...), d'ajouter des sources à votre liste de paquets disponibles sur votre système.

Je vous ai perdu ? Je vous explique !

L'installation d'un logiciel sur les distributions Linux

Pour installer un logiciel, il est nécessaire d'aller sur le site de l'éditeur du logiciel, télécharger le logiciel et de l'installer. Ok pour ça tout le monde sait de quoi il s'agit. Dans Linux, les distributions mettent à disposition un ensemble de logiciels qui seront par la suite mis à jour avec tout le système, c'est ce qu'on appelle des paquets logiciels, ou paquets. Paquets car ces “logiciels” ne contiennent pas seulement les applications, mais aussi tout ce dont elles ont besoin pour fonctionner (pilotes, librairies bluetooth par exemple...

Donc, quand vous choisissez une distribution, vous choisissez aussi un ensemble de logiciels. Certaines distributions permettent de suivre l'avancée des logiciels (dernière version de Firefox, LibreOffice par exemple), d'autres restent bloquées dans des versions un peu plus anciennes. C'est pour remédier à cela que vous pouvez ajouter des sources supplémentaires (des adresses de serveur, par exemple pour Steam, celle de Valve) pour mettre à jour plus facilement vos logiciels.

Le PPA, dans l'univers d'Ubuntu et ses dérivées.

C'est ici que rentre en jeu les PPA. Ce sont des sources de nouveaux logiciels hébergées par un service de Canonical (éditeur d'Ubuntu), Launchpad.

Dans les temps anciens d'Ubuntu, il fallait éditer à la main un fichier texte, le fameux sources.list et lui rajouter les adresses de serveurs. Aujourd'hui, l'installation d'un PPA se fait grâce à une ligne de commande à copier-coller dans votre terminal : sudo add-apt-repository ppa:LE_NOM_DU_PPA

Mises en garde sur l'utilisation des PPA

Les PPA sont bien utiles pour avoir accès à certains logiciels récents non proposés par défaut par votre distribution. Mais, certains PPA embarquent plus de logiciels et sont de véritables suites logicielles, avec tous les composants à jour pour faire tourner leurs logiciels. Et c'est ici qu'il faut être vigilant. Installer un PPA qui ne contient qu'un seul logiciel, ça se tient, et c'est même intéressant dans la plupart des cas. Installer un PPA avec une suite de centaines de logiciels et leurs dépendances peut casser votre installation facilement.

Je vous recommande ceci : bien vérifier les paquets qu'on peut mettre à jour sur le site du PPA. Comme cela vous saurez si le PPA contient le logiciel ou aussi des mises à jours de Mesa, de pilotes... dont les versions vont se substituer à celles de votre système et le rendre potentiellement instable.

Une solution, n'installer que ce qui est utile ! ;)

Par exemple, pour le logiciel CoreCTRL, nous pouvons remarquer que le PPA proposé ( https://launchpad.net/~ernstp/+archive/ubuntu/mesarc ) contient le logiciel et des mises à jours de Mesa, de pilotes...

Nous pouvons n'installer que le logiciel dont on a besoin en prenant le .deb : “view package details”, le télécharger, et l'installer. C'est comme cela que je fais souvent. Si le logiciel a des dépendances bizarres, je le saurai tout de suite et/ou je pourrai passer à la compilation pour l'utiliser... ou pas (car s'il a des dépendances pourries, c'est peut-être aussi que le logiciel en question un peu moisi)

Voici en image ce que ça donne :

#ppa #ubuntu #popos

Nasra, passionné de jeux vidéos depuis longtemps (j'ai commencé sous DOS en 1986 ^^). Je suis aussi un fan des consoles Nintendo depuis la Gameboy. AlleyCat J'ai eu une période PC only (où j'ai “loupé” des consoles comme la N64, PS2, GameCube, Wii et PS3). Cette période est pour moi aussi une période où je découvre l'émulation (UltraHLE pour Zelda OoT que j'ai fini sur émulateur) et beaucoup de jeux non sortis en Europe (les J-RPG de la Snes comme Rudra No Hihou, Seiken Densetsu 3, les shoot-them-up de l'arcade (Cave mon ami)...). Donpachi Je jouais principalement sur PC avec Baldur's Gate, DukeNukem3D, Quake 3, Homeworld, Civilization, Morrowind, SilkroadOnline... J'ai arpenté pas mal de forums sur l'émulation, dont le regretté Toudy.com, Emu-France, Consollection, Gametronik... Toudy Puis, j'ai acquis quelques consoles portables (GBA, NDS, 3DS). Je suis revenu aux consoles de salon Nintendo avec la Switch. Je me suis créé sur un RaspberryPi une petite machine multi-jeux qui me permet de redécouvrir des systèmes que j'avais un peu zappé (Megadrive et PSP surtout).

Niveau jeux vidéos sur PC, notons que je suis passé exclusivement sous Linux en 2006. J'ai connu la période avant que Steam ne soit natif sur Linux (2013). J'ai fait tourner beaucoup de jeux avec Wine (dont HalfLife 2, Oblivion...). Niveau matos GPU, je suis passé par des Nvidia (Riva Tnt2), ATI (HD3650), Nvidia (GTX450, GTX650Ti, GTX970), puis aujourd'hui AMD (RX5500XT). Et niveau CPU j'ai toujours été fidèle à AMD (K6-2-450, Duron 700, Barton 3000+, Athlon II X3, FX 8350, Ryzen 2600 puis 5600).

Linux ?

Linuxien au quotidien depuis la version 5.04 de Ubuntu, je tourne depuis la 22.04 sur Pop!_OS.

Voici mon parcours de linuxien

  • 2001 : Tests sur un PC P266MMX 32Mo de Ram (PC “Portable”, Acer Extensa 503) –> installation d'une Slackware 7.0 puis 8.0
  • 2002-2003 : Différents tests sur mon PC principal en live-CD par dessus mon installation de Win2K. (Knoppix, Fedora...)
  • 2004 : Passage à Win XP, puis installation en dual-boot de Ubuntu 5.04 (je ne suis plus passé par Win après).
  • 2005 : Installation de Kubuntu
  • 2006 : Suppression du Dual-Boot (c'est quoi déjà cette partition qui me prend des Go inutilement ?)
  • 2006 à 2012 : Je suis tous les versions de Ubuntu (LTS comme intermédiaires) jusqu'à la 12.04, en changeant entre Kubuntu et Xubuntu.
  • 2013 : ElementaryOS (+ installation chez beaucoup de personnes).
  • 2016 : Xubuntu 16.04 (PC fixe comme portables)
  • 2019 : Réflexions pour passer à Manjaro.
  • 2019 : Passage à Pop!_OS 19.04,
  • 2022 : Pop!_OS 22.04 aujourd'hui.

Finalement, il m'a fallu près de 4 ans pour être si à l'aise avec le système que je n'avais plus besoin d'un refuge Windows. J'ai commencé à devenir une référence “Linux” auprès de mes proches 6 ans après que je me sois senti “à l'aise” avec mon système.

Comme quoi, il est à mon sens compliqué de dire à des personnes qui viennent juste d'installer Linux qu'elles peuvent être à l'aise et en sécurité tout de suite avec ! ;)

#nasra #linux #ubuntu #elementaryos #popos #emulation #linuxgaming