On Fri, 25 Jul 2003, zavandi wrote:
> Ar putea exista fisiere de backup. Din nou, problema nu e ideea de
> registry, ci implementarea.
Iata mai jos cateva motive:
1) De multe ori, fisierele de configurare text din Unix nu sunt doar linii
de forma:
cheie = valoare
ci au o structura mai completa, semanand mai mult cu un fel de limbaj de
programare. De exemplu, o directiva din httpd.conf
<IfModule modul1.c>
modul1_optiune1 aaa
modul1_optiune2 bbb
<IfModule modul2.c>
modul2_optiune1 aaa
modul2_optiune1 aaa
</IfModule>
</IfModule>
Sau alt exemplu din /etc/pcmcia/ide.opts:
# ATA/IDE drive adapter configuration
# The address format is "scheme,socket,serial_no[,part]".
# For multi-partition devices, first return list of partitions in
# $PARTS. Then, we'll get called for each partition.
case "$ADDRESS" in
*,*,*,1)
#INFO="Sample IDE setup"
#DO_FSTAB="y" ; DO_FSCK="y" ; DO_MOUNT="y"
#FSTYPE="msdos"
#OPTS=""
#MOUNTPT="/mnt/ide"
;;
*,*,*)
#PARTS="1"
# Card eject policy options
NO_CHECK=n
NO_FUSER=n
;;
esac
2) Alteori, fisierele de configurare pot contine expresii regulate, pe
care le poti "sparge" in mai multe linii, etc. Exrpesiile regulate sunt niste
mecanisme foarte puternice, dar prin natura lor sunt mai mult text-based
decat GUI-based. Exemplu din `man procmailex`:
Forward all mail from peter about compilers to william (and keep a copy
of it here in petcompil).
:0
* ^From.*peter
* ^Subject:.*compilers
{
:0 c
! [EMAIL PROTECTED]
:0
petcompil
}
(in paranteza fie spus, dupa parerea mea puterea si flexibilitatea lui
procmail nu se compara cu nici un GUI de mailer din lume).
3) Uneori, vrem sa facem disable la anumite optiuni fara sa stergem
valorile unei anumite chei. Sa presupunem ca intr-o aplicatie avem o
valoare care reprezinta coordonatele unei anumite ferestre in forma
"x1,y1,x2,y2": Intr-o interfata GUI legata la un registry, aceste valori
iti apar intr-un field. Nu le poti comenta, doar sterge. Intr-un fisier de
configurare text le poti comenta si deci pastra dezactivate.
4) Comentarii. Comentariile sunt de foarte mare ajutor si mai mult, se
alfa localizate nu in nu stiu ce fisiere de help cu chiar impreuna cu
"cheia" in sine, exact in locul cel mai potrivit: in fisierul de
configurare
5) Alt motiv ar fi intuivitatea: este mult mai simplu sa iti amintesti sau
sa deduci cam pe unde se afla un fisier de configurare, decat sa tii minte
exact cheia din registry. Stii ca fisierele de configurare se afla prin
/etc, cauti un fisier care incepe cu numele aplicatiei care nu porneste,
si apoi citind si comentariile din el, poti deduce ce nu ar merge. Ce este
intuitiv aici: HKLM\Software\CLASSES\exefile\shell\open\command ->
"default REG_SZ \"%1\" %* "?
6) Rescue: in caz de dezastru, este mult mai simplu sa faci un mediu de
rescue (de exemplu un CD bootabil) care sa aiba un bootloader, un shell si
un editor de text cu care sa modifici fisierele de configurare text (daca
asta e cauza), decat sa iti faci un mediu de rescue grafic (drivere, etc),
numai pentru regedit.
7) Poti cauta in anumite/toate fisierele de configurare cu grep, care este
o unealta de cautare _mult_ mai puternica decat rudimentarul find. Fie si
numai pentru ca grep suporta, asa cum ii spune si numele, expresii
regulate
8) Referinte. De multe ori in fisierele de configurare apar variabile
globale. De exemplu:
DownloadDir = $HOME/downloads
In windoze parca exista %variabila% sau cam asa ceva. Dar ia incearca sa
faci urmatoarea modificare in registri: "Program Files" sa se cheme
"Applications". Am incercat eu asta pe un Windoze98 cu multi ani in urma
si am avut nevoie de vreo 4 ore de sapaturi in registri ca sa inlocuiesc
stringul "Program Files" in vreo mie de locuri.
9) SPOF. Single point of failure. A gresi e omeneste si e mult mai usor sa
gresesti stergand intreg registry-ul, decat stergand o multime de fisiere
de configurare.
10) Majoritatea admnilor prefera modul text pentru administrare (vorbim
aici inclusiv de cel mai eficient mod de remote admin: ssh), si este mult
mai simplu sa folosesti un editor text decat o aplicatie text-mode cu
tree-view, etc).
11) Totul este la vedere. Registrii sunt un foarte bun loc de a ascunde
functionalitati. Sa iti dau urmatorul exemplu: vrea ca pe desktop-ul lui
Windoze sa am un icon (de folder) care cand se da dublu click pe el imi
deschide un anumit folder: C:\cale. Atentie, nu vreau shortcut! Si nu
vreau ca folderul respectiv sa fie subfolder de-al lui Desktop! Vreau un
fel de icon "My Document" creat de mine. Tin minte ca am sapat o multime
si nu am reusit. Desi tehnic se poate. Formatul binar nu se potriveste cu
filosofia free software: "totul la vedere".
Cu multi ani in urma, pe cand incepeam sa ma joc cu C++ si descopeream
Linux-ul (si eram la etapa entuziasta a re-inventarii rotii de unul singur
:-) ), am incercat sa fac eu un fel de registry-settings system pe Linux.
Desi il facusem sa mearga pana la urma, experienta acumulata ca admin m-a
convins ca fisierele text sunt cea mai _comoda/intuitiva_ solutie.
Iar ca programator nu e mare diferenta, pentru ca si pentru fisierele text
de configurare exista librarii gata scrise pentru parsare, deci a folosi
registri sau fisiere text nu implica diferente de efort de programare prea
mari. Dimpotriva, riscul ca aplicatia in faza de development sa altereze
intreg registry-ul este inexistent.
Si in final, inca un argument. Dupa atatia ani de fisiere binare, formatul
pentru schimbul de date care se impune este XML, care este text-based.
Tocmai datorita faptului ca oamenilor le va veni intotdeauna mai usor sa
"parseze" vizual text decat sa fie dependenti de nu stiu ce utilitare
obscure pentru a intelege formatul unor date.
Ave,
Radu
--
Radu Filip
Network Administrator @ Technical University of Iasi
[EMAIL PROTECTED] Information Technology and Communication Center
http://socrate.tuiasi.ro/ [EMAIL PROTECTED] | http://ccti.tuiasi.ro/
