En ce mardi 3 avril 2018, les utilisateurs du Projet Fedora seront ravis d’apprendre la disponibilité de la version bêta de Fedora 28.
Malgré les risques concernant la stabilité d’une version Beta, il est important de la tester ! En rapportant les bogues maintenant, vous découvrirez les nouveautés avant tout le monde, tout en améliorant la qualité de Fedora 28, et vous réduisez du même coup le risque de retard. Les versions en développement manquent de testeurs et de retours pour mener à bien leurs buts.
Notons que Fedora 28, avec ses quelques 51 changements officiels validés, est sans conteste la version comportant le plus de changements de son histoire. La version finale est pour le moment fixée pour la première semaine de mai (sortie le 1er ou le 8 mai).
Sommaire
- Bureautique
- Gestion du matériel
- Internationalisation
- Administration système
- Développement
- Modularité
- Projet Fedora
Voici les nouveautés annoncées pour cette version :
Bureautique
- Passage à GNOME 3.28
- L’environnement Sugar est disponible en version 112.
- Mise à jour de Fontconfig à la version 2.13.
- Réduction de la redondance entre Anaconda et gnome-initial-setup dans la configuration demandée à l’utilisateur créé lors de l’installation. Le clavier, la date, l’heure et la langue resteront configurés par Anaconda, en revanche la configuration du nom d’hôte est supprimée, tout comme la création du compte root pour reprendre la politique d’Ubuntu. La création du premier utilisateur revient à gnome-initial-setup.
- Les modules invités de VirtualBox sont peu à peu intégrés dans le noyau officiel, Fedora propose ainsi dans ses dépôts officiels les paquets pour obtenir la résolution native ou le dossier partagé dans un système Fedora virtualisé dans Virtualbox.
Gestion du matériel
- Meilleure gestion de l’autonomie des ordinateurs portables avec un processeur Intel. Cela passe par une meilleure gestion de l’énergie des ports SATA pour disques durs et SSD (gain de 1 à 1,5 W), Intel HDA codec pour le multimédia est mis en sommeil après une seconde d’inactivité (gain de 0,4 W) et activation de l’économie d’énergie pour les récepteurs Bluetooth en USB (gain de 0,4 W si tous les ports USB sont en repos). Sachant qu’un ordinateur portable récent non orienté puissance consomme moins de 10 W (7,5 W chez moi) en usage non intensif. Cela peut donner 20 % d’autonomie supplémentaire.
- Intégration de la norme Thunderbolt 3 (concurrent à l’USB sur de nombreux points). La politique de sécurité liée à cette norme (pour éviter qu’un nouveau périphérique accède sans autorisation à des informations confidentielles) est intégrée à GNOME Shell pour notifier les demandes à l’utilisateur.
- Mise à jour de VA-API à la version 1.0.0, qui change l’API et l’ABI mais propose en contrepartie une meilleure exploitation de l’accélération matérielle du matériel récent.
- Les appareils photo RealSens ont besoin de deux bibliothèques librealsense 1 et 2 pour exploiter l’entièreté de leur gamme historique. Le paquet librealsense se réfèrera à la version 2 de la bibliothèque pour les versions modernes, un nouveau paquet librealsense1 sera nécessaire pour le matériel plus ancien.
Internationalisation
- Ibus Typing utilise maintenant la boîte de dialogue pour les émoticônes afin de proposer des symboles Unicode en tapant leur description. Ainsi copyright sign propose le symbole
©. - La bibliothèque libidn passe à la version 2.0.0 forçant le passage de la norme IDNA2003 à IDNA2008 qui ne sont pas compatibles et pouvaient être source d’attaque par redirection. Cette norme sert à transcrire un nom de domaine Internet Unicode en une chaîne latine unique comme faß.de qui devient fass.de ou xn--fa-hia.de respectivement.
- Les données concernant l’internationalisation de glibc sont mises à jour à partir des fichiers ISO et CLDR de 2015 (Unicode 9.0) en remplacement de iso14651_t1_common qui avait 15 ans. Cela permettra de corriger pas mal d’erreurs, dont des tris alphabétiques dans des langues moins courantes en Occident, ou les symbole infini et ensemble vide qui étaient considérés comme identiques.
- Les langues asiatiques chinoises, coréennes et japonaises utiliseront par défaut les polices de Google Noto.
Administration système
- Anaconda, le programme d’installation, devient modulaire. La communication se fait via une API plus stable en DBus, permettant d’améliorer les tests, d’être utilisable sans les droits super‐utilisateur et d’être étendu par l’utilisateur.
-
authselect remplace authconfig et devient l’outil de configuration par défaut pour PAM et le fichier
nsswitch.conf. - Le paquet tcp_wrappers est supprimé. Son utilisation doit être remplacée par iptables, ou mieux par firewalld.
- libnsl et nss_nis sont proposés hors de glibc comme recommandé par le projet officiel. libnsl passe à la version 2 au passage, autorisant la compatibilité de NIS avec la norme IPv6.
- De même pour Sun RPC dont la gestion dans glibc est supprimée pour libtirpc qui permet, entre autres, la gestion de l’IPv6 nativement.
- Le stockage par défaut des clés et autres certificats de sécurité par la bibliothèque NSS est le format de SQLite au lieu de DBM. Cela permet l’accès parallèle et diminue le risque de corruption de la base de données.
- OpenLDAP utilise OpenSSL au lieu de NSS, comme recommandé par le projet officiel.
- Les bibliothèques de OpenLDAP non compatibles multi-fils d’exécution (multithread) redirigent vers leurs versions compatibles multithread comme libldap qui pointe vers libldap_r.
- OpenLDAP abandonne la gestion de TCP Wrappers également.
- L’utilisateur et le groupe nobody voient leurs identifiants (UID et GUID) passer de 99 à 65534, nfsnobody est supprimé, et nobody n’est plus utilisé par défaut pour certains services. Des utilisateurs dédiés seront créés.
- Nouvelle version de la politique de sécurité par défaut. Les clés RSA doivent être de minimum 2 048 bits et DSA est désactivé par défaut. Le passage à TLS 1.2 minimum est repoussé pour le moment.
- Les paquets de gestion de Kerberos dans Python sont grandement remaniés. python-krbV, pykerberos et python-requests-kerberos sont remplacés par python-gssapi. Le premier n’est pas compatible Python 3, le second n’a pas de documentation et est trop minimaliste, quant au dernier, il n’est plus maintenu.
- libcurl utilisera libssh au lieu de libssh2 pour les protocoles SCP et SFTP, ce qui permet l’utilisation de l’authentification GSS-API et l’usage d’algorithmes plus sécurisés par défaut.
- L’outil time passe à la version 1.8, qui change de licence vers GPL v3 et GFDL, qui a de nouveaux codes d’erreur et une nouvelle sortie par défaut. L’affichage conforme POSIX reste possible via l’option
-p. - Mise à disposition de l’application Stratis Storage, qui est une application Python communiquant à travers DBus pour gérer l’espace de stockage du système. Reposant sur le système de fichiers XFS pour le moment, son but est de proposer des fonctionnalités populaires chez Btrfs, ZFS ou LVM, mais en plus simple pour l’utilisateur, comme les instantanés, l’intégrité des données ou la mise en place d’un système de cache.
- Facter passe de la version 2.4.3 à 3.9.2.
Développement
- Binutils passe à la version 2.29.1.
- La glibc 2.27 est utilisée par défaut.
- La partie cryptographique libcrypt de glibc est remplacée par libcrypt.
- GCC 8 devient le compilateur de référence.
- Le cadriciel Web de Python DJango dégaine à la version 2.0.
- Coup de Boost à la version 1.66.
- Ruby est poli à la version 2.5.
- Le compilateur Haskell GHC évolue à la version 8.2.
- De même pour le couple Erlang/OTP pour la version 20.
- Le langage Go court vers la version 1.10.
- L’éléphant PHP avance prudemment à la version 7.2.
- Mise à jour de giflib vers la version 5.1.4 ; un paquet compat-giflib est proposé pour faciliter la transition aux utilisateurs.
- Les symboles de débogage PE pour les applications compilées avec MinGW (à destination de Windows, donc) seront conservés pour simplifier le débogage natif. Les autres symboles seront bien conservés dans le dossier
.debugà part. Cela a un surcoût d’environ 17 % d’espace disque pour une application compilée par ce biais.
Modularité
- Ajout des dépôts modular, modular-updates et modular-updates-testing pour proposer d’autres versions des composants que dans les dépôts natifs de Fedora. Ainsi, l’utilisateur peut choisir d’utiliser une version plus récente (ou ancienne) de Python que celle proposée nativement. Mais, seuls des composants toujours maintenus par le projet officiel sont proposés.
Projet Fedora
- L’architecture AArch64 (ARM 64 bits) devient une architecture primaire pour Fedora Server, donnant lieu à une meilleure promotion et à une meilleure qualité des images officielles.
- L’architecture s390x est proposée aux images Cloud, Docker et Atomic.
- Les binaires empaquetés par Fedora et compilés avec GCC sont maintenant annotés pour permettre de plus facilement retrouver les options de compilations les ayant généré ou les propriétés de leurs ABI.
- Renforcement des options de compilation par défaut pour une meilleure sécurité. Ajout de
-fstack-clash-protection,D_GLIBCXX_ASSERTIONS,-fcf-protection=full -mcet,.got.pltet--enable-default-pie. - Définition et empaquetage des applications écrites en Rust comme exa, ripgrep ou tokei.
- Activation de Python Generators pour permettre aux empaqueteurs de choisir d’utiliser ou non le générateur automatique de dépendance envers un module Python au lancement.
- Les scriptlets ldconfig sont supprimés, du moins pour les paquets installant les bibliothèques partagées dans des endroits standards. Cela simplifiera la maintenance des fichiers SPECS de construction de RPM et l’installation des paquets sera également plus rapide.
En cas de bogue, n’oubliez pas de relire la documentation pour signaler les anomalies sur le Bugzilla ou de contribuer à la traduction sur Zanata.
Bons tests à tous !
Aller plus loin
- Site officiel du projet Fedora (534 clics)
- Site officiel de la communauté francophone de Fedora (190 clics)
- Site officiel de l’association Borsalinux-fr (98 clics)
- Torrents officiels (99 clics)
- Calendrier de Fedora 28 (133 clics)
# Finalement adoptée
Posté par gnumdk (site web personnel) . Évalué à 10.
Ca fait plusieurs mois que je lâche peu à peu ArchLinux. Raison principal, l'absence des symboles de "debug" ce qui rend tous les rapports de bug fait sous ArchLinux bancals. De plus coredumpctl (gdb?) sous Fedora est capable de dire quel paquets installer quand on ouvre un dump.
J'ai longtemps cherché autre chose que Fedora parce que je voulais rester sur une distribution en Rolling Release:
OpenSUSE: L'opposé du KISS d'ArchLinux, plein de wrapper à la con qui font que OpenSUSE fonctionne comme OpenSUSE au lieu de fonctionner de manière standard. Genre, en faisant une installation minimale, installer gdm ne permet pas de lancer gdm… Ca m'a complétement rebuté.
Solus: Bonne distrib mais les paquets sont patchés à l'arrache pour personnaliser l'environnement au lieu d'utiliser XDG_DATA_DIRS et faire rentrer une application dans leur distrib, c'est une galère sans nom.
Debian SID reste dans ma liste même si le freeze obligatoire à l'approche de la release d'une nouvelle stable n'en fait pas une vraie rolling release
Bref, finalement, je reste sous Fedora dont l'intégration de GNOME est juste parfaite. J'utilise F28 depuis la sortie de Gnome 3.28 et elle est déjà plus que stable.
[^] # Re: Finalement adoptée
Posté par phocean . Évalué à -6.
Certes, l'intégration de Gnome est parfaite, mais Gnome étant très imparfait (surtout instable et lent), c'est justement ça qui me pose un problème avec cette distribution.
[^] # Re: Finalement adoptée
Posté par David Demelier (site web personnel) . Évalué à 5. Dernière modification le 04 avril 2018 à 08:24.
Je suis d'accord, je pense retourner sous un wm sous peu. C'est simple, j'ai fermé GNOME Boxes, il a commencé à prendre 100% du CPU. J'ai abrt qui s'est lancé suite à un crash de firefox, il a pris 100% du CPU. Mon pauvre petit thinkpad. Sans compter les indénombrables bugs par ci par là. La qualité de GNOME a malheureusement bien chuté par rapport à ses débuts.
Fedora utilise GNOME par défaut mais fournit beaucoup de spins si tu souhaites autres chose :)
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Finalement adoptée
Posté par gnumdk (site web personnel) . Évalué à 9.
Il fait un snapshot si tu le fermes avec un OS qui tourne
Oui, il a généré un dump pour pouvoir faire un rapport de bug, c'est quoi le rapport avec Gnome?
[^] # Re: Finalement adoptée
Posté par David Demelier (site web personnel) . Évalué à 3.
Non, c'est un problème connu
Non, c'est un problème connu
C'est vrai qu'abrt est divisé en deux, le daemon et gnome-abrt. J'ai un peu mis les deux dans le même sac cependant. Il n'empêche qu'il était installé par défaut avec la Workstation edition.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Finalement adoptée
Posté par gnumdk (site web personnel) . Évalué à 1.
C'est un outils redhat, rien à voir avec le projet Gnome…
[^] # Re: Finalement adoptée
Posté par Okki (site web personnel, Mastodon) . Évalué à 2.
En ce qui concerne Boxes, le rapport de bug indique que ça a été corrigé pour GNOME 3.28.
Quant à abrt, même si je ne nie pas le problème, n'ayant jamais subi ce bug, il n'est sans doute pas si évident que ça à reproduire et corriger. Puis la plupart des gens ne faisant pas de rapports de bugs, ils peuvent sans problème le désactiver.
[^] # Re: Finalement adoptée
Posté par Misc (site web personnel) . Évalué à 2.
Et ensuite rale sur le fait que les trucs sont instables et non corrigés :/
[^] # Re: Finalement adoptée
Posté par ff9097 . Évalué à 3.
Le soin apporté aux autres spins n'est pas du tout le même
[^] # Re: Finalement adoptée
Posté par gnumdk (site web personnel) . Évalué à 3.
Bon, j'ai quand même testé Debian SID hier soir mais il y'a pas les symboles de debug pour WebKit2GTK (WTF?) donc y'a vraiment que Fedora qui répondre à mes besoins :-)
Sachant que Fedora est en semi rolling release (mise à jour des applications durant sa durée de vie avec une base stable et figée), je vais donc rester sous F28.
[^] # Re: Finalement adoptée
Posté par JJD . Évalué à 10.
Pour la plupart des paquets Debian, les symboles de debug existent mais sont dans des paquets qui ont été sortis des dépôts principaux.
Jette un coup d'œil sur cette page :
https://wiki.debian.org/HowToGetABacktrace
En résumé, les symboles de debug sont maintenant (depuis 2015 ?) dans une archive à part (ligne «deb http://debug.mirrors.debian.org/debian-debug/ unstable-debug main» à ajouter au source.list pour Sid).
J'espère que ça te redonnera envie de tenter l'expérience Debian ;-)
[^] # Re: Finalement adoptée
Posté par Le Gab . Évalué à 2.
Pour les symbols, il te faut la branche "stretch-debug" pour Debian 9.4 par exemple.
source: How to get a backtrace
C'est plutôt sain comme approche.
[^] # Re: Finalement adoptée
Posté par freem . Évalué à 2. Dernière modification le 04 avril 2018 à 14:43.
Totalement hors-sujet par rapport à fedora, mais:
Je n'ai pas regardé, mais je serais surpris que voidlinux n'ait pas les symboles de debug. Je n'ai personnellement pas utilisé Arch plus d'un jour (il est des choses qui marquent les souvenirs, comme un paquet Xorg qui à un problème de dépendance direct après l'installation…) mais de ce que je lis au sujet d'arch, voidlinux semble coller pas trop mal à la philosophie (et d'expérience personnelle, ça marche nickel avec un démarrage nettement plus rapide que Devuan que j'ai en double boot. Faudra que je compare avec Debian, un jour, en gardant à l'esprit que j'utilise le build musl de void, pas le build gcc)?
Du coup, questions, as-tu testé void? Pourquoi? Et si testé sans être satisfait, pourquoi également?
[edit]
Aussi, si tu cherches une rolling release, pourquoi fedora? À ma connaissance, c'est une distrib classique, versionnée?
[^] # Re: Finalement adoptée
Posté par Maderios . Évalué à 1.
Jamais vu ce genre de chose chez Arch mais si cela arrivait un jour, il suffirait de rester sur la version antérieure en attendant une correction qui en général arrive en moins de 24 h.
[^] # Re: Finalement adoptée
Posté par freem . Évalué à 3.
Dans mon cas, je ne pouvais pas, puisque c'était justement au cours de l'installation qui devait me faire tester arch. Donc, pas de version antérieure disponible sur ma machine à ce moment la.
[^] # Re: Finalement adoptée
Posté par Maderios . Évalué à 2.
Avec Arch, il existe plusieurs solutions pour installer des versions antérieures. X n'étant pas indispensable, cela aurait été facile de le downgrader:
https://wiki.archlinux.fr/Downgrade
https://wiki.archlinux.fr/Arch_Rollback_Machine
En tous cas, la meilleure chose à faire est de signaler le bug. C'est corrigé rapidement, parfois dans l'heure. :)
[^] # Re: Finalement adoptée
Posté par freem . Évalué à 3.
C'est vrai, quel imbécile je suis!
Sans interface graphique, sur une distrib que je ne connais pas parce que c'est l'installation justement pour la tester, avec laquelle je ne sais donc pas encore vérifier les numéros de version du paquet que j'essaie d'installer et donc encore moins quelle version à été la dernière fonctionnelle, c'est tellement simple, d'installer la dernière version qui casse pas tout le système…
Faut arrêter hein… Arch à des défauts. Arch peut échouer. Certains l'ont vécu, et on jugé en conséquence que cette distro à ce moment n'était pas pertinente pour leurs usages. Et ils n'ont pas tort. Je réessaierai peut-être un jour, peut-être. J'en doute, honnêtement, et ce pour 2 raisons principales:
[^] # Re: Finalement adoptée
Posté par Maderios . Évalué à 1.
Exact. Par ailleurs, Arch n'est pas fait pour les gens qui n'ont pas un minimum de connaissances concernant le système Linux. Rien que l'installation d'Arch (basée sur des scripts) n'est pas évidente. Si l'on n'aime pas ou si c'est trop la galère, pas la peine de s'accrocher…
[^] # Re: Finalement adoptée
Posté par Maderios . Évalué à 2.
On ne peut comparer ces deux distributions. Arch reste très près des sources donc les rapports de bug sont en général à envoyer à "l'upstream". C'est ce que j'ai constaté et c'est ce que j'ai fait depuis un an que j'utilise Arch à la place de Debian et Fedora.
Concernant Fedora, ma critique d'utilisateur: sous des dehors finis et stables, les ennuis tombent à la pelle dès que l'on veut sortir des clous ou même sans sortir des clous. On est à la merci des mises à jour qui se font attendre ou bien, de mises à jour intempestives qui parfois plantent le système. Cela devenait trop compliqué pour moi à gérer. Je préfère de loin Arch pour sa simplicité, sa transparence. La stabilité? Je rencontre bien moins de problèmes qu'avec Fedora et Debian testing. Le tout est de savoir ce que l'on fait. Installer un noyau LTS par exemple pour contourner les noyaux trop jeunes. Le dépôt Aur est vraiment un must, tout y est (ou presque) et au moins, on sait ce que l'on installe. Pour conclure cette ode à la gloire de Arch: on constate que l'on peut (presque) tout contrôler, s'affranchir des paquets officiels si besoin. Grâce à Aur, on peut supprimer les dépendances inutiles comme avec une Gentoo. C'est le top du top…pour moi tout du moins… :)
[^] # Re: Finalement adoptée
Posté par gnumdk (site web personnel) . Évalué à 3.
Mais sans symboles, envoyer un rapport à l'upstream, ça revient à leur dire: "aller vous faire foutre, j'ai une distrib à la con et je vous merde"…
Et sinon j'aime Arch parce que justement ça colle à l'upstream mais sur ce point, Fedora est vraiment très proche de l'upstream, au point que je n'ai pas vu de différence majeurs avec Arch (contrairement aux autres distribs)
[^] # Re: Finalement adoptée
Posté par Maderios . Évalué à 3.
Sans vouloir polémiquer parce que notre appréciation d'une distribution dépend d'une foultitude de paramètres subjectifs et même sentimentaux, la différence majeure réside dans le fait que, à la différence de Fedora, Arch est une vraie "rolling".
[^] # Re: Finalement adoptée
Posté par freem . Évalué à 7.
Debian testing est une version bêta de Debian en même temps… si tu veux jouer avec une Debian rolling-release style (ce qui, en soit, me paraît assez étrange comme concept, mais pourquoi pas) mieux vaut se baser sur unstable.
Sur unstable, les MàJ sont plus fréquentes, donc les correctifs de problèmes arriveront plus vite qu'en testing, ça inclue les problèmes de sécurité.
Oui, Debian patche les paquets pour les intégrer avec le reste du système.
Mais Debian se coltine la maintenance de versions n'ajoutant pas de fonctionnalités et ne modifiant pas le fonctionnement pour les utilisateurs pendant plusieurs années, chose qui serait impossible à une rolling release.
Et donc, tu compares ça avec une distrib qui est rolling release, prévue pour ça, et munie d'une communauté dont la façon de penser colle à ce mode de fonctionnement?
Personnellement, j'ai utilisé Debian testing pendant plusieurs années sans avoir le moindre problème, et sans avoir besoin de me figer sur un kernel particulier. Je connaissais aussi quelques subtilités genre le cache des paquets à vider régulièrement pour pas bouffer tout le /var, je sais qu'avec le boot loader que j'utilise il me faut faire une étape manuelle à la main pour mettre à jour un kernel (parce que j'ai toujours eu la flemme de chercher comment marche dpkg-divert, ou un truc du genre), etc etc.
J'ai arrêté parce que, en fait, ça ne m'apporte rien par rapport à une stable + backports. Au pire quand il me manque un paquet ou si je veux un truc plus récent, j'importe le paquet en question et je le recompile, c'est pas vraiment difficile. Et si le paquet existe pas ou est trop vieux même dans testing/unstable/experimental, ben, je clone le dépôt officiel et je compile. Parfois je patch, aussi (m'est arrivé sur cgdb, mais il faudrait que je remette mon nez dedans, j'ai quelques plantages et freeze qui font chier parfois… 'fin bon).
Mais bon, toi comme moi, ici, on triche: oui, c'est facile de ne pas tomber dans les pièges quand on sait ou ils sont.
D'un autre côté, je pense qu'arch vise des utilisateurs aussi plus démerdards que Debian, qui sert accessoirement de distro mère à pas mal de monde, c'est aussi à prendre en compte.
M'enfin, pour moi, que ce soit fedora, debian, arch, … elles ont toutes une vraie raison d'être et une philosophie bien précise derrière. Je ne crois pas qu'elles soient en opposition mais plutôt complémentaires.
[^] # Re: Finalement adoptée
Posté par Renault (site web personnel) . Évalué à 5.
Tout à fait, il serait bien que cela soit compris par tous.
[^] # Re: Finalement adoptée
Posté par Le Gab . Évalué à 1.
Une belle phrase bateau.
Je ne veux pas empêcher les archistes de vivre mais en même temps ce sont les plus bruyants et vecteurs de fausses idées (userfriendly, plus léger, etc,…)
Fedora, Debian possèdent toutes deux une image minimaliste "net-install" à partir de laquelle tu peux composer ton système.
Il y a certes, certaines partie du système-d (:)) que tu ne pourras pas remplacer facilement, comme tu pourrais le faire avec Arch ou Gentoo mais à part ça, je ne vois pas.
Mais, elles aussi ont des branches différentes, des repo communautaires, tu peux reconstruire les paquets si nécessaire, etc…
Donc elles résolvent les même problèmes et proposent les même solutions.
"Oui mais pourquoi autoriser 2 et pas 3 distro ?"
Hé bien Fedora, même si communautaire, est avant tout backé par Red Hat. Compagnie qui fait du libre, mais compagnie avec des impératifs économiques tout de même.
Debian est vraiment "libre" et d'origine communautaire et présente depuis le début.
Mais voilà, GNU/Linux n'a pas vraiment besoin de plus de distro du genre surtout basé sur le même paradigme par contre, des initiatives comme NixOS ou autres qui sortent un peu des sentiers, là ça a du sens.
Et donc Archlinux? Simplicité du système? C'est un point valide mais Debian sans un DE, c'est tout aussi simpliste, tout est relatif.
Tu n'as pas deviné tout seul comment créer des services, des paquets sous Archlinux, ben pareil sous Debian ou Fedora, tu as lu le handbook ou le wiki.
Debian n'est pas parfaite, bien que ça soit mon "daily driver", mais je préfère capitaliser sur ses acquis, sa taille et sa stabilité dans le temps.
[^] # Re: Finalement adoptée
Posté par freem . Évalué à 4.
Ben perso, je n'installerai pas une rolling release sur un serveur au taf (j'ai bien d'autre tâches à accomplir que serrer les fesses ou lire les patchs à chaque MàJ) par contre sur un système perso pour avoir des soft aux dernières versions, pourquoi pas. Arch semble une candidate intéressante, surtout quand on constate la qualité de la documentation de leur wiki pour le barbu.
Si je veux un truc que je puisse custo à 100%, j'irai voir gentoo, idem, pas mal de doc pas dégueu me semble, mais plus orientée compilation et non configuration.
Pour un système perso avec lequel j'ai envie d'avoir du bleeding edge mais en étant plus tranquille quand je fais une MàJ, et pour découvrir le système de paquet de RH, fedora me semble intéressante.
Debian, si je veux pas payer du support à red hat et que je veux de la stabilité, ça juste marche nickel.
Voila qui développe un peu ma phrase bateau, non?
Nous sommes d'accord, mais c'est pas la faute de la distrib.
Lesquelles, pour Debian? Je suis curieux, vu que je n'ai pas, à ma connaissance, de systemd qui tourne sur ma machine actuelle, qui est sur une Debian stable. Udev peut-être? À part ça, je vois pas, et si je le vire pas c'est surtout parce que je n'ai jamais pris le temps de savoir comment il marche (donc, je ne sais pas si ça serait simple).
Le côté rolling release pur. Proche de l'upstream. Le wiki d'arch est sans commune mesure au niveau de la qualité. Et je suis un utilisateur de Debian convaincu depuis quelques années. Un système minimal? J'ai une Debian qui tourne avec musique et session graphique avec moins de 80Mo de RAM, à la maison (la machine en question ayant au total moins de 200, y'a des paquets que je pourrais encore compresser si je recompilais, mais la flemme…).
Je pense que je peux dire que je sais faire. Par contre, simplicité? Debian? Euh… non.
Déjà à l'époque de sysVinit, modifier ou créer un script d'init n'était pas simple, mais au moins changer le TTY ça se fait en 2 temps 3 mouvements.
Depuis systemd… y'a des fichiers d'init partout, c'est un foutoir monstrueux. Changer proprement le tty sans que ça risque d'être écrasé à la prochaine MàJ? J'ai pas trouvé perso.
Je sais pas ce que ça donne dans les autres distros qui utilisent systemd, donc je ne pourrais pas juger, mais je peux comparer avec void qui utilise runit, et si on parle de simplicité, je vois pas comment faire mieux, pour le coup.
Tiens, j'ai du bol, c'est le bon jour pour parler d'init :)
[^] # Re: Finalement adoptée
Posté par Lutin . Évalué à 3.
Le meilleur coté de Arch, ça reste quand même sa documentation.
Dire qu'il y a encore quelques années c'était de Gentoo qu'on disait ça.
[^] # Re: Finalement adoptée
Posté par Jiel (site web personnel) . Évalué à 3.
Arch c'est le Gentoo de 2018.
[^] # Re: Finalement adoptée
Posté par Psychofox (Mastodon) . Évalué à 3.
Je ne suis pas pro telledistro (j'utilise actuellement à parts égales du fedora et du debian) mais questions phrases bateau qui ne veulent rien dire ça se pose là.
[^] # Re: Finalement adoptée
Posté par Le Gab . Évalué à 1.
Peut-être lis-tu mal, déjà que tu n'as pas l'air de comprendre l'expression "phrase bateau" (point culture)
Pareil, je suis aussi à part égale sur ces deux distros, mais ce que je veux dire, c'est que fondamentalement, l'une n'apporte pas plus que l'autre et que l'une est moins libre de mouvement (Fedora) que l'autre.
Red Hat fait son chiffre d'affaire sur le cloud, containers etc… si ils décidaient d'arrêter les frais avec Fedora, il y a peu de chance qu'elle survive là où Debian, libre et communautaire depuis le début n'a pas ce problème. Elle n'est pas à l'abris de fork (cf Devuan) mais on le voit, tant que l'original est en vie et se porte bien, la sauce ne prend pas.
Donc en GROS, voilà pourquoi on devrait principalement focaliser sur Debian.
[^] # Re: Finalement adoptée
Posté par Renault (site web personnel) . Évalué à 6.
Fedora n'est pas moins libre de mouvement que Debian, c'est quoi cette ânerie ?
Fedora reste un Logiciel Libre (donc tout le monde est libre de le forker) avec un développement communautaire (non, Fedora ne suit pas un calendrier de Red Hat, beaucoup de bénévoles y proposent ou y font des choses sans rapport).
Fedora a une communauté assez large et a une place assez centrale pour rebondir.
N'oublions pas que Red Hat a des contributeurs clés (entre 10 et 50% des contributions) dans systemd, LibreOffice, le noyau Linux ou même GNOME (étrange pour une distribution que pour un usage serveur ?), tu crois que Debian saurait gérer une perte d'autant de contributeurs dans autant de logiciels clés pour elle ? Tu penses que GNOME, Linux ou LibreOffice ne sont pas libres de mouvement car Red Hat ou d'autres entreprises proposent l'essentiel du travail ? Debian se reposant sur des logiciels dont elle n'en a aucun contrôle est-elle vraiment libre de ses mouvements ?
Selon moi ça n'a pas de rapport, ce n'est pas parce qu'une entreprise finance ou contribue fortement qu'un logiciel est moins libre de mouvement qu'un autre. D'ailleurs par transitivité, Debian tomberait dans ta critique en fait, si tu étais cohérent.
Fedora est libre et communautaire depuis le début. Merci pour elle.
Fedora, Ubuntu, ArchLinux et autres ont un impact significatif dans l'écosystème du Logiciel Libre en général. Debian n'est pas seul et ne peut remplir tous les rôles des autres distributions. Tu crois que Wayland serait aussi avancé sans l'implication de Fedora ? Tu crois qu'on aurait autant d'utilisateurs Linux (et donc indirectement de développeurs) sans Ubuntu ? Etc.
Chaque distribution (du moins majeure) a son intérêt, sa communauté et son influence positive.
[^] # Red Hat
Posté par Arthur Accroc . Évalué à 1.
Comment expliques-tu que Fedora ait très longtemps installé par défaut le calamiteux Sendmail 8 (calamiteux aussi bien du point de vue de sa configuration que de la sécurité), alors que les autres distributions l’avaient remplacé avec raison, si ce n’est que RedHat l’installait sur RHEL et vendait du support dessus (il y aurait moins de support à vendre sur un logiciel beaucoup plus facile à configurer comme Postfix ou Exim) ?
On peut soupçonner que ça aide à ce qu’un projet (disons GNOME) adopte les solutions apportées par un autre projet (systemd).
L’expérience a effectivement montré que les autres distributions finissent bon gré mal gré par adopter les changements impulsés sur Fedora par les employés de RedHat (PulseAudio, systemd…) et n’ont souvent pas les moyens d’imposer leurs solutions, voire de les maintenir (Upstart, Mir, Unity…), ou ne serait-ce que de développer des solutions originales (il faut des développeurs pour ça).
Bref, Red Hat est assez libre de ses mouvements (enfin pas autant que Microsoft avec Windows) justement parce qu’elle a les moyens d’employer des développeurs clés d’un certain nombre de projets du libre.
Les autres sont libres… de profiter des contributions des employés de Red Hat (qui ont forcément du positif, sinon ils se feraient jeter, comme Sendmail 8).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Red Hat
Posté par Renault (site web personnel) . Évalué à 4.
Sendmail était fournie sur d'autres OS que Linux je le rappelle (notamment Mac OS X fut un temps). Il ne faut pas croire que ce logiciel était si mauvais que cela d'autant qu'il avait quelques atouts.
Ah la fameuse théorie du complot de fournir un logiciel compliqué pour vendre du support. Il est en général plus efficace de vendre un bon produit, agréable à utiliser pour attirer le client que l'inverse. Car configurer un serveur de courriels cela demande des compétences aussi, même si tu utilises des solutions plus simples.
Ou peut être que systemd propose des solutions pour répondre à des besoins de GNOME en fait ?
GNOME n'est pas développé uniquement par Red Hat hein, si les autres développeurs ne veulent pas de systemd ou veulent maintenir une alternative, ils en étaient largement capables de le faire.
Ouaaaaaa, Red Hat a menacé tout le monde tu crois ? Les débats pour les adoptions ont rarement étaient longues en fait… Et rappel, PulseAudio a été développé sur une base d'Ubuntu avant que Fedora ne l'adopte. Donc bon le complot de Red Hat pour s'imposer on va arrêter ici.
Upstart a été utilisé par Red Hat et Fedora qui y ont contribué. systemd a toujours été vu comme un successeur de upstart, son créateur ayant lui même expliqué que les défauts d'upstart nécessitaient la réécriture complète. Upstart n'était donc pas un concurrent de systemd mais comme une étape intermédiaire (et Canonical n'a pas discuté longuement avant d'utiliser systemd).
Wayland n'a pas été lancé par Red Hat mais par des développeurs de X11 d'une part, et ce avant Mir. Mir a été conçu car Canonical plutôt que de participer à Wayland a ses débuts s'est plaint des choix faits techniquement et a préféré faire quelque chose de son côté. N'inverse pas les rôles donc.
Quant à Unity, personne ne l'a adopté à part Ubuntu (étrange non ? Un complot de Red Hat sans doute) du coup Canonical supportait seule sa maintenance et son évolution ce qui est trop lourd. Cela n'avançait pas assez vite et trop de problèmes restaient en suspend.
Bref, ce serait bien d'éviter les clichés et autres théories du complot qui se basent sur des faits et des théories fumeuses.
[^] # Re: Red Hat
Posté par freem . Évalué à 3.
D'autant que toutes les distributions n'ont pas adopté ces outils, pas plus qu'ils ne sont imposés sur toutes les distributions qui les installent par défaut.
En tout cas, personnellement, je n'ai jamais eu besoin de PA, et ne l'installe donc pas. Je préfère runit à systemd, et ma Debian marche très bien sans systemd.
Par contre, c'est vrai, je n'utilise pas gnome et n'ai pas de périphérique bluetooth (j'ai cru lire que slackware installe PA parce que bluez ont droppé la compat alsa… mais bon, je m'en fout un peu, j'ai pas besoin de bluez moi).
C'est un nouveau composant de systemd?
Bon ok, je sors…
[^] # Sendmail
Posté par Arthur Accroc . Évalué à 2.
J’ai administré un serveur Sendmail sous Solaris avec plusieurs domaines mail, je connais.
Et dès que je n’ai plus été dans l’urgence à gérer ses problèmes, je l’ai remplacé par Postfix, en version bêta à l’époque (ça devait être en 1999), donc déjà infiniment plus solide que Sendmail.
Les failles majeures presque tous les mois (à l’époque où il était massivement utilisé) ?
La configuration imbitable ?
Les macros M4 qui produisaient une configuration à partir d’un fichier plus lisible par les humains, sauf qu’on était obligé de la retoucher derrière pour que ça marche vraiment (probablement pas dans les cas triviaux, mais par exemple pour du multi-domaine) ?
La lourdeur ?
Ah ça oui remarque, ça limite la quantité de spam qu’un pirate (qui t’a piraté grâce à une faille de Sendmail…) peut envoyer avec ton serveur.
Sendmail a une place… dans l’histoire.
Ah la fameuse façon d’éluder la question en disant « théorie du complot ».
Explique-moi plutôt pourquoi Fedora a conservé Sendmail des années (facilement une dizaine) après que les autres distributions (sauf RHEL) l’aient viré (elle n’a même jamais installé un autre serveur mail par défaut, elle a juste arrêté d’installer un serveur mail par défaut).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Sendmail
Posté par Renault (site web personnel) . Évalué à 3.
On va faire simple : certains outils (comme cron) par défaut avaient besoin d'un MTA pour communiquer avec l'utilisateur avant l'utilisation de certains fichiers logs. Fedora a mis plus de temps que les autres pour s'en débarrasser, en tout cas il n'y a aucune discussion où un non employé Red Hat a tenté de s'en débarrasser (et je rappelle que les décisions techniques de ce genre sont prises en majorité par des personnes issues de la communauté).
Et quand les employés de Red Hat se sont bougés pour le virer, ça a mis 3 ans :
https://fedoraproject.org/wiki/Features/NoMTA
https://fedoraproject.org/wiki/Changes/NoDefaultSendmail
Preuve que les gens n'étaient pas spécialement motivés pour s'en débarrasser. Car bon soyons honnête, si ce n'était pas la meilleure solution technique existante, elle remplissait son besoin de base et si l'utilisateur voulait mieux il y avait postfix ou exim dans les dépôts. Je ne vois pas ce que Red Hat a avoir là dedans…
[^] # Re: Sendmail
Posté par Arthur Accroc . Évalué à 1.
En effet. Mais pourquoi choisir le plus mauvais (et de loin) ?
Ces liens éclairent sur son retrait, pas sur le fait d’avoir conservé celui-là en particulier.
Après, je ne dis pas que Red Hat a fait pression pour conserver sendmail.
L’autocensure peut suffire à expliquer. Si je participais à un projet où une grosse boîte fournissait la majorité des moyens (en particulier en développeurs), j’hésiterais aussi avant de demander qu’on jette son gagne pain.
Donc les mainteneurs de Fedora auraient juste mauvais goût.
Après tout, c’est peut-être crédible : quand Red Hat a mis Gnome par défaut (il n’y avait pas encore de Fedora et c’était Gnome 1 ou une préversion), il était carrément bogué, pareil quand Fedora est passé à Gnome 3 ou a intégré PulseAudio… Un goût pour les usines à gaz boguées, semblerait-il.
C’était quand même dommage de laisser un truc qui collectionnait les failles juste pour remplir le besoin de base…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Sendmail
Posté par Renault (site web personnel) . Évalué à 3.
Décision probablement historique et pas prioritaire => status quo.
Deux choses :
D'ailleurs dans les liens que je pose, tu vois que différents ingénieurs de Red Hat se sont penchés sur la question de supprimer sendmail et que cela a pris trois ans pour aboutir. Non pas à cause d'une décision hiérarchique, mais parce que ce n'était pas la priorité et tout le monde s'en foutait.
Tu as un goût prononcé pour le troll. Personnellement je m'arrête là.
[^] # Re: Red Hat
Posté par freem . Évalué à 2.
Encore faudrait-il qu'elles aient envie d'imposer leurs solutions ET que ces solutions soient supérieures à l'existant. Une piste: ce n'est le cas ni de mir, ni de upstart.
C'est ça, les autres sont libres, d'utiliser ou non tout ou partie des contributions de RH. Et pourquoi pas, d'ailleurs?
Pour l'info, j'utilise à titre personnel les 2 distributions que pour lesquelles j'ai mis des liens. Je n'utilise aucun soft qui ait besoin de PA. Les systèmes bootent très bien (dans le cas de void, la vitesse de démarrage est d'ailleurs bluffante) et le son marche à la perfection.
Pour en finir avec ce post: je remercie Lennart Poettering d'avoir fait systemd. Parce que sans ça, je n'aurais jamais étudié le sujet des systèmes d'initialisation, je serais resté avec l'infâme et ingérable sysVinit version Debian. Grâce à systemd, j'ai découvert runit (entres autres outils).
[^] # Re: Finalement adoptée
Posté par freem . Évalué à 2.
Un fork qui a bien pris: Ubuntu et ses déclinaisons. De la sont nées notamment Mint et Kali.
Quant à Devuan, elle ne sera probablement jamais au même niveau, ça restera probablement aussi confidentiel que des trucs comme Trisquel, mais elle est suffisamment vivace pour avoir une version stable, et un certain nombre de changements dans la testing (au fur et à mesure, des outils moins mainstream sont utilisés et intégrés, notamment eudev, et je pense que c'est une bonne chose. L'idéal, ça serait que le travail fait par Devuan soit repris par Debian, avec un mécanisme d'alternatives, mais bon, le temps le dira.).
[^] # Re: Finalement adoptée
Posté par Maderios . Évalué à -1.
Un fork, par définition dérivé du projet initial, devient autonome par rapport à ce projet pour s'en éloigner peu à peu. Ubuntu peut il se passer de Debian? Non. Idem pour Manjaro et Arch.
[^] # Re: Finalement adoptée
Posté par freem . Évalué à 3.
En quoi?
À mon sens, ils s'en passent plutôt pas mal pour bien des briques du système, et depuis quelques temps déjà. À minima, ils ont changé le système d'init par défaut par upstart bien avant que Debian ne considère même de changer ça, ils ont eu leur propre DE installé par défaut, et il me semble me souvenir de problèmes de symboles dans quelques libs, d'une époque ou je m'étais amusé à installer un paquet Ubuntu sur ma Debian (me demandez pas pourquoi, je m'en souviens plus… probablement un ppa?).
[^] # Re: Finalement adoptée
Posté par Maderios . Évalué à -1.
A supposer que Ubuntu puisse se passer de Debian, pourquoi le fait il sans le faire vraiment? :))
Yes, Ubuntu is a fork. No, it isn't. Yes it is! Oh, whatever.
https://wiki.ubuntu.com/MarkShuttleworth#Is_Ubuntu_a_Debian_fork.3F_Or_spoon.3F_What_sort_of_silverware_are_you.2C_man.3F
[^] # Re: Finalement adoptée
Posté par freem . Évalué à 3.
Parce que tous les forks ne sont pas agressifs, et qu'il est plus simple de maintenir un fork qui reste le plus proche de l'upstream possible tout en gardant les spécificités sous forme de patchs, ce que le système de paquets de Debian permets relativement aisément.
À noter que c'est ce que fait Devuan également :)
A lire quelques lignes au hasard, il semble que ma réponse soit un bon résumé :)
Mais je pense que pour répondre à la question «Ubuntu est-elle un fork de Debian?» il faut déjà définir ce qu'est un fork. Pour moi, un fork, c'est partir d'une base (de code source, de configurations, de documentation, peu importe) déjà existante et la modifier pour aller dans une direction qui n'est pas celle voulue par la base.
Ensuite, un fork peut devenir totalement décorellé de l'original, ou rester proche, re-fusionner ou contribuer, ce n'est pas important.
Du coup, selon ma définition, Ubuntu est totalement un fork de Debian, mais ce n'est pas un fork qui s'est fait dans le conflit, contrairement à Devuan. Iceweasel était un fork de Firefox, également, même si le code restait très proche de l'original et si je suis persuadé qu'ils ont reversé des patchs acceptés par l'upstream.
[^] # Re: Finalement adoptée
Posté par Maderios . Évalué à 0.
Exact. J'ai installé et je "maintiens" régulièrement une Debian stable pour une proche. Rien de mieux. Gestion pépère, pas trop de mises à jour…
# pas rolling release mais presque
Posté par PLuG . Évalué à 2.
Fedora n'est pas rolling release, elle est versionnée ( F28 ) mais passe d'une release a la suivante (depuis F21) avec une simple commande (sans réinstaller), et ça marche de mieux en mieux. Avant F21 c'était possible mais il fallait bricoler.
https://fedoraproject.org/wiki/DNF_system_upgrade
mes 2c
[^] # Re: pas rolling release mais presque
Posté par Okki (site web personnel, Mastodon) . Évalué à 2.
Ça reste des mises à jour à date fixe (même si les dates sont très variables, chez Fedora).
Par contre, contrairement à Debian ou Ubuntu, dont les applications ne changent pas en dehors du cycle (à quelques très rares exceptions près, comme le navigateur), chez Fedora, le noyau, certaines technologies du système de base et de nombreuses applications sont régulièrement mises à jour.
Donc, même s'il ne s'agit pas d'une rolling release à proprement parler, ça bouge tout de même pas mal, je trouve.
[^] # Re: pas rolling release mais presque
Posté par ff9097 . Évalué à 1.
T'es censé plutôt passer par Gnome Software, qui te notifie lorsqu'une nouvelle version est disponible, donc en un clic tu peux upgrader
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.