Pourquoi GNOME ?

Maintenant que Mark Shuttleworth vient d’annoncer l’abandon d’Unity 8 (et probablement celui de Mir), certains se posent la question du choix de GNOME sur les forums, plutôt qu’un environnement plus traditionnel comme peuvent l’être MATE ou Xfce.

Je vais donc profiter de l’occasion pour rappeler qu’un environnement de bureau ne se limite pas à la partie visible, que ce soit avec ou sans panel au bas de l’écran et autre menu principal.

Mais avant toute chose, il est important de rappeler qu’Ubuntu a toujours utilisé GNOME, ne remplaçant finalement que son shell par ce fameux Unity. Mais pour tout le reste, que ce soit les applications de base (gestionnaire de fichiers, éditeur de texte, visionneur d’images, agenda, contacts, terminal…), le centre de contrôle ou les technologies sous-jacentes (GTK+, GVFS, GStreamer, Cairo, D-Bus, dconf…), la majeure partie des différentes briques nécessaires pour pouvoir proposer un environnement complet, homogène, fonctionnel… provenaient du projet GNOME.

Ce même GNOME qui n’a aucun problème à s’appuyer sur des projets modernes tels que systemd, PulseAudio, NetworkManager… qui permettent de construire un environnement robuste et pleinement fonctionnel, parfaitement adapté à notre époque (technologies récentes, informatique dans les nuages, mobilité…), là où d’autres préfèrent partir dans des trolls sans fin, préférant voir l’utilisateur tout configurer par lui-même plutôt que de lui proposer un environnement qui juste marche.

Ensuite, et c’est le plus important, il ne faut pas limiter un environnement de bureau à un panel et un menu principal. Ça se doit d’être avant tout une plateforme proposant un certain nombre de technologies (bibliothèques, frameworks, couches d’abstraction, système de configuration…) facilitant le travail des développeurs tout en leur permettant de concevoir des applications qui seront parfaitement intégrées à l’environnement et qui pourront interagir les unes avec les autres.

Cinq jours avant l’annonce de Mark Shuttleworth, Dustin Kirkland, le chef de projet d’Ubuntu, intervenait sur Hacker News pour interroger la communauté et connaître ses retours et ses attentes quant à la version 17.10 d’Ubuntu. Une intervention suivie avec grand intérêt par Christian Schaller, le responsable de l’équipe Red Hat en charge de l’environnement de bureau GNOME. Deux jours avant l’annonce de Mark Shuttleworth, ce dernier publiait à son tour un long billet de blog pour rappeler que la majeure partie des demandes étaient déjà présentes dans Fedora au travers de GNOME, Wayland, libinput et autres technologies libres nécessaires pour obtenir un bureau pleinement fonctionnel.

Parmi les principaux points soulevés, on peut citer la prise en charge des écrans à haute densité de pixels, qui se trouvent être déjà fonctionnels sous GNOME avec une mise à l’échelle 2, et dont la mise à l’échelle fractionnée (par exemple, 1.5) devrait arriver dans Fedora 27, voir même dans Fedora 26 s’ils arrivent à tout finaliser dans les temps. Il en profite d’ailleurs pour rappeller qu’en plus de sa prise en charge dans GNOME, Red Hat a employé des développeurs pour que Firefox et LibreOffice puissent utiliser GTK+ 3 et être compatibles avec Wayland.

Pouvoir utiliser les pavés tactiles avec trois doigts ou plus. Pendant longtemps, on ne pouvait utiliser que des gestes utilisant maximum deux doigts. Là encore, dans le but de supprimer une telle limitation, Red Hat a mis des développeurs sur le coup pour créer libinput et améliorer les pilotes comme celui de Synaptics, qui utilisait encore le port de communication PS/2, ce qui limitait les possibilités.

Faire des progrès sur la consommation énergétique en cas d’utilisation d’un ordinateur portable. Là encore, Red Hat a embauché des développeurs pour investiguer, corriger ce qui pouvait l’être, discuter avec les fabricants de matériel en vue d’améliorer leurs pilotes (comme ceux de nVidia, qui ne sont malheureusement pas libres).

GNOME Battery Bench

Corriger les problèmes concernant l’UEFI. Là encore, un employé Red Hat est membre du comité UEFI, ce qui aide grandement à ce que tout se passe bien avec le libre. Tout comme ils ont également embauché des développeurs pour que la mise à jour des firmwares UEFI puissent se faire directement depuis la logithèque GNOME. Christian Schaller en profite d’ailleurs pour annoncer que normalement, d’ici la fin de l’année tous les principaux fabricants devraient fournir des mises à jour au travers du service fwupd qu’utilise la logithèque GNOME.

Wayland. Les utilisateurs d’Ubuntu réclamaient Wayland. Ça tombe bien, c’est le choix par défaut sous GNOME :p Christian Schaller annonce qu’en plus du multi-DPI, on devrait voir arriver la prise en charge du HDR (grande gamme dynamique) ainsi que la prochaine génération de machines hybrides (multi-GPU), en travaillant de concert avec nVidia pour s’assurer que leurs pilotes fonctionnent parfaitement sur des systèmes libres (comprendre, sans avoir à bidouiller).

Quelque chose comme Redshift. Pour rappel, il s’agit d’une application permettant d’ajuster la température de couleur d’un écran en fonction du moment de la journée. Et là encore, ça tombe bien, avant même qu’Apple ne propose son Night Shift avec macOS 10.12.4 ou Microsoft son Mode Nuit avec la Creators Update de Windows 10, GNOME proposait déjà un mode nuit dans GNOME 3.24.

Le mode nuit dans GNOME 3.24

Amélioration du processus de mise à jour des pilotes graphiques. Je ne vais pas le répéter à chaque fois (enfin si, un peu, ça permet de bien réaliser tout ce qu’aurait dû faire Canonical dès le début), mais là encore, Red Hat possède toute une équipe pour travailler sur la pile graphique Linux (Wayland, Mesa, les pilotes…). Et un projet important aura été le développement avec nVidia de la bibliothèque glvnd qui permet d’utiliser plusieurs implémentations d’OpenGL en parallèle. Finis le risque de voir le pilote nVidia écraser les fichiers de Mesa ou inversement. Plus besoin non plus d’une bidouille à la Bumblebee pour utiliser son APU au quotidien, puis basculer facilement sur le GPU de la carte dédiée quand on souhaite se faire une petite partie de jeu vidéo.

Amélioration de la prise en charge des imprimantes. Là encore, plusieurs développeurs Red Hat s’assurent que CUPS (qui est un projet Apple, pour l’anecdote) fonctionne parfaitement bien. Et côté GNOME, la version 3.24 offre désormais une gestion des imprimantes bien plus simple et efficace.

Meilleure prise en charge du Bluetooth. Là encore, il y a plusieurs développeurs Red Hat sur le coup. Et parmi les changements à venir (sans doute dans PulseAudio 11), on peut citer par exemple une modification de Christian Kellner qui améliorera le choix des périphériques par défaut. Actuellement, PulseAudio privilégie la carte audio PCI, suivi des cartes audio USB, pour finir par un périphérique Bluetooth. À l’avenir, les choix par défaut devraient être plus logiques. Si l’on branche une carte audio USB, c’est sans doute que l’on ne souhaite pas utiliser le chipset audio fournit de base avec la carte mère. Même chose pour les micro-casques, dont la sortie audio n’était pas automatiquement redirigée vers ces derniers. Autre apport intéressant, le rapport d’état de la batterie de certains modèles devrait également faire parti des changements à venir.

Tout ça pour conclure que si l’on regarde honnêtement des bureaux comme MATE ou Xfce, qui ne gèrent pas ou de façon limitée tous les points soulevés (et tous n’ont pas été abordés, comme la prise en charge des services en ligne, la compatibilité Microsoft Exchange nécessaire aux entreprises, de meilleures applications de productivité (agenda, contacts…), la documentation, le design et l’ergonomie…), on comprend mieux le choix de Canonical de continuer à privilégier GNOME.

D’autant plus que rien ne les oblige à proposer un GNOME vanilla. Ils pourraient très bien adapter leur dock ou proposer certaines extensions par défaut.

Le « BIOS » pourra bientôt être facilement mis à jour sous Linux

 

UEFI

Christian Schaller a publié un billet de blog le mois dernier, où l’on apprenait que les spécifications de l’UEFI 2.5, dont les premières cartes mères équipées devraient sortir d’ici la fin de l’année, autoriseraient la mise à jour du micrologiciel depuis n’importe quel système d’exploitation supportant ces nouvelles spécifications ; ce qui sera le cas de Linux. On apprend d’ailleurs que Red Hat possède un représentant au sein du groupe de travail UEFI. C’est une bonne chose de constater que l’industrie ne se contente plus désormais du simple avis de Microsoft.

Avec Richard Hughes, qui est en charge du développement de Logiciels et de la spécification AppData, et qui a également publié un billet à ce sujet, ils auraient travaillé avec Microsoft et différents constructeurs pour voir ce qui serait le plus simple. Apparemment, on se dirigerait vers une archive CAB qui contiendrait, en plus du micrologiciel lui-même, un fichier .INF qui préciserait un certain nombre d’informations telles que l’ID du matériel attendu par le micrologiciel, le nom du fabriquant, la liste des modifications apportées…

Certains constructeurs, favorables à Linux, devraient également fournir un fichier AppStream. Le but étant, à terme, de pouvoir effectuer la mise à jour directement depuis le gestionnaire de logiciels, comme pour n’importe quel autre programme. Chez Red Hat, la mise à jour ne s’effectuera par contre que lors du prochain boot système, mais j’ignore s’il s’agit d’une limitation technique, ou d’une simple précaution de leur part, pour éviter de potentiels problèmes.

Pour l’intégration au sein du système de packages des différentes distributions, ça semble pour le moment plus confus. Dans le cas de micrologiciels dont la redistribution serait autorisée, Red Hat prévoit de créer des RPM pour ces derniers (les autres distributions pourront bien évidemment faire de même). Mais dans le cas de conditions plus restrictives, ils pensent pour le moment à une simple notification à l’utilisateur de l’existence d’une telle mise à jour, tout en lui indiquant où il pourra la télécharger.