Citat:
bojan_bozovic:
Performanse: Brzi je pristup registryju od vremena pristupa tekst fajlovima
Pazi, nisam doktor za Registry, ali... Registry ti vidis kao jedan file. I to binarni file. Medjutim, fizicki je i on razbijen na delove, pa tako snimljen na disk. Grubo mozemo reci da je prikaz Registry-a kao jednog binarnog file-a i prateci API zapravo "fasada", da se posluzim terminologijom Design Pattern-a. :) Tako da, pristup Registry bazi jeste istovremeno pristup nekom file-u na disku. Da ovo bude malo jasnije, ako se ne varam, kada se ucitava Registry, OS ne trpa ceo sadrzaj registrya sa diska u memoriju. Sto znaci da ce po potrebi da se obraca disku da ucitava podatke. E sada, stos je da on ne drzi logicki povezane podatke istovremeno i fizicki povezanim. Da bi opet ostvario neke untrasnje veze, postoje tu i neki untrasnji mehanizmi za mapiranje i indeksiranje da bi se ubrzao pristup itd. Povrh svega, mislim da je "engine" koji se svim tim bavi u kernelu sto je dodatni performance hit (to je, kako je meni objasnjeno, razlog zasto su npr. mutexi na Windowsu uzasno spori).
Sve ovo bi lepo funkcionisalo, da Registry nije opterecen zaista svim i svacim i da nije neizleciv od djubreta. Meni se npr. digla kosa na glavi kada sam prvi put ugledao razne Recently Used Documents liste u Registry-u, posebno one koje su zapisale MS Office aplikacije. Zamisli uzas indeksiranja i reindeksiranja prilikom tako cestih upisa i brisanja unosa. Siguran sam ja da su u MS-u dali sve od sebe da optimizuju ove operacije, ali nije ni optimizacija svemocan lek.
Znaci, glavna caka glede performansi je sto svi settings-i u Registry-u dele "istu sudbinu" (da se tako izrazim), odn.da u pogledu performansi uticu jedni na druge. Jos vise i jos dalje, svi uticu na razlicite postavke sistema koje su od vaznosti za opsti rad i konkretno za podizanje sistema. Efekat gomilanja djubreta u Registry-u se lepo primeti posle duze upotrebe, kada podizanje sistema postaje sve sporije i sporije. To i jeste problem sa ovim centralizovanim pristupom u pogledu performansi.
Ako bi pristupio conf file-u, pristupas samo onom koji te interesuje. Takodje, postavke koje se generalno cuvaju u conf file-ovima obicno se ucitavaju se prilikom startovanja aplikacije i cuvaju u nekim njenim globalnim promenljivim. Takodje, aplikacije koje podrazumevaju postojanje prave baze podataka i rad sa njom, obicno ovakve conf file-ove vole da cuvaju u bazi. No, obzirom da se ti setinzi citaju prilikom starta aplikacije, Performance hit ne dolazi do izrazaja jer podrazumeva obracanje disku u samo tom jednom trenutku. Takodje, podaci koji se odnose na jednu aplikaciju "ne maltretiraju" neku drugu aplikaciju ako za to nema potrebe. Junk koji bi se stvarao na ovaj nacin ne tretira se odvojeno, vec kao jedinstveni problem kao i svaki drugi junk na disku.
Citat:
Stabilnost: A restore points? Nisu moguci sa conf fajlovima! Kako bi sa conf fajlovima napravio restore point za ceo sistem, ako ne znas ni gde su ni koje treba da ukljucis?
Restore Points nisu bas znak stabilnosti vec vise rescue opcija. Kada govorim o stabilnosti sistema, onda pre mislim na one situacije kada greske u integritetu registry-a dovode do pucanja aplikacija u sred rada. Jos su tezi slucajevi kada dodje do takvih gresaka u Registry koje dovode do nemogucnosti podizanja sistema. Tada krece Restore itd...
Ova vrsta nestabilnosti, po mom misljenju, upravo dolazi iz cinjenice da je Registry jedan centralizovan repository za razlicite postavke i podatke koje aplikacije koriste i cuvaju. Pristup je lak, i moze doci da razlicitih povreda integriteta Registry-a. Sa druge strane, odrzavanje tog integriteta je veoma komplikovano, pa je stabilnost time dodatno ugrozena.
Kod conf file-ova (eh, ne zelim da pomislis kako zastupam misljenje da su conf file-ovi superiorno resenje, ovo je samo odgovor na tvoju pricu), stabilnost dobijas time sto je smanjena odn. nepostojeca je korelacija izmedju postavki i onoga sto pisu/brisu razlicite aplikacije.
Citat:
Bezbednost: Taj malware bi mogao promeniti podatke i u conf fajlovima, kako bi se to razlikovalo?
Kada govorimo o bezbednosti conf file-ova, imamo u stvari opste pitanje bezbednosti osnovnih I/O operacija na disku i sigurnosti file sistema. Medjutim, kod Registry-a imamo dodatno pitanje bezbednosti samog API-a i mogucnosti eksploatacije slozenog sistema odrzavanja Registry-a. Takodje, Registry je (opet da spomenemo) "opste dobro", odnosno od njega zavise svi koji ga koriste (aplikacije, servisi itd.). U stvari, koliko malware primera znas da su se pokretali time sto su upisali neki unos u neki conf file, a koliko njih se pokretalo kada bi se upisali u start - up (ili kako se vec zove) sekciju Registry-a ili neki drugi deo Registry-a.
Kao ilustracija slozenosti "lecenja" od ovakvih slucajeva jesu razne instrukcije za uklanjanje malware-a. Dakle, kada se dijagnostifikuje ko je problem, onda ide lista Registry unosa koje treba obrisati ili izmeniti. To je jako tesko prethodno valjano otkriti. Citanje tekstualnih file-ova je nesto ipak mnogo lakse...
Da zakljucim: Registry je jedinstven u sistemu. Svi koji zavise od njega su potencijalno ugrozeni problemima koji mogu da ga pogode, bez obzira ko je uzrokovao te probleme: nepazljivi korisnik racunara, (neodgovorni) programer ili cyber kriminalac.