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.
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.
> Lire le journal (48 commentaires, moyenne: 2,6).
Vous avez demandé le commentaire #874782.
Run by 
Cette page a été générée par Templeet en 0.0739s (dont 0.0068 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Surtout pour éviter l'infâme bloat de mono
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
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
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
Ben sur ma debian j'ai fait un apt-get install gnome-desktop-environment et je n'ai ni Orca, ni Mono ...
Le scheme c'est bien.
[^]Re: Surtout pour éviter l'infâme bloat de mono
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
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
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
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
"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
oui tu cliques droit sur ton panel, add applet puis tu choisis sticky notes/pense bête
[^]Re: Surtout pour éviter l'infâme bloat de mono
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
"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
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
"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
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
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.