Test de Fedora 13 : Goddard

Posté par  (site web personnel) . Modéré par Mouns.
Étiquettes :
7
26
juil.
2010
Fedora
La distribution Fedora 13 (Goddard) est sortie le 25 mai dernier, comme annoncé sur LinuxFr.org, et j'ai réalisé un test de cette dernière avec les captures d'écran d'usage.

J'ai pour l'occasion téléchargé la version i386 sur mon Toshiba Qosmio G40 (4 Go de RAM et carte vidéo Nvidia). Dans la liste des derniers paquets, j'ai noté : ALSA 1.0.23, noyau 2.6.33, KDE 4.4, Gnome 2.6.30, GCC 4.4.4, X.Org Server 1.8.0, Firefox 3.6.3, et encore beaucoup de bonnes choses.

Je vous invite à consulter ce petit survol des nouveautés à la sauce FRLinux. (Petit rappel, comme pour la plupart des distributions testées, le but est de fournir un avis rapide sur une distribution pour l'utilisateur ou le décideur pressé.)

Aller plus loin

  • # i386

    Posté par  . Évalué à 7.

    32 bit sur une machine avec plus de 3.5 Go de RAM ?

    DLFP >> PCInpact > Numerama >> LinuxFr.org

    • [^] # Re: i386

      Posté par  (site web personnel) . Évalué à 3.

      Il existe encore beaucoup de processeur sans PAE ?

    • [^] # PAE (was i386)

      Posté par  . Évalué à 3.

      Fedora supporte le [http://en.wikipedia.org/wiki/Physical_Address_Extension PAE] depuis belle lurette, donc pas de soucis de ce côté là. ;)
      (par contre, une application seule ne peux pas accéder à plus de ~4GB)

      P.S. Lundi matin je ne sais plus faire de liens sur dlfp! :)

      • [^] # Re: PAE (was i386)

        Posté par  . Évalué à 4.

        C'est pas plutôt le kernel qui supporte le PAE ?

        • [^] # Re: PAE (was i386)

          Posté par  . Évalué à 2.

          Merci aux développeurs du kernel!

          • [^] # Re: PAE (was i386)

            Posté par  . Évalué à 1.

            Oui, of course, merci les kernel devs. ;)
            Par contre, j'ai pas le souvenir d'avoir vu une autre distribution fournir un noyau avec le PAE disponible. (ou j'ai raté quelques marches ...)

            • [^] # Re: PAE (was i386)

              Posté par  (site web personnel) . Évalué à 1.

              Opensuse aussi

            • [^] # Re: PAE (was i386)

              Posté par  (site web personnel) . Évalué à 2.

              Ben quasiment toute, non ? Vu que Mandriva le propose, Opensuse ( cf remarque ), Fedora, et je vois pas de raison ( à part un bug dans une gamme de P4 ) pour ne pas le supporter.

              • [^] # Re: PAE (was i386)

                Posté par  . Évalué à 4.

                Merci les développeurs mandriva, merci les cookers, merci le plf, merci misc, sophie: salope !

                • [^] # Re: PAE (was i386)

                  Posté par  . Évalué à 5.

                  sophie: salope !

                  Mais non, c'est « sophie : fonfec ! »

                  (oui bon, ça passe moins bien à l'écrit)

                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: PAE (was i386)

        Posté par  (site web personnel) . Évalué à 4.

        Sans oublier le problème de la division de la mémoire en zone haute et basse, ce qui peut causer des problèmes de fragmentation bien plus rapidement qu'en x86_64.
        http://linux-mm.org/HighMemory

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: i386

      Posté par  (site web personnel) . Évalué à 2.

      C'est vrai que depuis, on a inventé les systèmes 64 bits. Linux a pris en charge les instructions AMD64 avant même que des processeurs les implémentant soient physiquement disponibles. Les logiciels libres étant très portables, c'est une honte d'utiliser ces processeurs en 32 bits comme de vulgaires utilisateurs de Windows.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 1.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: i386

          Posté par  . Évalué à 4.

          Ce n'est pas ce qui est dit.

          Ce qui est dit, c'est que les versions 64 bits de Windows sont arrivés *bien* après celles de distributions libres.

          Pour Windows il a fallu attendre la prochaine release. Pour les distribs, il suffit d'attendre que le paquet soit disponible pour la bonne architecture. Les paquets essentiels (kernel, libc etc.) ont été dispo très rapidement.

          Il faut aussi noter que sous Windows, la philosophie du .exe n'a pas aidé. Pour passer en 64 bits, il faut attendre une nouvelle version du logiciel. Et comme tu n'as pas les sources, ben à part attendre, tu ne peux pas faire grand chose. Alors que quand on a les sources, il suffit de recompiler (éventuellement bidouiller, bugreporter, chercher dans la doc etc. Ce n'est pas toujours simple, mais c'est toujours possible).

          Il faut aussi noter que la logique du .exe à code source non disponible l'est souvent pour une logique commerciale. L'éditeur une fois qu'il a réussi à faire payer pour te filer son binaire, il est content. Pour qu'il t'en file un autre sans surcout, il faut que tu sois vachement convaincant.


          Donc oui, il existe des versions 64 bits de Windows (mais qui sont arrivés bien après les version 64 bits des distribs libres), mais je suppose que les Windows 64 bits sont encore blindés de binaires 32 bits (je n'ai pas été vérifier, je me plante peut être, mais ça me semble hautement probable), alors que des distribs full 64 bits, il y en a à foison.

          Et c'est quand même un peu con de se payer un super CPU 64 bits top moumoute avec plein de registres de la mort pour faire des gros scores à 3DMark, mais si c'est pour gâcher les ressources en question, c'est dommage. Mais je pense que l'optimisation des ressources est plus souvent une préoccupation pour un libriste que pour un utilisateur de Windows.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 2.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: i386

              Posté par  . Évalué à 5.

              Aller hop! Faut relever le troll du Windows 64bits (surtout dès Lundi).
              Le support du 64 bits date de 2001 de mémoire, à peu près la même époque pour Linux; pour NetBSD c'est vers 1994 si mes souvenirs sont bons ...
              Mais dans l'absolu, la question n'est pas de savoir si l'OS supporte entièrement le 64 bits, ou si les binaires sont elles-même fournies compilées pour du 64 bits, ou si l'OS est en 64 bits et s'amuse à faire tourner des applications 32 bits. Non, la question c'est de savoir si les applications (celles qui en ont réellement besoin au passage) ont été conçues pour tourner sur du 64 bits ou pas. A ma connaissance, c'est assez rare et on se contente trop souvent de compiler en 64 bits en ajoutant juste le support pour plus de 4GB de mémoire virtuelle ... et encore, c'est pas tout le temps le cas.

              P.S. oui, il y a bien des applications 64 bits sous Windows; regardez par exemple IE! au passage, c'est un très bon anti-flash puisque flash n'existe qu'en 32 bits et refusera de s'installer si vous utilisez IE-64 ... dans le monde des bras cassés, y'a pas à dire, y'en a qui sont rois! =)

              • [^] # Re: i386

                Posté par  (site web personnel) . Évalué à 1.

                Non, la question c'est de savoir si les applications (celles qui en ont réellement besoin au passage) ont été conçues pour tourner sur du 64 bits ou pas. A ma connaissance, c'est assez rare et on se contente trop souvent de compiler en 64 bits en ajoutant juste le support pour plus de 4GB de mémoire virtuelle ... et encore, c'est pas tout le temps le cas.

                En même temps, à part une application spécialisée ou optimisée à mort, je ne vois pas pourquoi elle tiendrait compte de l'architecture. Pour mes propres applications, je vois mal comment tirer partie du 64bits.

      • [^] # Re: i386

        Posté par  (site web personnel) . Évalué à 3.

        Mais le fait d'avoir un système 64 bits, ça rends pas les programmes plus gros ( je me souvient d'avoir 20% de plus sur la taille de ls entre 32 et 64 ) ?

        • [^] # Re: i386

          Posté par  . Évalué à 2.

          Mais quand tu es en 64 bits, tu en as une grosse (de mémoire). ;)

        • [^] # Re: i386

          Posté par  (site web personnel) . Évalué à -1.

          Plus gros ? Avec une installation de tous les logiciels dont tu auras jamais besoin, ça fait si mal que ça de passer de 7 Gio à 7,3 Gio ? On peut déjà s'estimer heureux de ne pas être à 30 Gio comme les utilisateurs d'autres systèmes.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 1.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: i386

              Posté par  (site web personnel) . Évalué à 5.

              Moi ? Rien, là-dessus je ne suis pas amer, au contraire. C'est grâce aux gens qui achètent des ordinateurs avec des processeurs quad-cœur hyperthreadés à 2 GHz, 4 Gio de mémoire et 500 Gio de stockage que je peux acheter pour pas cher un ordinateur déjà surpuissant pour moi avec un processeur mono-cœur à 1 GHz, 512 Mio de mémoire et 40 Gio de stockage.

            • [^] # Re: i386

              Posté par  (site web personnel) . Évalué à 5.

              Bien joué. La dernière fois que j'ai essayé d'installer Windows XP sur une partition de cette taille là, après trois mises à jour c'était plein.

              Je suis quand même muet d'admiration devant le DVD bien rempli pour installer un système d'exploitation tout nu dont les fonctionnalités sans rien installer d'autres sont inférieures à ce que j'installe personnellement sur un CD.

              • [^] # Re: i386

                Posté par  . Évalué à 3.

                Un DVD pour installer un OS ?

                Quand je pense qu'aujourd'hui, on peut faire tenir un OS moderne sur un CD avec tout ce qu'il faut (multimédia et bureutique), et aller jusqu'à l'utiliser sans avoir besoin de l'installer...

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: i386

              Posté par  . Évalué à 3.

              avec suite Open Office complete
              Faut dire que tu as pris léger là, environ 200Mo pour l'installation. La suite office de Microsoft, version 2007, prend grosso modo 1GB.

            • [^] # Re: i386

              Posté par  (site web personnel) . Évalué à 1.

              30GB ? à mon avis, il parle de Mac OS X (10.5).
              En tout cas, je ne l'ai jamais utilisé, et à part installer les mises à jour, un driver ext2/3 et des dev tools (que j'ai supprimé par manque de place), ça remplit bien la partition 30GB allouée.

              Il n'y a tellement plus de place que je ne peux plus faire de mises à jour. En même temps, je crois que la prochaine fois que je réinstalle cer ordinateur, Mac OS X passera à la trappe.

              • [^] # Re: i386

                Posté par  . Évalué à 1.

                30 Gigas? C'est pire qu'un Windows XP/Vista et ses 10 Gigs minimum. Dire que je viens d'installer un linux et que cela m'a pris 5Gigs et cela comprend OOo et Latex (d'ailleurs ce dernier avec tous les trucs associe en full install ca prend quasiement 1Gigs maintenant...)

          • [^] # Re: i386

            Posté par  . Évalué à 2.

            Plus gros ? (...) de passer de 7 Gio à 7,3 Gio ?
            Il faut surtout voir les effets de cache. Un code 20% plus gros, ça fait à l'ordre 1 20% de cache miss en plus, et ça peut beaucoup se sentir sur certains codes.

            Il y a un vieux bench ici http://www.geekpatrol.ca/2006/09/32-bit-vs-64-bit-performanc(...) où il faut par exemple oublier le test Blowfish, cet algorithme ayant été fait spécialement pour les architectures 32 bits et non pas 64 bits.

      • [^] # Re: i386

        Posté par  (site web personnel) . Évalué à 2.

        Bon, je reformule, parce que j'ai été mal compris. Faire une installation 32 bits sur un processeur 64 bits, c'est du gâchis et ça n'a aucun intérêt.

        C'est juste bon pour les utilisateurs de systèmes dont les pilotes ou logiciels n'ont pas été adaptés assez vite. Pour un utilisateur de logiciels libres c'est juste complètement con, et c'est choisir volontairement de ne pas profiter d'un des avantages du libre, sa portabilité.

        • [^] # Re: i386

          Posté par  (site web personnel) . Évalué à 3.

          Faire une installation 32 bits sur un processeur 64 bits, c'est du gâchis et ça n'a aucun intérêt.

          c'est justement ce qui est bizarre, sur http://smolts.org/static/stats/stats.html c'est 33% qui ont choisi de faire ce que tu préconises. 66% préfèrent visiblement rester en i686 alors que la plupart des processeurs actuels gèrent les instructions x86_64.

          • [^] # Re: i386

            Posté par  . Évalué à 3.

            C'est à cause des gens qui ne veulent pas se poser de questions, et qui sont restée sur la vieille idée, sans doute complètement fausse, que le 64 bits peut poser des problèmes.
            Par exemple, au hasard, moi.

            Un jour sans doute, j'essayerais une installation en 64 bits.

            LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140

            • [^] # Re: i386

              Posté par  (site web personnel) . Évalué à 2.

              Le seul problème que je connaisse (à l'heure actuelle) avec le 64 bit est le suivant : en choisissant de ne pas inclure le support pour les binaires 32 bits dans son noyau (ce n'est qu'une option) il devient difficile de se préparer une nouvelle version de grub… Rien à voir avec les problèmes de 2002 quand tout le monde se préparer à passer au ia64 et que toute les librairies boggaient en tout sens.

              « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

          • [^] # Re: i386

            Posté par  (site web personnel) . Évalué à 2.

            Ah, c'est sûr que si on conseille aux gens d'installer un système 32 bits par défaut, il y aura plus de gens avec ça.

            • [^] # Re: i386

              Posté par  (site web personnel) . Évalué à 3.

              Tu remarqueras que je n'ai pas indiqué ce qui serait à préconiser. Il est possible de faire dire tout et son contraire à des statistiques.

              J'ai beau utiliser du x86_64 sur mon desktop, je ne le recommande qu'à des personnes prêtes à faire du tout libre (exit flash, google-earth, wine et consors..., l'install' des lib32 étant pour moi un pis-aller et surtout une perte de place) ou ayant 4 Go (ou plus) de RAM.

              • [^] # Re: i386

                Posté par  (site web personnel) . Évalué à 2.

                Pour moi c'est si tu veux faire des concessions au libre que le 64bits est moins bien (la tripotée de lib32- à installer pour wine, le driver alpha de la daube... ou alors sauter par la fenêtre).

                Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

                • [^] # Re: i386

                  Posté par  (site web personnel) . Évalué à 2.

                  o_O
                  il est très bien le x86_64 (natif hein, comme je dis, sans pourritures de lib32 qui traînent de ci-de là), justement pour se passer des ignominies - inutiles généralement - qui ne font même pas l'effort d'être portables voire libres...

          • [^] # Re: i386

            Posté par  (site web personnel) . Évalué à 2.

            Utiliser et conseiller d'utiliser un système 32 bits parce que la plupart des gens utilisent un système 32 bits, c'est un cercle vicieux.

            D'ailleurs, je te conseille d'utiliser Windows, Internet Explorer et Outlook Express. C'est ce qu'utilise la majorité des gens.

            • [^] # Re: i386

              Posté par  (site web personnel) . Évalué à 3.

              Bon tant pis je me lance :)

              Je n'utilise plus que du 64 bits au travail sur l'intégralité de mes serveurs et certaines stations utilisateurs qui ont des gros besoins de mémoire. Pour les autres, oui je reste conservateur et les installe en 32 bits. Dans le temps, cela nous a occasioné moins de problèmes.

              Coté perso, j'utilise un peu de tout, mais j'ai toujours un moment sur une machine x86_64 ou j'ai une application ou deux qui ne fonctionneront pas. Je suis comme tout le monde, je n'ai pas toujours en préoccupation d'attendre que cela soit corrigé (bien que je reporte souvent le problème).

              Voila :)

        • [^] # Re: i386

          Posté par  (site web personnel) . Évalué à -1.

          Inutile de reformuler, les gens de bonne volonté avaient parfaitement compris. Le propos était parfaitement clair me semble-t-il. Malheureusement, on tolère beaucoup trop les trolls et leur technique consistant à détourner les commentaires en prétendant en faire une interprétation erroné.

          « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

        • [^] # Re: i386

          Posté par  . Évalué à 3.

          Alors qu'une installation 64bits, ça a tout de suite un très gros interêt.

          • [^] # Re: i386

            Posté par  (site web personnel) . Évalué à 2.

            Ah, ça doit en avoir un, sinon, ils ne seraient jamais sortis, les processeurs 64 bits.

            • [^] # Re: i386

              Posté par  . Évalué à 3.

              Je ne peux pas croire que tu crois à ce que tu racontes là.

              • [^] # Re: i386

                Posté par  (site web personnel) . Évalué à 4.

                Il a vite oublié l'utilisation première du x86_64 : le traitement en masse de grosses volumétries de données. Les marchés sont principalement :
                - les bases de données
                - plus spécifiquement tout ce qui est Informatique_décisionnelle
                - tout ce qui réclame des masses de données (codage audio ? hormis que déjà utiliser le multi-coeur ce serait déjà bien...)
                - et là s'est rajouté le marketing : 640 ko ne suffisent pas à tout le monde ; plus c'est gros, plus c'est bon (approché) ; plus c'est gros, meilleur c'est (là, c'est Amanda Lear qui précise que spa la taille qui compte mais le goût /o\) ; on va faire quoi des 16 Go donnés aux utilisateurs^Wpigeons s'ils ne peuvent réellement en utiliser que 3 Go ? et autres arguments plus ou moins valables...

                Perso, je reste sur ma position : pourquoi vouloir du x86_64 ? Si tu ne sais pas, c'est que tu n'en as pas besoin... Les arguments que j'ai mis en avant là-dessus étant recevables àmha, il y en a peut-être d'autres...

                • [^] # Re: i386

                  Posté par  (site web personnel) . Évalué à 2.

                  Pourquoi vouloir du 686 ? Si tu ne sais pas, c'est que tu n'en as pas besoin, mieux vaut installer un système pour 386 dans le doute.

                  • [^] # Re: i386

                    Posté par  (site web personnel) . Évalué à 2.

                    fournir une distribution 386 a du sens effectivement (les ordinosaures), la question était dans l'autre sens si je me rappelle bien ;-)

                    http://en.wikipedia.org/wiki/I686 indique l'Extension_d'adresse_physique aka PAE évoquée au-dessus, mais cela ne va pas dans le sens que tu souhaitais àmha :/ (ni moi d'ailleurs).

                    • [^] # Re: i386

                      Posté par  . Évalué à 2.

                      fournir une distribution 386 a du sens effectivement (les ordinosaures),

                      Fournir du x86_64 n'a pas moins sens, puisque ce sont les processeurs modernes.

                      Quant aux avantages du 64 bits sur x86, je cite Wikipédia (ça vaut ce que ça vaut) :

                      En 64 bits, les entiers et les adresses passent de 32 bits (4 octets) à 64 bits (8 octets). Mais dans le cas de l'architecture x86 ce n'est pas l'unique changement. Les processeurs x86 32 bits actuels (Celeron, Pentium, Pentium II, Pentium III, Pentium 4) sont en fait un processeur 8-bits (l'Intel 8088) amélioré pour faire du 16-bits et à nouveau amélioré pour faire du 32-bits. La structure des registres dans un processeur x86 32 bits hérite donc de ce passé tant dans le nombre réduit de registres que dans leur structure archaïque. Passer de x86 32 bits à x86 64 bits permet de passer de 8 registres généraux 32 bits à 16 registres généraux 64 bits. Il est à noter que ceci ne vaut que pour l'architecture x86, les autres architectures qui existent en 32 bits et 64 bits (MIPS, SPARC, PowerPC...) n'ont pas leur version 32 bits encombrée d'une structure archaïque.

                      Donc si j'ai bien compris, le passage au 64 a permis un dépoussiérage dans les processeurs en les expurgeant de leur héritage pré-32 bits.

                      De là, je pense qu'on peut en déduire que les processeurs sont meilleurs à tout point de vue : plus performants et consommant moins pour une même fréquence.

                      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                      • [^] # Re: i386

                        Posté par  . Évalué à 2.

                        Oui, aujourdhui, le 64bits étant le standard de fait dans les CPUs c'est à peu près logique que les OS s'y mettent. C'est le passage au 64bits pour ceux qui s'en fichent qui n'a pas d'importance particulière.

                        La réflexion d'origine était de l'ordre "c'est une honte d'utiliser un OS 32bits sur une archi 64bits" et ça c'est juste complètement à côté de la plaque, voire puant d'élitisme aveugle sans fondement concret.

                    • [^] # Re: i386

                      Posté par  . Évalué à 2.

                      J'oubliais la référence : https://secure.wikimedia.org/wikipedia/fr/wiki/Processeur_64(...)

                      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: i386

          Posté par  . Évalué à 3.

          Pour un utilisateur de logiciels libres c'est juste complètement con, et c'est choisir volontairement de ne pas profiter d'un des avantages du libre, sa portabilité.
          AMHA les gens qui choisissent le 32 bits ne sont pas des utilisateurs de logiciels libres, mais des utilisateurs de Linux qui veulent avoir recours à des machines virtuelles propriétaires (Adobe Flash) ou des pilotes propriétaires non dispos en 64 bits.

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # J'ai testé aussi

    Posté par  . Évalué à 5.

    Habitué à Debian depuis quelques années (avant j'ai installé un peu tout ce qui me tombait sous la main), j'ai essayé Fedora 13 pour voir. J'ai trouvé le système d'installation et de mise à jour de paquets extrêmement lent, à tel point que je me suis dit qu'il devait y avoir un problème sur mon PC. Il a quand même fini par faire son office. C'est un problème connu sur cette distribution, ou c'est juste chez moi ?

    • [^] # Re: J'ai testé aussi

      Posté par  . Évalué à 4.

      Un petit débat APT Versus RPM pour bien commencer la semaine !

      • [^] # Re: J'ai testé aussi

        Posté par  (site web personnel) . Évalué à 8.

        Mais non, on ne va pas attaquer de troll de si bon matin.

        Et puis RPM est mieux de toute façon.

      • [^] # Re: J'ai testé aussi

        Posté par  (site web personnel) . Évalué à 2.

        De mon expérience, rpm -qf est plus rapide que dpkg -S. Pour tout le reste, dpkg/apt(itude) est vachement plus rapide que rpm/yum.

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: J'ai testé aussi

        Posté par  . Évalué à 2.

        purée, arrêtez de plomber les journaux/dépêches après 2comms!

        C'est une question légitime.
        Les distro genre MDK, RedHat, SuSe ont vraiment des gestionnaires de paquets lourdingues.

        APT combiné à Portage/Pacman serait vraiment le top.

    • [^] # Re: J'ai testé aussi

      Posté par  (site web personnel) . Évalué à 5.

      La première fois ça prend plus de temps, il me semble qu'il teste la rapidité des miroirs pour prendre le plus rapide vu de chez toi.

      Ensuite par contre ça devrait tourner normalement. La lenteur que tu as constatée, c'est avec yum (ligne de commande) ou PackageKit (graphique/Gnome) ?


      P.S.: pour les trolleurs, si vous n'avez pas testé avec un yum très récent, vos tests de rapidité ne valent rien.

      • [^] # Re: J'ai testé aussi

        Posté par  . Évalué à 2.

        Oui, la grosse différence actuellement entre yum et apt-get, c'est que yum va automatiquement chercher à mettre à jour sa base de données via internet alors qu'apt-get vous forcera à le faire manuellement avec un `apt-get update`.

        Conséquence directe pour l'utilisateur : le premier appel à yum est lent, puisqu'il faut se farcir le délai de connexion à chaque dépôt.

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 2.

          Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: J'ai testé aussi

          Posté par  . Évalué à 2.

          Y'a pas que le premier appel de Yum qui est lent, il est lent même sans se mettre à jour.
          Il s'améliore de version en version, mais reste en deça d'APT.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: J'ai testé aussi

            Posté par  (site web personnel) . Évalué à 1.

            Si ta définition de "lent" c'est "plus lent que APT", alors oui. Yum est un peu plus lent que APT pour certaines opérations (même si je ne suis pas un gros utilisateur d'APT). Certaines opérations sont tout à fait équivalentes en rapidité, comme la recherche par exemple (yum search / apt-cache search). Mais là aussi pas de benchs, c'est juste une impression.

            Cela dit, yum a quand même tout un tas de fonctionnalités en plus, donc ça me choque pas. Il y a une vitesse minimum en dessous de laquelle c'est désagréable, mais après si APT met 1 seconde de moins sur une grosse opération, franchement ça me fait ni chaud ni froid.

            • [^] # Re: J'ai testé aussi

              Posté par  . Évalué à 2.

              Quelles sont les fameuses fonctionnalités en plus de Yum ?
              Comme je l'utilise sur RHEL, j'ai eu l'occasion de lire la doc plusieurs fois la doc, et je n'ai pas souvenir de fonctionnalités en plus, plutôt en moins (autoremove, deborphan, pinning, purge, etc).

              Le seul avantage que j'ai trouvé à RPM vs Deb, c'est que plusieurs versions d'un paquet peuvent être installées en même temps. Mais je n'en ai pas l'utilité, les autres fonctions, si.

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

              • [^] # Re: J'ai testé aussi

                Posté par  . Évalué à 1.

                les paquets delta cela n'existe pas pour deb et c'est un manque a mon avis.

                • [^] # Re: J'ai testé aussi

                  Posté par  . Évalué à 2.

                  OK, je croyais qu'il n'y avait que Suse qui proposait un tel système.

                  Après, le problème de Debian est qu'il s'agit à la fois d'une distribution à versions fixes (pour stable) et rolling-release (pour testing et sid). Du coup, je pense qu'utiliser les deltas seraient bien indiqués pour la première, mais ça serait ingérable pour les secondes (trop d'évolution, trop de boulot à prendre en compte les deltas entre toutes les versions d'un paquet).

                  Donc c'est à mon avis inhérent à la distribution. Fedora sort une nouvelle version fixe régulièrement, là c'est jouable.

                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                • [^] # Re: J'ai testé aussi

                  Posté par  (site web personnel) . Évalué à 3.

                  http://debdelta.debian.net/README.txt

              • [^] # Re: J'ai testé aussi

                Posté par  . Évalué à 4.

                Un truc que yum sait faire et pas apt c'est le rollback d'une transaction.
                * autoremove ==> plugin remove-with-leaves
                * deborphan ==> package-cleanup --orphan
                * pinning ==> selon, ce que tu veux faire les plugins protectbase, versionlock ou priorities, tu peux également utiliser les clauses exclude/includepkgs par dépôts.
                * purge ==> rpm renomme automatiquement les fichiers de configuration en xxx.rpmsave, tu peux utiliser la commande rpmconf pour gérer ça.

                Yum plus pauvre que apt en fonctionnalités, c'était vrai il y a 4 ans, ça l'est beaucoup moins aujourd'hui. Yum a l'avantage d'être plus facilement extensible que apt (c'est du python et l'API est plutôt sympa et assez bien documenté).

      • [^] # Re: J'ai testé aussi

        Posté par  . Évalué à 2.

        C'était sans doute PackageKit, en tous cas c'était graphique sous Gnome.

        En fait, l'expérience qui m'a surtout marqué est l'installation sur mon EEE PC 900A, une machine qui me donne quelques soucis parce que sa carte réseau n'est pas prise en charge par les noyaux actuels de Debian et Ubuntu. J'y ai donc mis Fedora 13. Très peu après la sortie, il a fallu plus de 3 heures pour la mettre à jour, et quelques redémarrages plus tard, le système ne boote même plus. J'ai donc remis Ubuntu 9.10, puisque rien de ce que j'ai essayé de plus récent ne marche. Je m'attendais à devoir le laisser quelque temps se mettre à jour, résultat : en moins d'une demi-heure, c'est fini. Je ne cherche absolument pas à troller, il y a vraiment quelque chose qui ne va pas là-dedans. Si c'est une question de miroir, il n'est pas compliqué d'en sélectionner un pas trop mauvais dès le départ, quitte à en laisser le choix à l'utilisateur avec une option par défaut raisonnable, comme le fait Debian.

        • [^] # Re: J'ai testé aussi

          Posté par  (site web personnel) . Évalué à 2.

          Ce que tu décris laisse juste penser qu'il y a beaucoup plus de mises à jour sur Fedora que sur Ubuntu, ce qui est totalement vrai.
          Il est assez courant d'avoir plus de 200Mo de mises à jour quelques semaines (voire jours) après la sortie d'une Fedora.

      • [^] # Re: J'ai testé aussi

        Posté par  . Évalué à 4.

        "P.S.: pour les trolleurs, si vous n'avez pas testé avec un yum très récent, vos tests de rapidité ne valent rien."

        C'est pas l'excuse sortie à chaque sortie de Fedora quand quelqu'un est supris par la lenteur de Yum ?

        BeOS le faisait il y a 20 ans !

        • [^] # Re: J'ai testé aussi

          Posté par  (site web personnel) . Évalué à 2.

          C'est parce que c'est amélioré à chaque sortie.

          Si le yum de la F13 est très lent, y'a un problème, mais si c'est encore une fois quelqu'un qui avait essayé un Fedora 6 et qui avait gravé dans sa mémoire que yum-c'est-lent, il vaut mieux passer à quelque chose de plus constructif.

    • [^] # Re: J'ai testé aussi

      Posté par  . Évalué à 2.

      C'est un problème connu sur cette distribution, ou c'est juste chez moi ?

      Ben, ça ne date pas d'hier cette constatation :
      http://linuxfr.org/comments/648638.html#648638


      J'ai testé chez moi et diversifié les tests (parce que ce qui est proposé dans le lien est certes parlant, mais très limité) et j'en suis toujours arrivé à la même conclusion.


      Il parait qu'il y a des améliorations côté RPM. Mais je n'ai pas pu tester ne disposant plus de rpm chez moi (ni de deb au travail).

      • [^] # Re: J'ai testé aussi

        Posté par  . Évalué à 5.

        En fait, ce n'est pas réellement un problème, ça a juste été conçu différemment. Donc certes j'ai pu constater que la gestion des paquets est plus lente sous Fedora que sous Ubuntu, mais c'est justifié.
        Là où apt conserve en cache une liste des paquets disponibles, que l'on rafraîchit explicitement à l'aide d'un 'update', yum le fait systématiquement; il est possible de demander à yum de se comporter comme apt pour ceux qui en ont vraiment envie, mais j'en vois pas trop l'intérêt.
        Par contre, à l'instar du Windows Installer (qui est aussi connu pour sa lenteur sans égal), yum est transactionnel; cela signifie que chaque opération est consignée et qu'il est possible de revenir en arrière (rollback) comme si de rien était (ou presque). A l'inverse, pour apt, il suffit d'installer le paquet précédent. Au passage, vous pourrez noter que les repos de Fedora ne conservent pas les versions intermédiaires des paquets, ce qui peut poser quelques soucis ...
        Voila, voila, c'est juste que yum et apt c'est pas la même chose, donc normal qu'il y ait des différences (et un plus rapide que l'autre); après, c'est juste un coup de main à prendre. ;)

        P.S. hésitez pas à me contredire, mais tapez pas trop fort :'(
        P.P.S. pour poursuivre le troll, après avoir fait des .deb et des .rpm, je peux dire que ce sont ces derniers qui sont les plus simples, les plus rapide et les plus agréables à faire (donc c'est forcément mieux ... mais ça n'engage que moi)

        • [^] # Re: J'ai testé aussi

          Posté par  . Évalué à 3.

          Tant que nous sommes dans le troll installateurs de paquets je suis assez impressione de celui de pardus qui est tres rapide et utilise, contrairement a dpkg, les delta.

        • [^] # Re: J'ai testé aussi

          Posté par  . Évalué à 3.

          il est possible de demander à yum de se comporter comme apt pour ceux qui en ont vraiment envie, mais j'en vois pas trop l'intérêt.

          Ben gagner du temps, ce n'est déjà pas si mal. Je considère que mon temps est suffisamment précieux pour minimiser autant que possible le temps que je passe à mettre à jour mon système.


          P.S. hésitez pas à me contredire, mais tapez pas trop fort :'( Pourquoi ne pourrait-ont pas échanger des points de vue sans perdre notre calme ?

          • [^] # Re: J'ai testé aussi

            Posté par  . Évalué à 2.

            > Je considère que mon temps est suffisamment précieux pour minimiser autant que possible le temps que je passe à mettre à jour mon système.

            Tu vas aimer presto, tu économises 80% de bande passante (donc autant de temps de téléchargement en moins). Par contre, sur le rafraichissement du cache, autant avec une debian stable, ça peut être superflu, autant avec une fedora, debian sid et dérivées, c'est pas une mauvaise idée.

  • # Après coup

    Posté par  . Évalué à 3.

    Relativement déçu par cette Fedora:

    - mon portable rencontrait une fois sur deux des problèmes pour s'éteindre ou redémarrer
    - obliger de désactiver les instructions de virtualisation avec le driver nouveau pour éviter un bug qui massacrait mon espace disque à coup de mégaoctets de log

    Ce sont les deux seuls soucis que j'ai pu identifier, mais suffisamment important pour agacer à la longue :)

    J'ai migré sous archlinux pour le coup

    • [^] # Re: Après coup

      Posté par  . Évalué à 1.

      Pareil,décu par:le temps de démarrage ,le gestionnaire de paquet (moins intuitif et rapide que chez debian/ubuntu) et l'accés au "mal" (flash,pilote nvidia,..) (il faut installer un depot en plus et c'est pas hyper intuitif)

      Pour pas me prendre tous les fedora fanboy,j'ai aimé "nouveau" et les paquets aussi récents (voir plus) qu'ubuntu.

      • [^] # Re: Après coup

        Posté par  . Évalué à -2.

        j'ai reteste et bien c'est toujours pas ca Fedora, c'est une version test de RH et cela ce sent en particulier j'ai pas aime de ne pas avoir le touchpad qui fonctionne par defaut c'est pas tres pratique surtout lorsque tu n'as pas de souris externe sous la main du coup elle a fait aller retour sur le disque... Par contre j'ai trouve beaucoup plus classe le theme par defaut de kdm mais c'est tout ce que je peux dire et je trouve cela un peu dommage en 2010.

        • [^] # "cacher ce sein que je ne saurait voir"

          Posté par  . Évalué à 0.

          c'est juste un retour d'experience d'il y a moins de 24h. Le touchpad fonctionne en arrivant sur kdm et se desactive lors de la connection sous kde. Alors ok peut etre que ca fonctionne sous gnome mais je veux utiliser kde, il doit bien y avoir un fichier a la noix dans .kde pour changer cela mais bon j'ai eu la flemme de chercher et le probleme est pas recent puisque il y a un an j'avais deja rempli un bug report sur le bugzilla de fedora donc maintenant vous pouvez continuer a moinsser le message au dessus et faire comme les devs de Fedora vous voiler la face cela ne fera pas evoluer les choses dans le bon sens...

      • [^] # Re: Après coup

        Posté par  . Évalué à 1.

        > (il faut installer un depot en plus et c'est pas hyper intuitif)

        Quelle partie n'était pas intuitif ?

        J'avoue que j'aime beaucoup pouvoir cliquer sur un lien, cliquer "OK", donner le mot de passe root de la machine et me retrouver avec un nouveau dépôt de configuré.

        • [^] # Re: Après coup

          Posté par  . Évalué à 2.

          J'imagine qu'il voulait parler du fait de trouver le nouveau dépôt (rpmfusion ?) plutôt que de la procédure d'installation.

          En tout cas, le fait de pouvoir installer un nouveau dépôt dans le navigateur fait partie des petits fignolages qui me plaisent vraiment dans cette distrib. Le Network Login via LDAP aussi.

          Je lui pardonne volontiers la lenteur de démarrage et du gestionnaire de paquets. C'est du Python après tout.

          /me qui aime sa Fedora 13 fraîchement installée et fonctionnelle sur son MBP neuf.

  • # ca fait tout bizarre

    Posté par  . Évalué à 2.

    un troll Fedora sans GEneralZod.... :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.