Page de recherche dans les notes du jardin numérique de Stéphane Klein

Recherche effectué dans :

Tous type de notes (19)

journal_note (10)

evergreen_note (9)

Filtre actif, cliquez pour en enlever un tag :

gnome

Cliquez sur un tag pour affiner votre recherche :

Résultat de la recherche (19 notes) :

Cette note fait partie de la série de notes : "J'ai étudié et testé CoreOS et je suis tombé dans un rabbit hole 🙈".

Note précédente : "Support OCI de CoreOS (image pull & updates)".

Colin Walters, le principal développeur de libostree a initié le projet bootc en mars 2021. J'ai découvert le projet bootc en début d'année et lisant des articles liés à systemd.

La vision de bootc est assez simple : rendre la création d'images de système d'exploitation aussi simple que la création d'images de conteneurs d'applications tout en utilisant les mêmes outils. Pour avoir un peu de contexte historique, je conseille l'article lwn de juin 2024 : Making containers bootable for fun and profit

Les images bootc utilisent la même technologie de stockage que les images des container classique : OCI.

D'après ce que j'ai compris, ce type d'image bootc ne porte pas nom officiellle, elles sont nommés aussi bien "bootc image", que "bootable container image" ou "bootable OCI image".

En janvier 2025, Red Hat a transféré le projet bootc à la CNCF. Le but est de permettre à toutes les distributions de l'adopter comme standard, indépendamment de Red Hat.

Parmis les distributions qui ont adopté bootc, trois retiennent mon attention :

fedora-bootc
fedora-coreos (mais attention, cette version n'est pas encore prête à être utilisé)
Bluefin du projet Universal Blue

Au moment où j'écris ces lignes, je pense migrer d'ici quelques mois ma workstation vers une distribution Desktop bootc, probablement Bluefin, qui est déjà disponible, ou Fedora Silverblue, une fois que son support bootc sera finalisé.

J'aurai donc certainement l'occasion de tester en pratique comment créer des images bootc personnalisées.

Voici diverses ressources que j'ai trouvées concernant le support bootc pour Fedora Silverblue :

Issue dans "Fedora Atomic Desktops / SIG Issue Tracker" :
- Roadmap to Fedora Bootable Containers
Pages dans "Fedora Project Wiki" :
- Initiatives/Fedora bootc
- Changes/OstreeNativeContainerStable
Section "First step towards Bootable Containers: dnf5 and bootc" dans l'article "What’s new for Fedora Atomic Desktops in Fedora 41"

Je compte aussi tester bootc et tout particulièrement Bluefin dans le cadre de mon "Projet 26 - "Expérimentation de migration de deux utilisateurs grand public vers des laptops sous Fedora"".

Cette note fait partie de la série de notes : "J'ai étudié et testé CoreOS et je suis tombé dans un rabbit hole 🙈".

Note précédente : "composefs, un filesystem spécialement créé pour les besoins des distributions atomic"

En étudiant libostree, j'ai découvert que Flatpak est construit sur OSTree depuis sa création : voir page Flatpak documentation - Under the Hood.

Flatpak utilise la fonctionnalité pull d'OSTree pour télécharger l'intégralité des applications depuis un repository OSTree, ou des deltas pour les mises à jour. Depuis la version 0.6.0 de 2016, Flatpak supporte aussi le téléchargement au format OCI.

Voici un exemple de repository Flatpak configuré sur mon workspace :

$ flatpak remotes -d

Name    Title                    URL                                    Collection ID Subset Filter Priority Options    Com… Descript… Homepage             Icon
fedora  Fedora Flatpaks          oci+https://registry.fedoraproject.org -             -      -      1        system,oci -    -         -                    -
flathub Fedora Flathub Selection https://dl.flathub.org/repo/           -             -      -      1        system     Sel… Selected… https://flathub.org/ https://dl.flathub.org/repo/logo.svg
flathub Flathub                  https://dl.flathub.org/repo/           -             -      -      1        user       Cen… Central … https://flathub.org/ https://dl.flathub.org/repo/logo.svg

On peut voir que Flathub est un serveur libostree et le registry registry.fedoraproject.org utilise le format OCI.

Sans entrer dans les détails (ce serait trop long pour cette note), libostree est la raison pour laquelle Flatpak est plus performant que Snap basé sur squashfs.
Selon Claude.ia, Flatpak offre par rapport à Snap : un démarrage des applications 2 à 3 fois plus rapide, 60-80% de bande passante en moins sur les mises à jour, et 30-40% d'espace disque économisé.

Note suivante : "Support OCI de CoreOS (image pull & updates)".

Dans ce billet du blog de Bluefin #JaiDécouvert Bazaar (https://github.com/kolunmi/bazaar).

Bazaar is a new app store for GNOME with a focus on discovering and installing applications and add-ons from Flatpak remotes, particularly Flathub ...

Bazaar is fast and highly multi-threaded, guaranteeing a smooth experience in the user interface. You can queue as many downloads as you wish and run them while perusing Flathub's latest releases. This is due to the UI being completely decoupled from all backend operations.

source

Bazaar est une alternative à l'application officielle GNOME nommée gnome-software.

Contrairement à gnome-software qui est basée sur PackageKit et gère différents types de packages (rpm, DEB, Flatpak, Snap, etc.), Bazaar a un périmètre plus limité et se concentre exclusivement sur les packages Flatpak.

Dans un premier temps, je me suis demandé quel était l'intérêt de créer une nouvelle GUI pour installer des packages, pourquoi l'auteur n'a pas choisi de contribuer à gnome-software ?

J'ai trouvé une réponse dans ce thread.

Bazaar est une application avec une vision tranchée :

support uniquement le repository Flathub (qui contient seulement des packages Flatpak) ;
mise en avant de solution pour faire des donations.

Cette vision a permis à l'auteur de créer Bazaar en mai 2025, à partir de zéro, avec une implémentation plus direct (pas de support PackageKit…).
Cela lui a permis aussi de se consacrer fortement sur l'expérience utilisateur.

Après avoir testé l'application, je constate que contrairement à gnome-software, toutes les tâches s'exécutent de manière asynchrone. À la différence de gnome-software, Bazaar évite de recharger constamment l'index des packages après chaque opération , ce qui rend l'expérience utilisateur excellente 🙂.

Bazaar is fast and highly multi-threaded, guaranteeing a smooth experience in the user interface. You can queue as many downloads as you wish and run them while perusing Flathub's latest releases. This is due to the UI being completely decoupled from all backend operations.

source

Je tiens tout de même à préciser que la version 49 de gnome-software a fait des progrès à ce sujet, un gros travail de refactoring a été fait sur 3 ans (73 Merge Request 😮) pour apporter le support de threading dans gnome-software.

Je pense utiliser Bazaar dans Projet 26 - "Expérimentation de migration de deux utilisateurs grand public vers des laptops sous Fedora".

#JaiLu cet excellent article "The future of Flatpak".

J'y ai appris énormément de choses au sujet de Flatpak. Le sujet est bien plus complexe que je l'imaginais. Je découvre aussi que les axes d'amélioration du projet sont nombreux.

#JaiDécouvert l'origine du nom du projet Flatpak :

Flatpak was originally developed by Alexander Larsson, who had been working on similar projects stretching back to 2007. The first release was as XDG-App in 2015. It was renamed to Flatpak in 2016, a nod to IKEA's "flatpacks" for delivering furniture.

source

J'adore l'idée derrière ce nom !

#JaiDécouvert l'extension GNOME Shell : astra-monitor (from).

J'ai bien aimé le contenu de la page "Project Comparison". Par exemple, ce paragraphe :

Introduction

Secondly, it acts as a guide for users, offering greater insights and assisting them in making an informed decision when choosing the ideal tool for their needs. By highlighting the unique features, performance benchmarks, and key differences between Astra Monitor and its alternatives, we hope to foster a transparent and informative environment for both our development team and the user community at large.

source

Voici en screenshot le résultat de mon installation :

Dépendances que j'ai installées sous ma Fedora Workstation (commit dans mon repository dotfiles) :

$ sudo dnf install \
    libgtop2-devel \
    nethogs \
    iotop \
    libdrm-devel \
    https://github.com/Umio-Yasuno/amdgpu_top/releases/download/v0.10.4/amdgpu_top-0.10.4-1.x86_64.rpm

#JaiDécouvert https://github.com/Umio-Yasuno/amdgpu_top

Voici ce que retourne la commande sensors sur mon laptop :

$ sensors
thinkpad-isa-0000
Adapter: ISA adapter
fan1:        65535 RPM
CPU:          +63.0°C
GPU:              N/A
temp3:        +63.0°C
temp4:         +0.0°C
temp5:        +63.0°C
temp6:        +63.0°C
temp7:        +63.0°C
temp8:         +0.0°C

amdgpu-pci-3300
Adapter: PCI adapter
vddgfx:        1.45 V
vddnb:       734.00 mV
edge:         +51.0°C
PPT:          19.18 W

BAT0-acpi-0
Adapter: ACPI interface
in0:          15.14 V
power1:       11.96 W

ath11k_hwmon-pci-0100
Adapter: PCI adapter
temp1:        +41.0°C

k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +62.9°C

nvme-pci-0200
Adapter: PCI adapter
Composite:    +33.9°C  (low  = -273.1°C, high = +80.8°C)
                       (crit = +84.8°C)
Sensor 1:     +33.9°C  (low  = -273.1°C, high = +65261.8°C)
Sensor 2:     +45.9°C  (low  = -273.1°C, high = +65261.8°C)

acpitz-acpi-0
Adapter: ACPI interface
temp1:        +63.0°C
temp2:        +20.0°C

Voici comment j'ai configuré la température du haut (45°C) et du bas (44°C) du screenshot :

En haut, j'ai sélectionné le paramètre acpitz-acpi-0/temp1 qui contient la température du CPU
En bas, j'ai sélectionné le paramètre amdgpu-pci-3300/edge qui contient la température du GPU

Voici mon fichier de configuration pour astra-monitor astra-monitor-settings.json.
Il est possible de facilement l'importer dans la section "Utility" de astra-monitor.

#JaiLu « Triple Buffering, a debrief » au sujet de Linux Desktop, GNOME en particulier (via).

Suite à la lecture de ce pouet, #JaiLu le billet de blog d'Emmanuele Bassi "The Mirror" qui traite de GObject et d'une stratégie d'amélioration.

Je n'ai pas compris l'intégralité de ce que j'ai lu. Cependant, l'écosystème Linux Desktop est un sujet qui me passionne depuis des années et je continue à me cultiver sur le sujet.

J'ai apprécié la lecture sur LinuxFr d'un commentaire au sujet de GTK 4 posté par un core développeur de Gimp : https://linuxfr.org/news/gimp-3-0-rc1-est-sorti#comment-1975019.

Dans le thread Reddit GNOME "Is there any chance gnome supports window tiling ?", je suis tombé à nouveau sur cet excellent article : "Rethinking Window Management - Space and Meaning".

Ensuite #JaiDécouvert l'extension Tiling Shell. J'ai décidé de tester cette extension.

J'ai l'impression que cette extension a modifié / supprimé mes raccourcis clavier de déplacement de fenêtre. Cela m'embête un peu si je décide de désactiver cette extension 🤔.

J'ai configuré les raccourcis clavier comme ceci :