Newsgroup: it.comp.os.linux.software
Titolo: Linux e il registro di Windows

Esiste per Linux qualcosa tipo il registro di Windows?
Cio� un database di settaggi che raccolga tutte le impostazioni di un 
programma, accessibile dai programmi tramite chiamate standard?

 programma, accessibile dai programmi tramite chiamate standard?
 
/etc
 

 programma, accessibile dai programmi tramite chiamate standard?
 
E qui non ci capiamo. Devi essere tu ad accedere alla configurazioni
dei programmi e non un programma ad accedere alle configurazioni 
degli altri programmi.

 /etc
 
Hai detto la cazzata quotidiana.
 
/etc è solo la directory dove, tra le altre cose, risiedono alcuni
dei file di configurazione di sistema, e nemmeno tutti. Ad esempio
i file di configurazione personali generalmente stanno in $HOME.


Meno male che ci sei tu a correggermi...
 

 programma, accessibile dai programmi tramite chiamate standard?
 
Se escludiamo qualcosa che lo sostituisca come /etc o le impostazioni 
utente, in gnome abbiamo qualcosa di simile
Ma per gnome, non per tutto il sistema
 

 ...
 
Se qualche coglione sente la necessità di dire questo significa che 
qualche altro coglione lo ha già fatto ed ha provocato molti danni. 
Un'altra ragione per stare alla larga da GNOME e da Ubuntu.
 
Da accapponare la pelle 
 

 i file di configurazione personali generalmente stanno in $HOME.
 
Sembrerebbe una svista. Non sarebbe stato meglio parlare di 
/us/local/etc ? Le configurazioni personali stanno nelle directory 
./apps/  sotto, la gerarchia della home di ciascun utente, non 
le configurazioni di sistema, 
Forse, ma era voluto per sottolineare che le impostazioni e le 
preferenze personali sono separate dalle impostazioni di sistema
per non fare danni eventuali.
 
 


Ho solo scritto che esiste, sulla sua fama lascio la palla e la 
responsabilità  all' utente
 

 [,..] lascio la palla e la responsabilità  all' utente
 
Responsabilità all'utente? Stai scherzando? 
 
O semplicemente te ne stai lavando perché non vuoi entrare 
in una discussione inutile?
 
Concordo.
 

 Un'altra ragione per stare alla larga da GNOME e da Ubuntu.
 
Posto che sono d'accordo in toto con la tua affermazione, vorrei far notare 
che GNOME non c'entra niente con Ubuntu
 
Enrico

 /us/local/etc ?
 
No. Le configurazioni utente, non quelle di sistema (o meglio, globali), 
sono tassativamente sotto $HOME proprio per permettere una personalizzazione 
dell'ambiente a livello di utente. La directory da te citata non puo` quindi 
permettere configurazioni utente, in virtu` del fatto che e` preposta per 
quei software installati manualmente (ovvero tramite sorgenti) 
dall'amministratore. Inoltre, Freedesktop ha definito uno standard per le 
configurazioni utente (le directory ~/.config ~/.local e ~/.cache), anche se 
per motivi storici non tutti lo seguono
 
Enrico

 vorrei far notare che GNOME non c'entra niente con Ubuntu
 
... cetera censeo Chartago delenda est. 
 

 ...
 
Mi sono spiegato male; /usr/local/etc/* è un esempio di file di 
configurazione globale (grazie per la correzione) che non si trova sotto la 
directory /etc. 
Nel discorso precedente parlavo di configurazioni globali, poi sono saltato 
alle configurazioni di utente senza nessun apparente motivo. Volevo 
spiegarmi meglio ma vedo che non ci sono riuscito.
 
 
 


Intendevo tipo 'utente avvisato mezzo salvato'
Personalmente qualche piccola modifica in passato l' ho fatta a gconf e 
problemi non ne ho avuti
Roba da niente tipo modificare il valore di qualche chiave
 
 

 
https://projects.gnome.org/gconf/
 
 
Aggiornati:
https://wiki.gnome.org/Projects/dconf
 
 

 Per fortuna no.
 
Stavo per rispondere la stessa cosa! :-O
 
-- 
Massimo Bacilieri AKA Crononauta

 degli altri programmi.
 
Avresti ragione se potessi fare tutte le configurazioni con dei 
jumperini hardware, come sulle vecchie motherboard... ma per accedere 
alle configurazioni dei programmi in /etc *devo* usare un editor di 
testo, che è un programma. Posso usare l'editor di testo che voglio, ok, 
ma comunque non mi salvo: un editor lo devo usare.
 
Dall'altra parte il mio programma dovrà implementare un parser di testo 
per leggere le impostazioni da un file (con potenziali casini di 
permessi, directory ecc.), quando invece potrebbe chiamare il sistema e 
leggersele senza fare tanto casino.
 
 

 Ma per gnome, non per tutto il sistema
 
Quindi, se non erro, gconf?
 
Se funziona per gnome allora non vedo perché non dovrebbe fungere anche 
per altri programmi... no? io faccio il mio programmino, ci metto le 
chiamate a gconf e sto apposto...
 
 
 


Perchè è stato fatto solo per gnome
Che piaccia o non piaccia è cosi, e non si vede il motivo perchè un 
utente che per qualsiasi motivo non voglia gnome deve per forza 
installare un pezzetto di gnome perchè tu vuoi il registry
 
 

 leggersele senza fare tanto casino.
 
Cioè tu proponi una soluzione molto incasinata e piena di possibili
buchi, quale il registro di Windows) solo per facilitare la vita a
programmatori incompetenti? Vattene via trolletto.
 

 testuale incasini solo il tuo programma.
 
Sì, sì... quanti programmi hai scritto in vita tua? Tipo... quasi uno? 
In bashscript?
 
Per il troll: vatti a rileggere il tono con cui rispondi alla gente (non 
me) qui e su forum commons e poi guardati allo specchio. Avrai una bella 
sorpresa ;-)
 
 

 In bashscript?
 
Sì esatto. Quasi uno in più di te.
 

 installare un pezzetto di gnome perchè tu vuoi il registry
 
Motivi ce ne potrebbero essere; ad esempio quello inverso al mio che,
pur usando Gnome3 e quindi le librerie grafiche GTK3, accetto di buon
grado di installare anche libqtcore4 e libqtgui4 (normalmente utilizzate
in KDE), pur di poter disporre di VLC, media-player che io ritengo
ottimo e del quale non desidero fare a meno.
 
*Ripeto*: Gconf da alcuni anni e` stato sostituito da Dconf che, come
leggo nella descrizione del pacchetto, e` "un database chiave/valore a
basso livello progettato per archiviare le impostazioni di un ambiente
desktop".
 
La retrocompatibilita` per chi avesse sul sistema vecchie configurazioni
fatte con l'ormai obsoleto gconf e` pero` ancora garantita tramite
gsettings-data-convert che esegue la migrazione delle impostazioni
utente da GConf a DConf.
 
Nulla vieta quindi ad un programmatore di scegliere di integrare
perfettamente la sua applicazione in Gnome3 utilizzando il framework
GTK+ e di permetterne la configurazione comunicando tramite D-Bus con il
servizio DConf.
 
E` chiaro che poi probabilmente l'installazione di un'applicazione di
questo genere fara` storcere il naso ad un utilizzatore di KDE in quanto
lo abbligherebbe ad installare tutta una serie di pacchetti di
dipendenze altrimenti non necessarie al suo DE.
 

 desktop".
 
DConf-0.18.0 infatti.
 
Quasi perfetto per quello che mi serve. L'unico svantaggio è la 
dipendenza dalle GTK+, ma pazienza...
 
 


Se si sviluppa un pacchetto gnome infatti puo andare
Ma se il pacchetto è per qualche altro DE o command line allora, come 
hai affermato, obbligherebbe l' utilizzatore ad installare sw che non è 
compreso nel DE usato
Senza parlare di un sw  orientato alla linea di comando, ad esempio nei 
server
Installare questo sw aggiuntivo potrebbe essere troppo
Dal mio punto di vista non lo farei,userei delle impostazioni globali in 
/etc o /usr/local/etc e utente in $HOME/.<nome_appl> in file di 
configurazione classici
 
 
 

 In bashscript?
 
Io ho scritto parecchio codice, e mai mi e` venuto in mente di usare un 
sistema alla Windows, tanto che fu uno dei motivi per cui abbandonai 
definitivamente GNOME e passai a KDE
 
Enrico

 Quasi perfetto per quello che mi serve.
 
Ma usare una libreria che gestisca un file di testo che abbia una struttura 
di tipo INI (ovvero sezione->chiave->valore) e cercare il  file di 
configurazione in una posizione precisa del sistema (e.g. ~/.config o /etc)? 
Di lilbrerie del genere ce ne sono a miliardi in giro sull'internet, per 
qualsiasi linguaggio di programmazione (o quasi) ti venga in mente, ma 
soprattutto, non richiedono inutili dipendenze a programmi esterni
 
Enrico

 /etc)? 
 
Troppo semplice. Si rischia di non fare casini, di non aggiungere bug
e di non inventare l'acqua calda. ;-)
 
 

 dipendenze altrimenti non necessarie al suo DE.
 
Non storcere il naso ma e una scelta che comunque comporta installare 
due ambienti grafici full optional o quasi, due librerie, due display 
manager et cetera, cioè raddoppiare il consumo di risorse per poi 
ottenere pochissimi vantaggi. Non quindi una scelta da prendere alla 
leggera ma da ponderare attentamente.
Il discorso cambia se poi usi un ambiente leggero come LXDE; allora 
installare una applicazione non nativa è da escludere a priori perché 
va contro la prima ragione per cui si sceglie un ambiente leggero.


Facebook: Massimo Bacilieri

 servizio DConf.
 
E tutto questo delirio per non scrivere un parser che in C saranno 10 
righe? (hint-> ci sono le librerie apposta libconfig che ti mettono a 
disposizione delle funzioni per il parsing delle variabili, se proprio 
non hai voglia di usare 4 funzioni di gestione delle stringhe).
 
Cioè lasciamo che un'unica applicazione scritta col culo ci sputtani 
tutto il sistema, solo per agevolare un mentecatto che si fa chiamare 
programmatore, pur non sapendo fare il parsing di un file rc neanche con 
le funzioni apposta?! Mi par di sognare.


 con le funzioni apposta?! Mi par di sognare.
 
Uso gnome da parecchi anni ma da quel verso non mi si e` mai sputtanato
nulla. E` vero pero` che uso quasi esclusivamente applicazioni che
stanno nel repository ...
Cmq quando modifichi qualcosa dal Menu/Preferenze di una applicazione,
vai si ad incidere sul dconf ma solo a livello utente per cui non
pregiudichi l'intero sistema; poi, faccio un esempio, se l'utente
tramite gsettings vuole modificare una chiave booleana e ci scrive una
stringa, questa semplicemente non viene accettata, non e` che si
inchioda tutto ma viene utilizzato il valore di default.
In dconf poi si puo` tornare sempre allo stato di default iniziale.
 
 

 programma di *quell*'utente.
 
Spezziamo una lancia a favore di gconf/dconf. :)
 
In realtà il tutto si basa su file XML e cartelle, dentro una cartella 
nascosta, e gconf/dconf servono solo per facilitare l'accesso dalle 
applicazioni (compreso il client command line).
 
Quindi è, in astratto, un concetto simile al registro di Windows, ma in 
pratica un sistema simile alla /etc di Linux, con in più il vantaggio di 
avere tutti i file nello stesso formato (XML), e di avere una libreria 
condivisa per l'accesso in lettura e scrittura.
 
Quello che non piace a me è appunto l'XML (che ha un overhead enorme 
rispetto ai dati che memorizza), e che non sia documentato bene a livello 
di parametri disponibili per applicazione.
 
Ma, obiettivamente, con un'interfaccia grafica come dconf-editor è 
abbastanza semplice andare a vedere cosa c'è. Quello che non sa/capisce è 
cosa si può aggiungere e, spesso, che valori possano prendere molti dei 
parametri.
 
Bye.

 di parametri disponibili per applicazione.
 
Potrei sbagliarmi ma da quel che leggo qui:
 
https://wiki.gnome.org/action/show/Projects/dconf?action=show&redirect=dconf
 
 
"Having all of the keys in a single compact binary format also avoids
the intense fragmentation problems currently experienced by the
tree-of-directories-of-xml-files approach."
 
mi pare di capire che a differenza di gconf, dconf non usi piu` l'XML.
 
 

 programma di *quell*'utente.
 
E quando anche succedesse l'irreparabile si cancella il file di
configurazione ed il programma riprende a funzionare come 
prima. (AFAIK solo con pochissimi programmi, come grub
e XWindow, si possono avere gravi problemi manomettendo 
i file di configurazione)

 parametri.
 
Non so se essere d'accordo o meno; ti contraddici. Dapprima dici che
l'interfacci grafica è più chiara (ma più chiara di cosa) e poi affermi che 
ti nasconde molte cose (e quindi implichi che non è molto chiara). Mah!
 
Invece ciò con cui non sono affatto d'accordo è che una interfaccia 
grafica  è abbastanza semplice vedere cosa c'è; su questo punto è 
meglio avere una documentazione completa e chiara.


 
Lungi da me difendere il registry di Windows, ma anche li le 
impostazioni utente stanno dentro la home dell'utente...
 
http://en.wikipedia.org/wiki/Microsoft_Windows_profile#Profile_contents
 

 impostazioni utente stanno dentro la home dell'utente...
 
Cambia poco; il concetto di database unico delle impostazioni è sbagliato.
 
 

 Cambia poco; il concetto di database unico delle impostazioni è sbagliato.
 
giusto
meglio annotarsi le impostazioni su un taccuino con la matita e poi 
reimpostare ogni volta i programmi :-D
 
a me risulta che sia in .gconf che .config ci siano cartelle (so che 
directory ti piace troppo) separate per ogni applicazione quindi - 
tanto per cambiare - si tratta del solito senseless ranting
 
-- 
bye
!(!1|1)
 

 impostazioni utente stanno dentro la home dell'utente...
 
Il guaio è che _adesso_ è così. Ma prima no... la maledizione di 
Windows, il passato che ti lega sempre le mani.
 
 


In windows le impostazioni utente stanno un po nel registry (un file 
nella home utente) ed altri in comunissimi files (un cartella nascosta)
tipo stile unix
Quindi è un po un mix delle due cose

 tanto per cambiare - si tratta del solito senseless ranting
 
Sai leggere? Si tratta sempre di un database unico implementato 
in modo diverso: o hai un solo programma che accede a tanti file di 
configurazione o hai tanti programmi che accedono ad un solo 
database. In entrambi casi hai un unico punto di guasto. Questo per
dconf/gconf; con il sistema Unix tradizionale il problema non si
pone, ogni programma è indipendente dagli altri (almeno per i propri 
file di configurazione).
 
Invece per il registro di Windows la cosa è anche peggio: almeno con
dconf non rischi di non poter avviare il computer, cosa che invece mi
è successa dopo aver incasinato il registro di Windows '98.
 
addio
 

Addì  venerdì 27 dicembre 2013 15:12 Massimo Soricetti scrisse:

Su questo  puoi aver ragione ma resta sempre il dato di fondo; 
il registro è sbagliato.
 
 

 Quindi è un po un mix delle due cose
 
Però fai attenzione a non confondere le cose: ho il sospetto che sia 
cosi *attualmente*  solo perché alcuni programmi di terze parti usano 
i propri file di configurazione non fidandosi del registro. 

 di windows
 
...vabbè, tanto ormai mi sono fatto la fama di troll... andiamo dunque 
fino in fondo.
 
Nessuno nega i difetti del registro di sistema di Windows, che per 
inciso nascono in maggioranza dal fatto di non aver previsto dei livelli 
di privilegio per accedere alle varie sezioni, un difetto comune a tutta 
la sicurezza windows.
 
Ma ti devo dire che il sistema dei file di config testuali che usa Unix 
non è mica tanto meglio. Millemila file diversi, tutti con sintassi 
diverse, e NON stanno nemmeno tutti quanti in /etc, e quando li cerchi 
devi sempre vedere in che cazzo di sottodir l'hanno ficcati in quella 
particolare distribuzione. E cambiano pure posto da una versione 
all'altra di una stessa distro, per giunta.
 
Se credi che sia un difetto da poco prova a scrivere un programma non 
banale, o un driver, che si autoinstalli e funzioni al primo colpo su 
OGNI distro in circolazione, poi ne riparliamo. O a fare assistenza su 
Linux-tutte-le-versioni. Telefonica, magari, lavorando da un call center :-D
 
Senza contare i tentativi negli anni, tutti falliti, di creare un 
programma che permettesse di governare in un colpo solo tutte le 
impostazioni di Linux: debconf per esempio, oppure i vari control panel 
di KDE e Gnome. Bene che vada ti permettono di modificare le 
impostazioni del desktop environment e poco altro, perché di fatto 
mettersi prima a cercare, poi a leggere e in ultimo a decodificare tutti 
i vari config file in /etc (e come detto non sono manco tutti lì dentro) 
è un'impresa impossibile.
 
Tutto questo casino per fare cosa? Per salvare in modo permanente una 
collezione (named) di queste due cose:
1) una stringa (path, url, email, opzioni di command line, sarca$$o);
2) un numero (al limite un solo bit per le opzioni true/false).
 
A questo punto, visto che tutti i programmi devono fare la stessa cosa, 
tanto vale creare un meccanismo a livello di sistema che lo faccia per 
tutti nello stesso modo e con più efficienza.
Già il fatto che Gconf e Dconf *esistano* e siano l'uno l'evoluzione 
dell'altro dovrebbe suggerirti che l'idea non è tanto peregrina... ha un 
suo perché.
 
"Ma così diventa un casino come su Windows": no, se implementi un 
meccanismo di registry decente.
Il filesystem /proc è già qualcosa di molto simile al registro di 
windows, per esempio: vuoi venirmi a dire che /proc è una cagata?
 
Per rispondere in anticipo agli argomenti da Vero Programmatore tipo "su 
Unix si fa così", "incapace, non sai manco scrivere un parser" ecc. 
ecc.: ai tempi di Unix si poteva fare *solo* così. E quando programmo, 
più cose fa il sistema e meno me ne devo accollare io. Si chiama 
produttività.
 


Credo che sia cosi da win7 o vista in poi
Comunque il metodo è ufficializzato da M$
 

 produttività.
 
Vedi sopra. È produttivo finché funziona. Poi... *zzi acidi.


 avere una documentazione completa e chiara.
 
Su questo siamo d'accordo.
Ma ho notato che (in generale) la documentazione sotto Linux si sta 
abbassando di qualità e di quantità a una velocità preoccupante.
 
Per fare un esempio, Vala (il linguaggio) ha lo stesso "manuale" (tra 
virgolette perché è totalmente inutile) dal 2009. Non è stata aggiunta 
una riga.
 
Gli HOWTO non vengono aggiornati da anni. Le liste di compatibilità delle 
stampanti sono ferme al 2009-2010 (a meno di non andare a vedere il 
singolo manutentore).
 
Io sono un po' preoccupato...
 
Bye.

 windows, per esempio: vuoi venirmi a dire che /proc è una cagata?
 
/proc (e /run ) sono due cose *completamente* differenti dal registro di 
sistema. Se nemmeno questo ti e` chiaro, allora ritorno a dire che la 
programmazione su ambienti Linux non fa per te
 
Enrico

 Windows, il passato che ti lega sempre le mani.
 
Che non c'entra una fava, visto che la struttura del registro e` trasparente 
all'applicativo
 
Enrico

 Cambia poco; il concetto di database unico delle impostazioni è sbagliato.
 
Questa frase mi fa pensare a PAM_LDAP e a 389ds :D
 
Enrico
P.S. no, OpenLDAP non lo cito nemmeno morto...

 gravi problemi manomettendo i file di configurazione
 
GRUB sicuramente, X Window no in quanto oramai va in autoconfigurazione (usa 
il file di configurazione solo per forzare determinati parametri)
 
Enrico
 

 binario).
 
La soluzione c'e`, e si chiama XDG (per coloro che la implementano). E non 
richiede alcuna astrazione se non quella di seguire alcune linee guida lato 
sviluppo
 
Enrico

Addì  martedì 31 dicembre 2013 00:47 Enrico 'Henryx' Bianchi scrisse:

Tempo fa con Xorg ho impostato una risoluzione non supportata dal 
mio monitor e non riuscivo ad accedere al sistema. Poi ho risolto 
in  pochi minuti avviando con la live ma ancora non riesco a capire 
come mai non sono riuscito a loggarmi in modalità testuale. Mah.
 
 
 

 .... 
 
Condivido

 Io sono un po' preoccupato...
 
Anche io. Il software libero è collaborativo, ognuno dà il suo contributo;
se sei su USENET per ricevere aiuto senza darne, per impicciarti e spiare
(cioè lurkare), o trollare, cambia strada, non sei gradito.
Certo non è il caso tuo, non so se fai già queste cose, ma certo ci sono 
tanti che pensino basti installare Linux e pretendere aiuto gratuito.
 
 
 
 
 
 
 

 Altra cosa che è male.
 
^^^^^^^^^^^^^^^^^^^^^^^^^ ...
 

Windows, il passato che ti lega sempre le mani.
 
Butto il mio bicchierino di benzina sul fuoco: mi pare che si stia
discutendo se sia meglio caffe' col latte o latte col caffe'.
 
Un filesystem *E'* un database. Invece di una SELECT usi chdir() e
fopen() etc., ma in entrambi i casi - piu' file separati su disco,
oppure un database "esplicito" - hai delle API, per accedere a dei
dati, dei permessi che decidono chi accede a che cosa, eccetera.
 
Funzionalmente, fra XML e un albero padre-figlio in SQL non esiste
la minima differenza (tant'e' vero che si puo' trasformare uno XML
di quel tipo in EAV e viceversa senza perdita di informazioni).
 
Quello che puo' fare la differenza e' quanto e' accessibile, senza
usare le API preposte, il sistema sottostante. Perche' questo dopo
mi influenza l'estendibilita' del sistema (e cose tipo: quanto, in
caso di disastro, posso recuperare dai rottami fumanti?).
 
Un sistema di registry globale deve avere solo separazione fra gli
utenti e accessibilita' "ordinaria" (cioe', non-root) protetta via
API robuste. Una volta che c'e' questo, che uno lo faccia mediante
chiamate accessor/mutator o parsando dei file .INI o .conf, cambia
esattamente zero per le "features". Ovviamente non ci deve proprio
essere una API utente che consenta un DELETE WHERE TRUE, e, al suo
posto, ci sara' "boolean deleteRegistryKey(const char *fullpath)".
 
Leonardo
 
-- 
 
Then felt I like some watcher of the skies, when a new planet swims into his ken;
Or like stout Cortez when with eagle eyes, he star'd at the Pacific; and all his men
Look'd at each other with a wild surmise - silent, upon a peak in Darien.

 API robuste. ...
 
Non solo. La separazione deve avvenire a livello di applicazione e 
non di utente, deve essere flessibile (nel senso che ogni applicativo
deve fare ciò che gli pare), deve essere espandibile e  deve essere 
robusto rispetto ai  guasti; sono cose che è facile ottenere con un
filesystem qualsiasi e tanti file testuali ( binari che siano.
 
 

 ... Guarda che ci può essere un modo migliore.
 
No senza adottare un database /fault/ /tolerant/ per ambienti 
/mission/ /critical/ tipo Oracle.  
 
 
 

filesystem qualsiasi e tanti file testuali ( binari che siano.
 
Ma anche con un database e una API, via.
 
Anzi, siccome come si diceva le funzioni (e dunque le interfacce) sono
in gran parte le stesse per DB, FS e big XML, si potrebbe "facilmente"
realizzare un front-end di configurazione (configd?), con piu' backend
verso SQLite, MySQL, /etc, ~/.config e cosi' via. E magari perfino con
la possibilita' di proxare un server config centrale.
 
Certo: il configd toccherebbe configurarlo da linea di comando :-D


 verso SQLite, MySQL, /etc, ~/.config e cosi' via.
 
http://www.freedesktop.org/wiki/Software/Elektra/
 
 
Enrico
P.S. ed il bello e` che lo stavo cercando ad inizio thread :D


Fiiigo. Lo provo subito :-D


 
http://www.freedesktop.org/wiki/Software/Elektra/
 
 
OH OH questa s� che � manna ^___^

 
http://www.freedesktop.org/wiki/Software/Elektra/
 
 
al momento la sua diffusione � ancora ridotta
 
 
su Debian testing l'unica cosa che dipende da elektra sono gli altri
pezzi di elektra
------------------------------------------------------------------------
$ apt-cache rdepends libelektra3
libelektra3
Reverse Depends:
  libelektra3:i386
  libelektratools2
  libelektra-dev
  libelektra-cpp0
  elektra-bin
$
------------------------------------------------------------------------
 
 
e non c'� nessun modulo in Python per interfacciarsi ad elektra!
------------------------------------------------------------------------
https://pypi.python.org/pypi?%3Aaction=search&term=elektra&submit=search
 
 
Index of Packages Matching 'elektra'
There were no matches.
------------------------------------------------------------------------

 al momento la sua diffusione è ancora ridotta
 
Penso che ci siano veramente pochi progetti che usano Elektra, proprio 
perche` e` un modo di concepire la configurazione completamente differente 
da come ci si e` abituati (e, vogliamo ripeterlo, di librerie per scrivere 
file di configurazione testuali aventi la stessa struttura, ne e` pieno il 
mondo)
 
Enrico