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. 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".
Aller plus loin
- La note officielle de la sortie de la beta (1 clic)
- Fedora 9 Feature List (1 clic)
# testeur de la beta
Posté par lejocelyn (site web personnel) . Évalué à 6.
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.
[^] # Re: testeur de la beta
Posté par lejocelyn (site web personnel) . Évalué à 2.
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
# Installation
Posté par Mildred (site web personnel) . Évalué à 3.
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 !
[^] # Re: Installation
Posté par IsNotGood . Évalué à 4.
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.
[^] # Re: Installation
Posté par bubar🦥 (Mastodon) . Évalué à 5.
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 ?
[^] # Re: Installation
Posté par bubar🦥 (Mastodon) . Évalué à 4.
http://img180.imageshack.us/img180/1597/captureua6.jpg
[^] # Re: Installation
Posté par Fopossum . Évalué à 1.
T'as pas honte de coller du Linux sur le réseau eu ? Alors que le master officiel est encore en W2K :)
cd /pub && more beer
[^] # Re: Installation
Posté par bubar🦥 (Mastodon) . Évalué à 2.
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 ;)
[^] # Re: Installation
Posté par Fopossum . Évalué à 1.
cd /pub && more beer
[^] # Re: Installation
Posté par madko (site web personnel) . Évalué à 6.
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...
[^] # Re: Installation
Posté par IsNotGood . Évalué à 4.
> 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.
[^] # Re: Installation
Posté par GeneralZod . Évalué à 2.
Sinon, pour faire des chroots, tu as mock qui supporte parfaitement yum et qui peut chrooter n'importe quelle distribution à base de rpm.
[^] # Re: Installation
Posté par Mildred (site web personnel) . Évalué à 3.
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 :)
[^] # Re: Installation
Posté par bubar🦥 (Mastodon) . Évalué à 2.
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
[^] # Re: Installation
Posté par IsNotGood . Évalué à 2.
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".
[^] # Re: Installation
Posté par Mildred (site web personnel) . Évalué à 4.
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
[^] # Re: Installation
Posté par IsNotGood . Évalué à 2.
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.
[^] # Re: Installation
Posté par Olivier Tétard (site web personnel) . Évalué à 1.
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;
# Re:
Posté par IsNotGood . Évalué à 4.
> 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:
Posté par madko (site web personnel) . Évalué à 5.
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:
Posté par madko (site web personnel) . Évalué à 2.
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:
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Et sur le site du projet sont réunis de nombreux résultats de tests.
http://www.bootchart.org/samples.html
Cordialement
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
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:
Posté par imr . Évalué à 8.
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:
Posté par IsNotGood . Évalué à 3.
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:
Posté par bubar🦥 (Mastodon) . Évalué à 4.
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:
Posté par Mildred (site web personnel) . Évalué à 2.
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)
[^] # Re: Re:
Posté par bubar🦥 (Mastodon) . Évalué à 3.
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:
Posté par IsNotGood . Évalué à 3.
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:
Posté par IsNotGood . Évalué à 2.
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:
Posté par bubar🦥 (Mastodon) . Évalué à 2.
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:
Posté par bubar🦥 (Mastodon) . Évalué à 2.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 3.
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:
Posté par IsNotGood . Évalué à 2.
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:
Posté par inico (site web personnel) . Évalué à 1.
=> 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.
[^] # Re: Re:
Posté par Mildred (site web personnel) . Évalué à 2.
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à.
[^] # Re: Re:
Posté par Olivier Tétard (site web personnel) . Évalué à 2.
> 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:
Posté par IsNotGood . Évalué à 3.
> 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:
Posté par madko (site web personnel) . Évalué à 2.
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
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.