Fedora-Fr - Communauté francophone Fedora - Linux

Planet de Fedora-Fr : la communauté francophone autour de la distribution Linux Fedora

A propos

Cette page est actualisée toutes les heures.

Cette page est une sélection de blogs autour de Fedora. Fedora-Fr.org décline toute responsabilité au sujet des propos tenus par les auteurs des blogs de ce planet. Leurs propos sont leur entière responsabilité.

Le contenu de ce planet appartient à leurs auteurs respectifs. Merci de consulter leur blogs pour obtenir les licences respectives.

Mot-clefs : fedora15

Fin de vie de la Fedora 15

Edouard Bourguignon

A chaque nouvelle sortie de Fedora, la même histoire recommence. La version n-2 devient obsolète et n'est plus maintenue. Alors si vous utilisez une Fedora 15, notez bien dans vos agenda qu'elle sera concidérée comme morte à partir du 26 juin prochain (EOL: End Of Life). Donc plus de mises à jour pour cette version, plus de correctifs de bugs ou de sécurité (le plus gênant). Il est donc important de passer à une version plus récente (Fedora 17 par exemple, autant prendre la dernière).

Pour télécharger une Fedora récente: Le site officiel

Problèmes de rafraichissement partiel de l'ecran sous Gnome 3

Edouard Bourguignon

Si vous rencontrez des problèmes de rafraichissement partiel de l'ecran sous Gnome 3, particulièrement visible sous gnome-terminal, voici une astuce qui vaut le coup d'être testée.

Ce billet est l'occasion de partager un petit problème et sa solution, cela intéressera peut être du monde et au pire servira de note pour moi même.

J'étais concerné par ce problème depuis un certain temps (depuis le Fedora 15 me semble), sur plusieurs portables, surtout avec les drivers proprio Nvidia. En général ça me bloquait juste l'affichage de la dernière ligne sous gnome-terminal, qui finissait quand même par apparaitre. Mais sur mon portable personnel là c'était presque les 3/4 de l'écran qui restait noir. Bref cette fois il fallait faire quelque chose.

Sur le bugzilla RedHat/Fedora, un bug semble correspondre, bien que marqué comme corrigé: https://bugzilla.redhat.com/show_bug.cgi?id=720605

Et d'après les commentaires, cela semble en effet fonctionner sous Fedora 15, et ne pas concerner uniquement les drivers proprio Nvidia.

Au final, la manip consiste à créer un fichier /etc/X11/xinit/xinitrc.d/10-clutter-hack.sh avec le contenu suivant:

#!/bin/sh
export CLUTTER_PAINT=disable-clipped-redraws:disable-culling

Puis à relancer la session.

Non seulement ça corrige mes problèmes de rafraichissement partiel, mais en plus cela semble accélérer l'affichage (qui semblait avoir du plomb dans l'aile depuis la F16, surtout sous Firefox).

Darktable 0.9.3

Edouard Bourguignon

La version 0.9.3 du logiciel de retouche photo darktable vient de sortir, avec au programme des améliorations au niveau performance (optimisations de certains traitements en utilisant les instructions SSE), des traductions mises à jour (dont le français), de nouveau réglages (split toning, tone curve, equalizer, color zones) et bien sûr un lot de correction de bugs. Le site du projet a aussi été refait.

Les paquets Fedora pour cette nouvelle version sont en attente vers le dépôt updates-testing, et si tout ce passe bien ils seront disponibles dans les dépôts stables d'ici une bonne semaine. Cliquez ici pour suivre leur avancée.

A noter qu'un des développeurs du projet a fait d'excellents podcasts pour montrer certaines nouveautés par rapport à la version 0.9.2. Il y a en particulier les sujets de la suppression du bruit (denoising) ou de retouche ponctuelle (spot removal).

Darktable 0.9.1

Edouard Bourguignon

Les développeurs du projet darktable tente de proposer des versions plus souvent, ce qui est bien pratique pour pouvoir proposer des RPMs aux utilisateurs Fedora. Ceux-ci pourront ainsi suivre au plus près l'évolution de cette éditeur d'images RAW.

La version 0.9.1 est donc une version corrective de la 0.9, avec en tout 184 patches. Les principales améliorations concernent la lecture des fichiers RAW (en utilisant les nouvelles versions de rawspeed, dcraw et libraw), le HDR, l'historique et des corrections de bugs.

Il y a aussi depuis la version 0.9 un support d'OpenCL afin d'utiliser la carte graphique pour soulager le CPU de certains traitements. A voir si cela est packagé/packageable dans les RPMs, je n'ai pas vraiment eu le temps de me pencher sur le sujet.

Pour plus d'info: site officiel de Darktable

Les paquets darktable 0.9.1 pour Fedora sont dans les dépôts updates-testing, et devraient arrivés dans le dépôt classique dans au minimum 1 semaine.

Darktable 0.9

Edouard Bourguignon

Voilà enfin une nouvelle version de l'excellent logiciel d'édition de photo darktable. Après la version 0.8 sortie en février dernier, la 0.9 sortie ce matin devrait arriver dans les dépôts testing sous peu. Si vous êtes courageux et voulez contribuer à la chasse aux bugs, vous pouvez récupérer les paquets là:

Vous pouvez aussi attendre que ça arrive gentilment dans les dépôts testings, ce qui ne devrait pas tarder. Ensuite il faudra au minimum une semaine avant que ça arrive dans les dépôts stables si aucun problème n'est remonté.

Si vous êtes déjà en rawhide/F16, il en faut, cela devrait se faire tout seul lors des prochaines mises à jour. Et si vous êtes encore en Fedora 13 (ou encore plus vieux), pas de chance... Mettez à jour.

Voici la liste des changements, traduction de l'annonce officielle:

  • Detection automatique d'un support pour l'accéleration GPU (pas testé encore sous Fedora)
  • Operations de mixage (blend)
  • Outil de suppression des points (cramés?)
  • Outil de vision en faible luminosité
  • Filtre antibruit basé sur des moyennes non locales (?)
  • Première partie du Google summer of Code de darktable déjà ajoutée
  • Plugin d'ajout de cadre (pour ajouter des bordures carte postale)
  • Travail sur une gamme étendue (tonemapping) bien plus rapide (pour le HDR par ex)
  • Les images modifiées arrivent avec le tag "changed"
  • etc

Et bien sûr l'habituel lot de bugs corrigés et autres améliorations (notamment en terme de rapidité). Merci à l'équipe de développeurs ;) Plus d'information sur le site officiel.

Fin de vie pour la Fedora 13

Edouard Bourguignon

Un bref rappel pour ceux qui seraient encore en Fedora 13, celle-ci est arrivée au terme de son cycle de maintenance (End of Life). Les cycles des Fedora se terminent en général 1 mois après la sortie de la version N+2.

Depuis le 24 juin 2011, 1 mois après la sortie de la Fedora 15, la Fedora 13 ne reçoit donc plus aucune mise à jour, il est de ce fait très important de passer à une version plus récente et encore maintenue comme la Fedora 14, voire mieux, la Fedora 15.

Annonce officielle

Instructions de mise à niveau

Pour info, la Fedora 14 est sortie le 02/11/2010 et devrait voir sa fin de vie après l'arrivée de la Fedora 16, grosso modo pour la fin de cette année. Quant à la Fedora 15, sortie le 24/05/2011, elle a encore de beaux jours devant elle. La Fedora 17 ne devrait sortir que dans 1 an...

Calendrier de la Fedora 16

Si le cycle Fedora de 6 mois vous semble trop court, il y a la distribution RedHat (il faut payer une souscription) et ses clones (gratuits), comme la Scientific Linux 6. Là le cycle de vie est de 10 ans, comme expliqué ici.

Fedora 15 et après?

Edouard Bourguignon

La Fedora 15 nommée Lovelock est sortie dans les temps. Pour avoir une liste détaillée des nouveautés: lire ce Post Fedora-FR

Pour résumer:

  • Noyau Linux 2.6.38
  • Le fameux Gnome 3
  • systemd

Ce serait réducteur de limiter cette Fedora qu'à ces 3 points, mais ce sont ceux qui intéressent le grand public en ce moment. Tout particulièrement Gnome 3 et son interface à la philosophie nouvelle: gnome-shell. Ce gnome-shell risque de faire de l'ombre à Unity d'Ubuntu, bien que totalement différent. Gnome 3 prône comme toujours une ergonomie à lextrême avec un environnement qui se veut le moins intrusif possible. Unity vise avant tout la simplicité. Avec Gnome 3, le changement d'interface est radical, et il faudra reprendre ces marques et faire preuve de patience. Heureusement, Fedora-FR propose un guide de survie.

Comme Gnome 3 va certainement faire peur (à tord ou à raison) à tous ceux qui sont réfractaires au changement, cela donnera un coup de pouce aux excellents bureaux alternatifs que sont XFCE ou LXDE et tous les autres que j'oublie. Et il reste bien sûr KDE, qui continue sur sa lancé avec la branche 4.x. Pour tester facilement tout ça, il y a les versions personnalisées de Fedora.

J'ajouterais dans la longue liste des nouveautés l'excellent Firefox 4, et la suite bureautique qui passe à LibreOffice. Le pare-feu se voit aussi améliorer d'une fonctionnalité permettant d'ajouter dynamiquement des règles tout en gardant les connexions existantes, ce qui promet encore plus de souplesse, surtout que les applications peuvent maintenant piloter le pare-feu via le canal DBus.

A noter que l'excellent Muffin parle aussi des nouveautés (dont Gnome 3 forcément) de la Fedora 15.

Et la suite? La Fedora 16 est prévue en beta dès le 20 septembre prochain, et une sortie finale pour le 25 octobre (si tout se passe bien). Le nom de cette prochaine Fedora sera Verne, car tout comme Lovelock, Jules Verne était (entres autres) un futurologue.

La version du kernel devrait, si on en croit les rumeurs, changer radicalement. Linus estime en effet que 2.6.40 ça commençe à faire beaucoup. Faut-il parier sur une branche 2.8.x ou carrement 3.0.x? Je ne vois pas trop pourquoi on passerait directement à 3.0.x sauf s'il y a un énorme changement, mais la branche 3.0.x à l'air d'avoir un franc succès sur le net. Bref c'est la fin du noyau 2.6.

Pour la partie environnement de bureau, Gnome devrait normalement sortir une version 3.2 vers le mois de septembre, ce qui peut indiquer que cette version pourrait être utilisée pour la Fedora 16. Pour KDE, fin juillet est prévue normalement la version 4.7, qui devrait apporter pas mal de nouveautés sur KWin entres autres. Pour les autres environnements (XFCE, LXDE, etc) ceux-ci devraient aussi en toute logique progresser.

Cette Fedora 16, si ce n'est pas encore repoussé, devrait aussi proposer le format BTRFS par défaut. Il reste certains points à régler pour ça, comme Grub ou Grub2, ou le gestionnaire de volume (celui de BTRFS ou LVM?) et par conséquence Anaconda. En tout cas tout s'organise, pour plus d'information, lire ce thread.

Mais la Fedora 16 est encore bien loin, il faudra être patient. Heureusement que la Fedora 15 tient ses promesses, l'attente sera moins longue. La page à surveiller pour savoir ce que nous réserve la relève est ici : FeatureList F16. Au fur et à mesure, la liste devrait se remplir, comme ce fut le cas avec les précédentes versions de Fedora.

Pourquoi systemd?

Edouard Bourguignon

Voici une traduction rapide de la page: why systemd?. Article très complet qui liste les avantages de systemd par rapport à ces "concurrents" directs. Très intéressant.

Traduction:

systemd est encore un projet jeune, mais il n'est plus un bébé maintenant. L'annonce initiale a été posté il y a exactement un an. Depuis, la plus part des distributions majeures ont décidé de l'adopter, d'une manière ou d'une autre, alors que des distributions plus petites l'utilisent déjà. La première distribution importante utilisant systemd par défaut sera la Fedora 15, pour la fin du mois de mai. On peut s'attendre à ce que les autres distributions suivent le mouvement un peu plus tard (avec une exception). Beaucoup de développeurs l'ont déjà adopté, et il y a même déjà une entreprise qui propose des services et une expertise spécialisés sur systemd. En bref, en un an systemd est devenu un projet prometteur.

Malgré cela, il y a encore des gens qui n'ont pas été convaincu. Si vous faites partie d'une de ces catégories, alors veuillez lire la comparaison des systèmes d'init qui va suivre:

  • Vous travaillez sur des projets pour de l'embarqué, et vous vous demandez s'ils devraient être basés sur systemd.
  • Vous êtes un utilisateur ou un administrateur et vous vous demandez quelle distribution choisir, et vous hesitez si elle doit être basée ou nonn sur systemd.
  • Vous êtes un utilisateur ou un administrateur et vous vous demandez si votre distribution favorite utilisera systemd, même si tout marche déjà bien jusqu'à présent.
  • Vous developpez une distribution qui n'a pas encore basculé sur systemd, et vous vous demandez s'il faut investir du travail pour basculer sur systemd.
  • Et même si vous ne faites pas partie de ces catégories, vous pourriez trouver cette comparaison intéressante.

nonus allons comparer les 3 principaux système d'init utilisés sous Linux: sysvinit, Upstart et systemd. Bien sûr, il y a d'autres systèmes d'init qui existent, mais ils ne jouent virtuellement aucun rôle majeure dans le tableau. A moins que vous utilisez Android (qui est une bete à part de toute façon), vous avez surement déjà utilisé un des ces trois systèmes d'init sur votre nonyau Linux. (OK, ou busybox, mais alors grossièrement vous n'êtes pas en train d'utiliser un système d'init du tout). A moins que vous ayez un besoin exotique il n'y a pas besoin d'aller voir plus loin. Et aussi parce que je suis un peu paresseux, et que je ne veux pas passer du temps à analyser ces autres systèmes en détails pour être complètement honnête avec ceux-ci.

En parlant d'honnêteté, je suis bien sûr l'un des créateurs de systemd. J'essayerais de faire de mon mieux pour être juste envers les deux autres concurrents, mais au final, à prendre quand même avec des pincettes. Je suis sûr que même si je devrais être injuste ou d'une manière incorrect, quelqu'un le signalera dans les commentaires, donc n'hesitez pas à les lire aussi, avant de mettre trop de confiance dans ce que je dis.

nonus ne regarderons que les fonctionnalités déjà implémentées dans une version déjà disponible. Les fonctionnalités futures ne comptent pas.

Fonctionnalités générales

sysvinit Upstart systemd
Interface avec D-Bus non oui oui
Démarrage sans Shell non non oui
Services modulaires codés en C disponibles très tôt au boot non non oui
Read-Ahead non non[1] oui
Activation basée sur surveillance de socket non non[2] oui
Activation basée sur surveillance de socket: compatibilité avec inetd non non[2] oui
Activation évènementielle par surveillance d'un bus non non[3] oui
Activation évènementielle par un matériel non non[4] oui
Configuration des dépendances matériel avec des règles udev non non oui
Activation évènementielle par surveillance d'un chemin (inontify) non non oui
Activation basée sur un timer non non oui
Gestion de mount non non[5] oui
Gestion de fsck non non[5] oui
Gestion des quota non non oui
Gestion de automount non non oui
Gestion de la swap non non oui
Prise dinstantanés de l'état du système non non oui
Support de XDG_RUNTIME_DIR non non oui
Suppression optionnelle des processus restants quand un utilisateur se delogue non non oui
Intégration des Control Groups Linux non non oui
Génération d'enregistrement pour audit des services démarrés non non oui
Intégration de SELinux non non oui
Intégration de PAM non non oui
Support des disques durs encryptés (LUKS) non non oui
Gestion du certificat SSL ou du mot de passe pour LUKS, incluant Plymouth, Console, wall(1), TTY et les agents GnonME non non oui
Gestion du périphérique loopback pour le réseau non non oui
Gestion de binfmt_misc non non oui
Gestion de la localisation globale du système non non oui
Configuration de la Console et du clavier setup non non oui
Infrastructure pour créer, supprimer et nettoyer les fichiers temporaires et volatiles non non oui
Gestion de sysctl pour /proc/sys non non oui
Intégration de Plymouth non non oui
Sauvegarde/restauration d'un random seed non non oui
Chargement statique des modules kernel non non oui
Gestion automatique de la console série non non oui
Gestion d'un identifiant unique de la machine non non oui
Gestion dynamique du nonm d'hôte et des meta données de la machine non non oui
Arrêt fiable des services non non oui
Enregistrements /dev/log très tôt au boot non non oui
Démon minimal de syslog basé sur kmsg pour un usage embarqué non non oui
Relance sur plantage de service sans perte de connectivité non non oui
Mises à jour de service sans indispo non non oui
UI graphique non non oui
Outils et profilage intégrés non non oui
Services instanciés non oui oui
Intégration de PolicyKit non non oui
Accès distant/Support Cluster intégrés dans les outils clients non non oui
Peut lister tous les processus d'un service non non oui
Peut identifier le service d'un processus non non oui
CPU Cgroups automatiques par service, pour contrôler l'utilisation CPU non non oui
Cgroups automatiques par utilisateur non non oui
Compatibilité SysV oui oui oui
Services SysV contrôlables de la même manière que les services natifs oui non oui
/dev/initctl compatible SysV oui non oui
Re-exécution avec une sérialisation complète des états oui non oui
Démarrage interactif non[6] non[6] oui
Support des container (remplacement évolué de chroot()) non non oui
Démarrage basé sur des dépendances non[7] non oui
Désactivation de services sans éditer un fichier de configuration oui non oui
Masquage de services sans éditer un fichier de configuration non non oui
Arrêt du système robuste avec le PID 1 non non oui
Support intégré de kexec non non oui
Génération dynamique de service non non oui
Support en amont depuis d'autres composants de l'OS oui non oui
Fichiers de service compatibles entre distributions non non oui
Transmission de signaux vers services non non oui
Arrêt fiable des sessions utilisateurs avec l'arrêt du système non non oui
Support de utmp/wtmp oui oui oui
Fichiers de services facilement compréhensible, parfait pour la manipulation avec des outils de gestion non non oui

¹ L'implémentation de Read-Ahead pour Upstart est disponible via un paquet séparé "ureadahead", nécessite un patch non standard sur le kernel.

² L'implémentation de l'activation par socket pour Upstart est disponible en tant que "preview", mais ne supporte pas la parallélisation et du coup rate complètement lintérêt de l'activation par socket.

³ L'implémentation de l'activation par Bus pour Upstart disponible comme patch, pas encore intégré.

⁴ L'implémentation de l'évènementiel via udev sur les périphérique au niveau d'Upstart est disponible en tant que "preview", en transmettant intégralement la base udev, peu pratique.

⁵ L'utilitaire de gestion mount "mountall" pour Upstart est disponible dans un paquet séparé, ne couvrant que les montages lors du boot, avec un système très limité de dépendance.

⁶ Certaines distributions offrent cette implémentation dans le shell.

⁷ Les scripts d'init LSB supportent ceci, s'ils sont utilisés.

Réglages disponibles sur les services natifs

sysvinit Upstart systemd
Ajustement de l'OOM non oui[1] oui
Répertoire de travail non oui oui
Répertoire racine (chroot()) non oui oui
Variables d'environnement non oui oui
Variables d'environnement depuis un fichier extérieur non non oui
Limitation des ressources non some[2] oui
umask non oui oui
Groupement des Utilisateurs/Groupes/Groupes supplémentaires non non oui
Classe/priorité de l'ordonnancement des IO non non oui
Valeur de nice pour l'ordonnancement CPU non oui oui
Politique/priorité d'ordonnancement CPU non non oui
Contrôle de la remise à zero de l'ordonnanceur CPU sur fork() non non oui
Affinité CPU non non oui
Timer Slack non non oui
Contrôle des capacités non non oui
Contrôle du bit de sécurité non non oui
Contrôle des Control Groups non non oui
Contrôle d'un espace de nommage de haut niveau sur le système de fichiers: rendre des répertoires inacessibles non non oui
Contrôle d'un espace de nommage de haut niveau sur le système de fichiers: rendre un répertoire en lecture seul non non oui
Contrôle d'un espace de nommage de haut niveau sur le système de fichiers: /tmp privé non non oui
Contrôle d'un espace de nommage de haut niveau sur le système de fichiers: héritage de montage non non oui
Entrée depuis la Console oui oui oui
Sortie via Syslog non non oui
Sortie via kmsg/dmesg non non oui
Sortie sur un TTY donné non non oui
Contrôle du signal Kill non non oui
Exécution conditionnelle: par l'identification d'une virtualisation CPU /container non non oui
Exécution conditionnelle: par la présence d'un fichier non non oui
Exécution conditionnelle:: par un framework de sécurité non non oui
Exécution conditionnelle: par ligne de commande kernel non non oui

Gnome 3 et le double-écran

Edouard Bourguignon

Gnome 3 apporte un nombre impressionnant de nouveautés, et aussi forcement son lot de changement d'habitude pour l'utilisateur qui va avec. Le premier point visible concerne la gestion du bureau et des espaces de travail (ou bureau virtuel, workspace en anglais). Préparez vous mentalement, les bureaux virtuels ne sont plus collés entre eux par la tranche verticale, mais par la tranche horizontale. Ainsi le 2e bureau virtuel n'est plus à la droite du 1er, mais en dessous. Si ça c'est pas de la révolution! Du même coup on passe d'un bureau à l'autre avec la combinaison ctrl+alt+flèche bas/haut.

Autant ce premier point n'est pas gênant, autant le deuxième concernant le double écran est plus déroutant. En effet, quand vous branchez un deuxième écran, celui-ci est correctement détecté grâce à xrandr (si votre pilote graphique le supporte) et devient tout de suite utilisable. C'était déjà le cas depuis un bon moment sous Gnome, donc jusque là rien de nouveau. Mais Gnome 3 propose par défaut, au niveau de la gestion des bureaux virtuels, que votre écran secondaire soit en fait qu'une sorte d'écran de statut. C'est à dire que toutes les fenêtres que vous y mettrez seront visibles peu importe dans quel bureau virtuel vous êtes. On est donc assez loin de la gestion habituelle du double-écran où le bureau s'étendait simplement sur la totalité des deux écrans.

Je ne sais pas si c'est très clair, je donne donc un exemple tout simple du fonctionnement par défaut. Si j'ouvre Firefox sur l'écran principal dans le 1er bureau virtuel, et un terminal sur l'écran secondaire toujours dans le 1er bureau. Je vois donc Firefox et le terminal sur chaque écran. Si je change de bureau virtuel, pour par exemple lancer evolution, j'aurais toujours le terminal sur l'écran secondaire.

Bien sûr avec de l'habitude, ce mode de fonctionnement par défaut est peut être intéressant. En tout cas, ce qui fait aujourd'hui défaut à Gnome 3, c'est un outil de configuration. Car il est en effet possible de revenir à un comportement plus classique du double écran en modifiant une valeur dans gconf.

Voici donc l'astuce:

yum install gconf-editor
gconf-editor

Puis dans /desktop/gnome/shell/windows, décocher workspaces_only_on_primary. Relancer la session pour que ce soit pris en compte.

Gnome3 dualhead

Au final, Gnome 3 reste très intéressant, très réactif, il faut juste prendre le temps de retrouver ses repères.

Le nouveau systemd

Edouard Bourguignon

Le remplacement de l'ancestrale sysVinit pour la gestion du démarrage de la machine et de ses services est en soit une petite révolution dans le monde Linux. On lui reprochait de ne pas être assez modulaire et dynamique pour les usages qu'on fait maintenant de nos ordinateurs. Maintenant, il faut une gestion qui se base sur de lévènementiel plutôt que sur du séquentiel, tout en gérant de l'interdépendance. C'est vrai qu'avec SystemVinit qui date des années 90, on en était loin. Il y eu plusieurs candidats (par exemple Upstart) car le sujet n'est pas nouveau et la tâche n'est pas des plus simple. Mais depuis la Fedora 14, la révolution est en marche et le choix s'est arrêté sur systemd. Celui-ci sera pleinement intégré à la future Fedora 15.

Systemd vient avec la commande systemctl, mais pour éviter d'impacter de manière trop violente nos bonnes vieilles habitudes, les commandes habituelles de gestion de service continueront de fonctionner comme avant. Ainsi, les commandes service et chkconfig peuvent toujours être utilisées sous systemd. Il est de plus compatible avec SysV et les scripts d'init LSB. Ainsi les scripts d'init habituels en shell vont pouvoir cohabiter (ceux dans /etc/init.d) avec systemd, les autres sont remplacés dans systemd par des fichiers descriptifs .service (présents dans /lib/systemd/system).

Voici par exemple, le fichier descriptif ntpd.service, tout à fait compréhensible (heureusement qu'ils ont pas choisi du XML):

[Unit]
Description=Network Time Service
After=syslog.target ntpdate.service

[Service]
EnvironmentFile=/etc/sysconfig/ntpd
ExecStart=/usr/sbin/ntpd -n -u ntp:ntp $OPTIONS

[Install]
WantedBy=multi-user.target

Les gros avantages de systemd sont sa capacité de parallélisation à outrance, la gestion des sockets (port d'écoute) et l'utilisation de DBus pour l'activation des services, ainsi que l'usage des cgroups. Il supporte aussi des options avancées pour la sécurisation des services avec la possibilité d'isolation des processus (chroot ou namespace sur le système de fichiers).

Systemd est découpé en unités (units), disposant chacune d'un nom et d'un type. Par exemple le fichier avahi.service est l'unité avahi et est de type service. Voici les principaux types:

  • service, pour gérer les démons.
  • socket, pour définir un socket. Par exemple l'unité nscd.socket si elle reçoit une demande de connexion pourra lancer l'unité nscd.service.
  • device, udev permettra d'indiquer à systemd qu'un périphérique peut être utilisé comme unité.
  • mount, cette unité permet à systemd de surveiller un point de montage.
  • automount, est associé à une unité mount qui sera activée quand on accédera au répertoire de l'unité automount.
  • target, permet de grouper plusieurs unités. Par exemple multi-user.target correspondera à peu près au demarrage des services du runlevel 5 avec SysV.
  • snapshot, permet de grouper l'état actuel des unités actives, afin de sauvegarder l'état du système pour pouvoir ensuite y revenir.

Il est donc évident que tout ceci est une nouvelle approche dans la gestion du système. Bien sûr les unités peuvent être interdépendantes ou indiquer d'éventuels conflits. Vu les différents types à disposition cela va permettre beaucoup de souplesse. Il sera par exemple possible de déclencher le montage d'un périphérique dès que celui-ci devient disponible, montage qui entrainera lui aussi d'autres dépendances, comme le démarrage d'un service... Que du bon en perspective.

Pour l'utilisateur final, l'objectif est de proposer un temps de boot bien plus rapide, dû principalement au fait que les services seront lancés en parallèle mais aussi qu'ils seront activés que s'ils sont nécessaires. D'autres tâches de gestion du système pourront être automatisées, déclenchées par exemple avec l'apparition ou la disparition d'un périphérique. De quoi disposer d'un système complètement dynamique.

Il ne reste plus qu'à attendre la sortie de la Fedora 15, prévue pour le 24 mai 2011.

Fedora 15: journée de tests pour la gestion de l'energie

Edouard Bourguignon

Cette fois, il s'agit d'une journée de tests concernant la gestion de l'alimentation et de l'économie d'energie. Donc si vous voulez être sûr que cette partie soit bien gérée dans la prochaine Fedora, c'est le moment de la tester.

Toutes les informations sur cette page: https://fedoraproject.org/wiki/Test_Day:2011-03-24

Les nouveautés de la Fedora 15

Edouard Bourguignon

Alors que la version alpha de la Fedora 15 vient à peine de sortir, voici un aperçu des nouveautés annoncés:

  • Environnement de Bureau à jour, avec en vedette Gnome 3. Mais bien sûr les autres environnements, comme KDE et Xfce, ne seront pas en reste, et seront disponibles dans leurs dernières versions stables.
  • Gestion du système et des sessions. Déjà disponible dans la Fedora 14 en tant qu'avant goût technologique, systemd prend encore plus d'importance dans la Fedora 15. Systemd est un moyen plus intelligent et plus fiable pour le démarrage des différents services que nous utilisons tous les jours, tel que NetworkManager et PulseAudio (entres autres).
  • Cloud. Besoin de créer des appliances à utiliser dans un Cloud? BoxGrinder permet de créer des appliances (machines virtuelles) pour de nombreuses plateformes (KVM, Xen, EC2) en partant d'un fichier de définition simple en texte.
  • Des langages de programmations et des outils mis à jour. La Fedora 15 propose de nouvelles version de Rails, OCaml et Python. GDB et GCC sont aussi mis à jour (La Fedora 15 a été compilé avec GCC 4.6.0).
  • Applications productive. LibreOffice contient tous les outils pour un usage quotidien, avec un traitement de texte, un tableur, et des applications de présentation. Il remplace OpenOffice.
  • Nommage persistent des interfaces réseaux. La gestion de serveur devient encore plus facile. Fedora 15 utilise les noms des ports réseaux en interrogeant le BIOS, soulageant la tâche des administrateurs.
  • Parefeu dynamique. Fedora 15 ajoute le support pour le démon optionnel de parefeu, qui propose une gestion dynamique des règles de filtrage en utilisant une interface D-Bus.
  • eCryptfs dans Authconfig. Fedora 15 apporte un support amélioré pour eCryptfs, un système de fichiers crypté pour Linux. Avec la Fedora 15, authconfig peut être utilisé pour mounter automatiquement une partie privée encryptée du repertoire d'un utilisateur quand celui-ci ouvre sa session.
  • DNSSEC pour les stations de travail. NetworkManager utilise maintenant le serveur BIND comme resolveur DNSSEC. Toutes les réponses DNS reçues sont prouvées comme étant correctes. Si un domaine particulier est signé et échoue sur la validation, alors le résolveur retourne une erreur SERFVAIL au lieu d'invalider la réponse, ce qui signifie que quelque chose ne va pas.
  • Plus vert. Amélioration des outils de gestion de l'énergie, incluant PowerTOP qui identifie les composants logiciel qui font que l'ordinateur consomme plus d'énergie que nécessaire quand il est en repos. Le réglage automatique de la consommation d'énergie et des performances permet d'économiser la batterie pour les portables.
  • Des outils de gestion "business". Tryton est une plateforme trois tièrs d'applications generiques, proposant des solutions de gestions de comptes, de ventes, de facturations, d'achats, d'analyses et inventaires.
  • De nouveaux groupes de paquets. Le groupe "Graphics" a été renommé en "Design", et le SIG Robotics a créé le groupe de paquet "Robotics" proposant une collection de logiciels permettant de disposer d'un environnement complètement utilisable de simulation robotique.

Et bien sûr tout plein d'autres améliorations, de corrections de bugs etc pour que Fedora reste à la pointe.

Ceci était une traduction adaptée de l'annonce officielle de la Fedora 15 alpha disponible à l'adresse suivante:

http://fedoraproject.org/wiki/F15_Alpha_release_announcement

Fedora 15: journée de tests pour le pilote intel

Edouard Bourguignon

Cette fois, il s'agit d'une journée de tests pour les pilotes libres des cartes graphiques Intel. C'est donc les possesseurs de carte graphique intégrée Intel qui pourront contribuer à Fedora en testant le pilote sur la Fedora 15. Pour cela il faut suivre la procédure suivante:

http://fedoraproject.org/wiki/Test_Day:2011-02-24_Intel

La documentation concernant l'utilisation des LiveCD à l'adresse suivante:

http://fedoraproject.org/wiki/FedoraLiveCD

On ne rappelle jamais assez l'intérêt de ce genre de test ciblé à grand échelle, mais cela permet d'éradiquer certain bugs et de valider que tout fonctionne sur un maximum de matériels.

Fedora 15: journée de tests pour le pilote radeon

Edouard Bourguignon

Cette fois, il s'agit d'une journée de tests pour les pilotes libres des cartes graphiques ATI/AMD. C'est donc les possesseurs de carte graphique AMD/ATI qui pourront contribuer à Fedora en testant le pilote radeon sur la Fedora 15. Pour cela il faut suivre la procédure suivante:

http://fedoraproject.org/wiki/Test_Day:2011-02-23_Radeon

La documentation concernant l'utilisation des LiveCD à l'adresse suivante:

http://fedoraproject.org/wiki/FedoraLiveCD

On ne rappelle jamais assez l'intérêt de ce genre de test ciblé à grand échelle, mais cela permet d'éradiquer certain bugs et de valider que tout fonctionne sur un maximum de matériels.

Fedora 15: journée de tests pour le pilote nouveau

Edouard Bourguignon

Les journées tests sont l'occasion de tester un point précis afin de remonter le maximum de bugs sur le sujet. Forcement cela se passe sur la version encore en développement de la prochaine Fedora (ici la Fedora 15), mais tout est mis en œuvre pour faciliter son utilisation avec un LiveCD dédié pour la journée de tests.

Aujourd'hui il s'agit du tests sur le pilote nouveau, donc les possesseurs de carte graphique Nvidia qui voudraient contribuer à Fedora peuvent suivre la procédure suivante avec les images ISO des LiveCD:

http://fedoraproject.org/wiki/Test_Day:2011-02-22_Nouveau

La documentation concernant l'utilisation des LiveCD à l'adresse suivante:

http://fedoraproject.org/wiki/FedoraLiveCD

On ne rappelle jamais assez l'intérêt de ce genre de test ciblé à grand échelle, mais cela permet d'éradiquer certain bugs et de valider que tout fonctionne sur un maximum de matériels.

Darktable 0.8

Edouard Bourguignon

Darktable est un logiciel de traitement d'images orienté photographie. Il supporte un grand nombre de formats bruts (raw) de la plus part des constructeurs d'appareil photo. Il se distingue par l'utilisation de deux modes bien connus des photographes, un mode table lumineuse et un mode chambre noire. La première sert au classement des photos, trie, notation, etc, la deuxième sert à l'édition de nombreux réglages affectant le rendu de la photo (contraste, correction du grain/bruit, des aberrations chromatiques, des déformations de l'objectif, des couleurs etc). Tous ces réglages sont en fait disponibles sous forme de plug-ins, ce qui rend le logiciel très modulaire.

La sortie officielle de la version 0.8 de Darktable vient d'être annoncée. En traduction "adaptée" de l'annonce, voici les principales nouveautés:

  • Un chargement des images plus rapide grâce à rawspeed
  • Beaucoup d'amélioration de performance dans les caches et unités de traitement des pixels
  • Utilisation d'OpenCL pour utiliser les capacitiés de traitement du GPU (si disponible, pas pour l'instant sur la Fedora)
  • Encore plus de plugins
  • Depixelisation des images plus rapide
  • HDR (encore un peu expérimental)
  • Support de l'upload vers flickr
  • Nouveaux langages: thai et japonais
  • De nouvelles matrices de couleurs et des pré-réglages de la balance des blancs
  • Des corrections de bugs

Darktable 0.8 utilise maintenant la bibliothèque little CMS en version 2, pour la gestion des couleurs, ce qui malheureusement met sur la touche les utilisateurs de Fedora 13 (qui ne dispose que de la little CMS en version 1). La dernière version de Darktable sur la Fedora 13 sera donc la 0.7.1.

Les paquets de cette nouvelle version sont arrivés sur les dépôts updates-testing avec pas mal de difficultés vu que les développeurs du projet sont passés à cmake pour la compilation. Il y a eu aussi quelques soucis avec le nouveau GCC des prochaines Fedora (> F14) qui tolère encore moins certaines choses (par exemple les variables définies mais jamais utilisées). Mais tout ceci est fait dans un but d'amélioration du code donc c'est une bonne chose.

Pour tester ces paquets:

yum install darktable --enable-repo=updates-testing

D'ici quelques jours ou semaines, s'il n'y a pas de problème majeur, ces paquets arriveront dans les dépôts stables.