FC4T2 : Fedora Core 4 Test 2
Ben voilà, elle est sortie (annonce+miroirs) :
http://www.redhat.com/archives/fedora-announce-list/2005-April/msg0(...)
Les torrents
http://torrent.dulug.duke.edu/(...)
Plein de truc pour draguer les filles (ou les mecs) ou pour faire plaisir à sa belle-mère (ou beau-père) :
- gnome 2.10
- KDE 3.4
- gcc 4.0 par défaut
- du java tout partout
- eclipse en natif
- OOo 2.0
- Xen
- evince
- etc
Version finale pour le 6 juin.
Notons qu'il y a des paquets Fedora Extra pour la branche développement (actuellement la future FC4) :
http://fr2.rpmfind.net/linux/fedora/extras/development/(...)
C'est pour i386, AMD64, ppc.
Fedora Extra :
http://www.fedoraproject.org/wiki/Extras(...)
À voir dans les torrents, les vidéos du dernier FUDCon.
FUDCon I :
http://fedoraproject.org/fudcon/FUDCon1/(...)
FUDCon II en juin et en Europe (LinuxTag) ! :
http://fedoraproject.org/fudcon/(...)
# Synaptic toujours pas intégré ?
Posté par Adrien BUSTANY (site web personnel) . Évalué à 3.
[^] # Re: Synaptic toujours pas intégré ?
Posté par ArnY (site web personnel) . Évalué à 2.
- yumex (avec son applet pour remplacer la rhn-applet) http://linux.rasmil.dk/dnl/(...)
howto ici: http://fedoranews.org/tchung/yumex/(...)
- gyum (aussi connu sous le nom de yumgui) http://cobind.com/yumgui.html(...)
howto ici: http://fedoranews.org/tchung/gyum/2.0/(...)
Des deux, yumex est largement recommandé puisqu'il tire parti des ameliorations de la version 2.1 de yum.
les howtos sont pour la frc3, mais cela ne devrait pas poser de problème pour la fc4t2
Sinon, sur la roadmap de la fc5, je crois qu'il a un package manager compatible yum... (qui devrait s'integrer à anaconda afin de pouvoir récuperer les packages des extras directement pendant l'installation)
[^] # Re: Synaptic toujours pas intégré ?
Posté par Adrien BUSTANY (site web personnel) . Évalué à 4.
[^] # Re: Synaptic toujours pas intégré ?
Posté par fabb . Évalué à 1.
http://smartpm.org/(...)
C'est en phase béta. C'est sympa et prometteur.
[^] # Re: Synaptic toujours pas intégré ?
Posté par TImaniac (site web personnel) . Évalué à 3.
Bref yum est pratique, mais tant qu'à faire une IHM, faudrait repartir de 0.
Si tu veux un truc de gestion de paquets digne de ce nom, y'a Open-Carpet (ex red-carpet), dommage qu'il n'y ai pas assez de repositories compatibles pour fedora.
# Toujours plus de stabilite ?
Posté par Quentin Delance . Évalué à 0.
La date de freeze est plus ou moins pour la fin de mois :
http://fedora.redhat.com/participate/schedule/(...)
et meme si la sortie de OOo 2.0 etait compatible avec le freeze de la FC 4 ca veut dire que OOo version RPM Fedora ne recevrait aucun test.
Bref Fedora continue d'etre une grosse experimentation a ciel ouvert. Pas de quoi attirer les foules a mon sens.
Apres il ne faut pas s'etonner sur les gens se tournent vers des version gratuites de la RHEL, qui sont elles stables, pas comme la Fedora :(
[^] # Re: Toujours plus de stabilite ?
Posté par Matthieu Moy (site web personnel) . Évalué à 8.
C'est un objectif affiché de Fedora.
http://fedora.redhat.com/about/objectives.html(...)
Be on the leading edge of open source technology, by adopting and helping develop new features and version upgrades. [...] Promote rapid adoption of new releases [...] Form the basis of Red Hat's commercially supported operating system products.
Que je traduirais grosso modo par "On se jette sur toutes les nouveautés, on fait ce qu'on peut pour que ça ne nous pète pas a la gueule, mais si ça casse, c'est toujours mieux que si ça cassait dans RHEL". (ce qui est assez logique vu que c'est principalement RedHat qui paye les développeurs ...)
> Pas de quoi attirer les foules a mon sens.
Tu en bénéficie pourtant probablement indirectement, même si tu n'utilises pas Fedora. Maintenant, si tu cherches des solutions éprouvées et longuement testées, Fedora n'est pas faite pour toi (< troll > prends une Debian stable plutôt </ troll >).
[^] # Re: Toujours plus de stabilite ?
Posté par fabb . Évalué à 2.
Pour les bugfix il n'y a pas de date limite. La version finale est pour début juin.
> ca veut dire que OOo version RPM Fedora ne recevrait aucun test.
N'importe quoi.
> Pas de quoi attirer les foules a mon sens.
Ben utilise pas.
> Apres il ne faut pas s'etonner sur les gens se tournent vers des version gratuites de la RHEL, qui sont elles stables
Fedora est très stable.
Tu critiques sans connaitre.
[^] # Re: Toujours plus de stabilite ?
Posté par Adrien BUSTANY (site web personnel) . Évalué à 1.
[^] # Re: Toujours plus de stabilite ?
Posté par fabb . Évalué à 1.
À moi qui utilise Red Hat/Fedora depuis la version RH4.2 ou à Quentin DELANCE ?
[^] # Re: Toujours plus de stabilite ?
Posté par Adrien BUSTANY (site web personnel) . Évalué à 1.
[^] # Re: Toujours plus de stabilite ?
Posté par Quentin Delance . Évalué à 1.
Relis mon post et tu verras que je n'ai rien dit de tel (mais vous etes vraiment de mauvaise foi ou quoi ?).
OOo est une version beta, elle plante c'est normal. Ne me dit pas le contraire je l'utilise. (si la version Fedora ne plante pas alors il faut que le projet OOo s'arrete et reparte des sources de Fedora !)
Et puis dire que OOo plante ca n'a pas grand chose a voir avec les devs Fedora qui font principalement du packaging de l'OOo de SUN (OOo n'etant pas encore un modele de devel communautaire, SUN formant le gros des troupes cote devel).
[^] # Re: Toujours plus de stabilite ?
Posté par Quentin Delance . Évalué à 1.
J'utilise la Fedora en milieu professionnel car certains clients veulent a tout prix l'utiliser (l'historique Red Hat rassure) mais regulierement je trouve de gros pb et de gros bugs.
Pas surprennant etant donne l'objectif vise par la Fedora (grosse distrib de test) mais je pense qu'il est de moins en moins raisonnable de la recommander a des utilisateurs de base. Ca degrade l'image de Linux ("linux c'est aussi buggue que windows finalement").
Et non en ce qui me concerne ce n'est pas ce que j'utilise (Debian testing pour moi).
Mais libre a toi de te contenter d'un laconique "n'importe quoi", cela te grandit.
# OOo2
Posté par Pinaraf . Évalué à 2.
En même temps, c'est bien d'avoir une distrib qui ose mettre des logiciels comme gcc 4.0 par défaut ! Ça ça va faire bouger les choses
[^] # Re: OOo2
Posté par gnumdk (site web personnel) . Évalué à 4.
[^] # Re: OOo2
Posté par Pinaraf . Évalué à 1.
Surtout que elle elle doit sortir bientôt, non ? Bref, vivent les applis instables qu'on intègre dans une distribution "stable" : je sais pas ce que ça va donner, mais j'espère pour eux qu'ils mettront des mises à jour dans you pour pouvoir passer à la finale facilement.
[^] # Re: OOo2
Posté par Guillaume POIRIER . Évalué à 1.
Ca dépend de quel côté de la barrière tu te trouve tu sais.
Si tu es du côté développeur, c'est quand même pas marrant de devoir retoucher du code qui marchait très bien pour qu'il fonctionne à nouveau avec GCC-4.0.
Par exemple, dans FFmpeg et MPlayer, il y a tout un tas de fonctions écrites en assembleur inline pour gérer des transformations d'images en SIMD (MMX, SSE, tout ça).
GCC-4.0 oblige à retoucher à ce code là en « l'obfuscant », et pour des raisons qui m'échappent autant qu'aux devs de ce magnifique projet. Les gens de GCC ont beau dire qu'il n'y aurait pas eu de problèmes si le code avait été codé avec des « intrisincs », ce qui est largement plus propre, le problème c'est que les vieilles versions de GCC ne le gèrent pas ou peu, ce qui n'est pas très cool pour les gens qui utilisent encore GCC-2.95.
Tu avoueras que quand tu as un bout de code qui fonctionne bien tu as pas envie d'y toucher.
C'est sûr que tu côté utilisateur, on est moins sensible à ce genre d'argument.... sauf quand tes applications favorites ne compilent plus!
[^] # Re: OOo2
Posté par Guillaume POIRIER . Évalué à -1.
Si tu es du côté développeur, c'est quand même pas marrant de devoir retoucher du code qui marchait très bien pour qu'il fonctionne à nouveau avec GCC-4.0.
Par exemple, dans FFmpeg/MPlayer, il y a tout un tas de fonctions écrites en assembleur inline pour gérer des transformations d'images en SIMD (MMX, SSE, tout ça).
GCC-4.0 oblige à retoucher à ce code là en « l'obfuscant », et pour des raisons qui m'échappent autant qu'aux devs de ce magnifique projet. Les gens de GCC ont beau dire qu'il n'y aurait pas eu de problèmes si le code avait été codé avec des « intrisincs », ce qui est largement plus propre, le problème c'est que les vieilles versions de GCC ne le gèrent pas ou peu, ce qui n'est pas très cool pour les gens qui utilisent encore GCC-2.95.
Tu avoueras que quand tu as un bout de code qui fonctionne bien tu as pas envie d'y toucher.
Par contre, du côté utilisateur, c'est tout bénèf' puisque apparemment les perfs sont là... sauf qu'on s'en fout des perfs quand on ne peut plus compiler ses applications favorites!
# Expérience perso (sans prétention)
Posté par galactikboulay . Évalué à 2.
petit test de Fedora Core 2 Test 4. Je précise que je n'y connais rien
du tout à Fedora, j'ai juste l'expérience de RedHat 6 jusqu'à RedHat
9. J'utilise habituellement Debian.
Au niveau installation, rien à dire, tout est convivial et s'est très
bien passé. Graphiquement parlant, ça en jette.
Très bon point, gestion de SELinux et de LVM dès le départ.
Je voulais tester Fedora dans le contexte où j'utilise mon PC
habituellement, à savoir machine de développement (surtout que
là, avec GCC 4, c'est une bonne occasion de tester Fedora). Pour les
packages, installation en mode custom avec sélection des groupes
de packages adéquats (Développement X and co).
Au reboot, je trouve un environnement Gnome 2.10, que je n'ai
pas étudié dans le détail, mais qui m'a semblé fonctionnel.
Là où ça s'est un peu corsé, c'est pour compiler une appli à moi.
Cette appli a besoin de net-snmp et net-snmp-devel, c'était donc
l'occasion de tester le gestionnaire de package.
J'ai pas lu de doc (je sais sai mal), mais bon yum est tout sauf
intuitif... Quelques imports de clés GPG plus loin, j'arrive à installer
net-snmp, par contre net-snmp-devel il veut pas. Pas trop compris
pourquoi. J'ai fini par télécharger le RPM à la main, là ça passe
comme papa dans maman. Un peu curieux.
Le truc qui chiffonne surtout, c'est la lenteur effroyable de yum.
Une petite remarque au passage, apparemment c'est écrit en
python, y'a pas intérêt à ce que l'installation de python soit gauffrée
sur la machine pour une raison X ou Y, parce que sinon ça doit
être assez fun.
Au niveau de la doc en ligne, je pensais que le site de RedHat
répondrait à certaines de mes questions, mais ça n'a pas été
le cas. Globalement, j'ai eu moins de mal à installer des packages
sur FreeBSD 5.3 et OpenBSD 3.6 que sur FC4T2, alors que je ne
connais pas du tout les *BSD. Ceux qui connaissent le FreeBSD
Handbook comprendront ce que je veux dire par doc super intuitive.
La 1ère fois que j'ai installé une Debian, j'avais pas lu de doc non
plus, mais en 5 min je me débrouillais sans pb avec dpkg / apt.
Au niveau de GCC 4, il reste quelques petites choses à voir, du style:
cisco_dtp.c:385: warning: pointer targets in passing argument 2 of â differ in signedness
ipflow_cli.c:92: warning: â defined but not used
Apparemment quelques bugs dans l'affichage des erreurs (â au lieu
du nom de la fonction), et ça fait vraiment expérimental :)
Je n'ai pas testé les performances de programmes compilés par
GCC 4.
Bref, je vais continuer à découvrir FC4T2, de ce 1er test
pour moi les points forts c'est :
- SELinux
- Gnome 2.10
- L'intégration du système
Le point faible:
- la gestion des packages
[^] # Re: Expérience perso (sans prétention)
Posté par fabb . Évalué à 1.
C'est une version de test :-)
Tu dois être sur Rawhide (la branche de développement de FC4).
Sans plus d'info, je ne peux en dire.
> y'a pas intérêt à ce que l'installation de python soit gauffrée sur la machine pour une raison X ou Y
Il y a toujours rpm.
> Au niveau de la doc en ligne, je pensais que le site de RedHat répondrait à certaines de mes questions
La doc en ligne c'est man, info, etc...
Pour yum, c'est "yum --help" ou "man yum".
Je ne pense pas qu'il soit dans l'esprit de Fedora d'avoir plein de doc. Le but est le "just works".
Mais tu voulais quoi comme doc ?
Un lien utile pour utiliser Fedora (ici c'est FC3) :
http://www.fedorafaq.org/(...)
> Bref, je vais continuer à découvrir FC4T2
Fais une mise à jours :
- yum update
Il y a déjà près de 300 Mo de nouveau paquet.
> Le point faible:
> - la gestion des packages
La gestion des paquets ou l'outil de gestion des paquets ?
Yum, en tant qu'outil en ligne de commande marche bien. Je l'apprécie beaucoup. Par contre il est lent. Mais je le préfère à apt par exemple.
Un outil intéressant (quoique certains comportements soient discutables) est smart :
http://smartpm.org/(...)
[^] # Re: Expérience perso (sans prétention)
Posté par galactikboulay . Évalué à 2.
Oui c'est pour ça que je ne m'en offusque pas, ça sera surement
corrigé lors de la version finale :)
J'aurais voulu avoir une doc sur le WEB expliquant comment gérer
proprement les packages avec rpm/yum, tout bêtement.
Merci pour ton lien, je vais y jeter un coup d'oeil.
C'est ce que j'avais fait juste après l'installation, il y a eu
effectivement pas mal de packages mis à jour (une centaine
je crois).
Je le trouve vraiment horriblement lent. C'est mon reproche principal.
Après, j'ai pas eu le temps d'en faire le tour :)
Sinon, par curiosité, qu'est-ce que tu reproches à apt ?
[^] # Re: Expérience perso (sans prétention)
Posté par fabb . Évalué à 1.
Si après un "yum update" qui met 200 paquets à jours tu trouves que yum est lent, tu te trompes un peu.
Là le temps est principalement lié à rpm (qui fait beaucoup de flush avec db4 pour assurer l'intégrité de la base, etc). Yum ne fait "que" résolveur. Il n'installe ou ne met pas à jours les paquets. C'est librpm qui le fait.
Par contre, même si yum est lent, il est apprécié pour ça "justesse". Il n'a pas d'optimisation avec des effets de bord, les dépendances sont calculées en s'appuyant sur librpm, il gère le bi-arch (mix i386/amd64), gére les dépendances sur fichier (Require: /etc/xinirc, etc). Sur les mailing test et devel de Fedora (où 95 % des gens connaissent apt), c'est yum qui a la préférence et de loin.
Si tu ne peux "vivre" sans apt, il y a apt et synaptic dans Fedora Extra (aussi dans la branche de développement actuellement dédié à FC4).
Saches que apt4rpm n'est plus vraiment maintenu. Smart (qui n'est pas encore dans Fedora Extra) est le remplaçant de apt4rpm. J'ai testé et bien qu'en phase beta, je peux affirmer que c'est du bon (bien que j'apprécie moyennement certains choix. Question de goût). Smart utilise python mais est aussi partiellement écrit en C. Il est beaucoup plus rapide que Yum. A une interface TUI et GUI.
Néanmoins j'utilise encore yum. Mais il est possible qu'un jour je switche vers Smart.
> J'aurais voulu avoir une doc sur le WEB expliquant comment gérer proprement les packages avec rpm/yum, tout bêtement.
Mouaif. Si tu lis la page man de yum, c'est suffisant.
Normalement, yum est pour les développeurs/testeurs/experts.
Pour l'utilisateur "moyen", c'est system-config-packages. Mais il sucks grave :-)
Au-delà de la doc, ce qui manque surtout c'est la finalisation de system-config-packages (qui doit devenir une couche graphique de yum).
La page des specs :
http://fedora.redhat.com/projects/config-tools/specs/redhat-config-(...)
Le gros gros problème est là. Ça avance mais dieu que c'est lent. Pire que yum :-)
Red Hat ne se mets pas la pression sur ce point car pour RHEL c'est up2date qui est principalement utilisé (System-config-packages étant limité à l'installation/désinstallation de paquet depuis les CD) et pour Fedora les développeurs sont déjà "accros" à yum.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.