Journal Test de la Mandriva Cooker, future 2010.0

Posté par (page perso) .
Tags : aucun
6
12
oct.
2009
Bonjour,

D'Humeur à faire des tests, et bénéficiant depuis peu d'une connexion 30Mbps limitée à 30Gio/mois, je me suis mis en tête de télécharger la dernière bêta de Mandriva 2010.0 et de l'installer, histoire de tester et de découvrir Mandriva.

En effet, comme dit dans un de mes précédents journaux, j'ai trouvé la version 2009.1 de Mandriva exceptionnellement supérieure aux autres distributions, de mon point du vue.

Je télécharge, écrit tout ça sur ma clef USB, et démarre dessus. Cette fois-ci, tout marche impeccablement. Je lance l'installateur, partitionne (cette fois-ci, c'est une partition Ubuntu 9.04 qui a valsé :-) ), configure, et installe.

Au redémarrage, écran noir avec une boîte blanche au centre. Pas de panique, Ctrl+Alt+F1, et j'arrive dans une console virtuelle qui marche. Au passage, je remarque les joies du KMS : le switch est instantané, sans devoir changer le mode de mon écran :D ! Je lance un top, et voir qu'un grep utilise 11% de ma mémoire et 100% de mon IO. Je repasse en graphique, qui s'est curieusement débloqué. Je m'inscrit alors sur leur site comme c'est si gentiment proposé.

Ensuite, le bureau démarre, toujours avec le grep en arrière-plan. Le tout est réactif, le défilement de l'utilitaire de présentation est fluide, la 3D marche (carte Intel + pilote libre), parfait.

Je clique sur le menu K, et arrive, au bout de 5 secondes, sur leur petit menu de KDE3. C'est là que je remarque un bug bien embêtant que j'avais connu du temps de la sortie de KUbuntu 9.04 : le pilote Intel semble lent, très lent. Une fois que les composants sont affichés à l'écran, ça va, mais la création de fenêtre est d'une lenteur désolante. J'ai testé l'ancien menu, le nouveau, et Lancelot, avec et sans composition, c'est toujours aussi lent. Ouvrir une boîte de dialogue est également poussif.

Je me dis qu'une mise à jour va corriger le problème. Magnifique, une jolie icône en forme de point d'exclamation s'est affichée. Ca change de mon temps sous Debian Sid, qui n'affiche pas cette icône. Je coche toutes les mises à jour, et remarque que ça va m'installer 800 paquets. Pas de panique, j'ai une connexion de monstre maintenant, donc j'appuie sur OK.

Je n'aurais pas du. 2 heures, oui, deux heures que ça a pris !! Je n'ai jamais vu un truc aussi lamentablement et ignoblement poussif. Je savais que comparé au .deb, le RPM n'était pas rapide, et que les outils Mandriva sont codées en perl, mais là, c'est clairement le programmeur qui a bu.

J'ai 800 paquets à installer. Ça m'en télécharge 8, puis ça vérifie les signatures (et bien entendu, ça ne télécharge rien de plus, sinon ce serait trop beau), puis ça les installe un par un par un RPM poussif qui prend 5 secondes par paquet. Une fois le groupe fini, on télécharge les 8 paquets suivant, vérifie, installe, etc. Ce petit manège a duré des heures, pour finalement bien se terminer (en prenant tellement son temps, c'est impossible de rater).

Quand je pense que pendant ce temps-là, je développe un gestionnaire de paquets capable de télécharger, décompresser et installer en parallèle, je me dis que j'ai bien fait, tellement la fonctionnalité manque quand on ne l'as plus. Bon, par contre, la résolution des dépendances est rapide, plus que APT/Aptitude (Aptitude est plus lent que APT), ça a du prendre une demi seconde pour la mise à jour de 800 paquets.

Bon, une fois ces paquets installés, je découvre les magnifiques outils de configuration de Mandriva. Là encore, c'est beau, c'est fluide, et on a le choix. Ce truc, je suis certain qu'il sait faire le café si on trouve le bon bouton ! Je trouve l'endroit où on installe les paquets, sélectionne «Tout» à la place de «Uniquement les applications graphiques» (très bon ce filtre, ce sera repris dans ma GUI), et recherche "libqt4-dev". J'installe libqt4-devel, puis kdelibs4-devel (qui m'installe 300 autres paquets, dont cups-common o_O), et installe.

Là aussi, ça prend son temps. J'en profite pour aller lire mes mails, c'est à dire configurer Kontact. Ce doué d'installateur, à qui j'avais bien dit que j'ai une partition /home, l'a bien monté comme il faut mais a écrasé mon dossier de mails dans KMail pour aller mettre ce petit mail de présentation de Mandriva pour m'accueillir. Pof, a plus les 150 mails que je gardait, et les 8000 autres dans la corbeille.

Il y a aussi d'autres petits machins qui ne vont pas, en particulier les paquets. En quoi ais-je besoin de gnome-common ? Toujours ces foutues applications qui dépendent de GNOME alors qu'elles ne devraient pas, et Mandriva qui m'installe Ekiga alors que je n'ai rien demandé. J'ose à peine imaginer le nombre de trucs qu'on aurait pu faire rentrer sur le LiveCD si on n'avait pas la moitié de GNOME qui vient avec (au hasard, GIMP).

Du côté système, Mandriva est très bon. Il y a ce KMS qui marche bien, et la chaîne de démarrage qui est magnifique. GRUB 1 graphique (ça j'aime pas trop, trop hackish pour moi, j'aurais préféré GRUB 2), Plymouth qui marche à merveille, et des thèmes spéciaux pour KDM et KSplash. Le tout démarre très vite, et en 20 secondes, on est sur le bureau. Par contre, ils ont joué le Windows là. En 20 secondes, je suis sur le bureau, le disque à l'arrêt. Je me dis «Tiens, mes applications que j'avais lancées ne sont pas réouvertes, je vais les relancer». J'ouvre donc un Konqueror, et une Konsole s'ouvre ! Et oui, le démarrage des services (dont la restauration de session) est fait quelques secondes après le login. Ce n'est donc qu'une impression de bureau prêt, même si c'est vrai que c'est agréable d'avoir la main très tôt.

En clair, j'aime bien Mandriva. Quand on est resté sur une Debian Sid pendant plus de deux mois, c'est agréable de toucher à nouveau à une distribution pour débutant. Je vais pouvoir me concentrer sur mon code (en plus GCC 4.4 est installé à la place du vieux 4.3 de Debian), et le système se gère tout seul. Il suffit de faire les mises à jour, et ça roule. Le gestionnaire de paquets graphique avec les applis classées par catégories est super. On n'y pense pas, mais c'est très agréable quand on s'ennuie d'explorer la catégorie Jeux et d'en installer un au hasard. Qui sait, peut-être qu'un jour je contribuerai à un des jeux répertoriés là-dedans.

Une dernière note pour les versions : au menu, noyau 2.6.31.4 (alors que l'officiel est encore le .3, ils sont trop forts chez Mandriva), le pilote Intel 2.9.0 (donc le dernier), KDE 4.3.2 (donc le dernier), et tout un tas d'autres softs (dont FireFox 3.5, et ses dépendances GNOME 2.28).

Moi, je signe. J'ai peut-être dit un peu beaucoup de mal du gestionnaire de paquets, mais je l'aime bien. En quelques clics, on a le Logiciel Libre à sa portée.

Franchement, chapeau aux développeurs de Mandriva. C'est la distribution qui devrait être à la place d'Ubuntu.
  • # Et parce qu'on poste toujours trop vite...

    Posté par (page perso) . Évalué à 3.

    ...Je rajoute quelques détails.

    J'ai, première fois de ma vie, formatté ma partition en XFS, pour tester. Il faut dire que je n'en n'avais entendu que du bien, performant, sans checkdisk au démarrage, rapide à formatter, solide, etc. Je ne suis pas déçu ! Le démarrage est bien rapide, je l'ai dit dans le journal, mais je viens aussi d'importer ma collection de musiques dans Amarok. Sous Debian, ça prenait une dizaine de secondes. Ici, ça a pris 2 secondes, et encore !

    Deuxième point, les thèmes. Quand la 3D est activée, on a des décorations de fenêtres genre Oxygen, mais avec quelques modifications (qui personnellement ne me plaisent pas trop). Le thème de widgets, unifié entre GNOME et KDE, est léger et épuré. Il est également gentil pour le processeur, ce qui fait que l'ensemble de l'interface semble bien fluide. Pour tout ce qui est fond d'écran et écran de démarrage, c'est très joli.

    Par contre, énorme point noir, c'est du i586. J'ai donc un KDE SVN compilé et tous ses modules qui se trouve impossible à lancer, de même qu'un Qt snapshot Git (future 4.6). Je sens que ça va compiler sec ces prochains jours (toujours mon petit Atom qui compile 1 SBU* en près de 25 minutes).

    * http://www.linuxfromscratch.org/lfs/view/development/chapter(...)
    • [^] # Re: Et parce qu'on poste toujours trop vite...

      Posté par . Évalué à 3.

      Par contre, énorme point noir, c'est du i586.

      C'est parce que tu as installé avec un live CD, qui sont tous des version i586 pour supporter la plus large audience possible.

      Si tu veux du X86_64 il faut prendre le DVD version x86_64 (il y a les deux) ou l'ISO mini-dual qui contient le minimum du système pour les deux architectures (et après on installe par internet, ou directement pendant l'installation on choisit des sources distances pour qu'il sélectionne tout directement).

      cf http://wiki.mandriva.com/en/2010.0_RC_2#Available_media
      • [^] # Re: Et parce qu'on poste toujours trop vite...

        Posté par . Évalué à 1.

        Ça m'étonnerait puisque, à cette heure et malheureusement, la one de la rc2 n'est pas encore disponible d'après ce que je peux constater sur les miroirs.

        À moins qu'il ne parle de la rc1...
      • [^] # Re: Et parce qu'on poste toujours trop vite...

        Posté par (page perso) . Évalué à 1.

        C'est possible, mais rien n'est fait pour me mettre en confiance :

        * Je vois que les paquets sont du genre "lib64qt4", ce qui me fait croire qu'on peut toujours avoir un système "à moitié" en 32-bit. Fedora avait ce problème, car tous les paquets qu'on installait l'étaient en 32-bit sauf si on demandait explicitement le contraire (Fedora 9, ça date)
        * Vu que quasi tout le monde utilise la version 32-bit, il faudrait s'assurer que les paquets 64-bit soient de la même qualité.

        Bref, ça me convient pour le moment, et me permet de tester GCC 4.4.
        • [^] # Re: Et parce qu'on poste toujours trop vite...

          Posté par . Évalué à 4.

          Faudrait savoir, tu veux du 64 bits ou pas?
          Moi j'utilise la version x86_64 depuis la 2008.1.

          Le packaging permet effectivement d'avoir un mélange de paquets 32 bits sur une installation de base 64 bits et c'est un gros avantage.
          Ça permet d'utiliser quand même des programmes qui ne fonctionnent pas en 64 bits (openoffice avait par exemple mis du temps à être fonctionnel, ou encore si tu veux utiliser des logiciels propriétaires).

          Il "suffit" de mettre les sources de paquets dans le bon ordre pour donner priorité aux version x86_64 (ça peut encore donner des effets bizarres si tu as une version plus récente d'un paquet dans une source 32 bits, mais si tu reste sur les sources officielles ça ne devrait pas arriver).

          * Vu que quasi tout le monde utilise la version 32-bit, il faudrait s'assurer que les paquets 64-bit soient de la même qualité.

          D'où viennent tes statistiques?
          • [^] # Re: Et parce qu'on poste toujours trop vite...

            Posté par (page perso) . Évalué à 2.

            > D'où viennent tes statistiques?

            Le neuneu moyen, il va télécharger les belles images LiveCD qui sont présentées sur la première page du wiki et sur le site officiel. Les images x86_64, il faut vraiment les vouloir (ici passer par un DVD -je n'ai pas de DVDs-, ou alors il paraît que les PowerPack contiennent une version 64-bit. On peut aussi prendre des images minimales, mais ce n'est pas l'idéal pour le débutant).

            Pour la majorité des utilisateurs, seule la version i586 existe, donc ils la prennent, et comme ils sont nombreux, les développeurs vont bien déboguer les paquets i586 (de même que plus d'utilisateurs enverront leurs bugs).
            • [^] # Re: Et parce qu'on poste toujours trop vite...

              Posté par . Évalué à 2.

              Dans les install parties, lorsque la personne a du matériel compatible je fais toujours une installation x86_64, et j'ai déjà vu plusieurs fois des gens qui n'y connaissent pas grand chose en informatique, mais qui savaient que leur ordinateur est un 64 bits (because marketing) et voulaient donc un linux (ils ne connaissaient pas non plus le terme distribution) qui utilisera pleinement leur matériel.

              Donc si, je t'assure, il y a des gens qui utilisent les version x86_64.
              • [^] # Re: Et parce qu'on poste toujours trop vite...

                Posté par (page perso) . Évalué à 2.

                avec des stats pour le montrer ça va toujours mieux
                http://smolts.org/static/stats/stats.html
                27,8% de x86_64 (et aucune ubuntu, cf. page OS)
              • [^] # Re: Et parce qu'on poste toujours trop vite...

                Posté par . Évalué à 4.

                Je n'ai toujours pas compris l'intérêt d'avoir du 64 bits à la place du 32 bits quand on n'a pas strictement plus que 4 Go de RAM...

                OK la swap est pratiquement illimitée, OK les jeux d'instructions sont mieux pensés qu'en 32 bits mais au final j'ai l'impression (je parle bien du cas inférieur ou égal à 4 Go qui d'après mes études hautement poussées représentent 90 % du parc) que la vitesse d'exécution 32 vs 64 est en moyenne à peu près la même et que les versions 64 bits demandent plus de mémoire pour s'exécuter à cause de la taille des pointeurs qui enfle.

                Si quelqu'un a un article de qualité (voir même un argumentaire, on n'est pas vendredi, soyons fous !) confirmant ou infirmant cette impression, je suis moult intéressé...
                • [^] # Re: Et parce qu'on poste toujours trop vite...

                  Posté par . Évalué à 1.

                  Pas grand chose, mais d'après Wikipédia :

                  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, autres) n'ont pas leur version 32 bits encombrée d'une structure archaïque

                  (Tiré de Processeur_64_bits).

                  En gros, si j'ai bien compris, ça permet de gommer les défauts architecturaux des processeurs x86.

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

                  • [^] # Re: Et parce qu'on poste toujours trop vite...

                    Posté par . Évalué à 3.

                    Oui, j'avais déjà lu l'article de wp... la version anglaise étant à mon sens plus pertinente : http://en.wikipedia.org/wiki/64-bit#Pros_and_cons

                    Mais dans la vie de tous les jours (ie hors utilisation intensive de programmes optimisés pour utiliser efficacement les registres supplémentaires du 64 bits) j'ai l'impression que le 64 bits (pour moins de 4 Go) n'apporte pas grand chose (voire enlève parfois).
                • [^] # Re: Et parce qu'on poste toujours trop vite...

                  Posté par . Évalué à 1.

                  Si tu aimes vraiment les versions 32bits il doit y avoir des noyaux «serveurs» tout fait pour mandriva qui permettent d'avoir jusqu'à 64Go de RAM (avec l'option HIGHMEM64G).

                  Perso j'ai un proc 64bits, alors j'installe des distributions en 64bits, je cherche pas plus loin.
                • [^] # Re: Et parce qu'on poste toujours trop vite...

                  Posté par . Évalué à 1.

                  Et moi je n'ai toujours pas compris l'intérêt d'avoir du 32 bits à la place du 64 bits quand on a du materiel compatible et des logiciels qui fonctionnent en 64 bits...
                  • [^] # Re: Et parce qu'on poste toujours trop vite...

                    Posté par . Évalué à 1.

                    super cette phrase... échange les nombres 32 et 64 et elle marche toujours ;-)

                    sinon pour répondre sur le fond : en 32 bits la taille des données utilisées est moins importante qu'en 64 bits (et ça dépend du modèle 64 bit utilisé ainsi que de l'utilisation plus ou moins importante de pointeurs) et peut donc plus facilement rentrer dans le cache et retarder l'utilisation du swap. Un programme 32 bits peut donc très bien être plus rapide (et parfois beaucoup) qu'un programme 64 bits. Le cas où on tire profit du 64 bits c'est typiquement quand les programmes ont été optimisés **spécialement** pour le 64 bits (et pas juste recompilés), ce qui est souvent vrai pour des programmes utilisant de l'arithmétique intensément (compression, chiffrement, etc), mais beaucoup moins pour une utilisation générale.

                    Mettre du 64 bits pour mettre du 64 bits (et je rappelle qu'on parle de mémoire vive inférieure à 4 Go), je suis désolé, si ça utilise plus de mémoire et si c'est plus lent que le 32 bits, désolé, mais je ne vois pas l'intérêt.
                    • [^] # tests d'encodage

                      Posté par (page perso) . Évalué à 2.

                      Il y a quelques temps, j'avais installé Mandriva en version 32 et 64 bits (peut être était-ce la 2008.1) et je m'étais livré à quelques essais d'encodage audio (wav vers mp3 ou ogg) et j'avais constaté un gain de performance de l'ordre de 30% en 64 bits.

                      Ça vaut ce que ça vaut
    • [^] # Re: Et parce qu'on poste toujours trop vite...

      Posté par . Évalué à 3.

      Je vais peut-être passer pour un imbécile qui comprend tout de travers, mais tu dis que Kmail a effacé tes mails, donc ce n'est pas ton /home que tu avais reformaté en XFS mais une autre partition, non? C'est laquelle? Parce que Amarok, je suppose qu'il fait aussi sa base de données dans ton /home?

      (J'ai dit une conn...?)
    • [^] # Re: Et parce qu'on poste toujours trop vite...

      Posté par (page perso) . Évalué à 1.

      Un inconvénient de XFS: s'il sait très bien gérer les extensions de partition, il ne supporte pas les réductions de partition.

      Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

  • # Bonne distribution mais...

    Posté par . Évalué à 1.

    J'ai pu tester également dernièrement la Mandriva cooker, et franchement quand tu veux une distribution entièrement sous QT/KDE, c'est quasiment impossible. Il y aura toujours une dépendance vis à vis d'une librairie gnome ou autres.

    ''J'installe libqt4-devel, puis kdelibs4-devel (qui m'installe 300 autres paquets, dont cups-common o_O), et installe.''
    Tu as essayé l'option --no-suggests de urpmi? ça débarrasse déjà de beaucoup de dépendances optionnelles.

    Le dernier truc qui m'irrite, impossible de virer ce pulseaudio, il restera ancré dans mandriva obligatoirement, car si on tente de le supprimer, ça vire les 3/4 des paquets.
    Sinon globalement mis à part ces dépendances en tout genre et qu'on ne sait pas pourquoi on en a besoin, c'est une bonne distribution.
    • [^] # Re: Bonne distribution mais...

      Posté par (page perso) . Évalué à 5.

      $ pacman -Q|grep gnome
      $

      Si si, ca existe ;)
    • [^] # Re: Bonne distribution mais...

      Posté par (page perso) . Évalué à -3.

      Donc Mandriva avec des deb, c'est la distribution ultime?

      Et pour pulse audio, c'est partout pareil, c'est une bouze infame qui s'est étendu sur l'ensemble des systèmes depuis sa création :/
      • [^] # Re: Bonne distribution mais...

        Posté par (page perso) . Évalué à 4.

        Bon, allez, j'en rajoute une couche ;)

        $ pacman -Q|grep pulse
        $
      • [^] # Re: Bonne distribution mais...

        Posté par . Évalué à 7.

        > Et pour pulse audio, c'est partout pareil, c'est une bouze infame
        Une bouse uniquement sur les distros qui savent pas configurer correctement PA. Hein, PA a des problèmes mais nettement moins que feu aRts et ESound qu'il remplace.


        > qui s'est étendu sur l'ensemble des systèmes depuis sa création
        La première distribution a avoir installé PA par défaut c'est Fedora 8 fin 2007 et ça fonctionnait parfaitement. Les autres distributions ont suivi 6 mois plus tard avec plus ou moins de bonheur. La palme de l'imbécilité revenant à Ubuntu qui a foutu PA (ça mérite même pas le terme intégration) dans la 8.04 avec une configuration foireuse non testée, sans même consulter le mainteneur upstream (le fameux Lennart Poettering).
        PA est né en 2004 sous le nom Polypaudio, il est pas sorti de nulle part et au bout de 4 ans, il était peut-être temps de l'intégrer au bureau.


        À un moment, faut se sortir les doigts du cul, PA n'est pas parfait, son mainteneur est aussi aimable qu'un roulier texan assis sur un banc d'oursins, mais dans l'ensemble c'est une amélioration substantielle de la pile audio du bureau GNU/Linux.
        Au lieu de pleurnicher et de le désinstaller au premier pépin *sans chercher plus loin*, faites l'effort de faire remonter les bogues. Sans compter que bon nombre de bogues attribués à PA sont des bogues propres aux pilotes Alsa, ou dû à des hacks pour contourner les-dits bogues.
        "J'ai pas de son" ==> vlan, vire PA, "mon nordinateur est lent" ==> vlan, vire PA, "j'installe la distro XYZ" ==> VIRE PA !!!!
        • [^] # Re: Bonne distribution mais...

          Posté par (page perso) . Évalué à 1.

          "Je n'en ai pas l'interet" ==> vlan, vire PA

          Franchement, pour monsieur tout le monde, ca sert à quoi?

          Je l'ai installé sur une Debian SID en me mettant dans le bon groupe et tout et tout...

          Ca tournait plutot bien mais j'ai pas vu l'interet => vlan, vire PA
          • [^] # Re: Bonne distribution mais...

            Posté par . Évalué à 4.

            > Franchement, pour monsieur tout le monde, ca sert à quoi?
            To 3nl4rg3 sa desktop experience. Avec PA, tu peux configurer le volume pour chaque application, tu peux rediriger facilement le son sur une autre machine, d'autres applications sont possibles comme baisser automatiquement le volume de toutes tes applis quand tu reçois un appel par VoIP, à switcher automatiquement la sortie audio quand tu branches un casque etc...
            C'est peut-être "gadget", mais ça revient à se remettre au niveau des OS propriétaires communs sur le desktop.

            Tu n'en vois pas l'intérêt ou n'a pas l'utilité c'est ton droit, mais j'en ai marre de lire sur les forum (fedora y compris) des messages où pour n'importe quel problème (qui parfois n'ont rien à voir du tout avec l'audio), on te fait désinstaller PA. Le plus agaçant, c'est ceux qui n'ont pas utilisé PA depuis plus d'un an et qui après se permettent de dire "PA saidlamerde, gnagna".
            • [^] # Re: Bonne distribution mais...

              Posté par . Évalué à 3.

              Non c'est génial sur le papier
              ça reste génial sur le papier

              Maintenant si pour faire ça PA consomme 20% de 2 Xeon 3.4ghz et 12% de 2go ecc, ben y a pas à dire... rien à dire d'autre que "PA ? dehors !!!"

              C'est Alsa qui faut revoir. C'est pas en foutant des couches rt des couches que ça va améliorer les choses. Je reste toujours sur le cul que justement cela soit Fedora qui est intégré ce truc là. Qu'une petite distrib s'y essaye, ok, mais Fedora, et avec le recul d'aujourdhui.... comme quoi, tout le monde peux se tromper.

              Je me trompe peut être aussi, mais pour moi c'est plus bas qu'il faut revoir les choses. Améliorer Alsa, en foutre plus dans le userland... mais bon....
              • [^] # Re: Bonne distribution mais...

                Posté par . Évalué à 7.

                Je reste toujours sur le cul que justement cela soit Fedora qui est intégré ce truc là.
                C'est justement pour cela que fedora existe, tout tester, on s'en fout que ce soit utilisable. Si c'est concluant, ça passe dans red-hat, sinon c'est remis à plus tard -avec développement à la clef, ou jeté.

                Pour le reste j'apprécie particulièrement le fait de pouvoir couper/baisser le son du flash sans couper amarok, (alors qu'avant flash me bloquait le dsp et empêchait tout son de sortir si j'avais rien qui tournait lorsque le plug-in s'est déclenché)

                La grosse énigme pour pour reste quand même jack, j'avais essayé ça y a quelques années et il m'avait semblé que si plus d'application savaient le gérer ça aurait pu bien percer.

                Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                • [^] # Re: Bonne distribution mais...

                  Posté par . Évalué à 1.

                  Incroyable cet argument massue de Flash qui revient à chaque fois pour PulseAudio.
                  C'est vrai que PA a permis cela, presque comme une priorité absolue pour plaire à l'utilisateur, dès le début de l'intégration de PA.

                  Mais maintenant que Flash est full-alsa, on baisse le son d'une vidéo flash sans baisser le son d'un autre truc.

                  Pour Jack, compare les applications qui le supportent et celle qui ne le supportent pas, tu va être surpris ;) Mais c'est un tout autre débat.

                  J'ai l'intime conviction que PA a voulu à la fois combler les manques de Alsa, à la fois remplacer tout les trucs de haut niveau (genre esd / arts), et à la fois illico plaire à l'utilisateur. Le résultat c'est que ça marche moyen, y compris sur des distros comme Fedora et Mandriva qui en ont une excellente intégration semble t il, et que surtout ça consomme des ressources cpu / ram plus que Flash et Java réunis. On est donc en droit de se demander, au vue du résultat, si le choix était judicieux, et peut être un peu trop ambitieux. J'aimerai beaucoup voir PA intégré de plus basse couche (PA ou Jack, ou une amélioration de Alsa, je m'en fous et n'ai pas les compétences nécessaires pour juger de la meilleure solution, juste une simple intuition que "PA", tout comme esd ou arts, c'est vraiment pas beau)
              • [^] # Re: Bonne distribution mais...

                Posté par . Évalué à 2.

                Chez moi, PA au repos, 0% CPU, 6.5Mo en RAM, je lance une vidéo, ça monte à 5% (tout compris) et 17Mo en RAM. La machine est un quad core qui tourne depuis plus d'un mois.
                C'est pas extravagant, PA c'est un process supplémentaire donc forcément ça bouffe plus de ressources, ça a pas mal évolué en 2 ans. Par contre, sur certaines machines, la conso CPU reste affolante mais si personne n'aide à identifier le problème, on risque pas d'aller bien loin.

                > C'est Alsa qui faut revoir.
                Certes, Alsa et les pilotes ont sérieusement besoin d'un bon coup de polish.
                Alsa c'est très bas niveau, ça ne dispense pas d'avoir une API plus haut niveau.

                > Je reste toujours sur le cul que justement cela soit Fedora qui est intégré ce truc là
                Là, je t'arrête, intégrer des nouvelles technologies et les aider à atteindre leur maturité le plus rapidement possible c'est LA mission de FedoraProject.
                En plus, le mainteneur upstream est également le mainteneur dans Fedora (et il fait très bien son boulot en tant qu'intégrateur, une cassure au tout début en 2 ans) donc les correctifs ont été très rapidement intégré. En revanche, les distributions se sont ruées dessus trop tôt contrairement aux recommandations de L. Poettering.
                • [^] # Re: Bonne distribution mais...

                  Posté par . Évalué à 2.

                  Certes j'exagère quelque peu sur l'usage des ressources matérielles par P.A. néanmoins j'ai toujours observé, sur Mandriva comme sur Fedora, une propention -inexplicable pour moi- à consommer de plus en plus. Cela ressemble presque à une fuite de mémoire (et une fuite de conso cpu) car ce n'est pas une augmentation exponentielle de la conso en fonction du nombre d'appli l'utilisation, mais d'une augmentation de consommation avec le même nombre d'application.

                  Jack par exemple, est également consommateur de ressource, mais de façons bien moindre, et surtout en rappoprt avec la latence et le nombre d'appli (et de liens entre elles). Par exemple, oui j'ai une config qui a une latence de 0,004 millisecondes avec jack (!) mais c'est au prix de 70% de conso cpu sur 2 xeon 3.4ghz, avec Ardour, Mplaye x 2, RecordMydesktop... La latence exigée est la principale source de consommation avec Jack. Ca consomme dur aussi. Mais ça semble logique d'une part, et surtout c'est stable !

                  J'espère et je souhaite vraiment le meilleur au desktop linux, bien sûr, mais je ne sais pas si P.A. ne nous pousse pas vers une attitude alavista : toujours consommer plus pour ne pas faire plus qu'auparavant, à peine plus facile.
                  • [^] # Re: Bonne distribution mais...

                    Posté par . Évalué à 2.

                    mais je ne sais pas si P.A. ne nous pousse pas vers une attitude alavista : toujours consommer plus pour ne pas faire plus qu'auparavant, à peine plus facile.

                    Ce n'est pas ce que le projet KDE a fait avec la version 4 ? Et pourtant, qui s'en plaint aujourd'hui ?

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

      • [^] # Re: Bonne distribution mais...

        Posté par (page perso) . Évalué à 3.

        Donc Mandriva avec des deb, c'est la distribution ultime

        Et ça apporterait quoi concrètement de passer de RPM à Deb ?
        • [^] # Re: Bonne distribution mais...

          Posté par . Évalué à -2.

          De la rapidité ?

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

          • [^] # Re: Bonne distribution mais...

            Posté par (page perso) . Évalué à 4.

            Et comment ? Tu ne confonds pas gestion des dépendance, installation et format de paquet ?
            • [^] # Re: Bonne distribution mais...

              Posté par . Évalué à -3.

              De toute façon sur les trois, deb/apt est plus rapide...

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

              • [^] # Re: Bonne distribution mais...

                Posté par . Évalué à 3.

                La rapidité ne fait pas tout. Et le type de packaging non plus.

                Je n'aime pas du tout, mais alors vraiment pas, voir des dépendances absconnes tombées lorsque j'installe un paquet (absconnes parceque non en rapport avec le paquet demandé, des dep de dep de dep). Avec Mandriva c'est rarement le cas, très rarement. tu a en trouvé un beau, là "kdelibs4-devel (qui m'installe 300 autres paquets, dont cups-common o_O" hihi c'est pas incohérent non plus, comme sous deb', mais c'est un peu énervant, cela devrait être en "suggestion" et ne pas être séléctionné avec l'option "--no-suggests). C'est le reproche que je fais à Debian, par défaut, cela se comporte en "install the rest of the world". Ceci n'est pas un troll deb/rpm, c'est juste un constat d'utilisation. A la limite je préfère encore l'opposé : le bon vieux rpm seul à ce compte là, au moins j'installe juste ce dont j'ai besoin.

                Ne t'arrêtes pas à cette première impression sur la gestion de paquets, steckdenis, car d'une part il y a un gros boulot qui est fait sur le packaging, les algo de résolutions de dep entre autre (et ça devrait t'intéresser, ça, sûr :) ), et d'autre part des bugs du type "menu" c'est totalement une tradition sur cooker. Le menu lent est vraiment l'exemple typique qui revient régulièrement dans cooker, et disparait sur la powerpack. Dans le genre autre bug classique, il y a les drakxtools qui sont souvent cassés aussi. Va faire un tour sur http://www.mandriva.com/enterprise/en/company/r-d qui vient tout juste d'avoir une belle mise à jour, ça tombe bien ;) ;) ;) ;) Bon je suppose que Mancoosi devrais plus te 'parler'

                Et ouaih, urpmi est une foudre de guerre. Clair. C'est une magnifique réussite. Parceque j'utilise rpm, up2date et maintenant yum 8h par jour, surtout depuis yum : j'apprécie encore plus Urpm en rentrant chez moi \o/ D'ailleurs je vois qu'il commence à y avoir des portages de Urpm pour Fedora, super \o/ Ca vaut le coup de se faire son dépôt synchro pour utiliser Urpm avec Fedora !

                /*pas un troll
                yum install Xephyr = 38 secondes de traitement, puis 3mo sur la swap car les 512 de ram sont occupés, puis l'installation.
                urpmi xephyr = 3 secondes de traitement, puis l'installation.
                Etat initial identique, dépendances à installer identiques. La différence est tellement énorme qu'il faut vraiment essayer soi même pour le vérifier !
                */

                Essaye drakrpm, il vient tout juste (il me semble) d'avoir une nouvelle fonction fort sympathique sur Cooker : il télécharge tout seul les nouvelles listes (sur Cooker c'est forcément indispensable) et ...uniquement si besoin... Là encore quelle différence !! Même avec l'interface graphique c'est plus que sympa et pratique.

                Pour le full Qt ça va être dur vu que les outils Mandriva sont tous en "Gtk", il y aura donc toujours des bouts de Gtk sur une distrib même 100% Qt. Et de toutes façons, par défaut, LXde est installé (en remplacement du bon vieux ICEwm) comme bureau de secours, donc Gtk aussi. Perso j'aime bien ce mix, tant qu'il est pas envahissant sur le look'n'feel.
    • [^] # Re: Bonne distribution mais...

      Posté par . Évalué à 2.

      Pour pulseaudio, tu peux malgré tout le désactiver et utiliser directement alsa (ou un autre seveur de son).
      C'est en fait gnome qui a une grosse dépendance dessus parce qu'il remplace esound, via le paquet pulseaudio-esound-compat, je pense que si tu remplace ce dernier par esound-daemon tu devrais pouvoir virer pulseaudio sans que ça entraîne tout gnome (et tout ce qui dépend de esound, comme mplayer).
      • [^] # Re: Bonne distribution mais...

        Posté par . Évalué à 1.

        J'avais installé mandriva histoire de revoir l'état actuel (car la dernière fois que je l'ai utilisé c'était la Mandrake 10.1).
        Pour le peu que je l'ai utilisé, j'étais obligé de désactiver pulseaudio car le son s'accélérait avec l'option targa-dig de snd-hda-intel, donc pas le choix !
        D'ailleurs j'ai aimé la fois où pulseaudio a déliré et où il s'est mis à prendre 550mo d'ram et X % du CPU.

        Il n'y a pas que Gnome qui a une grosse dépendance vis à vis de pulseaudio, KDE l'a tout autant ;).
        Malgré tout, heureusement que j'ai ma p'tite arch sur une partition.
        • [^] # Re: Bonne distribution mais...

          Posté par . Évalué à 3.

          Il n'y a pas que Gnome qui a une grosse dépendance vis à vis de pulseaudio, KDE l'a tout autant ;).

          Non.
          Si je fais un test de désinstallation de PA les seuls paquets de KDE4 qui s'en vont sont ceux ayant une dépendance sur mplayer (qui dépend de libesd qui dépend de esound qui est fourni par PA via un paquet de compatibilité).
          Les quelques programmes de KDE3 qui me restent partent aussi à cause de libarts qui a aussi une dépendance sur libesb (??).

          Et comme je disais dans mon post précédent il faut simplement installer le paquet esound-daemon, qui va du coup forcer la désinstallation de pulseaudio-esound-compat et après on peut désinstaller PA sans virer la moitié des programmes.

          D'ailleurs, alliant le geste à la parole, je viens de désinstaller pulseaudio, une fois l'épine esound sortie du pied ça ne désinstalklke plus que 8 paquets, tous explicitement en rapport avec PA.
          • [^] # Re: Bonne distribution mais...

            Posté par (page perso) . Évalué à 4.

            En meme temps, installer esound pour remplacer PA, faut être un peu maso...
          • [^] # Re: Bonne distribution mais...

            Posté par . Évalué à 1.

            Pourtant dans mon cas, sur une installation fraiche de Mandriva via DVD, il me vire une grosse partie de kde 4 (j'avais X logiciels d'installés, j'avais pas trié à l'installation)
            Peut être que par le biais d'une installation minimale de KDE celà se ressent moins.
            • [^] # Re: Bonne distribution mais...

              Posté par . Évalué à 2.

              As-tu essayé d'installer esound-daemon pour remplacer pulseaudio-esound-compat?
              • [^] # Re: Bonne distribution mais...

                Posté par . Évalué à 1.

                Oui mais toujours pareil, en choisissant toujours esound à la place de pulseaudio, ben il y a toujours une trace de pulseaudio, en installant uniquement task-kde-minimal. Etonnant.
                Mais bon c'est pas la fin du monde si ça traine, c'était juste une remarque quant au dépendances trop "attachantes".
  • # temps de chargement

    Posté par . Évalué à 5.

    Bonjour,

    je suis sur mandriva depuis plusieurs années,
    je viens de d'installer complètement la cooker 2010,

    j'ai toujours remarqué qu'il ne fallait pas lancé la mise à jour lors de l'intallation,
    car effectivement dans ce cas c'est très très long,

    j'ai lancé ma mise à jour (en partant de la free 64 bit lxde vers kde4) soit 950 paquets
    au premier redémarrage et ça a pris 20 minutes au plus

    ++

    • [^] # Re: temps de chargement

      Posté par . Évalué à 2.

      Ah, mais dans ce cas c'est à l'installateur de vivement conseiller l'utilisateur de ne pas faire de mise à jour avant le redémarrage.

      Mandriva est une distribution orientée vers les débutants, qui ne peuvent pas deviner!
      D'ailleurs, même les utilisateurs expérimentés qui découvrent Mandriva ne peuvent pas deviner!
      • [^] # Re: temps de chargement

        Posté par . Évalué à 2.

        Mandriva, oui
        Mais Mandriva Cooker est orienté testeurs, au moins testeurs (et plutot chevronnés quant même, du moins qui ne seront pas choqués que telle fonction ne marche pas)
        ;)

        http://wiki.mandriva.com/fr/Cooker
        • [^] # Re: temps de chargement

          Posté par . Évalué à 3.

          Ah, mais dans ce cas il faut préciser que le problème n'existe que sur la Cooker et pas la version finale.

          (Bon, je sais: Ah mais dans ce cas je suis lourd, bon ben je suis lourd hein!)

          Cependant, c'est vrai que si des utilisateurs de Cooker s'inquiètent de trouver des bugs ou des fonctionnalités mal finies, va falloir qu'on leur explique 2 ou 3 trucs...
  • # Essayé aussi, adopté

    Posté par (page perso) . Évalué à 2.

    Testé la RC1 sur un EeePC 1005HA il y a quelques semaines... avec ses tonnes de mises à jour régulières.
    Adopté. J'hésite même à mettre la RC sur mon poste de travail de tous les jours...

    [note: utilisateur Debian sur les serveurs et Mandriva sur les machines de bureau]

    Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

  • # pour kmail :

    Posté par (page perso) . Évalué à 1.

    À vérifier :
    Dans ton home, il y a probablement un répertoire ~/.Mail.

    Si c'est le cas :
    Arrêter kmail ;
    Dans ton répertoire ~/.kde4/share/apps/kmail, il y a un répertoire mail.

    Rebaptise le et fais un lien (ln -s) vers ~/.Mail.

    Et hop ! tes anciens mails sont récupérés

    Il ne te reste plus qu'à copier ou déplacer tes nouveaux mails dans l'ancien répertoire et le tour est joué.

    Tu peux aussi déplacer l'ancien répertoire ~/.Mail à la place de ~/.kde4/share/apps/mail. Le reste à l'avenant.

Suivre le flux des commentaires

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