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.
Journal Test de la Mandriva Cooker, future 2010.0
12
oct.
2009
# Et parce qu'on poste toujours trop vite...
Posté par steckdenis (site web personnel) . Évalué à 3.
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 wismerhill . Évalué à 3.
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 sirrus . Évalué à 1.
À moins qu'il ne parle de la rc1...
[^] # Re: Et parce qu'on poste toujours trop vite...
Posté par wismerhill . Évalué à 2.
http://wiki.mandriva.com/en/2010.0_RC_1#Available_media
La beta n'est sortie quant à elle qu'en DVD et live CD
http://wiki.mandriva.com/en/2010.0_Beta#Available_media
[^] # Re: Et parce qu'on poste toujours trop vite...
Posté par steckdenis (site web personnel) . Évalué à 1.
* 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 wismerhill . Évalué à 4.
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 steckdenis (site web personnel) . Évalué à 2.
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 wismerhill . Évalué à 2.
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 BAud (site web personnel) . Évalué à 2.
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 aedrin . Évalué à 4.
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 zebra3 . Évalué à 1.
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 aedrin . Évalué à 3.
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 Ludo . Évalué à 1.
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 Anonyme . Évalué à 1.
[^] # Re: Et parce qu'on poste toujours trop vite...
Posté par aedrin . Évalué à 1.
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 goom . Évalué à 2.
Ça vaut ce que ça vaut
[^] # Re: Et parce qu'on poste toujours trop vite...
Posté par Maclag . Évalué à 3.
(J'ai dit une conn...?)
[^] # Re: Et parce qu'on poste toujours trop vite...
Posté par lolop (site web personnel) . Évalué à 1.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# Bonne distribution mais...
Posté par yimm . Évalué à 1.
''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 gnumdk (site web personnel) . Évalué à 5.
$
Si si, ca existe ;)
[^] # Re: Bonne distribution mais...
Posté par Maurice Rosenfelder (site web personnel) . Évalué à 1.
Et hop !
[^] # Re: Bonne distribution mais...
Posté par vincent_k (site web personnel) . Évalué à -3.
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 gnumdk (site web personnel) . Évalué à 4.
$ pacman -Q|grep pulse
$
[^] # Re: Bonne distribution mais...
Posté par GeneralZod . Évalué à 7.
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 gnumdk (site web personnel) . Évalué à 1.
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 GeneralZod . Évalué à 4.
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 bubar🦥 (Mastodon) . Évalué à 3.
ç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 fearan . Évalué à 7.
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 bubar🦥 (Mastodon) . Évalué à 1.
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 GeneralZod . Évalué à 2.
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 bubar🦥 (Mastodon) . Évalué à 2.
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 zebra3 . Évalué à 2.
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 Dr BG . Évalué à 3.
Et ça apporterait quoi concrètement de passer de RPM à Deb ?
[^] # Re: Bonne distribution mais...
Posté par zebra3 . Évalué à -2.
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 Dr BG . Évalué à 4.
[^] # Re: Bonne distribution mais...
Posté par zebra3 . Évalué à -3.
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 bubar🦥 (Mastodon) . Évalué à 3.
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 Hrundi V. Bakshi . Évalué à 4.
[^] # Re: Bonne distribution mais...
Posté par wismerhill . Évalué à 2.
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 yimm . Évalué à 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 wismerhill . Évalué à 3.
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 gnumdk (site web personnel) . Évalué à 4.
[^] # Re: Bonne distribution mais...
Posté par wismerhill . Évalué à 2.
Il n'est pas plus démarré que ne l'était pulseaudio.
[^] # Re: Bonne distribution mais...
Posté par yimm . Évalué à 1.
Peut être que par le biais d'une installation minimale de KDE celà se ressent moins.
[^] # Re: Bonne distribution mais...
Posté par wismerhill . Évalué à 2.
[^] # Re: Bonne distribution mais...
Posté par yimm . Évalué à 1.
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 alexen . Évalué à 5.
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 Maclag . Évalué à 2.
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 bubar🦥 (Mastodon) . Évalué à 2.
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 Maclag . Évalué à 3.
(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 lolop (site web personnel) . Évalué à 2.
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]
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# pour kmail :
Posté par Maurice Rosenfelder (site web personnel) . Évalué à 1.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.