Je viens de profiter des vacances pour mettre à jour mon portable sous Fedora 19, actuellement en version alpha. Jusqu'à présent, j'utilisais preupgrade, mais comme fedup deviendra bientôt la solution officielle, j'ai voulu tenter le coup.

preupgrade proposait une interface graphique qui permettait rapidement de passer à la version n+1. fedup, passe par un client en ligne de commande. Certes, c'est plus ardu mais ça permet de mettre à jour une Fedora sans interface graphique. Malheureusement, le passage par anaconda oblige toujours de devoir avoir un accès physique sur la bécane ou à minima un KVM Over IP.

Si vous aussi vous voulez tâter de l'alpha :

fedup-cli --disablerepo remi --disablerepo fedora-chromium-stable --disablerepo Dropbox --disablerepo google-musicmanager --disablerepo llaumgui --network 19 --debuglog fedupdebug.log --instrepo http://dl.fedoraproject.org/pub/fedora/linux/releases/test/19-Alpha/Fedora/x86_64/os/

Salut.

C'est encore avec beaucoup de retard, après une fin d'année 2012 très compliquée pour moi, que je vous livre ces dernières mesures...

Voici les résultats comparatifs de Fedora 18 vs Fedora 17.

Pour rappel, ma machine est équipée d'un Quad Core Intel Q6600 à 2,4 GHz avec 4 Go de RAM.

Je me suis limité au benchmark UnixBench qui fournit un indice global, ce qui me simplifiera la comparaison. La version UnixBench utilisée est la version 4.1.0.

Mon protocole de tests est le suivant :

• Installation de Fedora 18 version 32 bits avec le noyau Fedora 3.6.10-4.fc18.i686.PAE.
• La machine est placée en niveau 3 (init 3).
• 10 séries de tests avec UnixBench compilé sous Fedora 18 et exécuté sous Fedora 18 (noyau Fedora 3.6.10-4.fc18.i686.PAE).
• 10 séries de tests avec UnixBench compilé sous Fedora 17 et exécuté sous Fedora 17 (noyau Fedora 3.3.4-5.fc17.i686).

Voici les résultats obtenus :

Fedora 18 version 32 bits :

Série 1 : 755.2
Série 2 : 747.9
Série 3 : 757.8
Série 4 : 771.8
Série 5 : 764.7
Série 6 : 759.2
Série 7 : 764.8
Série 8 : 759.0
Série 9 : 766.7
Série 10 : 748.7

Moyenne : 759.6

Fedora 17 version 32 bits :

Voici pour rappel les résultats obtenus avec Fedora 17 :
Série 1 : 720.6
Série 2 : 720.1
Série 3 : 717.1
Série 4 : 728.1
Série 5 : 735.0
Série 6 : 736.3
Série 7 : 727.2
Série 8 : 719.6
Série 9 : 738.5
Série 10 : 719.7

Moyenne : 726.2

Résultats :

Pour Fedora 18, on obtient un indice moyen de 759.6 pour UnixBench.
Pour Fedora 17, j'avais obtenu un indice moyen de 726.2 pour UnixBench.


On a donc un gain moyen de près de 4.6 % de Fedora 18 32 bits par rapport à Fedora 17 32 bits...
On assiste encore une fois à une légère amélioration des performances avec cette nouvelle version de Fedora comme montré sur la figure suivante :

Conclusion :

Au moment de ces tests, le noyau Fedora 18 (basé sur le noyau vanilla 3.6.10) propose un gain de 4.6 % par rapport au noyau Fedora 17 (basé sur le noyau vanilla 3.3.4), ce qui le ramène au niveau de Fedora 7 (soit au début de mes tests !).


++

Je viens de rempiler pour un 4ème mandat (consécutif) au sein du conseil d'administration de l'association Borsalinux-Fr : l'association française de loi 1901 constituée de bénévoles et dédiée à la promotion de la distribution Fedora et des logiciels libres dans tous les pays francophones.

Lassemblée générale qui a eu lieu Samedi dernier a permis d'élire un nouveau CA ainsi qu'un nouveau bureau :

• Emmanuel Seyman (eseyman) - Président
• Pierre-Yves Chibon (pingou) - Vice-Président
• Nicolas Chauvet (kwizart) - Trésorier
• Pablo Martin-Gomez (bouska) - Trésorier adjoint
• Charles-Antoine Couret (renault) - Secrétaire
• Kévin Raymond (shaiton) - Secrétaire adjoint
• Guillaume Kulakowski (llaumgui)

Il est cependant a déplorer que le nombre dadhérents baisse et que je suis l'un des 2 derniers membres fondateurs... Alors il n'est pas trop tard pour adhérer :

Si vous venez de faire une installation toute fraîche de Fedora 18 vous serez peut être étonné que la commande systemd-analyze n'est plus disponible de base. Cette commande très utile est dans le paquet "systemd-analyze", qu'il suffit d'installer:

yum install systemd-analyze

Et voilà! Utile pour diagnostiquer un démarrage lent:

$ systemd-analyze blame
  2055ms postfix.service
   601ms systemd-udev-settle.service
   530ms firewalld.service
   476ms fedora-storage-init.service
   451ms iscsid.service
   335ms bluetooth.service
   229ms abrt-ccpp.service
   222ms systemd-binfmt.service
   204ms NetworkManager.service
   199ms fedora-storage-init-late.service
   195ms systemd-logind.service
   185ms avahi-daemon.service
   169ms ntpd.service
   162ms cpupower.service
   159ms acpid.service
   158ms fedora-loadmodules.service
   127ms systemd-udev-trigger.service
   105ms sshd.service
   103ms systemd-readahead-collect.service
   101ms abrt-vmcore.service
    98ms ksmtuned.service
    93ms gdm.service
    93ms lvm2-monitor.service
    92ms sys-kernel-debug.mount
    90ms systemd-readahead-replay.service
    85ms ksm.service
    80ms dev-mqueue.mount
    79ms udisks2.service
    78ms proc-sys-fs-binfmt_misc.mount
    68ms dev-hugepages.mount
    67ms systemd-vconsole-setup.service
    66ms systemd-remount-fs.service
    66ms systemd-tmpfiles-setup.service
    65ms home.mount
    62ms rpcbind.service
    60ms fedora-readonly.service
    59ms bacula-fd.service
    53ms colord.service
    52ms iscsi.service
    51ms tmp.mount
    51ms systemd-sysctl.service
    48ms polkit.service
    47ms systemd-modules-load.service
    45ms boot.mount
    45ms auditd.service
    42ms sys-kernel-config.mount
    29ms wpa_supplicant.service
    27ms accounts-daemon.service
    27ms systemd-udevd.service
    23ms upower.service
    12ms rtkit-daemon.service
     9ms systemd-user-sessions.service

Pas mal cette Fedora 18, assez propre sans rien faire (et encore j'ai perdu 2 secondes au boot en installant postfix). La transition vers systemd est de plus en plus complète, vu ce qu'il reste dans init.d:

$ ls /etc/init.d/
ebtables  functions  iscsi  iscsid  libvirt-guests  netcf-transaction  netconsole  network  README

A suivre!

Quand il est nécessaire d'accèder à des systèmes de fichiers particuliers, à travers le réseau (NFS, CIFS, etc) ou sur une ressource pas toujours disponible (disque externe USB), voire même pour soulager les requêtes sur ce montage, il est utile de passer par la fonctionnalité "automount". Comme son nom l'indique, cela permet de monter automatiquement un point de montage, dès la première requête d'accès sur ce dernier. L'inverse est aussi de mise, démonter le point de montage quand celui-ci n'a pas été accédé depuis un certain temps (timeout).

Avant il fallait passer par autofs/automount, et configurer un ou plusieurs fichiers de configuration pour indiquer les points de montage à gérer. Rien de très complexe ceci dit. Mais aujourd'hui, le fameux remplaçant de SystemVinit, systemd, a de nombreux avantages dont celui de prendre en charge nativement les points de montage, particulièrement pratique pour remplacer autofs/automount.

Il y a deux possibilités pour configurer un point de montage automatique avec systemd:

• via les fichiers unit de systemd, avec la création d'un fichier .automount et son associé en .mount
• via directement le fichier /etc/fstab

Comme ici, le but est de faire plus simple qu'à l'époque de autofs, nous allons juste voir la méthode via fstab. Attention c'est simple, il suffit d'ajouter une ligne classique du montage souhaité, et dans les options d'ajouter la mention x-systemd.automount. Et voilà le tour est joué.

Exemple avec un montage nfs4:

srvnfs:/nfs/exports/home /mnt/nfs/home nfs4 x-systemd.automount 0 0

Exemple avec un disque externe usb (ex /dev/sdb1):

UUID=a2969b8d-c90a-432e-8198-f697c23f8c96 /mnt/externe            ext4    noauto,x-systemd.automount 0 0

(blkid /dev/sdb1 pour avoir l'UUID).

Au prochain reboot, au moindre accès dans le point de montage indiqué par x-systemd.automount, ce dernier sera automatiquement monté. C'est magique!

La Fedora 18 étant disponible depuis le 15 janvier dernier, il va falloir penser à mettre à jour si vous êtes en retard. En effet, chez Fedora, la version n-2 devient obsolète et n'est plus maintenue.

Alors si vous utilisez encore une Fedora 16, notez bien dans vos agenda qu'elle sera considérée comme morte à partir du 12 février 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 18 par exemple, autant prendre la dernière).

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

Pour mettre à jour votre Fedora: Procédure de mise à jour

Après une review assez longue, mes RPMs pour Indefero viennent d'intégrer les dépôts Fedora et EPEL. Pour le moment dans la partie testing mais ils devraient intégrer la branche stable sous quinzaine.

C'est une grande satisfaction pour ma part, qui va me simplifier mes déploiements. En effet, je me sers de ce logiciel quotidiennement, que ce soit pour gérer mes projets perso mais également dans le cadre de mon travail à CGI Montpellier où Indefero est notre plateforme de gestion sources.

Pour ceux qui voudraient faire la mise à jour, sachez que j'ai implémenté un script d'update de la base de donnée. Après avoir lancé votre yum update (avec les options qui vont bien pour activer les dépôts de tests), vous n'avez plus qu'à lancer un indefero_update et votre modèle de données passera en 1.3.3.

Pour ceux qui sont passés à côté de l'info ou qui n'ont pas vu la pub sur le côté de mon blog : Fedora 18, dont le nom de code est "Spherical Cow", vient tout juste d'être publiée.

Plus d'info chez les copains d'en face...

Après la refonte du blog, il fallait que je mettes le thème de ma plateforme de projets également aux couleurs de mon nouveau thème. C'est à présent chose faite.

J'en ai également profité pour mettre à jour Indefero en version 1.3.3. La mise à jour est à présent super facile vu qu'il suffit de lancer le script fourni avec mes RPM :

root@kalach ~> /usr/sbin/indefero_update
PHP include path: .:/usr/share/pear:/usr/share/php:/usr/share/php/pluf
Migrate  to version latest
26 26NullableActivityInProject up
 
Proceed to the update? [n/y]y
PHP include path: .:/usr/share/pear:/usr/share/php:/usr/share/php/pluf
Migrate  to version latest
26 26NullableActivityInProject up
 
Done.

Pour une fois les RPM ne sont pas disponibles sur mon dépôt. En effet, comme la review avance à grand pas je ne désespère pas de pouvoir pousser cette version directement sur les dépôts officiels de Fedora/EPEL.

Enfin! Le GO vient d'être donné pour la sortie officielle de la Fedora 18 (Spherical Cow), la date sera donc le 15 janvier prochain.

Après plusieurs mois de retard, principalement lié à la refonte importante du programme d'installation Anaconda, cette prochaine version qui commençait à se faire attendre arrive enfin. Il aura fallu reporter sa sortie près de 7 fois, ce qui est surement une première chez Fedora, pour enfin corriger les derniers bugs bloquants. Vivement le 15!

Tout plein de nouveautés comme à chaque fois:

• Gnome 3.6
• Firewalld
• toujours plus de systemd
• DNF
• oVirt 3.1
• Samba 4
• MATE, xfce etc

J'en oublie surement, la liste est longue: ici

Plus que quelques jour à attendre.

Fedora 18 arrive ! Il est temps d'afficher le compteur sur nos blogs et sites. Pour cela, comme chaque années, le Fedora Project met à disposition un compteur officiel :

<script id="fedora-banner" type="text/javascript" src="http://fedoraproject.org/static/js/release-counter-ext.js?lang=fr&width=200px"></script>

Ou alors, pour ceux qui comme moi carbure à headjs :

<script id="fedora-banner" type="text/javascript">head.js("//fedoraproject.org/static/js/release-counter-ext.js?lang=fr&amp;width=200px");</script>

Cela va faire maintenant 7 versions que j'upgrade ma distribution fétiche à grand coup de yum upgrade (il y a longtemps) ou de preupgrade. Bref ce qui aujourd'hui est une Fedora 17 était avant une Fedora 10. Je me suis donc dit qu'il était grand temps de faire une installation propre !

Et là, je dois dire que cet opus 18 de Fedora est un grand crus :

• Pléthore d'outils biens conçus pour configurer son poste sans passer par la case terminal.
• Nouvel Anaconda.
• Configuration du firewall très poussée mais tout en restant facile à utiliser.
• J'ai enfin laissé SELinux installé ! Il est enfin (AMHA) utilisable simplement !
• GNOME 3.6 qui devient de mieux en mieux (sur mon portable).

Bref, je suis tellement séduit que je pense fortement à migrer également mon poste de travail sous F17 (toujours en installation propre).

La Fedora 18 vient de passer une étape importante en vue de sa sortie finale avec la sortie de sa Beta. L'arrivée de cette Beta a été reporté plusieurs fois suite à quelques bugs importants, principalement dans l'installeur. Mais après quelques semaines de retard, la Beta est enfin là! Vous pouvez donc contribuer à son amélioration en testant cette version.

Pour télécharger la beta: http://fedoraproject.org/get-prerelease

Il peut bien entendu rester quelques problèmes, qui sont normalement référencés sur cette page: F18 Common Bugs (par exemple l'installation de MATE depuis le DVD d'installation est HS).

Plusieurs méthodes sont disponibles pour installer une Fedora 18:

• soit directement depuis un média d'installation ou un liveCD (le DVD d'installation a souvent moins de problèmes)
• soit avec preupgrade depuis une ancienne Fedora (depuis la 17 ce sera plus facile)
• soit avec yum en suivant la procédure habituelle, décrite ici
• soit avec le nouvel outil FedUp

Pour les fonctionnalités apportées par la Fedora 18, beaucoup de choix concernant l'environnement graphique:

• Gnome 3.6
• Nouvelles versions pour KDE, XFCE, Sugar
• Arrivée de MATE (fork de Gnome2)
• Cinnamon est toujours présent (fork de Gnome3)

Mais aussi un nouvel installeur, complètement repensé. Cf Anaconda 18

Pour avoir un aperçu plus détaillé des nouveautés: http://fedoraproject.org/wiki/Releases/18/FeatureList

Pour rappel la Fedora 18 "Spherical Cow" est prévue pour le 8 janvier 2013.

Bon test!

  Une fois n’est pas coutume, je vais vous donner une astuce pour Windows afin de gérer l’horloge en mode UTC, tout comme les systèmes d’exploitations dérivés d’UNIX. Si, comme moi, vous êtes un adepte du multiboot sur vos machines, ce truc vous évitera d’avoir une horloge qui se décale au fur et à mesure des [...]

Si vous êtes contributeurs Fedora, pensez à aller voter pour le nom de la prochaine Fedora, la version 19. Après le "Spherical Cow" de la Fedora 18, on commence enfin à s'éloigner de la bouffe américaine! Voici les noms proposés au vote:

• Cubical Calf
• Higgs Boson
• Loch Ness Monster
• Martian Blueberries
• Newtonian Dynamics
• Parabolic Potassium
• Schrödinger's Cat
• Tiddalik

Par contre, l'influence ubuntuesque reste encore un peu présente. Certains noms risquent en plus d'être difficile pour les graphistes (surtout pour le Schrödinger's Cat), mais on commence à avoir l'habitude de ne plus avoir de thèmes graphiques en rapport avec le nom de notre Fedora, ce qui est un peu dommage. Pour ma part j'ai une préférence pour Higgs Boson et Tiddalik, et vous?

source: ici (pour voter)

Adieu yum, ce n'est peut être pas pour tout de suite quand même! Mais cela approche...

Le fabuleux gestionnaire de paquets yum (YellowDog Updater Modified), que nous utilisons depuis les débuts de Fedora, n'a jamais cessé de s'améliorer au fil du temps. Il a toujours été simple à utiliser, pas forcément rapide ni efficace dans la gestion des dépendances au tout début, mais il est maintenant un des meilleurs gestionnaires de paquets disponibles. Son succès l'amène d'ailleurs sur la plus part des distributions basées sur des RPMs.

Ses avantages aujourd'hui sont à mon avis les suivants:

• Une seule commande comme point d'entrée (yum)
• Une gestion automatique de son cache
• Un affichage clair et efficace
• Programmé en python
• Fichiers de configuration simples et clairs
• Facilité pour développer des plugins
• Sa rapidité

Mais, bien souvent quand un produit arrive à une telle maturité, il peut être intéressant d'explorer de nouvelles pistes. Peut être pour contrer l'ennui de ses développeurs qui sait... Du coup, un fork a été crée, pas forcément avec délicatesse vis à vis des mainteneurs du yum originel, mais ça c'est fait. Le nouveau projet s'appelle DNF, ce qui ne veut rien dire car le nom est peut être temporaire. Il est censé améliorer certains points, déjà du point de vue des performances (ah?), de l'utilisation possible d'autres langages que python, et d'une mise à disposition d'une API claire et propre.

DNF est déjà disponible dans la Fedora 18, ce sera donc l'occasion de le tester. Mais il ne faudra pas s'attendre non plus à une révolution, l'ensemble du projet DNF étant un fork de yum il en utilise encore une très grande partie. D'ailleurs la commande dnf s'appellera peut être de nouveau yum quand elle pourra complètement le remplacer dans une future Fedora.

Le but premier de dnf est de fournir la bibliothèque hawkey qui s'appuie sur libsolv pour la résolution des dépendances. Pour information libsolv vient du monde openSuse. A terme toutes les résolutions de dépendances, pas forcément dans yum/dnf, sappuieront sûrement sur libsolv.

Proposer une nouvelle API, plus propre/précise, permettra aussi une meilleure intégration dans l'environnement graphique. A voir ce que cela donnera dans Gnome par exemple.

Pour tester dnf, il suffit de l'installer:

yum install dnf

Les commandes dnf sont identiques (pour l'instant?) à yum, pas la peine d'en parler:

dnf help

Le fichier de conf se trouve logiquement dans /etc/dnf/dnf.conf. A voir sur le long terme ce que donnera dnf.

Sur la prochaine Fedora 18, l'ancestral fichier /etc/sysctl.conf n'existe plus. Il faut maintenant déposer les modifications souhaitées dans un fichier .conf dans le répertoire /etc/sysctl.d.

Ce qui est dommage pour l'instant, c'est que la commande sysctl -p, que nous avions l'habitude de lancer pour prendre en compte les nouvelles modification, n'a pas connaissance de tout ceci. Elle finit donc en erreur. Ceci est dû au fait que les fichiers présents dans /etc/sysctl.d sont en réalité pris en charge par le service systemd-sysctl. Donc pour activer tout changement:

systemctl restart systemd-sysctl.service

Exemple concret pour l'activation des Magic Sysrq Keys:

echo "kernel.sysrq = 1" > /etc/sysctl.d/magic.conf
systemctl restart systemd-sysctl.service

Pour vérifier:

sysctl kernel.sysrq

Que de surprises avec cette Fedora 18!

Smolt pour ceux qui ne connaîtraient pas, est un projet pour collecter les informations matériels des utilisateurs Fedora/RedHat. Le but étant d'avoir des statistiques détaillées sur le parc d'ordinateurs tournant sous un des OS au chapeau. Cela se présentait sous forme d'une page lors du premier démarrage de la machine, après son installation, demandant si les statistiques pouvaient être envoyées sur le serveur Smolt. Les informations envoyées étaient bien sûr anonymes, et l'utilisateur, s'il le souhaitait, pouvait les compléter, principalement pour indiquer le niveau de support du matériel (bref si son pc fonctionnait sans rien faire).

Exemple de page Smolt.

Malheureusement, Smolt n'est pas super bien maintenu. Par exemple il ne fonctionne pas sous RedHat 6. L'infrastructure hébergeant le service a aussi été mal conçue à la base, et est bien trop souvent inaccessible. De plus, tout le travail sur les statistiques collectées, le besoin d'origine, est que trop difficilement exploitable. Partant de ce constat, Smolt ne sera plus utilisé et va devoir bientôt prendre sa retraite.

Ce départ en retraite sera progressif, mais il est déjà prévu pour la fin de l'année. Les requêtes seront redirigées vers des serveurs expliquant tout ceci. Ces redirections disparaîtront totalement fin 2013.

La Fedora 18 (dont la beta a été retardé) ne devrait donc logiquement plus nous proposer l'envoie des données vers Smolt.

Bien sûr le besoin d'origine, disposer de statistiques sur le matériel des utilisateurs et son bon support est toujours présent. Un remplaçant de Smolt est donc déjà prévu, ce sera le projet "Census". Pour l'instant pas plus d'information sur ce dernier.

Un des changements qui sera sûrement le plus visible dans la prochaine Fedora sera celui concernant le programme d'installation Anaconda.

Ce dernier a été complètement repensé et s'oriente vers un menu principal, puis des éléments à configurer dans l'ordre qu'on veut, avant de lancer l'installation (un peu à la slackware, en plus jolie). Fini lenchaînement d'étapes linéaires. Bien sûr tant que les éléments obligatoires n'ont pas tous été configuré, l'installation ne se lance pas.

En image pour mieux se rendre compte, avec l'écran principal:

Un exemple de page de configuration:

Notez l'emplacement du bouton "back", peut être pas le meilleur emplacement.

Enfin sur le DVD d'installation, la page pour choisir son environnement (Gnome, KDE, etc):

Je dois dire que l'aspect global est plutôt réussi, et la configuration de l'installation semble se faire en un minimum d'étapes, ce qui la rend beaucoup plus simple. Le travail n'est bien sûr pas terminé (le partitionnement est une horreur), mais c'est déjà prometteur.

L'installation en mode texte a aussi été revu sur le même principe, encore plus light du coup (style *BSD):

Faudra voir ce qu'en penses les utilisateurs??

Salut.

C'est avec beaucoup de retard, pour les raisons que j'ai exposées dans mon précédent billet, que je vous livre ces dernières mesures...

Voici les résultats comparatifs de Fedora 17 vs Fedora 16.

Pour rappel, ma machine est équipée d'un Quad Core Intel Q6600 à 2,4 GHz avec 4 Go de RAM.

Je me suis limité au benchmark UnixBench qui fournit un indice global, ce qui me simplifiera la comparaison. La version UnixBench utilisée est la version 4.1.0.

Mon protocole de tests est le suivant :

• Installation de Fedora 17 version 32 bits avec le noyau Fedora 3.3.4-5.fc17.i686.
• La machine est placée en niveau 3 (init 3).
• 10 séries de tests avec UnixBench compilé sous Fedora 17 et exécuté sous Fedora 17 (noyau Fedora 3.3.4-5.fc17.i686).
• 10 séries de tests avec UnixBench compilé sous Fedora 16 et exécuté sous Fedora 16 (noyau Fedora 3.1.0-7.fc16.i686).

Voici les résultats obtenus :

Fedora 17 version 32 bits :

Série 1 : 720.6
Série 2 : 720.1
Série 3 : 717.1
Série 4 : 728.1
Série 5 : 735.0
Série 6 : 736.3
Série 7 : 727.2
Série 8 : 719.6
Série 9 : 738.5
Série 10 : 719.7

Moyenne : 726.2

Fedora 16 version 32 bits :

Voici pour rappel les résultats obtenus avec Fedora 16 :
Série 1 : 668.1
Série 2 : 677.7
Série 3 : 675.3
Série 4 : 679.0
Série 5 : 677.3
Série 6 : 674.6
Série 7 : 682.3
Série 8 : 686.7
Série 9 : 683.7
Série 10 : 679.1

Moyenne : 678.4

Résultats :

Pour Fedora 17, on obtient un indice moyen de 726.2 pour UnixBench.
Pour Fedora 16, j'avais obtenu un indice moyen de 678.4 pour UnixBench.


On a donc un gain moyen de près de 7.0 % de Fedora 17 32 bits par rapport à Fedora 16 32 bits...
On assiste encore à une légère amélioration des performances comme montré sur la figure suivante :

Conclusion :

Au moment de ces tests, le noyau Fedora 17 (basé sur le noyau vanilla 3.3.4) propose un gain de 7 % par rapport au noyau Fedora 16 (basé sur le noyau vanilla 3.1.0), ce qui le ramène au niveau de Fedora 9.


++