- Modifié
Retour sur expérience de FC6.
J'utilise FC6 depuis la test2.
Des images CD de FC6 finale sont tombée d'un camion avant sa sortie et je l'ai installé hier en faisant une installation fraiche (pas une mise à jour) histoire d'avoir quelque chose de peut-être plus propre (ma bécane a peut-être vu passé 5 Go de mise à jour depuis FC6 test2). Ben en fait cette nouvelle installation n'a rien changé 🙂
Installation
La nouveauté est de pouvoir ajouter directement Extras lors de l'installation. C'est une avancée importante pour Fedora. Pas forcément techniquement. Ça marque que Fedora Core et Fedora Extras forment un tout qui est la distribution Fedora. On peut aussi y ajouter n'importe quelle dépôt (en spécifiant l'url qui va bien). Par contre il faut le réseau et je n'ai pas de réseau à l'installation. Donc je n'ai pas testé. C'est très intéressant pour les mises à jours. Pour une installation c'est d'un intérêt plus limité.
J'ai été bluffé par la rapidité de l'installation. Au moment où l'installation des paquets débute jusqu'à la fin : 10 minutes !
Pourtant je n'ai pas une bête de course (Athon 1600 XP (1200 MHz)).
A celà quelques explications. L'installation par défaut (poste client) a été allégée. En plus, j'ai l'habitude de faire des installations très légères en virant ce que je ne pense pas utiliser. Après, à l'utilisation j'ajoute ce qui me manque. Avec les précédentes Fedora, via le biais de dépendances rpm et du fichier qui définit les groupes, plein de choses que je n'avais pas demandées était néanmoins installées. Maintenant c'est beaucoup moins. Mon installation au premier boot ne prenait qu'un peu moins de 2 Go. Après l'installation, virer ce que je n'utilises pas ne m'a pas pris beaucoup de temps. Ceci intéressera beaucoup ceux qui font des installations personnalisés et automatiques (déployement de machine) via kickstart.
A l'installation j'ai même pu virer rhgb (l'interface graphique au boot). Donc je ne peux dire à quoi ça ressemble (je ne l'utilisais pas avec Test 2). "Mieux", dbus-X11 n'était pas installé ce qui m'a valu quelques protestations de Gnome au premier login. Je l'ai installé et tout est rentré dans l'ordre. Idem, bien que j'utilise Gnome (et gnome-panel), je peux virer gnome-session (un bug est un bug...).
J'insiste sur ce point, l'effort est très significatif. Par exemple avec l'installation de faite je boote en 40 secondes ! Avant j'étais autour de 55 secondes. Maintenant que j'ai tout au petit oignon je suis à 30 secondes ce qui est un poil mieux que sous FC5 aux petits oignons. C'est aux petits oignons mais sans bidouiller les scripts de boots. Tout est "respecté", je ne fais que virer les paquets que je n'utilise pas ou faire quelques "chkconfig bidule off" . Le temps de boot n'est pas de mes préoccupations, mais ici c'est un bon indicateur.
Anaconda
Anaconda peut utiliser une mise à jour de lui-même. Ça peut-être particuliairement utile lorsque qu'anaconda ne marche pas pour une configuration spécifique. Il suffit d'avoir la mise à jour (inutile sans graver un nouveau CD) et d'indiquer à anaconda où est la mise. Et c'est partie...
Reste plus qu'a espérer que cette fonction sera utilisée. Pour certain problème, il n'y a que cette méthode qui peut marcher.
Le nouveau look
Les couleurs de Fedora sont maintenant moins fades avec theme NDA. L'image de Fedora y gagne beaucoup. On retrouve NDA dans grub, écran de loggin et le papier par défaut. L'écran de loggin est particuliairement réussi.
Le theme par défaut sous Gnome (je n'ai testé KDE, ni XFCE) est Clearlook (Bluecurve a fait long feu). Le thème est assez travaillé. Coloré sans être agressif ou rentré dans la catégorie jouet. C'est finement réalisé peut-être pas encore totalement abouti. C'est mieux que le thème précédent.
Les nouveaux icones sont comme on les attends pour un système moderne. En 3d (perceptive), compréhensibles et colorés (sans être criant). Elle sont dérivée de Bluecurve. Les icones Gnome prennent un gros coup de vieux à côté.
Le tout est vraiment agréable et sympatique. Ça peut être encore amélioré.
Pas de screenshot ici, il y a aura plein dans une semaine 🙂
Puis j'utilise le thème Thinice pour les contrôles 🙂 Par pour des raisons esthétique mais car il y est moins fatiguant (pas de fond blanc).
Gnome
C'est Gnome 2.16, dans la lignée de 2.14. C'est plus rapide, ça bouffe moins de mémoire, etc...
Le gain de performance vient peut-être aussi de l'utilisation de glibc 2.5. C'est une premier pour une distribution. Glibc permet d'utiliser LD_GNU_HASH : gain mesuré de 50 % pour l'édition lien ; hors temps accès disque évidemment. Tout a été compilé avec cette fonctionnalité.
Je n'ai pas le bon profile pour m'étendre sur Gnome. Je suis un accro de la ligne de commande, et j'ai même fait un "yum remove nautilus gnome-utils" 🙂
Non que je trouve nautilus naze, mais seulement car je ne l'utilise pas. Mais avant de le virer j'ai fait quelques tests pour voir. Notamment, j'ai "bidouillé" avec le multi-média. Totem et gstreamer se sont sérieusement améliorés et ont énormément gagné en qualité. C'est bien intégré à Gnome avec nautilus qui donne une petit image du film. L'interface de Totem est excellente pour un lecteur vidéo par défaut. C'est du "just works", c'est intuitif, comme l'aime Gnome. Un petit reproche, la synchronisation n'est pas encore du niveau de Mplayer. Il y a des petits accous. Rien de grave, il faut regarder attentivement. Le plugin Totem pour Firefox marche particuliairement bien. Globalement "c'est que du bonheur". Peut-être manque-il un système de plugin pour utiliser des fonctionnalités avancés comme c'est fait avec epiphany (je vous conseille de faire un essai avec ce dernier via un "yum install epiphany-extensions").
Evidemment, il faut installer gstreamer-plugins-ugly (ugly car taché de brevets) et gstreamer-ffmpeg si on veut lire autre chose que du ogg. On trouvera ça dans http://rpm.livna.org/ . L'avantage de livna sur freshrpms/etc est qu'il ne remplace jamais des paquets de Fedora Extras ni les concurrences. C'est un addon de FC+FE. Ça garantit une bonne cohérence du système dans le temps et moins de problème de dépendance. Freshrpms a fait mon bonheur, reste un dépôt fabuleux, mais j'ai switché maintenant sur Extras+livna. Longue vie à Freshrpms.
Saluons le travail des dépôts externes à Fedora, ils sont déjà (presque?) tous à FC6. Mais mieux, alors que j'utilisais FC6 test2, rien ne me manquait. C'est vraiment agréable. C'est un gros plus lors des phases de test.
Le système de paquet
C'est du rpm, rien ne change ici. Il a des évolutions qui seront peu visibles pour la majorité des gens. Notons que c'est un fork du rpm officel. Fedora n'est pas satisfait de la direction que prend rpm actuellement. Fedora utilise un version "forckée" depuis rpm 4.4.2, la dernière version officielle est la version 4.4.7. La situation est floue, peut-être que Fedora et Novell vont initialiser un nouveau projet (en partant des sources de la version 4.4.2).
Le reste s'appuit massivement sur Yum. Anaconda utilise Yum (depuis FC5). D'ailleurs RHEL 5 n'utilisera que Yum.
Il y a Yum en ligne de commande (+ des goodies avec yum-utils, yum-versionlock, yum-updateonboot, yum-skip-broken, repoquery, etc).
Il y a pirut comme interface graphique à Yum et qui prend en charge les fichiers comps.xml (définition de groupes d'un niveau supérieur aux groupes de rpm). L'interface est simple et très bien pensée. Mais il reste encore quelques bugs. Entre autre il se mélange les crayons lorsques plusieurs dépôts utilisent un comps.xml. Par exemple j'ai 5 "Applications|Environnement de bureau KDE". Peut-être que les fichiers comps.xml sont erronés mais j'en doute. MODIFICATION : Je me suis trompé, les comps.xml étaient buggués. Ça marche maintenant comme prévu. La boite détail n'affiche pas les retours à la ligne. Mais pour une application "tout public" elle est bien pensée. Par contre c'est trop lent lorsqu'on change d'onglet (heureusement il y a une "barre de progression/d'attente"), certaines informations de contexte sont perdues (du moins ne sont plus affichées).
FC6 inaugure yum-updatesd. Yum-updatesd regarde s'il y a des mises à jours et le communique via dbus ou mail ou syslog. Via dbus, il va réveiller l'applet puplet qui va afficher qu'il y a des paquets à mettres à jour et combien. Un clique sur l'applet demande le mot de passe root et lance le programme pup pour faire la mise à jour. Comme pour pirut, pup est d'une simplicité enfantine.
Yum-updatesd peut être configuré pour downloader automatiquement les mises à jours qu'il installera immédiatement ou à la demande. Malheureusement à ne marchepas (ou il y a un truc que je n'ai pas compris).
Avec Yum, pirut, puplet, pup, yum-updatesd, il y a maintenant un ensemble complet et cohérent. Bien que la faible vitesse de Yum ne m'ait jamais particuliairement énervée, il est temps d'optimiser sérieusement tout ça car c'est maintenant le défaut le plus criant. Un pas en avant a été fait pour parser plus rapidement les fichiers xml des dépôts.
Globalement, il y a de belles avancées dans le domaine de la gestion des paquets, et dans la bonne direction. Mais globalement je suis aussi déçu. J'ai rencontré plusieurs problèmes comme des deadlocks avec rpm, Yum qui passe un temps fou a trifouiller dans ses bases sqlites sans raisons compréhensibles, pirut qui je mélange les crayons avec les groupes, yum-updatesd qui ne downloade pas, parfois le cache dans sqlite n'est pas à jour, yumdownloader qui ne marche pas non plus.
Ce n'est pas dramatique, mais pour moi ce sont de mauvais signes. Espérons que des corrections arrivent et que le tout soit d'une qualité supérieure.
Raison possible : Yum est passé en version 3.0 il y a 3 semaines.
Espoir : Yum, pirut, etc est dans RHEL 5, Red Hat veillera sûrement à corriger tout ça.
Relativons, ça marche dans la majorité des cas, je n'ai pas perdu de données, etc...
Puis il y a Smart dans FE si Yum fait faux-bon.
Le noyau
Ici un 2.6.18.1.
Globalement du mieux. Ma carte dvb ne marche plus (ce n'est pas spécifique à Fedora). M'enfin se sont des choses qui arrivent. Quand 10 bugs sont corrigés il y en a toujours au moins un qui est créé.
L'horloge RTC a été revue dans 2.6.18 et ne me satisfait pas. Des petits accros avec Mplayer. Une recompilation pour avoir un noyau aux petits oignons et utiliser l'ancien RTC corrige ça. Peut-être un problème Mplayer qui doit être adapté au nouveau RTC ?
Ext3 a eu un petit coup de boost dans la lecture des gros fichiers. Je tape facilement le 100 Mo/s avec ma vieille bécane ! C'est maintenant mon cpu qui est presque trop limité pour le débit.
l'init
Fedora support les disques usb au boot. C'est-à-dire qu'on peut utiliser un périphérique usb pour la partition racine. C'est encore un peu rock'n roll car il faut que le bios et grub suivent. Evidemment initrd c'est vu ajouter les modules usb qui vont bien.
udev
Globalement Fedora a une structure très solide et très souple.
Exemple de /dev automatiquement remplis :
[c]/dev/disk/
/dev/disk/by-path
/dev/disk/by-path/pci-0000:00:06.2-usb-0:2:1.0-scsi-0:0:0:0
/dev/disk/by-path/pci-0000:00:11.1-ide-0:0-part3
/dev/disk/by-path/pci-0000:00:11.1-ide-0:0-part1
[...]
/dev/disk/by-id/usb-0930_USB_Flash_Memory_0E21285022F268AC
/dev/disk/by-id/ata-Maxtor_6Y080L0_Y28G0SEE-part3
/dev/disk/by-id/ata-Maxtor_6Y080L0_Y28G0SEE-part1
[...]
/dev/disk/by-label
/dev/disk/by-label/big_b3
/dev/disk/by-label/big_b1
/dev/disk/by-label/big_c3
[...]
/dev/disk/by-uuid
/dev/disk/by-uuid/4d8be246-0959-4760-93da-7340446b2baa
/dev/disk/by-uuid/72abcf17-7925-2b28-77d9-d218c8b8e4eb[/c]
Pour charger automatiquement un module il suffit d'ajouter un fichier dans /etc/sysconfig/modules/.
Pour les droits par défaut, ajouter un fichier à /etc/makedev.d/
Pour les droits, au-lieu de bidouiller avec les groupes, il suffit de placer un fichier dans /etc/security/console.perms.d/.
La création du fichier spécial est toujours assuré par un fichier dans /etc/udev/rules.d/.
La configuration du périphérique après chargement du module peut-être assurée par un petit fichier dans /etc/dev.d/.
Cette structure permet de fournir des parquets avec des drivers qui marchent "out of the box" au-lieu de demander à l'utiliser d'éditer des fichiers obscures.
Pour l'interfaçage avec l'utilisateur il y a aussi Hal. Linux a vraiment un ensemble qui roxor aujourd'hui.
Certains vont dire : Et l'absence de compatibilité binaire du noyau qui impose de recompiler les modules à la moindre mise à jour du noyau !
Ben Fedora a un petit plus. Je crois que l'idée est de Novell. Ce n'est pas finalisé mais c'est intéressant.
Exemple :
[c]$ rpm -q --provides kernel-2.6.18-1.2798.fc6
[...]
kernel(drivers_message_i2o) = 6dd362f04cfc1c2161cc0eab83928f7f27abd61b
kernel(drivers_pci_hotplug) = 6b499a15a23b4edea9f55a61f8d9c9b81bd11d34
kernel(drivers_connector) = cb480a023f9e2ae65059bed901c8b25da49b199d
kernel(drivers_media_dvb_dvb_core) = ec81df442f0249252dedd9477c9817bbf0bb638d
kernel(drivers_usb_serial) = b907905e3e41fa287cc36df025784c83f47ab8f3
[...][/c]
C'est-à-dire que l'api de noyau est signé par catégorie d'api.
Si j'ai un module qui demande l'api drivers_usb_serial dont la signature est b907905e3e41fa287cc36df025784c83f47ab8f3, et si le noyau la fournie, le module sera chargé et devrait marché. Le noyau ne va pas "bêtement" refusé le module car il n'est pas de la même version que le noyau (2.6.18.1 != 2.6.18.2 par exemple). Donc si l'api concernée pour le chargement d'un module ne change pas, le module est chargé même si le module a été compilé pour un 2.6.18 et qu'on utilise un 2.6.37. Alors qu'avant, c'était "non" même si ça pouvait marché. NB : un changement de configuration du noyau peut (ce n'est pas obligé) aussi changer l'api.
En exemple, module-init-tools a maintenant le programme /sbin/weak-modules. En gros ce programme recherche dans les anciens modules ceux qui peuvent être utiliser pour le noyau spécifié en ligne de commande. S'il en trouve (en regardant la signature des api), il les met dans /lib/modules/2.6.../weak-updates/ .
Ainsi pour prendre un mauvais exemple, le driver proprio NVidia pour un ancien noyau sera peut-être récupéré pour le nouveau noyau.
C'est utilisé lors de l'installation d'un noyau.
[c]$ rpm -q --scripts kernel-2.6.18-1.2798.fc6
postinstall scriptlet (using /bin/sh):
[...]
/sbin/weak-modules --add-kernel 2.6.18-1.2798.fc6
[...][/c]
On a vu que rpm indique les signatures des apis pour le noyau. Malheureusement il n'y a pas encore le système réciproque pour les paquets qui fournissent un module. Ainsi on a toujours pour kmod-bidule "require kernel=2.6.18-1.2798" et non "require kernel(drivers_usb_serial) = b907905e3e41fa287cc36df025784c83f47ab8f3" par exemple.
Il reste encore beaucoup d'étape pour que ça marche "out of the box".
Xorg
C'est le 7.1, donc avec AIGLX.
J'ai une malheureuse G400 mais ça marche avec compiz (il faut un résolution inférieure à 1024).
J'ai testé, la 3D c'est bien, mais compiz c'est naze.
Je ferais un nouvelle essai quand Metacity supportera la 3d.
Pour information, si vous voulez ou avez besoin de désactiver AIGLX ou Xcompose :
[c]/etc/X11/xorg.conf :
Section "ServerFlags"
Option "AIGLX" "off"
EndSection
Section "Extensions"
Option "Composite" "Disable"
EndSection[/c]
Avec FC6 on peut dire que Fedora par défaut ne configure plus le fichier /etc/X11/xorg.conf. D'une certaine manière, c'est le même pour tout le mode (sauf pour le clavier : azerty ou qwerty par exemple). Xorg se configure automatique en fonction des périphériques qu'il trouve. Donc à l'installation Fedora ne demande rien pour Xorg et ne configure rien (sauf le clavier) ! L'utilisateur (et pas l'administrateur) peut choisir parmis les configurations adaptés au hardware via xrandr (ou en graphique avec gnome-display-properties dans le menu "Système|Préférence" ).
C'est une excellente idée, mais pas pour tous les cas. On peut refaire à la main un system-config-display pour avoir un /etc/X11/xorg.conf complet. C'est utile dans mon cas où le moniteur ne fournit aucune indication (donc Xorg passe en 800x600). Attention, le but de Fedora n'est pas de virer le fichier /etc/X11/xorg.conf. Il peut toujours servire.
Java
Plugin java (via gcj) dans Firefox. N'est pas activé par défaut (voir le fichier : /usr/share/doc/libgcj-4.1.1/README.libgcjwebplugin.so). Il reste des problèmes de sécurité qui devrait être corrigé pour FC7. Actuellement pour chaque applet, un message demande confirmation pour lancer l'applet. On peut aussi indiquer que l'applet est de confiance pour qu'elle soit lancée automatiquement la prochaine fois ou qu'elle n'est définitivement pas de confiance.
Ça ne marche pas pour tout, mais ça marche déjà pour beaucoup de chose. C'est au moins excellent pour les développeurs libres. Il peuvent au moins vérifier que ça marche avec l'implentation libre et ainsi fournir quelque chose qui n'est pas dépendant d'un jre proprio.
crypto
Il est maintenant facile d'utiliser des FS cryptés ainsi que le swap avec cryptsetup-luks. Comme en plus c'est intégré à Hal et gnome-mount, ça marche nickel sous Gnome qui ouvre une boite de dialogue pour saisir un mot de passe lorsqu'on insére une clée usb cryptée. L'intégration dans Hal était peut-être déjà dans FC5. Mais cryptsetup-luks est nouveau.
Xen
Le gros morceau. Ce n'est pas encore sans quelques hics.
Virt-manager fait des merveilles et parfois on croit utiliser vmware 🙂 En quelques cliques on crée une nouvelle machine complète avec son OS et on se loggue graphiquement.
Console virtuelle affichée dans X11, utilisation automatique de vnc, etc...
On peut aussi installer FC6 dans FC6 via Anaconda.
Tout ça prend furieusement la voie du "out of the box".
Je n'ai pas beaucoup utilisé Xen car ma bécane n'a que 512 Mo. Mais mes tests me disent que pour FC7 ça va roxer des ours et que beaucoup vont utiser Xen sur une bécane perso (tester Rawhide, tester un truc sans poluer l'installation en cours, etc).
Puis avec la technologie VT, on pourra faire tourner Windows dans Linux avec d'excellentes performances.
J'utilise pas Windows chez moi. Mais au boulot oui. Avoir une bécane sous Linux avec un windows dans un coin sans rebooter pour avoir des performances décentes serait un plus énorme.
Je sens que dans quelque mois je vais acheter un nouveau PC...
Mock
Mock permet de compiler un paquet dans un environnement chrooté. Il installe toute les dépendances en suivant les "requires/buildrequires" de rpm. Il est ainsi plus facile de renseigner les "Buildrequires".
FC6 a été compilé avec Mock. Idem pour Fedora Extras.
C'est facile à utiliser. Mais il convient d'avoir tous les paquets en local (rsync et createrepo sont tes amis) sinon à chaque fois on downloade des tonnes de paquets.
Mock n'est pas nouveau, mais c'est la première fois que je l'utilise. Surtout n'hésité pas à l'utiliser.
Bon, j'arrête ici, c'est déjà trop long. Il y a tant de chose dans une distribution Linux, qu'on n'en fait jamais le tour.
Les tests se termine en générale par "je conseille cette distribution à ...".
Fedora est spécial. Le but de Fedora n'est pas d'avoir des grosses parts de marché. Fedora ne cible pas un type d'utilisateur particulier. Fedora est là pour faire évoluer le logiciel libre, pour avoir Linux sur PS3 (c'est un fork de Fedora), pour aider OLPC, pour RHEL, pour les développeurs upstream, etc. Fedora c'est avant tout un projet et non une distribution. Sa cible principale, s'il y en a une, est donc les développeurs. Mais un développeur est aussi un utilisateur, un développeur n'évalue son travail qu'avec des utilisateurs et travail pour des utilisateurs. Alors certe, les utilisateurs n'est pas la cible principale de Fedora, mais beaucoup a été fait pour que Fedora soit utile.
Sortie officielle de FC6 le 24/10/06.
J'utilise FC6 depuis la test2.
Des images CD de FC6 finale sont tombée d'un camion avant sa sortie et je l'ai installé hier en faisant une installation fraiche (pas une mise à jour) histoire d'avoir quelque chose de peut-être plus propre (ma bécane a peut-être vu passé 5 Go de mise à jour depuis FC6 test2). Ben en fait cette nouvelle installation n'a rien changé 🙂
Installation
La nouveauté est de pouvoir ajouter directement Extras lors de l'installation. C'est une avancée importante pour Fedora. Pas forcément techniquement. Ça marque que Fedora Core et Fedora Extras forment un tout qui est la distribution Fedora. On peut aussi y ajouter n'importe quelle dépôt (en spécifiant l'url qui va bien). Par contre il faut le réseau et je n'ai pas de réseau à l'installation. Donc je n'ai pas testé. C'est très intéressant pour les mises à jours. Pour une installation c'est d'un intérêt plus limité.
J'ai été bluffé par la rapidité de l'installation. Au moment où l'installation des paquets débute jusqu'à la fin : 10 minutes !
Pourtant je n'ai pas une bête de course (Athon 1600 XP (1200 MHz)).
A celà quelques explications. L'installation par défaut (poste client) a été allégée. En plus, j'ai l'habitude de faire des installations très légères en virant ce que je ne pense pas utiliser. Après, à l'utilisation j'ajoute ce qui me manque. Avec les précédentes Fedora, via le biais de dépendances rpm et du fichier qui définit les groupes, plein de choses que je n'avais pas demandées était néanmoins installées. Maintenant c'est beaucoup moins. Mon installation au premier boot ne prenait qu'un peu moins de 2 Go. Après l'installation, virer ce que je n'utilises pas ne m'a pas pris beaucoup de temps. Ceci intéressera beaucoup ceux qui font des installations personnalisés et automatiques (déployement de machine) via kickstart.
A l'installation j'ai même pu virer rhgb (l'interface graphique au boot). Donc je ne peux dire à quoi ça ressemble (je ne l'utilisais pas avec Test 2). "Mieux", dbus-X11 n'était pas installé ce qui m'a valu quelques protestations de Gnome au premier login. Je l'ai installé et tout est rentré dans l'ordre. Idem, bien que j'utilise Gnome (et gnome-panel), je peux virer gnome-session (un bug est un bug...).
J'insiste sur ce point, l'effort est très significatif. Par exemple avec l'installation de faite je boote en 40 secondes ! Avant j'étais autour de 55 secondes. Maintenant que j'ai tout au petit oignon je suis à 30 secondes ce qui est un poil mieux que sous FC5 aux petits oignons. C'est aux petits oignons mais sans bidouiller les scripts de boots. Tout est "respecté", je ne fais que virer les paquets que je n'utilise pas ou faire quelques "chkconfig bidule off" . Le temps de boot n'est pas de mes préoccupations, mais ici c'est un bon indicateur.
Anaconda
Anaconda peut utiliser une mise à jour de lui-même. Ça peut-être particuliairement utile lorsque qu'anaconda ne marche pas pour une configuration spécifique. Il suffit d'avoir la mise à jour (inutile sans graver un nouveau CD) et d'indiquer à anaconda où est la mise. Et c'est partie...
Reste plus qu'a espérer que cette fonction sera utilisée. Pour certain problème, il n'y a que cette méthode qui peut marcher.
Le nouveau look
Les couleurs de Fedora sont maintenant moins fades avec theme NDA. L'image de Fedora y gagne beaucoup. On retrouve NDA dans grub, écran de loggin et le papier par défaut. L'écran de loggin est particuliairement réussi.
Le theme par défaut sous Gnome (je n'ai testé KDE, ni XFCE) est Clearlook (Bluecurve a fait long feu). Le thème est assez travaillé. Coloré sans être agressif ou rentré dans la catégorie jouet. C'est finement réalisé peut-être pas encore totalement abouti. C'est mieux que le thème précédent.
Les nouveaux icones sont comme on les attends pour un système moderne. En 3d (perceptive), compréhensibles et colorés (sans être criant). Elle sont dérivée de Bluecurve. Les icones Gnome prennent un gros coup de vieux à côté.
Le tout est vraiment agréable et sympatique. Ça peut être encore amélioré.
Pas de screenshot ici, il y a aura plein dans une semaine 🙂
Puis j'utilise le thème Thinice pour les contrôles 🙂 Par pour des raisons esthétique mais car il y est moins fatiguant (pas de fond blanc).
Gnome
C'est Gnome 2.16, dans la lignée de 2.14. C'est plus rapide, ça bouffe moins de mémoire, etc...
Le gain de performance vient peut-être aussi de l'utilisation de glibc 2.5. C'est une premier pour une distribution. Glibc permet d'utiliser LD_GNU_HASH : gain mesuré de 50 % pour l'édition lien ; hors temps accès disque évidemment. Tout a été compilé avec cette fonctionnalité.
Je n'ai pas le bon profile pour m'étendre sur Gnome. Je suis un accro de la ligne de commande, et j'ai même fait un "yum remove nautilus gnome-utils" 🙂
Non que je trouve nautilus naze, mais seulement car je ne l'utilise pas. Mais avant de le virer j'ai fait quelques tests pour voir. Notamment, j'ai "bidouillé" avec le multi-média. Totem et gstreamer se sont sérieusement améliorés et ont énormément gagné en qualité. C'est bien intégré à Gnome avec nautilus qui donne une petit image du film. L'interface de Totem est excellente pour un lecteur vidéo par défaut. C'est du "just works", c'est intuitif, comme l'aime Gnome. Un petit reproche, la synchronisation n'est pas encore du niveau de Mplayer. Il y a des petits accous. Rien de grave, il faut regarder attentivement. Le plugin Totem pour Firefox marche particuliairement bien. Globalement "c'est que du bonheur". Peut-être manque-il un système de plugin pour utiliser des fonctionnalités avancés comme c'est fait avec epiphany (je vous conseille de faire un essai avec ce dernier via un "yum install epiphany-extensions").
Evidemment, il faut installer gstreamer-plugins-ugly (ugly car taché de brevets) et gstreamer-ffmpeg si on veut lire autre chose que du ogg. On trouvera ça dans http://rpm.livna.org/ . L'avantage de livna sur freshrpms/etc est qu'il ne remplace jamais des paquets de Fedora Extras ni les concurrences. C'est un addon de FC+FE. Ça garantit une bonne cohérence du système dans le temps et moins de problème de dépendance. Freshrpms a fait mon bonheur, reste un dépôt fabuleux, mais j'ai switché maintenant sur Extras+livna. Longue vie à Freshrpms.
Saluons le travail des dépôts externes à Fedora, ils sont déjà (presque?) tous à FC6. Mais mieux, alors que j'utilisais FC6 test2, rien ne me manquait. C'est vraiment agréable. C'est un gros plus lors des phases de test.
Le système de paquet
C'est du rpm, rien ne change ici. Il a des évolutions qui seront peu visibles pour la majorité des gens. Notons que c'est un fork du rpm officel. Fedora n'est pas satisfait de la direction que prend rpm actuellement. Fedora utilise un version "forckée" depuis rpm 4.4.2, la dernière version officielle est la version 4.4.7. La situation est floue, peut-être que Fedora et Novell vont initialiser un nouveau projet (en partant des sources de la version 4.4.2).
Le reste s'appuit massivement sur Yum. Anaconda utilise Yum (depuis FC5). D'ailleurs RHEL 5 n'utilisera que Yum.
Il y a Yum en ligne de commande (+ des goodies avec yum-utils, yum-versionlock, yum-updateonboot, yum-skip-broken, repoquery, etc).
Il y a pirut comme interface graphique à Yum et qui prend en charge les fichiers comps.xml (définition de groupes d'un niveau supérieur aux groupes de rpm). L'interface est simple et très bien pensée. Mais il reste encore quelques bugs. Entre autre il se mélange les crayons lorsques plusieurs dépôts utilisent un comps.xml. Par exemple j'ai 5 "Applications|Environnement de bureau KDE". Peut-être que les fichiers comps.xml sont erronés mais j'en doute. MODIFICATION : Je me suis trompé, les comps.xml étaient buggués. Ça marche maintenant comme prévu. La boite détail n'affiche pas les retours à la ligne. Mais pour une application "tout public" elle est bien pensée. Par contre c'est trop lent lorsqu'on change d'onglet (heureusement il y a une "barre de progression/d'attente"), certaines informations de contexte sont perdues (du moins ne sont plus affichées).
FC6 inaugure yum-updatesd. Yum-updatesd regarde s'il y a des mises à jours et le communique via dbus ou mail ou syslog. Via dbus, il va réveiller l'applet puplet qui va afficher qu'il y a des paquets à mettres à jour et combien. Un clique sur l'applet demande le mot de passe root et lance le programme pup pour faire la mise à jour. Comme pour pirut, pup est d'une simplicité enfantine.
Yum-updatesd peut être configuré pour downloader automatiquement les mises à jours qu'il installera immédiatement ou à la demande. Malheureusement à ne marchepas (ou il y a un truc que je n'ai pas compris).
Avec Yum, pirut, puplet, pup, yum-updatesd, il y a maintenant un ensemble complet et cohérent. Bien que la faible vitesse de Yum ne m'ait jamais particuliairement énervée, il est temps d'optimiser sérieusement tout ça car c'est maintenant le défaut le plus criant. Un pas en avant a été fait pour parser plus rapidement les fichiers xml des dépôts.
Globalement, il y a de belles avancées dans le domaine de la gestion des paquets, et dans la bonne direction. Mais globalement je suis aussi déçu. J'ai rencontré plusieurs problèmes comme des deadlocks avec rpm, Yum qui passe un temps fou a trifouiller dans ses bases sqlites sans raisons compréhensibles, pirut qui je mélange les crayons avec les groupes, yum-updatesd qui ne downloade pas, parfois le cache dans sqlite n'est pas à jour, yumdownloader qui ne marche pas non plus.
Ce n'est pas dramatique, mais pour moi ce sont de mauvais signes. Espérons que des corrections arrivent et que le tout soit d'une qualité supérieure.
Raison possible : Yum est passé en version 3.0 il y a 3 semaines.
Espoir : Yum, pirut, etc est dans RHEL 5, Red Hat veillera sûrement à corriger tout ça.
Relativons, ça marche dans la majorité des cas, je n'ai pas perdu de données, etc...
Puis il y a Smart dans FE si Yum fait faux-bon.
Le noyau
Ici un 2.6.18.1.
Globalement du mieux. Ma carte dvb ne marche plus (ce n'est pas spécifique à Fedora). M'enfin se sont des choses qui arrivent. Quand 10 bugs sont corrigés il y en a toujours au moins un qui est créé.
L'horloge RTC a été revue dans 2.6.18 et ne me satisfait pas. Des petits accros avec Mplayer. Une recompilation pour avoir un noyau aux petits oignons et utiliser l'ancien RTC corrige ça. Peut-être un problème Mplayer qui doit être adapté au nouveau RTC ?
Ext3 a eu un petit coup de boost dans la lecture des gros fichiers. Je tape facilement le 100 Mo/s avec ma vieille bécane ! C'est maintenant mon cpu qui est presque trop limité pour le débit.
l'init
Fedora support les disques usb au boot. C'est-à-dire qu'on peut utiliser un périphérique usb pour la partition racine. C'est encore un peu rock'n roll car il faut que le bios et grub suivent. Evidemment initrd c'est vu ajouter les modules usb qui vont bien.
udev
Globalement Fedora a une structure très solide et très souple.
Exemple de /dev automatiquement remplis :
[c]/dev/disk/
/dev/disk/by-path
/dev/disk/by-path/pci-0000:00:06.2-usb-0:2:1.0-scsi-0:0:0:0
/dev/disk/by-path/pci-0000:00:11.1-ide-0:0-part3
/dev/disk/by-path/pci-0000:00:11.1-ide-0:0-part1
[...]
/dev/disk/by-id/usb-0930_USB_Flash_Memory_0E21285022F268AC
/dev/disk/by-id/ata-Maxtor_6Y080L0_Y28G0SEE-part3
/dev/disk/by-id/ata-Maxtor_6Y080L0_Y28G0SEE-part1
[...]
/dev/disk/by-label
/dev/disk/by-label/big_b3
/dev/disk/by-label/big_b1
/dev/disk/by-label/big_c3
[...]
/dev/disk/by-uuid
/dev/disk/by-uuid/4d8be246-0959-4760-93da-7340446b2baa
/dev/disk/by-uuid/72abcf17-7925-2b28-77d9-d218c8b8e4eb[/c]
Pour charger automatiquement un module il suffit d'ajouter un fichier dans /etc/sysconfig/modules/.
Pour les droits par défaut, ajouter un fichier à /etc/makedev.d/
Pour les droits, au-lieu de bidouiller avec les groupes, il suffit de placer un fichier dans /etc/security/console.perms.d/.
La création du fichier spécial est toujours assuré par un fichier dans /etc/udev/rules.d/.
La configuration du périphérique après chargement du module peut-être assurée par un petit fichier dans /etc/dev.d/.
Cette structure permet de fournir des parquets avec des drivers qui marchent "out of the box" au-lieu de demander à l'utiliser d'éditer des fichiers obscures.
Pour l'interfaçage avec l'utilisateur il y a aussi Hal. Linux a vraiment un ensemble qui roxor aujourd'hui.
Certains vont dire : Et l'absence de compatibilité binaire du noyau qui impose de recompiler les modules à la moindre mise à jour du noyau !
Ben Fedora a un petit plus. Je crois que l'idée est de Novell. Ce n'est pas finalisé mais c'est intéressant.
Exemple :
[c]$ rpm -q --provides kernel-2.6.18-1.2798.fc6
[...]
kernel(drivers_message_i2o) = 6dd362f04cfc1c2161cc0eab83928f7f27abd61b
kernel(drivers_pci_hotplug) = 6b499a15a23b4edea9f55a61f8d9c9b81bd11d34
kernel(drivers_connector) = cb480a023f9e2ae65059bed901c8b25da49b199d
kernel(drivers_media_dvb_dvb_core) = ec81df442f0249252dedd9477c9817bbf0bb638d
kernel(drivers_usb_serial) = b907905e3e41fa287cc36df025784c83f47ab8f3
[...][/c]
C'est-à-dire que l'api de noyau est signé par catégorie d'api.
Si j'ai un module qui demande l'api drivers_usb_serial dont la signature est b907905e3e41fa287cc36df025784c83f47ab8f3, et si le noyau la fournie, le module sera chargé et devrait marché. Le noyau ne va pas "bêtement" refusé le module car il n'est pas de la même version que le noyau (2.6.18.1 != 2.6.18.2 par exemple). Donc si l'api concernée pour le chargement d'un module ne change pas, le module est chargé même si le module a été compilé pour un 2.6.18 et qu'on utilise un 2.6.37. Alors qu'avant, c'était "non" même si ça pouvait marché. NB : un changement de configuration du noyau peut (ce n'est pas obligé) aussi changer l'api.
En exemple, module-init-tools a maintenant le programme /sbin/weak-modules. En gros ce programme recherche dans les anciens modules ceux qui peuvent être utiliser pour le noyau spécifié en ligne de commande. S'il en trouve (en regardant la signature des api), il les met dans /lib/modules/2.6.../weak-updates/ .
Ainsi pour prendre un mauvais exemple, le driver proprio NVidia pour un ancien noyau sera peut-être récupéré pour le nouveau noyau.
C'est utilisé lors de l'installation d'un noyau.
[c]$ rpm -q --scripts kernel-2.6.18-1.2798.fc6
postinstall scriptlet (using /bin/sh):
[...]
/sbin/weak-modules --add-kernel 2.6.18-1.2798.fc6
[...][/c]
On a vu que rpm indique les signatures des apis pour le noyau. Malheureusement il n'y a pas encore le système réciproque pour les paquets qui fournissent un module. Ainsi on a toujours pour kmod-bidule "require kernel=2.6.18-1.2798" et non "require kernel(drivers_usb_serial) = b907905e3e41fa287cc36df025784c83f47ab8f3" par exemple.
Il reste encore beaucoup d'étape pour que ça marche "out of the box".
Xorg
C'est le 7.1, donc avec AIGLX.
J'ai une malheureuse G400 mais ça marche avec compiz (il faut un résolution inférieure à 1024).
J'ai testé, la 3D c'est bien, mais compiz c'est naze.
Je ferais un nouvelle essai quand Metacity supportera la 3d.
Pour information, si vous voulez ou avez besoin de désactiver AIGLX ou Xcompose :
[c]/etc/X11/xorg.conf :
Section "ServerFlags"
Option "AIGLX" "off"
EndSection
Section "Extensions"
Option "Composite" "Disable"
EndSection[/c]
Avec FC6 on peut dire que Fedora par défaut ne configure plus le fichier /etc/X11/xorg.conf. D'une certaine manière, c'est le même pour tout le mode (sauf pour le clavier : azerty ou qwerty par exemple). Xorg se configure automatique en fonction des périphériques qu'il trouve. Donc à l'installation Fedora ne demande rien pour Xorg et ne configure rien (sauf le clavier) ! L'utilisateur (et pas l'administrateur) peut choisir parmis les configurations adaptés au hardware via xrandr (ou en graphique avec gnome-display-properties dans le menu "Système|Préférence" ).
C'est une excellente idée, mais pas pour tous les cas. On peut refaire à la main un system-config-display pour avoir un /etc/X11/xorg.conf complet. C'est utile dans mon cas où le moniteur ne fournit aucune indication (donc Xorg passe en 800x600). Attention, le but de Fedora n'est pas de virer le fichier /etc/X11/xorg.conf. Il peut toujours servire.
Java
Plugin java (via gcj) dans Firefox. N'est pas activé par défaut (voir le fichier : /usr/share/doc/libgcj-4.1.1/README.libgcjwebplugin.so). Il reste des problèmes de sécurité qui devrait être corrigé pour FC7. Actuellement pour chaque applet, un message demande confirmation pour lancer l'applet. On peut aussi indiquer que l'applet est de confiance pour qu'elle soit lancée automatiquement la prochaine fois ou qu'elle n'est définitivement pas de confiance.
Ça ne marche pas pour tout, mais ça marche déjà pour beaucoup de chose. C'est au moins excellent pour les développeurs libres. Il peuvent au moins vérifier que ça marche avec l'implentation libre et ainsi fournir quelque chose qui n'est pas dépendant d'un jre proprio.
crypto
Il est maintenant facile d'utiliser des FS cryptés ainsi que le swap avec cryptsetup-luks. Comme en plus c'est intégré à Hal et gnome-mount, ça marche nickel sous Gnome qui ouvre une boite de dialogue pour saisir un mot de passe lorsqu'on insére une clée usb cryptée. L'intégration dans Hal était peut-être déjà dans FC5. Mais cryptsetup-luks est nouveau.
Xen
Le gros morceau. Ce n'est pas encore sans quelques hics.
Virt-manager fait des merveilles et parfois on croit utiliser vmware 🙂 En quelques cliques on crée une nouvelle machine complète avec son OS et on se loggue graphiquement.
Console virtuelle affichée dans X11, utilisation automatique de vnc, etc...
On peut aussi installer FC6 dans FC6 via Anaconda.
Tout ça prend furieusement la voie du "out of the box".
Je n'ai pas beaucoup utilisé Xen car ma bécane n'a que 512 Mo. Mais mes tests me disent que pour FC7 ça va roxer des ours et que beaucoup vont utiser Xen sur une bécane perso (tester Rawhide, tester un truc sans poluer l'installation en cours, etc).
Puis avec la technologie VT, on pourra faire tourner Windows dans Linux avec d'excellentes performances.
J'utilise pas Windows chez moi. Mais au boulot oui. Avoir une bécane sous Linux avec un windows dans un coin sans rebooter pour avoir des performances décentes serait un plus énorme.
Je sens que dans quelque mois je vais acheter un nouveau PC...
Mock
Mock permet de compiler un paquet dans un environnement chrooté. Il installe toute les dépendances en suivant les "requires/buildrequires" de rpm. Il est ainsi plus facile de renseigner les "Buildrequires".
FC6 a été compilé avec Mock. Idem pour Fedora Extras.
C'est facile à utiliser. Mais il convient d'avoir tous les paquets en local (rsync et createrepo sont tes amis) sinon à chaque fois on downloade des tonnes de paquets.
Mock n'est pas nouveau, mais c'est la première fois que je l'utilise. Surtout n'hésité pas à l'utiliser.
Bon, j'arrête ici, c'est déjà trop long. Il y a tant de chose dans une distribution Linux, qu'on n'en fait jamais le tour.
Les tests se termine en générale par "je conseille cette distribution à ...".
Fedora est spécial. Le but de Fedora n'est pas d'avoir des grosses parts de marché. Fedora ne cible pas un type d'utilisateur particulier. Fedora est là pour faire évoluer le logiciel libre, pour avoir Linux sur PS3 (c'est un fork de Fedora), pour aider OLPC, pour RHEL, pour les développeurs upstream, etc. Fedora c'est avant tout un projet et non une distribution. Sa cible principale, s'il y en a une, est donc les développeurs. Mais un développeur est aussi un utilisateur, un développeur n'évalue son travail qu'avec des utilisateurs et travail pour des utilisateurs. Alors certe, les utilisateurs n'est pas la cible principale de Fedora, mais beaucoup a été fait pour que Fedora soit utile.
Sortie officielle de FC6 le 24/10/06.
