Fond d'écran par défaut d'Ubuntu 24.04

Une histoire de piaf et de prophétie

Ubuntu 24.10 : destination Wayland et chiffrement intégral du disque

Fond d'écran par défaut d'Ubuntu 24.04

Dans sa dernière communication, l’équipe de développement d’Ubuntu a donné plusieurs informations importantes sur la prochaine version de la distribution Linux. La mouture 24.10 devrait être nettement plus riche en nouveautés que la 24.04 LTS du mois dernier.

Ubuntu 24.04, alias Noble Numbat, n’était pas dénuée d’apports. Mais on ne peut pas dire qu’elle ait révolutionné l’informatique, ce qui convient d’ailleurs à une bonne part des utilisateurs. Il s’agissait en fait d’un contexte particulier : l’activation par défaut des framepointers et d’autres éléments, ainsi que le gros problème de sécurité engendré par l’affaire XZ Utils ont entrainé une révision des plans et une compilation de toute la distribution.

Le temps « perdu » a limité le nombre de nouveautés à inclure dans la bêta publique, qui ne dure que deux ou trois semaines. Les plans pour Ubuntu 24.10 – qui s’appellera Oracular Oriole – sont de rattraper le retard et de lisser les nouveautés introduites dans Noble Nombat. Des apports significatifs sont prévus.

Chiffrement intégral du disque et Wayland

Canonical compte réactiver la télémétrie sur les problèmes de configuration rencontrés sur les périphériques. La société ambitionne en effet d’utiliser par défaut le chiffrement intégral du disque basé sur la puce TPM. L’annonce fait étrangement suite à celle de Microsoft, qui s’avance dans la même direction.

Ce retour d’informations interviendra dès l’installation du système. L’installeur, intégralement revu pour Ubuntu 23.10 et amélioré dans la version 24.04 LTS, sera donc à nouveau renforcé. Les informations captées devraient aider Canonical à mieux cerner certains soucis techniques, notamment ceux liés aux pilotes NVIDIA.

L’éditeur compte ainsi préparer le terrain au chiffrement intégral du disque (qui n’interviendra peut-être pas dans la prochaine version) et activer par défaut Wayland pour les possesseurs de GPU NVIDIA.

« Il y a encore quelques problèmes connus avec cette combinaison et en raison de la forte utilisation d'Ubuntu Desktop dans l'IA/ML, VFX et d'autres industries, nous avons conclu qu'il était trop tôt pour faire ce changement dans Ubuntu 24.04 LTS », ajoute Canonical.

L’activation par défaut va, là aussi, permettre la remontée d’informations. L’éditeur évoque une liste de problèmes réduite, qui devrait permettre la même activation par défaut dans Ubuntu 26.04, la prochaine édition LTS du système. Avec Ubuntu 24.10, Wayland devrait donc être actif sur la totalité des configurations, l’ancien serveur graphique X restant disponible en solution de secours.

De multiples autres nouveautés

GNOME 47 sera de la partie. Sa version finale devrait être prête quelques semaines avant la publication de la bêta d’Ubuntu 24.10. Canonical va d’ailleurs profiter de l’intégration renforcée de Wayland dans GNOME à cette occasion.

L’assistant de bienvenue va également être révisé. Canonical poursuit son travail de réécriture pour ses applications intégrées en les passant à la moulinette Flutter. L’assistant va donc être remanié en tenant compte des changements intervenus dans l’installeur, pour donner une continuité dans l’expérience utilisateur. De nouvelles fonctions doivent y être ajoutées, dont la création de comptes utilisateurs.

Puisque l’on parle de Flutter, Canonical ajoute que le travail de migration de GTK3 vers GTK4 continue. Les bénéfices attendus sont de meilleures performances ainsi qu’une prise en charge améliorée de l’accessibilité. Sur ce dernier point, rappelons que l’un des apports d’Ubuntu 24.04 est la possibilité d’activer les options d’accessibilité dès le début du processus d’installation.

Le Centre d’applications sera enrichi lui aussi. La découverte sera facilitée sur un plus grand nombre de catégories. On y trouvera aussi le support des installations tierces de paquets DEB. Enfin, une amélioration est prévue pour les messages de mises à jour pour les snap en cours d’exécution.

Version immuable et embauches massives

Enfin, deux nouvelles d’importance. D’abord, le travail continue sur Ubuntu Core Desktop, la première version immuable du système pour les machines de bureau.

Ensuite, Canonical va embaucher. Dans l’année qui vient, l’entreprise compte faire grandir l’équipe Ubuntu Desktop « d’au moins 50 % ». « Si vous avez la passion et les compétences nécessaires pour être à la pointe de la performance, de la sécurité, de l'immuabilité et de l'accessibilité, alors nous voulons vous connaître », indique l’entreprise.

Commentaires (13)


J'avoue avoir un peu de mal avec Wayland. On n'arrête pas de dire que le modèle X est totalement dépassé, car il part du principe que l'application tourne sur un serveur distant et puissant, en s'affichant sur un terminal local aux performances plus faibles. Et surtout qu'il ne viendrait à l'idée de plus personne de faire ça...

Mais. Car il y a un mais. Il tient en un mot.

Cloud...

Sauf qu'aujourd'hui pour le Cloud, on stream un flux vidéo directement pas un modèle client serveur avec API comme X avec le fameux network transparency.

Patatt

Sauf qu'aujourd'hui pour le Cloud, on stream un flux vidéo directement pas un modèle client serveur avec API comme X avec le fameux network transparency.
Bah je dis pas, mais... Si j'ai un serveur n'importe où dans le cloud, installé sans le moindre environnement de bureau, je peux, si je veux, m'y connecter par ssh -X et depuis la ligne de commande taper gitk --all & et je peux me balader simplement dans l'historique git exactement comme si j'étais en local. Avec une technologie qui existe depuis 30 ans...

À part des emm rd m nts, un énième port TCP à whitelister (ce qui implique que je sois administrateur de l'environnement cloud), un audit de sécurité, une liste longue comme le bras de packages à installer et des soucis de compatibilité, qu'est-ce qu'un flux vidéo streamé directement m'apporterait ?

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Bah je dis pas, mais... Si j'ai un serveur n'importe où dans le cloud, installé sans le moindre environnement de bureau, je peux, si je veux, m'y connecter par ssh -X et depuis la ligne de commande taper gitk --all & et je peux me balader simplement dans l'historique git exactement comme si j'étais en local. Avec une technologie qui existe depuis 30 ans...

À part des emm rd m nts, un énième port TCP à whitelister (ce qui implique que je sois administrateur de l'environnement cloud), un audit de sécurité, une liste longue comme le bras de packages à installer et des soucis de compatibilité, qu'est-ce qu'un flux vidéo streamé directement m'apporterait ?
Sinon, Git est justement fait pour accéder facilement à des repos à distance, et offre tous les outils possibles pour le faire, en particulier à travers SSH.

Tu n'as aucunement besoin d'un flux video ou d'un desktop à distance pour gérer un repo git, encore moins pour simplement parcourir l'historique.

Il suffit d'ajouter qqchose comme (au pif) ssh://user@ip-distante:/path/du/repo en tant que remote du ton repo git local. C'est beaucoup plus propre, sécuritaire et efficace que d’utiliser X.
Modifié le 20/05/2024 à 20h28

Historique des modifications :

Posté le 20/05/2024 à 20h25


Sinon, Git est justement fait pour accéder facilement à des repos à distance, et offre tous les outils possibles pour le faire, en particulier à travers SSH.

Tu n'as aucunement besoin d'un flux video ou d'un desktop à distance pour gérer un repo git.

Il suffit d'ajouter qqchose comme (au pif) ssh://user@ip-distante:/path/du/repo en tant que remote du ton repo git local.

Posté le 20/05/2024 à 20h27


Sinon, Git est justement fait pour accéder facilement à des repos à distance, et offre tous les outils possibles pour le faire, en particulier à travers SSH.

Tu n'as aucunement besoin d'un flux video ou d'un desktop à distance pour gérer un repo git, encore moins pour simplement parcourir l'historique.

Il suffit d'ajouter qqchose comme (au pif) ssh://user@ip-distante:/path/du/repo en tant que remote du ton repo git local.

wagaf

Sinon, Git est justement fait pour accéder facilement à des repos à distance, et offre tous les outils possibles pour le faire, en particulier à travers SSH.

Tu n'as aucunement besoin d'un flux video ou d'un desktop à distance pour gérer un repo git, encore moins pour simplement parcourir l'historique.

Il suffit d'ajouter qqchose comme (au pif) ssh://user@ip-distante:/path/du/repo en tant que remote du ton repo git local. C'est beaucoup plus propre, sécuritaire et efficace que d’utiliser X.
Et dire que je le savais ...

Je le savais que si je prenais un exemple simple (gitk) d'une application GUI que je veux utiliser à distance, quelqu'un allait me rappeler que j'étais idiot et qu'il existe une autre solution pour cet exemple précis...

Merci à tous de m'apprendre une fois de plus mon métier.

33A20158-2813-4F0D-9D4A-FD05E2C42E48

Et dire que je le savais ...

Je le savais que si je prenais un exemple simple (gitk) d'une application GUI que je veux utiliser à distance, quelqu'un allait me rappeler que j'étais idiot et qu'il existe une autre solution pour cet exemple précis...

Merci à tous de m'apprendre une fois de plus mon métier.
Je comprend ton agacement, mais c'est un peu le pire exemple que tu as choisi.
Surtout qu'en pratique, peu de serveurs Git ont un serveur X.
Et que Git a été conçu pour être utilisé à distance par SSH.
Modifié le 20/05/2024 à 23h28

Historique des modifications :

Posté le 20/05/2024 à 21h53


Je comprend ton agacement, mais c'est un peu le pire exemple que tu as choisi.
Surtout qu'en pratique, peu de serveurs Git ont un serveur X.
Et que Git a été conçu pour être utilisé distance par SSH.

Mais qui t'a dit que ce n'était pas possible avec wayland ? Xorg n'est pas encore mort (pour l'installer sur du cloud), et tu l'ouvres en local avec xwayland.

Sinon, tu as des compositeurs wayland légers basés sur wlroots utilisables et le logiciel wayvnc qui permettent de faire du headless en software (désolé pour les anglicismes). Tu lances ton application en mode cage, et tu t'y connectes avec un client vnc.

Le besoin n'étant pas énorme, ce genre de cas n'est pas traité de façon simple, mais reste possible. Et bien sûr, un vnc peut être encapsulé en ssh, mais ça, tu le sais sûrement.

Wayland permet énormément de choses légères (si tu regardes du côté de wlroots en tout cas).

Edit: j'ai oublié waypipe qui a pour but de faire du ssh -X à la sauce wayland. À tester.
Modifié le 21/05/2024 à 09h18

Historique des modifications :

Posté le 21/05/2024 à 09h02


Mais qui t'a dit que ce n'était pas possible avec wayland ? Xorg n'est pas encore mort (pour l'installer sur du cloud), et tu l'ouvres en local avec xwayland.

Sinon, tu as des compositeurs wayland légers basés sur wlroots utilisables et le logiciel wayvnc qui permettent de faire du headless en software (désolé pour les anglicismes). Tu lances ton application en mode cage, et tu t'y connectes avec un client vnc.

Le besoin n'étant pas énorme, ce genre de cas n'est pas traité de façon simple, mais reste possible. Et bien sûr, un vnc peut être encapsulé en ssh, mais ça, tu le sais sûrement.

Wayland permet énormément de choses légères (si tu regardes du côté de wlroots en tout cas).

guildem

Mais qui t'a dit que ce n'était pas possible avec wayland ? Xorg n'est pas encore mort (pour l'installer sur du cloud), et tu l'ouvres en local avec xwayland.

Sinon, tu as des compositeurs wayland légers basés sur wlroots utilisables et le logiciel wayvnc qui permettent de faire du headless en software (désolé pour les anglicismes). Tu lances ton application en mode cage, et tu t'y connectes avec un client vnc.

Le besoin n'étant pas énorme, ce genre de cas n'est pas traité de façon simple, mais reste possible. Et bien sûr, un vnc peut être encapsulé en ssh, mais ça, tu le sais sûrement.

Wayland permet énormément de choses légères (si tu regardes du côté de wlroots en tout cas).

Edit: j'ai oublié waypipe qui a pour but de faire du ssh -X à la sauce wayland. À tester.
Waypipe est un peu complexe à utiliser, il y a quelques subtilités qui rendent des erreurs difficiles a investiguer, mais c'est un projet assez "récent" aussi qui s'améliore beaucoup. Mais c'est quand même toujours bien plus complexe qu'un ssh -X :frown:
J'espère qu'avec le chiffrement, on pourra toujours installer anaconda sans se prendre la tête... parce qu'à l'heure actuelle, les chemins pour certains fichiers dépassent les 255 caractères, et donc, avec un compte chiffré sur Mint (basé sur Ubuntu), pas moyen d'installer la suite : il faut passer par l'installation dans un dossier non chiffré. Grosse prise de tête pour comprendre quel était le soucis, et comment le contourner !
Chiffrement intégral du disque par défaut, on le voit pour linux, windows en a parlé aussi... Mais concrètement, si la carte mère tombe en rade, on perds accès à tous ses stockages ?

Quelles sont les procédures de restauration pour ces cas de figure ?
J'imagine que de la même manière que pour Bitlocker, ou LUKS (on chiffre nos Debian avec le TPM avec LUKS chez nous): une clé qui te permet de déchiffrer que tu gardes soigneusement quelque part
Si Windows veut maintenant un chiffrement Bitlocker du disque et Ubuntu veut son propre chiffrement du disque pour fonctionner, on pourra toujours faire du dual-boot ?
Les 2 systèmes chiffrent les partitions et pas tout le disque. De plus, chacun d'eux a besoin d'une (ou plusieurs) partitions non chiffrées pour démarrer.
On devrait donc toujours pouvoir faire du dual boot. Même si ça n'a que peut d'intérêt. :troll:
Fermer