Sortie de Fedora 17 nommée Beefy Miracle

46
29
mai
2012
Fedora

En ce mardi 29 mai 2012, le projet Fedora est fier d’annoncer la sortie de la distribution GNU/Linux Fedora 17. Cette version est baptisée « Beefy Miracle », par mémoire à la naissance de Fedora Core, où Red Hat redistribuait Fedora Core sans la marque ni le logo déposés Fedora, en les remplaçant par un hot dog !
Logo Beefy Miracle

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.

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, la célèbre suite de compilateurs GCC, etc. Voici l’ensemble des contributions de Red Hat.

Par ailleurs, les distributions telles que RHEL, Scientific Linux ou CentOS (plus indirectement), avec un temps de cycle plus faible 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 et une garantie.

Voir la suite de la dépêche pour une liste des nouveautés de Fedora 17.

NdM : Merci à Nÿco, Benoît Sibaud, Florent Zara, j, patrick_g, Yves Bourguignon, azmeuk, tankey, Xavier Claude, come, Sébastien Wilmet et barul pour avoir participé activement à la rédaction de cet article.

Sommaire

Listes des nouveautés principales

Bureautique

Environnements bureautiques

GNOME 3.4 débarque sur Fedora ! Cette version corrige les erreurs de jeunesse du nouveau GNOME 3. Au menu : pleins de détails corrigés avec un thème légèrement refait. Le navigateur Epiphany profite d'une grande refonte de son interface pour plus de sobriété et utilise SQLite pour gérer l'historique. Le gestionnaire de clés prend en charge la gestion des cartes à puce. L'utilitaire de gestion des disques a subi une refonte totale pour passer de la technologie HAL à udisks et de GTK+2 à GTK+3 ce qui permet également de simplifier légèrement l'interface. Pour se rapprocher de la prise en charge des tablettes, il y a la prise en charge du mode avion et du multi-point pour l'écran tactile. Le carnet d'adresses apparaît, le logiciel de messagerie peut maintenant gérer les comptes Windows Live depuis le passage à XMPP chez Microsoft. L'application « Box » permet de gérer très simplement la virtualisation à l'aide de la bibliothèque libvirt. Pour finir, GNOME Shell peut être utilisé avec des cartes graphiques vieillissantes pour supprimer le mode « dégradé ».

Bureau par défaut

KDE n'est pas en reste avec la version 4.8. Le gestionnaire de fenêtre KWin dispose d'une amélioration notable de la gestion des ressources pour ses effets graphiques. Le navigateur de fichiers Dolphin améliore ses performances d'affichage et possède un nouveau mode d'affichage par défaut, cependant la vue par colonne a également été supprimée. L'éditeur de texte Kate améliore sa gestion du chercher/remplacer et peut utiliser les raccourcis clavier de l'éditeur Vim. Okular peut maintenant annoter les PDF, KMix peut modifier sans PulseAudio le son de chaque application. Le gestionnaire de connexions KNetWorkManager peut partager une connexion Wifi et son interface a été repensée pour plus de simplicité. Le gestionnaire d'énergie est plus intelligent, ne réduisant pas la luminosité en cas de lecture vidéo ou de photos par exemple. KSecretService qui gère les mots de passe peut stocker celle des applications non-KDE pour plus de transparence. L'afficheur multimédia, GwenView, n'a désormais plus aucune latence lorsqu'il rencontre une vidéo à afficher, et pour le zoom sur images ou photos il propose une « vue d'aigle » à la place des barres latérales de scroll, enfin il ajoute des effets de transition entre photos.

Mais derrière ces deux gestionnaires de bureau très connus, Sugar continue toujours sa progression au sein de Fedora avec la version 0.96. Rappelons que cette interface est utilisée dans le cadre de l'opération OLPC avec l'ordinateur XO. Cette version débute la transition vers la bibliothèque graphique GTK+3 comme le navigateur Web ou le lecteur de PDF et livres numériques. Les « activités » en profitent pour obtenir de nombreuses améliorations et corrections diverses. Et enfin, cette version prend en charge NetworkManager 0.9 permettant une meilleure gestion de la connexion réseau qui est pour l'ordinateur XO une première nécessité pour la gestion du réseau ad-hoc notamment. Cette version apporte des améliorations avec le lecteur de livres numériques ou encore le lecteur vocal de textes présenté dans la capture d'écran suivante.

Lecteur de texte sous sugar

Gestion du matériel

Dans un autre registre, la prise en charge des profils ICC par CUPS, qui gère les impressions. Les profils ICC servent à déterminer la correspondance de couleur entre périphériques informatiques. En effet, les matériels informatiques comme les écrans, appareils photos, webcam ou imprimantes ne représentent pas la couleur de la même façon et ce même d'un modèle à l'autre d'un même constructeur ! Ainsi un rouge sur votre écran peut être un rouge différent sur le papier imprimé ou sur l'écran du voisin, et ce problème est très important dans les métiers de l'infographie où la couleur doit être fidèlement représentée sur toute la chaîne de production (de la prise de la photo au papier). Fedora apporte la solution pour le passage de l'écran à l'impression par cette fonctionnalité. Le démon colord correspondant choisira le profil adapté à l'impression pour le rendu et appliquera le filtre.

Fedora 17 possède une meilleure gestion de l'énergie de par l'usage de nouveaux profils de consommation et continuera à évoluer. L'objectif est d'utiliser dbus pour rendre le système plus intelligent, notamment au branchement et débranchement de l'alimentation d'un ordinateur portable. Il est possible de concevoir des profils adaptés à chaque situation ce qui devrait diminuer la consommation globale d'énergie, notamment quand l'ordinateur est sur batterie. Il est également possible d'étendre ces profils aux machines virtuelles via KVM.

Prise en charge des écrans multi-points. Fedora a patché le serveur X mais aussi ses bibliothèques associées pour permettre l'usage du multi-point au sein des interfaces de Fedora, telle que GNOME Shell qui est adaptée pour cet usage.

Fedora avec sa version 17 signe la fin de la prise en charge des pilotes 3D DRI version 1. Ceci allège le code de Mesa en ne gérant plus les pilotes suivants : i810, mga, r128, savage, sis, tdfx et unichrome qui sont en règle général très peu utilisés aujourd'hui et plus maintenus depuis de nombreuses années. Le 2D reste pris en charge et avec l'amélioration de GNOME Shell, il est maintenant possible de l'utiliser avec de tels pilotes nativement.

Autres éléments logiciels

Prédiction lors de la frappe en anglais. En effet, iBus, un utilitaire qui permet de changer de disposition de clavier aisément, peut maintenant utiliser un dictionnaire pour réaliser de l'auto-complétion de mots dans la langue de Shakespeare où que vous soyez dans l'interface. L'utilisateur détermine les mots à placer dans le dictionnaire au fur et à mesure et a accès à la suggestion de mots notamment en cas de mauvaise orthographe… Intégration de libpinyin dans iBus pour les langues chinoises. L'objectif est d'augmenter la vitesse de frappe pour ces langues en se basant sur la phrase tapée afin de suggérer certains caractères, diminuant ainsi le nombre de touches nécessaires pour saisir le caractère.

Les dispositions claviers m17n (pour multilingualization) pour les langues hindoues ont été modifiées selon un nouveau standard en préparation par le gouvernement indien.

Dans la même veine, la prise en charge de Unicode 6.0 pour les langues hindoues est également disponible avec les polices Lohit, mettant plus de caractères à disposition pour ces langues. Le rendu n'est pas idéal et devrait mener à de futurs peaufinages.

Création d'un utilitaire pour configurer les polices du système. Cette configuration est propre à chaque utilisateur et peut se faire langue par langue disponible par le système afin d'avoir le meilleur rendu possible pour une langue donnée.

fonts-tweak-toll

Mise à disposition de GIMP 2.8. La nouvelle version majeure du logiciel de traitement d'image libre permet de rendre l'interface en mode fenêtre unique comme son concurrent Adobe Photoshop ou de garder l'apparence par défaut. L'équipe de développement offre aussi le groupement de calque tant attendu, l'édition de texte se fait directement dans le canevas (donc sur l'image et non dans une fenêtre à part). Il est aussi possible de modifier la dynamique des brosses. Bien entendu, d'autres nouveautés sont présentes.

Administration système

Système et services

Le plus gros travail dans ce domaine était le déplacement de la racine (/) vers le dossier user (/usr) entrainant la disparition des répertoires /bin, /sbin, /lib et /lib64. Ces répertoires étaient présents pour des raisons historiques et techniques qui n'ont plus lieu d'être aujourd'hui. /usr est un dossier qui était aujourd'hui indispensable et la séparation des 4 dossiers de /usr posait des problèmes techniques pour la séquence de démarrage avec initramfs qui avait besoin de nombreux logiciels pour son exécution et qui sont un peu dispersés dans tous ces répertoires, répertoires qui ne sont pas montés au même instant en général. Cette séparation va entrainer un certain allègement du démarrage du système, mais aussi améliorer la compatibilité avec d'autres Unix comme Solaris qui ont déjà opéré ce changement, la gestion des paquets s'en trouvera également simplifiée. En effet, il n'y aura plus de cas particuliers à gérer, tout ira dans le même dossier, sans risque de confusion à l'usage. Pour migrer en douceur, les répertoires par défauts sont maintenant des liens symboliques vers leurs successeurs dans /usr.

Conversion des derniers scripts init de SysV vers systemd. Systemd est l'application qui gère le lancement des processus lors du démarrage de la machine afin qu'elle se lance correctement. Systemd a déjà remplacé init chez Fedora pour cette tâche pour la 15e version, mais la plupart des services utilisaient la couche de compatibilité entre init et systemd. Maintenant ce sont des scripts natifs pour systemd et qui par conséquent exploitent mieux ses possibilités. Le temps de démarrage peut être sensiblement amélioré et la configuration de ces scripts sera beaucoup plus simple pour les administrateurs systèmes. Ce travail a débuté depuis de nombreuses versions de Fedora mais n'avait jamais été totalement finalisé.

Les services du système lancés par systemd peuvent obtenir des dossiers dans le répertoire /tmp avec des droits d'accès supplémentaires. L'objectif est de rompre la communication entre l'utilisateur et ces services pour éviter des problèmes de sécurité par le procédé d'escalade de privilège. En effet, un service pouvant obtenir des droits supplémentaires sur le système par rapport à l'utilisateur de base, l'usage à mauvais escient de cette communication pouvait permettre à un utilisateur de base d'obtenir ces droits supplémentaires.

Réseau

Le pare-feu dynamique fait son apparition sous forme de démon nommé firewalld. Son objectif est de remplacer les outils iptables qui sont statiques. Le principal inconvénient étant qu'actuellement le pare-feu statique nécessite un redémarrage de ce dernier en cas de modification des paramètres, entrainant un problème de sécurité et nécessitant même de perdre la connexion durant ce laps de temps. Ce problème est résolu avec ce nouveau pare-feu qui demandera une prochaine version de Fedora pour remplacer iptables totalement, le temps d'adapter tous les outils tels que system-config-firewall et l'adaptation entière du système à cette modification majeure.

En prolongeant le travail sur le pare-feu dynamique, cette version de Fedora apporte la conception de « zones de réseaux » pour déterminer les services réseaux disponibles selon le niveau de confiance accordé à un réseau. Cela peut sembler évident, mais un réseau Wifi public ne devrait pas laisser passer les mêmes flux de données en clair que le réseau filaire chez soi. Grâce à cela, un réseau peut être classé dans l'une de ces zones et l'administrateur décide ainsi pour une zone donnée de l'usage possible du trafic réseau pour la machine. Cette nouveauté repose entièrement sur le nouveau pare-feu décrit précédemment, afin de charger un nouveau profil de pare-feu selon la connexion en cours.

NetworkManager se dote de nouvelles fonctions dédiées aux usages professionnels ou de virtualisation que sont les connexions de liaisons, IP-over-infiniband et VLAN. L'objectif est de pouvoir utiliser Fedora dans le plus de configurations possibles. Un travail important a été effectué pour intégrer le tout avec la virtualisation par libvirt.

Toujours au sujet du réseau, Fedora 17 passe toutes ses requêtes DNS à travers le protocole DNSSEC. Ce protocole est destiné à combler les manques de sécurité de son célèbre prédécesseur qu'est le DNS avec la protection des données de bout en bout empêchant ainsi l'exploitation des données par un serveur situé dans la liaison. Le tout utilise un système de clé et actuellement plus d'une vingtaine de TLD sont signés et de même pour les serveurs racines.

Débarquement du simulateur de réseau Ns-3, en sachant que le programme ns-2 est déjà utilisé par de nombreuses universités américaines pour l'enseignement réseau.

À proximité du noyau

La prise en charge du système de fichiers ext4 au-delà de 16 Tio : en effet, il n'est pas rare de nos jours, avec les systèmes RAID actuels à bas coût, de voir des systèmes approcher cette capacité limite, préjudiciable en entreprise. Cette extension permet de repousser la limite à 100 Tio.

Il est dorénavant possible à SELinux de ne plus autoriser à d'autres processus de lire la mémoire d'autres processus que le sien, cela passe par le booléen deny_ptrace. L'objectif est que tout processus ne puisse examiner la mémoire d'un autre processus et ce, pour assurer une plus grande sécurité du système, même pour ceux qui utilisent une étiquette identique ou proche de l'autre processus à examiner. Pour l'administrateur système ou le programmeur qui en aurait besoin, il est possible de désactiver cette option pour l'usage du débogueur gdb par exemple. La désactivation se fait par la commande : setsebool deny_ptrace 0 ; l'activation quant à elle nécessite de remplacer le 0 par 1.

Il est maintenant possible d'utiliser les noyaux Linux cibles nommés LIO pour iSCSI et FCoE, le premier utilisant le stockage via des liaisons par TCP/IP quant au second cela est assuré par le protocole Fibre Channel sur un réseau Ethernet. Ceci passe par l'utilisation d'un nouvel outil de configuration qui est targetcli en remplacement de l'outil tgtd qui était plus complexe à configurer et un fichier de configuration plus difficile à appréhender. Par l'usage d'une API Python, il est également possible de programmer l’interaction avec targetcli.

mkdumprd est réécrit avec kexec-tools et l'utilitaire dracut pour générer l'initrd du noyau kdump. La génération d'un initrd est complexe, car cet outil doit participer au lancement du système avec le minimum d'outils à disposition et sans se planter, sinon il est impossible de démarrer tout le système. Or mkdumprd était complexe et nécessitait une lourde maintenance, d'où le passage à dracut qui réalise déjà cette tâche pour les noyaux classiques, les noyaux kdump permettant d'obtenir des informations de débogages supplémentaires. Ceci pourrait être réutilisé par d'autres distributions facilement, dracut étant déjà disponible sur d'autres distributions.

Sécurité et authentification

Suppression de ConsoleKit qui est la couche permettant de lister les utilisateurs connectés au système et permettant notamment la connexion de nouveaux utilisateurs depuis le gestionnaire de connexions graphique. Ce composant est remplacé par systemd. L'objectif affiché est de rendre cette partie du système plus sécurisée, petite et simple pour la maintenance. Cela introduit la prise en charge des multiutilisateurs automatiquement, mais aussi la possibilité d'autoriser le lancement de services utilisateurs sans la connexion de l'utilisateur en question via une tâche automatique par cron.

La possibilité d'utiliser une configuration multiutilisateur avec Linux existe depuis longtemps, mais a toujours exigé une configuration complexe. Pour la première fois, Fedora 17 fourni une configuration totalement automatique pour le multiutilisateur.
Pour utiliser cette fonctionnalité, il suffit de connecter une station d'accueil USB telle que la station d'accueil universelle, avec un écran, une souris et un clavier, et un nouvel environnement bureautique sera créé.
Pour plus d'informations sur cette nouvelle fonctionnalité, veuillez consulter les articles suivants :

Unification de la vérification de la sécurité des mots de passe par l'usage de la bibliothèque libpwquality. L'objectif est que tout logiciel demandant la création d'un mot de passe ait les mêmes limites que les autres quant à la qualité du mot de passe demandée. Ceci est configurable dans le fichier /etc/security/pwquality.conf. Cela facilitera la vie des administrateurs systèmes qui n'auront à changer qu'à un seul endroit la configuration de ces limitations.

SSSD monte en grade avec l'intégration de sudo et de l'autofs. SSSD est un ensemble de services pour réaliser ce que l'on appelle l'identification centralisée, très répandue dans les grandes entreprises. À la différence des méthodes traditionnelles, SSSD permet d'utiliser le compte distant en local sans avoir besoin du serveur central, c'est-à-dire qu'un utilisateur déjà authentifié sur une machine pourra éteindre la machine et l'utiliser sur un autre réseau avec le même compte utilisateur que celui utilisé précédemment. Le tout passant par le protocole LDAP. L'intégration de sudo permet d'importer également dans le cache de SSSD les paramétrages liés à sudo et de pouvoir les utiliser en mode hors-ligne, comme pour les utilisateurs traditionnels. L'intégration de AutoFS permet de monter automatiquement certains périphériques distants via Samba ou NFS par exemple en mode hors ligne. L'usage du cache SSSD permet d'économiser des requêtes LDAP pour les obtenir si on est en mode connecté.

Surveillance système et autres applications

Création de thermostat, une application permettant de faire du contrôle de mesures de plusieurs instances de machines virtuelles Java (et donc des applications Java) mais aussi pour réaliser de la configuration de ces dernières. Pour le moment, l'application se limite seulement aux machines virtuelles locales. Les machines virtuelles libres IcedTea/OpenJDK sont prises en charge. Une interface graphique est également disponible, le prise en charge du cloud se fera dans les prochaines versions de l'utilitaire.

Apparition du démon numad qui surveille la topologie et la consommation des processus pour réaliser un alignement mémoire des applications ou des machines virtuelles pour de meilleures performances.

Remplacement de dm-snapshot par thin-provisionning. Cet outil permet de créer des clichés d'un disque virtuel, comme une partition, et de les mettre dans le même volume que tous les autres clichés dans le but de réduire l'occupation disque et de favoriser les partages de données entre les machines virtuelles. Il est dorénavant possible de déterminer une profondeur de clichés de manière récursive (donc le nombre de clichés de clichés de clichés, etc. à réaliser au maximum). Il est possible de sauvegarder les métadonnées associées en dehors du volume considéré, notamment en les mettant sur un disque SSD pour de meilleures performances.

Apport de DIET au sein de la distribution. DIET est un intergiciel pour l'informatique de haute performance dans des environnements hétérogènes et distribués comme les stations de travail, les clusters, les grilles ou le cloud. Il implémente le standard OGF Grid RPC. Cet ensemble d'outils permet de gérer les utilisateurs et leur authentification, de gérer les tâches et les fichiers de manière sécurisée et de gérer les flux d'information. DIET peut par exemple déterminer quelles machines sont les plus aptes à répondre à la requête d'un client de part la répartition des données et la charge actuelle de chaque machine de la grille. Le tout en donnant une estimation du temps de traitement pour chaque machine. L'architecture est redondante et hiérarchisée pour limiter l'engorgement du système et éviter la perte de données. DIET est un projet français de recherches de l'INRA notamment et proposé sur Fedora par le contributeur francophone Haïkel Guémar.

Le domaine des clusters s'améliore avec la prise en charge de la haute disponibilité et la répartition de charge pour le Corosync Cluster Engine. Son API est stable pour la branche 2.0 nouvellement créée avec l'amélioration des performances d'un facteur 5 à 10 par rapport à la version précédente.

Virtualisation

Amélioration de la gestion des supports de stockage pour les clients virtualisés de part l'usage de fonctionnalités avancées de SCSI par KVM. Il est possible maintenant de dépasser la limite des 30 supports de stockage que nous pouvons librement brancher à chaud. De plus, les applications pourront s'adresser au périphérique directement par la prise en charge du « SCSI passthrough » et les clients et serveurs pourront accueillir de nouvelles fonctionnalités sans nécessiter la mise à jour des pilotes correspondants. Ces fonctionnalités feront l'objet d'un patch pour le noyau Linux 3.4.

Le Projet Fedora a élaboré la commande virt-sandbox pour mettre un service ou une application dans un bac à sable d'une machine virtuelle et reprend le principe du bac à sable de SELinux dans la mise en œuvre. Cet environnement confiné donne une vue adaptée du système du fichier et du réseau afin d'améliorer la sécurité globale, d'autant plus que les applications peuvent adresser, d'après le paragraphe précédent, des requêtes SCSI directement (passthrough). Actuellement n'est supporté que l'hyperviseur KVM mais suivront prochainement VMware et Xen.

Toujours dans le camp KVM, la mise en place d'un moniteur de performance pour les systèmes clients. cela permet grâce à des outils plus standards de suivre le fonctionnement du système et de ses paramètres et de faciliter le débogage en cas de problème.

Inclusion du projet oVirt. L'objectif est de diversifier l'offre des services de virtualisation libres au sein de Fedora car libvirt avec KVM est actuellement à une place très privilégiée. Ainsi l'industrie, mais aussi les utilisateurs, ont plus de choix selon leurs besoins et un grand travail a été effectué pour permettre une meilleure intégration possible avec les outils standards de Fedora. Les fonctionnalités de base du projet sont la gestion d'un cloud, des capacités de stockage et du réseau. Pour les machines virtuelles, la possibilité de réaliser des clichés, la détermination de sa durée de vie initiale et la migration des machines virtuelles. Avec bien entendu des outils de manipulation pour l'utilisateur ou l'administrateur y compris en ligne de commande et la prise en charge des agents clients. Pour finir, cette solution dispose d'un serveur d'authentification centralisé, de serveurs DNS et DHCP et les outils pour réaliser de la haute disponibilité.

Pour améliorer la gestion réseau des systèmes virtualisés, le Projet Fedora a travaillé sur l'intégration de Open vSwitch. Cet outil permet de concevoir des commutateurs virtuels pour faire la liaison au sein d'un réseau entre machines virtuelles et réelles là ou les solutions existantes posent des difficultés techniques sur des réseaux si complexes. L'objectif de ce projet est de se rapprocher d'un véritable switch pouvant être administré et concurrencer les solutions proches de VMware et Cisco dans le domaine.

Cloud Computing

Le cloud computing est un domaine informatique en plein essor et le Projet Fedora souhaite suivre cette tendance en améliorant les outils disponibles.

Fedora 16 a donné lieu à la disposition du Condor Cloud, Fedora 17 propose désormais d'apporter l'outil Wallaby pour programmer en haut niveau la configuration des services de gestion de Condor. Ceci va faciliter la configuration de ce dernier, Wallaby est basé sur un modèle sémantique, il peut gérer les versions des configurations (par les clichés et contrôle des versions) et il peut s'utiliser à distance via une API orientée-objet et s'interfacer avec les langages Python et Ruby.

OpenNebula arrive dans Fedora 17 pour gérer les infrastructures clouds hétérogènes et des serveurs physiques différents. Ce framework est compatible actuellement avec Amazon EC2, OGF OCCI et vCloudet mais aussi les hyperviseurs Xen, KVM et VMware. Il peut être utilisé via une interface en ligne de commande, une interface web ou encore les langages de programmation Python, Java et Ruby ce qui le rend particulièrement souple et efficace.

De même, OpenStack a été la source de toutes les attentions au sein de cette 17ème version de Fedora. Tout d'abord, le programme est porté à sa nouvelle version nommée Essex qui apporte une plus grande stabilité et intégration des composants, un système de greffons plus puissant, la possibilité de réaliser une authentification centralisée mais aussi de réaliser un meilleur suivi du système sans oublier une meilleure protection des données, surtout après un arrêt brutal du système. Mais cela ne s'arrête pas là, Horizon, l'interface web est inclue maintenant sur Fedora. L'objectif est de pouvoir lancer, arrêter ou suivre une instance de OpenStack et de gérer les utilisateurs par une interface graphique distante. Pour les prochaines versions, une meilleure documentation et configuration par défaut seront à l'étude. Puis le service des réseaux virtuels, nommée Quantum, est également pris en charge et peut à l'aide de greffons, réaliser des réseaux virtuels L2 à l'aide de Open vSwitch (décrit plus haut), le noyau Linux ou certains produits Cisco. Toujours pour OpenStack, Fedora a travaillé pour que OpenStack puisse utiliser libguestfs pour utiliser différentes opérations sur des disques virtuels et augmenter le nombre de formats supportés. Pour finir la partie sur cette solution de Cloud, OpenStack peut enfin utiliser Qpid pour l'échange de messages entre différents nœuds de OpenStack de manière alternative à RabbitMQ utilisé actuellement permettant plus de choix sur ce besoin.

Développement

Le Projet Fedora met tout en œuvre pour être une distribution phare des développeurs en mettant à leur disposition les derniers outils existants.

Pour commencer, la célèbre suite de compilateurs GCC a été mis à jour à la version 4.7 et l'ensemble des paquets ont été conçus par cette dernière. Cette version propose la prise en charge expérimentale de la mémoire transactionnelle pour le domaine de la programmation concurrente, des optimisations pour les derniers nés de l'architecture x86_64, la prise en charge du Cortex-A7 pour l'architecture ARM, diverses optimisations pour l'architecture SPARC et la prise en compte de certaines nouveautés des nouvelles normes C11 et C++11. Et bien d'autres encore !

Pour ceux qui sont intéressés par la compilation croisée à destination de Windows, Mingw-w64 propose la compilation d'exécutable pour Windows 32 ou 64 bits, au choix de l'utilisateur.

Un analyseur statique des erreurs dans les extensions de Python écrites en C a été conçu. En effet, ces modules en C peuvent gérer les références des objets de Python pouvant provoquer un certain nombre de fuites mémoire ou d'accès illicites à une case mémoire. Cet outil peut détecter ces problèmes et faire le lien avec le code problématique afin de patcher plus rapidement le code responsable et améliorer la situation.

Les amateurs de Ruby pourront utiliser la version 1.9.3 de ce langage avec une nouvelle ligne de conduite pour empaqueter les paquets liés à ce langage comme ses extensions. RubyGems peut être plus facilement installé par les utilisateur classiques dans leur propre répertoire. Cette version de Ruby permet l'ajout de code sous licence Ruby ou BSD (et non plus GPLv2), une meilleure prise en charge du multi‐threading, un chargement plus rapide des bibliothèques et la prise en charge de l'Unicode 6.0.

La célèbre bibliothèque du langage C++, Boost, arrive en version 1.48. Les bibliothèques d'Asio, Chrono, Geometry et Math étant les plus modifiées avec notamment une amélioration des performances pour certaines.

Pour les langages plus « exotiques », le langage D poursuit sa progression au sein du Projet Fedora. Il est maintenant possible de concevoir des interfaces avec GTK et OpenGL ou encore utiliser SQLite pour les bases de données. Le compilateur a également été mis à jour.

Java

Parmi les langages connus, Java 7 remplace désormais la version 6 avec la machine virtuelle libre OpenJDK 7.0. La machine virtuelle supporte les langages typés dynamiquement, la prise en charge de Unicode 6.0, une meilleure prise en charge de l'accélération XRender pour les interfaces graphiques Java 2D, l'arrivée d'un nouveau synthétiseur de son et bien d'autres nouveautés.

Pour continuer dans la lignée de Java, JBoss AS7, qui est un serveur d'applications Java EE, est aussi disponible, souvent mis en avant dans les offres Red Hat. Le temps de démarrage passe ainsi de 45 à 5 secondes environ grâce à l'indexation de métadonnées et l'usage de cache. Il utilise au repos moins de 20 Mio de mémoire contre plus de 100 pour son prédécesseur en minimisant les temps de pause du garbage collector et en ne chargeant que les archives jar nécessaires. Le tout devient plus modulaire en ne chargeant que les classes nécessaires et en isolant les applications. La configuration est maintenant plus simple et élégante en centralisant les options et se centrant sur l'utilisateur.

Pour finir avec le langage d'Oracle, l’environnement de développement Eclipse Juno est disponible. Cette version n'est pas encore totalement stable et devrait être publiée fin juin de cette année.

Langages fonctionnels

Pour les amateurs du langage fonctionnel Erlang, ce langage passe à la version R15. Une nouvelle interface graphique permet de faciliter le traçage du comportement des applications de ce langage. Il met à disposition une nouvelle implémentation du SSL, les exceptions précisent maintenant la ligne et le fichier concernés ce qui facilite grandement le débogage ou le rapport d'erreur.

Pour ceux qui préfèrent le langage Haskell, c'est la version 2011.4 qui débarque pour la plateforme Haskell. Ce dernier étant un ensemble d'applications pour programmer de manière confortable en Haskell.

Développement web

Pour les développeurs web, PHP 5.4 arrive également sur Fedora qui intègre notamment un mini serveur web pour le développement, une amélioration notable des performances, un nettoyage des options de configuration, des changements syntaxiques notamment pour la gestion des tableaux et plein d'autres choses !

Puis le langage Opa 0.9 arrive. Ce langage est destiné à réaliser des applications web riches, distribuées et sécurisées ou des applications de base de données. Cette plate-forme est tout-en-un, en permettant une exécution complète avec simplement un système d'exploitation fonctionnel. Cette version apporte entres autres, une nouvelle syntaxe plus proche du JavaScript, le support de nombreuses possibilités du HTML5 et le support de MongoDB pour la gestion de base de données. De manière plus générale, cette plate-forme fonctionne enfin sous Windows et FreeBSD en plus de Mac OS X et GNU/Linux, déjà pris en charge.

Infrastructure du Projet Fedora

Enfin, pour finir avec cette partie liée au développement, le Projet Fedora fournit le service darkserver. Ce service est destiné à aider les utilisateurs à trouver des informations à partir d'un build-id ou du nom d'un paquet RPM. Darkserver utilise un format json pour être plus facilement compréhensible par d'autres programmes et réaliser l'interrogation du serveur SQL contenant les informations. Ce service est intégré à l'infrastructure du Projet Fedora, notamment dans l'interface web de Koji pour les empaqueteurs. Par exemple, si vous souhaitez obtenir des informations sur le build-id « aa995549415cd52a6fbbc21811dfc2dd00e2c242 », sa sortie sera « {"buildid":"aa995549415cd52a6fbbc21811dfc2dd00e2c242","elf":"/usr/lib/mailman/pythonlib/japanese/c/_japanese_codecs.so","rpm":"mailman-2.1.12-17.el6.x86_64.rpm"} ».

Les méthodes de conception et d'installation des LiveCD de Fedora ont été revues de part l'utilisation de lorax. Lorax permet de créer des CD d'installation à partir d'Anaconda, le logiciel d'installation de Fedora, et de ses dérivées. Actuellement, la conception d'un liveCD nécessite de lourds travaux sur lorax, Anaconda, python-imgcreate et livecd-creator, l'objectif serait de se passer des deux derniers ce qui allégerait la procédure, introduirait moins d'anomalies et permettrait d'étendre les fonctionnalités, le système devenant plus simple.

Mises à jour majeures de logiciels

Voici la liste des mises à jour majeures des paquets de Fedora avec les liens vers leurs notes de versions :

  • # Posté depuis un ordi sous fedora17

    Posté par . Évalué à  7 .

    Merci pour cette dépêche qui relate très bien tout le travail de fond et de forme qui a été effectué sur cette nouvelle version de fedora. D'après l'info sur systemd, est ce qu'il est a présent possible, et facile, de lancer un programme en tant que démon, par exemple rygel (partage upnp/dlna), au démarrage de la machine et avec les bons droits?

  • # HFS

    Posté par . Évalué à  7 .

    Le plus gros travail dans ce domaine était le déplacement de la racine (/) vers le dossier user (/usr) entrainant la disparition des répertoires /bin, /sbin, /lib et /lib64. Ces répertoires étaient présents pour des raisons historiques et techniques qui n'ont plus lieu d'être aujourd'hui. /usr est un dossier qui était aujourd'hui indispensable et la séparation des 4 dossiers de /usr posait des problèmes techniques pour la séquence de démarrage avec initramfs qui avait besoin de nombreux logiciels pour son exécution et qui sont un peu dispersés dans tous ces répertoires, répertoires qui ne sont pas montés au même instant en général. Cette séparation va entrainer un certain allègement du démarrage du système, mais aussi améliorer la compatibilité avec d'autres Unix comme Solaris qui ont déjà opéré ce changement, la gestion des paquets s'en trouvera également simplifiée. En effet, il n'y aura plus de cas particuliers à gérer, tout ira dans le même dossier, sans risque de confusion à l'usage. Pour migrer en douceur, les répertoires par défauts sont maintenant des liens symboliques vers leurs successeurs dans /usr.

    Je présume qu'ils ont gardés des liens symboliques pour compatibilité, mais faudra pas les supprimer ces liens parce que si je ne m'abuse POSIX définie #!/bin/sh comme shell pour les scripts (à moins qu'il faille utiliser #!/usr/bin/env).

    Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

    • [^] # Re: HFS

      Posté par . Évalué à  2 .

      Ya aussi le chemin "/lib/ld-linux.so.2" qui est hardcodé dans le noyal ou quelque chose comme ça (je connais mal les mécanismes de link dynamique), enfin qui est vraiment impossible à changer quoi, c'est comme une ABI.

      • [^] # Re: HFS

        Posté par (page perso) . Évalué à  7 .

        ld-linux.-so.2 est hard-codé selon une configuration du compilateur (gcc) lors de son bootstrap (compilation de gcc pour avoir un autre gcc). Il est donc tout à fait possible de modifier /lib/ld-linux.so.2 pour le faire passer sous /usr/lib (le même type de problème s'était posé pour les différentiations entre /lib, /lib32 et /lib64).

        • [^] # Re: HFS

          Posté par (page perso) . Évalué à  1 .

          Oui c'est ça, merci de la précision. ;-)
          Je pense tout de même que si l'équipe de Fedora a décidé d'en faire une nouveauté principale de cette version et a jugé l'objectif rempli, c'est bien que les petites difficultés de ce type ont été corrigées, d'une manière ou d'une autre.

      • [^] # Re: HFS

        Posté par . Évalué à  4 .

        /lib/ld-linux.-so.2 est dans l'en-tête de l'exécutable ELF.

        Il vaut mieux ne pas changer ce chemin d'accès si on veut copier les binaires d'une distro à une autre.

    • [^] # Re: HFS

      Posté par . Évalué à  6 .

      Il y a eu un très gros thread à ce sujet sur la ML des devs de Gentoo, une bonne partie n'étant pas spécialement pour le déplacement de /bin, /lib etc dans /usr parce que ça cassait toutes les installations avec un /usr séparé sans initramfs pour le monter (ah bah oui, on fait comment pour monter la partition sans /bin/mount ?), sans parler du fait que ce n'est pas conforme au FHS qui, étant peut-être d'une clarté discutable sur ce qui doit être dans /bin et qui doit être dans /usr/bin, fixe quand même quelques principes.

      Au final toutes les distributions seront forcées de suivre l'exemple de Fedora car udev ne fonctionnera plus sinon (je ne me souviens plus des raisons exacte). Il apparaît en fait que les devs d'udev sont les même que que ceux qui ont poussé Fedora sur cette voie, de façon plus ou moins unilatérale. Cette situation est loin de plaire à tout le monde, d'autant qu'un fork d'un projet de la complexité et de l'importance d'udev n'est pas envisageable, ce qui signifie que les autres distributions devront se plier à leurs décisions.

      Je me demande encore quel est l’intérêt de tout migrer vers /usr, puisque les dossiers /lib, /bin et /sbin ne disparaîtrons pas, il y a trop de scripts avec des chemins hardcodés dedans, /bin/sh en est un bon exemple, pour que quiconque soit assez fou pour en imposer le retrait définitif. Les symlinks vont rester très, très, très longtemps…

      • [^] # Re: HFS

        Posté par . Évalué à  -1 .

        Je me demande encore quel est l’intérêt de tout migrer vers /usr

        Je dirais que un dev RH a (encore) fumer de la moquette pas propre. Apres que cela casse les autres distribs ce n'est qu'un dommage collateral qui n'est que tres apprecie et ne parlons meme pas du fait que ca va probablement foutre en l'air les autres Unix mais la encore que du tout bon.

        Tout ca pour booter 2 secondes plus vite…

        • [^] # Re: HFS

          Posté par . Évalué à  1 .

          Je dirais que un dev RH a (encore) fumer de la moquette pas propre.

          Tout ca pour booter 2 secondes plus vite…

          Sauf que RH bosse pour ses clients, pas pour toi. Si ses clients lui ont demandé un OS qui boote plus vite, RH va travailler dessus.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: HFS

            Posté par . Évalué à  3 .

            Mais bien sur un client a demande:

            "Je veux que ca boot plus vite et surtout oubliait pas de tout casser la compatibilite en meme temps."

            Amusant tres amusant.

            • [^] # Re: HFS

              Posté par . Évalué à  4 .

              J'avais oublié, toi tu sais tout mieux que tout le monde, tu connais tous les clients de RHEL de par le monde et tu es forcément au courant de leurs demandes.

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: HFS

            Posté par . Évalué à  6 .

            Et chez Fedora ils travaillent pour RH, c'est ça ? Ils tentent de vendre le fait qu'ils sont communautaire, mais ils ne le sont que quand les autres sont d'accord avec eux ?

            Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

            • [^] # Re: HFS

              Posté par . Évalué à  4 .

              Et chez Fedora ils travaillent pour RH, c'est ça ?

              Bah vu qu'une bonne partie ont des adresses email en @redhat.com, il y a des chances.

              Au hasard, tu prends le comité technique de Fedora, tu as six membres sur neuf qui bossent chez RH.

              Ils tentent de vendre le fait qu'ils sont communautaire, mais ils ne le sont que quand les autres sont d'accord avec eux ?

              Je n'ai jamais dit qu'ils n'étaient pas communautaires, d'ailleurs ils bossent autant que possible avec l'upstream.

              Mais ça n'empêche pas de faire des choix au bénéfice de RH.

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

              • [^] # Re: HFS

                Posté par (page perso) . Évalué à  2 .

                Et chez Fedora ils travaillent pour RH, c'est ça ?

                Bah vu qu'une bonne partie ont des adresses email en @redhat.com, il y a des chances.

                Au hasard, tu prends le comité technique de Fedora, tu as six membres sur neuf qui bossent chez RH.

                En même temps le bureau est composé à la majorité de personnes issues de la communauté (et c'est un principe, pas seulement la situation actuelle)

                Matthieu Gautier|irc:starmad

                • [^] # Re: HFS

                  Posté par (page perso) . Évalué à  2 .

                  De toute façon ils ont un pouvoir limité aux grandes orientations du Projet, pour les choses plus techniques et pratiques c'est d'autres organisations qui prennent le relais et où la communauté est encore plus présente.

                  De plus, tout le monde peut travailler pour le projet Fedora pour y tester des concepts intéressants, ce n'est pas réservé uniquement à Red Hat et ses employés, tout le Libre peut en profiter car c'est l'objectif même du projet !

          • [^] # Re: HFS

            Posté par . Évalué à  1 .

            Amusant ça me rappelle Ulrich Drepper :)

        • [^] # Re: HFS

          Posté par (page perso) . Évalué à  4 .

          Tout ca pour booter 2 secondes plus vite…

          Les raisons sur le sujet sont bien plus complexes que de booter seulement 2 secondes plus vite. La séquence de démarrage de ta machine est très complexe et la situation avant la fusion des dossiers était très difficile à gérer pour ceux qui s'en chargeaient. Et pour les machines plus complexes qu'un PC (où le disque dur local n'a pas toutes les données par exemple) cela devient encore plus problématique.

          De plus, Solaris a fait la même chose et c'est Sun qui l'a décidé (et vu l'importance pour eux du marché professionnel ça peut s'expliquer), est-ce pour autant que le monde s'est effrondé avec cette situation ? Pas du tout, ça demande une adaptation mais ça viendra avec le temps.

          • [^] # Re: HFS

            Posté par (page perso) . Évalué à  2 . Dernière modification : le 30/05/12 à 19:52

            Les raisons sur le sujet sont bien plus complexes que de booter seulement 2 secondes plus vite. La séquence de démarrage de ta machine est très complexe et la situation avant la fusion des dossiers était très difficile à gérer pour ceux qui s'en chargeaient.

            Bof… On avait un init qui fonctionnait bien avant. Et puis systemd est arrivé, je ne dis pas que ce n'est pas bien, au contraire. Mais ce qui est énervant, c'est que c'est pas fini! J'adore Fedora, mais je trouves extrêmement pénible de faire des bonds, des sauts de 20 mettres de haut ou du skydiving tous les 6 mois ou de se dire tout simplement que la distribution à une chance sur 2 de ne plus rebooter à chaque releases pour des bêtes trucs… Y a pleins de petits trucs comme ça. Mais voilà quoi, ça ne m'étonerais pas que rh fasse ça pour vendre ses solutions desktop, je me suis fait avoir moi! :p

            Le problème de fedora et à mon avis pour beaucoup de gens, c'est que c'est une distribution qui évolue trop vite, et trop en profondeur en imposant des choix.

            • [^] # Re: HFS

              Posté par (page perso) . Évalué à  2 . Dernière modification : le 30/05/12 à 19:59

              Le problème de fedora et à mon avis pour beaucoup de gens, c'est que c'est une distribution qui évolue trop vite, et trop en profondeur en imposant des choix peut-être un peu trop rapidement ou trop vite… Les choix ne sont pas forcément mauvais en soit ;)

              T'as même pas le temps de découvrir tranquillou la "technologie", "ou les choix qu'ils font" que tout est déjà presque obsolette 6 mois après.

              • [^] # Re: HFS

                Posté par . Évalué à  -2 .

                Fedora c'est Fedora, avec ses objectifs.

                Pour être brutal, ce n'est pas l'utilisateur final de Fedora qui indique la pertinence d'une distribution comme Fedora.
                Si Fedora était foireux, si Fedora ne respectait pas ses objectifs, Fedora n'aurait pas d'impact sur les autres distributions. C'est le contraire qu'on voit, donc c'est une distribution géniale.

                Mais, Fedora n'est pas pour tout le monde. Maintenant la distribution est assez connue, il y en a qui devraient passer leur chemin. Mais ils préfèrent critiquer…

                • [^] # Re: HFS

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

                  Pour être brutal, ce n'est pas l'utilisateur final de Fedora qui indique la pertinence d'une distribution comme Fedora.

                  Bien sur que si :) Tu vas te mettre à utiliser une distribution un certain temps, et si ta distribution commence à crachouiller pour des broutilles, tu vas partir…

                  Si Fedora était foireux, si Fedora ne respectait pas ses objectifs, Fedora n'aurait pas d'impact sur les autres distributions.

                  Ha bon ? Et Fedora à quel impacte sur les autres distributions ? On a de la chance dans le monde "linux" que les "créateurs de distributions" collaborent entre eux. Tu retrouveras des mecs qui bossent chez Red Hat et qui sont développeurs Debian.

                  Mais ils préfèrent critiquer…

                  Je critiques parce que j'adore Fedora, c'est une excellente distribution. Mais si on pouvait un peu éviter les conneries de développeurs zélés, ça arrangerait. Fedora a un potentiel énorme. C'est bêtes de casser la moitier de la distro pour le plaisir de sortir des distributions…

                  Moi ça me fait chier d'avoir une interface réseau nommée "p4p1" ou d'avoir la moitier des services qui ne fonctionnent pas avec "chkconfig". C'est le genre de petits trucs qui fache. Je suis passé sous rhel parce que ça ne m'intéresse pas d'avoir de nouveaux trucs et 32 mises-à-jour dans ma distribution tous 3 jours. Mais encore une fois, j'adore Fedora, c'est une excellente distribution ;)

                  • [^] # Re: HFS

                    Posté par (page perso) . Évalué à  1 .

                    ça ne m'intéresse pas d'avoir de nouveaux trucs et 32 mises-à-jour dans ma distribution tous 3 jours. Mais encore une fois, j'adore Fedora, c'est une excellente distribution ;)

                    C'est que tu n'as pas compris la philosophie de Fedora alors, qui est d'être leading-edge, et donc par conséquent aussi bleeding edge : en intégrant les toutes dernières technologies en grandeur nature, y a forcément des bugs qui apparaissent.

                    « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

            • [^] # Re: HFS

              Posté par (page perso) . Évalué à  7 .

              Le problème de fedora et à mon avis pour beaucoup de gens, c'est que c'est une distribution qui évolue trop vite, et trop en profondeur en imposant des choix.

              C'est un peu son objectif affiché.
              Ne serait-ce pas certains utilisateurs qui se sont trompé de distro et on juste oublié de lire l'objectif de Fedora pour voir que ce n'est pas en phase avec leur besoin?

              Si tout casser tous les 6 mois ne te plait pas, ben… Prend autre chose que Fedora! Par exemple, une distro basée sur Fedora et maintenue 10 ans : RHEL (ou CentOS pour les fauchés). Tu ne casseras des choses que tous les 10 ans.

              Bref, le mieux pour les utilisateurs est peut-être de savoir choisir une distro adaptée à ses besoins, pas de se plaindre d'avoir choisi une distro qui ne répond pas à ses besoins puis de se plaindre qu'elle ne répond pas aux besoin mais qu'elle fait ce qu'elle a dit qu'elle fait la méchante.

              • [^] # Re: HFS

                Posté par . Évalué à  1 .

                C'est un peu ma vision du schmilblick. J'utilise fedora sur une ou des machines ou je sais que je peux rendre mon système inutilisable sans soucis, mais pour les machines qui sont en prod la j'utilise des distribs plus stables. Cela me semble logique.

                Ceci dit j'ai fais la mise à jour d'une de mes machines sous fedora 16 vers fedora 17 et j'ai pas eu de soucis.

        • [^] # Re: HFS

          Posté par . Évalué à  -4 .

          Taper sur Red Hat et encore sur Red Hat, c'est si facile.

          Si les gens n'en veulent pas, qu'ils forkent.
          On en trouve 10 000 pour critiquer et pas un pour se sortir les doigts du cul.

          • [^] # Re: HFS

            Posté par . Évalué à  2 .

            Si les gens n'en veulent pas, qu'ils forkent

            forker quoi ? Il dis qu'il n'aime pas ce changement. Il reste probablement sans ces changements avec une autre distribution.

            Surtout que pour le coup c'est RH qui « forke » HFS.

            Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

      • [^] # Re: HFS

        Posté par (page perso) . Évalué à  7 .

        • [^] # Re: HFS

          Posté par (page perso) . Évalué à  0 .

          Peut-être que j'ai loupé une explication, mais pourquoi on n'en profite pas pour arrêter avec une différentiation bizarre entre /bin et /sbin (parce que j'ai du mal à suivre le "static" de sbin aujourd'hui en tous cas), bref pourquoi /sbin ne profiterai pas pour pointer sur /usr/bin quitte à faire du ménage?

          Les méandres du filesystem Linux sont parfois très cryptiques… (vu que /bin et /sbin sont déjà tous les deux dans la path, j'ai du mal à suivre l’intérêt de cette séparation)

          • [^] # Re: HFS

            Posté par . Évalué à  7 . Dernière modification : le 31/05/12 à 10:09

            Non, Le s de sbin signifie system.

            la différenciation de /bin et /sbin vient du fait que /sbin contient les binaires réservés à l'administrateur auxquels les utilisateurs normaux n'ont pas besoin d'avoir accès (useradd, fsck, ifconfig, etc). D'ailleurs, /sbin (et /usr/sbin) n'est dans $PATH que pour root.

            C'est écrit sur Wikipédia, mais comme je me doute que tu vas me dire que ce n'est pas fiable, je vais aussi te donner la référence utilisée par l'article :-)

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: HFS

              Posté par . Évalué à  2 .

              D'ailleurs, /sbin (et /usr/sbin) n'est dans $PATH que pour root.

              Il y a des distributions qui le mettent pour tout (je présume que c'est par exemple le cas pour celles qui n'ont plus d'utilisateur root).

              Pour le reste totalement d'accord.

              Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

              • [^] # Re: HFS

                Posté par . Évalué à  1 .

                Par curiosité, quelles sont ces distributions qui font ça ?

                J'ai du mal à imaginer un système sans root :-/

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                • [^] # Re: HFS

                  Posté par (page perso) . Évalué à  3 .

                  ubuntu n'a pas de password pour root par défaut, c'est l'utilisation de sudo qui est recommandée.

                  « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                  • [^] # Re: HFS

                    Posté par . Évalué à  2 .

                    L'utilisateur root existe toujours sous Ubuntu, il est juste innaccessible par défaut avec un mot de passe. Mais si tu fais un sudo passwd, tu peux lui en donner un.

                    De plus, /sbin n'est pas dans le $PATH pour tous les utilisateurs ; en tout cas, c'était le cas la dernière fois que j'ai utilisé Ubuntu il y a bien deux ans, ça a peut-être changé mais ça m'étonnerait quand même.

                    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                    • [^] # Re: HFS

                      Posté par (page perso) . Évalué à  3 .

                      L'utilisateur root existe toujours sous Ubuntu

                      Je n'ai pas dis le contraire.

                      De plus, /sbin n'est pas dans le $PATH pour tous les utilisateurs ; en tout cas, c'était le cas la dernière fois que j'ai utilisé Ubuntu il y a bien deux ans, ça a peut-être changé mais ça m'étonnerait quand même.

                      Je n'ai pas testé ça.

                      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                      • [^] # Re: HFS

                        Posté par . Évalué à  3 .

                        L'utilisateur root existe toujours sous Ubuntu
                        Je n'ai pas dis le contraire.

                        Toi non, par contre c'est ce qui était dit dans ce commentaire dont la réponse (à laquelle tu répondait toi-même) demandait quelles distributions n'avais pas d'utilisateur root.

      • [^] # Re: HFS

        Posté par (page perso) . Évalué à  1 .

        Il apparaît en fait que les devs d'udev sont les même que que ceux qui ont poussé Fedora sur cette voie, de façon plus ou moins unilatérale.

        Donc c'est les dev d'udev qui veulent tout migrer vers /usr, pas vraiment Fedora ?

        Dans ce cas les autres distrib sont obligées de suivre udev, pas Fedora. Fedora n'est que la première à le faire.

        Matthieu Gautier|irc:starmad

        • [^] # Re: HFS

          Posté par . Évalué à  4 .

          Beaucoup des devs d'udev sont en fait des employés de RH qui bossent parfois aussi sur Fedora. Du coup sur cette décision, faire la distinction n'a pas vraiment de sens.

          • [^] # Re: HFS

            Posté par (page perso) . Évalué à  1 .

            Bah, ça aurait autant que de dire "une majeur partie des devs d'udev sont blonds, donc on a pas besoin de faire la distinction". Les devs sur Fedora sont relativement libres de leur choix, et si tu regardes un peu les archives des listes, tu va voir que même dans les gens avec un email @redhat, tout le monde n'est pas d'accord avec le choix. Tout comme tout le monde sans email @redhat n'est pas d'accord, ou comme tout le monde n'est pas contre.

            Tu va voir aussi que les discussions ont comencés avant que le mainteneur d'udev quitte novell/suse pour aller chez RH.

      • [^] # Re: HFS

        Posté par (page perso) . Évalué à  2 .

        Il y a une tentative de fork avec mdev, mais ce n'est pas encore au niveau (ça marche mal avec lvm2 apparemment).

  • # Typo

    Posté par (page perso) . Évalué à  3 .

    "les extensions de Python écrites en C"

    Vous pouvez supprimer ce commentaire après correction, merci.

    • [^] # Re: Typo

      Posté par (page perso) . Évalué à  3 .

      Corrigé, merci.

    • [^] # Re: Typo

      Posté par . Évalué à  3 .

      De même : «La désactivation se fait par la commande : setsebool deny_ptrace 0 ; la désactivation quant à elle nécessite de remplacer le 0 par 1.»

      L'activation, non ?

      • [^] # Re: Typo

        Posté par . Évalué à  3 .

        « OpenStack a été la source de toutes les intentions au sein de cette 17ème version de Fedora »

        -> Attentions

  • # Très fort

    Posté par (page perso) . Évalué à  10 .

    L'intégration de AutoFS permet de monter automatiquement certains périphériques distants via Samba ou NFS par exemple en mode hors ligne.

    Même quand il n'a pas le réseau, il arrive à télécharger les répertoires distants, c'est vraiment un système très intéressant. Il ne manque plus que l'intégration d'IPoT pour la gestion de version.

    « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

    • [^] # Re: Très fort

      Posté par . Évalué à  4 .

      C'est le miracle du chien chaud!

    • [^] # Re: Très fort

      Posté par (page perso) . Évalué à  3 .

      Si j'ai bien compris le concept lors de mon étude sur le sujet. C'est que si le serveur LDAP n'est pas connecté, malgré tout il tentera de monter les points de montages d'un serveur NFS qui peut être distinct du serveur LDAP.

      Donc le hors-ligne est à prendre au sens « vis à vis du serveur LDAP » et non du reste.

      Voici l'une des phrases de la documentation disponible sur le sujet :
      > offline access - even though if the client cannot connect to the LDAP server chances are that the NFS server is unreachable as well

      • [^] # Re: Très fort

        Posté par (page perso) . Évalué à  3 .

        Ah, c'est dommage, j'espérais que ce soit plus un système de synchronisation pour avoir accès à une copie des répertoires distants quand on est pas connecté pour avoir quand même accès à ses documents. Enfin, c'est quand même intéressant mais moins.

        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

  • # Bravo !

    Posté par . Évalué à  9 .

    Excellente dépêche ! ;) Mes félicitations aux rédacteurs.

  • # Quelques remarques

    Posté par (page perso) . Évalué à  3 .

    Étant toujours en Fedora 14 sur mon portable de boulot, il va peut être falloir envisager une mise à jour du système…
    Fedora 17 propose t'il un Bureau GNOME 3 compatible GNOME 2 comme le mode GNOME legacy d'ubuntu 12.04 ?

    "Fedora avec sa version 17 signe la fin de la prise en charge des pilotes 3D DRI version 1. Ceci allège le code de Mesa en ne gérant plus les pilotes suivants : i810, mga, r128, savage, sis, tdfx et unichrome qui sont en règle général très peu utilisés aujourd'hui et plus maintenus depuis de nombreuses années."

    Cela fait des années que les système de suivi de bugs des distributions ont des rapports de bugs long comme le bras concernant les problèmes de fonctionnement des anciennes cartes graphiques. J'ai plein de vieux PC équipé de Matrox apte a rendre service si seulement je pouvais installer une distrib plus récente que 2008… Malheureusement, même en 2D ces cartes ne fonctionne plus ! Idem pour unichrome, problème en 2D. Pour surfer sur le Web avec ces machines avec la dernière version de Firefox, flash et compagnie, j'ai du réinstaller Windows 2000… triste !
    Dire que plus grand monde utilise ces cartes, c'est malheureusement parce que les devs ont supprimé le choix aux utilisateurs.

    "Il est maintenant possible d'utiliser les noyaux Linux cibles nommés LIO pour iSCSI et FCoE, le premier utilisant le stockage via des liaisons par TCP/IP quant au second cela est assuré par le protocole Fibre Channel sur un réseau Ethernet. Ceci passe par l'utilisation d'un nouvel outil de configuration qui est targetcli en remplacement de l'outil tgtd qui était plus complexe à configurer et un fichier de configuration plus difficile à appréhender. "

    AMHA tgt est plus facile et simple à mettre en œuvre pour du iSCSI. Son défaut est de tourner en mode utilisateur et donc d'être plus gourmand en ressource qu'un module en mode noyau.
    Cependant, j'ai testé LIO avec Ubuntu 12.04 et j'ai eu plein de problème de stabilité. Je suis revenu à tgt. De plus Targetcli et monstrueusement lourd à installer à cause de toutes ses dépendances. Avec Ubuntu ça ramène tout texlive sur le serveur !!! oO J'ai abandonné l'idée de l'utiliser…

    • [^] # Re: Quelques remarques

      Posté par (page perso) . Évalué à  5 .

      Étant toujours en Fedora 14 sur mon portable de boulot,

      Fedora 14 end-of-life date: 2011-12-08.
      Et après on dit que ce sont ceux qui sont sous Windows qui sont les inconscients pas doués en sécurité… Miam miam. Il y a un bon 6 mois de retard sur la migration à faire.

      • [^] # Re: Quelques remarques

        Posté par (page perso) . Évalué à  1 . Dernière modification : le 29/05/12 à 20:29

        Bha, dans le pire dès cas, si la stabilité prime à mort. Une bonne rhel (centos, scientific linux) ;)

        Ca doit pouvoir être fesable de migrer en rhel 6 sans trop de problème. J'avoue que sur une machine de boulot c'est pas le top.

    • [^] # Re: Quelques remarques

      Posté par (page perso) . Évalué à  6 .

      Non, c'est parce que les utilisateurs ne sont pas devenus mainteneurs que les drivers ont disparus. Le code est encore la dans le git, si tu veux le reprendre, tu peux. Tu peux aussi râler parce que quelqu'un n'a pas fait le taf bénévolement pour toi, mais tu va juste râler dans le vide, et tu va rien réussir de positif.

    • [^] # Re: Quelques remarques

      Posté par (page perso) . Évalué à  2 .

      il est toujours possible de forcer le mode dégradé … mais ce ne sera pas automatique parce que même vesa est compatible avec gnome-shell via llvmpipe.

  • # Beefy ?

    Posté par . Évalué à  3 .

    C'est pas du porc dans les hot-dogs ?

    • [^] # Re: Beefy ?

      Posté par (page perso) . Évalué à  10 .

      C'est dire si c'est miraculeux… Du porc appelé chien qui se convertit en bœuf.

    • [^] # Re: Beefy ?

      Posté par . Évalué à  3 .

      Ouais, tu devrais le signaler aux développeurs, ils vont corriger ça vite fait.

      Il se prend pour Napoléon, son état empire.

  • # Remarques

    Posté par . Évalué à  3 .

    Les services du système lancés par systemd peuvent obtenir des dossiers dans le répertoire /tmp avec des droits d'accès supplémentaires. L'objectif est de rompre la communication entre l'utilisateur et ces services pour éviter des problèmes de sécurité par le procédé d'escalade de privilège. En effet, un service pouvant obtenir des droits supplémentaires sur le système par rapport à l'utilisateur de base, l'usage à mauvais escient de cette communication pouvait permettre à un utilisateur de base d'obtenir ces droits supplémentaires.

    Je n'ai pas compris ce paragraphe :

    • quel est le lien entre la création dans /tmp et le fait de "rompre la communication avec l'utilisateur" ?

    • Quand on parle de "droits d'accès supplémentaires", ce sont les services qui ont le droit d'accéder aux dossiers ? Quel est le lien avec l'escalade de privilège ?

    DIET est un projet français de recherches de l'INRA notamment et proposé sur Fedora par le contributeur francophone Haïkel Guémar.

    Est-ce qu'il n'y a pas une confusion entre INRA et INRIA ? Je suis sûr que l'Institut National de la Recherche Agronomique a des projets logiciels, mais c'est quand même moins proche de son domaine de compétence, donc une erreur semble probable.

    • [^] # Re: Remarques

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

      je suis sûr que l'Institut National de la Recherche Agronomique a des projets logiciels

      Oh que si, je dois installer leurs merdes régulièrement, certifiées codées avec les pieds…

    • [^] # Re: Remarques

      Posté par (page perso) . Évalué à  1 . Dernière modification : le 01/06/12 à 10:01

      Est-ce qu'il n'y a pas une confusion entre INRA et INRIA ?

      Effectivement, DIET est développé principalement par l'équipe de recherche GRAAL, notamment rattachée à l'INRIA (recherche en informatique et automatique) et non pas à l'INRA (recherche en agronomie).

    • [^] # Re: Remarques

      Posté par (page perso) . Évalué à  2 .

      Le /tmp est séparé, ie le service démarre, il écrit dans /tmp , mais de façon transparente, c'est pas le même que celui des autres services et de l'utilisateur. Regarde http://0pointer.de/blog/projects/security.html

      Et le lien est si ton programme utilise une socket dans /tmp pour communiquer, tu ne la voit pas. Ou le bête problème de Linux Mint ( http://www.openwall.com/lists/oss-security/2012/03/19/14 ) qui va lancer un soft en root, et va faire des traitements dans /tmp, sans vérifier la présence de fichier déjà présent, etc.

  • # Toujours aussi 'mal fini'

    Posté par . Évalué à  3 .

    Va falloir attendre encore un peu avant que ca fonctionne reelement 'bien'…

    Eclipse Juno a ete installe…sauf que, a l'ouverture d'un projet certains composants graphiques plantent (on peut fermer et reouvrir la vue concernee pour que ca fonctionne) Les consoles n'affichent rien, et visiblement l'integration pour Valgrind s'arrete a l'installation du plugin…(imposible de parametrer le projet, on clique sur le bouton rien ne se passe…)

    Accessoirement que ce soit sur un poste fixe ou sur une machine virtuelle preupgrade foire (comme d'habitude je dirais maintenant, entre les problemes d'espace libre des versions precedentes, sa toujours totale incapacite d'estimer l'espace necessaire avant de lancer l'upgrade, et dorenavant, le fait qu'au reboot, l'upgrade ne continue pas…)

    Sisi 2013 sera l'annee du desktop….bouarf…

    • [^] # Re: Toujours aussi 'mal fini'

      Posté par . Évalué à  1 .

      Pour preupgrade qui ne reprend pas au reboot, est ce que tu aurais par hasard un partitionnement avancé, à base de raid ou de lvm, bref, un peu exotique? Il me semble que preupgrade a du mal à fonctionner dans ces cas là. Ça reste un bug, mais ça ne touchera pas grand monde.

      • [^] # Re: Toujours aussi 'mal fini'

        Posté par . Évalué à  1 .

        Nonpour preupgrade c'est une install par defaut (le seul truc un peu specifique sur le fixe c'est que je choisis dans le bios le disque dur…
        Accessoirement j'ai ausi teste le coup du kernel xxx, init xxx, et boot dans grub et ca plante (je pense que ca a a voir avec les changement d'arboresscence)…j'ai pas cherche plus loin, je vais plus vite a installer une image neuve a chaque fois….sur la machine virtuelle rien de special non plus…)

        Et pour les excuses 'Fedora est une distrib de test'…
        Ben j'essaye aussi Ubuntu de temps en temps, ca foire ailleurs….bref. (je prevenais surtout pour Eclipse, la seule raison pour laquelle j'utilise encore Linux c'est pour Valgrind, j'ai plus envie de perdre mon temps)

    • [^] # Re: Toujours aussi 'mal fini'

      Posté par (page perso) . Évalué à  1 . Dernière modification : le 30/05/12 à 12:30

      Va falloir attendre encore un peu avant que ca fonctionne reelement 'bien'

      C'est peut-être pas le public cible. Fedora, c'est devenu une branche de test pour redhat… C'est quand même une distribution à tweaker un petit peu. Je dirais même qu'il faut garder ça en tête quand on install Fedora. Une fois que c'est mit ça fonctionne.

      Je te dis, les mecs qui font Fedora, ils ne font que ça toute la journée… Dès qu'ils ont une idée, boum Fedora. ;)

      • [^] # Re: Toujours aussi 'mal fini'

        Posté par . Évalué à  1 .

        Fedora, c'est devenu une branche de test pour redhat

        En principe c'était le cas de fedora core mais pas de fedora qui est communautaire et tout et tout.

        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

        • [^] # Re: Toujours aussi 'mal fini'

          Posté par (page perso) . Évalué à  2 . Dernière modification : le 30/05/12 à 16:48

          En principe c'était le cas de fedora core mais pas de fedora qui est communautaire et tout et tout.

          Mouais… Red Hat est quand même fort présent dans Fedora tu sais :) Les gros composants de la distribution on les retrouvent dans la version entreprise et les 3/4 des trucs sont maintenus par des mecs qui travaillent chez red hat… Ils font tous les testes sur Fedora avant de les tappers dans rhel. Je sais pas si on pourait comparer ça à Debian, ou à Mageia ou a une distro vraiment "communautaire".

          Enfin bon les gens qui veulent une station de travaille, solide facile, c'est rhel. De toute façon, ça revient au même, c'est du Fedora 12/13 maintenu ;)

          J'ai toujours l'impression que Fedora, c'est un peu comme Debian dans le fond, limite la stabilité en moins parce que le cycle de développement n'est pas le même. Mais bon, ça n'engage que moi :)

          • [^] # Re: Toujours aussi 'mal fini'

            Posté par . Évalué à  5 .

            J'ai toujours l'impression que Fedora, c'est un peu comme Debian dans le fond, limite la stabilité en moins parce que le cycle de développement n'est pas le même. Mais bon, ça n'engage que moi :)

            Il y a quelques grosses différences :

            • la dernière version de Debian c'est Squeeze (6.0.5), les versions plus récentes sont considéré comme en développement et ne sont pas présenté autrement, tu mange un gros bug, t'es au courant
            • Debian cherche (mais on peut facilement trouver des contre exemples je parle de lignes directives) à apporter de l'aide en upstream et minimiser les modifications spécifique à la distribution. Au final le seul gros contre exemple que j'ai c'est la gestion du réseau. Cette philosophie se vois dans le fait que bien que n'utilise que Debian depuis quelques années, je ne connais que l'installeur et les outils de gestions de paquets qui sont spécifiques à Debian, pas d'outils de configuration super beau ++ comme c'est le cas pour mandriva par exemple. Un autre exemple c'est le wiki.debian.org dont l'une des règles consiste a ne mettre que des choses en rapport avec Debian (si tu veux expliquer comment configurer OpenSSH, ce seras supprimé et on te demandera de reporter cette explication dans la doc d'OpenSSH).

            Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

            • [^] # Re: Toujours aussi 'mal fini'

              Posté par (page perso) . Évalué à  2 .

              Sauf erreur de ma part, il y a le système de boot, qui est spécifique debian. Mais oui, si on retire tout ce qui est propre à la distro ( l'installeur, les paquets, la gestion de paquet, la gestion de la distro ), il ne reste que des trucs génériques :)

          • [^] # Re: Toujours aussi 'mal fini'

            Posté par (page perso) . Évalué à  5 .

            Ils font tous les testes sur Fedora avant de les tappers dans rhel. Je sais pas si on pourait comparer ça à Debian, ou à Mageia ou a une distro vraiment "communautaire".

            Si Red Hat profite de Fedora pour expérimenter, libre à chaque communauté ou distribution de faire la même chose.

            Fedora est une distribution libre qui se veut à la pointe de l'innovation des solutions libres, si une équipe veut ajouter ou tester quelque chose sur Fedora avant de l'implémenter ailleurs, il peut et c'est d'ailleurs le but de le distribution.
            Nous n'avons pas eu de retours d'une fonctionnalité refusé par le Projet Fedora car le gars qui a soumis l'idée est un développeur Debian… D'ailleurs certains ne travaillent pas avec Red Hat et proposent des choses (comme dans le cas de DIET présenté dans la dépêche).

            Bref, Fedora est un laboratoire de test pour tout le monde, si Red Hat en profite le plus ça ne veut pas dire que c'est fermé aux autres. C'est un logiciel libre. ;)

          • [^] # Re: Toujours aussi 'mal fini'

            Posté par (page perso) . Évalué à  2 .

            Ouais enfin les paquets testés dans Fedora, y a aussi le même gcc, la même glibc, le même kernel qu'il y a sur tout les distros. Et il y a visiblement aussi pas mal de truc autour du cloud ( open nebula, openstack etc ) qui veulent passer par Fedora pour justement avoir le même genre de tests.

            Et dans le cas de Mageia, il y a par exemple aussi eu des versions de deve de gnome dans cooker, une version de dev de pulseaudio, parfois des RCs de perl.

            Il y a une tendance de fond de certains packageurs de fournir des tests via les versions de devs ou via les versions récentes de distros linux.

        • [^] # Re: Toujours aussi 'mal fini'

          Posté par . Évalué à  3 .

          C'est toujours le cas.

          La preuve c'est que RHEL6 est basé sur une Fedora 12 fiabilisée.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # les fontes

    Posté par (page perso) . Évalué à  3 .

    c'est quand même dommage que par défaut le rendu des fontes soit aussi laid, j'ai installé la fc17 avec xfce et visuellement c'est vraiment dur à encaisser..

    L'autre truc pénible c'est ce firewall qui bloque mdns

    • [^] # Re: les fontes

      Posté par . Évalué à  2 .

      Dés que j'install Fedora, j'utilise Fedora Utils et les petits fix, notamment celui du rendu des polices de caractères.

      • [^] # Re: les fontes

        Posté par . Évalué à  3 .

        Existe t il une liste de tout ces petits fix ?

    • [^] # Re: les fontes

      Posté par . Évalué à  1 .

      Pour les fontes, on peut améliorer les choses avec les patchs d'ici : http://www.infinality.net/blog/

      • [^] # Re: les fontes

        Posté par (page perso) . Évalué à  2 .

        Effectivement c'est ce que j'ai utilisé et c'est le jour et la nuit. Mais je ne comprends pas pourquoi ils ne font pas un effort pour avoir une conf par defaut qui soit potable, ne serait-ce que d'un point de vue marketting ça me semble assez maladroit. Peut etre que je pinaille, mais j'accorde beaucoup plus d'importance au rendu des fontes qu'au theme du bureau ou à la presence d'un hotdog hilare dans le fond d'écran

        • [^] # Re: les fontes

          Posté par (page perso) . Évalué à  3 .

          De mémoire il y a une histoire de brevets derrière cette histoire de police car cela a déjà été refusé.

          • [^] # Re: les fontes

            Posté par (page perso) . Évalué à  4 .

            Les brevets en question ont désormais expirés.

            « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Re: les fontes

          Posté par . Évalué à  2 .

          Tout pareil. Je suis passé à Fedora uniquement quand j'ai trouvé une solution potable et par dépôt pour les fontes.

  • # Et un thème de démarrage pour fêter ça!

    Posté par . Évalué à  1 .

    Pour l'occasion de la sortie de cette version de Fedora, un nouveau thème de démarrage est disponible. Il suffit d'installer le paquet 'plymouth-theme-hot-dog' pour en profiter.

    Pour un petit aperçus: >> NIMAGES NANIMÉES

  • # dnssec

    Posté par . Évalué à  0 .

    Apparemment dnssec n'est pas activé par default : http://lwn.net/Articles/499192. Et la validation dnssec échoue pour tous les sous-domaines de fedoraproject.org ..

Suivre le flux des commentaires

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