Fedora 25 est disponible !

55
22
nov.
2016
Fedora

En ce mardi 22 novembre 2016, le projet Fedora est fier d’annoncer la sortie de la distribution GNU/Linux Fedora 25.

Fedora est une distribution communautaire développée par le projet éponyme et sponsorisée par Red Hat, qui lui fournit des développeurs ainsi que des moyens financiers et logistiques. Fedora peut se voir comme une sorte de vitrine technologique pour le monde du logiciel libre, c’est pourquoi elle est prompte à inclure des nouveautés.

Une des nouveautés majeures est l’activation par défaut de Wayland grâce à l’arrivée de GNOME 3.22. Fedora devient la première distribution majeure à le fournir, par défaut, pour GNOME.

D’autres changements moins visibles améliorent le confort d’utilisation. Les développeurs noteront l’amélioration de Flatpak pour faciliter leur gestion de logiciels et l’arrivée du compilateur pour le langage Rust.

Fedora

Sommaire

Présentation

Fedora est une distribution communautaire développée par le projet Fedora et sponsorisée par Red Hat, qui lui fournit des développeurs ainsi que des moyens financiers et logistiques. Fedora peut se voir comme une sorte de vitrine technologique pour le monde du logiciel libre, c’est pourquoi elle est prompte à inclure des nouveautés.

Fedora garde un rôle central dans le développement de ces nouveautés via le développement en amont. En effet, les développeurs de la distribution contribuent également directement au code d’un certain nombre de logiciels libres contenus dans la distribution, dont le noyau Linux, GNOME, NetworkManager, PackageKit, PulseAudio, X.Org, systemd, la célèbre suite de compilateurs GCC, etc. Cliquez ici pour voir l’ensemble des contributions de Red Hat.

Par ailleurs, les distributions telles que RHEL, Scientific Linux ou CentOS (plus indirectement), avec un cycle de sortie plus espacé permettant un support à plus long terme, sont développées à partir d’une version de Fedora et mises à jour environ tous les trois à cinq ans. Notons que CentOS est un clone gratuit de RHEL, cette dernière étant certes libre, mais payante, offrant ainsi un support technique, des certifications et une garantie.

Environnement bureautique

logo de Wayland
La nouveauté la plus importante est sans conteste la mise à disposition par défaut de Wayland pour l’environnement bureautique GNOME. Fedora devient ainsi la première distribution majeure à faire ce choix, pour promouvoir ce projet novateur annoncé il y a maintenant huit ans. Wayland consiste en une remise à plat du système d’affichage graphique historique des systèmes UNIX, X Window version 11 (X11) (qui a plus de 30 ans) et dont X.Org est l’implémentation actuelle sur GNU/Linux, en tenant compte de l’évolution des usages et de l’architecture de nos machines aujourd’hui. Wayland vise à améliorer la sécurité du système, en évitant qu’une application quelconque puisse dessiner sur d’autres applications, par exemple. Il pourrait à terme améliorer les performances, en exploitant pleinement l’accélération matérielle par les cartes graphiques. En outre, il devrait fiabiliser le système, en améliorant l’architecture du programme et en facilitant sa maintenance.

Pour revenir à X.org, si besoin
Cependant, si Wayland commence à devenir mûr, de nombreuses fonctionnalités restent à proposer par rapport à l’expérience proposée par X11. C’est pourquoi, à l’ouverture de la session GNOME, il reste possible de choisir X11. Pour ceux qui n’ont pas besoin de ces fonctions, l’usage de Wayland devrait être totalement transparent. Fedora espère proposer toujours plus de technologies innovantes et modernes et récolter beaucoup de retours afin de les améliorer avant une éventuelle généralisation à d’autres distributions. Notons que si les autres environnements comme KDE peuvent exploiter Wayland, la stabilité n’est pas encore jugée suffisante pour proposer cela par défaut pour ces environnements.

Cette nouveauté a été possible grâce à la mise à jour de GNOME à la version 3.22.

Logiciels gère nativement mais sommairement le format de paquets Flatpak de Freedesktop.org qui est un format concurrent de Snap de Canonical. Dans cette optique de cloisonnement, les applications doivent demander des autorisations pour accéder à certaines fonctions comme la géolocalisation, de manière similaire à ce qui se fait sur téléphone. La stabilité de l’API des extensions est telle, que les versions prises en charge par les extensions ne sont plus vérifiées pour enrichir l’écosystème. Fichiers peut faire du renommage multiple, tirant parti des métadonnées éventuelles dans ce but. Fichiers est également dissocié de l’affichage du bureau lui‐même, pour améliorer la stabilité du système. Et bien d’autres changements !

Fedora Media Writter
Nous en avions parlé pour Fedora 24, l’utilitaire Fedora Media Writer est la méthode de téléchargement de Fedora par défaut. L’objectif est en effet que l’utilitaire télécharge et installe très simplement une version spécifiée de Fedora, qui peut être un Spin, par exemple. Cela évite notamment de devoir graver l’image disque à la main sur clé USB ou CD, étape compliquée pour trop d’utilisateurs potentiels. Cette fois, l’utilitaire est disponible pour Windows et Mac OS X également, d’où sa mise en avant pour cette version.
Capture d’écran de Media Writer

La distribution propose de mieux exploiter les machines avec deux cartes graphiques, une intégrée au processeur et une autre externe. Cette configuration, très populaire sur les ordinateurs portables récents, permet en temps normal d’avoir une carte graphique minimale suffisante pour la bureautique qui consomme peu d’énergie et d’utiliser la carte externe pour les applications gourmandes. Jusqu’ici, sans outil externe, votre environnement fonctionnait avec une carte graphique seulement et sans possibilité de changer celle en fonction à chaud. Aujourd’hui, celle intégrée au processeur est utilisée par défaut. Puis, en cas de besoin, vous pouvez lancer un logiciel sur l’autre carte graphique. Cela nécessite de lancer le programme avec la variable d’environnement DRI_PRIME=1 ou via un clic droit pour lancer l’application dans l’interface GNOME Shell.
Lancer une application sur la carte graphique externe

Administration système

Fedora poursuit le changement opéré par Fedora 24, avec la suppression des algorithmes de sécurité obsolètes RC4 et SSL 3.0 dans la bibliothèque NSS. Après les bibliothèques OpenSSL et GnuTLS, cela concerne donc cette fois les applications de Mozilla ou cURL. Cela permet d’améliorer la sécurité des applications en empêchant l’utilisation de ces protocoles qui ne sont plus sécurisés. Dans la même veine, les certificats 1 024 bits provenant d’autorités de certification ont été supprimés du système.

Deux liens symboliques liés à SSH sont supprimés : slogin et sshd-keygen. Le premier était un lien symbolique vers ssh lui‐même pour la compatibilité avec d’anciens systèmes, mais qui a été supprimé par le projet officiel il y a peu, et Fedora a décidé d’en faire autant. Le second était un script, notamment d’initialisation, pour générer les clés SSH. Cependant, avec le passage à systemd, il a été supprimé et les applications qui ont besoin des clés SSH disponibles sur le système devront dépendre du service systemd sshd-keygen.target.
Logo d’OpenSSH

La bibliothèque UDisks2 a été remplacée par Storaged. Cette bibliothèque est en fait un fork de UDisks2 pour proposer des greffons orientés pour l’entreprise pour gérer les volumes LVM2 et iSCSI. Elle gère aujourd’hui également Btrfs, BCache, LSM et ZRam. Cependant la compatibilité binaire et avec DBus a été préservée. Cela concerne la plupart des logiciels qui s’occupent des espaces de stockages, tels que GVFS, GNOME Disques, blivet ou Cockpit.

Améliorations dans l’utilitaire Cockpit. Cet utilitaire, prisé par les administrateurs système, dispose maintenant d’un module similaire au rapporteur graphique des anomalies constatées par SELinux, avec la suggestion de correction si l’anomalie est légitime. Les clés SSH de l’hôte sont affichées dans le tableau de bord pour identifier plus facilement les changements opérés sur celui‐ci. En outre, il devient possible d’utiliser l’identification par deux facteurs, pour améliorer la sécurité d’accès.

FreeIPA, le système de gestion d’identité progresse à la version 4.4. Cette version apporte dans l’interface Web la possibilité de visualiser et de modifier la topologie du système. Cette même interface peut être accessible via une identification par clés de sécurité ou certificats. L’intégration d’Active Directory progresse, avec l’ajout de fonctions pour les environnements professionnels, comme les utilisateurs qui peuvent changer leurs informations via la ligne de commande ou encore le solveur DNS qui gère les conflits d’espaces de noms. Et bien d’autres choses encore !

Développement

La bibliothèque standard Glibc progresse à la version 2.24. Comme souvent, glibc renforce sa stabilité et sa sécurité par des correctifs mineurs. Fedora en a profité pour créer deux paquets glibc-nss-devel et libcrypt-nss pour tout ce qui concerne NSS, afin d’alléger les systèmes n’en ayant pas besoin. Dans ce but également, les binaires sln et ldconfig sont maintenant identiques, car ils avaient beaucoup de code en commun. Comme busybox, l’usage de la partie spécifique de l’un ou de l’autre dépendra du nom de la commande d’invocation.

Pour Python, il est possible d’installer des versions concurrentes ensemble. Auparavant, Fedora ne proposait que les dernières versions de Python des branches 2.x et 3.x. Aujourd’hui, il existe des paquets pour exploiter Python 3.5, 3.4, 3.3, 2.7 et 2.6 au sein d’un même système, pour faciliter le travail des développeurs sur des applications pas toujours compatibles.

Le compilateur de Haskell, GHC, passe à la version 7.10. Cette version introduit des changements majeurs, rompant la compatibilité avec le passé. Par exemple, la classe Applicative devient une superclasse de Monad. Parmi les améliorations importantes, GHC se débarrasse des conditions spécifiques accordées à la bibliothèque C GMP pour gérer les grands nombres, dorénavant c’est une bibliothèque comme les autres. Les greffons peuvent aussi modifier le comportement du vérificateur de type, qui, lui‐même, peut gérer une signature de fonction partielle pour la traiter en détail dans un second temps.

Le reluisant langage Perl évolue à la version 5.24. Cette version apporte la gestion de l’Unicode 8.0 et le hasbang redirige maintenant vers le futur Perl 6. Certains comportements sont mieux définis, comme les décalages d’entiers négatifs (avec << ou >>) ou les fonctions printf() et assimilées qui peuvent changer la précision des arguments. Les noms de variables en ASCII doivent être des caractères visibles. Et bien d’autres choses encore…

Logo de Node.js
Pour les amateurs de JavaScript, c’est Node.js qui utilise la branche 6.x (6.9, plus précisément). En effet, Fedora avait repoussé ce changement pour des raisons de durée de vie des versions de ce projet. Parmi les améliorations notables, nous avons une meilleure gestion des erreurs dans beaucoup de modules. Il y a aussi une meilleure sécurité, par la mise à jour de nombreuses dépendances (comme OpenSSL ou V8) mais aussi par des changements de comportement comme url.resolve() qui n’envoie pas un couple identifiant-mot de passe en cas de changement de l’hôte par exemple. Et bien d’autres changements, qui peuvent nécessiter une adaptation des modules ou applications.

Logo de Rust
Le compilateur pour le langage Rust est enfin disponible. Le langage développé par Mozilla va servir de base aux changements à venir du moteur de rendu de Firefox : Gecko. En fait, ce langage a été conçu dans l’optique de remplacer le C ou le C++, avec des performances similaires mais une fiabilité à l’exécution accrue en réalisant beaucoup de vérifications en amont ou de par sa gestion de la concurrence permettant de tirer profit sans grand risque du parallélisme de nos processeurs. Cette mise à disposition permettra à la communauté autour de ce langage d’y travailler depuis Fedora plus simplement.

Le langage Go fonce à la version 1.7. Le langage de Google bénéficie surtout d’un changement de ses outils périphériques, le langage lui‐même bénéficiant de changements mineurs. Google s’est attaqué à de nombreuses optimisations, principalement pour l’architecture x86-64. Par exemple, le compilateur est basé sur une nouvelle architecture SSA permettant d’identifier plus rapidement des portions de code inutiles, afin de gagner du temps à l’exécution et en taille de binaire. Le ramasse‐miettes et le compilateur ont été optimisés également, tout comme le format d’exportation des binaires. Selon Google, les binaires pourraient être de 20 à 30 % plus légers, et la vitesse d’exécution de 5 à 35 % plus rapide.

Le langage fonctionnel Erlang 19 est à l’honneur. Cette version apporte beaucoup de choses, comme une amélioration des performances des fonctions cryptographiques via l’ajout d’une interface permettant l’usage plus poussé d’OpenSSL. Une nouvelle machine d’état gen_statem est proposée, destinée à remplacer gen_fsm en étendant ses fonctionnalités comme les évènements qui peuvent être repoussés. Mais aussi l’ajout expérimental de la gestion des UNIX Domain Sockets, ouvrant la voie à l’interaction d’Erlang avec journald, systemd ou encore dbus, que le nouveau paquet erlang-dbus permet.

Le cadriciel Ruby on Rails est sur les rails vers la version 5.0. Il met à disposition ActionCable pour interagir avec les WebSockets, API mode pour concevoir des API serveur plus facilement, ou encore le nouvel utilitaire Rake pour exploiter Rails en ligne de commande.

Logo de PHP
Le langage PHP s’impose avec la version 7.0. Cette version majeure garde une bonne compatibilité ascendante avec la précédente. Une bonne partie a été réécrite pour améliorer les performances de consommation mémoire et de temps d’exécution (de l’ordre de 50 % pour chaque, pour les gros sites). Mais l’API interne a beaucoup changé, ce qui a impliqué beaucoup de réécriture des extensions en C et la suppression de toutes celles qui n’ont pas su tenir le rythme.

Inclusion de Jekyll, un utilitaire qui transforme vos fichiers textes au format Liquid et Markdown en site Web ou blog automatiquement. GitHub Pages repose sur cette solution, par exemple.

Internationalisation

La norme UNICODE 9.0 fait son entrée dans Fedora 25. Cette mise à jour apportée aux bibliothèques de base de la distribution, telle que glibc permet de la répercuter sur l’ensemble des applications. Elle apporte près de 7 500 caractères, environ 70 emojis et ajoute ou améliore la gestion de certaines langues asiatiques et africaines.
Logo d’Unicode

L’assistant à la saisie iBus a bénéficié de plusieurs améliorations importantes. Tout d’abord, vous connaissiez peut‐être déjà la saisie de n’importe caractère Unicode en rentrant son code hexadécimal après Ctrl + Maj + U ? Bien pratique parfois, mais néanmoins peu utilisable génériquement, à moins de connaître par cœur tout Unicode. Or, typiquement, les « caractères emojis » ne sont pas disponibles par défaut sur les claviers. Ainsi, plutôt que d’insérer manuellement les codes de caractères Unicode, il sera maintenant possible de rentrer des mots‐clés après Ctrl + Maj + E, ce qui proposera une liste d’emojis correspondants. Les mots clés sont tirés de la liste des annotations emoji, lesquelles sont localisées.
castle emoji
Mais iBus propose également une aide à la saisie rapide qui a été améliorée pour suggérer des emojis.

Ce même assistant — qui suggère des mots durant la frappe — peut dorénavant proposer plusieurs langues à la fois. Ainsi, il est possible d’auto‐compléter le terme en cours en anglais alors que la phrase est en français et inversement.
Several languages

Du côté du Projet Fedora

L’image minimale de base de Fedora ne dispose plus des paquets Perl pour l’alléger d’environ 20 Mio et simplifier sa maintenance. Cette image de base, qui pèse aujourd’hui 527 Mio, est utilisée par Koji pour tester l’installation d’un ensemble de paquets essentiels pour toutes les images de Fedora. Elle est aussi exploitée par les empaqueteurs pour s’assurer du bon fonctionnement d’une mise à jour ou d’un nouveau paquet. Cela leur offre donc également un gain de temps important à terme.

Un nouvel outil pour gérer la création des images officielles a été conçu. Nommé Release Engineering Automation Workflow Engine, il met en œuvre une centralisation dans la communication entre certains composants de l’infrastructure, afin de collecter les journaux associés et de proposer un véritable espace de travail pour simplifier ce processus. Le tout reposant sur Ansible, il permet de remplacer un bon nombre de scripts et autres tâches planifiées cron et de simplifier l’infrastructure existante. Cela permettra au processus de devenir plus flexible à l’avenir car plus fiable et rapide, notamment dans le cadre de Fedora.NEXT, mais aussi de former plus facilement de nouveaux contributeurs dans cette équipe de livraison.

Les nouvelles de la traduction

Pour Fedora 25, les traducteurs se sont chargés de traduire intégralement ibus-typing-booster, qu’on pourrait appeler l’accélérateur de saisie ! Il vise à l’origine à faciliter l’écriture de langues asiatiques, mais peut aussi permettre aux occidentaux, outre l’accélération de la saisie par prédiction, d’accéder à leurs propres symboles : les émoticônes !

Dans la continuité, nous avons également traduit ou finalisé des outils plus anciens ibus, ibus-anthy, ibus-chewing et ibus-libpinyin, permettant la saisie en japonais et chinois.

Évidemment, l’outil Fedora Media Writer, qu’on appellerait l’installateur de médias, est intégralement traduit pour faciliter l’installation. Les sites Internet et tous les outils principaux sont toujours complètement traduits.

L’outil de signalement automatique ABRT et ses dépendances devraient être également complètement traduits pour faciliter la remontée de rapports d’anomalie, ainsi que Storaged pour le partitionnement.

L’équipe de documentation a toujours besoin de bras pour actualiser ses documents et publier nos traductions. Ils refondent leurs outils et chaînes de production, n’hésitez pas à les aider !

Que faire pour aider ?

Dès que vous voyez un logiciel (que vous utilisez) qui est incomplet voire non traduit :

  • remontez jusqu’à son code ;
  • trouvez sa plate‐forme de traduction ;
  • battez‐vous pour obtenir une traduction à 100 % ;
  • relisez trois fois pour un 100 % en qualité ;
  • suivez son cycle de parution pour s’assurer que les nouvelles traductions parviennent jusqu’à votre ordinateur.

La dernière étape peut prendre du temps.

Traduisez également les notes de version de vos logiciels et outils pour faciliter leur compréhension.

Un doute dans la traduction d’un programme ?

Vous pouvez préciser dans quelle langue lancer le programme en surchargeant la valeur de la variable d’environnement LANG.

Par exemple, si votre système est configuré en français, vous pouvez tout de même lancer l’éditeur OpenStreetMap en anglais, en faisant :

LANG="en_US" josm

Organisation de Fedora

L’organisation de la traduction d’une distribution est particulière de par la diversité des sources des contenus fournis à l’utilisateur.

La communauté Fedora :

Des logiciels peuvent être majoritairement utilisés par Fedora, mais être pensés dans une optique plus large, on les retrouvera sur la plate‐forme « publique » de Zanata.
C’est d’ailleurs là qu’on trouvera Zanata ou Publican : https://translate.zanata.org/.

Pour tout le reste, il faut remonter à la source du code pour trouver où traduire. Voici quelques exemples parmi les plus connus :

  • # Coquille

    Posté par . Évalué à 2 (+1/-0).

    "sécurité obsolètes TC4"

    C'est pas plutôt RC4 ??

  • # Wayland

    Posté par (page perso) . Évalué à 10 (+10/-0).

    Il pourrait à terme améliorer les performances, en exploitant pleinement l'accélération
    matérielle par les cartes graphiques.

    Pas à terme, c'est déjà le cas. Sur mon vieux PC au boulot, les transitions GTK étaient lentes comme la mort sous Xorg, avec le passage à Wayland, c'est juste aussi rapide que sur un PC morderne.

    • [^] # Re: Wayland

      Posté par . Évalué à 1 (+0/-0).

      Il faudrait comparer à noyau identique : les progressions sur le noyaux sont constantes et dans mon cas, j'ai vu des changements très importants lorsque je suis passé en backport pour le noyau sur Debian.

  • # wayland une remise à plat de X11 ?

    Posté par (page perso) . Évalué à 3 (+2/-0).

    Wayland consiste en une remise à plat du serveur graphique historique X11

    Je n'ai pas tout suivi, mais wayland me semble plutôt une alternative complète plutôt qu'une remise à plat.

    • [^] # Re: wayland une remise à plat de X11 ?

      Posté par (page perso) . Évalué à 6 (+3/-0).

      C'est une remise à plat dans le sens où cela vient de la réflexion sur comment est utilisé Xorg aujourd'hui et comment refaire le design pour que cela corresponde mieux. Si je ne me trompe pas, c'est même parti du travail fait sur X12.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # KDE

    Posté par . Évalué à 4 (+4/-0).

    Donc si je comprends bien, on peut utiliser KDE mais à ses risques et périls ou on reprend du xorg. Quelqu'un sait quand KDE supportera pleinement wayland ?

  • # Petit retour d'expérience

    Posté par . Évalué à 10 (+12/-0).

    J'ai F25 depuis 1 mois (évidemment via un passage par la version beta).
    Utilisation du bureau Gnome/Wayland.

    Wayland fait perdre quelques fonctionnalités, mais rien d'important. En fonction des besoins, ça peut être irritant. Donc fournir X11 est nécessaire encore et peut-être pour assez longtemps.
    Wayland chez moi est "rocksolid". Avec Xorg j'avais parfois des plantages, aussi des soucis avec gnome-shell quand utilisation de libva (vaapi). L'affichage en 3D de http://flightradar24.com/ dans Firefox faisait parfois planter Xorg. Avec F25 je n'ai eu absolument aucun problème de fiabilité avec Wayland ! Rien, nada. Chapeau bas !
    Je suis convaincu que la grande majorité des utilisateurs de Gnome seront sous Wayland avec F25.
    Avant j'avais F23, mais il restait trop de limitation pour utiliser en permanence Wayland (à l'époque déjà rocksolid).

    Le problème le plus irritant que j'ai avec Wayland est qu'un "su -l" (ou sudo) ne configure pas l'environnement pour utiliser Wayland (il faut utiliser xhost et définir $DISPLAY à la main). C'est bien un bug de l'intégration de Wayland. Je précise qu'il reste des défauts, mais ils sont anecdotiques.

    Pour le reste, ben j'ai rien à dire, tout marche comme prévu, désolé.
    Dans les très nombreuses versions de Fedora que j'ai utilisé (je suis sous Fedora depuis le début de Fedora), c'est celle qui a la meilleure qualité. Après de mémoire ça devait être la version 13 ou 15.

    Le seul moment où j'ai fait un peu de recherche car j'avais un problème était avec mock. Je défini 'base_dir' de mock à /tmp/mock pour gagner en vitesse. Mais sous F25 /tmp est monté avec "nodev". En solution à l'arrache : "mount -o remount,dev /tmp".

    Bref, je suis ravi.
    Ravi également du décollage de Wayland, étape importante. Entre Xorg et Wayland, je prend Wayland car plus fiable.

    • [^] # Re: Petit retour d'expérience

      Posté par . Évalué à 1 (+2/-1).

      Le problème le plus irritant que j'ai avec Wayland est qu'un "su -l" (ou sudo) ne configure pas l'environnement pour utiliser Wayland (il faut utiliser xhost et définir $DISPLAY à la main). C'est bien un bug de l'intégration de Wayland. Je précise qu'il reste des défauts, mais ils sont anecdotiques.

      Tous les développeurs hurlent qu'il ne faut pas utiliser une application graphique en root, mais en pratique cela est t-il possible? Par exemple, les gestionnaires de paquets ont tous besoin des droits root. D'ailleurs, si ouvrir une session graphique en root est effectivement a proscrire, je n'ai jamais compris en quoi cela était si dangereux d'utiliser un logiciel en root!

      Merci à Fedora d'avoir le courage d'utiliser Wayland dès maintenant. Cela va permettre de mettre en évidence de nombreuses imperfections…

      • [^] # Re: Petit retour d'expérience

        Posté par (page perso) . Évalué à 3 (+1/-0).

        Tous les développeurs hurlent qu'il ne faut pas utiliser une application graphique en root, mais en pratique cela est t-il possible? Par exemple, les gestionnaires de paquets ont tous besoin des droits root.

        Disons qu'il y a un juste milieu.
        Certaines applications ont besoin des droits du superutilisateurs, mais pas pour toute l'application en général. Les applications peuvent demander à la volée les droits nécessaires (cas de GNOME Logiciels par exemple).

        De plus, ici cela ne concerne que les applications lancées depuis la ligne de commande. Lancer graphiquement une application qui a besoin d'être root sous Wayland ne pose aucun problème.

        D'ailleurs, si ouvrir une session graphique en root est effectivement a proscrire, je n'ai jamais compris en quoi cela était si dangereux d'utiliser un logiciel en root!

        Car la moindre faille, le moindre problème sur le logiciel et toutes tes données peuvent être corrompues, ou ta machine vérolée à distance, etc. C'est pour cela qu'il faut limiter au maximum ces droits sur nos machines.

        Par ailleurs, Wayland permet aussi de ne pas avoir un logiciel lancé en root en permanence : X11. Et oui, s'en sera fini de ce risque sécuritaire.

        • [^] # Re: Petit retour d'expérience

          Posté par (page perso) . Évalué à 8 (+5/-0).

          Par ailleurs, Wayland permet aussi de ne pas avoir un logiciel lancé en root en permanence : X11. Et oui, s'en sera fini de ce risque sécuritaire

          systemd permet cela aussi de ne plus avoir X en setuid

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Petit retour d'expérience

            Posté par (page perso) . Évalué à 4 (+2/-0).

            Ouais, j’ai utilisé pendant pas mal de temps — jusqu’à que je commence à utiliser SDDM, qui ne sait pas encore le faire — X sans droits root avec xinit et ça marchait parfaitement bien.

            Écrit en Bépo selon l’orthographe de 1990

  • # Comme d'habitude

    Posté par . Évalué à 7 (+5/-0). Dernière modification le 23/11/16 à 20:08.

    Ma machine principale, dite "de gamer", vient de passer sous F25, via une méthode peu recommandée : dnf update. Et comme d'habitude, ça se passe sans aucun soucis… zéro, nibe, nada, que dalle. Malgré la présence, sur cette machine, du blob nvidia (et de steam, et de pas mal de softs compilés localement genre les derniers Octave) Je change les $releasever et 24 par 25 dans yum.repos.d/*, je met à jour. C'est tout. (La seconde machine, le LibreBook, est passé de F23 a F25 direct, même méthode. Elle vient de F18 comme ça.)

    ça fait longtemps qu'il ne faut pas le dire, mais quand même … Fedora c'est vraiment le niveau au dessus. oupss.

    ps : le thème de sddm est vraiment très réussi. bravo.
    ps2 : la mise à jour vers arimo10 est aussi très réussie.

    • [^] # Re: Comme d'habitude

      Posté par (page perso) . Évalué à 5 (+3/-0).

      Y a une raison pour ne pas utiliser dnf system-upgrade qui est fait pour ça ?

      • [^] # Re: Comme d'habitude

        Posté par . Évalué à 3 (+1/-0). Dernière modification le 23/11/16 à 20:37.

        Jamais utilisé, yum & dnf ont tjs permis le passage sans soucis d'une version à l'autre, via un simple "update" après mise à jour à la main des fiches de dépôts. Et ce, y compris pendant le passage à dnf (et également pendant et avec drpm) Un mauvais souvenir de pre-upgrade qui reste, peut être … Bref, update fonctionne :-)

        • [^] # Re: Comme d'habitude

          Posté par (page perso) . Évalué à 10 (+8/-0).

          Attention, cela comporte des risques. dnf system-upgrade fait la mise à niveau hors ligne et gère justement l'adaptation des dépôts et leur éventuelle absence à la bonne version.

          Le gros problème de faire comme tu fais, c'est que tu mets à jour à chaud le système sur la quasi-totalité des composants et souvent dans des versions très différentes (je pense entre autre aux couches basses). Cela peut amener des soucis comme ici lors d'une mise à jour banale qui pouvait conduire à un système corrompu et donc inutilisable.

          Honnêtement, dnf system-upgrade est très fiable et fonctionnel. En fait il fonctionne pratiquement comme un dnf update classique, avec l'avantage de le faire hors ligne donc sans risque sur ta machine et en cas d'échec te permettre d'utiliser la version d'avant sans soucis (ce qui n'est pas le cas avec ta procédure).

      • [^] # Re: Comme d'habitude

        Posté par . Évalué à 0 (+0/-1).

        Normalement tu passes par GNOME Logiciels pour ça

  • # Redshift !

    Posté par . Évalué à 4 (+4/-0).

    Wayland ça à l'air de bien marcher mais des logiciels comme Redshift ne fonctionnent pas dessus. On va rester à l'ancienne !

    • [^] # Re: Redshift !

      Posté par . Évalué à 5 (+3/-0).

      Rien dans le design de Wayland n'empêche a priori un logicel équivalent à redshift de fonctionner. Il faut probablement que ça soit géré au niveau du compositeur cependant.

      • [^] # Re: Redshift !

        Posté par (page perso) . Évalué à 5 (+3/-0).

        Tout à fait.
        Je crois d'ailleurs que GNOME envisage de gérer ça soi même. Mais ce n'est pas encore disponible.

      • [^] # Re: Redshift !

        Posté par . Évalué à 6 (+5/-0). Dernière modification le 24/11/16 à 17:10.

        Ils en parlent sur le Bugzilla de Gnome : https://bugzilla.gnome.org/show_bug.cgi?id=741224
        (edit : grillé !)

      • [^] # Re: Redshift !

        Posté par . Évalué à 3 (+1/-0).

        du compositeur --> DES compositeurS

        Contrairement à X chaque compositeur fait tout le travail donc chacun doit (ré)implémenter les fonctionnalités..

        • [^] # Re: Redshift !

          Posté par (page perso) . Évalué à 3 (+1/-0).

          Je pense qu'il partait du principe que tu n'utilises qu'un compositeur à la fois, et que celui-ci doit l'implémenter. ;-)

          • [^] # Re: Redshift !

            Posté par . Évalué à 5 (+3/-0).

            J'avais compris mais je pense quand même qu'il est important de faire remarquer qu'avec Wayland, pour avoir vraiment l'équivalent de RedShift (qui n'avais besoin je pense que de travailler avec le serveur X quelque soit le DE) il faut que
            1) chaque compositeur implémente la fonctionnalité (je n'ai pas l'impression que libweston soit beaucoup utilisé, je me trompe?)
            2) l'accès a la fonctionnalité soit standardisée (dans le protocole XDG-Shell je pense)

            Chaque DE reproduisant en interne ce genre de fonctionnalité, bonjour la fragmentation..

    • [^] # Redshift disponible sous Wayland !

      Posté par (page perso) . Évalué à 3 (+2/-0).

      Ça y est, c’est dès à présent possible d’avoir Redshift avec Wayland !

  • # Wayland d'abord sur Arch

    Posté par (page perso) . Évalué à 3 (+2/-0).

    J'ai installé une ArchLinux il y a quelques semaines et Gnome était déjà par défaut sous Wayland.
    Sinon, j'ai des problèmes avec le screenshoteur de Gimp, qui génère des carrés tout noirs. Il faut en passer par l'outil gnome-screenshot pour que ça marche. J'attends Gimp 3, ça marchera peut-être mieux, on verra bien.

    • [^] # Re: Wayland d'abord sur Arch

      Posté par (page perso) . Évalué à 7 (+5/-0).

      J'ai installé une ArchLinux il y a quelques semaines et Gnome était déjà par défaut sous Wayland.

      Mouais, je dirais que Gentoo et Archlinux ne comptent pas vraiment pour ce genre de considérations. Ce ne sont pas des systèmes livrés clés en main. Les choix opérés par Archlinux par défaut (sauf pour les briques de base tels que le noyau ou systemd) ont peu d'impact finalement sur l'utilisateur car il devra de toute façon choisir beaucoup de chose par lui même. Entre demander l'installation de GNOME pour X11 ou pour Wayland, pour un utilisateur Archlinux, c'est plus ou moins pareil.

      Fedora a des choix par défaut très impactant, car le système peut (et même doit) être pleinement utilisable avec ces choix par défaut sans personnalisation ou choix de paquets par l'utilisateur.

      Sinon, j'ai des problèmes avec le screenshoteur de Gimp, qui génère des carrés tout noirs. Il faut en passer par l'outil gnome-screenshot pour que ça marche. J'attends Gimp 3, ça marchera peut-être mieux, on verra bien.

      Cela a peu de chances de fonctionner.
      Wayland apporte un nouveau concept de sécurité : les applications ne doivent pas voir ou modifier le contenu affiché par les autres fenêtres. Chose qui était pleinement autorisée avec X11. Du coup cela pose soucis pour les applications telles que la capture d'écran, Redshift ou encore les économiseurs d'écran. Cela doit être géré par le compositeur de fenêtre (qui a le contrôle de l'ensemble) et donc de ton environnement graphique.

      Cela signifie que pour le moment, seules les applications GNOME peuvent faire ces tâches.
      Bien entendu, dans le futur ce sera étendu, probablement via les Flatpak qui permettront à l'utilisateur d'autoriser ou non ce type d'actions.

    • [^] # Re: Wayland d'abord sur Arch

      Posté par (page perso) . Évalué à 7 (+5/-0).

      Wayland n'autorise pas un programme à "voir" les autres programmes. La "vision" étant aussi bien les caractères tapés dans d'autres programmes (protégeant notamment des keyloggers), que le contenu des fenêtres… Ce sont des questions de sécurité.

      Donc c'est effectivement normal que le screenshot de GIMP ne marche plus. Un code de capture d'écran écrit pour marcher sous X11 ne fonctionnera tout simplement jamais sous Wayland, non seulement pour les raisons de sécurité évoquées (il faut un client avec des privilèges particuliers), mais aussi parce que les logiciels de capture s'interfacent directement avec le serveur X sans comportement réellement standardisé.
      GIMP 3 n'y changera rien. Ce qui changera sera si on décide de coder la capture spécifiquement pour Wayland (je n'ai aucune idée de ce que cela implique. Y a encore quelques mois (moins d'un an), ce n'était même pas possible techniquement, tout court).

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

      • [^] # Re: Wayland d'abord sur Arch

        Posté par . Évalué à -6 (+0/-8).

        Wayland n'autorise pas un programme à "voir" les autres programmes. La "vision" étant aussi bien les caractères tapés dans d'autres programmes (protégeant notamment des keyloggers), que le contenu des fenêtres… Ce sont des questions de sécurité.

        Ce qui veut dire que le clic milieu pour copier/colle ne fonctionne plus?

        Le truc c'est que j'ai l'impression que Wayland c'est le reve des compagnies qui adorent les DRM. Sous le couvert de la "securite" on nous refourgue un truc qui casse pas mal de chose tout de meme. Enfin de tout de facon comme beaucoup de chose nous n'avons pas le choix :(

        • [^] # Re: Wayland d'abord sur Arch

          Posté par (page perso) . Évalué à 4 (+2/-0).

          Le click milieu fonctionne très bien, c'est géré par mutter.

          • [^] # Re: Wayland d'abord sur Arch

            Posté par . Évalué à -2 (+2/-6).

            Le click milieu fonctionne très bien, c'est géré par mutter.

            Et moi qui avait appris que le partage de code c'etait mieux y compris (surtout) pour limiter les bugs et ameliorer la securite…

            • [^] # Re: Wayland d'abord sur Arch

              Posté par . Évalué à 1 (+0/-1).

              Je ne suis pas fan non plus du design de Wayland (j'aurais préféré un "X12") mais bon n'oublie quand même pas qu'on parle d'un remplacement d'X11 qui coté sécurité est totalement nul donc ça reste une grosse amélioration pour la sécurité.

              Après, toute cette duplication de code c'est vrai que ça pique..

            • [^] # Re: Wayland d'abord sur Arch

              Posté par . Évalué à 2 (+2/-0).

              Je vois pas tellement de problème pour la duplication de code: il suffit de faire une lib.

              Certes, ce ne sera pas dans Wayland, mais je ne voit pas ça comme un problème: la fonctionnalité copié-collé par click du milieu n'a rien à voir avec le serveur graphique, et un environnement de bureau pourrait très bien décider que cette fonctionnalité n'apporte rien et ne pas l'implémenter.

              Le seul problème semble être que le code pour gérer ça n'est pas encore là / pas encore intégré dans tous les DE. Et là, bah c'est comme tout: ça viendra mais ça prends du temps.

              • [^] # Re: Wayland d'abord sur Arch

                Posté par . Évalué à 1 (+1/-2).

                • C'est la meme chose pour faire un screenshot du bureau.
                • C'est la meme chose pour pouvoir avoir des decorations de fenetres coherentes
                • C'est la meme chose pour le remote desktop

                Chaque bureau doit re-implementer.

            • [^] # Re: Wayland d'abord sur Arch

              Posté par (page perso) . Évalué à 3 (+1/-0).

              https://github.com/wayland-project/weston

              C'est un choix de l'équipe de mutter de ne pas utiliser libweston.

    • [^] # Re: Wayland d'abord sur Arch

      Posté par (page perso) . Évalué à 6 (+4/-0).

      le screenshoteur de Gimp, qui génère des carrés tout noirs

      En complément des réponses déjà faites, le dernier billet de Martin Graesslin explique un peu plus techniquement la difficulté.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • # Retour d’expérience version bêta et Wayland !

    Posté par (page perso) . Évalué à 3 (+2/-0).

    Bêta

    C’est la première fois que je fais la bêta depuis que j’utilise Fedora en version 21.
    Cette bêta c’est s’est bien passée et était tout bonnement fonctionnelle.
    Il faut s’attendre a pas mal de mises à jour.

    Wayland

    Concernant Wayland, voici les bugs et manques que j’ai rencontrés :

    • RedShift plus fonctionnel (énoncé plus haut dans les commentaires).
    • GNOME Terminal est devenu inutilisable qui utilise une grosse quantité de CPU. (Il me semble que ce problème est apparu dans la bêta).
    • un mauvais affichage du contour de GNOME Vidéos lors du passage en plein écran.
    • Xonotic s’est retrouvé avec une sensibilité immense, donc injouable.

    Durant cette bêta les bugs qui ont été corrigés : Xonotic et GNOME Vidéos.

    Donc, au final, je suis toujours sous X.org.
    Mais, dès que GNOME Terminal redeviens fonctionnel, je devrais passer et rester sous Wayland.

  • # Fedora LXDE Spin

    Posté par . Évalué à 2 (+1/-0). Dernière modification le 25/11/16 à 12:48.

    Salut,

    Petit retour d'expérience sur Fedora.

    Il y a quelques semaines, j'ai installé Fedora 24 spin LXDE sur mon vieux mais toujours vaillant EEPC 1201n.
    J'ai donc migré sur Fedora 25 hier.

    Hé bien, tout s'est bien passé.
    La documentation est très détaillée et a très bien marché pour moi, pour un processus de migration par forcément trivial (contrairement à Ubuntu où il ne faut lancer qu'une commande).

    Bref, j'en ai également profité pour install un driver nvidia (340), car je voulais la gestion du VDPAU.
    Tout s'est bien passé. Même remarque qu'au-dessus, la documentation est excellente alors que la version des driver que j'ai installé n'est pas compatible avec Xorg 1.9. Tout était très bien expliqué pour downgrader la version et continuer l'install.

    Bref, que du bonheur de retrouver cette distib' que j'avais abandonné il y a plusieurs années (Bugs, matériel pas compatible, etc.)

    Voili voilou !

    • [^] # Re: Fedora LXDE Spin

      Posté par (page perso) . Évalué à 2 (+1/-1).

      La documentation est très détaillée et a très bien marché pour moi, pour un processus de migration par forcément trivial (contrairement à Ubuntu où il ne faut lancer qu'une commande).

      Qu'elle documentation ? Histoire qu'on la simplifie si tu trouve ça non trivial.
      Normalement cela consiste en deux voire trois commandes assez claires (un pour installer le greffon dnf qui va bien, une autre pour télécharger les paquets et une dernière pour redémarrer).

    • [^] # Re: Fedora LXDE Spin

      Posté par (page perso) . Évalué à 5 (+4/-0).

      Heu, non trivial ?

      Capture de l'écran de mise à jour

      Je trouve ça plutôt simple moi… j'ai cliqué sur un bouton…

  • # Abandon de Fedora 24 après un an d'utilisation

    Posté par . Évalué à 2 (+1/-0).

    J'étais plutôt enthousiaste, sauf au début où un méchant bug corrompait le contrôleur ethernet de mon asus X751, portable qui, pourtant, fonctionnait normalement sur Debian Sid. J'étais obligé d'éteindre complètement le portable pour retrouver le réseau. Le problème fut résolu en désinstallant network-manager et en paramétrant le réseau à la main. Ensuite, ça allait plutôt bien jusqu'à cet automne où ce fut vraiment la cata. Après une mise à jour du noyau (le 4.7), plus du tout de clavier, (même avec win$ en dual boot gardé pour la garantie) sauf avec le bios. Que faire? J'ai démonté le portable (au revoir la garantie), débranché puis rebranché la batterie plusieurs fois, idem pour le clavier mais rien à faire, plus de clavier ni de touchpad au boot. Je branche un clavier usb et à tout hasard, je décide d'installer Debian. Miracle, le portable refonctionne normalement. Il s'avère qu'avec Fedora, c'est un peu la valse des noyaux, des noyaux pas vraiment éprouvés puisque l'un d'entre eux a mis hors service mon clavier. Jamais vu cela en 16 années de Linux.

    • [^] # Re: Abandon de Fedora 24 après un an d'utilisation

      Posté par . Évalué à 2 (+2/-0).

      Fedora est aussi un laboratoire à la base, donc il est mis à jours très souvent.

      Dirige toi vers une autre distribution à long support du style de CENTOS si tu veux rester sur une base Fedora.

      Pense à rapporter les bogues ça aide toujours.

      • [^] # Re: Abandon de Fedora 24 après un an d'utilisation

        Posté par . Évalué à 2 (+1/-0).

        Fedora est aussi un laboratoire à la base, donc il est mis à jours très souvent.

        Venant de Sid, j'étais devenu un utilisateur Fedora en connaissant les risques mais j'étais loin d'imaginer qu'une distribution présentée comme relativement "stable" pouvait casser le matériel. Ce qui est dommage, c'est la rotation trop rapide des noyaux.

        Dirige toi vers une autre distribution à long support du style de CENTOS

        Ce n'est pas mon genre, je m'ennuierais trop! J'ai utilisé Debian, dont Sid et testing pendant 15 ans, je suis retourné à Debian testing/sid qui d'ailleurs se bonifie.

    • [^] # Re: Abandon de Fedora 24 après un an d'utilisation

      Posté par . Évalué à 5 (+2/-0).

      Si j'ai bien compris:
      1.Nouveau noyau Fedora:
      -le clavier ne marche plus sous Fedora
      -le clavier ne marche plus sous win
      2.Démonte du portable:
      -bidouille batterie
      -bidouille câble clavier
      3.Boot
      -clavier et touchpad non fonctionnels
      4.Branche un clavier USB
      L'histoire ne dit pas si à ce moment tu réessaies Fedora et Win
      5.Installe Debian/Sid
      -tout remarche

      J'ai due mal à imaginer comment un pilote peut casser un clavier et un autre le réparer.
      Je pense que le fautif est le BIOS, possiblement déclenché par un élément du nouveau noyau Fedora, mais je doute que les specs d'un BIOS incluent "si l'OS envoie le mauvais code, des trucs peuvent s'arrêter sans prévenir!". Ça devrait être plus robuste que ça.
      Toujours est-il que brancher le clavier USB aura remis les choses en place.

      • [^] # Re: Abandon de Fedora 24 après un an d'utilisation

        Posté par . Évalué à 1 (+0/-0).

        L'histoire ne dit pas si à ce moment tu réessaies Fedora et Win

        Désolé pour cet oubli. Bien entendu, après avoir débranché/rebranché batterie et clavier, j'ai tenté maint fois de booter Fedora, sans succès. L'affaire a duré une semaine… :((

        Je pense que le fautif est le BIOS

        Non puisque le clavier du portable fonctionnait normalement avec le bios.

        Toujours est-il que brancher le clavier USB aura remis les choses en place.

        Non puisque c'est ce que j'ai fait et ça ne rétablissait pas le clavier du portable quand je débranchais le clavier USB. Logique puisque c'était le contrôleur du clavier/touchpad du portable qui était affecté, et non le/les contrôleur(s) usb.

        J'ai due mal à imaginer comment un pilote peut casser un clavier et un autre le réparer.

        Il faut croire que le pilote du noyau fedora boguait le contrôleur clavier tandis que celui du noyau debian ne l'a pas "réparé" mais a "travaillé" normalement avec lui. Mystère…

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.