C une question existentielle qui m'est venue soudain ...

/etc/

cd ~
ls -a

Disons que ma réponse est un "équivalent" de HKEY_LOCAL_MACHINE
La réponse de lorill est une éaquyivalent à HKEY_CURRENT_USER
 
Mais il ne faut pas forcément chercher de l'équivalence, surtout au niveau système. Les couches basses de ces deux OS n'ont rien à voir. C'est comme si je demandais quel est l'équivalent de /dev sous windows, ça risque d'^etre dur à trouver.

Une base de registre sous Linux !!
 t'y est pas fou dans ta tête toi !!!!!
 
Si /etc ou ~ s"en rapprochent ils ont l'énorme avantage d'être compréhensibles et éditables avec un éditeur de texte. et qu'on peut y faire des truc à la main sans avoir besoin d'u tweakkekchose

effectivement , pas evident !
Deja que je voyais pas pour le registre    
Enfin merci des precisions !!
Dis sinon , y'a un clan Narta ou koa la ??  

FlamM a écrit a écrit : Une base de registre sous Linux !!  t'y est pas fou dans ta tête toi !!!!!   Si /etc ou ~ s"en rapprochent ils ont l'énorme avantage d'être compréhensibles et éditables avec un éditeur de texte. et qu'on peut y faire des truc à la main sans avoir besoin d'u tweakkekchose

J'assume total !!

Ouaip, jusqu'au jour où les devs utiliseront des vrais fichiers de config unifiés et parsables intelligament, genre une BerkleyDb, ou encore du XML...

La berkeleyDB, je ne pense pas que ce soit une bonne idée. C'est utilisé par e17 afin d'accelerer les accès à la configuration courante sans pour autant tout charger en mémoire, mais ça rend la configuration en dehors des outils dédiés impossibles.
 
Le XML est une bonne idée, les parseurs sont tout faits, simples à utiliser, et tout, mais ça a tendance à ^etre long à lire pour un programme, et parfois un poil lourd à manipuler.
 
En fait, ce qui est à mon sens le mieux, c'est d'utiliser un fichier XML comme base de configuration, mais de construire un index permettant de retrouver simplement les donnnées du XML, afin d'en accélérer l'accès à l'éxécution sans plomber les perfs. C'est ainsi que fonctionnentn les bases de données XML telles ebXML. On a ainsi la lisibilité (?) du XML, avec l'éffcacité des configs en base.

J'aime bien mes fichiers textes  

911GT3 a écrit a écrit : J'aime bien mes fichiers textes

emoidonc!

Ça existe, ça s'appelle gconf. C'est utilisé par galeon et nautilus, et c'est assez puissant. Ça fait même plus que du stockage de configuration, car il y a un démon qui gère les accès concurrents.

hmmm, ca commence a devenir interessant la !
jcour voir ca        

gconf juste pour la conf GNOME , pas pour tout le systeme.

Les avantages de la BerkleyDB :

• ca donnes un simple fichier .db, tu peux exporter tes dotfiles et autres...
• C'est très rapide à charger/parser
• Gère en natif les variables typées sans se soucier de parser convenablement de l'asciz (en gros, ca rajoute de la secu pour les codeurs qui ne codent pas secur par default)
• Peut stoquer du binaire...
• La lib BerkleyDB existe pour beaucoup d'env
• Il existe moultitude d'outils/d'éditeurs dédiés à la lecture des bases BDB.

XML :

• vraiement un standart interessant/fonctionnel
• très unifié, tu lit la DTD et ses comments et tu a lu l'équivalent du man trucmuch.conf
• parsable très facilement (dom et sax existent dans tous les languages très fréquement utilisés)

Un index? pourquoi pas... tu veux dire un simple ID unique (comme ebXML) ou carrément ID généré par ton parser + table de hashage/tableau de références pour accéder encore plus rapidement à un élément directement? Tu ne peux pas demander à un mec qui tapes une conf de générer un ID pour chaque élément...
Anyway, un fichier de conf, y'a de grandes chances que tu le lise en entier (sauf cas précis genre fichier d'utilisateurs, ...), donc bon... Mais l'iddée d'index est laissée au libre arbitre des developeurs...

à la limite, je préfères la lib de Raster pour les BDB qui est plus "universelle", ie tout le monde peut l'utiliser...

• très unifié, tu lit la DTD et ses comments et tu a lu l'équivalent du man trucmuch.conf

Je préfèrerement l'utilisation du XMLSchema. Bien que plus lourd à écrire, ça rajoute en plus un typage des données. On y retrouve notamment la possibilité d'avoir des valeurs enum, de demander des entier strictement position (pour un numero de port par exemple), voir m^eme de déclarer un element comme devant avoir une valeur répondant à une regexp. L'utilisation de ce genre d'outils déporte énormement de test qui sinons seraient faient par le programme qui lit. De plus, si le fichier de schema est suffisamenet précis, on peut automatiquement en déduire une interface de saisie pour le fichier de conf.  
 
dom et sax existent dans tous les languages très fréquement utilisés
M^eme dans ceux pas utilisé=s d'ailleurs.
 
ID généré par ton parser + table de hashage/tableau de références pour accéder encore plus rapidement à un élément directement?
 
Oui, carrément ce système. Au travail, j'ai bossé sur des fichiers XML de plusieurs mégas. Utiliser DOM donne de telles occupations mémoire que l'on mettait les PC à genou (et hors de question d'imposer aux clients 1Go de mémoire), SAX se relançait dans la lecture du fichier à chaque fois que l'on cherchait un truc. Donc, au démmarage de l'appli, un coup de SAX pour regenerer un index d'accès (avec hashtable), et hop, rapide et efficace pour le reste de la journée.

• J'utilise très peut XMLShema... donc je n'ai pas d'avis pratique sur la question, juste théorique...
• pour l'index comme tu le vois, j'avais déjas fait ca en java, mais c'étais simplement parcequ'une appli nous exportait un flux XML au bas mot de 20 Mo en un seul coup, et qu'ils ne voulaient pas que l'on accède à leur DB directement... donc ces cons avait fait un daemon qui faisait un select *, et qui nous renvoyait le flux XML COMPLET sur demande... Donc en gros, je veux juste un enrengistrement, eux ils font une requète sur toute la DB, charge monstrueuse, ils nous filent un fichier XML bourrin (en plus, la DTD était super bizare), et moi, je devais retrouver mon enregistrement là dedans avant de détruire le flux et de refaire une demande...

J'avais mis un système de cache quand même, mais je travaillait sur le fichier XML (soit caché, soit provenant du flux) -> donc mise en place d'un Index, et d'un hashtable...

mais bon, XMLShema, ca me parait un peut lourd pour un fichier de conf
surtout qu'un des avantages du XML sur la BDB, c'est d'etre lisible par un éditeur de texte, donc si tu rajoute de la complexitée avec tes Shemas... l'utilisateur lambda vas se pendre...

mais bon, rapellons que l'on parles de fichiers de conf (et éventuellement de fichiers de ressources), donc bon, la taille justifies rarement un Index...
 
par contre le typage est important à mes yeux, surtout quand on voit comment certaines personnes codent (certains codent en C comme en perl   )

[jfdsdjhfuetppo]--Message édité par PinG le 06-05-2002 à 11:59:51--[/jfdsdjhfuetppo]

911GT3 a écrit a écrit :

wossoup?

 
Moi je suis un utilisateur Lambda et je veux pas voir disparaître mes fichiers de conf tout cons au 'profit' de fichiers truffés de balises et de synthaxes  

[jfdsdjhfuetppo]--Message édité par 911GT3 le 06-05-2002 à 12:13:44--[/jfdsdjhfuetppo]

911GT3 a écrit a écrit :     Moi je suis un utilisateur Lambda et je veux pas voir disparaître mes fichiers de conf tout cons au 'profit' de fichiers truffés de balises et de synthaxes

moi aussi je suis un utilisateur lambda, mais les conf plain text, c'est merdique quand même... tant pour le dev que pour l'admin que pour les ressources machines...

en plus, tu peux stoquer du binaire, faire des checksums, crypter des mdp facilement, compresser les confs et autres avec ma solution...
c'est quand même vachement mieux...

je dis pas le contraire mais je le conf comment après mon pure-ftpd ?

berk aux abris un baril de lessive !!

PinG a écrit a écrit : mais bon, XMLShema, ca me parait un peut lourd pour un fichier de conf

 
Le ficheir de conf est pas en shema dans ce cas, il est en XML, c'est la descr'iption du format du fichier de conf qui est en schema.

au lieu de plusieurs petits fichiers conf, je propose une bonne grosse base de registre à la windows, qui fait tout ramer + on ajoute de trucs
 
A+

ouaip, j'avais bien compris, mais un des avantages du XML que j'ai cité, c'est qu'une petite lecture du DTD te permettais de comprendre la gueule du .conf, alors que des Shémas, faut voir la geule que ca a...

bah soit on créé un éditeur spécial, ou un mode majeur emacs, ou encore un script qui convertit depuis un plain-text en db3...

Je vote pour la 2 !
Emacs j'ai essayé je peux pas   et puis 20Mo pour 3 fichiers de 2ko

911GT3 a écrit a écrit : Je vote pour la 2 ! Emacs j'ai essayé je peux pas   et puis 20Mo pour 3 fichiers de 2ko

c'est quoi la 2?

pas réveillé ?  
 

 
Edit: oups! C'était la 3

[jfdsdjhfuetppo]--Message édité par 911GT3 le 06-05-2002 à 16:04:45--[/jfdsdjhfuetppo]

 
ca existe deja pour pureftp quand tu configures avec pure-pw + puredb tout ce que tu fais c est remplir un fichier texte tres semblable a un fichier password , et a partir de ce fichier tu crée
une base puredb.

je sait, ne t'en fait pas
c'est un exemple.