Test d'Ubuntu Jaunty (9.04)

Posté par (page perso) . Modéré par patrick_g.
Tags :
1
30
avr.
2009
Ubuntu
Alors que la dernière Ubuntu sortait il y a une semaine sa nouvelle version stable (Jaunty). Je vous propose le test qui survole les nouveautés de cette version afin de vous donner un aperçu rapide.

L'apport de nouveautés est un peu moins important que son prédécesseur, mais propose tout de même beaucoup de bonnes choses. Ayant l'occasion de travailler énormément avec Ubuntu dans mon environnement professionnel, J'ai pu tester cette nouvelle version sur différentes configurations en utilisant différents médias d'installation.

Pour rappel, Ubuntu Jaunty 9.04 contient : noyau 2.6.28, Gnome 2.26, Brasero 2.26, Xorg 7.4 (Xserver 1.6, DRI2), KDE 4.2.2 (Kubuntu), XFCE 4.6.0 (Xubuntu), Firefox 3.0.9, GCC 4.3.3, glibc 2.9, nouveau système de notifications, améliorations de la vitesse de démarrage, support ext4 et intégration d'eucalyptus.
  • # my 2 cents

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

    suis passé d'une easypeasy (8.04) à cette 9.04 sur mon eeepc 901, et c'est très plaisant, ça marche tip top. Manquait juste un truc pour le support des activations/desactivations du wifi, webcam etc. Mais un paquet plus tard, ça roule.
    Dommage que l'installation de la version netbook ne fasse pas le nécessaire pour mettre des choses en tmpfs automatiquement (au moins le proposer), comme /tmp ou /var/log.
    • [^] # Re: my 2 cents

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

      question : quel paquet as-tu installé pour le support des activations/desactivations du wifi, webcam etc. ?
      Merci
      • [^] # Re: my 2 cents

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

        'eee-control'. C'est un peu la jungle de ce côté là... Je geek plus trop et j'ai du mal à isoler une solution parmis toutes celles dispos, qui semblent faire toujours la meme chose... Sur easypeasy, j'utilisais les script de elmurato, et ça marchait, mais y'avait des petits bugs:
        - premier boot, y'avait tjrs un (très) long délai avant traitement des première requêtes. Genre tu boot, tu demandes "wifi off", et t'as le message en OSD qui apparait 30s plus tard (et le wifi n'est pas off avant 30s)
        - réactivation wifi devait se faire avec un cycle on/off/on. Le 1er on ne marchant pas (message d'erreur lors du chargement du module).

        Du coup, me suis dit que j'allais testé autre chose cette fois. eee-control fourni en plus une applet pour activer/desactiver en cochant dans une liste, une petite iface pour choisir quoi faire des boutons (genre Fn+F5, Fn+F6, les 4 boutons en haut, ...).

        Après, pour la conso, c'est vague... D'après ce que j'ai compris, certains scripts savent gérer le changement de FSB, du voltage, etc. Et là, ben j'ai pas réussi à comprendre qui faisait quoi. Je crois que eee-control gère fsb et voltage... Ma batterie 6600 semble faire 4/5h donc ça me va.

        Tout ça pour dire que j'avais un peu peur de mettre une 9.04 direct sur mon eeepc, mais finalement, c'est chouette, tout marche directement (en tout cas sur mon 901).
        • [^] # Re: my 2 cents

          Posté par . Évalué à 2.

          Le wifi fonctionne en WPA2 ?? J'avais essayé la RC et ça ne passait pas ...
          • [^] # Re: my 2 cents

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

            pas eu l'occasion de tester, mon colloc et mon labo utilisant cette technologie ultra-moderne : le WEP /o\
    • [^] # Re: my 2 cents

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

      Le saut d'une version n'est pas supportée, non ?

      Normalement ce sont les passage d'une version à une autre ou les passages de LTS à LTS.. non ?
      • [^] # Re: my 2 cents

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

        j'ai réinstallé directement, j'ai pas fait de mise à jour. D'après certains qui ont tenté, le passage d'une distrib à l'autre par mise à jour sur un SSD de ce type (bouze), ça se compte en heureS. Vu que j'ai très peu modifié le système et que tout se trouve dans mon /home, j'ai réinstallé. Un peu pénible après car il faut réinstaller qqs paquets, mais rien de bien méchant.

        Pour le SSD, j'ai pas de mal à croire, car la simple copie d'une vidéo de 300Mo via ftp empeche le système de faire autre chose... La copie est rapide, mais je pense que tout fini en RAM et derrière, le SSD sort les rames. Je me sers de la commande "sync" pour savoir quand je peux commencer à regarder une vidéo après copie, et ça peut mettre facilement 30s parfois... Bref, c'est bien du caca quand même ces SSD pas chers. Mais à côté de ça, tip top !
  • # Probleme plasma-widget-networkmanager

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

    En fait, tu as surement du oublié d'installer kwalletmanager... Le plasmoid de kde ne fonctionne pas pour l'instant si il est désactivé.
  • # En avance, toujours en avance

    Posté par . Évalué à 4.

    Wouah, KDE 4.4.2 ! En avance sur son temps cette ubuntu, 1an d'avance sur les version de KDE. C'est la 4.2.2 je pense.
  • # Problème emesene avec musique courante Amarok

    Posté par . Évalué à 0.

    Salut à tous,
    je suis bien satisfait dans l'ensemble de ubuntu 9.04 mais j'ai deux problème qui m'irritent bien:
    1- Amarok 2 n'a plus (à priori) son onglet Wikipédia :@. J'avais choisi ce lecteur à la base sur ça et puis depuis j'en suis accro.
    Je ne comprends vraiment pas pourquoi canonical a choisi cette beta dans sa distro (avis perso vue les bugs et manque de fonctionnalités).

    2- Le paquet python-dcop a disparu de Jaunty du coup je n'est plus ma musique courante sur emesene et j'ai une erreur.

    Pouvez me trouver des solutions à ces problèmes SVP?

    Merci.
    • [^] # Re: Problème emesene avec musique courante Amarok

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

      Amarok 2 n'a plus (à priori) son onglet Wikipédia

      regarde dans la colonne centrale où (la pochette est affichée), il y a un petit + pour ajouter des éléments (dont la page Wikipédia).
    • [^] # Re: Problème emesene avec musique courante Amarok

      Posté par . Évalué à 2.

      Salut
      Sur amarok 2 je n'étais pas très enthousiaste, mais au final j'aime bien cette nouvelle ergonomie (bien que pas vraiment évidente au premier regard) le script pour les paroles a l'air d' être plus stable.
      Pour avoir le script wikipedia, c'est sur la partie central de l'interface (4 espaces dispo) sur l'une d'elle tu clic sur le + et le tour est joué.
      • [^] # Re: Problème emesene avec musique courante Amarok

        Posté par . Évalué à 3.

        Moi j'ai eu beau essayer je m'y fais pas à ce nouveau amarok. C'est non seulement pauvre en fonctionnalité mais ça n'est même pas beau, et puis c'est mal branlé l'ergonomie est tirée vers le bas.
        J'espère du mieux à l'avenir mais pour l'instant, désastre. De plus en plus de distrib passent au 2 par défaut, et de plus en plus de gens sur le net cherchent comment rester sur 1... J'en fais partie.
  • # C'est moi ou...

    Posté par . Évalué à 3.

    "J'ai installé deux stations en ext4 (votre /boot doit être sur une autre partition en ext2/3 pour que grub puisse en profiter)."

    Mon /boot est sur du ext4 et ca fonctionne.
  • # koacedonc ?

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

    C'est quoi Eucalyptus ? C'est presente comme si c'etait evident..
  • # Toujours aussi bien.. sauf que

    Posté par . Évalué à 6.

    [mode troll="off" ma-vie="1"]
    J'ai toujours été moyennement emballé par les debian-like, mais depuis que le héron m'a séduit j'ai abandonné lâchement Mandriva. Et tant pis si les commandes dpkg/select/apt/get/file/search/cache/bidule sont plutôt obscures pour le non initié.
    [/mode]

    Jusque là, quelle que soit la version, tout marchait plutôt bien, net, musique, vidéos, TV, TNT, 3D, tablette wacom, scanner, imprimante espon et brother, souris high-tech, graveur, onduleur... tout nickel.

    Mais je suis tombé sur un os, car j'ai un disque en raid software et il y a le bug là :

    https://bugs.launchpad.net/ubuntu/+source/hal/+bug/361689

    HAL qui crashe, un bug mineur de rien du tout, et hop, tout le système tombe par terre.
    ça rend le système tout bonnement inutilisable.

    Heureusement ma grand-mère (86 ans) n'est pas tombée sur ce genre de bug, parce que pour un non informaticien, impossible de s'en sortir... c'est tout de même comparable à un windows qui blue-screen-of-death au démarrage après une update (souvenez-vous, ça faisait ça avec NT).

    A part ça, ben jaunty marche plutôt bien ! Mais ptet que canonical pourrait embaucher des ingénieurs test/qualité supplémentaires ? :-)
    • [^] # Re: Toujours aussi bien.. sauf que

      Posté par . Évalué à 4.

      Avec l'argent que tu leur as versé ? Enfin peut-être as-tu acheté du support je suis mauvaise langue...

      Non sérieusement. C'est un logiciel libre. Alors pour plus de test il suffit que plus de gens téléchargent/installent la beta avant la sortie (de préférence en dual-boot pour éviter de se retrouver sans système le jour ou un bug survient et qu'on doit terminer un rapport urgent...).
      Et surtout que ces gens fassent des rapports de bug précis et suivent leur rapport... Oui c'est du boulot et personne n'y est contraint. Dans le libre on peut aussi juste en profiter sans rien faire, sans rien payer, et sans être jugé. Mais alors évitons de critiquer en demandant qu' "ils" embauchent plus... et qu' "ils" bossent plus...

      Merci à tous ceux qui investissent de leur temps et à ceux qui en profite, soit qui valorisent le travail des premiers.
      • [^] # Re: Toujours aussi bien.. sauf que

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

        En même temps, ça fait déjà un certain nombre d'années que le tout bénévole est révolu. Bien qu'utilisateur d'Ubuntu, autant je ne dirai rien contre Red Hat, qui a un chiffre d'affaire de plusieurs centaines de millions de dollars, plus de 2200 employés et contribue énormément à l'écosystème libre, autant Cannonical / Ubuntu, bien qu'ayant moins de revenus et d'employés, on ne les a jamais vu contribuer à quoi que ce soit. Donc oui, ça ne serait pas du luxe qu'ils emploient enfin des développeurs pour bosser sur certains projets utilisateur.

        Je me souviens par exemple d'Hardy, qui avait inclut PulseAudio et gvfs, tous deux à moitiés terminés, ce qui donnait un produit bancal avec un manque flagrant de finition. Plutôt que de laisser Alexander Larsson (employé par Red Hat) bosser tout seul sur gvfs, ils auraient pu payer un développeur pour l'épauler, histoire qu'on ai droit à quelque chose d'un peu plus fonctionnel. D'ailleurs, trois versions plus tard et malgré mes rapports de bugs sur le backend ftp de gvfs (l'impossibilité de supprimer des répertoires contenant certains caractères, la taille des fichiers qui bloque à 4 Go même s'ils en font 12...), ça n'a guère évolué.

        Plutôt que de perdre de l'argent avec Ship It (leur service pour commander des CD gratuitement) en autorisant tous les pays, y compris ceux qui ont de super connexions et de nombreux magazines qui proposent des CD (en gros, réserver le service au tiers monde), ils auraient mieux fait d'embaucher des développeurs pour Gnome et les drivers.
        • [^] # Re: Toujours aussi bien.. sauf que

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

          > autant Cannonical / Ubuntu, bien qu'ayant moins de revenus et d'employés, on ne les a jamais vu contribuer à quoi que ce soit.

          Ohh. Joli, mais 3h16 en avance, ton troll.
          Ubuntu a une contribution *majeure*: ça a rendu GNU/linux à plus de monde qu'aucune autre distribution en un temps record. Certains ont aimé et y sont resté, d'autres on migré vers d'autres distributions (ou OS).
          Rien que ça, selon moi, c'est une contribution valable. Et ce n'est pas à toi de leur dire "au lieu d'offrir des CDs, embauchez des gens". C'est leur gestion, et elle ne cause pas de tort.

          Au fait, selon toi, le tiers-monde contient-il le Royaume-Uni, avec ses débits internet de merde et sa vie hors de prix (y compris la littérature linux) ?
        • [^] # Re: Toujours aussi bien.. sauf que

          Posté par . Évalué à 3.

          on ne les a jamais vu contribuer à quoi que ce soit

          Normalement, Launchpad va être totalement libre en Juillet cette année, c'est un gros truc quand même. Et la communauté remonte un gros tas de bugs (même si évidemment ces bugs ne sont pas sur les versions de développement). Je trouve que la mise à disposition d'une base gigantesque pour tester les logiciels et les paquets Debian, c'est une forme de contribution au libre.
          • [^] # Re: Toujours aussi bien.. sauf que

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

            Ça fait des années qu'ils promettent de libérer Launchpad, alors je préfère attendre de voir du concret avant de les remercier de leur contribution. Quant aux bugs, je pense que ça serait plus productif pour les deux parties (distribution et projet) qu'ils soient rapportés upstream.

            Parce que pour le moment, j'ai l'impression que de nombreux bugs rapportés sur Launchpad ne sont pas remontés. Les projets concernés ne vont pas s'amuser à suivre les rapports de bugs de toutes les distributions, et comme Cannonical n'a pas vraiment de véritables développeurs pour corriger les bugs relatifs à Gnome et compagnie, ça ne sert pas à grand chose.

            L'idéal, ça serait que les gens arrivent à distinguer un bug propre à la distribution d'un bug qui concerne directement le logiciel, mais c'est pas gagné.
            • [^] # Re: Toujours aussi bien.. sauf que

              Posté par . Évalué à 4.

              j'ai l'impression que de nombreux bugs rapportés sur Launchpad ne sont pas remontés.

              Je pense que c'est injuste de dire ça. Launchpad a la capacité de s'interfacer avec beaucoup de systèmes de rapports de bugs upstream, ce qui lie physiquement les deux rapports de bugs. Regarde par exemple pour un projet Gnome comme evolution : https://bugs.launchpad.net/ubuntu/+source/evolution . J'ai cliqué sur les 5 premiers bugs, et les 5 sont bien liés à des bugs reportés upstream (après, ça ne veut pas dire que le bug a été d'abord signalé sur Ubuntu). Je ne vais pas faire des stats, mais je n'ai pas réussi à trouver un seul bug majeur ou normal pour evolution qui n'est pas aussi présent upstream.

              Bien entendu, les devs de Gnome ne veulent pas nécessairement des rapports de bugs sur les versions stables (je me suis déja fait mordre chez Gnome, quand tu remontes un bug ils voudraient que tu le vérifie en compilant le svn, je comprends leur point de vue mais franchement, faut être totalement allumé pour compiler soi-même une version de développement de Gnome).
            • [^] # Re: Toujours aussi bien.. sauf que

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

              L'idéal, ça serait que les gens arrivent à distinguer un bug propre à la distribution d'un bug qui concerne directement le logiciel, mais c'est pas gagné.

              Ça risque d'être difficile surtout que les distributions patch les logiciels ou compil sans le support de tel truc. Du coup, si l'utilisateur doit lire le diff des sources pour savoir où est le problème, on n'est pas sauvé.

              « 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: Toujours aussi bien.. sauf que

            Posté par Anonyme . Évalué à 3.

            Oui mais bon launchpad c'est un peu fondé sur un truc qui ne va servir que a launchpad... bazaar. Peut être que git et mercurial fonctionneront un jour avec mais ce n'est pas le cas actuellement et cela va être bloquant pour pas mal de monde à mon avis.
      • [^] # Re: Toujours aussi bien.. sauf que

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

        C'est un logiciel libre. Alors pour plus de test il suffit que plus de gens téléchargent/installent la beta avant la sortie

        Je suis d'accord sur le fond, mais pour bêta-tester, il faut avoir un PC supplémentaire disponible ou aimer prendre des risques. Les tests dans un machine virtuelle ne suffisent pas lorsque des problèmes de matériel sont en jeu.
        Par exemple, dans mon cas, la mise à jour vers Jaunty s'est mal passée : au redémarrage, après le menu GRUB, j'avais juste un message d'erreur incompréhensible et une invite de commande BusyBox.
        Pour une raison inconnue, ma partition racine n'était plus reconnue.

        Pour préciser, il ne s'agit pas de matériel récent : carte mère avec Pentium IV, disques durs IDE, etc... Tout fonctionnait sans problème sous Intrepid.

        Lorsque des versions dites stables produisent ce genre d'effet, on peut devenir réticent à installer des versions bêta.
    • [^] # Re: Toujours aussi bien.. sauf que

      Posté par . Évalué à 3.

      HAL qui crashe, un bug mineur de rien du tout, et hop, tout le système tombe par terre.
      ça rend le système tout bonnement inutilisable.
      [...]
      A part ça, ben jaunty marche plutôt bien ! Mais ptet que canonical pourrait embaucher des ingénieurs test/qualité supplémentaires ? :-)


      On ne peut pas tout avoir :
      - une distrib mise à jour tous les 6 mois
      - les derniers logiciels
      - un truc avec assez de recul, càd assez testé et qui a pu être corrigé.

      Ubuntu vise plus à remplir les deux premiers objectifs, Debian le dernier.
      (Mais évidemment, un logiciel complètement exempt de bug n'existe pas)
      • [^] # Re: Toujours aussi bien.. sauf que

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

        Entre sortir une distrib exempté de bugs et laisser passer des bugs majeurs, il y a quand même de la marge. Sans parler de l'inclusion de technologies à moitié finies (PulseAudio et gvfs en leur temps), il y a également les régressions. Dans Jaunty, par exemple, suite à l'abandon de disk-manager par son unique développeur et le fait que ce dernier contenait un peu trop de bugs, Ubuntu a décidé de le virer des dépôts. D'un point de vu qualité, effectivement, il est préférable de ne pas proposer un projet instable. De l'autre côté, le programme était utilisé par beaucoup de débutants rebutés à l'idée de devoir éditer le fstab à la main. Ils auraient pu mettre un développeur sur le coup pour reprendre le projet, ou en développer un autre. Non, ils se sont contentés de le virer, sans proposer la moindre alternative. C'est donc une régression. Et malheureusement, ça arrive souvent.

        Le gros problème d'Ubuntu, c'est qu'ils se reposent trop sur les autres, en reprenant leur travail, sans jamais contribuer.

        Un peu comme le site http://brainstorm.ubuntu.com qu'ils ont ouvert. C'était une très bonne idée, mais comme ils n'ont aucun développeur et qu'ils ne comptent pas travailler sur les bonnes idées qui ont pu émerger de ce site, ça ne sert finalement strictement à rien.
        • [^] # Re: Toujours aussi bien.. sauf que

          Posté par . Évalué à 3.

          Sait-on vraiment combien de dev travaillent officiellement sur Ubuntu? Une distribution est avant tout un problème de tests et d'intégration, j'imagine que les dev travaillent avant tout sur la cohérence des paquets, la correction des bugs à l'installation, à l'upgrade, etc. Les bugs dans les logiciels sont remontés upstream, et upstream en fait ce qu'il veut : on ne peut pas vraiment demander à Canonical de s'impliquer dans chaque projet, quand même. Il serait intéressant de savoir exactement combien de devs bossent pour Canonical, et ce qu'ils font. Il y a forcément des gens à plein temps sur la gestion des bugs, c'est d'autant plus nécessaire que la plupart des rapports de bugs nécessitent beaucoup de boulot (vu le public visé par la distro, les rapports sont de faible qualité, et beaucoup doivent être classés sans suite).

          Après, c'est clair que Canonical n'a pas les moyens de ses ambitions. Sortir une version tous les 6 mois représente un boulot monstrueux, et la qualité de la distribution n'est pas toujours au rendez-vous; la plupart du temps, la version qui sort fonctionne à peu près correctement sur la majorité des machines, mais dans le détail, c'est pas très propre. Mais bon, personne ne sait comment Canonical fait du pognon, on ne sait même pas s'ils en font vraiment, donc ça me parait délicat de demander quoi que ce soit en terme de contributions: leur boulot c'est de faire une distrib qui marche, ils essayent de le faire avec les moyens qu'ils ont et selon leur politique que personne ne comprend vraiment.
          • [^] # Re: Toujours aussi bien.. sauf que

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

            Généralement, ce qui est fait sur la gestion des bugs c'est de faire appel aux "utilisateurs avancés" de la distribution (cela n'intéresse que peu les développeurs généralement qui désespèrent des rapports de bugs non qualifiés de certains utilisateurs qui confondent le bugzilla et les forums, oubliant bien souvent de se greffer sur un bug existant pour le compléter).

            Il y a des squash bugs party dans la plupart des distributions (genre un week-end pendant la phase d'alpha ou bêta) permettant de former des personnes à l'utilisation des outils et effectuer les relances des utilisateurs pour tests, éventuellement remonter upstream pour faire s'intéresser les développeurs au bug qualifié.
            Monter ce genre d'équipe interface entre l'utilisateur, les développeurs et l'upstream permet d'augmenter la qualité des remontées et des diagnostics (à défaut de proposer des patchs directement pour l'upstream) et c'est la valeur ajoutée de la plupart des distributions (pour éviter que l'upstream croule sous des rapports de bugs de versions obsolètes - selon eux - notamment).
            J'ose espérer que cela fonctionne bien chez Ubuntu vu la base d'utilisateurs ;-)

            Toute la difficulté est surtout que les utilisateurs ont la version stable et non celle en développement (que ce soit au niveau logiciel ou au niveau distribution), ce qui ne motive àmha ni développeurs de la distrib' ni l'upstream.
            J'ai tout de même l'impression que dans la communauté du libre (au sens large), il nous reste un gros effort à faire pour démocratiser les bonnes pratiques de développement et proposer des process documentés plutôt qu'ad'hoc afin que tout le monde s'y retrouve :
            - faire que l'upstream pense plus au "release early, release often" (seuls les logiciels majeurs sont en version svn dans les distribs), estampiller une version svn comme suffisament stable et la publier (en version mineure par exemple) permet d'avancer plus vite et promeut l'intégration dans les distribs qui n'ont pas non plus le temps de suivre chaque commit.
            - faire que les utilisateurs et utilisateurs avancés pensent à "comment reproduire le bug" et est-il reproductible dans une version plus récente de l'upstream pour pousser les dévs de la distrib' à monter de version
  • # Config minimale

    Posté par . Évalué à 1.

    Bonjour,

    Je pense qu'ils devraient revoir la config minimale pour faire tourner Kubuntu 9.04.

    Je suis passé d'une Kubuntu 8.04 (KDE 3.5) à une Kubuntu 9.04 (KDE 4.2.2) avec un Athlon 1700+ et 2GB de RAM.

    Je précise que j'en ai profité pour faire une réinstallation complète qui s'est d'ailleurs bien passée (récupération de quelques GB de mails sous Thunderbird et de tout mon environnement sous Firefox).

    Autant K8.04 (pourtant surchargé de plein d'applications installées, de serveurs qui tournaient, de mises à jour successives, etc.) tournait parfaitement, autant K9.04 rame, le processeur étant très souvent à 100%, XOrg prenant beaucoup de temps CPU.

    Du coup, je me demande quoi faire.
    C'est utilisable mais limite.
    Je ne peux pas utiliser les avantages de la nouvelle interface graphique de KDE 4.

    - Sois je persévère en jouant sur les options (je Twick),
    - Soit je change mon "vieux" PC qui pourtant marchait très bien et à l'avantage d'être très silencieux. Il me faudra donc en trouver un autre très silencieux, voire 0db.
    - Soit je passe sous Xubuntu 9.04 sur lequel je lancerais mes applis KDE...

    Si vous avez des conseils.

    Et pour ce qui est de ma carte graphique ATI Radeon 7000, il va là aussi falloir que je Twick la config XOrg comme je l'avais fait sur ma précédente install car ce que j'ai par défaut est limite utilisable : écran pas centré, résolution basse, fréquence de rafraîchissement faible. J'ai été déçu de ne pas trouver de moyen de configurer ça via le tableau de configuration.

    zFlorent
    • [^] # Re: Config minimale

      Posté par Anonyme . Évalué à 2.

      La première chose à faire c'est de fermer strigi si il est lancé. C'est un logiciel connu pour bouffer du CPU et tomber en boucle si il y a un fichier tar.gz ou tar.bz2 par exemple... Cela devait être théoriquement réglé avec kde4.2 mais connaissant le packaging kubuntu il est fort possible que le bug soit encore présent...
      • [^] # Re: Config minimale

        Posté par . Évalué à 1.

        J'ai regardé. Strigi est bien installé mais ce n'est pas lui qui semble prendre du temps CPU.

        En faisant des recherches sur internet, je m'oriente plus vers l'interface 3D de KDE 4.2.2 qui n'utiliserait pas bien la puissance de ma carte graphique ATI Radeon 7000.

        Il va me falloir faire des essais de drivers libres/propriétaires dans les dépôts/propriétaires dernière version.
        Et sinon, désactiver les effets 3D. Déjà commencer par ça, pour valider l'hypothèse.

        A suivre...
        zFlorent
        • [^] # Re: Config minimale

          Posté par Anonyme . Évalué à 2.

          Ouh la ATI et kwin+3D cela fait très mauvais ménage actuellement. Il y a un gros bug dans xorg 1.6 et les drivers ati libres (enfin cela s'oriente entre autre vers cela) donc bon courage sur le sujet... Vivement l'année prochaine pour avoir enfin un xorg qui se vautre pas toutes les 30 secondes...
          • [^] # Re: Config minimale

            Posté par . Évalué à 3.

            Juste pour archive : j'ai eu de très gros pépins avec la 3D et ATI sur Jaunty. Genre impossible de lancer une application OpenGL "réelle" (comprendre: glxgears marche très bien merci) sans un blocage total du système dans les trois minutes qui suivent. Ceci avec une Radeon X1650 et le pilote libre, que j'utilisais déjà sur Intrepid et qui marchaient raisonnablement (pas au point d'accepter le compositing ET les applications OpenGL, mais faut pas trop en demander). Donc _grosse_ régression.

            Et puis, après avoir essayé des tas de trucs divers sans succès, j'ai bêtement choisi mon ancien noyau (2.6.27 au lieu de 2.6.28) dans Grub. Et là, miracle, tout remarche comme sur Intrepid. Ni mieux, ni pire. Juste pareil. Ce qui plantait avant plante toujours. Les avertissements liés au module 'drm' de temps en temps (un truc à propos de r300_scratch, de mémoire) sont toujours là. Mais bon sang, qu'est ce que ça fait du bien ;)

Suivre le flux des commentaires

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