jeudi 10 avril

Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Astuces :: Suivi :: RDF

Articles précédents : Distribution

[73] Ubuntu 8.04 Bêta
[10] ClefAgreg : une clef USB pour l'agrégation
[31] Présentation du système Saevia
[6] Publication de SliTaz GNU/Linux 1.0
[50] Mandriva Linux 2008 Spring RC2 est disponible
[30] Knoppix 5.3.0
[13] System Rescue CD estampillé 1.0
[29] Shuttle adopte Foresight Linux
[14] Des PC sous Linux en Europe de l'Est
[99] Ubuntu Mobile bientôt de sortie !

Liens connexes

La note officielle de la sortie de la beta (424 hits)
Fedora 9 Feature List (388 hits)

Dépêche modérée par

Nyco

Dépêche éditée par

Distribution : La Fedora 9 arrive en version beta

Posté par madko (). Modéré le 28 mars 2008.

Une version de plus en plus stabilisée de la Fedora 9 est disponible depuis quelques jours, elle marquera le début de la version beta afin de figer les fonctionnalités déjà présentes et d'uniquement se focaliser sur la correction de bugs. Le début de la diffusion de la version beta avait déjà été reculé à cause des vacances de Pâques.

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.

La note officielle de la sortie de la beta (424 hits)
Fedora 9 Feature List (388 hits)

> Lire la dépêche (39 commentaires, moyenne: 2,9).

Les nouveautés de la Fedora 9 :

Upstart

Une des nouveautés les plus visibles pour les utilisateurs confirmés concerne le remplacement du démon d'init, l'historique SystemVinit disparait au profit d'UpStart. UpStart est déjà utilisé sur Ubuntu et a largement fait ses preuves, il apporte une gestion plus sophistiquée sur le démarrage des services avec la gestion d'évènements entre autres, ce qui le rend plus adapté à l'utilisation actuelle de nos machines. 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.

Tous les scripts d'init sur la Fedora 9 devraient fonctionner sans erreur, le fichier /etc/inittab reste présent (pour l'instant?) mais toute modification doit être portée sur Upstart. Un guide sur l'utilisation d'upstart est déjà disponible: http://upstart.ubuntu.com/getting-started.html
PackageKit

Il s'agit d'un logiciel de gestion de paquets multi-distribution qui supporte bien sûr complètement yum. Il a pour but d'unifier les outils graphiques de gestion de packages entre les différentes distributions Linux. Il repose sur l'utilisation des services tel que D-Bus et intègre bien sur PolicyKit.

Il s'agit du gestionnaire graphique de paquets par défaut sur la Fedora 9 Beta.
PolicyKit

Venant du projet FreeDesktop.org, PolicyKit permet aux applications non privilégiées un accès plus fin à des processus privilégiés, sans pour autant élever les privilèges de toute l'application (comme le ferait par exemple sudo).
Fast X

X étant relativement lent à se lancer et à se relancer, celui-ci ralentit pas mal d'aspects du système tel que le démarrage (rhgb lance X pour le boot graphique), la fermeture de session graphique, et la bascule entre différentes sessions graphiques (relance de X). Le but de ce projet est d'améliorer X afin qu'il puisse s'exécuter et être prêt à accepter des clients en une seconde.

http://fedoraproject.org/wiki/Features/OneSecondX
La virtualisation

La virtualisation n'est pas en reste avec cette version de Fedora, avec l'inclusion des derniers changements sur paravirt_ops dans le kernel, l'ajout de l'authentification Virt, de Virt Manager Policy Kit, et du support des pilotes accélérés virtio pour améliorer les performances d'entrées/sorties.
On note également que KVM émule maintenant par défaut des cartes réseaux e1000 et un affichage SVGA de VMware.
GNOME 2.22

De nombreuses améliorations comme toujours, avec l'arrivée des remplaçants de GNOME VFS, à savoir GVFS et GIO, codés par les développeurs de Fedora et le mainteneur de Nautilus, Alexander Larsson.

GVFS apporte des améliorations au niveau des performances, mettant en file d'attente les multiples transferts de fichiers, ainsi qu'au niveau de la sécurité - via l'intégration de PolicyKit, qui est développé et maintenu par le développeur Fedora David Zeuthen, et déjà initialement introduit dans la Fedora 8.

Cette nouvelle mouture de Gnome comprend de nouvelles applications déja traitées dans les nombreuses dépêches sur la sortie de Gnome 2.22, comme par exemple une applet d'horloge mondiale, une application pour les webcams, etc.

Une nouvelle version du gestionnaire de session GDM arrive, apportant plein de nouvelles fonctionnalités comme la possibilité de la gestion d'énergie dès la mire de login, de configurer dynamiquement l'écran, et une meilleure intégration avec PolicyKit.

Autre changement, du côté du Bluetooth les différentes applications précédemment utilisées pour les transferts de fichiers sont maintenant complètement intégrées au bureau Gnome pour plus de simplicité. Les Palm Pilots peuvent maintenant être synchronisés par Bluetooth.

Côté multimédia, il s'agit encore des améliorations apportées par Gnome 2.22 : Totem se voit encore amélioré avec un meilleur support des sous-titres, ainsi que de nouveaux plugins comme le plugin MythTV ou celui de recherche sur YouTube. Rhythmbox devient le lecteur CD par défaut, et supporte l'UPNP ainsi que les Podcasts (support amélioré des flux Atom et Itunes).
KDE 4

Grosse nouveauté, très attendue, l'arrivée de la toute dernière branche de KDE, actuellement dans la beta en version 4.0.2. La liste des améliorations est impressionnante avec l'arrivée de QT4 et des nouveaux frameworks orientés multimédia et matériel tel que Phonon et Solid. Plasma, le nouveau bureau apporte de nouveaux concepts, une recherche intégrée, la gestion de l'affichage composite avec Kwin et un nouveau style visuel appelé Oxygen.

Un groupe de travail a spécialement été formé chez Fedora pour l'intégration de cette nouvelle version de KDE, qui comprendra des paquets de compatibilité pour faire fonctionner les applications qui ne seraient pas encore portées sous QT4.
La gestion du réseau

Fedora repose encore un peu plus sur l'utilisation de NetworkManager, mais les développeurs ont apporté certaines fonctionnalités pour une meilleure intégration dans la Fedora, comme le support des connexions wifi Ad-Hoc, des connexion mobiles GSM/CDMA au travers de PPP, et l'intégration de PolicyKit pour la configuration complète du réseau de la machine.
Internet

La Fedora 9 dans cette version Beta (Rawhide 8.92) propose Firefox 3 Beta 5 avec, et c'est nouveau, un plugin compatible Flash directement installé via le passage de swfdec dans gstreamer.
Anaconda

Anaconda supporte enfin le redimensionnement des partitions ext2, ext3 et NTFS. Durant l'installation on peut maintenant choisir de crypter les partitions. La bibliothèque "libblkid" est maintenant utilisée pour la détection des systèmes de fichiers déjà présents sur les disques.

Le support ext4 est déjà supporté par Anaconda à titre expérimental via l'option de boot "iamanext4developer".

Kudzu pour la détection du materiel a été remplacé par HAL et Udev.

Il y a maintenant une nouvelle image sur le CD/DVD pour les installations réseaux avec tout ce qu'il faut dedans, le fichier se nomme "netinst.iso".

testeur de la beta

Posté par lejocelyn () le 28/03/2008 à 22:03. (lien). Évalué à 6.

Je teste la beta et je suis agréablement surpris. Pas mal de problèmes et je pense que KDE 4 manquera de finition mais je suis surpris par la rapidité du tout. l'affichage d'un site par Konqueror ou du contenu d'un dossier (par Dolphin ou Konqueror), la construction de ma bibliothèque musicale par Juke, etc.

Je n'ai pas testé toutes les nouveautés d'Anaconda (chiffrement, taille des partoches) car je n'en ai pas besoin.

J'ai pu essayé Kaider (loKalize mais nommé Kaider car ça doit etre une vieille version), le projet me semble très prometteur mais ne supporte pas encore le format TMX 1.4, celui que j'utilise pour le moment.

Package-Kit semble très prometteur mais je n'ai pas trouvé comment installer plusieurs paquets à la fois, ce qui est un très gros problème.

J'ai encore pas mal de choses à essayer et j'ai rapporté quelques problèmes mais cette version est prometteuse.

[ Répondre ]

[^]Re: testeur de la beta

Posté par lejocelyn () le 31/03/2008 à 16:53. (lien). Évalué à 2.
Je viens de remarquer un truc qui me fait vachement plaisir, une version récente du pilote nouveau est installée (mais pas utilisée par défaut).

rpm -qi xorg-x11-drv-nouveau.i386
Name : xorg-x11-drv-nouveau
Version : 0.0.10
Release : 1.20080311git460cb26.fc9
Build Date: Tue 11 Mar 2008 01:23:26 PM CET

[ Répondre ]

Installation

Posté par Mildred (Jabber id, page perso, ) le 29/03/2008 à 00:01. (lien). Évalué à 3.

J'espère qu'il y a moyen d'installer Fedora via un chroot. J'avais déjà essayé F8 mais était revenue à ArchLinux qui apporte une très grande facilité de création de paquets (je me refuse a installer des logiciels dans /usr/local via make install)

Mais bien sûr, j'ai un MacBook, avec une table des partitions GPT que les installeurs ne comprennent souvent pas bien. Et en plus, j'ai EFi au démarrage :/
Donc je ne fais pas bien confiance aux installeurs pour installer où je veux sans effacer ce que je veux garder.

Vous savez si c'est possible (et quelle page décrt comment faire) ?

Sinon, je trouve que Fedora est une très bonne distriburion, moteur d'améliorations dans le bureau libre ... et je trouve ça très bien. Bravo !

--
La Roue du Temps

[ Répondre ]

[^]Re: Installation

Posté par IsNotGood () le 29/03/2008 à 01:21. (lien). Évalué à 4.
> J'espère qu'il y a moyen d'installer Fedora via un chroot.

Je ne comprend pas bien le "via un chroot".
Tu peux installer Fedora dans un répertoire (puis faire un chroot).
Mock, qui est utilisé pour compiler les paquets, peut-être utilisé pour faire ça :
http://fedoraproject.org/wiki/Projects/Mock

On peut aussi le faire sans Mock.

[ Répondre ]
- [^]Re: Installation
  
  Posté par bubar () le 29/03/2008 à 13:10. (lien). Évalué à 5.
  c' est vrai que quelque chose d' aussi simple que
  
  mkdir /chroot
  urpmi basesystem --root /chroot
  mount -t proc none /chroot/proc
  cp -L /etc/resolv.conf /chroot/etc/resolv.conf
  urpmi --root /chroot urpmi locales-fr task-gnome
  chroot /chroot /bin/bash
  
  ça serait génialissime sur Fedora
  
  urpmi, options intéressantes pour le chroot :
  --root
  --use-distrib
  
  Croyez vous qu' il serait possible de porter urpmi sur fedora ?
  
  [ Répondre ]
  - [^]Re: Installation
    
    Posté par bubar () le 29/03/2008 à 13:15. (lien). Évalué à 4.
    photo d' écran rigolote
    http://img180.imageshack.us/img180/1597/captureua6.jpg
    
    [ Répondre ]
    - [^]Re: Installation
      
      Posté par Possum Marsupial Power (Jabber id, page perso, ) le 31/03/2008 à 19:54. (lien). Évalué à 1.
      Toi, je sais pour quelle boîte tu bosses :)
      
      T'as pas honte de coller du Linux sur le réseau eu ? Alors que le master officiel est encore en W2K :)
      
      [ Répondre ]
      - [^]Re: Installation
        
        Posté par bubar () le 01/04/2008 à 10:11. (lien). Évalué à 2.
        Il y a aussi un Master officiel Linux :)
        c' est une RHEL4_u4 ou u5 pour tout nouveau poste.
        Tu peux en faire la demande auprès de l' équipe responsable, et me contacter en privé si tu veux des modifs (tant que cela reste dans les clous des exigeances du master et du règlement interne)
        Et officiellement, tu peux choisir entre Kde, Gnome ET Xfce, tout les 3 trois sont validés ;)
        
        [ Répondre ]
        
        [^]Re: Installation
        
        Posté par Possum Marsupial Power (Jabber id, page perso, ) le 01/04/2008 à 10:50. (lien). Évalué à 1.
        T'as un message :)
        
        [ Répondre ]
  - [^]Re: Installation
    
    Posté par madko () le 29/03/2008 à 13:55. (lien). Évalué à 6.
    perso je fais:
    
    mkdir -p /chroot /chroot/var/lib/rpm /chroot/var/log /chroot/proc /chroot/dev /chroot/var/lib/yum
    rpm --root=/chroot --initdb
    mount -o bind /proc /chroot/proc
    mount -o bind /dev /chroot/dev
    rpm -ivh --root=/chroot fedora-release-<version que je veux>*.rpm
    yum --installroot=/chroot install basesystem bash
    chroot /chroot
    
    C'est sur que ya plus de truc a faire qu'avec urpmi et c'est dommage. Apres je repete ce qu'a dit IsNotGood si c'est juste pour compiler un package et meme jouer avec un chroot tu peux utiliser Mock ça marche tres bien, je m'en sert par exemple pour compiler des packages pour une centos sur une fedora :)
    
    Sinon je pense que rien ne t'empeche d'installer urpmi sur une Fedora, je le faisait a l'epoque sur RHEL 4 ça marchait niquel. Le soucis: avoir un dépot urpmi...
    
    [ Répondre ]
  - [^]Re: Installation
    
    Posté par IsNotGood () le 29/03/2008 à 20:28. (lien). Évalué à 4.
    > mkdir /chroot
    > urpmi basesystem --root /chroot
    
    En réalité, ce qui supporte l'installation dans un autre répertoire (base rpm compris), c'est rpm. urpm ou yum ou autre n'est qu'une couche.
    J'ai déjà fait des installations en chroot seulement avec rpm.
    
    > Croyez vous qu' il serait possible de porter urpmi sur fedora ?
    
    Oui. Si tu veux le faire, n'hésites pas.
    
    [ Répondre ]
  - [^]Re: Installation
    
    Posté par GeneralZod () le 01/04/2008 à 09:39. (lien). Évalué à 2.
    urpmi est disponible sous le cpan et certains prétendent que ça marche sous Fedora.
    Sinon, pour faire des chroots, tu as mock qui supporte parfaitement yum et qui peut chrooter n'importe quelle distribution à base de rpm.
    
    [ Répondre ]
- [^]Re: Installation
  
  Posté par Mildred (Jabber id, page perso, ) le 29/03/2008 à 14:07. (lien). Évalué à 3.
  L'idée c'est de pouvoir installer Fedora depuis une autre distrib Linux sans utiliser un CD d'installation ... et sans avoir un installeur qui limite un peu les choix (genre partitionnement ... alors que j'ai déjà toutes les partitions prêtes)
  
  Un truc dans le genre de debootstrap ou du genre de [http://wiki.archlinux.fr/install:chroot]
  
  J'ai effectivement vi qu'il existant le projet Mock mais je ne sais pas dans quelle mesure il faut ce que je veux faire ... et comment l'utiliser. Mais il semble que je doive fouiller d'avantage dans ce sens.
  
  Sans compter que bien sûr, je ne part pas d'une distribution Fedora. Donc pas question d'installer des RPM (mais l'installation depuis les sources ne me fait pas peur :)
  
  --
  La Roue du Temps
  
  [ Répondre ]
  - [^]Re: Installation
    
    Posté par bubar () le 29/03/2008 à 14:21. (lien). Évalué à 2.
    Je vais aussi creuser la doc de Mock.
    Mais pour une installation, il n' y en a pas besoin peut être (certainement ?)
    Perso j' utilise le chroot, puis un dump du mbr (ou utilisation de la partition /boot originale), ensuite je renseigne correctement le fstab du chroot. Et hop je peux booter sur la nouvelle distrib.
    Cela réunit, il me semble, divers avantage : choix très précis des paquets, installation transparente sur un système actif, installation uniquement de rpm à jour depuis les dépôts officielles (pas besoin d' updates), évite de se servir de netinstall.iso, rapidité et facilité.
    mes deux cents
    
    Merci des informations sur Mock
    Cordialement
    
    [ Répondre ]
  - [^]Re: Installation
    
    Posté par IsNotGood () le 29/03/2008 à 21:26. (lien). Évalué à 2.
    > Un truc dans le genre de debootstrap
    
    A ma connaissance, il n'y a pas ce que tu veux pour le faire "out of the box".
    A moins que tu aies le goût de défi, je crains que Fedora ne soit pas le bon choix pour ce que tu veux faire.
    
    > Donc pas question d'installer des RPM
    
    Tu peux installer rpm sur un système non rpm.
    Le strict minimum qu'il te faut pour installer dans un répertoire est "# rpm --root=/mnt/mon_root ..."
    
    > J'ai effectivement vi qu'il existant le projet Mock
    
    Mock n'est pas dédié à faire tourner une distribution en chroot. Il est conçu pour les compilation de paquets. Puis il s'est vu la possibilité de faire tourner des trucs dans le chroot (options --shell et --root).
    
    > L'idée c'est de pouvoir installer Fedora depuis une autre distrib Linux sans utiliser un CD d'installation ... et sans avoir un installeur qui limite un peu les choix (genre partitionnement ... alors que j'ai déjà toutes les partitions prêtes)
    
    L'orientation Fedora est clairement vers la virtualisation. Red Hat/Fedora a développé libvirt/virt-manager.
    Donc tu peux faire une installation sans graver de CD. Il faut seulement une petite image ISO (que tu n'as pas besoin de graver) et après tu fais une installation réseau. Beaucoup de développeur font les tests avec la virtualisation.
    
    http://docs.fedoraproject.org/install-guide/f8/en_US/sn-expe(...)
    Download the boot.iso image for a minimal boot CD or bootdisk.img file for a minimal boot USB flash drive. Write the image to the approriate physical media to create bootable media.
    
    Globalement tout ceci n'est pas trivial pour quelqu'un qui n'est pas habitué à Fedora. Je ne veux pas que tu partes dans un plan "galère".
    
    [ Répondre ]
    - [^]Re: Installation
      
      Posté par Mildred (Jabber id, page perso, ) le 30/03/2008 à 00:22. (lien). Évalué à 4.
      Merci ... mais l'dée ce n'est pas d'aviter à tout prix de graver un CD/DVD (les DVD-RW existent) mais surtout éviter de passer par un installeur qui limite les possibilités ... et qui touche a tout ce que je n'ai pas envie qu'il touche sur ma machine.
      
      Genre m'interdire de continuer l'installation a cause de ma table de partition GPT, ou de me changer tous mes labels. Voire de vouloir a tout prix installer un chargeur de démarrage (j'ai déjà un GRUB qui marche bien) ...
      
      Et si pendant l'installation je peux en plus continuer a aller sur Internet, utiliser mon ordinateur, c'est un plus appréciable
      
      --
      La Roue du Temps
      
      [ Répondre ]
      - [^]Re: Installation
        
        Posté par IsNotGood () le 30/03/2008 à 00:52. (lien). Évalué à 2.
        Je comprend bien.
        Tout ceci est possible depuis une Fedora. Mais c'est un peu compliqué.
        C'est aussi possible depuis une non Fedora. Mais c'est très compliqué.
        Partant de ce constat, et si tu ne veux/peux pas utiliser la virtualisation, ben évites Fedora. Je ne veux pas que tu perdes du temps et aies une mauvaise image de Fedora car tu as voulu faire un truc qui n'est pas vraiment prévu (sauf pour les experts/développeurs).
        
        Je ne vais pas te raconter des conneries pour caser une Fedora :-)
        Mais, je peux me tromper et il y a peut-être quelque chose qui fait ça les doigts dans le nez.
        
        [ Répondre ]
  - [^]Re: Installation
    
    Posté par Olivier Tétard (Jabber id, page perso, ) le 29/03/2008 à 21:35. (lien). Évalué à 1.
    > Un truc dans le genre de debootstrap ou du genre de [http://wiki.archlinux.fr/install:chroot]
    
    Je ne sais pas si ça peut faire l'affaire (je n'ai jamais testé cet outil), mais Rinse [http://xen-tools.org/software/rinse/] est présenté comme « A tool to bootstrap RPM-based distributions », ce que tu sembles chercher.
    
    Olivier;
    
    [ Répondre ]

Re:

Posté par IsNotGood () le 29/03/2008 à 09:18. (lien). Évalué à 4.

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 :-)

[ Répondre ]

[^]Re: Re:

Posté par madko () le 29/03/2008 à 11:59. (lien). Évalué à 5.
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).

[ Répondre ]
- [^]Re: Re:
  
  Posté par madko () le 29/03/2008 à 13:05. (lien). Évalué à 2.
  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
  
  [ Répondre ]
  - [^]Re: Re:
    
    Posté par bubar () le 29/03/2008 à 13:41. (lien). Évalué à 2.
    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
    
    [ Répondre ]
  - [^]Re: Re:
    
    Posté par IsNotGood () le 29/03/2008 à 20:37. (lien). Évalué à 2.
    > 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.
    
    [ Répondre ]
    - [^]Re: Re:
      
      Posté par imr () le 30/03/2008 à 06:28. (lien). Évalué à 8.
      >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.
      
      [ Répondre ]
      - [^]Re: Re:
        
        Posté par IsNotGood () le 30/03/2008 à 10:16. (lien). Évalué à 3.
        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.
        
        [ Répondre ]
    - [^]Re: Re:
      
      Posté par bubar () le 30/03/2008 à 11:22. (lien). Évalué à 4.
      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
      
      [ Répondre ]
      - [^]Re: Re:
        
        Posté par Mildred (Jabber id, page perso, ) le 30/03/2008 à 11:43. (lien). Évalué à 2.
        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
        
        [ Répondre ]
        
        [^]Re: Re:
        
        Posté par bubar () le 30/03/2008 à 12:57. (lien). Évalué à 3.
        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!
        
        [ Répondre ]
        
        [^]Re: Re:
        
        Posté par IsNotGood () le 30/03/2008 à 13:57. (lien). Évalué à 3.
        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.
        
        [ Répondre ]
      - [^]Re: Re:
        
        Posté par IsNotGood () le 30/03/2008 à 11:49. (lien). Évalué à 2.
        > "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).
        
        [ Répondre ]
        
        [^]Re: Re:
        
        Posté par bubar () le 30/03/2008 à 12:18. (lien). Évalué à 2.
        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
        
        [ Répondre ]
        
        [^]Re: Re:
        
        Posté par bubar () le 30/03/2008 à 12:28. (lien). Évalué à 2.
        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.
        
        [ Répondre ]
        
        [^]Re: Re:
        
        Posté par IsNotGood () le 30/03/2008 à 14:18. (lien). Évalué à 3.
        > 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).
        
        [ Répondre ]
        
        [^]Re: Re:
        
        Posté par IsNotGood () le 30/03/2008 à 13:35. (lien). Évalué à 2.
        > 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.
        
        [ Répondre ]
        
        [^]Re: Re:
        
        Posté par inico (Jabber id, page perso, ) le 30/03/2008 à 18:28. (lien). Évalué à 1.
        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..
        
        [ Répondre ]
        
        [^]Re: Re:
        
        Posté par Mildred (Jabber id, page perso, ) le 30/03/2008 à 19:48. (lien). Évalué à 2.
        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
        
        [ Répondre ]

[^]Re: Re:

Posté par Olivier Tétard (Jabber id, page perso, ) le 29/03/2008 à 21:30. (lien). Évalué à 2.
> 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;

[ Répondre ]
- [^]Re: Re:
  
  Posté par IsNotGood () le 29/03/2008 à 23:58. (lien). Évalué à 3.
  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.
  
  [ Répondre ]
  - [^]Re: Re:
    
    Posté par madko () le 31/03/2008 à 15:00. (lien). Évalué à 2.
    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
    
    [ Répondre ]

Revenir en haut de page

Articles précédents : Distribution

Liens connexes

Dépêche modérée par

Dépêche éditée par

Distribution : La Fedora 9 arrive en version beta

testeur de la beta

[^]Re: testeur de la beta

Installation

[^]Re: Installation

[^]Re: Installation

[^]Re: Installation

[^]Re: Installation

[^]Re: Installation

[^]Re: Installation

[^]Re: Installation

[^]Re: Installation

[^]Re: Installation

[^]Re: Installation

[^]Re: Installation

[^]Re: Installation

[^]Re: Installation

[^]Re: Installation

[^]Re: Installation

Re:

[^]Re: Re:

[^]Re: Re:

[^]Re: Re:

[^]Re: Re:

[^]Re: Re:

[^]Re: Re:

[^]Re: Re:

[^]Re: Re:

[^]Re: Re:

[^]Re: Re:

[^]Re: Re:

[^]Re: Re:

[^]Re: Re:

[^]Re: Re:

[^]Re: Re:

[^]Re: Re:

[^]Re: Re:

[^]Re: Re:

[^]Re: Re:

[^]Re: Re: