-
remark #278
"Mikozben pont az irja Kegemusha hogy az ini file GUI nelkul is szerkesztheto (olvashato) a registry meg kodolt (binaris)."
"A registry is többnyire szöveges."
Olyan nincs hogy "tobbnyire szoveges". Vagy text fajl, vagy binaris. A registry melyik? Ne a beleirt adatokat mondd, hanem azt hogy maga a fajl milyen?
Egyebkent pedig: http://support.microsoft.com/kb/256986 "Registry data is stored in binary files."
Szoval miert is van az hogy az egyertelmu dolgokrol is vitatkozni kell veled?
"Mivel a regedit ugyanúgy adott, mint a notepad, ugyanúgy kézi szerkesztésnek minősül."
A regedit az egy specialis, direkt egyfele fajlformatumhoz irt szerkeszto program. Ha szerinted ez "kezi" szerkesztes, akkor az egyszerubb .doc fajlok szerkesztese Wordpad-dal is kezi szerkesztes...
"A regedit-tel bármelyik program registry bejegyzését szerkeszthetem, ahogy a notepad meg minden ini fájlt kezel."
Szereny velemenyem szerint az ervelesed a valosagtol teljesen elrugaszkodott. A regedit a registry-hez keszult szerkeszto program, mig a notepad nem ini fajlok szerkesztesehez keszult, valamint ini fajlokat nem csak notepad-dal lehet szerkeszteni.
"Az API-t egyszer kell csak beüzemelni."
Az hogy hanyszor kell beuzemelni, annak semmi koze a kerdeshez.
"De API-zok, mert van API."
Nem az a kerdes hogy van-e api, hanem az, hogy mindket formatumhoz van api, ergo az api meglete az nem szol a registry mellett. Mas szolhat a registry mellett, dehogy pont az api legyen az!!! Ertelmetlen. Mielott eltero ini formatumok problemajat hozod fel, olvass tovabb, lesz errol is szo.
Hogy ne kelljen keresgelni, idehelyezem ezt a reszt is:
>>> "Nem kell hogy te kezeld az ini fajlt, ha nem akarod"
Egyes formátumokhoz lehet, hogy van API, de mindhez biztosan nem. <<<
Itt most az ini fajl kezelesevel kapcsolatban arrol volt szo hogy ha te magad dontenel ugy hogy az adataidat ini fajlba helyezed, akkor mivel van API, ezert az ini fajl kezelese konnyu. Most probalok elkepzelni egy olyan esetet, mikor en irok egy programot, aminek "minden" ini "fajltipust" kezelnie kell. De nem tudok. Szoval milyen gyakorlati haszna van egy "minden" ini "fajltipust" kezelni tudo API-nak?
"Akkor mondok egyet : C++."
Ha te azt mondod hogy a C++-ban konnyebb egy kulcsot kiolvasni a registry-bol mint kiolvasni egy sort egy szovegfajlbol (merthogy ez volt az eredeti felvetes) akkor azt neked elhiszem. ;-)
"De nagyjából bármelyik nyelvet mondhatnám, amelyiken elérhető a megfelelő API."
Egyebkent nemreg epp Perl-ben jott elo ez a kerdes, es Perl-ben nagsagrendekkel konnyebb szoveges fajlokat kezelni mint registry-t, hiaba van API a registry kezeleshez. Ha azt hasonlitom hogy az ini fajl API-jat konnyebb kezelni vagy a registry API-jat akkor megintcsak az ini fajlt egyszerubb kezelni, szimplan azert mert az ini formatuma egyszerubb es ennek megfeleloen az azt kezelo API is egyszerubb. Logikusan hangzik, nem?
>>> "A registry _formatumat_ nehezebb elrontani."
Én is ezt mondom. <<<
Nem. Te ezt nem mondod, hanem szajkozod. Akkor is ezt irod, amikor en nem is errol beszelek, es nem vagy hajlando (kepes?) felfogni hogy mit irok en. A felvetesek igy kovetik egymast:
remark: "Mondom funkcionalisan: mint eltarolom az adatot, kiolvasom az adatot. Ha elrontom az egeszet [olvasast/irast], borul a programom igy is ugy is mert ahogy mar emlitettem, az adatnak is van szintaxisa..."
BiroAndras: "De a registry-t sokkal nehezebb elrontani (hacsak nem szándékossan csinálod)."
(lehet hogy a registry-t nehezebb elrontani, TE ezt mondod, de EN nem erre hivatkozok, ergo nem erted hogy mirol beszelek)
remark: "Nem. A registry _formatumat_ nehezebb elrontani. Igy ertettem en. Nem mashogy. A registrybe is ugyanugy irhatsz hulyeseget, ..."
(figyelmeztetlek hogy nem a registry formatumarol beszeltem eddig, erre te:)
BiroAndras: "Én is ezt mondom."
(es akkor itt most teljesen kesz vagyok....)
"Nem is kell. Minek választanám a nehezebb utat, aminek semmi előnye sincs?"
Az hogy jon ide hogy te mit valasztanal? Meg hogy neked mi a nehezebb? Meg hogy szerinted semmi elonye? Altalanossagban beszelgetunk, es azert van olyan ember aki felfogja az ini fajl elonyeit is es nem csak a hatranyait, azaz azt valasztja.
>>> "regedit is egy gui!"
Akkor a notepad is. <<<
Ez az erveles ketfele iranybol is tamadhato:
-Ha még a notepad-et GUI-nak is hivod (csak azert mert van benne standard File Edit menu???), annak hivod a notepad alternativait is? Pl. vi?
-A regedit attol GUI mert az kezeli a specialis _binaris_ fajlformatumot. Tartalmaz olyan specialis funkciokat amik a registry specifikusak (mig a notepad nem tartalmaz ini fajl specifikus funkciokat).
A GUI (a vitank szempontjabol) nem attol GUI mert az a windows grafikus kontrolljait hasznalja, es van benne "save as" dialog... Attol GUI mert egy olyan specialis grafikus program (van karakteres registry editor a windows-hoz? tudom, nincs, es tudom, azert nincs, mert minek a gagyi verzio ha van grafikus is, de nem ezt kerdeztem, ugyhogy arra reagalj amit irok) amit kifejezetten ehhez a fajlformatumhoz irtak, nincs alternativaja, es fajlformatum specifikus funkciokat tartalmaz. Ettol GUI. A regedit olyan a registry-hez mint a Word a .doc fajlokhoz. Es a Word az egy GUI.
>>> "Ez nem a kerdesre valasz, ez nem oldja meg a problemat. Ha picit utanajarsz, akkor maris nincs azzal sem problemad hogy hogyan kell a mysql-t konfiguralni ini-ben."
Nos, a registry egyáltalán nem útvesztő... <<<
Es te csak fujod tovabb a magadet. Ha ennyire nem erdekel amit irok, akkor inkabb ne reagalj...
"A mysql vonatkozó részei ellenbensokkal problémásabbak, mivel..."
Mar leirtam 1000x hogy ne a registry-t hasonlitsd a mysql-hez, mert en a kettot sose hasonlitottam, ergo te most itt mire is reagalsz? Ragaszkodsz ahhoz az agyszulemenyedhez hogy a registry hasonlithato a mysql-hez. Nem, kortet nem hasonlitjuk ossze az almaval, csak specialis esetben. De ez biologia ora ahol a korte != alma.
>>> "Pl. ini fajl atfolyathato a standard inputon, igy hasznalhato a parancssorban parameterkent"
Ha nagyon kell, a registry tetszőleges része exportálható textfájlba. <<<
Ha szerinted a textfajlba exportalas lehetosege osszehasonlithato azon szovegfajl kezelesi lehetosegekkel amik unix-on parancssorbol elerhetoek... am legyen, akkor igazad van.
>>> "vagy feldolgozhatod, hasznalhatod shell scriptekben, stb."
A registry-t is. <<<
Lehet, csak nem mindegy a bonyolultsag. Ahogy egy hozzaerto kollegam egyszer mondta: "Minek választanám a nehezebb utat, aminek semmi előnye sincs?" (Egyebkent ne feledd: a konfig fajlokkal kapcsolatban unix-on elerheto flexibilitast hasonlitjuk a windows-on a registry-vel kapcsolatban meglevo (?) flexibilitashoz.)
"A helyreállítás is védelem."
Az MS-fele ertelmezoszotar szerint igen. Az MS ezek szerint ugy definialja a vedelmet es biztonsagot hogy eleg ha kiadnak olyan tool-okat amikkel utolag a rendszer helyreallithato.
"Ezen kívül szerintem nem is hagyja direktben felülírni."
En nem csak a felulirasrol beszelek (ami ellen nem ertem miert kellene vedenie az OS-nek kulon, ez a jogosultsagi rendszer beallitsanak kerdese, vagy mivel 1 fajl, ezert nem lehet egyszeruen a 2000 fele programnak kulonfele jogosultsagokat beallitani hozza, ugye? eh, hat ez kerem a kozpontositott tarolas hatulutoje, es illene beismerni hogy az fajlrendszer szintu vedelem nehezen szabhato testre 1 fajl eseten... (azaz lehetetlen) de egyebkent meg -> ) A vita kezdete ota olyan peldakat hozok fel unix-rol is, hogy ha pl. elcseszodik az a particio amin pl. az oracle konfiguracios fajljai vannak akkor meg a rendszer el es virul, de ha az oracle beallitasai ugyanott vannak ahol minden mas beallitas is, akkor barmi legyen is a hiba, megvan az esely hogy minden mas is elszall. Ez megint nem egy olyan dolog szerintem amit ne lehetne belatni.
"De a lényeg : a tapasztalat azt mutatja, hogy egyáltalán semmi baj sincs a megbízhatóságával."
1) en ugy olvasom lejjebb itten, hogy vannak olyan tapasztalatok miszerint egyes esetekben jobb lenne ha nem ilyen lenne a registry (ugye ez az alapfelvetes, hogy belassuk vegre, hogy _van amikor jobb_ az ini mint a registry)
2) a tapasztalat azt mutatja hogy nincs semmi baj a konfiguracios fajlok megbizhatosagaval (tehat miert lenne a registry mellett szolo erv a biztonsag? foleg ha ilyen erveket is fel lehet hozni mint a tieid, miszerint "a tapasztalat azt mutatja", hat ha ennyi mar erv, akkor a tapasztalat azt is mutatja hogy sokan jol megvannak az ini fajlokkal a mai napig).
"Mi az esélye annak, hogy a registry (mint fájl) megsérül? A tapasztalat szerint elenyésző."
Ebben az egyben _majdnem_ egyetertunk. Annak hogy az 1 darab registry fajl konnyebben megserul, meg annak hogy az 1 darab ini fajl megserul, _csak_ a hadver vagy fajlrendszer eredetu problemakat nezve, nincs jelentos kulonbseg. DE: meg mindig konnyebben megserul az a fajl, amelyiket nagysagrendileg tobbet hasznal a rendszer, mint az amelyiket csak akkor hasznalja mikor alkalmazas specifikus adatokra van szukseg. Ezt gondolom nem nehez belatni, mert trivialis. 1 darab registry 1 darab fajlredszeri bejegyzes (most leszamitva a windows automatikus vedelmi ficsoreit ami a registry-hez kapcsolodik). 200 konfig fajl, az 200 bejegyzes, egymastol tavol (mas particion, fizikailag masik merevlemezen, masik gepen akar (!)), az ugye nagyobb vedelem. 200x kisebb az eselye annak hogy _minden_ tonkremegy mint a registry eseten. (Es most megegyszer: _csak_ fajlrendszer eredetu problemakrol beszelek.)
Nem csoda hogy a registry kore egy halom vedelmet epitett az MS, a registry "nagyobb igenybevetelnek" van kiteve mint egy szerencsetlen alkalmazas specifikus ini fajl ergo nagyobb az esely barmilyen jellegu katasztrofara.
"Szerintem egy konfig fájlt könnyebb véletlenül letörölni, vagy felülírni."
Ha jol osszegzem az eddigi beszelgetesunket, akkor az egyetlen dolog ami miatt a registry a fajlrendszer szintjen biztonsagosabb, az az, hogy "A registry fájlok jól el vannak rakva, nem könnyű őket véletlenül elpusztítani". Az ini fajl meg minden mas szempontbol biztonsagosabb: flexibilis modon lehet felulirast szabalyozo jogosultsagokat adni, hardver hibaktol konnyebb megvedeni, egyszeru szerkezete miatt tobbfele eszkozzel es konnyebben elkeszitheto/atirhato/javithato.
>>> "Igen rosszul ertettel. Nem tudsz kulonbseget tenni a registry strukturajabol fakado es a kozponti tarolasbol fakado veszelyek kozott."
A registry struktúrájának alapvető tulajdonsága a központosítás. <<<
De mondom hogy nem erted. :-) Ahhoz hogy az ervelesed (a teljes beszelgetesunkre hivatkozok most) vilagos legyen, kulonbseget kell tenned a fajformatumbol fakado, es a kozponti tarolasbol fakado veszelyek kozott. Miert? Mert a fajlformatumbol fajlon beluli hibak (konfig fajl eseten ugy hivnad hogy "szintaktikai hibak") keletkeznek (amit orvosolni api-val meg gui-val lehet), mig a kozponti tarolasbol fajlrenszer szintjen kezelendo problemak akadnak (amit a fajlrendszer biztonsagosabba es megbizhatobba teltelevel kell orvosolni). Mikor ervelsz, a kettot ne mosd ossze, mert nem lesz logikus amit irsz. (Csak szepen tudomanyosan, hiszen mernokok vagy fizikusok (?) vagy mik vagyunk, azaz ez nem egy politikai musor... bar ha most arra gondolok hogy neked a marketing szoveg is az ervek koze tartozik...)
"Ha a fájlok csakúgy megpusztulnak a rendszerben, akkor ott sokkal súlyosabb problémák vannak."
Ebben egyetertunk. Abban nem hogy mik ennek a sokkal sulyosabb problemanak a kovetkezmenyi akkor ha az ertekes adataink 100%-a serul meg 1 fajl megserulese eseten, vagy ha az ertekes adatainknak csak toredeke serul meg 1 fajl megserulese eseten.
"Egyébként mint ahogy már írtam sok kis szanaszét pakolt fájl esetén nagyobb az esélye a sérülésnek."
Csak a fajlrendszer eredetu serulesre kisebb az esely. De olyan sokminden mas is megfontolando, nem csak 1 szempont. Ez a kerdes leegyszerusitese, es egyszerusitesz, igy a kovetkeztetes amire jutsz is teves.
Megaztan: nem csak esely letezik, hanem okozott kar merteke is. Aminek az eselyet nezni kell, az a "mi az esely a sulyos adatvesztesre, meghibasodasra". Nezzuk reszletesen:
-Hardver (gep vagy merevlemez) szempontjabol az adatok eloszthatosaganak koszonhetoen kisebb az esely hardver hiba eseten a teljes meghibasodasra.
-Fajlrendszer szintu meghibasodasra kovetkezteben az adatvesztesre, mivel a tobb fajl tobb bejegyzes, kisebb az esely. (Az nem ide tartozo kerdes, hogy fajlrendszer meghibasodas milyen gyakori. Nem gyakori, de ha eljatszunk a gondolattal hogy lehetseges, akkor a fajlszer meghibasodas kovetkezmenyei nagyobbak 1 fajl eseten. A valoszinusege kisebb, ezt elismerem, de ha beut a menko, akkor az okozott kar az nagyobb!)
-Fajlrendszer szintu biztonsagi problemakbol adodo adatvesztesre, mivel a tobb fajl mindegyike kulon-kulon vedheto a fajlban tarolt adatoknak megfeleloen testreszabva (!), igy annak az eselye hogy valaki olyan ini fajlba ir, amire nincs joga, kisebb az esely akkor, ha a jogosultsagokat beallitjuk. A lehetoseg adott, es a flexibilitas nagyobb mint 1 fajl eseten. (Ne abbol indulj ki hogy windows-on vagyunk, ahol mindenki adminisztrator, es igy a mysql.ini-t akarki letorolheti...).
-A fajlformatum egyszerusege miatt arra hogy egy third party program hibasan irjon a fajlba (fajl szerkezetet teve tonkre), kisebb az esely (ne reagalj meg, olvass tovabb!). Ha erre az a valaszod hogy pont ezert van megkotve az ember keze a registry eseten, es csak az OS GUI-jan vagy az OS API-jan keresztul lehet a registryhez ferni, akkor erre azt mondom hogy igen, igazad van, a flexibilitast felaldozva biztonsagossa tettuk a rendszert. De: ez nem win-win scenario. Itt valamit fealdoztunk valamiert. Es mivel igy van, ezert ezt errol igy kellene beszelni. Neked is.
-Az igaz hogy a konfig fajl formatumat nem vedi semmi, de mivel EZ IGAZ, ezert ezt be is ismertem. (Mondjuk azt meg kell jegyeznem, hogy akkor viszont vedve van a formatum, ha ugyanugy ahogy windows-on is, gui-t hasznalsz, vagy ha ugyanugy ahogy windows-on is, api-t hasznalsz... azaz ha bedugod a fejed linux alatt a beklyoba, cserebe ugyanazt a biztonsagot kapod ott is... ;-) De ugy altalanossagban nezve: ha egy a fajl formatumat nem ismero szerkesztovel szerkeszted a registry-t (mivel binaris fajlrol beszelunk, ez az editor egy hexa editor lesz), ugyanugy elrontohatod mint a notepad-dal az init... ;-) )
Es meg egy gondolat: Ne keverd ossze azt, hogy az MS kotelezove teszi a registry-t es ezert hasznalja azt mindenki, azzal, hogy mindenki magatol is azt valasztotta volna. Ha a registry fenyevekkel jobb lenne mint az ini fajl, akkor az ujabb oprendszereken azonnal ez a megoldas terjedt volna el.
"Mivel van róla biztonsági másolat,..."
Ahogy a konfig fajlokrol is van.
"...a legtöbb esetben..."
A maradek esetben meg a rendszernek annyi.
"...automatikusan javítódik..."
Erre az algoritmusra nagyon kivancsi lennek amelyik eldonti hogy egy registry-ben tortent valtozas az most hiba-e vagy sem. Minden bejegyzeshez van ellenorzo osszeg generalva, meg az egesz fajlhoz is, igy barmikor megallapithato hogy egy-egy kulcs vagy ertek, es maga az egesz registry is autentikus-e vagy serult? Valamint az OS vegig ezen porog mint a virusirto, hogy ezt ellenorizgeti? Minden registry-hez valo hozzafereskor? Vagy ha nem akkor hogyan kell az egeszet elkepzelni?
"...és már megy is minden tovább"
Igen, pont ez az amirol hires a windows. Automatikusa minden tok jo, es a munka megy is tovabb. Ehe.
>>> "es a hibatol fuggoen elofordulhat, hogy semmi az eg vilagon nem megy, beleertve az OS-t is."
A rendszervisszaállítás még itt is segít. <<<
Az mar tul keso. Ha az oracle beallitasaimat tarolo fajl mondjuk ugy megy tonkre, hogy (csak pelda, hogy ertheto legyen mirol beszelek) mondjuk atkodolodik, ergo az egesz fajl hasznalhatatlan lesz, attol meg az OS, es minden mas alkalmazas is vigan megy tovabb. Ha a registry megy ugy tonkre, hogy atkodolodik (mondom, ez csak az erthetoseg miatt egy pelda) akkor minden megborul. Ez a felvetes. Erre kellene azt mondanod most hogy igen, a registry ebbol a szempontbol serulekenyebb.