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.
Sommaire
- Présentation
- Environnement bureautique
- Administration système
- Développement
- Internationalisation
- Du côté du Projet Fedora
- Les nouvelles de la traduction
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
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.
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 !
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.
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.
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.
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…
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.
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.
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.
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.
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.
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" josmOrganisation 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 :
- utilise majoritairement Zanata comme plate‐forme de traduction de ses productions internes ;
- on y trouve, par exemple, les sites Web ;
- les outils majeurs, tels que l’installateur ou le gestionnaire de paquets DNF.
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 :
Aller plus loin
- Site de la communauté francophone de Fedora (1986 clics)
- Site officiel du projet Fedora (722 clics)
- Téléchargez Fedora 25 (torrents officiels) (800 clics)
- Les variantes officielles des autres bureaux graphiques de Fedora (322 clics)
- Les variantes officielles des suites de productivité de Fedora (183 clics)
- Notes de version (168 clics)
- Dépêche sur la version précédente (149 clics)
- Annonce sur Fedora Magazine (150 clics)
# Coquille
Posté par cbri . Évalué à 2.
"sécurité obsolètes TC4"
C'est pas plutôt RC4 ??
[^] # Re: Coquille
Posté par Renault (site web personnel) . Évalué à 3.
Si tout à fait, merci de l'avoir vu.
Si un modo pouvait le corriger. :)
[^] # Re: Coquille
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigé, merci.
# Wayland
Posté par gnumdk (site web personnel) . Évalué à 10.
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 Mikis . Évalué à 1.
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.
[^] # Re: Wayland
Posté par gnumdk (site web personnel) . Évalué à 6.
Ben je compare à noyau identique vu que le changement de session se fait dans GDM…
[^] # Re: Wayland
Posté par pseudovalide . Évalué à 2.
j'ai rien contre les tics de langage , mais ce 'juste' alors….pfff…Dans votre cas, il veut dire quoi ?
c'est à peine aussi rapide que sur un PC moderne.
c'est aussi rapide que sur un PC moderne.
Mais c'est la mode d'introduire des faux-amis anglo-saxons et de les tenir pour de vrais alliés…
# wayland une remise à plat de X11 ?
Posté par Xavier Combelle (site web personnel) . Évalué à 3.
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 claudex . Évalué à 7.
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 SagaGemini . Évalué à 4.
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 ?
[^] # Re: KDE
Posté par Renault (site web personnel) . Évalué à 8.
Par défaut KDE utilise X.org. Seul GNOME a Wayland par défaut, les autres environnements n'étant pas prêts.
Pour la dispo avec KDE, personne ne le sait, mais le meilleur moyen d'aider est de tester et de dire ce qui ne va pas. ;)
[^] # Re: KDE
Posté par SagaGemini . Évalué à 1.
Pas faux !
[^] # Re: KDE
Posté par gnumdk (site web personnel) . Évalué à 3.
Le passage de Xorg à Wayland se fait dans GDM (session wayland ou X11) donc Xorg est toujours là ;)
[^] # Re: KDE
Posté par saltimbanque (site web personnel) . Évalué à 4.
il me semblait que gdm était sous wayland depuis un bail?
https://fedoramagazine.org/login-screen-in-fedora-22-workstation-uses-wayland/
[^] # Re: KDE
Posté par Renault (site web personnel) . Évalué à 3.
Oui, bien sûr, mais ce n'était pas le sens de son propos.
Si tu relis bien, il dit que dans GDM on peut toujours choisir de lancer GNOME avec X11.
[^] # Re: KDE
Posté par Shuba . Évalué à 10.
Ils travaillent fortement dessus, tu peux lire le blog de Martin Graesslin si tu veux te tenir à jour.
[^] # Re: KDE
Posté par SagaGemini . Évalué à 3.
Merci !
[^] # Re: KDE
Posté par ʭ ☯ . Évalué à 2.
KDEPlasma supporte pleinement Wayland, au sens où tu peux travailler avec Wayland. Par exemple avec la future Mageia 6, j'ouvre des sessions au choix avec X11 ou Wayland.Par contre, il reste de bugs très gênants, ou des fonctionalités non encore portées.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: KDE
Posté par Albert_ . Évalué à 1.
Donc ca marche pas. Point.
[^] # Re: KDE
Posté par ʭ ☯ . Évalué à 2.
Je t'invite à lire les retour d'expérience ci-dessous sur Gnome/Wayland. Il en est à peu près de même.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: KDE
Posté par ff9097 . Évalué à 1.
Non Wayland sur Gnome est très LARGEMENT utilisable au quotidien.
[^] # Re: KDE
Posté par Albert_ . Évalué à 3.
Malheureusement j'ai essaye les deux et etant utilisateur de KDE ca me fait bien chier de le dire mais Wayland Gnome fonctionne quand celui de plasma est inutilisable. Le premier bug de visible ce sont les polices qui sont enormes pour certains elements de plasma mais pas pour tous (ou elles sont normales).
# Petit retour d'expérience
Posté par Pseudo007 . Évalué à 10.
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 maxmasou . Évalué à 2.
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 Renault (site web personnel) . Évalué à 4.
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.
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 claudex . Évalué à 9.
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 ariasuni . Évalué à 4.
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
[^] # Re: Petit retour d'expérience
Posté par swilmet . Évalué à 3.
Je veux pas faire le rabat-joie, mais quand gnome-shell plante sous Wayland, toutes les applications plantent avec (si un contenu n'était pas sauvegardé, les données sont perdues) :
https://fedoraproject.org/wiki/Wayland_features#Restarting_gnome-shell
Alors qu'avec X11, gnome-shell est redémarré automatiquement par la session (gnome-shell n'est qu'un client parmi d'autres du serveur X). Sous X11, c'est quand le serveur X plante que toutes les applications plantent avec. Mais le serveur X plante beaucoup plus rarement, c'est un code beaucoup plus ancien et éprouvé.
Quelques raisons qui ne me laissent pas en confiance sous Wayland : une grosse partie du code de gnome-shell est écrit en JavaScript. C'est une architecture monolithique (beaucoup moins modulaire que Xfce, par exemple). Et il y a un an ou deux d'ici, j'avais assez souvent des crash de gnome-shell (sous X11), et je pense qu'on pouvait voir sur le Retrace Server que ça arrivait à pas mal de monde.
Ces dernières années les développeurs de gnome-shell ont fait pas mal d'efforts pour stabiliser le code, mais des plantages, il y en aura encore. Et quand ça arrivera à quelqu'un, il perdra ses dernières modifications.
[^] # Re: Petit retour d'expérience
Posté par Renault (site web personnel) . Évalué à 5.
Ce n'est pas forcément spécifique à Wayland.
Le fait que Gnome-Shell souhaite corriger cette régression montre que cela semble possible, il faut juste changer l'architecture de mutter vis à vis de Wayland.
Ne confonds pas Wayland avec son implémentation dans Gnome-Shell.
Il n'y a aucun rapport entre Wayland et le JavaScript. Tu confonds encore l'implémentation de Wayland dans Gnome-Shell et Wayland lui même.
Sans compter que je ne vois pas le rapport entre JavaScript et la qualité d'un projet (de beaux projets robustes peuvent être faits en JS et de la merde en boîte avec n'importe quel autre langage au monde).
Tu veux qu'on reparle de tous les défauts de X11 aussi pour te convaincre que Wayland même si pour le moment n'offre pas tout, reste un choix pertinent aujourd'hui ?
[^] # Re: Petit retour d'expérience
Posté par swilmet . Évalué à 1.
Je parlais bien de GNOME/Wayland, pas de Wayland en général.
Comme expliqué dans ce commentaire, c'est possible de changer l'architecture de gnome-shell/mutter pour régler ce problème, mais ça demanderait énormément d'efforts.
# Comme d'habitude
Posté par bubar🦥 (site web personnel) . Évalué à 7. Dernière modification le 23 novembre 2016 à 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 Sufflope (site web personnel) . Évalué à 6.
Y a une raison pour ne pas utiliser dnf system-upgrade qui est fait pour ça ?
[^] # Re: Comme d'habitude
Posté par bubar🦥 (site web personnel) . Évalué à 3. Dernière modification le 23 novembre 2016 à 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 Renault (site web personnel) . Évalué à 10.
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 ff9097 . Évalué à 0.
Normalement tu passes par GNOME Logiciels pour ça
# Redshift !
Posté par zephyr32 . Évalué à 4.
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 Shuba . Évalué à 6.
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 Renault (site web personnel) . Évalué à 6.
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 Letho . Évalué à 7. Dernière modification le 24 novembre 2016 à 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 reno . Évalué à 4.
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 Renault (site web personnel) . Évalué à 4.
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 reno . Évalué à 5.
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..
[^] # Re: Redshift !
Posté par swilmet . Évalué à 1.
Rien n'empêche d'écrire une bibliothèque pour avoir du code en commun.
[^] # Re: Redshift !
Posté par reno . Évalué à 3.
Oui, c'est(c'était?) le but de libweston dont je parle, mais pour autant que je sache ça n'est pas utilisé (ni par GNOME, ni par KDE).
Entre "rien n'empêche" et que dans les faits ça soit le cas..
[^] # Re: Redshift !
Posté par swilmet . Évalué à 1.
En tout cas pour l'input, il y a libinput. Il y a peut-être d'autres exemples.
[^] # Redshift disponible sous Wayland !
Posté par M5oul (site web personnel) . Évalué à 4.
Ça y est, c’est dès à présent possible d’avoir Redshift avec Wayland !
[^] # Re: Redshift disponible sous Wayland !
Posté par reno . Évalué à 5.
Pas avec Wayland: avec GNOME Wayland!
C'est une extension de GNOME au dessus de Wayland: si tu essaye d'utiliser ça sur un DE qui utilise un autre compositeur Wayland (KDE par exemple) ça ne marchera pas.
# Wayland d'abord sur Arch
Posté par Zorro (site web personnel) . Évalué à 3.
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 Renault (site web personnel) . Évalué à 7.
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.
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 saltimbanque (site web personnel) . Évalué à 2.
oui & non. Pas dix mille choix. en fait à part configurer initfamfs pour gérer lvm & installer gnome, je ne me souviens pas d'avoir choisi grand chose
[^] # Re: Wayland d'abord sur Arch
Posté par Jehan (site web personnel, Mastodon) . Évalué à 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é.
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 Albert_ . Évalué à -7.
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 gnumdk (site web personnel) . Évalué à 5.
Le click milieu fonctionne très bien, c'est géré par mutter.
[^] # Re: Wayland d'abord sur Arch
Posté par Albert_ . Évalué à -1.
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 reno . Évalué à 3.
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 BAKfr . Évalué à 3.
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 Albert_ . Évalué à 2.
Chaque bureau doit re-implementer.
[^] # Re: Wayland d'abord sur Arch
Posté par gnumdk (site web personnel) . Évalué à 5.
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 ZeroHeure (site web personnel) . Évalué à 6.
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
[^] # Re: Wayland d'abord sur Arch
Posté par David Demelier (site web personnel) . Évalué à 1.
Personnellement j'ai un souci de focus, quand j'ai Firefox et Qt Creator ouverts, faire alt+tab pour passer de Firefox à Qt Creator me perd le focus de la zone d'édition. C'est très pénible.
Donc malheureusement, toujours xorg pour le moment :(
git is great because linus did it, mercurial is better because he didn't
# Retour d’expérience version bêta et Wayland !
Posté par M5oul (site web personnel) . Évalué à 3.
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 :
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.
[^] # Re: Retour d’expérience version bêta et Wayland !
Posté par Renault (site web personnel) . Évalué à 3.
C'est bizarre, je n'ai pas ce soucis chez moi.
Tu as un profil très personnalisé ?
[^] # Problème GNOME Terminal sous Wayland
Posté par M5oul (site web personnel) . Évalué à 1.
Pas tellement. J’ai uniquement configuré des raccourcis clavier.
Je travaille tout le temps avec plusieurs onglets d’ouverts (trois à sept) et le client console ncurses Poezio d’ouvert.
GNOME Terminal est très lent à l’usage, le redimensionnement de la fenêtre est horriblement lent.
C’est le processus
gnome-terminal serverqui utilise beaucoup de charge processeur.[^] # Problème d’affichage de LibreOffice avec Wayland, HiDPI?
Posté par M5oul (site web personnel) . Évalué à 3.
Ah, j’ai trouvé un autre problème :D
C’est LibreOffice qui s’affiche mal et qui deviens inutilisable.
C’est peut-être lié à la résolution HiDPI de mon écran.
[^] # Re: Problème d’affichage de LibreOffice avec Wayland, HiDPI?
Posté par Laurent Mouillart . Évalué à 3.
C'est semble-t-il corrigé dans la révision 10 du paquet de LibreOffice :
https://bodhi.fedoraproject.org/updates/FEDORA-2016-cdfdbdcf02
Le paquet sera déployé dans plusieurs jours, sinon il est possible de le récupérer via koji.
[^] # Redimensionnement d’application GTK+ avec écran HiDPI
Posté par M5oul (site web personnel) . Évalué à 2.
Le problème de redimensionnement d’applications GTK+ avec écran HiDPI a été identifié.
[^] # Bugs corrigés sous Wayland !
Posté par M5oul (site web personnel) . Évalué à 2.
Allé hop !
Tous les bugs sus-cités ont été corrigés dans la grosse mise à jour qui viens de paraître avec les logiciels de GNOME/GTK+ qui sont passés en versions 3.22.2, ainsi qu’avec LibreOffice build-10.
Je tourne à présent sous Wayland qui fonctionne finalement bien mieux !
# Fedora LXDE Spin
Posté par yeahman . Évalué à 3. Dernière modification le 25 novembre 2016 à 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 Renault (site web personnel) . Évalué à 3.
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 ff9097 . Évalué à 2.
Gnome Logiciels est la façon officielle de mettre à jour désormais
[^] # Re: Fedora LXDE Spin
Posté par yeahman . Évalué à 2.
Oui oui, c'est pas compliqué à suivre pour un mec un peu technique ou avec des connaissances basiques mais pour M. Toutlemonde c'est pas juste un écran avec un bouton à appuyer… sur le spin en tous cas.
https://fedoraproject.org/wiki/DNF_system_upgrade
[^] # Re: Fedora LXDE Spin
Posté par Renault (site web personnel) . Évalué à 3.
Pour ces gens là, il y a la mise à niveau par GNOME Logiciels, et comme dit plus haut, il suffit d'un clic. ;-)
En plus c'est suggéré par une pop-up quand c'est disponible, pas besoin de savoir qu'une version est sortie pour la mettre à niveau.
[^] # Re: Fedora LXDE Spin
Posté par Patrice FERLET (site web personnel) . Évalué à 3.
Heu, non trivial ?
Je trouve ça plutôt simple moi… j'ai cliqué sur un bouton…
[^] # Re: Fedora LXDE Spin
Posté par yeahman . Évalué à 2.
L'écran que tu montres n'est pas sur le spin LXDE ;)
# Abandon de Fedora 24 après un an d'utilisation
Posté par Maderios . Évalué à 4.
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 VINDICATORs . Évalué à 4.
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 Maderios . Évalué à 4.
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.
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 gnumdk (site web personnel) . Évalué à 6.
Sinon, y'a ArchLinux avec le noyau LTS, t'es plutôt peinard ;)
[^] # Re: Abandon de Fedora 24 après un an d'utilisation
Posté par saltimbanque (site web personnel) . Évalué à 4.
Oui sous Fedora plein de choses pêtent tout le temps =)
autant la distrib est super importante et agréable en temps qu'elle devance tout ; autant ça se paie & je passe partiellement sous Arch pour la même raison. & pareil je viens de sid, que j'avais quitté pour avoir des versions plus récentes des softs mais bon… peut être qu'un jour debian stable + flatpack récents sera la magie.
[^] # Re: Abandon de Fedora 24 après un an d'utilisation
Posté par Maclag . Évalué à 5.
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 Maderios . Évalué à 2.
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… :((
Non puisque le clavier du portable fonctionnait normalement avec le bios.
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.
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…
[^] # Re: Abandon de Fedora 24 après un an d'utilisation
Posté par urschuca . Évalué à 2.
J'ai eu deux cas de régression de fonctionnalités avec mon portable sous fedora24 (un HP probook 640). A chaque fois un reboot en choisissant l'avant dernier noyau installé à "corriger" le soucis, ces soucis ce sont régler d'eux mêmes avec une mises à jour :
Cas 1: impossible de faire fonctionner la carte wifi
Cas 2: impossible d'utiliser le port VGA externe
C'est la seule distribution qui m'a fait le coup et ça fait quand même peur d'avoir de tels dysfonctionnement suite à un simple "yum update".
[^] # Re: Abandon de Fedora 24 après un an d'utilisation
Posté par Maderios . Évalué à 1.
Dans mon cas, aucun noyau ne fonctionnait. Récemment, un noyau Debian testing m'a fait le même coup (perte du clavier). J'ai installé un noyau Sid de version supérieure et le problème a disparu.
[^] # Re: Abandon de Fedora 24 après un an d'utilisation
Posté par David Demelier (site web personnel) . Évalué à 2. Dernière modification le 08 décembre 2016 à 14:52.
Tu ne perds pas la garantie en ouvrant un portable. Heureusement sinon on ne pourrait même pas changer un disque dur et nettoyer les ventilateur.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Abandon de Fedora 24 après un an d'utilisation
Posté par Maderios . Évalué à 1.
A. Exclusions du service de Garantie Limitée
le produit a été examiné, démonté, réparé et/ou modifié par du personnel non autorisé ;
https://www.asus.com/fr/support/article/590/
[^] # Re: Abandon de Fedora 24 après un an d'utilisation
Posté par Sufflope (site web personnel) . Évalué à 3.
https://fr.wikipedia.org/wiki/Clause_l%C3%A9onine
[^] # Re: Abandon de Fedora 24 après un an d'utilisation
Posté par David Demelier (site web personnel) . Évalué à 1.
Mauvaise marque, changer marque.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Abandon de Fedora 24 après un an d'utilisation
Posté par EauFroide . Évalué à 1. Dernière modification le 12 décembre 2016 à 15:01.
Boaf il faut les comprendre: si tu ouvre ta machine qu'est-ce qui prouve que tu n'es pas l'auteur des dommages? *1
Note que même après avoir ouvert mes pc je n'ai jamais eu de soucis de garantie (pourtant j'ai eu aussi le coups des visses dont les filets sont peint en bleu pour voir si je l'ai déjà ouvert, par contre quand j'ai un problème je suis capable de mentionner assez de détails pour que le personnel du SAV ne marque pas "noob qui a ouvert sa machine et tout cassé").
Enfaîte la seule fois ou une garantie m'a pris la tête c'est pour une pièce détachée dont le revendeur, après avoir cherché avec une loupe, m'accusait de l'avoir endommagé (et le matos a quand même été remplacé à leur frais car le fabricant a dépassé le délais accordé par la lois pour démontrer que le(s) dommage(s) étaient de ma faute)
*1 sachant que les machines sont conçue afin d'augmenter les risques de casse si tu les ouvres, genre des clips en plastique pas fait pour être déclipsé à un endroit où, il y a dix ans, on plaçait des visses en acier. (c'est super visible dans les XBox)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Abandon de Fedora 24 après un an d'utilisation
Posté par Romeo . Évalué à 3.
Le bleu sur les vis c'est du freinfilet, ça permet d'éviter que les vis se dévissent avec les vibrations.
# installation et test par un utilisateur de debian
Posté par yoyz . Évalué à 4.
Je viens de tester cette distribution fedora 25 donc je fais un retour, ça fait 4h que je l'utilise, donc c'est tout frais.
J'ai utilisé fedora la dernière fois pendant 6 mois il y a près de 15 ans, je n'avais pas aimé à l'époque, mais c'est vieux, les choses évoluent.
Donc après 15 ans j'etais toujours un peu réticent sur cette distrib.
Je suis un gros utilisateur de debian et rhel par mon background donc, les yum, rpm, dpkg et autres ça ne m'effrai pas.
J'ai une utilisation desktop sommaire : fluxbox, emacs/vim, terminator, ssh, screen, chrome, mplayer.
Et bien pour faire court je suis agréablement surpris par ce que j'utilise à l'instant, c'est une distrib desktop réussi sans chichi.
Ca s'installe très facilement, ça je m'en doutais et je n'en attendais pas moins, j'ai installé une clef usb à partir d'un poste windows, c'etait fonctionnel et facile, j'ai tout de même noté deux choses pas génial pour l'installeur :
- un fsck.extX qui tournais en tache de fond sur mon laptop et figé l'affichage de l'installeur, sur la première page, ça c'est pas top ;
- le choix de partitionnement du disque n'est pas si intuitif, non vraiment pas, pourtant il y a un effort sur le graphique, mais je ne le trouve pas terrible, en même temps, je suis plus mode texte qu'interface graphique, en général c'est peut être ça au fond, c'est moi le soucis ;
Puis, le pc s'est installé et a redémaré.
Le grub2 est la, le windows 7 est toujours la, bon tout me semble ok.
Et la miracle, tout marche au démarage sans fichier à bricolé, j'ai un wayland/X fonctionnel, l'acceleration 3d, le suspend to ram, le wifi qui passe, le son, le ventilo qui ne souffle pas, un youtube fluide sous firefox, une utilisation du cpu et de la ram convenable, pas de process qui me mettent le pauve laptop à genoux.
Je regarde si mes mp3, mes films et la couche samba pour acceder à mon nas est fonctionnel.
Et, c'est bon pour samba, mais pas top pour les mp3 et films, il faut installer des paquets.
En dix minutes d'internet, tout est réglé et en plus toute l'aide est sur le site de fedora, avec des repo préconnisé par le fournisseur de la distrib en plus. Pas de sombre site à ajouter au système de package ou à se compiler à la main.
J'installe des paquets en graphique, bof, j'y comprend rien, je passe en ligne de commande, la ça roule tout seul, screen, emacs, vim, gcc-c++, make, sdl, git tout roule tout seul.
Je compile quelques applis, rien à redire, ça passe, les headers sont dispo, il y a même quelques ".a" pas trop, mais il y en a, le nom des paquets n'est pas funky, je retrouve la rhel.
Plutot agréablement surpris d'être sur une distrib qui offre la même qualité de finition que la debian mais qui fait tourné mon desktop bien mieux que ma debian. Ce qui n'etait pas toujours le plus évident il faut le dire pour ma debian unstable ( très très stable mais qui n'est pas desktop dans l'ame ).
Donc au final, je la trouve bien cette fedora 25, et je suis satisfait d'y avoir passé quelques heures, au revoir fluxbox, on se retrouvera dans quelques mois/année et bienvenu gnome-shell.
[^] # Re: installation et test par un utilisateur de debian
Posté par Renault (site web personnel) . Évalué à 3.
Une autre interface sera disponible dans Anaconda à partir de Fedora 26 : blivet-gui (que tu peux installer sur ta Fedora actuelle si tu veux un visuel) qui sera plus proche de GParted et consort en terme d'organisation.
L'interface actuelle ne sera pas supprimée pour autant, le but est de satisfaire différents besoins des utilisateurs. Ces interfaces n'auront donc pas le même public et blivet est plus proche des outils traditionnels par son approche.
Si tu as utilisé GNOME Logiciels, il n'est pas adapté pour installer des environnements de développement. Il ne propose que des applications finies et qui possèdent un fichier .appdata dans son paquet voire code pour la description et d'autres infos. Donc en effet tout ce qui est CLI ou bibliothèque, cela n'est pas visible. Il faut se tourner vers la CLI ou un autre utilitaire tel que Yumex.
Cool. :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.