Journal Yum vs Apt

Posté par  (site web personnel) .
Étiquettes :
4
29
août
2009
http://www.linux-mag.com/cache/7382/1.html

Juste un petit comparatif Yum vs APT pour se conforter dans l'idée que Debian, ça devrait être la base de toutes les distribution GNU/Linux ;)

Enfin, pour contre balancer ce troll, je dois dire que j'ai utilisé zypper sous openSUSE et ce dernier est vraiment pas mal, quelques rares problèmes de dépendances mais un temps d'exécution très correct.

Par contre, j'ai voulu tester oVirt sous Fedora11 et j'ai vraiment détester Yum, j'avais des erreurs de dépendances avec les repositories officiels et les temps d'exécution était vraiment infernaux! Bref, amis fedoristes (Très bonne distrib, malheureusement pas autant neuneu proof que Ubuntu mais bien mieux léchées à mon avis), comment faites vous pour vivre avec Yum?

  • # yum install apt

    Posté par  . Évalué à 7.

    La première commande que j'ai exécutée sur ma dernière fedora (en 2004).

    J'ai l'impression que ça n'a pas significativement changé depuis.

  • # Comparaison

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

    C'est bien de voir un article qui fait cette comparaison et c'est ahurissant de constater une telle différence de rapidité.
    Je ne prend que le premier test (un refresh de la base des packages) : On s'attend à ce que Fedora gagne car les dépots sont moins nombreux et moins fournis...et Ubuntu l'éclate dans les grande largeurs.
    Bien entendu je ne pense pas que ce soit lié intrinsèquement au format RPM...c'est juste que Yum à l'air de suxer pas mal.

    • [^] # Re: Comparaison

      Posté par  . Évalué à 2.

      c'est juste que Yum à l'air de suxer pas mal.

      Mouaif...
      On est vraiment dans un concours à celui qui a la plus grosse...
      Toutes les manips prennent moins de 30 secondes. Yum n'est pas utilisé toutes les heures ni tous les jours et encore moins que ça.

      Pour info, yum est écrit en python et apt en C. Normal que Yum soit plus lent. Apt serait-il aussi rapide que Yum s'il était écrit en python ? Pas sûr. Donc yum sucks ou c'est python ?

      Les plus gros consommateurs de Yum sont les développeurs/testeurs de Fedora et la vitesse de yum est satisfaisante.

      Le jour où Windows passe à apt, Windows va devenir un OS formidable.

      • [^] # Re: Comparaison

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

        Je pense que le python, même s'il a facilité (grandement) la tâche d'écriture de yum, plombe méchament les performances quand il s'agit de résoudre les problèmes de dépendances, ou même simplement de mise à jour de la BDD locale.

        Honnêtement, 30 secondes pour installer ntpd ou dhcpd (sans compilation), je trouve cela ahurissant. Yum, même pour des paquets standalone (comme dans le test), il passe 30 secondes à mouliner je ne sais quoi !
        Apt mouline aussi, mais même sur mon pauvre NAS à 133MHz sur du ARM, ca prend moins de 5 secondes.

        • [^] # deb lent aussi

          Posté par  . Évalué à 2.

          Il me semble pourtant que sur un PC 200mhz avec jesaispluscombien de RAM, apt était lent pour faire la moindre opération (je n'ai pas essayé yum ou autre), et apt relit sa base plusieurs fois par installation de paquets, ce qui transformait une quelconque installation o mise à jour en calvaire.

        • [^] # Re: Comparaison

          Posté par  . Évalué à -5.

          Bof...

          En passant, yum est utilisé à l'installation de Fedora.
          Il y a-t-il des tests qui disent que l'installation est abominablement lente ?

          Honnêtement, 30 secondes pour installer ntpd ou dhcpd (sans compilation)

          Où t'as vu ça ?
          Peut-être que lors du test ils sont sur des mirroirs lents. Ça arrive.

          Bref, en gros je m'en fous.
          Le pire comme gestionnaire de paquet, le plus lent et de loin, est celui de Windows. Ben les utilisateurs de Windows n'en font pas un fromage.

          Ici c'est un journal uniquement pour casser Yum et dire que Apt roxe. Sur quoi ? Car yum est plus lent. Est-ce vraiment un gène ? Pas vraiment. Mais si Yum est 10 secondes plus lent, ça devient toute une histoire. Comme si Yum était utilisé 10 fois par jours. C'est une blague.

          C'est comme les problèmes de dépendance où on veut nous faire croire qu'il n'y a aucun problème avec Debian/Ubuntu mais plein avec Fedora :
          http://www.googlefight.com/index.php?lang=en_GB&word1=&q(...)

          Très bien, Yum est plus lent, profitez en bien dans votre propagande.

          • [^] # Re: Comparaison

            Posté par  . Évalué à 9.

            Bref, en gros je m'en fous.
            Moi pas. Lorsque j'ai plein plusieurs logiciels à installer sur plusieurs serveurs, parfois c'est vraiment long. Même pour une recherche, je le trouve lent.
            Le pire, c'est que ça ne serait pas grave s'il n'y avait pas la comparaison avec APT...

            Après, je n'utilise que des RHEL/CentOS, qui emploient la version de Yum issue de Fedora 6 si je me souviens bien. J'imagine que depuis, Fedora a dû bien le faire évoluer et que sa version actuelle doit être comparable à APT, il faudrait que je prenne un peu de temps pour essayer une Fedora.

            Le pire comme gestionnaire de paquet, le plus lent et de loin, est celui de Windows. Ben les utilisateurs de Windows n'en font pas un fromage.
            Forcément, il ne sont même pas au courant qu'il existe.

            Comme si Yum était utilisé 10 fois par jours. C'est une blague.
            Non, ce n'est pas une blague. Il m'arrive de faire des maquettes, de tester des logiciels ou des choix d'architecture, et alors je teste naturellement ce qu'il y a dans les dépôts, donc j'utilise Yum intensivement dans ces moments-là.

            C'est comme les problèmes de dépendance où on veut nous faire croire qu'il n'y a aucun problème avec Debian/Ubuntu mais plein avec Fedora :
            Là, je dirais que pour Ubuntu c'est plus un problème d'utilisateurs : tu as plein de débutants qui installent les derniers logiciels à la mode et qui ajoutent plein de dépôts (non sécurisés, tant qu'à faire), et là forcément, tu te retrouves avec des dépendances foireuses. C'est pareil avec Fedora : trop de dépôts et tu as un bordel sans nom dans les dépendances (rien que RPMForge et EPEL causent parfois des collisions).

            Pour Debian, c'est plutôt dû aux distributions de tests que sont Testing et Unstable. D'un côté les dev peuvent se permettre un certain laxisme (relatif) sur Testing/Unstable, de l'autre ils sont extrêmement rigoureux sur la stable. Et c'est logique, c'est le rôle de cette séparation : les tests permettent d'ajouter de nouvelles choses et de les corriger derrière.
            Pour la stable par contre, je n'ai connaissance d'aucune dépendance cassée.

            Très bien, Yum est plus lent, profitez en bien dans votre propagande.
            Reconnais que c'est tout de même un désavantage pour Red Hat/Fedora face à Debian/Ubuntu/Whatever : sur une batterie de serveurs, faire une mise à jour ou une bête installation demande plus de temps. C'est un fait, et ça peut jouer.

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

            • [^] # Re: Comparaison

              Posté par  . Évalué à 4.

              > sur une batterie de serveurs, faire une mise à jour ou une bête installation demande plus de temps. C'est un fait, et ça peut jouer.

              Ça prend 10 secondes de plus... Me dit pas que tu utilises yum itérativement à la main sur chaque machine sur une batterie de serveur.

              Yum pourrait être plus rapide c'est un fait. Après est ce vraiment un problème et un critère de choix ou seulement du confort ? Note aussi que c'est bien plus rapide dans les dernières Fedora.

              • [^] # Re: Comparaison

                Posté par  . Évalué à 5.

                Me dit pas que tu utilises yum itérativement à la main sur chaque machine sur une batterie de serveur.
                Ça m'arrive, pas forcément sur une batterie, mais sur quelques serveurs à la suite (et pas toujours la même commande). Et j'aime bien être sûr que ma commande a bien abouti (normal, quoi).

                Je considère que ça fait partie du confort de l'administrateur, s'il veut bien faire son boulot. Si l'on devait se poser la question de la pertinence à chaque fonctionnalité de ce genre, on en serait encore au KSH. Or même sur HP-UX, la première chose que j'installe est Bash.

                Dans le même ordre d'idée, actuellement, toutes les distributions travaillent pour accélérer le démarrage du système. Pourtant, je ne le démarre qu'une fois le matin et je l'arrête le soir.
                Si je suis la façon de penser de certains, pourquoi s'entêter à vouloir améliorer cette partie du système, puisqu'on ne redémarre pas toutes les dix secondes ?

                Note aussi que c'est bien plus rapide dans les dernières Fedora.
                Oui oui, j'ai dit que je le suppose, puisque je ne connais que RHEL/CentOS.
                D'ailleurs, c'est la preuve que les dév Fedora prennent bien la chose comme un problème, et que ce n'est pas un truc dont tout le monde se moque, comme le prétend IzNotGood.

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

              • [^] # Re: Comparaison

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

                >>> Note aussi que c'est bien plus rapide dans les dernières Fedora.

                Ouais enfin tu a noté que le test qui fait l'objet du journal , celui ou Fedora/Yum se fait littéralement tronçonner par Ubuntu/Apt, est effectué en prenant une Fedora 11 ?
                Ce que tu nous dit c'est que Yum était encore pire avant ?

                • [^] # Re: Comparaison

                  Posté par  . Évalué à 2.

                  Oui avant c'était lent au point d'être pénalisant et pénible. Maintenant c'est juste pas véloce.

              • [^] # Re: Comparaison

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

                Me dit pas que tu utilises yum itérativement à la main sur chaque machine sur une batterie de serveur.

                Oui, c'est une chose que je fais toujours manuellement. Avec cssh ça reste relativement simple à faire 10-20 fois la même commande et avoir un contrôle humain de ton opération. Après le jour ou j'ai mille systèmes à mettre à jour, j'envisagerais un script ... Mais pour le moment je le fais à la main.

                "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

          • [^] # Re: Comparaison

            Posté par  . Évalué à 2.

            En passant, yum est utilisé à l'installation de Fedora.
            Il y a-t-il des tests qui disent que l'installation est abominablement lente ?

            Euh pas de tests officiels mais il y a deux mois j'ai tente differentes distributions pour savoir vers quoi je passerai apres ubuntu et bien j'ai trouve l'installation de fedora comme la plus lente de toutes. Est-ce que cela vient de yum je ne sais pas mais c'est lent. Apres qu'il reste plein de bugs (plus qu'avec ubuntu) dont certains 100% specifiques a Fedora c'est un autre probleme.

            Par rapport au fait que python soit le responsable de la lenteur j'ai un doute dessus vu que le systeme utilise par pardus est lui aussi en python et tres rapide. Pour le moment je n'ai pas eu le moindre probleme de dependance avec.

            Fedora comme tu le dis toi meme c'est du bleeding edge et cela se sent. Ce n'est pas une distribution a mettre dans toutes les mains.

          • [^] # Re: Comparaison

            Posté par  . Évalué à 2.

            Bref, en gros je m'en fous.

            Ahah le fanboy, on dirait un utilisateur Mac...

            Est-ce vraiment un gène ? Pas vraiment
            Bien sur. Tout les utilisateurs testant Fedora après Debian crachent dessus à cause de yum. Y'a même un site web qui compare les deux dis donc. Mais c'est pas grave. C'est pas comme si il était important d'attirer de nouveaux testeurs.

      • [^] # Re: Comparaison

        Posté par  . Évalué à 5.

        J'ai installé une fedora sur ma ps3 (c'est une distrib qui avait l'air le plus facile a installer sur la ps3). Et bien yum est à la limite inutilisable. Les opérations ne prennent pas 30s mais plutot 4 à 5 minutes, et l'installation des paquest est affreusement lente.

        Donc je pense que je vais tenter une autre distrib :)

        Pour info la ps3 a 256Mo de RAM et je pense que le souci vient de ça.

        • [^] # Re: Comparaison

          Posté par  . Évalué à 2.

          Pour info la ps3 a 256Mo de RAM et je pense que le souci vient de ça.

          Pour la mémoire Yum (en fait rpm) était un peu glouton.
          Ça a été corrigé dans F10 ou F11 (j'ai oublié). Quelle version de Fedora as-tu installé sur PS3 ?

      • [^] # Re: Comparaison

        Posté par  . Évalué à 4.

        > Pour info, yum est écrit en python et apt en C. Normal que Yum soit plus lent.

        La prochaine comparaison devrait donc se faire avec pisi (Pardus, écrit en python) et yum.

        The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein

    • [^] # Re: Comparaison

      Posté par  . Évalué à -3.

      Allez voilà à quoi cela me fait penser ce genre de débat:

      [http://www.googlefight.com/index.php?lang=en_GB&word1=ub(...)]

      J'utilise autant Ubuntu que Centos 4/5.
      Les deux me paraissent aussi lent.

      Ce que j'aime pas avec apt, c'est comme cité dans un post: apt-get, apt-cache, apt-faitmoilecafe etc..

      C'est pénible.

      • [^] # Re: Comparaison

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

        Ce que j'aime pas avec apt, c'est comme cité dans un post: apt-get, apt-cache, apt-faitmoilecafe etc..
        C'est pénible.

        En même temps c'est ton problème si tu utilise encore des outils obsolètes. Le gestionnaire de paquets officiel est aptitude et de ce que je comprend, en plus d'être celui conseillé par la distrib, corespondrait mieux à ce que tu aime.

        Mais les gens n'aiment pas lire les release notes...

        • [^] # Re: Comparaison

          Posté par  . Évalué à 3.

          En effet, aptitude est beaucoup plus pratique pour les commandes. Par contre, il est aussi beaucoup plus lent...

          • [^] # Re: Comparaison

            Posté par  . Évalué à 2.

            Effectivement. Pour palier ce problème sans utiliser 10000 commandes, je me limite à apt-cache pour rechercher des infos sur les paquets, aptitude pour installer / mettre à jour. Et éventuellement dpkg pour les infos sur les paquets installés sur ma machine. C'est pas la mort, trois commandes ...

          • [^] # Re: Comparaison

            Posté par  . Évalué à 1.

            Il est plus lent, et c'est aussi un gouffre question RAM. Mais pour l'instant ça reste pratique. (oui, j'utilise encore apt-get sur des vieux systèmes)

  • # In life, there's only windows and apples..

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

    Debian, ça devrait être la base de toutes les distribution GNU/Linux ;)

    Et pacman(-g2) ?
    Et emerge ?
    Et les ports/pkg* ? (bon, ok, pas du GNU/Linux, mais c'est tout bon quand-meme)

    Desole mais meme si rpm "sapu" (je cite, jamais eu a tester), y'a d'autres gestionnaires de paquets, et pour certains qui sont beaucoup moins excecrables a l'execution qu'apt (je pense surtout a pacman).

    • [^] # Re: In life, there's only windows and apples..

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

      apt "exécrable" ? et pourquoi donc ?

    • [^] # Re: In life, there's only windows and apples..

      Posté par  . Évalué à 3.

      Même si j'utilise pacman tout les jours, je le trouve relativement lent pour la recherche de dépendance. Mes souvenirs avec apt étaient meilleurs.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: In life, there's only windows and apples..

        Posté par  . Évalué à 3.

        apt est peut-être rapide, mais je ne sais pas à quel niveau il est au niveau des features.
        C'est facile de dire que "A plus rapide que B", mais il faudrait aussi vérifier ce qu'il en est dessous.

        J'ai l'impression que pour debian et ubuntu, c'est effectivement rapide, mais qu'il y a derrière un temps énorme passé à faire les paquets, ce que d'autres distros n'ont pas forcément les ressources pour faire (et ont alors développé un gestionnaire de paquets plus complet pour faire le boulot à la place de personnes réelles, ce qui est un peu plus lent).

        Dans le cadre d'un projet de plus petite envergure, je pense qu'avoir un gestionnaire de paquet permettant de faciliter la tâche aux créateurs de paquets et de réduire le temps qu'ils passent à les créer vaut bien tout le temps qui peut être perdu lors du calcul des dépendances.

        • [^] # Re: In life, there's only windows and apples..

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

          Je ne pense pas que la création d'un paquet debian soit si complexe que cela... Avec cdbs, les fichiers rules se résume le plus souvent à 3 lignes.

          Je pense que ce qui est le plus complexe sous Debian est le découpage très fin des paquets...

          • [^] # Re: In life, there's only windows and apples..

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

            La création d'un paquet debian ? Pinaise ! C'est trop facile !

            Tu créés la structure finale + un répertoire debian contenant un fichier control (fichier texte indiquant les dépendances, la description du paquet, etc). Ensuite un dpkg-deb --build <fichier_deb> et c'est fini. Y'a rien de plus facile ! (même avec les scripts post/pre install/remove).

            J'ai jamais fait de RPM, mais plus facile, ça me paraît pas difficile (pour les paquets "basiques" tout au moins)

            #tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo

            • [^] # Re: In life, there's only windows and apples..

              Posté par  (Mastodon) . Évalué à 2.

              Checkinstall sous slackware, ça marche tout seul, ya rien à faire de compliqué :
              # wget truc-src.tar.bz2
              # tar xf truc-src.tar.bz2
              # cd truc
              # make
              # checkinstall -S --newslack
              Tu réponds à deux trois questions (genre mettre un numéro de version de paquet, et une description du paquet), et hop !

              Et pour l'installer ya même pas besoin d'avoir une slackware ni les pkgtools :
              cd /
              tar xf mon_paquet.tgz
              cd install
              ./install.sh
              cd ..
              rm -r install


              Yth.

            • [^] # Re: In life, there's only windows and apples..

              Posté par  . Évalué à 2.

              tu voulais pas dire "mais plus facile ca me parait difficile" plutôt ?

              Ps : pour avoir faits des paquets debian, c'est comme tout c'est s'y mettre et se documenter qui est difficile ennuyant.

        • [^] # Re: In life, there's only windows and apples..

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

          J'ai l'impression que pour debian et ubuntu, c'est effectivement rapide, mais qu'il y a derrière un temps énorme passé à faire les paquets, ce que d'autres distros n'ont pas forcément les ressources pour faire (et ont alors développé un gestionnaire de paquets plus complet pour faire le boulot à la place de personnes réelles, ce qui est un peu plus lent).

          A avoir dû apprendre à faire les deux pour mon projet sans aucune base pour l'un ou l'autre, je pense pouvoir témoigner : c'est la même merde pour les deux. La différence est surtout que l'un me pourri mon source avec un répertoire à placer absolument à la racine du package sinon ça ne marche pas, et l'autre un simple fichier que je peux placer ou je veux, pas grand chose à voir avec la vitesse.

          faciliter la tâche aux créateurs de paquets et de réduire le temps qu'ils passent à les créer vaut bien tout le temps qui peut être perdu lors du calcul des dépendances.

          D'une, la création du paquet est faite une fois et l'install des milliers de fois, alors porter le temps sur l'install me parait débile, et de deux je ne pense pas que la vitesse d'exécution dépende du format de paquet, les deux formats se valant en fonctionnalités, mais du programme. On pourrait donc bien avoir une facilité de création et un vitesse du gestionnaire de paquet vu que c'est deux choses séparées, reste à le vouloir (que quelqu'un investisse du temps dessus)...

      • [^] # Re: In life, there's only windows and apples..

        Posté par  . Évalué à 5.

        Le pacman de Archlinux ? si c'est celui-là pour le trouver lent il faut vraiment être extrêmement pressé, il est instantané pour la recherche des dépendance.

        • [^] # Re: In life, there's only windows and apples..

          Posté par  . Évalué à 1.

          oui, et une fois le téléchargement effectué, l'installation vraiment très rapide. Impossible de revenir à apt une fois avoir goûté à pacman. Et pour revenir au titre de l'article "Having Yum for Breakfast", je préfère avoir "yaourt pour le petit déjeuner" (yaourt est une interface en mode texte à pacman)

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

          • [^] # Re: In life, there's only windows and apples..

            Posté par  . Évalué à 3.

            Yaourt moi je l'ai utilisé un temps mais je l'ai viré depuis..
            Je le trouvais bien lent par rapport à pacman seul, et son intérêt est limité pour moi: quand je télécharge un paquet sur AUR habituellement je regarde le pkgbuild, juste pour vérifier, donc ça sert à rien d'automatiser ça.

            La seule chose qui manque à pacman c'est la couleur, mais pacman-color arrange ça :)

    • [^] # Re: In life, there's only windows and apples..

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

      Il reste encore encore un truc de bon chez Debian, c'est une bonne nouvelle.

    • [^] # Re: In life, there's only windows and apples..

      Posté par  . Évalué à 4.

      emerge ? le truc qui va t'installer une version differente des softs tous les jours ?
      ca va être simpa pour faire une stable...

    • [^] # Re: In life, there's only windows and apples..

      Posté par  . Évalué à 2.

      Dans mes souvenirs, Portage ( emerge n'est que la commande ), qui est lui aussi écrit en Python, était particulièrement lent. Quand j'ai arrêté d'utiliser Gentoo, il y avait des discussions interminables sur la mailing-list pour savoir si il fallait ou non le remplacer et si oui, par quoi.

      Personnellement, j'utilisais Paludis qui était nettement plus rapide. Pkgcore avait aussi ses partisans.

      • [^] # Re: In life, there's only windows and apples..

        Posté par  . Évalué à 1.

        Moi aussi j'ai utilisé Paludis quand j'étais sous Gentoo…
        Sinon Paludis est écris en C++ si je ne me trompe pas et PkgCore est une réécriture de Portage from scratch de Portage en Python (pareil, si je ne me trompe pas)

  • # Re:

    Posté par  . Évalué à 6.

    Juste un petit comparatif Yum vs APT pour se conforter dans l'idée que Debian, ça devrait être la base de toutes les distribution GNU/Linux ;)

    C'est-à-dire ?
    Il existait apt pour Fedora. Mais comme presque personne est motivé pour maintenir le truc, il a disparu. Bref, pas si indispensable que ça.

  • # ce que je reproche à apt...

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

    Ce que j'aimais bien dans yum (cela fait plusieurs années que je n'utilise plus que debian et ubuntu) c'est qu'au moins il permettait de tout faire: rafraichir la liste des packages dispos, chercher un package installé ou non, installé un package local, etc. alors que pour manipuler mes .deb il me faut jongler avec apt-get, apt-cache, apt-cdrom, apt-key, apt-src, apt-show-version, dpkg, etc.

    Sinon, niveau vitesse, la lenteur de yum ne date pas d'aujourd'hui, même apt pour rpm était plus rapide, même si cela s'est bien amélioré (les premières versions étaient vraiment encore pire!)

    • [^] # Re: ce que je reproche à apt...

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

      J'utilise le minimum de apt (très peu de packets, tjr les même, et les updates > c'est un serveur), donc je reste sur apt-*

      Mais de mémoire, aptitude regroupe tout ça (search, install, remove...).
      Et (de mémoire aussi), aptitude sait gérer autre chose que apt (puisque c'est un front).... des expériences avec aptitude ?

      • [^] # Re: ce que je reproche à apt...

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

        >donc je reste sur apt-*

        En même temps, aptitude, aujourd'hui, j'aimerai bien savoir ce qu'il fait que apt ne fait pas.

        • [^] # Re: ce que je reproche à apt...

          Posté par  . Évalué à 2.

          En vrac :
          * apt-cache policy
          * apt-show-versions
          * apt-file
          * apt-mark

          Ce sont des commandes dont je me sers souvent, or aptitude n'en a pas d'équivalent.

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

    • [^] # Re: ce que je reproche à apt...

      Posté par  . Évalué à 3.

      Ce qui manque à apt, c'est une fichûe sortie couleur! c'est assez illisible par moment!

      Mais bon, après 5 années d'emerge, 6 mois de pacman, quelques tentatives de Yum et le truc de Suse, APT ressort vriament du lot!

      Juste un petit comparatif Yum vs APT pour se conforter dans l'idée que Debian, ça devrait être la base de toutes les distribution GNU/Linux ;)


      Debian devrait être la seule distro linux en fait! ... aller avec Slackware! :)

  • # contagion

    Posté par  . Évalué à -10.

    je crois que la grippe du cochon s'attaque aux neurones. Qu'est ce que c'est que cette mode des journaux "debian c'est bien" depuis quelques jours ? Ils payent chez debian pour faire le buzz ?

    • [^] # Re: contagion

      Posté par  . Évalué à 10.

      Non, c'est juste que la vérité est enfin rétablie.

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

    • [^] # Re: contagion

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

      Qu'est ce que c'est que cette mode des journaux "debian c'est bien" depuis quelques jours ?

      Un message qui date de novembre 2005 et qui explique la même chose que dans ce journal, ça fait partie de la « mode des journaux "debian c'est bien" depuis quelques jours » ou pas ?
      https://linuxfr.org//comments/648638.html#648638


      La différence entre l'utilisation de yum/up2date/rpm/etc. et dpkg/apt/aptitude, se sent instantanément quand on utilise les deux. Pas besoin de faire d'études très poussées.


      Quand tu dois attendre plusieurs dizaines de secondes un résultat d'une commande et que pour fignoler ton système tu en fait plusieurs dizaines à la suite, ça parait très rapidement très long (plusieurs minutes de perdues).

      Quand après tu reviens sous Debian et que la plupart des commandes s'exécutent en moins d'une seconde, la différence de confort est immédiatement appréciable.

    • [^] # Re: contagion

      Posté par  . Évalué à 4.

      J'attend mon chèque, mais dès que je le reçois je fais un autre journal, promis.

  • # yum assez lent

    Posté par  . Évalué à 5.

    Je ne connais pas bien yum (les options possibles) mais il est vrai, qu'étant habitué à apt-get, j'ai noté une grosse différence de timing lors des mises à jour entre des serveurs sous rhel 5 et debian lenny. (je ne parle évidemment pas du temps de téléchargement des parquets)
    Pire encore, la completion est inutilisable ou presque tellement elle est longue sous rhel 5.

  • # Et concernant les fonctions ?

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

    Est-ce qu'Apt propose des fonctions tels que Presto (mise à jour simplement de la partie du paquet changée) ? Voir https://fedorahosted.org/presto/
    ou
    yum-fastestmirror qui permet de sélectionner automatiquement les miroirs les plus rapides.
    ?
    Voir cette page pour toutes les extensions de YUM : http://doc.fedora-fr.org/wiki/YUM_:_Les_extensions

    • [^] # Re: Et concernant les fonctions ?

      Posté par  . Évalué à 5.

      Pour Presto, pas encore, mais il me semble que l'idée a déjà commencé à faire son chemin. Par contre bien sûr, pour la liste des paquets dans les dépots, oui, c'est fait, on ne télécharge que le différentiel.

      Pour la sélection du miroir, ça existe déjà, et depuis trèèèès longtemps:
      netselect-apt

    • [^] # Re: Et concernant les fonctions ?

      Posté par  . Évalué à 1.

      Est-ce que dpkg supporte enfin les triggers ?
      Peut-on signer un paquet avec dpkg et pas tout un dépôt ?
      Il y a-t-il le support multi-arch ?
      Peut-on faire un rollback ?
      Etc.

      Qu'importe, c'est le plus rapide dirons certains.

      • [^] # Re: Et concernant les fonctions ?

        Posté par  . Évalué à 2.

        c'est quoi ce que tu appelles multi-arch? Mon experience m'a montre que le meilleur support multi-arch s'etait de loin debian/ubuntu. J'ai eu plein de probleme en rajoutant wine (un application typiquement x86 sur un systeme x64 avec fedora. Cela m'a pete des librairies j'ai pa strop compris pourquoi ni comment.)

        • [^] # Re: Et concernant les fonctions ?

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

          Multiarch c'est que tu peux installer des bibliothèques issues d'un repositery x86 sur un x86_64. Et sur ubuntu, c'est un vrai cauchemar.
          Si on veut compiler un truc en x86 qui utilise autre chose que la glibc, c'est simple, y a aucun moyen avec juste apt (toujours sur ubuntu.), faut se taper des liens symboliques à faire à la main, et pour des libs pas trop courantes, il faut carrément les recompiler soit même, même si elles sont packagées en x86 !
          Alors que sur mandriva (je suppose pour fedora aussi), il suffit d'installer les libXXXpour avoir la lib en 32bits, sinon lib64XXX en 64bits.

          • [^] # Re: Et concernant les fonctions ?

            Posté par  . Évalué à 0.

            euh je suis sous ubuntu la et je n'ai aucun probleme que tu decris maintenant il faut dire aussi que les lib32 sont dans /usr/lib32 et les x64 dans /usr/lib ce qui me semble assez logique et moins "bordelique" que un melange dans le seul /usr/lib. Enfin une question de gout.

            • [^] # Re: Et concernant les fonctions ?

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

              Relit mieux.
              La question n'est pas l'emplacement, et évidement elles sont pas placées au même endroit, sinon bonjour le bordel, les libs 64bits sont dans /usr/lib64 et les 32bits dans /usr/lib (pour pouvoir réutiliser les paquets 32bits pas trop le choix de toutes façons)

              • [^] # Re: Et concernant les fonctions ?

                Posté par  . Évalué à 1.

                bon ben ubuntu fait l'inverse il met les x64 dans /usr/lib mais elles ne sont pas renommes en plus d'etre mise dans un repertoire specifique. En tout cas "chez moi ca marche", je n'ai aucun probleme avec wine, spotify et skype (pourtant tous des sources a ennuis).
                Il existe aussi un petit script qui aide bien pour regler pas mal de problemes du aux mix de dependances x32/x64 un petit lien que je te conseille:

                http://ubuntuforums.org/showthread.php?t=474790

                • [^] # Re: Et concernant les fonctions ?

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

                  On parlait de apt.
                  Le lien que tu donnes, montre implicitement que apt ne peut pas gérer des repositerys x86 sur x86_64. Et la solution proposée est quand même un hack immonde. Enfin celle déjà utilisée par ubuntu (un gros paquet où on fourre un peu tout ce qui pourrait éventuellement servir), l'est encore plus.
                  Et non, wine, spotify et skype ne sont pas des sources d'ennuis, car déjà packagés, vu que tous les windowsiens qui migrent sous linux voudront l'utiliser, et comme c'est le fer de lance d'ubuntu, bah voilà.
                  Par contre essaye de compiler une appli 32 bits (au hasard wine.), sans toucher à la main à /usr/lib32 (ce qui est possible sous fedora ou mandriva.).

                  • [^] # Re: Et concernant les fonctions ?

                    Posté par  . Évalué à 1.

                    c'est vrai tu as raison apt ne gere pas le multi-arch je melangeais dpkg et apt. Par contre dans mes tests que ce soit sous fedora ou sous mandriva le multiarch fonctionne moins bien. J'ai besoin de skype pour discuter avec ma femme et mes enfants qui sont au loin et je n'ai jamais reussi a faire fonctionner cela comme il faut sous fedora ou mandriva justement a cause des problemes de lib x32. Je sais que c'est un logiciel ferme etc mais bon je soupconne qu'aujourd'hui les seuls applis pour lequel tu as besoin de cela sont majoritairement des applis closed source. Ce n'est pas le seul cas car une des applis que j'utilise dans mon metier n'a qu'une version x32 pour le moment meme si les sources sont disponibles. Enfin sont installation avec le petit script indique au dessus c'est fait sans probleme.

                    • [^] # Re: Et concernant les fonctions ?

                      Posté par  . Évalué à 2.

                      Ce n'est pas qu'il fonctionne moins bien, c'est que tu n'as semble il pas compris comment l'utiliser. Sous Mandriva (et Fedora aussi ?), n'importe quelle lib x86 peut s'installer sur x86_64, à la difference d'Ubuntu ou ce n'est possible que pour certaines (celles qu'ils ont éstimé les plus importantes). Il suffit d'ajouter le media x86 et d'installer les paquets libXXX (plutot que lib64XXX en x86_64).

                  • [^] # Re: Et concernant les fonctions ?

                    Posté par  . Évalué à 2.

                    Compiler wine sans « toucher à la main à /usr/lib32 » n'a jamais été un problème avec ma Debian-amd64. ;-)

                    Le multi-arch est en train de se mettre en place doucement dans Debian (je crois que c'est un des release goals de la prochaine version stable). Je crois qu'il y a actuellement du travail qui est fait sur eglibc dans experimental.

                    Pour l'instant, effectivement, le support des applications 32 bits (sous x86_64) se fait avec ia32-libs et ia32-libs-gtk (plus quelques autres paquets). Il y a quelques temps, l'ancien mainteneur de ces bibliothèques avait introduit ia32-apt-get qui permettait d'installer n'importe quelle bibliothèque 32 bits (n'importe quel paquet en fait) en transformant à la volée les libfoo en ia32-libfoo.

                    Le problème c'est que dans les premières versions de ia32-apt-get cela mettait un peu le boxon. Le mainteneur en question s'est pris une petite volée de bois vert (un peu injustifiée à mon avis) sur debian-devel et on est revenu au paquet monolithique.

                    Tout ça pour dire que la multi-arch « propre » semble sur le point d'arriver dans Debian.

      • [^] # Re: Et concernant les fonctions ?

        Posté par  . Évalué à 3.

        Essaye de faire des commentaires avec un ton moins aigri, ça marchera mieux. Parce que là tes arguments sont bons en plus ! (bon, les triggers je ne sais pas trop ce que c'est mais il y en a sous debian pour l'ajout des entrées dans les menus, pour les MàJ de l'initrd, etc ...)

  • # Merci !

    Posté par  . Évalué à 10.

    Merci d'enfoncer une porte ouverte, ça fait pas de mal de temps en temps ;)

    Pour être un utilisateur de fedora, malgré ses nombreux défauts, je confirme que yum est lent.

    Certains vizirs qui voudraient être kalif seraient évidemment prêts à défendre cet indéfendable caractéristique, mais j'insiste sur un point : une des choses qui font la particularité d'une distribution _EST_ son gestionnaire de paquets. Et il est pris en compte dans l'avis que l'on se fait, l'opinion, le sentiment que l'on a quand on l'utilise.

    Je trouve qu'en plus de nuire fortement au confort de l'utilisateur (désolé, mais attendre 30 secondes pour installer un paquet de 1Mo, en 2009, avec le matériel dont on dispose, c'est une réelle nuisance), il nuit à la réputation d'une distribution.

    Alors oui, ces X secondes d'attente, ça me gêne :
    - parce que je n'aime pas attendre
    - parce que les 60Mo/s de bande passante sur mon disque et mes 3Mo/s de bande passante internet ne sont pas exploitées
    - parce que des concurrents autrement plus anciens (sous entendu développé avec pas toutes les technos actuelles) sont autrement plus performants

    • [^] # Re: Merci !

      Posté par  . Évalué à 5.

      Exactement, fedora est une excellente distribution notamment car elle est toujours à la pointe de l'innovation, mais le gestionnaire de paquet est pour moi l'énorme point noir qui ma fait chercher ailleurs.

      En plus d'être super lent YUM est le seul gestionnaire de paquet qui c'est cassé après à peine quelque jours d'utilisation, alors que je ne l'ai utiliser que pour des opération de base : installation à partir des dépot et mise à jour. Je n'avait pourtant qu'un dépôt externe pour installer uniquement les pilote nvidia (depot rpm fusion il me semble). Et d'après les forum impossible à réparer si je n'avais pas fait une sauvegarde de la BDD de YUM. Heureusement je que je comptait déjà changer de distrib.

      Résultat je suis passer à Archlinux depuis 1.5 ans, que du bonheur, super rapide même plus que apt, rolling release :) . Jamais une de problème de dépendance, alors que opensuse par exemple sur quelques mois j'en est eu à la pelle.

      • [^] # Re: Merci !

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

        Je sais pas si zypper est dispo sous fedora (je ne pense pas car cela implique un format de dépot spécial), mais il est de loin le plus rapide pour gérer des RPMs.

        • [^] # Re: Merci !

          Posté par  . Évalué à 2.

          La librairie de gestion de dépendance (sat-solver) est déjà portée, mais zypp en lui-même non, en partie parce que Fedora utilise RPM 4.7 et que openSUSE est toujours en cours de migration vers la version upstream.
          Pas sûr que ce soit prêt avant la deadline prévue pour la prochaine suse, vu que le mainteneur est actuellement en vacances :]

  • # Pour les rpm la solution est ICI

    Posté par  . Évalué à 5.

    urpmi roxe

  • # Yum sux

    Posté par  (Mastodon) . Évalué à 2.

    Mouaif...

    malheureusement pas autant neuneu proof

    Tout est là, dans ce bout de phrase.
    Yum n' est pas neuneu-proof.

    Le comportement de Yum PAR DEFAUT est catastrophique : il met à jour pour interroger, il présente des résultats très peu synthétiques, il..,il, le tout dans une lenteur abominable.

    C' est un peu exagéré, mais c' est vrai. Comparons Urpm et Yum dans leur comportement par défaut, et la différence est flagrante : "au secours c' est quoi cette daube de Yum ?".

    Mais c' est bien parcequ' il n' est pas "neuneu proof", en fait.
    Yum est totalement hallucinant dès lors qu' on sait le manipuler (que l' on connait un bon morceau sur pas mal d' options). L' impression donnée par le comportement par défaut peut être totalement inversée dès lors que l' on connait quelques options. On est vraiment dans un cas "pas neuneu proof".

    Bref le comparatif est intéressant, mais pour qu' il sorte d' un sentiment de gros troll velu, il faudrait détailler les options usitées pour la comparaison. Et faire un tableau comparatif croisé en fonction de ces options.

    Je vais la faire autrement :
    Yum ça roxorise sévère par sa vitesse de traitement.
    Urpm ça roxorise sévère parceque par défaut c' est pratique et rapide.
    APT ça roxorise sévère parcequ' il sait gérer des cas qu' aucun autre ne sait faire.

    • [^] # Re: Yum sux

      Posté par  . Évalué à 1.

      Donne moi un exemple d'options Yum qui changent tout si tu veut bien.

      Envoyé depuis mon lapin.

      • [^] # Re: Yum sux

        Posté par  (Mastodon) . Évalué à 3.

        -C ?

        • [^] # Re: Yum sux

          Posté par  . Évalué à 2.

          C'est pas une option, c'est un palliatif au défaut de Yum qui est de faire une mise à jour de sa base de données à chaque manipulation (même une simple interrogation).

          Encore que maintenant, cette option n'est plus très utile dans la mesure où ce comportement a été changé.

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

Suivre le flux des commentaires

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