Pour rappel la Fedora 9 inclut, du moins dans sa version beta, un kernel 2.6.25-rc5, GNOME 2.22, KDE 4.0.2, et d'autres nouveautés comme la gestion du chiffrement des partitions disques, de l'ext4, etc.
Même si les versions beta des Fedora sont en général assez stables et donc utilisables au quotidien, cela reste une beta, mais rapporter des bugs est aussi une manière de contribuer aux Logiciels Libres.
La Fedora 9, sauf retard imprévu, devrait sortir fin avril 2008.
![[en]](../images/en.png)
La note officielle de la sortie de la beta (489 hits)-
Fedora 9 Feature List (441 hits)
> Lire la dépêche (39 commentaires, moyenne: 2,9).
Vous avez demandé le commentaire #917624.
Run by 
Cette page a été générée par Templeet en 0.094s (dont 0.0088 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Re:
Le petit mon de Fedora est Sulphur.
> Même si les versions beta des Fedora sont en général assez stables et donc utilisables au quotidien, cela reste une beta, mais rapporter des bugs est aussi une manière de contribuer aux Logiciels Libres.
Tout à fait.
Mais un petit bémol. F9 est en phase beta. Fedora jusqu'à la phase test (le développement passe par alpha, beta, test (voire rc)) se permet de "tout casser". C'est-à-dire que pour récuperer une correction de bug, un "yum update" n'est pas toujours suffisant. Je ne dis pas que ça arrive souvent (bien au contraire). Mais ceux qui installent F9 beta doivent être avertis et s'abonner à la mailing testing pour rester informé.
> L'impact de l'utilisation d'Upstart se fait largement sentir lors des phases de démarrage ou d'arrêt avec une exécution beaucoup plus rapide.
Pour F9, ce n'est pas encore le cas. Mais pour F10 probablement.
Pour F9 l'objectif était seulement de passer à upstart sans rien casser d'autre.
> Il s'agit du gestionnaire graphique de paquets par défaut sur la Fedora 9 Beta.
J'ai cru que d'était faux :-)
Mais j'ai vérifié, c'est le cas. Au début de F9, ce n'était pas prévu ainsi. Bravo PackageKit pour tout le boulot.
> PolicyKit
Ce n'est pas vraiment une nouveauté, PolicyKit est déjà dans F8 (voire F7 ?). Dans F9 il est plus utilisé (et c'est plus visible).
> La virtualisation
Le gros changement (et notamment car Fedora est sponsorisé par Red Hat) est l'abandon de Xen. Donc il n'y a plus de kernel-xen.
Si tout va bien (car c'est un énorme travail), le KVM fournit doit supporter des guest Xen.
> Grosse nouveauté, très attendue, l'arrivée de la toute dernière branche de KDE
Notons que Fedora 9 aura par défaut KDE 4 et non KDE 3. Les développeurs sont donc plus concentrés sur le développement/intégration de KDE 4 que KDE 3.
> La bibliothèque "libblkid" est maintenant utilisée pour la détection des systèmes de fichiers déjà présents sur les disques.
libblkid est utilisé depuis longtemps par Fedora (et avant même Fedora). Un /etc/fstab typique a "LABEL=nom ..." au-lieu de "/dev/ ..."
> Kudzu pour la détection du materiel a été remplacé par HAL et Udev.
Mouaif. Kudzu n'était presque plus utilisé depuis longtemps. Il l'était pour quelques cas particulier. Ces cas sont maintenant couverts par HAL/udev, donc kudzu peut être viré (il n'y a plus rien à remplacer :))
Pour l'anecdote, kudzu était si peut utilisé qu'il faisait parti des paquets que je vire systématiquement de ma bécane :-)
[^]Re: Re:
Merci pour ces precisions
Il est toujours bon de rappeler les risques d'utiliser une beta, faut pas avoir peur de tout casser quoi. Mais si on a le temps, le matos pour tester ça dans un coin (ou meme dans une machine virtuelle) c'est un bon moyen de contribuer en rapportant le moindre bug.
Pour l'instant j'ai 2 install de fedora9 beta qui sont partie en sucette, 1 parceque lors d'un gros yum update SeLinux a empecher tous les scripts %pre/%post des rpms (pourtant impossible de reproduire le probleme) et la 2e c'est JFS... mais bon là jsuis sortie des clous.
Sinon concernant Upstart il m'a semblé que c'etait deja un poil plus rapide, mais bon c'est peut etre psychologique :p L'arret me semble bien rapide. L'hibernation ne marche pas par contre... je sais pas si upstart joue un role a ce niveau?
Policykit est arrivé avec la Fedora8 il me semble, mais là c'est beaucoup beaucoup plus visible
Pour Xen je ne savais meme pas qu'il l'abandonnait mais vu les progres de KVM ce n'est pas trop inquietant, je prefere meme. Sinon ya l'excellent Xenner pour faire tourner les vm xen avec KVM.
libblkid est utilisé depuis longtemps mais n'etait pas aussi bien utilisé dans anaconda, en tout cas les patchs remplacant les anciennes fonctions dans anaconda pour exploiter libblkid sont assez recents, tout comme la possibilité d'indiquer un autre stage2, d'utiliser le tmp du filesystem plutot que du ramfs pour le cache yum. Maintenant il me semble que les LABEL ne sont plus utilisés, au profit des UUIDs (a verifier jdis ça de tete jregarderais dans mon fstab).
[^]Re: Re:
ah ba phoronix avait testé le temps de boot des Fedora
http://www.phoronix.com/scan.php?page=article&item=fedor(...)
et c'est vrai que c'est meme plus lent mais bon c'etait la 8.90
[^]Re: Re:
Tu peux le vérifier par toi même, pour ta machine et ta configuration, à l' aide de l' utilitaire bootchart et de sa suite d' outils.
Et sur le site du projet sont réunis de nombreux résultats de tests.
http://www.bootchart.org/samples.html
Cordialement
[^]Re: Re:
> et c'est vrai que c'est meme plus lent mais bon c'etait la 8.90
Fedora n'est pas centré desktop comme Ubuntu. En caricaturant, le temps de boot est un critère parmi quelqu'un pour Ubuntu et parmis beaucoup pour Fedora. Donc pour Fedora le temps de boot est moins important et donc Fedora sera probablement parmis les distributions les plus lentes au boot.
Je ne dis pas que Fedora ne cherche pas à être rapide.
Comme je ne boot pas 50 fois par jour, le temps de boot je m'en fous.
[^]Re: Re:
>Comme je ne boot pas 50 fois par jour, le temps de boot je m'en fous.
Parfois un critère qui ne semble pas important revient te mordre plus loin, j'avais discerné un problème avec KDE sur petits écrans, mais je n'ai pas pris la peine de le remonter et d'en discuter avec les responsables du programme en question, parce que les écrans en 800x600 avaient quasiment disparus.
Résultat j'en souffre maintenant sur mon eee pc des années après.
Bien fait pour ma pomme, mais je ne suis pas le seul à en souffrir, c'est un manque de perspective de ma part.
D'ailleurs, l'importance du temps de boot a elle aussi été montrée par le succés du eee pc et de sa xandros.
[^]Re: Re:
Tu as raison. Mais, ce n'est pas tout à fait ce que j'ai dit.
OLPC c'est basé sur Fedora, le temps de boot y est particulièrement soigné (d'autant plus que ce n'est pas un montre de puissance).
Par contre Fedora (le brut de décoffrage de http://fedoraprojet.org/ ) n'est pas pour eeepc ou olpc. C'est une distribution a usage général (on est loin de olpc) et dédié à ceux qui contribuent au libre.
Tout ce qui peut améliorer le temps de boot est évidemment apprécié par Fedora. Mais si pour améliorer le temps de boot la distribution se spécialise et n'est plus une distribution à usage général, alors dans ce cas Fedora refuse.
Pour Fedora il est plus important d'avoir une bonne hibernation (ce qui n'est pas le cas aujourd'hui) que de gagner une poingée de seconde au boot.
[^]Re: Re:
C' est clair.
Une workstation ou un serveur n' ont pas à être rebootée 5 fois par jour ;)
Et RedHat, comme à leurs habitudes, privilègie le stable au fun.
Mais lorsqu' on installe une Redhat sur un laptop, c' est quelque chose de très appréciable, tout comme une bonne gestion de l' acpi afin de ne faire des démarrage que depuis l' image disque dans 9 cas sur 10 ;)
Mais il y a quant même quelque chose qui me titille dans tout ça :
RHEL4-u5 (et rhel5) sont effroyablement rapides au boot... En fait mon laptop boot aussi vite avec rhel4-u5 qu' avec mandriva cooker. Comme vous le savez, sur rhelX il n' y a pas de upstart ou de pinit. Et pourtant c' est rapide, mais rapide... En fait ce qu' elle perds en temps de boot avec les services, elle le regagne largement avec le démarrage de X et de Gnome. (en comparaison d' une mandriva, qui boot très vite grâce à pinit, depuis la 2007, reperds ce gain avec le dem' de X.)
Donc vraiment, il me tarde de voir de mes yeux l' évolution du projet sur le dem' de X citée dans la dépêche ( http://fedoraproject.org/wiki/Features/OneSecondX ) FastX !!!!!
Par contre sur upstart j' émet des gros doutes : parcequ' allez dire à ses boss "on est plus compatible SystemV, il faut refaire Tout les services de démarrage maison" -> Ca m' étonnerai beaucoup qu' ils apprécient upstart dans l' industrie... Pour des machines standalone ou laptop, ok. Pour des nouveaux serveurs dans de petites structures pourquoi pas. Mais pour une intégration dans un parc existant avec de fortes contraintes client, je crois que upstart peux se brosser... (et ça m' étonnerai d' ailleurs que cela soit un jour intégré dans RedHat ce truc). Il doit bien avoir quelque chose à faire pour accélerer le dem' des services sans casser la compat. V, non ?
Excusez moi d' avoir été un peu long, et j' espère que les tournures ne prêtent pas à confusions ni à troll, car ne n' est pas le but.
Cordialement
[^]Re: Re:
Le but d'upstart n'est pas que de démarrer plus rapidement ... mais aussi de démarrer les services à la demande lorsque c'est nécessaire.
Je pense que ça devrait permettre de faire des choses du style: quand je branche une imprimante, cups est démarré (mais pas avant).
Cela améliore aussi tout ce qui est gestion de processus serveurs ... qui sont redémarrés automatiquement si ils quittent. Alors qu'avec init.d, il faut faire un script spécial pour ça.
Je pense au contraire qu'upstart peut intéresser les utilisateurs de RHEL ... surtout qu'upstart a un module de compatibilité avec sysvinit (au niveau de /etc/init.d mais pas au niveau de /etc/inittab, c'est vrai)
La Roue du Temps
[^]Re: Re:
Excusez moi je n' avais pas vu ton message. A titre personnel, je ne vois pas pourquoi un projet prévu pour améliorer le temps de boot irait s' occuper d' autre chose que du boot. J' appelle ça une usine à gaz. Et je croyais que udev s' occuperait de cela, plutôt... Perso si je branche une imprimante à chaud : un outil graphique se lance tout seul, me propose de configurer cette imprimante et installe tout le nécessaire, tout seul, puis lance les services tout seul. En 2 minutes et 3 clickous l' imprimante est fonctionnelle.
Un truc qui ne fasse que le boot, et qui le fasse bien.
Un autre truc qui ne s' occupe que des devices et de leur dep. mais qui le fasse bien.
ps blague : PAM_Linuxfr me prévient que j' ai trop posté sur la news Fedora 9, j' arrêtes donc là pour éviter une impression d' envahissement lol.
Merci encore pour cette dépêche détaillée!
[^]Re: Re:
Initscript ce n'est pas vraiment que le boot. C'est aussi tous les services (ou presque).
Fait une truc. Boot en runlevel 1. Puis lance le service netfs "service netfs start". Ben SystemV ne gère pas ça. netfs doit être lancé que si network est lancé. upstart gère ce type de truc. Upstart gère les dépendances entre services, SystemV (presque) pas du tout. SystemV ne le fait que entre runlevel.
Upstart n'a pas été fait uniquement pour gagner de la vitesse. Upstart est une bonne réponse aux limitations (bien connues) de SystemV.
Ceci dit, sur le papier c'est sexy, mais ce n'est pas (actuellement) indispensable. M'enfin, ça va donner des idées, et qui sait ce que l'avenir nous réserve.
> Un truc qui ne fasse que le boot, et qui le fasse bien.
C'est quoi le boot ?
C'est apache car il est lancé ?
C'est X11, gdm ?
C'est l'initialisation des périphériques.
C'est seulement ce qui est fait dans initrd ?
Le boot ne peut être dissocié du lancement et l'arrêt de service. Ce qui est utilisé pour booter est utilisé pour le shutdown (majoritairement). C'est aussi utilisé pour passer en runlevel 1 (single user). Ce qui est utilisé pour lancer des services au boot, est utilisé pour les lancer à la main.
Ce qui est fait par initrd, peut-être considéré comme le boot et il ne fait que ça. Boot avec en paramètre "init=/bin/bash" pour t'en convaincre.
[^]Re: Re:
> "on est plus compatible SystemV, il faut refaire Tout les services de démarrage maison" -> Ca m' étonnerai beaucoup qu' ils apprécient upstart dans l' industrie...
De ce que je sais, upstart reste compatible SystemV. A ma connaissance Fedora l'utilise qu'ainsi actuellement (et Ubuntu aussi je crois). C'est transitoire.
La compatibilité SystemV ne me semble pas un problème.
(1) Avec SystemV (exemple fictif):
- S10 network
- S20 mount_nfs
(2) Avec upstart :
- network
- mount_nfs DEPEND ON network
On send de suite que passer de (1) à (2) n'est pas un problème.
Pour les scripts SystemV, il suffit d'adapter /etc/rc.d/init.d/functions pour que lors d'un start réussit un message dbus soit envoyé.
> et ça m' étonnerai d' ailleurs que cela soit un jour intégré dans RedHat ce truc
Si c'est dans Fedora, alors ça le sera (pour RHEL 6).
[^]Re: Re:
J' espère que tu as raison, mais il faut préciser quelques trucs : Quant on va dire "on est plus compatible systemV", il ne s' agit pas que d' adapter les services maisons sur les machines Linux, ça c' est un premier point du genre "hé faut tout se retaper à ce niveau, puis tout re-valider", le temps, tout ça. Mais c' est finalement secondaire en regard d' un autre point : la mise à l' écard de linux des autres unix existants. Et ça c' est le plus gros point. Bref ça à pas l' air de grand chose à voir comme ça, mais cela impacterai beaucoup de trop de choses chez beaucoup trop de clients.
C' est pourquoi, en l' état actuel de upstart, il s' agira certainement d' une première : pour la première fois quelque chose qui est dans Fedora ne sera pas dans Redhat. En l' état actuel de upstart, ce n' est pas possible, ce n' est pas sérieux.
D' ailleurs Ubuntu l' a bien compris et revient actuellement à SystemV, en proposant une couche de compatibilité. :
http://packages.ubuntu.com/hardy/base/upstart-compat-sysv
Je ne l' ai pas encore testé, mais cela m' étonnerai qu' on garde la même rapidité au boot, du coup. C' est dommage, car il me semble que ce sont des efforts perdus de notre côté, alors qu' il aurait (peut être, je ne sais pas) été possible de faire (ou de maintenir et améliorer un outil existant) un système qui accélère le boot tout en gardant nativement la compat. V
cordialement
[^]Re: Re:
Enfin, la chose intéressante est la standardisation, et c' est encore Fedora / Redhat qui fait le boulot. Gageons que les Developpeurs Fedora et RedHat rendront upstart viable.
[^]Re: Re:
> Enfin, la chose intéressante est la standardisation, et c' est encore Fedora / Redhat qui fait le boulot.
Fedora et Red Hat ne font pas dans la "standardisation".
Ils veulent pousser les technologies d'avenir et non rester aux vieux trucs car "ça marche" et le nouveau "par encore". Non rester au vieux trucs car "le driver proprio bidule ne marche pas avec le nouveau". Si le nouveau ne marche pas encore et qu'il est prometteur, ben Fedora s'y colle (même si ce n'est pas standardisé).
Il n'y a pas d'objectif de "standardisation". Au début de Fedora, il y avait up2date. Puis pirut, et maintenant PackageKit. Es-ce que PackageKit marchera mieux que Pirut dans F9 ? Peut-être pas. Mais l'avenir est dans PackageKit. Fedora ne va pas rester à attendre que PackageKit soit nickel. Fedora va aller "au front".
Le "standard" pour la virtualisation c'est Xen. Mais Xen est contraignant et donc Fedora s'en désengage pour KVM/pv_ops/etc. Es-ce que F9 avec uniquement pv_ops sera mieux que F8 avec Xen ? Peut-être pas. Mais qu'importe, l'avenir est dans pv_ops et non Xen. Et donc Fedora fonce dans pv_ops et tant pis si ça chie dans la colle au début.
Et c'est pour ça que j'adore Fedora. Ce n'est pas que packager le boulot des autres, c'est s'impliquer "à donf" dans l'évolution du logiciel libre.
Pour la standardisation, c'est à la LSB de voir si ce qui est proposé dans Fedora (et plus globalement dans le logiciel libre) doit être standardisé.
Pour ma part, je pense que c'est un mauvaise idée de "standardiser" un OS. Il faut "standardiser" les API (du moins assurer une bonne compatibilité ascendante), il faut standardiser les formats de donnés (police, chemin d'accès, etc). Mais je suis contre la standardisation de tout ce qui proche OS (et non proche appli).
[^]Re: Re:
> Et ça c' est le plus gros point. Bref ça à pas l' air de grand chose à voir comme ça, mais cela impacterai beaucoup de trop de choses chez beaucoup trop de clients.
Faut se "calmer". Ça ne conserne qu'une (grosse) poignée de script. Ça n'a rien à voir avec des millions de documents sous ODF ou autres.
Tu peux faire des échanges de document ODF, tu n'en fais quasiment jamais pour les scripts d'initialisation.
Imaginons (simple suposition) que Upstart soit totalement et définitivement incompatible SystemV. Pour Fedora ce n'est pas un problème (hors le problème technique de mettre à jours des scripts), Fedora est la pour l'évolution du logiciel et non la promotion de vieux "standards" sans avenir.
Pour RHEL, c'est un problème mais ça ne va pas empêcher Red Hat de faire évoluer RHEL. Ça va être fait dans un cadre plus contraignant que Fedora.
Red Hat va sortir une première beta de la prochaine RHEL avec un BIG warning qui indique que les init scripts doivent être adaptés. Il y aura probablement quelques lignes, ou un lien vers une doc, qui indique comment faire. Entre la première beta et la version finale il va se passer sans problème 5 mois voir plus !
Lorsque RHEL 6 sort, il y aura un large panel d'appli *déjà* certifiées ! Les vendeurs de logiciel y ont intérêt.
Exemple avec l'annonce de la beta 1 de RHEL 5 :
http://www.redhat.com/archives/rhelv5-announce/2006-Septembe(...)
Notons les avertissements sur subversion, apache et php qui ne sont pas compatibles avec RHEL 4. Il y a eu 7 mois entre la première beta (basée sur FC6 test2 si j'ai bonne mémoire) et la sortie de RHEL 5.
La compatibilité, l'intéropérabilité sont indispensables pour les formats de document. Pour les programmes, c'est beaucoup plus discutable et il ne faut pas freiner l'évolution du logiciel libre à cause de ça. Évidemment ça doit être pris en compte. Mais casser les choses est parfois un mal nécessaire.
> C' est pourquoi, en l' état actuel de upstart, il s' agira certainement d' une première : pour la première fois quelque chose qui est dans Fedora ne sera pas dans Redhat. En l' état actuel de upstart, ce n' est pas possible, ce n' est pas sérieux.
En l'état actuel peut-être pas. La prochaine RHEL sera probablement basée sur Fedora 10 et sortira probablement entre 4 et 6 mois après F10.
Mais je suis vraiment persuadé que la prochaine RHEL aura upstart.
[^]Re: Re:
http://packages.ubuntu.com/hardy/base/upstart-compat-sysv
=> Ce n'est pas un retour à sysv mais un wrapper de compatibilité.
Qui d'ailleur a bien été utilisé lors du passage de l'init traditionnel à upstart.
"Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
[^]Re: Re:
la compatibilité sysvinit est présente depuis les tous débuts d'upstart. C'est possible que maintenant le paquet soit splitté, mais ça a toujours été là.
La dernière fois que j'avais regardé upstart, la gestion des services natif upstart était un peu foireuse, et a u changer depuis. Par contre la compatibilité a toujours été là.
La Roue du Temps
[^]Re: Re:
> Le gros changement (et notamment car Fedora est sponsorisé par Red
> Hat) est l'abandon de Xen. Donc il n'y a plus de kernel-xen. Si
> tout va bien (car c'est un énorme travail), le KVM fournit doit
> supporter des guest Xen.
Je croyais que Fedora était en train d'essayer de faire migrer Xen avec paravirt_ops, même pour le dom0. Sont-ils vraiment en train d'abandonner Xen en faveur de KVM ?
Olivier;
[^]Re: Re:
Avertissement : Je ne suis pas un spécialiste virtualisation mais qu'un utilisateur (ravis).
> Je croyais que Fedora était en train d'essayer de faire migrer Xen avec paravirt_ops, même pour le dom0
C'est ça. Mais ça implique de virer Xen (le patch xen-source). Par contre, les guests Xen pourront trouner.
> Sont-ils vraiment en train d'abandonner Xen en faveur de KVM ?
Pour moi oui.
Mais il faut mettre les choses dans le contexte Red Hat. Fedora est entre autre l'incubateur RHEL. Red Hat vend beaucoup de Xen actuellement. Red Hat ne peut pas abondonner Xen du jour au lendemain car beaucoup de ses clients utilisent Xen.
Voici un scénario que j'imagine pour RHEL 6. RHEL 6 n'utilise plus Xen mais permet de faire tourner des guests Xen. Ainsi les machines virtuelles pourront être migrées de RHEL 5 (ou 4) vers RHEL 6 même si cette dernière n'est plus basée sur Xen.
Du 30 novembre 2008 :
http://berrange.com/personal/diary/2007/11/plan-for-xen-kern(...)
Either Xen has to be dropped entirely, or we need a different strategy for dealing with the kernels. Since people seeem to use Xen, we have decided not to drop it :-)
So the plan is to re-focus 100% of all Xen kernel efforts onto paravirt_ops.
...
Getting all this done for Fedora 9 is seriously ambitious, but it is the only long term sustainable option, other than dropping Xen entirely.
Ce n'est pas un abandon total. Mais un "désengagement" avec le nécessaire de fait pour assurer la compatibilité.
> Sont-ils vraiment en train d'abandonner Xen en faveur de KVM ?
On peut dire oui ou non. En terme de développement/technologie, pour moi c'est oui.
[^]Re: Re:
c'est aussi assez clair dans ce bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=437930
avec ce lien filé en commentaire sur la marche que va suivre fedora concernant xen:
http://fedoraproject.org/wiki/Features/XenPvops