http://aseigo.blogspot.com/2006/01/ldb-kde.html
http://aseigo.blogspot.com/2006/01/ldb-take-2.html
Aaron Seigo est en train de coder un "backend" ldap pour kconfig(le gconf de kde). Pour cela, il utilise une librairie développée pour samba4.
Ceci n'est rien de définitif pour kde 4, juste un test pour le moment...
Je pense qu'il faut surtout mettre le coté "backend" en avant et laisser au distributeur/administrateur le choix de la technologie à utiliser... Ce que les gens de gnome n'ont jamais fait en ne proposant qu'un seul "backend".
# Trucs à noter :
Posté par Pinaraf . Évalué à 10.
2- C'est bien plus évolué que la base de registre. Le système de transaction est proche d'une base de données par exemple.
3- Il existe un éditeur en mode texte pour cette base.
4- Il s'agit toujours de KConfig. On a donc toujours une description des différentes clés et valeurs possibles pour ces clés.
5- Comme tu l'as dis, il sera possible de choisir entre un stockage dans un classique fichier "ini" et cette base de données. Il faut tout de même noter que les performances des fichiers .ini sont catastrophiques par rapport à cette base.
6- Cette base sera utilisée par samba4. C'est d'ailleurs les développeurs de samba qui l'ont crée. Donc les performances sont (seront) très bonnes, et cela devra obligatoirement être stable et fiable vu l'envergure du projet Samba4 et la dépendance à cette base pour certains fonctionnalités
[^] # Re: Trucs à noter :
Posté par gnumdk (site web personnel) . Évalué à 10.
Pfff, meme pas drole :(
Par contre, pour l'argument de la fiabilité, je reste quand meme persuadé qu'il est plus facile que corrompre 1 fichier de config binaire suite à une coupure de courant plutot que 480 fichiers textes...
[^] # Re: Trucs à noter :
Posté par galactikboulay . Évalué à 3.
La base de registres de Windows est criticable dans le sens où le format est fermé, et quand elle est corrompue, il n'y a que peu de chances d'avoir à en obtenir qqch ; d'autre part elle stocke tout et n'importe quoi et il est difficile de s'y retrouver. De plus elle est également imposée, ici comme le souligne l'auteur du journal, le choix du backend est laissé libre à l'utilisateur.
[^] # Re: Trucs à noter :
Posté par Infernal Quack (site web personnel) . Évalué à 9.
Sinon entre KDE et Gnome et donc ksysoca et gconf, on a chez GNOME un répertoire ~/.gconf/ et sous KDE un répertoire ~/.kde/
Les fichiers de conf de Gnome sont en XML et ceux de KDE en texte clé=valeur.
Le répertoire .gconf stocke seulement des fichiers XML, celui de KDE stocke un sacré beau bordel qui à la base est censé être bien rangé mais avec les années commence à devenir difficile à comprendre. Maintenant, je ne sais pas où les applications Gnome stockent les préférences autre que XMLizables (images,...). Donc au final c'est le bordel chez les deux de façons différentes :)
Perso, ce qui serait top pour les deux c'est d'avoir un moyen de gérer les préférences qui sont dépréciées. Genre un outil qui parcourtles répertoire et clés de .kde ou .gconf (et autres endroits où les préférences sont) et propose de les dégager (ou migrer). Pour cela il faudrait que les applications Gnome ou KDE qui sont installés sur notre machine fournissent un fichier décrivant les clés utilisées (toutes) et les autres trucs si possible. C'est déjà plus ou moins le cas vu que gconf et KConfig permettent de décrire les clés (description, type, valeurs possibles,...). Maintenant ça serait bien que l'idée soit poussée plus loin. Voir /usr/share/config.kcfg/ pour KDE et /etc/gconf/schemas/ pour GNOME
Après que ça soit du ldap, texte, xml ou autres c'est pas si gênant que ça sauf que les fichiers textes (ou XML donc non binaires) ont toujours l'avantage d'être lisibles et modifiables même quand tout est planté de partout :)
Et tout à fait d'accord avec ta remarque de "corruption".
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Trucs à noter :
Posté par Pinaraf . Évalué à 7.
.kde/
- Autostart/ : des liens/fichiers .desktop/scripts/exécutables qui seront lancés au lancement de KDE
- cache-*/, tmp-*/ et socket-*/ : des dossiers pour les cache, fichiers temporaires et socket
- share/
- - applnk/ : contient des liens qui sont ajoutés au menu K et propres à l'utilisateur
- - apps/ : contient les fichiers des applications qui ne sont pas liés à la configuration. Exemple : les journaux de discussion sur IRC/Jabber, la base de données d'amaroK...
- - config/ : contient les fichiers de configuration des applications, au format "ini". Certaines applications utilisent plusieurs fichiers car elles sont séparées en plusieurs "composants" (exemple : kdevelop).
- - locale/ : je sais pas là...il est vide ce dossier
- - mimelnk/ : les associations de fichiers que l'utilisateur a modifié
- - services/ : les services propres à l'utilisateur. Exemple : des mots clés de recherche personnalisés (alt+f2 => "gg:test" recherche test sur google. On peut facilement ajouter d'autres mots clés que google)
- - servicetypes/ : contient des composants, actions de konqueror.. propres à un utilisateur
Bref, .kde est très rangé.
Et le système de configuration de KDE, KConfig, ne permet pas de cacher des entrées. KConfigEditor est ton ami pour l'édition des options d'ailleurs : http://extragear.kde.org/apps/kconfigeditor/
Au passage : kconfigeditor supporte aussi gconf
[^] # Re: Trucs à noter :
Posté par Infernal Quack (site web personnel) . Évalué à 3.
Sinon .kde/ reprend l'architecture des fichiers KDE de /usr
Justement le plus bordélique dans .kde c'est le répertoire share/apps/ qui parfois contient des trucs plus utilisés. Voir par exemple le répertoire de kmail. Ou alors des noms de fichiers rc qui ne reflète pas trop le nom de l'application qui l'utilise :(
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Trucs à noter :
Posté par gnumdk (site web personnel) . Évalué à 3.
> l'utilisateur
Ca fait un moment que ce n'est plus le cas, faut aller vois dans ~/.local/share/applications/ , freedesktop oblige...
Sinon, pour répondre au message auquel tu réponds, il est vrai que le .kde/share/apps peut finir par se remplir de fichier inutile, mais bon, je vois mal comment une applis comme konversation par exemple peut prendre la decision d'effacer un fichier de log d'un chan irc juste parce que tu ne t'y connectes plus...
# Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Rappel : Elektra c'est le top ! ;)
Posté par gnumdk (site web personnel) . Évalué à 2.
>qu'il faut donc toucher à /etc/network/interface /etc/resolv.conf, /etc/hosts.conf
Je ne vois pas bien ce qu'apporte elektra.
Je pense qu'il serait plus intelligent d'avoir une lib à base de plugins, donc adaptable à chaque distribution, comme le fait celle des outils de conf de gnome mais disponible aussi à une plus bas niveau à la sysctl...
[^] # Re: Rappel : Elektra c'est le top ! ;)
Posté par Julien MOROT (site web personnel) . Évalué à 1.
La ou l'implémentation ldb pour KConfig ne stocke que les paramètres de kde, Electra permet de stocker les propriétés systèmes contenues dans /etc et la config des différents programmes personnels dans la /home de l'utilisateur. Donc d'une part tout n'est pas stocké dans un seul fichier binaire mais dans un fichier texte accessible donc dès l'initialisation, mais il existe tout de même un programme en mode ligne de commande pour manipuler les clés du registre. D'ailleurs il est possible d'utiliser Electra avec Kconfig, ce dernier étant indépendant du backend.
[^] # Re: Rappel : Elektra c'est le top ! ;)
Posté par davux (site web personnel) . Évalué à 2.
Et sinon je viens de faire mon boulet: je t'ai plussé en cliquant sur "pertinent", alors que je voulais faire "répondre"... -_-
# Organisation des fichiers de conf dans le /home
Posté par Aldoo . Évalué à 6.
Pourquoi alors que l'architecture des répertoires "système" n'est pas trop mal foutue : à savoir les homedir dans /home, les applis dans /usr, la config dans /etc, dès qu'on entre dans /home/toto, c'est tout de suite le bordel ?
On y trouve au même niveau (à la racine) les différents fichiers de conf d'applis diverses et variées, les répertoires de conf d'applis qui demandent plusieurs fichiers, un répertoire Mails, un répertoire Documents, etc... ainsi que très souvent les documents créés et les fichiers téléchargés du net par l'utilisateur, qui se voit toujours proposer par défaut la racine de son homedir comme destination.
Ce que je me demande, c'est pourquoi on n'a pas prévu dès le début une archi standardisée à l'intérieur du homedir :
- un dossier etc pour mettre la conf
- un dossier apps (ou autre) pour mettre les applis installées par l'utilisateur (avec une structure classique : apps/bin apps/lib apps/share, etc... )
- un dossier Desktop : utilité discutable, mais pourquoi pas
- un dossier Documents : pour les documents créés et gérés explicitement par l'utilisateur
- un dossier Application data (à la windows ;-) ) pour y stocker les données crées et gérées par les applis (comme les mails, le carnet d'adresse, les signets, les historiques d'IM, etc... ). En gros tout sauf la config. Ce qui permet de sauvegarder/exporter/importer/partager facilement ses données personnelles y compris entre plusieurs environnements configurés différemment (puisque la config est dans le /home/toto/etc).
Une sauvegarde des données utilisateurs, finalement ne concernerait que les dossiers /home/toto/Documents et /home/toto/Application\ data.
Je pense qu'on y gagnerait beaucoup en lisibilité si toutes les applis avaient respecté dès le début un tel schéma.
[^] # Re: Organisation des fichiers de conf dans le /home
Posté par Séverin Tagliante-Saracino . Évalué à 0.
"Do you want to change the standard ?
[...] we believe it is the duty of each application to allow itself to be installed anywhere and to accept that other applications it needs to work with may be installed anywhere (more on this in the next section). Now, if there was a standard stating this, I'd even sign a petition to support it. In fact, there is: the GNU release standards, when they recommend the usage of GNU Autotools, supporting the -prefix family of switches, and probing for the location of applications with the configure script, do just that. But when a proposed standard like the FHS gives me an arbitrary list of binaries that should be, for unexplained reasons, in a separate directory, I laugh at that."
http://www.gobolinux.org/index.php?page=doc/articles/clueles(...)
[^] # Re: Organisation des fichiers de conf dans le /home
Posté par 태 (site web personnel) . Évalué à 2.
Ah non, epiphany sauve par défaut dans ~/Desktop/Downloads, Safari dans ~/Desktop et certains navigateurs dans ~/Desktop/datedujour. En gros, ça rejoint ton point : Desktop, c'est pour le vrac qu'on n'a pas encore rangé (ben oui, avant de mettre un truc dan un tiroir ou à la poubelle, il passe un temps sur le bureau dans la corbeille des trucs à faire).
Ensuite, le répertoire Mail. Ce n'est que tout récemment que je me suis fait un dossier Mail. Avant, les mails étaient stockés sur le serveur (ils le sont encore d'ailleurs) et accessoirement dans ~/Library/Mail/ , mais je n'ai pas besoin de le savoir, ils sont indexés par Spotlight, beagle ou mairix...
Les fichiers de config des applis sont en général dans ~/Library/Preferences/, et les fichiers utiles dans ~/Library/Application Support/
Et à part ça, dans mon home, il y a des dossiers Music, Pictures, Travail, Movies. Pourquoi ils ne sont pas dans Documents, je ne sais pas mais ça ne me dérange pas. Ce qui me dérange, c'est le répertoire texmf...
Bref, il y a moyen de suivre une certaine structure. Les programmes dotés de 2 sous de bon sens sont capables de comprendre si leur fichier de config est dans un endroit pas tout à fait prévu.
[^] # Re: Organisation des fichiers de conf dans le /home
Posté par Aldoo . Évalué à 2.
Par exemple, dans les cas (très minoritaires, j'imagine) de bureaux 100% Gnome ou 100% KDE, l'architecture doit être assez cohérente.
Le problème est plus l'absence d'un standard partagé.
Du boulot pour Freedesktop.org ? Peut-être... mais il ne faudrait pas que ça se limite au desktop (bon exemple, le répertoire texmf).
[^] # Re: Organisation des fichiers de conf dans le /home
Posté par Sufflope (site web personnel) . Évalué à 2.
Une piste à suivre pour les autres applis ?
[^] # Re: Organisation des fichiers de conf dans le /home
Posté par Staz . Évalué à 2.
[^] # Re: Organisation des fichiers de conf dans le /home
Posté par Staz . Évalué à 2.
http://standards.freedesktop.org/basedir-spec/basedir-spec-0(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.