Les versions RC sont faites pour qu'un maximum de personnes puissent tester le bureau GNOME et qu'elles puissent rapporter le maximum de bogues, afin d'obtenir une version 2.10 la plus stable possible.
De manière générale, l'intégration de D-BUS a été améliorée/ajoutée dans les logiciels composant le bureau, le démarrage des applications a aussi été accéléré, grâce à l'amélioration de GTK-2.6 qui intègre un système de cache des thème d'icônes.
Je conseille aux personnes souhaitant participer aux tests d'utiliser le daily liveCD d'Ubuntu, qui inclut au jour le jour toutes les dernières versions des logiciels du bureau GNOME (merci Seb Bacher pour tout le boulot fourni).
![[en]](../images/en.png)
Bugzilla GNOME (198 hits)-
Les notes de version complètes (426 hits)
-
Le daily LiveCD Ubuntu (702 hits)
![[fr]](../images/fr.png)
Le site Francais de GNOME (1194 hits)
> Lire la dépêche (115 commentaires, moyenne: 1,9).
Vous avez demandé le commentaire #540408.
Run by 
Cette page a été générée par Templeet en 0.195s (dont 0.0328 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Bonobo?
mais un travail important a été fait pour supprimer le support de BONOBO
Je suis Gnome de très très loin : du coup je suis allé voir, suite à cette info', où en était Bonobo : apparemment tjrs. vivant sur le site pour développeurs de Gnome.
Alors pourquoi en supprimer le support dans cette application?
[^]Re: Bonobo?
Clairement, je crois que BONOBO va y passer.
Déja Nautilus n'utilise plus son système de vue embarqué, maintenant il appelle le soft kivabien (je supportais pas trop ce genre de comportement).
D-BUS semble être le consensus choisis, tant au niveau GNOME que FDO/KDE pour être le système de 'messagerie' interne.
[^]Re: Bonobo?
> Clairement, je crois que BONOBO va y passer.
Bonobo ne va pas "y passer".
> D-BUS semble être le consensus choisis, tant au niveau GNOME que FDO/KDE pour être le système de 'messagerie' interne.
Tu l'as dit, c'est pour de la messagerie interne. Bonobo va plus loin et ne peut pas être remplacé par D-BUS avant un bon moment si jamais il est remplacé un jour.
[^]Re: Bonobo?
De toutes façons, Bonobo restera dans toute la série des GNOME 2.x, compatibilité binaire oblige.
[^]Re: Bonobo?
Et pour l'instant il n'est pas prévu de le virer pour Gnome 3.
[^]Re: Bonobo?
pour l'instant, Gnome 3 n'est pas prévu tout court
[^]Re: Bonobo?
Il est prévu mais pas planifié. C'est différent.
[^]Re: Bonobo?
http://live.gnome.org/ThreePointZero(...)
[^]Re: Bonobo?
Je me marre en lisant les problemes que rencontre l'utilisation de bonobo chez les developpeurs. C'est pour ce genre de raison que KDE a mis mico (le corba utilise a l'epoque pre-KDE 2) a la poubelle il y a quelque chose comme 5 ans. Ils ont remplace des mois de travail sur corba par 1 semaine - homme de dev et un dlopen. Mais bon, tout le monde peut continuer a croire que bonobo, c'est l'avenir de Gnome.
Je pense que le probleme de fond de bonobo, c'est que Corba est beaucoup trop complexe pour les besoins qu'en ont Gnome. Quand on a affaire a des gens qui travaillent pendant leur temps libre, mieux vaut eviter de leur compliquer la vie. A cote, KPart fournit les memes services que bonobo, mais ca a coute une semaine de dev et n'importe quel debutant motive peut comprendre comment ca marche en moins d'une semaine (man dlopen suffit en gros).
phil.freehackers.org
[+] [^]Re: Bonobo?
> Ils ont remplace des mois de travail sur corba par 1 semaine - homme de dev et un dlopen.
Puisque tu le dis.
> A cote, KPart fournit les memes services que bonobo
L'indispensable "KDE c'est mieux que Gnome" d'un fan KDE. Ça me manquait beaucoup.
[+] [^]Re: Bonobo?
C'est plus fort que moi, je ne peux pas resister.
Note que les problemes de bonobo ont ete evoque plutot par des supporters de Gnome.
phil.freehackers.org
[+] [^]Re: Bonobo?
> Note que les problemes de bonobo ont ete evoque plutot par des supporters de Gnome.
J'ai jamais dit que bonobo était la perfection absolu.
Mais ça fait depuis le début de bonobo (en fait le début de Gnome) que les gens critiquent Orbit/Corba/bonobo et prévoit sa suppression à court terme.
Ils se sont complètement trompés (je parle de la suppression de Corba/bonobo). Ce tromper ça arrive à tout le monde. Mais insister indéfiniment ça devient lourd.
Corba/bonobo est là depuis des années et sera encore là pour beaucoup d'années.
Pour ajouter un élément "technique", bonobo n'a rien à voir avec dlopen. Gtk+ fait ça depuis *très* longtemps. Faut pas confondre greffon et serveur.
[^]Re: Bonobo?
<< Mais ça fait depuis le début de bonobo (en fait le début de Gnome) que les gens critiquent Orbit/Corba/bonobo et prévoit sa suppression à court terme. >>
Ouai, ca se peut. Ils doivent etre assis en face de ceux qui predisent depuis le debut de KDE que le projet va se planter:
- parce qu'il est base sur un toolkit proprietaire (KDE 1)
- parce qu'il n'utilise pas Corba (KDE 2)
- parce que Sun, Redhat, IBM, Ximian, etc investissent a fond dans Gnome et vont rendre KDE obsolete.
Finalement, il faut pas trop ecouter les racontars...
<< Pour ajouter un élément "technique", bonobo n'a rien à voir avec dlopen. >>
Oui et non. Il est possible de faire tourner les composants bonobo a l'interieur du meme processus, et dans ce cas, c'est bien un dlopen qui est utilise.
Ce que je disais, c'est que l'equivalent cote KDE de bonobo, c'est KPart + DCOP. KPart utilise dlopen ce qui le rend leger, facile a comprendre, facile a lancer (pas de fork comme en corba) et qui a permis aux composants KPart de se developper tres vite.
Le choix de corba dans bonobo rend la technologie plus complexe et limite par consequent son adoption.
phil.freehackers.org
[^]Re: Bonobo?
> Ils doivent etre assis en face de ceux qui predisent depuis le debut de KDE que le projet va se planter:
C'est vrai.
> Oui et non. Il est possible de faire tourner les composants bonobo a l'interieur du meme processus, et dans ce cas, c'est bien un dlopen qui est utilise.
C'est vrai aussi :-)
> Le choix de corba dans bonobo rend la technologie plus complexe et limite par consequent son adoption.
J'ai jamais codé de bonobo. Mais là c'est un peu léger comme argument. J'image que lorsqu'on utilise bonobo on ne parle pas le "corba" en native. On utilise une interface qui doit cacher ces détails et simplifier la vie des développeurs d'appli.
[^]Re: Bonobo?
A mes yeux, le pb de bonobo, c'est pas que c'est pourri que ça marche mal et tout ça, c'est juste que c'est pas complètement fini, ie c'est un peu comme la xlib : avec la xlib, t'as tout ce qu'il faut pour faire des trucs biens, mais sans un toolkit comme qt ou gtk+, tu t'en sors pas. Bonobo à mon avis c'est pareil, faudrait rajouter des trucs pour le rendre plus simple à utiliser. Mais personne s'est lancé là dedans, et avec Havoc qui a décidé il y a bien longtemps que bonobo c'était pas bien, et qui par contre fait tout ce qu'il peut pour que son dbus puisse bénéficier d'une surcouche permettant de l'interfacer facilement avec gtk et la glib...
[^]Re: Bonobo?
> avec Havoc qui a décidé il y a bien longtemps que bonobo c'était pas bien, et qui par contre fait tout ce qu'il peut pour que son dbus puisse bénéficier d'une surcouche permettant de l'interfacer facilement avec gtk et la glib...
...
Havoc n'a JAMAIS dit que DBUS remplacera bonobo.
> son dbus puisse bénéficier d'une surcouche permettant de l'interfacer facilement avec gtk et la glib...
Ça n'a aucun sens. Interface gtk avec cvs si ça t'amuse.
[^]Re: Bonobo?
> Havoc n'a JAMAIS dit que DBUS remplacera bonobo.
Il l'a pas dit, mais en suivant l'évolution de dbus et de ce qu'il veut faire avec dbus, c'est de plus en plus évident (surtout si tu prends en compte le fait qu'il n'aime pas bonobo).
> Ça n'a aucun sens. Interface gtk avec cvs si ça t'amuse.
Je parlais de création automatique de wrappers pour accéder aux méthodes/propriétés d'un gobject via dbus, j'espère que ça t'es plus compréhensible maintenant. Par contre je comprends pas ce que tu dis toi ;)
[^]Re: Bonobo?
> Je parlais de création automatique de wrappers pour accéder aux méthodes/propriétés d'un gobject via dbus.
Que veux tu me faire dire ?
Qu'on peut remplacer bonobo par dbus si on étend dbus ?
Oui on peut.
Que le développement actuel de dbus ne vise qu'à virer bonobo ?
Je n'y crois pas 3 secondes.
Que bonobo n'est pas éternel ?
bonobo n'est pas éternel.
Que bonobo sera remplacé par dbus (+ quelque chose au dessus) ?
Oui, c'est possible. Mais ce n'est même pas prévu pour Gnome 3 ...
[^]Re: Bonobo?
> Que le développement actuel de dbus ne vise qu'à virer bonobo ?
Havoc ne l'a pas dit ouvertement, mais à mon avis un de ses objectifs est d'avoir qqchose de viable qui peut à peu près remplacer bonobo, même si ce n'est pas l'unique raison d'être de dbus...
> Que bonobo sera remplacé par dbus (+ quelque chose au dessus) ?
> Oui, c'est possible. Mais ce n'est même pas prévu pour Gnome 3 ...
Je sais pas trop d'où tu tires toutes tes certitudes et tes infos sur gnome, mais je peux te dire que moins il y aura de bonobo dans gnome 3, plus les développeurs seront contents...
[^]Re: Bonobo?
http://live.gnome.org/ThreePointZero(...)
[^]Re: Bonobo?
> mais je peux te dire que moins il y aura de bonobo dans gnome 3, plus les développeurs seront contents...
Les développeurs ne sont pas obligé d'utiliser bonobo.
C'est BEAUCOUP plus compliqué et pas standard d'utiliser D-bus ou de tout faire à partir de rien pour remplacer bonobo que d'utiliser directement bonobo. D'accord ?
Donc pourquoi les développeurs seront contents s'il y a moins de bonobo ?
Car ils auront l'opportunité de refaire bonobo ?
Ton propos n'a tout simplement pas sens tant qu'il n'y a pas d'alternative à bonobo, et à l'heure actuelle il n'y en a pas. Et si il n'y en a pas c'est aussi car bonobo est satisfaisant ou que personne ne sait (ou ne veux, mais ça revient à dire que bonobo est satisfaisant) faire mieux.
[^]Re: Bonobo?
C'est vrai, t'as raison, t'en sais certainement plus qu'un mec qui *lui* travaille sur le projet gnome et je peux te dire que dans l'ensemble les devels gnome sont de son avis, cela ne représente que les devels francais mais je doute que cela change quelque chose.
Apres, gnome 2.12 n'est pas encore la, il s'en passe des choses dans un projet ;)
>car bonobo est satisfaisant ou que personne ne sait ... faire mieux.
Mwai, en meme temps, quand gtk avait un selecteur de fichier pourri(je l'aimais bien moi), je pense pas que personne ne voulait faire mieux mais plutot que personne n'avait le temps de s'en occuper. Et dans ce cas la, c'est la meme chose, il faut quand meme constater que tout ca est un échec par rapport à kpart. Je ne parle pas d'un point de vu technique mais d'un point de vu facilité d'utilisation, la majorité des programmes kde(meme non officiels) utilise kpart et dcop...
Je pense que si gnome 3 arrive a fournir quelque chose de simple à utiliser pour un programmeur lambda, cela ne sera pas un mal, que ce soit en faisant une surcouche à bonobo ou en codant un truc nouveau.
Mais Christophe n'a pas dit que bonobo allait disparaitre, il a juste montré que ce n'était pas une fierté du projet Gnome et qu'il y'a peut être du travail à faire de ce coté la. L'avenir nous le dira...
Agogo
[^]Re: Bonobo?
> Mwai, en meme temps, quand gtk avait un selecteur de fichier pourri(je l'aimais bien moi), je pense pas que personne ne voulait faire mieux mais plutot que personne n'avait le temps de s'en occuper. Et dans ce cas la, c'est la meme chose
Et pour le selecteur de fichier avant tu aurais dit ? :
- moins il y aura de selecteur de fichier et plus les développeurs seront contents
Ça n'a pas de sens.
Que des gens disent :
- il faut améliorer bonobo
- il faut simplifier son utilisation
- il faut une meilleur doc
- etc
je peux parfaitement entendre ces reproches/aspirations.
Mais pour "gnome sans bonobo c'est mieux que gnome avec bonobo", je suis sourd.
> Je pense que si gnome 3 arrive a fournir quelque chose de simple à utiliser pour un programmeur lambda, cela ne sera pas un mal
Là, je suis d'accord. J'ai jamais dit que bonobo était l'outil ultime et qu'il était inammovible. S'il y a mieux ou s'il on sait/peut faire mieux, je dis : go !
Mais la disponibilité des fonctionnalités de bonobo c'est certainement mieux que rien.
[^]Re: Bonobo?
oui, c'est un peu le problème. CORBA/Bonobo est parfois vendu comme "language-neutral" : théoriquement, tu as ton interface décrite en IDL que tu peux utiliser depuis n'importe quel langage possédant une couche CORBA. Un problème est que CORBA en C est assez complexe, même avec bonobo et donc bien souvent une bibliothèque en C est écrite par dessus pour que ce soit plus simple à utiliser. Résultat : on est encore obligé d'écrire des bindings pour ces bibliothèques.
[^]Re: Bonobo?
La plupart des devels gnome actuels n'aiment pas bonobo (trop lourd à utiliser, trop compliqué, ...) donc la tendance actuelle est à limiter son usage au maximum.
[^]Re: Bonobo?
> donc la tendance actuelle est à limiter son usage au maximum.
Je crois que c'est une mauvaise perception. Il n'est pas question de limiter son usage. Il est question de l'utiliser là où il est utile. Dans nautilus (voir plus haut) il n'est pas utile. Par contre pour le panel, evolution, les visualisateurs, etc il est utile et son usage est fortement recommandé.
[^]Re: Bonobo?
> Il n'est pas question de limiter son usage
On doit pas parler avec les mêmes personnes alors...
Essaie de parler de bonobo aux développeurs de sound-juicer ou totem par exemple.
> visualisateurs
Je me demande si eog n'a pas perdu son support bonobo d'ailleurs...
[^]Re: Bonobo?
> Essaie de parler de bonobo aux développeurs de sound-juicer ou totem par exemple.
Tu trouveras toujours un ou deux développeurs pas content. C'est la vie.
T'as bien des gens qui trouve que Unix sucks.
Ça fait depuis des années qu'on entends que bonobo puxor et il est toujours là. *Librement* implémenté, *librement* utilisé.
> Je me demande si eog n'a pas perdu son support bonobo d'ailleurs...
Peut-être (au fait, il a déjà eu un support bonobo ?). Gthumb (le nouveau) a un support bonobo.
[^]Re: Bonobo?
mouais, moi je pense que c'est une bonne perception.
Bonobo a surtout été utilisé par les gens qui l'ont codé au départ, à savoir l'équipe Ximian (ex-Helixcode, maintenant Novell) pour leurs softs (Gnumeric, Evolution) et dans Nautilus. A part eux ...
[^]Re: Bonobo?
Gnumeric doit pas trop utiliser bonobo vu qu'il fonctionne sous windows. Evolution utilisait plus bonobo dans sa version 1.x que dans sa version 2 je pense.
[^]Re: Bonobo?
> Evolution utilisait plus bonobo dans sa version 1.x que dans sa version 2 je pense.
Tout est bonoboïfier dans Evolution 2.
Vires par exemple /usr/lib/bonobo/servers/GNOME_Evolution_Calendar_2.0.server pour rigoler.
[^]Re: Bonobo?
Oui, evo c'est encore 4/5 gros composants bonobo, mais dans la version 1, l'utilisation de bonobo était plus importante, tu devais avoir des composants out of process et tout le tintouin.
[^]Re: Bonobo?
> A part eux ...
- gnome-panel et tous les applets
- Rhythmbox
- abiword
- balsa
- gnomemeeting
- gpdf
- yelp
- etc
J'ai "seulement" 84 serveurs bonobo ici (dont 10 pour evolution qui est la plus grosse appli).
[+] [^]Re: Bonobo?
A mon sens, Bonobo a été une de plus grosse erreur technique du projet Gnome.
Il ne reste plus qu'à virer l'autre erreur : GConf :
- portabilité réduit à néant
- stabilité désastreuse
- compléxité accrue
- utilité constestée
Comme bonobo, c'est un concept agréable ...
[^]Re: Bonobo?
Tu peux développer ? En particulier au regard de http://tml-blog.blogspot.com/2005/02/would-real-maintainer-of-popt-(...)
Pour la stabilité, la complexité et l'utilité contestable, c'est pareil, j'aimerais bien que tu développes un petit peu.
J'ai vu pas mal de devels gnome se plaindre de bonobo, mais j'ai pas souvenir d'avoir déjà entendu qqu'un se plaindre de gconf... (à part quelques développeurs d'applications tierces pour qui la portabilité sous windows était importante).
[^]Re: Bonobo?
> mais j'ai pas souvenir d'avoir déjà entendu qqu'un se plaindre de gconf...
Moi non plus. Gconf est _très_ aprécié. Du moins l'idée car il reste quelque soucis d'implémentations (NFS et via réseau ; j'ai oublié les détails) et de performance (accès disque).
Je n'ai absolument pas envis de voir gconf partir pour des fichiers .ini qui sucks dans tous les domaines.
[^]Re: Bonobo?
(à part quelques développeurs d'applications tierces pour qui la portabilité sous windows était importante)
Et même pour eux, il y a un espoir, avec le travail de Tor Lillqvist (dans le cadre du port Windows d'Evolution ...).
http://tml-blog.blogspot.com/2005/02/would-real-maintainer-of-popt-(...)
(5ème paragraphe)
[^]gconf (était:Re: Bonobo?)
Je me glisse dans le fil avec une remarque et une question:
ici on utilise principalement kde. Mais pour faire plaisir aux stagiaires j'ai installé un Gnome "de base", avec ce qu'il faut pour bosser et se détendre (entre le dur labeur!).
Notre /etc/gconf est assez gros: 28Mo. Et dire qu'autrefois je pestais contre la taille de la base de registre Windows (ma question c'est est-ce que cette taille est normale?) ...!
Cette taille de /etc/gconf a créé un problème inattendu. Lors d'une mise à jour (avec apt sur Debian), la partition racine est devenue trop petite, à cause de gconf grandissant trop vite (40 Mo). La mise à jour s'est arrêtée en plein vol, avec les conséquences qu'on imagine. Bon ça se répare, on déplace son gconf sur /usr/local, on trifouille par ci par là et on relance le bazar. Mais quand même! Tout d'un coup j'ai trouvé gconf dangereux.
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm
[^]Re: gconf (était:Re: Bonobo?)
> la partition racine est devenue trop petite
Jamais, jamais, jamais compris cette obsession de partitionner les disques en 50 bouts.
Je trouve cette manie ridicule et surannée.
[^]Ca veu dire quoi surranée ?
Pour un particulier qui à un usage banale de sa machine (pas de serveur a l'écoute), ok, il n'y a pas grand interet.
MAIS, plus tu cherches la securité, la perenité de tes données et que t'es un minimum sérieux, tu partitionnes ton disque un peu plus qu'une bête / avec tout dedans.
Le premier exemple qui me viens est évidemment avoir un / et un /home sur 2 partitions différentes ... avoir tes précieuses données sur une partoche à part est toujours bon quand t'as à réinstaller par exemple.
Un autre exemple, essentiellement applicable à une machine en production avec de bonne contrainte de sécurité, est de séparer tes partitions en fonctions des "droits de montages". => man mount
=> http://www.debian.org/doc/manuals/securing-debian-howto/ch3.fr.html(...)
[^]Re: Ca veu dire quoi surranée ?
http://www.debian.org/doc/manuals/securing-debian-howto/ch4.fr.html(...)
Celui-ci explique un peu plus pourquoi mon man mount :)
Ok, ça tiens plus de la parano qu'autre chose, mais y en a pour qui s'est important.
[^]Re: Ca veu dire quoi surranée ?
> Ok, ça tiens plus de la parano qu'autre chose
Un peu :-)
J'ai bien le :
Toute personne qui accède physiquement au système peut le débrancher, frapper dessus avec un marteau, etc. Inhiber <ctrl><alt><sup> est le cadet de mes soucis.
[^]Re: Ca veu dire quoi surranée ?
Quoit !? tu n'as pas mis ton systeme dans une autre piece equipee d'une cage de farraday fermee a double tour par une porte blindee ??
Pfff, tout se perd...
--
;)
[^]Re: Ca veu dire quoi surranée ?
J'ai mis un cadena et j'ai jeté la clée dans un puit sans fond.
Tranquile je suis maintenant.
[^]Re: Ca veu dire quoi surranée ?
si c'est des pc public tu peux très bien imaginer que tes pc soit enfermé dans une piece a coté ou dans des caissons
[^]Re: Ca veu dire quoi surranée ?
Sans aller jusque là!
Notre filliale d'un grand groupe mutualise les salles serveurs (ben ouais, c'est cher une salle serveurs quand t'as que 2 serveurs par filliale); Du coup, imagine pour X Y raison un autre mec arrive, se plante de machine et fait un ctrl+alt+Suppr. Ben t'est baisé! Ou alors, t'est avec un swith clavier écran sur 4-5 machines, en switchant tu te trompe de machine et tu redemarres le serveur de production. T'est baisé aussi! (Décidément)
Il vaut mieux éliminer le plus de source d'erreur possible! Même si ça semble absurde à priori! Ca coute pas beaucoup mais des fois t'est bien content. Et ça, c'est vraiment du vécu!
[+] [^]Re: Ca veu dire quoi surranée ?
> Le premier exemple qui me viens est évidemment avoir un / et un /home sur 2 partitions différentes ... avoir tes précieuses données sur une partoche à part est toujours bon quand t'as à réinstaller par exemple.
Une partition de plus ne remplace pas un bon backup.
> => http://www.debian.org/doc/manuals/securing-debian-howto/ch3.fr.html(...)
Tu peux aussi chrooter chaques utilisateurs, les mettres dans un périphérique loopback etc.
J'ai autre chose à foutre.
[^]Re: gconf (était:Re: Bonobo?)
Il est utile de séparer les choses.
Personnellement, j'ai un /home, un /usr, et un tout le reste.
Le /usr, on peut le mettre en lecture seule quand on n'installe pas beaucoup de programmes. Comme ça, quand ton ordi crash parce que t'as débranché l'alim sans faire exprès ou parce que le fusible saute à cause de plaques chauffantes de la cuisine "qui pète les plombs", eh bien tu as moins de chances d'endommager tes programmes.
De plus, en faisant un "rm -rf /" même en root, tes programmes sont encores là.
Et pas mal aussi, on peut surveiller facilement la taille de tous tes programmes avec un simple df.
Le /home, c'est parce que c'est les données et que je ne vois pas ce que les données ont à faire sur la même partition que le système. Même sous Windows, on voit souvent une autre partition dédiée aux données,. Mais c'est surtout qu'avec Windows 98 il fallait souvent réinstaller son système. Et donc, en "formatant" le disque système, les données étaient encore là.
Alors, après, si c'est pour ton usage personnel, c'est peut-être inutile. Mais pour un système qui utilise pleinement le côté multi-utilisateur de UNIX, un serveur, ou autre machine devant être fiable, il faudrait par exemple avoir une partition /var séparée, pour éviter le déni de service par log interposé.
D'ailleurs, je me pose une question. Il serait plus logique - je trouve - de pouvoir mettre /etc sur une partition à lecture seule. Seulement, il me semble bien que ça n'est pas pour l'nstant possible, à cause de fichier comme /etc/mtab, ou encore /etc/ppp/resolv.conf. Je pense que ces fichiers devraient être dans /var. Que dit FSB ?
[^]Re: gconf (était:Re: Bonobo?)
Eh ? Mais c'est ton propos qui est ridicule! tu n'es pas dans mon bureau, pas devant les bécanes que je gère, et pas non plus au courant de nos contraintes.
Et surtout, comme tout le monde tu ne connais pas _tout_ d'Unix. Dans nos conditions de travail, il est hors de question de ne pas partitionner /var /usr et /tmp - le /home est distant.
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm
[^]Re: gconf (était:Re: Bonobo?)
> Dans nos conditions de travail, il est hors de question de ne pas partitionner /var /usr et /tmp - le /home est distant.
Je ne dis pas que ce n'est jamais intéressant mais j'ai vu *énormement* de personnes qui ont regretté avoir fait plein de partitions et qui se mordaient les doigts après coup. Si tu fréquentes des forums, tu ne pourra qu'être d'accord avec moi :
http://ww.google.fr/search?hl=fr&q=partition+%2Fvar+%2Ftmp+full(...)
Les gens qui ont regretté de ne pas avoir plein de partitions partout sont très rares. Ce qui est le plus populaire c'est d'avoir un "/home" séparé. Perso, je préfère un backup.
[^]Re: gconf (était:Re: Bonobo?)
Excuse-moi, mais vu comment tu le disais: "ridicule et suranné", je t'ai trouvé assez généraliste. C'est vrai que sur un poste perso, en utilisation normale (bureautique, web, etc.), ça n'a pas grand sens, vu les tailles de disques actuels. Mais il n'y a pas que ce genre d'utilisateurs sur DLFP.
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm
[^]Re: gconf (était:Re: Bonobo?)
> Excuse-moi, mais vu comment tu le disais: "ridicule et suranné", je t'ai trouvé assez généraliste.
J'ai fait une faute de communication :-)
ridicule :
- car dans 97 % des cas c'est inutiles et une source d'emmerdemment
suranné :
- c'est vieux et lié à des problèmes techniques. Limite du fs, limite en nombre de inode, limite des disques, pas de lvm, pas de quota, etc.
Ceci dit, je trouve très bien que l'arborescence Unix soit bien foutue et permette d'utiliser intelligement "plein de partitions" lorsque c'est utile.
[^]Re: gconf (était:Re: Bonobo?)
gnumdk@milouse:~$ mount | grep hd
/dev/hda1 on / type xfs (rw,noatime)
/dev/hda6 on /usr/local type xfs (rw,noatime)
/dev/hda7 on /usr/local/games type xfs (rw,noatime)
/dev/hda8 on /home type xfs (rw,noatime)
/dev/hda9 on /mnt/Download type xfs (rw,noatime)
/dev/hda10 on /var/cache/apt/archives type xfs (rw,noatime)
/dev/hda11 on /mnt/Documents type xfs (rw,noatime)
/dev/hda12 on /mnt/mdk type xfs (rw,noatime)
/dev/hdb1 on /mnt/Zik type xfs (rw,noatime)
/dev/hdb3 on /mnt/Save type xfs (rw,noatime)
/dev/hdb2 on /mnt/Videos type xfs (rw,noatime)
/dev/hdc1 on /mnt/P2P type xfs (rw,noatime)
/dev/hdc5 on /usr/src type xfs (rw,noatime)
gnumdk@milouse:~$
Plein de partoches roxor ;)
Si à chaque fois que je change d'os je dois recopier toutes mes données sur le dur parce que je n'ai qu'un /, je serais devenu fou depuis longtemps ;) D'ailleurs si je devais sauvegarder tout ce que j'ai sur mes durs, je serais envahi de cd depuis longtemps ;)
Par contre, il est clair que je prefere un gros / que deux partoches pour /var et /tmp, trop difficile de prévoir à l'avance de combien on aura besoin, alors qu'avec un / de 6 Go, je suis tranquille :)
/dev/hda1 5,8G 2,5G 3,4G 43% /
Agogo
[^]Re: gconf (était:Re: Bonobo?)
$ df | grep ^/dev
/dev/md0 120269524 47962012 66288864 42% /
/dev/hdc1 19467148 13004872 6462276 67% /mnt/big_a1
/dev/hda1 19467148 13005104 6462044 67% /mnt/big_b1
/dev/hde1 18658996 7932568 10726428 43% /mnt/small1
$ cat /proc/mdstat
Personalities : [raid0]
md0 : active raid0 hdc2[0] hda2[1]
120372992 blocks 128k chunks
tout est dans /dev/md0. /dev/hdc1 /dev/hda1 c'est pour backup (/dev/hdc1 c'est j-2 et /dev/hda1 c'est j-1). C'est identique à /dev/md0 mais sans les gros trucs sans importances (videos (légales, des enregistrements tv), trucs que je peux downloader, etc). Si /dev/md0 s'"écroule", je peux continuer à bosser avec /dev/hdc1 ou /dev/hda1. /dev/hde1 est a usage temporaire, typiquement pour des tests.
[^]Re: gconf (était:Re: Bonobo?)
Si tu veux retailler à la volée tes partition, regarde LVM + FS qui va bien genre JFS. Comme ça, même si tu n'a pas prévu assez, tu peux te débrouiller pour retailler ;-)
[^]Re: gconf (était:Re: Bonobo?)
Mon répertoire /etc/gconf pése 36 Mo.
Ces 36 Mo sont décomposé en 16 Mo de /etc/gconf/schemas et 20 Mo de /etc/gconf/gconf.xml.defaults
Les schemas contenus dans /etc/gconf/schemas représentent le fichier de conf brut des applis, et les fichiers dans /etc/gconf/gconf.xml.defaults sont les valeurs par défaut des applis initialisé à partir du schemas.
Pourquoi ces fichier de conf sont si volumineux ? Simplement parce que chaque options de configuration possède une description courte et une description longue dans toute les langues supportés par GNOME.
Y a t'il moyen de diminuer la taille de ces fichiers de conf ? Il faudrait étudier la pertinence de mettre ces traductions dans le fichier gettext .mo de l'application concerné. Ce serait alors au démon gconf de fournir les bonnes descriptions localisées et non plus aux application style gconf-editor de parser tous les fichiers xml pour afficher les desriptions de clé.
Si la taille des fichiers de schemas est vraiment critique, tu peux essayer de virer toutes les traductions.
[^]Re: gconf (était:Re: Bonobo?)
Si la taille des fichiers de schemas est vraiment critique, tu peux essayer de virer toutes les traductions.
oui pas con, j'y avais pas pensé
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm
[+] [^]Re: gconf (était:Re: Bonobo?)
c'est pas pour faire chier, mais si t'es a 10Mo pres sur ton /etc, ya peut etre comme qui dirait un probleme de calibrage de ta partition, non?