Journal De l'utilité de Xubuntu

Posté par  (site web personnel) .
Étiquettes :
0
15
oct.
2007
Aujourd'hui j'ai lu cette longue présentation des nouveautés de Xubuntu 7.10 : http://xubuntublog.wordpress.com/2007/10/14/this-is-gutsy/

A la fin de la lecture on en vient à se demander à quoi sert vraiment Xubuntu.
Le but d'origine était d'utiliser le bureau XFCE afin d'avoir une distribution plus légère que la Ubuntu classique basée sur Gnome. C'est clair, c'est simple, c'est précis et surtout c'est légitime.

Pourtant qu'est ce qu'on découvre lors de la lecture de cette présentation de la future Xubuntu ?

1) Xarchiver est viré au profit de l'outil standard Gnome (File-roller)
2) Gxine est viré au profit de l'outil standard Gnome (Totem)
3) Xfburn est viré au profit de Brasero
4) xfce4-taskmanager est viré au profit de l'outil standard Gnome (System monitor)
5) Ajout de tous les jeux de Gnome-games (17 jeux !)

Nom d'un chien mais pourquoi dénaturer ainsi Xubuntu ? Personnellement je m'en fiche car j'utilise une Ubuntu classique et j'aime Gnome....mais j'imagine l'amertume des supporteurs d'XFCE !
Outre le fait que la fameuse légèreté va peut-être en prendre un coup on ne comprends plus bien à quoi sert Xubuntu si elle intègre ainsi pleins de morceaux de Gnome. Les gens vont se dire "Si c'est presque pareil autant prendre l'original".
Est-ce un moyen détourné de la part de Canonical de réduire la charge de travail que représente cette variante de la distro principale ?
Je suis perplexe.

  • # Plop

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

    Encore un coup de ces maichants modérateurs de tribune! Ah les rascals ;*)

    La gelée de coings est une chose à ne pas avaler de travers.

  • # De toute façon...

    Posté par  . Évalué à 1.

    ...XFCE est déjà basé sur des composant de GNOME.

    GTK par exemple.
    http://packages.debian.org/etch/xfce4
    ....

    et d'autre part, la plus part des utilisateurs de Xubuntu (moi pour ne pas me citer) s'empressent de réinstaller certains composants de GNOME qui sont bien utiles: gnome-power-manager, nm-applet...
    Il doit certes y avoir une perte en terme de puissance, mais négligeable car je gagne toujours environs 5min de batterie entre une utilisation sous GNOME et sous XFCE...

    Donc voilà, je pense que les gens de Xubuntu se contentent d'écouter ce que la pluspart de leur utilisateurs leur disent... même si je conçoit tout à fait qu'il y a de quoi faire se retourner de nombreux puristes dans leur tombes (en même temps fallait pas choisir Ubuntu, si t'es puriste).

    • [^] # Re: De toute façon...

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

      XFCE et Gnome sont basés sur des composants identiques, c'est complétement différent.

      GTK signifie Gimp ToolKit et n'a rien à voir avec Gnome...

      Pour avoir travaillé sur l'indépendance de Grisbi vis à vis de Gnome, je suis effectivement d'avis que c'est regrettable d'avoir changé des applis XFCE au profil de leur équivalent Gnome...

      Chargé les libs Gnome en mémoire... pour ne pas l'utiliser par la suite, c'est vraiment regrettable...

      Axel

      • [^] # Re: De toute façon...

        Posté par  . Évalué à 10.

        GTK signifie Gimp ToolKit et n'a rien à voir avec Gnome...

        Que tu crois...

        Va falloir m'expliquer la boite de dialogue d'enregistrement et d'autres détails qui suivent la politique de gnome sur les interfaces. L'infame boite de dialogue fait bien partie de GTK, pas de Gnome.
        Que ça soit clair, GTK est développé par une grande partie de développeurs Gnome.

        Bien qu'il ai commencé sa vie en tant que le GIMP toolkit, il n'en a plus que le nom. C'est aujourd'hui le composant GUI de Gnome, et bien qu'il puisse etre utilisé par d'autres applications sans charger les autres libs d'un environnement Gnome complet, il reste que GTK c'est quasiment une part de Gnome maintenant. Voir aussi project ridley :
        Project Ridley is an effort to consolidate a number of external libraries into GTK+.

        These libraries are generally small, undermaintained, and buggy. They have an unclear mission (such as libgnome and libgnomeui) or would benefit by being in GTK+ (such as libgnomeprint and libgnomeprintui.)

        Rien à voir avec la relation QT/KDE par exemple où les développeurs KDE font dériver quasiment toutes les widgets de base et les étendent dans les kdelibs. La boite d'enregistrement de KDE n'est pas celle de QT. Il existe un QFileDialog chez QT et un KFileDialog chez KDE, par exemple.

      • [^] # Re: De toute façon...

        Posté par  . Évalué à 3.

        > GTK signifie Gimp ToolKit et n'a rien à voir avec Gnome...

        Pourtant il me semble que c'est massive utilisé par Gnome et principalement (pour ne pas dire exclusivement) développé par Gnome.
        Sinon oui GTK signifie Gimp ToolKit et GTK a ses origines dans le projet Gimp. Merci Gimp.

        > Chargé les libs Gnome en mémoire... pour ne pas l'utiliser par la suite, c'est vraiment regrettable...

        Le lib ne sont chargées que si tu les utilises. Et n'est chargé que la partie de la lib que tu utilises. Idem pour les exécutables. N'est chargé que s'il faut excécuter le code. C'est cette "feature" qui permet d'avoir le splash screen très tôt.

    • [^] # Re: De toute façon...

      Posté par  . Évalué à 10.

      Attention ! GTK ne fait pas parti de GNOME. GTK est un toolkit graphique (au même titre que Qt), et il est utilisé à la fois par GNOME et XFCE ... et par une multitude de projets ne dépendant ni de GNOME ni de XFCE.

      Donc, dire que XFCE est basé sur des composants GNOME, c'est faux :)

      • [^] # Re: De toute façon...

        Posté par  . Évalué à 6.

        <troll>
        Ouaip, je connais même des applis qui tournent sous Windows sans avoir Gnome installé dessus...
        </troll>

        <gnin hin hin>
        gnin hin hin
        </gnin hin hin>

      • [^] # Re: De toute façon...

        Posté par  . Évalué à 4.

        Enfin, Gnome et XFCE ne sont pas égaux face à GTK
        Des composants GNOME sont intégrés dans GTK, il n'y a pas encore eux de cas similaire pour XFCE.

        De façon institutionnel, GTK est pratiquement un des composants de GNOME, il s'appuie sur l'infrastructure du projet GNOME pour son développement: http://live.gnome.org/GtkTasks

        D'autres projets l'utilise, certe. Mais le lien GTK<->GNOME est plus fort que le lien XFCE<->GTK

      • [^] # Re: De toute façon...

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

        Pourtant, les fichiers sources de GTK sont intégralement versionnés dans les dépôts SVN de GNOME.

  • # XFCE est-il encore léger?

    Posté par  . Évalué à 5.

    Je suis passé sur une machine basique (PIII-450MHz 320MB de RAM)de IceWM à XFCE pour voir, pour avoir plus de fonctionalités, et parce qu'IceWM était un peu largué.

    J'ai été plutôt déçu par sa légèreté : il démarre assez lentement pour que je m'en aperçoive, et la gestion des fenêtres (mouvements, redimensionnements) me semble moins rapide. Par contre c'est bien plus beau, alors je l'ai gardé ;^)

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: XFCE est-il encore léger?

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

      Moi j'ai eu une experience vraiment horrible de xfce (avec xubuntu feisty):
      sur un PII 266Mhz avec 228Mo de RAM, xfce etait purement et simplement utilisable, des que je déplacais une fenêtre j'en avais pour plusieurs secondes, je parle meme pas des alt-tab, la seule application presque utilisable était firefox ! (ce qui m'epatte venant de sa part)
      Depuis j'ai installé kde, et ben euh ... c'est parfaitement utilisable !
      Alors bon évidement je suis encore loin de mon athlon 2500+, mais à part sur certaines pages web (aie aie aie le flash, ou ebay (lui fait ramer comme pas permis pour une raison qui m'échappe)), je sens pas vraiment de différence...
      Bon evidement pour lire des vidéos je dépasse pas le demi QVGA en autre chose que le mpeg2 (pour lire des vidéos vga en qvga,ffmpeg fait un tres bon boulot d'ailleur), m'enfin ca fait un format type youtube normal, pas joli joli mais pas à faire vomir, donc tout ca pour dire que XFCE, léger ? Mon oeil !

      • [^] # Re: XFCE est-il encore léger?

        Posté par  . Évalué à 3.

        Sur un g3 300Mhz (donc bien plus rapide quand même), mais avec 96mo de ram, xfce est utilisable (avec firefox aussi). Donc, ça sais être léger xfce.

        Envoyé depuis mon lapin.

    • [^] # Re: XFCE est-il encore léger?

      Posté par  . Évalué à 2.

      Pour le xfce plus beau que icewm, je ne sais pas.

      Il est possible de mettre un fichier .gtkrc2 dans ton dosseir perso et cela personnalise vraiment bien les applis gtk qui sont dans icewm. Si tu ajoutes un theme que tu crées toi même, il n'y a plus une si grande différence en terme de "jolie".

  • # Surtout pour éviter l'infâme bloat de mono

    Posté par  . Évalué à 3.

    XFCE, pour ma part, est surtout le seul moyen d'avoir un bureau "officiel" basé sur GTK+ SANS cet m.... de bloat de mono. (Bon y a gentoo avec le mono use flag, mais les users lambda avec leurs distros basées sur des packages binaires sont n... bin ouaip...).
    Gnome part en vrille, je suis dégouté mais bon, je ne perds pas espoir.

    • [^] # Re: Surtout pour éviter l'infâme bloat de mono

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

      rien ne t'empêche de supprimer mono et les quelques applis qui en dépendent.

      A part tomboy y'a quoi d'autre qui l'utilise ?

      Mais bon à part ça mono n'est pas plus un bloatware que perl, python, java ou ruby. Je trouve ta démarche à la fois curieuse et peu cohérente.

      • [^] # Re: Surtout pour éviter l'infâme bloat de mono

        Posté par  . Évalué à -2.

        Je veux que les gens puissent *installer* optionnellement mono et ses logiciels, pas qu'ils puissent *désinstaller* optionnellement mono et ses logiciels. Donc je voudrais qu'ils puissent installer *optionnellement* tomboy, donc mono.
        Je ne tolère pas plus ORCA écrit en python pour gnome "officiel" qui me donne de l'urticaire également, même si je tolère plus python que mono:
        perl/python/ruby sont des plateformes basés sur des langages dynamiques, conçus pour avant tout pour faciliter la distribution de code sources, à ne surtout pas confondre avec java/C# qui sont à compilation statique conçus avant tout pour la distribution de byte code. Et je ne parle pas de la controverse sur mono/C#.
        Si tu trouves ça incohérent, ou plutôt que les tenants et aboutissants t'échappent... ché po... laisse tomber l'informatique...

        • [^] # Re: Surtout pour éviter l'infâme bloat de mono

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

          Ben sur ma debian j'ai fait un apt-get install gnome-desktop-environment et je n'ai ni Orca, ni Mono ...


          Paquet : gnome-desktop-environment
          Dépend: gnome-core (= 1:2.18.3.1), alacarte (>= 0.11.3), bug-buddy (>= 2.18.1),
          dmz-cursor-theme, ekiga (>= 2.0.3), epiphany-browser (>= 2.18.2) |
          gnome-www-browser, esound, evince (>= 0.8.1), evolution (>= 2.10.2),
          evolution-data-server (>= 1.10.2), fast-user-switch-applet (>= 2.18.0),
          file-roller (>= 2.18.3), gcalctool (>= 5.9.14), gconf-editor (>=
          2.18.0), gdm (>= 2.18.2), gnome-backgrounds (>= 2.16.2), gnome-about
          (>= 2.18.2), gnome-games (>= 1:2.18.1), gnome-keyring-manager (>=
          2.18.0), gnome-media (>= 2.18.0), gnome-netstatus-applet (>= 2.12.1),
          gnome-nettool (>= 2.18.0), gnome-power-manager (>= 2.18.3),
          gnome-screensaver (>= 2.18.2), gnome-system-monitor (>= 2.18.2),
          gnome-system-tools (>= 2.18.1), gnome-themes (>= 2.18.1),
          gnome-user-guide (>= 2.18.1), gnome-utils (>= 2.18.1),
          gnome-volume-manager (>= 2.17.0), gstreamer0.10-plugins-base (>=
          0.10.7), gstreamer0.10-plugins-good (>= 0.10.3), gstreamer0.10-tools
          (>= 0.10.8), gucharmap (>= 1.10.0), gtk2-engines (>= 2.10.2),
          libgnome2-perl, libgnomevfs2-bin (>= 2.18.1), libgnomevfs2-extra (>=
          2.18.1), nautilus-cd-burner (>= 2.18.2), seahorse (>= 1.0.1),
          sound-juicer (>= 2.16.4), totem (>= 2.18.2), vino (>= 2.18.1), zenity
          (>= 2.18.2)

          • [^] # Re: Surtout pour éviter l'infâme bloat de mono

            Posté par  . Évalué à 1.

            Oh!
            Debian a réagi?? Ça ressemble à une super bonne nouvelle.
            Bon, je ne suis pas rentrer dans le détails, mais en effet il semble que Debian ne s'est pas fait avoir. En tout cas si en sid ils sont rester du côté claire de la force... je sens que je vais me mettre à installer à nouveau des desktop debian gnome... mais alors, et Ubuntu dans l'affaire, ils suivent? La dernière fois que j'ai regardé ct pas brillant sur ce point là...

        • [^] # Re: Surtout pour éviter l'infâme bloat de mono

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

          Ah bah si tu toléres pas, forcement, c'est une raison puissante, je vais de ce pas aller modifier toute les distros du monde devant ta demande de non tolérance.

          Il est évident que toi, connaissant l'informatique et les nombreux besoins des gens, a déja des alternatives en tête et des idées sur comment agencés différement les distributions, et que tu as également déja du code à proposer pour remplacer celui qui te géne, avant de finalement, et avec un brio digne de Chuck Noris, réussir à convaincre que les gens qui ont choisi de faire du python ou du c# qu'ils feraient mieux d'aller faire pousser des fleurs en Corréze, car visiblement, ils n'ont pas ta compréhension des tenants et aboutissants.

          Et sinon, pour le cas ou ça semble pas évident, c'est de l'ironie. Je pense que les codeurs sont libres d'utiliser les languages de leur choix ( c'est ça aussi la liberté ), et pour avoir fait du C et du python sur des projets à peu prés similaires ( clients jabber ), je prefere quand même le python.

          Ensuite, les distributeurs sont également libre de choisir les applis et les features par défaut, et avoir un systéme nu comme xp avec la possibilité d'installer aprés, c'est assez nulle. Parce que si tu veut avoir un meilleur produit qu'un concurent, il faut simplement faire mieux. Et avoir un systéme qui marche out of the box avec tout ce qu'il faut, c'est simplement la volonté de faire mieux que les autres.
          Et si les gens estiments qu'une appli pour prendre des notes installé par défaut est plus importante que ton manque de tolérance , ben tu va devoir t'y faire.

          • [^] # Re: Surtout pour éviter l'infâme bloat de mono

            Posté par  . Évalué à -4.

            Toi, tu as loupé pas mal de marches:
            Est-ce que tu as vu comment s'est imposé cette bouse de mono dans gnome?
            Grosso modo, l'application sticky notes qui faisait très bien ce qu'elle faisait écrite en C et *simple* fut remplacé par l'autre truc qui fait le café et qui tire la dépendance du giga Kludge qu'est mono.
            La chose la plus intelligente aurait été de laissé sticky notes, et laisser le choix à l'utilisateur de bloater sont système si il éprouve le besoin de plus de "features" pour une application de prise de note. Je te raconte pas les frondes du Novell Blog system, qui règne en despote pas du tout éclairé sur la communauté gnome, sur tout ceux qui ont essayé de sauver gnome de cette abomination.
            Et puis perso, je préfère largement le python au c# (lua à l'aire pas mal: 1,1 Mo décompressé), mais si je peux le faire en C, je le fais en C et j'évite d'imposer le Kludge des frameworks de ces plateformes à mes communautés, car je suis un codeur libre, mais j'essaye de rester raisonné, car beaucoup oublient qu'ensuite il faut maintenir le tout, et plus c'est gros et complexe, plus c'est difficile et plus il faut de monde. D'ailleurs c'est une excellent méthode pour faire du faux libre: un gros giga Kludge que seul tes codeurs peuvent faire évoluer et maintenir... Mono et Java sont de beaux exemples pour Sun et Novell. Donc les codeurs libres qui piffent pas ça et qui ne veulent pas assumer, et bin je leur enverrai bien Chuck leur faire leur fête pour éviter qu'ils nous pourrissent nos desktops chéris avec leur cochonneries.

            • [^] # Re: Surtout pour éviter l'infâme bloat de mono

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

              euh...sticky notes est toujours fourni avec gnome. Le truc c'est qu'il est moins populaire que tomboy parce qu'il a moins de fonctionnalités. Donc que tomboy soit fourni par défaut avec gnome dans de nombreuses distributions a du sens.

              Est-ce que tu râles si les distrib fournissent konqueror ou firefox alors qu'on pourrait se suffire de w3m pour aller sur internet ?

              Si tu n'aimes pas mono/tomboy, ne l'installes pas c'est aussi simple que ça. Rien ne t'interdit d'installer gnome sans lui.

              • [^] # Re: Surtout pour éviter l'infâme bloat de mono

                Posté par  . Évalué à 1.

                "sticky notes est toujours fourni avec gnome": ah bon? Bien entendu il est aussi accessible que son kludge d'alter ego?
                "il est moins populaire": bah c'est comme MSN. Il est mis en avant agressivement, les users lambda ne verront que lui et forcément ils l'utiliseront avant tout. Belle façon d'acquérir de la popularité!
                "Est-ce que tu râles si les distrib fournissent konqueror ou firefox alors qu'on pourrait se suffire de w3m pour aller sur internet ?" Bien sûr, c'est vrai que la complexité d'une application de prise de note est comparable à la complexité d'un navigateur internet moderne... bien qu'on est des super codeurs "libres" capable de le faire!
                "Si tu n'aimes pas mono/tomboy, ne l'installes pas c'est aussi simple que ça. Rien ne t'interdit d'installer gnome sans lui." Les dernières fois que j'ai regardé, il était imposé par défaut, mais il paraît que Debian à capter le piège, maintenant il faut qu'Ubuntu suive (et les autres bien entendu).
                Donc pas d'affolement, ne t'inquiète pas, si on continue sur cette lancé, j'aurais bientôt plus à me plaindre...

        • [^] # Re: Surtout pour éviter l'infâme bloat de mono

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

          Je ne tolère pas plus ORCA écrit en python pour gnome "officiel" qui me donne de l'urticaire également, même si je tolère plus python que mono:
          perl/python/ruby sont des plateformes basés sur des langages dynamiques, conçus pour avant tout pour faciliter la distribution de code sources, à ne surtout pas confondre avec java/C# qui sont à compilation statique conçus avant tout pour la distribution de byte code.


          1) c'est faux : ce n'est pas parce qu'un langage est interprété qu'il est conçu avant tout pour distribuer les code sources.

          2) qu'un langage soit interprété, compilé ou qu'il exécute du bytecode sur une vm, je ne vois pas en quoi ça a un quelconque rapport avec le débat du droit/besoin/choix de l'installer par défaut sur une distrib ou avec un projet.

          • [^] # Re: Surtout pour éviter l'infâme bloat de mono

            Posté par  . Évalué à -1.

            "c'est faux": non c'est vrai. Pour le moment les langages comme le python/perl/ruby/lua/javascript etc... sont orientés vers la distribution des sources et non pas de byte code. Java/Mono le sont par contre. Et sérieux, en tant que libriste je préfère les sources au byte code...

            • [^] # Re: Surtout pour éviter l'infâme bloat de mono

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

              ce que je veux dire : la distribution des sources n'est pas leur raison d'être.

              Rien ne t'empêche de distribuer des sources, que ce soit pour du perl, du c ou du C#, c'est une question éthique, pas technique. Il n'y a que l'inverse qui n'est pas vrai pour un langage interprété.

              • [^] # Re: Surtout pour éviter l'infâme bloat de mono

                Posté par  . Évalué à -3.

                "ce que je veux dire": tu pourras dire tout ce que tu veux, mais cela n'empêchera pas que dans la majorité des cas les plateformes des vrais langages de haut niveau perl/python/lua/ruby... sont optimisées pour la distributions des sources et les kludges mono/java pour le byte code.

                Ché pas moi, va voir du côté de CPAN pour perl et dis-moi si ils distribuent *significativement* des modules en byte code perl. Le "setup" du python serait par défaut pour travailler avec du byte code python? Ou encore tu vas me dire que le déploiement des applications J2EE se fait à partir des sources?

                Si tu as saisis, tu comprendras que tout libriste un tant soit peu éclairé et pas trop neuneu verra l'arnaque comme le nez au milieu du visage.

            • [^] # Re: Surtout pour éviter l'infâme bloat de mono

              Posté par  . Évalué à 3.

              Tu vas pas aimer Parrot toi.
              En tant que "libriste", tu dois également abbhorer le C et les autres langages compilés ...

              Hein, le but premier du bytecode n'est pas d'obsfuquer le code mais d'avoir de meilleures performances.
              De plus, Mono ou la JVM permettent d'avoir un comportement similaire. Par exemple, si je code en Boo (un Python-like adapté à la CLI), j'ai le choix entre:
              * compiler en bytecode avec booc (Boo Compiler).
              * interpreter mon .boo avec booi (Boo Interpreter).

              • [^] # Re: Surtout pour éviter l'infâme bloat de mono

                Posté par  . Évalué à -2.

                T'es pas doué non plus toi:
                Le monsieur était dans le contexte du perl/lua/python/ruby/php et java/mono *tout court*.

                Si tu rajoutes le C... et bin... je les mets tous à la poubelle et je garde uniquement le C.

                Effectivement, je préfère les interpréteurs aux VMs pour les langages de hauts niveau, et donc je vois parrot d'un mauvais ½il. Mais bon, si le libre doit avoir une VM... pourquoi pas parrot. Encore des ressources gaspiller sur des Kludges...

                Je vois encore plus d'un mauvais ½il "la donation" de la VM adobe au projet mozilla... c'est plus un piège à c... pour pousser le web vers le support du byte code, pour nous servir des clients riches web proprios (là où bien heureusement java a échoué lamentablement). Et là, mon âme de libriste est férocement contre.

                Tiens d'ailleurs l'intéropérabilité de mono/java est très limité avec les autres frameworks. Perl/Pyhton et encore plus, Lua, font des merveilles: je peux d'un code assembleur (je caricature) utiliser du code perl/python/lua sans que ce code soit "préparé" à l'avance. Tiens Python va plus loin encore et permet directement de monter les shared objects et d'y appeler des fonctions grâce aux ctypes. Lua est balaise lui aussi et perl c'est facile aussi avec XS.

  • # raisons

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

    Nom d'un chien mais pourquoi dénaturer ainsi Xubuntu ? Personnellement je m'en fiche car j'utilise une Ubuntu classique et j'aime Gnome....mais j'imagine l'amertume des supporteurs d'XFCE !
    Outre le fait que la fameuse légèreté va peut-être en prendre un coup on ne comprends plus bien à quoi sert Xubuntu si elle intègre ainsi pleins de morceaux de Gnome. Les gens vont se dire "Si c'est presque pareil autant prendre l'original".


    Es-tu sur que sa légèreté va en prendre un coup ?

    Avant de s'insurger, il faudrait peut-être vérifier les temps de démarrage, occupation mémoire et cpu de chacune de ces applications.

    Note que je n'ai pas fait ces tests, mais dans l'absolu rien ne prouve que ces applications rendraient xfce moins "léger".

    En tant qu'utilisateur de ubuntu/gnome, tu devrais plutôt t'insurger contre l'installation de firefox par défaut au détriment de epiphany, qui fonctionne pourtant très bien (et dont la plupart des extensions populaires à firefox ont été portées).

    • [^] # Re: raisons

      Posté par  . Évalué à 1.

      "Es-tu sur que sa légèreté va en prendre un coup ?"

      Tu sais lire, il a écrit "peut-être" alors avant de "Avant de s'insurger"...

      "Dans l'absolu rien de prouve"... elle est belle celle-là, XFCE a vocation à être léger, pas gnome, donc à priori c'est plus léger, mais c'est évident qu'il faudrait aller vérifier, mais c'est très probable rien qu'avec la batterie des bibliothèques de gnome.

      • [^] # Re: raisons

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

        je ne te demandes pas de me prouver si xfce est plus léger. Je te demande de me prouver que le bureau xubuntu - à desktop xfce identique - sera alourdi par la présence de totem plutôt que gxine, ce qui n'est pas forcément évident (idem pour les autres applis citées plus haut).

  • # (x)ubuntu

    Posté par  . Évalué à 4.

    Un utilisateur a bien résumé ce qui se passe : Xubuntu est devenu (x)Ubuntu.

    > Nom d'un chien mais pourquoi dénaturer ainsi Xubuntu ? Personnellement je m'en fiche car j'utilise une Ubuntu classique et j'aime Gnome....mais j'imagine l'amertume des supporteurs d'XFCE !

    C'est un choix du "papa" de xubuntu (Jani), sans tenir vraiment compte de l'avis du second développeur et des réponses sur la liste de développement. :(

    > 1) Xarchiver est viré au profit de l'outil standard Gnome (File-roller)

    Je n'utilise pas vraiment de gui pour extraire les archives, donc de ce côté-là je peux pas dire. Il y avait aussi squeeze (http://squeeze.xfce.org/), mais son développeur considère qu'il n'est pas encore prêt...

    > 2) Gxine est viré au profit de l'outil standard Gnome (Totem)
    > 4) xfce4-taskmanager est viré au profit de l'outil standard Gnome (System monitor)
    > 5) Ajout de tous les jeux de Gnome-games (17 jeux !)

    Ces 3 là sont des décisions unilatérales de Jani, en consultant après coup (genre : « j'ai ajouté totem et gnome-games dans xubuntu, ça ne vous dérange pas ? »

    > 3) Xfburn est viré au profit de Brasero

    Le paquet xfburn d'ubuntu est buggué, et le programme ne semble pas vraiment maintenu. Le seul problème avec brasero c'est sa dépendance sur libgnome* et libtotem-plparser... Il avait aussi été proposé de ne pas inclure d'application de gravure, tout simplement.

    > Est-ce un moyen détourné de la part de Canonical de réduire la charge de travail que représente cette variante de la distro principale ?

    Aucun employé Canonical ne travaille sur xubuntu directement. La charge principale pour eux c'est la génération des isos, rien de plus...

    Mais si on en croit ce message (https://lists.ubuntu.com/archives/xubuntu-devel/2007-October/004507.html), Jani ne va pas participer au cycle suivant, donc il y a une chance de tout redresser ^^"

    • [^] # Re: (x)ubuntu

      Posté par  . Évalué à 2.

      d'un autre coté, rien n'empêche de revenir à du full xfce... et remplacer tout ce qui est Gnome par l'alter-ego xfce initialement présent... rien n'empêche non plus d'attendre la prochaine release (quand Jani sera parti :)

  • # Comparatif de poids GNOME / KDE / XFCE

    Posté par  . Évalué à 3.

    Il y a là http://ktown.kde.org/~seli/memory/desktop_benchmark.html un comparatif intéressant sur le poids des environnements.

    Conclusion :

    - KDE est très léger si on n'utilise que Konqueror et Koffice.

    - XFCE devient très lourd si on y ajoute Firefox et OOo.

    - GNOME .... non allez je trolle pas.

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Comparatif de poids GNOME / KDE / XFCE

      Posté par  . Évalué à 7.

      T'as oublié dans ta conclusion:

      - Aero est extrêment léger, quand Windows Vista n'est pas installé.

      - Ion est très très lourd si on ajoute Firefox, OOo, Eclipse, Amarok et Doom 3 dans une machine virtuelle.

      …

    • [^] # Re: Comparatif de poids GNOME / KDE / XFCE

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

      Franchement ... gnome 2.12 ... t'as pas plus vieux comme comparatif ?

      Pour info, gnome 2.12 est sortie en 2005. En 2 ans il y a eu quelque modification sur le code.

      • [^] # Re: Comparatif de poids GNOME / KDE / XFCE

        Posté par  . Évalué à 2.


        Pour info, gnome 2.12 est sortie en 2005. En 2 ans il y a eu quelque modification sur le code.


        Oui enfin ca reste Gnome hein.

        Alors il est tout à fait envisageable (et je n'oserai dire probable) qu'il soit entre temps devenu encore plus lourd

        ~~~~~~~> []

        • [^] # Re: Comparatif de poids GNOME / KDE / XFCE

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

          Ben non, Gnome est de plus en plus léger. Et XFCE de plus en plus lourd. Il me semble que si ça continue, XFCE va devenir plus lourd que Gnome.
          [mavie]
          J'ai une copine à qui j'ai installé Xubuntu il y'a bien longtemps, sur un vieux P3 600mhz avec 200 et quelques de ram. Elle à tourné en 5.10 un long moment, puis passage en 6.06, déjà XFCE devenait plus lourd. Elle utilise maintenant la 6.10, mais à switché d'elle même sur Gnome (que j'avais mis aussi) car "Y'a plus de fonctionnalités et ça rame autant". Et depuis peu, elle à un nouveau PC plus puissant, et reste avec Gnome.
          [/mavie]

  • # Xubuntu n'a pas de monopole...

    Posté par  . Évalué à 6.

    http://www.xfce.org/download/distros

    Si avec ça tu trouves pas ton bonheur!

    [truc]-ubuntu est à la mode, c'est bien, tant mieux pour eux, mais c'est pas une raison pour commencer à croire que ce qui ne correspond pas à tes besoins dans [truc]-ubuntu n'est pas disponible ailleurs! ;)

    J'attends avec impatience un journal sur "e17 n'est pas disponible! La preuve: e17-ubuntu n'existe pas!!"

Suivre le flux des commentaires

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