289
-
tomi5534 #289 Sziasztok! Tom h ez most nem ide való de szeretném ajánlani egy könyvet melyben segitséget kapsz h lehet pénzt keresni az interneten! Tölstétek le ezt sztem megéri! De ti tudjátok h érdekell e!
http://www.onlinevallalkozas.hu/52699
-
remark #288 Van UNIX-hoz is RAID, meg replikacio. Az ERP dolog az csak egy pelda volt, ami szemleletesen bemutatja, hogy PELDAUL milyen praktikus okai lehetnek annak ha valaki a registry ellen beszel. -
BiroAndras #287 "vannak olyan rendszerek (pl. az ERP rendszer amit mi fejlesztunk) aminel ha az OS disk bedoglik, kiveszed az ERP rendszer disk-jet vagy disk-jeit (database disk-jet is vagy epp nem, ha az egy masik gepben van), atteszed egy masik gepbe, es a rendszer, attol fuggoen hogy mikent konfiguralod fel a lemezt az uj gepben, akar azonnal mukodokepes is lehet."
Ha komoly szerverekről beszélünk, akkor win-en is ugyanez működik. Arról nem is beszélve, ilyeneknél hogy RAID-et is illik használni, és akkor az OS-től függetlenül is problémamentesen kezelhető a vinyóhalál.
"Ha az adatok egy resze uszott volna az OS-sel egyutt, akkor maradna a backup, ami adatvesztest jelent."
Van RAID, meg replikáció.
Pl.: http://support.microsoft.com/kb/q174070/
"3) szerintem fogadd el, hogy a unix vilagban bizonyos dolgokrol mashogy gondolkodnak"
Miért ne fogadnám el? Még azt sem mondom, hogy feltétlenül minden esetben rosszabb. Én csak azért kezdtem el vitatkozni, mert sokan simán leszarozták a registry-t, és téves állításokkal érveltek (ha egyáltalán vették erre a fáradtságot). -
remark #286 Helyesen: "Az, hogy nem erted amit, IROK..." -
remark #285 "Te félrebeszélsz megint."
Az, hogy nem erted amit, az nem azt jelenti hogy igazad van. Lehet hogy nekem vannak kommunikacios problemaim, lehet hogy neked, de lehet hogy a forumon lehetetlen az ilyen tok egyszeru dolgokat megbeszelni (utobbit ketlem).
"A fálj maga rohadt jól védhető, mert elég, ha csak a rendszer tud hozzáférni, attól még az API-n keresztül elérhetik a júzerek."
Megint temat valtottal.
"És nem, nem erről bészéltél, lásd idézet."
Nem ezt irom. Nem erted. Irjam le mashogy?
"Érdekes, szerintem meg pont te csinálod ezt."
Akkor de jo hogy igy egymasra talaltunk.
"Azt értsd már meg, hogy ha a az a partíció száll el, amin az OS van, akkor b@szhatod. Ha meg nem az, akkor minden meg tovább gond nélkül."
Te meg azt ertsd meg hogy
1) lehet annak elonye hogy az osszes adat 1 disk-en van.
2) vannak olyan rendszerek (pl. az ERP rendszer amit mi fejlesztunk) aminel ha az OS disk bedoglik, kiveszed az ERP rendszer disk-jet vagy disk-jeit (database disk-jet is vagy epp nem, ha az egy masik gepben van), atteszed egy masik gepbe, es a rendszer, attol fuggoen hogy mikent konfiguralod fel a lemezt az uj gepben, akar azonnal mukodokepes is lehet. Ha az adatok egy resze uszott volna az OS-sel egyutt, akkor maradna a backup, ami adatvesztest jelent.
3) szerintem fogadd el, hogy a unix vilagban bizonyos dolgokrol mashogy gondolkodnak (szerver programokrol van szo). ez esetenkent elonyos, esetenkent nem. pl. a windows verzio filozofiaja mas nalunk is mint a unix verzioe. de ez hosszu tortenet.
"Az egy darab központ sokkal jobban védhető, mint sok szétszórt egység."
Az meglehet, csak nem errol volt eddig szo. -
BiroAndras #284 "Ez jo pelda arra hogy te hogyan ervelsz. Felvetek egy problemat: a fajlrendszeren ilyen meg olyan jogosultsagok igy meg ugy allithatok be ini eseten, meg registry eseten. Te meg visszairsz hogy alljunk csak meg, a registry-ben kulcsonkent is allithato a jogosultsag."
Te félrebeszélsz megint. Azt írod, hogy azért jobb az ini fájl, mert részletesebben be lehet állítani a jogosultságot.
Idézem:
"ez a jogosultsagi rendszer beallitsanak kerdese, vagy mivel 1 fajl, ezert nem lehet egyszeruen a 2000 fele programnak kulonfele jogosultsagokat beallitani hozza, ugye?"
Ez meg mint írtam butaság, mivel a registry esetén nem fájl szinten kell beállítani a jogosultságot.
"Eh. Ezt mar megbeszeltuk, hogy ez (kulcsonkenti jogosultsag) a registry plusz szolgaltatasa. Tul vagyunk rajta. Es en arrol beszelek hogy a fajl maga hogyan vedheto. Te meg nem."
A fálj maga rohadt jól védhető, mert elég, ha csak a rendszer tud hozzáférni, attól még az API-n keresztül elérhetik a júzerek. És nem, nem erről bészéltél, lásd idézet.
"Felvetek valamit X-rol te meg leirod hogy na neeee, hiszen Y meg igy meg ugy. Nem eloszor csinalod ezt, igy nehez megbeszelni barmit is."
Érdekes, szerintem meg pont te csinálod ezt.
"Unix-on (=szervereken) van egy nagy kupac particio (merevlemez) a legtobb gepben. "Nekem" is vannak olyan szervereim amelyekben 10 merevlemez is van. Ha az egyik fejreall, akkor csak azt az egyet kell visszallitani, mikozben ugye az osszes tobbi program (amelyek mas particiokat hasznalnak) zavartalanul mukodnek."
Azt értsd már meg, hogy ha a az a partíció száll el, amin az OS van, akkor b@szhatod. Ha meg nem az, akkor minden meg tovább gond nélkül.
És képzeld el, az én gépemben is 5 vinyó van, 6 partícióval. Ezek közül csak a rendszer partíció halála esetén válik működésképtelenné bármilyen program, mivel az összes többin csak adat van.
"Es ha meghibasodik a merevlemez, akkor a kovetkezo ket scenario volt a leggyakoribb: Windows desktop eseten totalis ujrainstall (=uj image felhuzas uj vinyora) vagy backup-rol visszaallitas (a lenyeg ugyanaz: minden borult); Unix eseten meg 1 darab merevlemez csere, majd backup-rol visszallitas."
1. Azt akarod mondani, hogy a Unix-oknál minden partíción egy önállóan életképes OS példány van? Mert különben nem látom, hogy hogyan élhetnék túl a rendszerpartíció halálát.
2. Win esetén az image felrakása nem "backup-rol visszaallitas" ?
"A lenyeget erted-e? Kozponti adattarolas=minden bukik, es elosztott adattarolas=csak par dolog bukik."
Ez igaz, de ez csak egyik felel a képnek. Az egy darab központ sokkal jobban védhető, mint sok szétszórt egység.
"tarolom az adatokat amelyek egyenkent is teljesertekuek (nincs osszefugges a fajlok kozott) akkor a komoly adatvesztes eselye alacsony."
Az egyik esetben kis eséllyel sokat vesztessz, a másik esetben nagy eséllyel keveset. Legalábbis ez lenne, ha a win nem nyújtana extra védelmet a registry-nek. -
remark #283 Ez jo: "'Conspiracy stuff' is now shorthand for unspeakable truth." -
remark #282 "Értsd már meg, hogy nem a pontos szám a lényeg, hanem a nagyságrend. Az idézett adatokkal csak annyit akartam bizonyítani, hogy a Vista nem bukott meg."
Jo, en megertem.
Te meg azt ertds meg, hogy elegem van abbol a fajta eroszakos velemenyformalasbol ami ma jellemzo, legyen szo barmilyen temarol is. Politika, gazdasag, szakma, szinte mindegy, mindenhol jelen van az amit csak "agymosas"-nak szoktam nevezni. Azert eroszakos, mert a tobbseg ignoranciajat, butasagat, nemtorodomseget, bizalmat hasznalja ki, es miutan oket megnyerte es a tobbseg velemenyet sikeresen atformalta, joggal nyomja le a maradek kisebbseg torkan is az egeszet, arra hivatkozva hogy dehat errol szol a demokracia (tobbseg akaratarol), meg a szabad verseny (amit a tobbseg igenyel, az lesz kiszolgalva). Erre az a hatarozott valaszom, hogy NEM! Ennek NEM igy kellene mukodnie, es a vaksagunk nem mentseg, nem teszi a felelossegunket semmisse!
Ugyhogy a Vista mellett ervelesed rendben van.
De mikor meglattam hogy tenykent kozolsz olyat ami (roviden egy) hazugsag, akkor kiakadtam. Mert persze az tobbseg nem tudja hogy az hazugsag (es nem is erdekli, viszont beepul mint adat megis, es visszakoszon kesobb, befolyasolva a velemenyet), mint ahogy a tobbseg mar nem is tudja hogy mit miert csinal az eletben, es hogyan jutottunk oda ahova.
Ami igaz, az igaz. Ami meg nem, akkor ne mondjuk megis, hogy igaz. -
remark #281 Gondolom nem banod ha csak a szamomra erdekesebb felvetesekre reagalok. Elvegre ez az egesz beszelgetes csak a sajat magam szorakoztatasa szempontjabol erdekes ugyis.
"... regedittel minden program registry bejegyzéseit lehet szerkeszteni, tehát ebből a szempontból ugyanolyan univerzális eszköz, mint az ini fájlok szerkesztésére a notepad."
Ez igy van. De ne vonj le messzemeno kovetkezteteseket ebbol, mert az "ebbol a szempontbol"-on van a hangsuly!! Notepad vs. regedit-rol pedig meg lesz szo lejjebb.
"Az egyszeri beüzemelés költsége sok száz, vagy sok ezer használatra szétosztva már elenyésző."
Ha osszevetem a "be kell uzemelni" es a "nem kell beuzemelni" koltsegeit, akkor a "be kell uzemelni"-é nagyobb. Ergo mindegy hanyszor kell beuzemelni, es hogy a beuzemeles koltsegei hany hasznalatra oszlanak szet, a beuzemeleses verzio koltsege nagyobb. Ez evidencia.
>>> "...az ini fajlt egyszerubb kezelni, szimplan azert mert az ini formatuma egyszerubb es ennek megfeleloen az azt kezelo API is egyszerubb. Logikusan hangzik, nem?"
Nem hangzik logikusnak. A registry is egy faszerkezet, az ini fájl is (ha nem, az pont hogy hátrány). A tárolás módja az API szempontjából érdektelen. <<<
Miert logikus hogy mindent faszerkezetben tarolj? Ha nem kell a faszerkezet, akkor pont hogy hatrany a bonyolitas. Az ini fajl miert lenne faszerkezet? Az ini fajl API-ja egyszerubb, miert is ne lenne az? .... hasznaltad egyebkent a kettot parhuzamosan? En igen, ezert mondom hogy a tapasztalat szerint az ini fajl api-ja egyszerubb.
"Tudom, hogy nem erre hivatkozol, hanem olyat állítassz, amit ez cáfol."
Abbol, hogy >> arra a felvetesemre, hogy a registry-be irt rossz adat ugyanugy megboritja a programot mint az ini fajlba irt rossz adat, te tevesen ugy reagalsz hogy a registry _formatumat_ nehezebb elrontani << hogyan kovetkezik a fenti allitasod?
"A notepad textfile specifikus funkciókat tartalmaz."
(Olvasd vegig es egyben ertelmezd:) Es az kit erdekel? Ini fajlokat hasonlitunk registry-hez nem szoveges fajlt a registryhez. A regedit ezert GUI (a registry GUI-ja), de meg kell jegyezzem tisztaban vagyok azzal hogy mikor eredetileg idekeverted a GUI-t akkor te a GUI mas definiciojara gondoltal. En csak felhivom a figyelmet arra hogy a registry-t nem lehet "kezzel" szerkeszteni, mert amit te kezzel szerkesztesnek hivsz, az egy specialis tool hasznalatat takarja a valosagban.
"A mysql ini fájlt használ. Az ini fájlokról beszéltünk, nem? Azt próbáltam elmagyarázni már sokadszorra, hogy ha lett volna hozzá GUI, akkor sokkal gyorsabban megtanulom konfigurálni."
Azt nem erted meg, hogy nem a kulonfele GUI-kat hasonlitjuk ossze. Ez ilyen egyszeru. Az a felvetesed, miszerint a registry elonye az hogy van hozza GUI, az ertelmetlen. Nem azert ertelmetlen mert nincs koze a temahoz, es nem lehet az eredeti temat kiboviteni ilyen iranyban, mert lehet. Azert ertelmetlen, mert nem errol van szo. Lehet ugy osszehasonlitani az OpenOffice-t az MS Office-szal, hogy azt mondjuk hogy tulajdonkeppen vannak olyan esetek amikor egyik se jo, es inkabb hasznlunk egy harmadik programot. De mi ertelme van bevinni a kerdesbe egy ilyen szempontot? Ezert lovagolok a GUI-n, mert a GUI-nak egy fajlformatummal kapcsolatos vitaban nincs helye. Szerinted van, leirtad, elolvastam, tudomasulvettem. Es meg mindig ugy gondolom hogy a formatumrol szolo vitanak a GUI-tol (API-tol stb.) fuggetlennek kellene lennie.
"Megint csak a felére reagálsz. Ott az az is szócska."
Azert reagalok csak arra, hogy kihangsulyozzam az alatalad leirtakkal kapcsolatos fenntartasaimat.
>>> "ez a jogosultsagi rendszer beallitsanak kerdese, vagy mivel 1 fajl, ezert nem lehet egyszeruen a 2000 fele programnak kulonfele jogosultsagokat beallitani hozza, ugye?"
Nagy tévedés megintcsak. A registry-ben kulcsonként is állítható a jogosultság. <<<
Ez jo pelda arra hogy te hogyan ervelsz. Felvetek egy problemat: a fajlrendszeren ilyen meg olyan jogosultsagok igy meg ugy allithatok be ini eseten, meg registry eseten. Te meg visszairsz hogy alljunk csak meg, a registry-ben kulcsonkent is allithato a jogosultsag.
Eh. Ezt mar megbeszeltuk, hogy ez (kulcsonkenti jogosultsag) a registry plusz szolgaltatasa. Tul vagyunk rajta. Es en arrol beszelek hogy a fajl maga hogyan vedheto. Te meg nem. Felvetek valamit X-rol te meg leirod hogy na neeee, hiszen Y meg igy meg ugy. Nem eloszor csinalod ezt, igy nehez megbeszelni barmit is.
"Én meg azt mondom már sokadszorra, hogy ha egy partíciód elszáll, akkor sokkal nagyobb bajban vagy annál, hogy a beállításaid miatt aggódj."
Ezt se erted. Unix-on (=szervereken) van egy nagy kupac particio (merevlemez) a legtobb gepben. "Nekem" is vannak olyan szervereim amelyekben 10 merevlemez is van. Ha az egyik fejreall, akkor csak azt az egyet kell visszallitani, mikozben ugye az osszes tobbi program (amelyek mas particiokat hasznalnak) zavartalanul mukodnek. Nem az ini fajlok miatt aggodok, azt mondom hogy ez (amit leirtam, az) egy plusz "szolgaltatas" (ami neha jol jon).
"Egyébként meg a legtöbb gépben egy partíción, de legalábbis egy vinyón van minden beállítás akárhogy is van tárolva."
Ugy gondolkodsz, mintha csak Windows desktop letezne a Foldon.
"1. Az említett probléma rendkívül kevés embert érint.
2. Semmi köze a tárolás módjához. ini fájlokkal is ugyanez történne."
A) Te eredetileg azt irtad hogy "semmi baj nincs". Ha akár 1 embernek is baja van, akkor az hulyeseg, hogy "semmi baj nincs". Esetleg fogalmazz mashogy, es akkor "nem kotok bele".
B) A ket felvetesed ertelmetlen. 1) Nem az volt a kerdes hogy hany embert erint. Hiszen az alapfelvetes az volt hogy "van aki mashogy szereti, ezert meg ezert". Ergo hacsak 1 ember mashogy szeretne, akkor mar van ertelme a kerdesrol beszelni, az meg nem erv, hogy dehat a tobbieknek az nem kell. 2) Az hogy ini fajl eseten mi tortenne azt meg mar honnan a busbol tudnad, mikor ilyen implementacio nincsen. Ha akarnank kesziteni egyet, akkor ezer fele megoldas kozul lehetne valasztani, nem csak az lenne az egyetlen ami a felvetesben a problemat okozza.
>>> "a tapasztalat azt mutatja hogy nincs semmi baj a konfiguracios fajlok megbizhatosagaval"
A biztonságot te hoztad fel, nem én. <<<
Olvasd vissza: megbizhatosagrol volt szo. Egyebkent pedig nem en hoztam elo a megbizhatosagat, hanem ez alapfelvetes volt kezdetektol fogva. Most miert kened ram?
>>> "...a registry "nagyobb igenybevetelnek" van kiteve mint egy szerencsetlen alkalmazas specifikus ini fajl ergo nagyobb az esely barmilyen jellegu katasztrofara."
A védelem nem a fájlrendszer ellen van, mert az nem szorul rá... <<<
Nem olvastad amit irtam? >"nagyobb az esely barmilyen jellegu katasztrofara"< Ki beszel kizarolag fajlrendszerrol?
>>> "hardver hibaktol konnyebb megvedeni"
Egyes részeit igen, de ez nem sokat ér. Ami igazán fontos, az az OS működéséhez szükséges fájlok. <<<
Neked ezek a fontosak. Egy adminisztrator meg lehet hogy orul hogy egyszeruen (!) lehet elszeparalni alkalmazasokat az OS-tol, adatok, programok es beallitasok (!) szintjen is.
Es megint ez az ertelmetlen ervelesi logikad. "X eseten igen, de ami igazan fontos az az Y" stb. Kit erdekel? X-rol irtam allitast, ami megallja a helyet, nem Y-rol. Azert mert Y-ra tudsz valamit irni ami igaz, az nem azt jelenti hogy X-el kapcsolatban is igazad van.
"A legnagyobb esélye annak ven, hogy elszáll az egész vinyó, vagy partíció."
Sok esetben nincs olyan hogy "egesz vinyo" meg "egesz particio" elszall (te ertelmezesed szerinti "egesz"). Nem csak desktop letezik, 1 vinyoval, 1 particioval.
>>> "(gep vagy merevlemez) szempontjabol az adatok eloszthatosaganak koszonhetoen kisebb az esely hardver hiba eseten a teljes meghibasodasra."
20 éve még biztos igaz volt. Ma már nagyon nem jellemző... <<<
Miota a mostani melohelyemen dolgozok rengetegszer tortent merevlemez meghibasodas kulonfele gepekben. Attol fuggetlenul hogy athelyez-e serult szektorokat (marmint a tartalmukat) mashova a rendszer automatikusan vagy sem. Es ha meghibasodik a merevlemez, akkor a kovetkezo ket scenario volt a leggyakoribb: Windows desktop eseten totalis ujrainstall (=uj image felhuzas uj vinyora) vagy backup-rol visszaallitas (a lenyeg ugyanaz: minden borult); Unix eseten meg 1 darab merevlemez csere, majd backup-rol visszallitas. A lenyeget erted-e? Kozponti adattarolas=minden bukik, es elosztott adattarolas=csak par dolog bukik.
>>> "Fajlrendszer szintu meghibasodasra kovetkezteben az adatvesztesre, mivel a tobb fajl tobb bejegyzes, kisebb az esely."
Épp hogy több az esély, mert több a fájl. <<<
Szokas szerint nem erted mirol irok. De hogy miert bonyolult felfogni?
Az a pelda, hogy a fajlrendszer valamilyen okbol meghibasodik akkor ha minden adatom 1 fajlban van, akor minden elveszett, de ha tobb fajlban tarolom az adatokat amelyek egyenkent is teljesertekuek (nincs osszefugges a fajlok kozott) akkor a komoly adatvesztes eselye alacsony.
Tehat nem a fajlrendszeri meghibasodas eselyerol irok, hanem a fajlrendszeri meghibasodas eseten annak az eselyerol, hogy nagy merteku lesz-e az adatvesztes.
>>> "-Fajlrendszer szintu biztonsagi problemakbol adodo adatvesztesre, mivel a tobb fajl mindegyike kulon-kulon vedheto a fajlban tarolt adatoknak megfeleloen testreszabva"
Mint már sokszor mondtam, ez téves. A windows-ban nem csak fájlszintű jogosultságkezelés van. <<<
Legy szives a felveteseimet probald meg ertelmezni, ha mar elolvasod oket.
Tehat: engem az a legkevesbe se erdekel, hogy nem csak fajlszintu jogosultsagkezeles van a registryhez. A felvetes fajlrendszer szintu biztonsagi kerdeseket feszeget.
Itt a felsorolas kozepen kiemelnem:
Nem veletlenul bontottam a kerdest elemeire, es keszitettem felsorolast. Te fogod, es osszemosod az egeszet, es teljesen mindegy mit hoz fel az ember, te ugy vagsz vissza hogy ugyesen atugrasz kapcsolodo reszekre, es azokkal folytatod az ervelest. Nem reagalsz arra amire a felvetes vonatkozott, hanem tovabbugrasz. Kenyelmes, de téves. Gondolkodj el azon hogy szerinted igy lehet-e ertelmes parbeszedet folytatni, legyen szo barmirol is.
Elmondanam azt is, hogy amire tovabbugrasz, azzal is tisztaban vagyok. Nem azert nem irtam rola, mert nem tudok rola, se nem azert mert nem latom az osszefuggest. Azert nem irtam arrol, mert az nem tema. Mert mikor irok valamirol, akkor nem az ahhoz kapcsolodo masik kerdesrol van szo, hanem arrol amirol effektive irok is.
>>> "-A fajlformatum egyszerusege miatt arra hogy egy third party program hibasan irjon a fajlba (fajl szerkezetet teve tonkre), kisebb az esely"
Inkább nagyobb. <<<
Ez egy elmeleti kerdes volt, de hogy teljes legyen a felsorolas, nem hagyhattam ki. Ha lenne mind registry-hez mind ini fajlhoz third party program, azaz olyan program amelyik a szabvanyos feluletet megkerulve ir a fajlba, akkor a registry-t konnyebb lenne elrontani, mert bonyolultabb. Azt irhattad volna valaszul, hogy ez a veszely nem valos, de azt irni hogy "inkabb nagyobb" az tevedes.
>>> "akkor erre azt mondom hogy igen, igazad van, a flexibilitast felaldozva biztonsagossa tettuk a rendszert."
Tehát elismered, hogy jobb. <<<
Nem ismerem el. Mirol beszelsz egyaltalan?
Azt mar kezdetektol fogva irom, hogy bizonyos dolgok jobbak a registry-nel, bizonyos dolgok meg az ini-nel. Ez a mondat aminek a felet beidezed, az egy 5 pontbol allo felsorolas egyike mellett all, raadasul olyan szovegkornyezetben ahol kifejtem hogy ez nem egy win-win eset. Olvasd el ujra, es ertelmezd. Ra fogsz jonni hogy nem azt irom amit te latni szeretnel hogy en irtam.
>>> "De ugy altalanossagban nezve: ha egy a fajl formatumat nem ismero szerkesztovel szerkeszted a registry-t"
Ilyet nem teszel, hacsak nem vagy teljesen hülye. <<<
Nem ez a lenyeg. Reszeltesen bemutatom a kerdest 5 kulonbozo szempont szerint. A felvetes csak a fogalmak es a logika tisztazasa miatt szerepel itt. Azt kellene felfognod, hogy az ini fajl szerkesztese notepad-dal az olyan mint a registry szerkesztese egy hexa editorral. Nem az a lenyeg hogy csinalnal-e ilyet az ember vagy nem.
"Meg ahogy te is mondtad, fájlszintű jogosultság kezeléssel nem túl biztonságos."
En nem ezt mondtam, latom ez a resz se volt vilagos szamodra. -
BiroAndras #280 "Olyan nincs hogy "tobbnyire szoveges". Vagy text fajl, vagy binaris."
Bináris fájlban van tárolva, de a tartalma nagyrészt szöveges információ, illetve a regedittel könnyen szerkeszthető manuálisan.
"A regedit az egy specialis, direkt egyfele fajlformatumhoz irt szerkeszto program."
Igen, speciális. Viszont garantáltan ott van minden gépen, ahol registry is van. Semmivel sem nehezebb attól a registry szerkesztése, hogy külön program kell hozzá.
"Ha szerinted ez "kezi" szerkesztes, akkor az egyszerubb .doc fajlok szerkesztese Wordpad-dal is kezi szerkesztes..."
Az egészen más. Sokkal magasabb szintű hozzáférés. Inkább olyan, mint a registry szerkesztése GUI-n keresztül.
"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."
Nem ez a lényeg. Arról beszélek, hogy a regedittel minden program registry bejegyzéseit lehet szerkeszteni, tehát ebből a szempontból ugyanolyan univerzális eszköz, mint az ini fájlok szerkesztésére a notepad.
""Az API-t egyszer kell csak beüzemelni."
Az hogy hanyszor kell beuzemelni, annak semmi koze a kerdeshez."
De igen. A kérdés az, hogy mennyire könnyű a hozzáférés, tehát nagyon nem mindegy, hogy mennyi extra költséggel jár a dolog. Az egyszeri beüzemelés költsége sok száz, vagy sok ezer használatra szétosztva már elenyésző.
"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."
Azért szól mellette, mert a registry-hez egy API van, ami garantáltan mindenhez jó, és jó lesz a jövőben is. Az ini fájlok szintaxisára nincs ilyen garancia.
De abban igazad van, hogy ha nem kell kézzel szerkeszteni, akkor ebből a szempontból nincs nagy különbség.
">>> "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"
Én nem erre gondoltam. Ha magadnak csinálsz ini fájlt, akkor egyébként se akkora gond a szintaxis, mert olyat találsz ki, ami neked kényelmes.
"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."
Biztosan könnyebb, mint parsert írni, és biztosan nem nehezebb, mint más API-t ahsználni.
"Egyebkent nemreg epp Perl-ben jott elo ez a kerdes, es Perl-ben nagsagrendekkel konnyebb szoveges fajlokat kezelni mint registry-t"
Passz. Nem használok Perl-t.
"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?"
Nem hangzik logikusnak. A registry is egy faszerkezet, az ini fájl is (ha nem, az pont hogy hátrány). A tárolás módja az API szempontjából érdektelen.
"lehet hogy a registry-t nehezebb elrontani, TE ezt mondod, de EN nem erre hivatkozok, ergo nem erted hogy mirol beszelek"
Tudom, hogy nem erre hivatkozol, hanem olyat állítassz, amit ez cáfol.
"Az hogy jon ide hogy te mit valasztanal? Meg hogy neked mi a nehezebb? Meg hogy szerinted semmi elonye? Altalanossagban beszelgetunk"
Én is általánosságban beszéltem.
"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 notepad textfile specifikus funkciókat tartalmaz.
"van karakteres registry editor a windows-hoz?"
a regedit parancssorban is működik. Persze sokkal kényelmetlenebb úgy használni.
"amit kifejezetten ehhez a fajlformatumhoz irtak, nincs alternativaja, es fajlformatum specifikus funkciokat tartalmaz. Ettol GUI."
Ha így definiálod, felőlem lehet. Ez értelmetlen filozófiai vita. A lényeg, hogy legalább olyan egyszerű kézzel szerkeszteni a registry-t, mint egy ini fájlt.
"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?"
A mysql ini fájlt használ. Az ini fájlokról beszéltünk, nem? Azt próbáltam elmagyarázni már sokadszorra, hogy ha lett volna hozzá GUI, akkor sokkal gyorsabban megtanulom konfigurálni.
"Ha szerinted a textfajlba exportalas lehetosege osszehasonlithato azon szovegfajl kezelesi lehetosegekkel amik unix-on parancssorbol elerhetoek... am legyen, akkor igazad van."
Ugyanaz, vagy még több is elérhető win-en.
"Lehet, csak nem mindegy a bonyolultsag."
Nem bonyolultabb szerintem.
"Az MS ezek szerint ugy definialja a vedelmet es biztonsagot hogy eleg ha kiadnak olyan tool-okat amikkel utolag a rendszer helyreallithato."
Megint csak a felére reagálsz. Ott az az is szócska.
"En nem csak a felulirasrol beszelek"
De azért az épp elég fontos.
"ez a jogosultsagi rendszer beallitsanak kerdese, vagy mivel 1 fajl, ezert nem lehet egyszeruen a 2000 fele programnak kulonfele jogosultsagokat beallitani hozza, ugye?"
Nagy tévedés megintcsak. A registry-ben kulcsonként is állítható a jogosultság.
"hat ez kerem a kozpontositott tarolas hatulutoje, es illene beismerni hogy az fajlrendszer szintu vedelem nehezen szabhato testre 1 fajl eseten..."
Pontosan ez az egyik hátránya a az ini fájloknak.
"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."
Én meg azt mondom már sokadszorra, hogy ha egy partíciód elszáll, akkor sokkal nagyobb bajban vagy annál, hogy a beállításaid miatt aggódj.
Ha meg annyira fontos, akkor amúgyis illik róla mentést csinálni.
Egyébként meg a legtöbb gépben egy partíción, de legalábbis egy vinyón van minden beállítás akárhogy is van tárolva.
"en ugy olvasom lejjebb itten, hogy vannak olyan tapasztalatok miszerint egyes esetekben jobb lenne ha nem ilyen lenne a registry"
1. Az említett probléma rendkívül kevés embert érint.
2. Semmi köze a tárolás módjához. ini fájlokkal is ugyanez történne.
Már csak azért is, mert ilyenkor az adat már a memóriában van, nem fájlban. És valószínűleg lapozni sem lehet még ilyenkor, különben a registry-t is simán kilapozhatná az OS.
"a tapasztalat azt mutatja hogy nincs semmi baj a konfiguracios fajlok megbizhatosagaval"
A biztonságot te hoztad fel, nem én.
"meg mindig konnyebben megserul az a fajl, amelyiket nagysagrendileg tobbet hasznal a rendszer"
Hát pedig nem. A fájlrendszer gyakorlatilag tökéletesen védi az adatokat, akármennyi használat esetén sincs gond (nemúgy mint a FAT32 esetén).
A vinyónak meg tökmindegy, hogy melyik részét használod. Akkor lenne igazad, ha flash memórián tárolnák a fájlokat. Azokhoz viszont van olyan fájlrendszer, ami folyamatosan mozgatja a gyakran használt fájlokat, így egyeneletesen használódik el minden része.
"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."
A védelem nem a fájlrendszer ellen van, mert az nem szorul rá. Inkább a vírusok, szarul megírt programok, és a túl kreatív felhasználók ellen véd.
"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"."
Nem csak ez.
"Az ini fajl meg minden mas szempontbol biztonsagosabb: flexibilis modon lehet felulirast szabalyozo jogosultsagokat adni"
Tévedés. Lásd fent.
"hardver hibaktol konnyebb megvedeni"
Egyes részeit igen, de ez nem sokat ér. Ami igazán fontos, az az OS működéséhez szükséges fájlok. Ezeket pedig hiába szórod szét, elég ha csak egy részük megsérül, akkor is működésképtelenné válik az OS.
A hardverhibák ellen védekezni RAID-del meg biztonsági másolattal lehet bármelyik fájlformátum esetén.
"egyszeru szerkezete miatt tobbfele eszkozzel es konnyebben elkeszitheto/atirhato/javithato."
"Ahhoz hogy az ervelesed (a teljes beszelgetesunkre hivatkozok most) vilagos legyen, kulonbseget kell tenned a fajformatumbol fakado, es a kozponti tarolasbol fakado veszelyek kozott."
Nem tettem?
"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."
A beállításokat én nem tartom értékesnek. Legfeljebb azokat, amik az OS működőképességéhez kellenek. Egyébként a sérülés esélye nagyobb, ha több fájlban van az adat, cserébe persze egyszerre nem feltétlen veszik el mind (bár mint mondtam a leggyakoribb hibáknál úgyis mind elveszik).
És mint már mondtam, ha tartassz az értékes adatok sérülésétől, akkor készíts mentést. Más nem véd meg. Marginális statisztikai különbségekre nem érdemes rábízni az adataidat.
"De olyan sokminden mas is megfontolando, nem csak 1 szempont. Ez a kerdes leegyszerusitese, es egyszerusitesz, igy a kovetkeztetes amire jutsz is teves."
Sokféle szempontról beszéltünk, nem?
"nem csak esely letezik, hanem okozott kar merteke is."
Pontosan. A legnagyobb esélye annak ven, hogy elszáll az egész vinyó, vagy partíció. Egyes fájlok gyakorlatilag csak felülírással sérülnek, azellen meg a jogosultságkezelés, meg még pár dolog véd.
"(gep vagy merevlemez) szempontjabol az adatok eloszthatosaganak koszonhetoen kisebb az esely hardver hiba eseten a teljes meghibasodasra."
20 éve még biztos igaz volt. Ma már nagyon nem jellemző. Ha egyes szektorok tönkre is mennek hosszú használat után, a vinyó automatikusan áthelyezi őket. A legtöbb esetben még időben ahhoz, hogy ne legyen adatvesztés.
"Fajlrendszer szintu meghibasodasra kovetkezteben az adatvesztesre, mivel a tobb fajl tobb bejegyzes, kisebb az esely."
Épp hogy több az esély, mert több a fájl.
"a fajlszer meghibasodas kovetkezmenyei nagyobbak 1 fajl eseten."
Az már igen.
"-Fajlrendszer szintu biztonsagi problemakbol adodo adatvesztesre, mivel a tobb fajl mindegyike kulon-kulon vedheto a fajlban tarolt adatoknak megfeleloen testreszabva"
Mint már sokszor mondtam, ez téves. A windows-ban nem csak fájlszintű jogosultságkezelés van.
"-A fajlformatum egyszerusege miatt arra hogy egy third party program hibasan irjon a fajlba (fajl szerkezetet teve tonkre), kisebb az esely"
Inkább nagyobb.
"akkor erre azt mondom hogy igen, igazad van, a flexibilitast felaldozva biztonsagossa tettuk a rendszert."
Tehát elismered, hogy jobb. A flexibilitásból egyébként szerintem semmit sem áldozunk. Mint már mondtam, ha nagyon akarod, a registry adott részét textfájlba exportálod, szerkezted amivel akarod, aztán visszaimportálod. De erre nem sűrűn van szükség.
"De ugy altalanossagban nezve: ha egy a fajl formatumat nem ismero szerkesztovel szerkeszted a registry-t"
Ilyet nem teszel, hacsak nem vagy teljesen hülye.
"az MS kotelezove teszi a registry-t"
Ezt honnan veszed? Egyáltalán nem kötelező, maximum ajánlott.
Elég sok programot írtam már, ami hozzá se nyúl a registry-hez. Sőt, konfig fájlokat is használnak (amíg csak én nyúlok hozzá, addíg kényelmesebb).
"Ha a registry fenyevekkel jobb lenne mint az ini fajl, akkor az ujabb oprendszereken azonnal ez a megoldas terjedt volna el."
Milyen oprendszereken? A windows-okon el is terjedt ahogy kell. A többi meg gyakorlatilag mind valamilyen unix variáns, ahol meg túl nagy hagyománya van a szövegfájloknak, meg a parancssornak. Meg ahogy te is mondtad, fájlszintű jogosultság kezeléssel nem túl biztonságos.
"Ahogy a konfig fajlokrol is van."
Ha te csinálsz. A registry-ről viszont készül automatikusan.
"Erre az algoritmusra nagyon kivancsi lennek amelyik eldonti hogy egy registry-ben tortent valtozas az most hiba-e vagy sem."
Ha hibás a fomrátuma, akkor hiba. Ha az OS nem tud elindulni, akkor hiba. Más esetekben a felhasználóé a döntés.
"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?"
Nem tudom, de nem lennék meglepve, ha így működne. De olyan nagyon ez nem érdekes, mert a közvetlen szerkesztés nagyon nem jellemző.
"Valamint az OS vegig ezen porog mint a virusirto, hogy ezt ellenorizgeti? Minden registry-hez valo hozzafereskor?"
Leginkább rendszerindításkor. Utánna már úgyis a memóriában van, és a fájlrendszer nem engedi közvetlenül írni.
"Az mar tul keso."
Nem késő. A rendszervisszaállítás akkor is működik, ha az OS nem indul.
"Ha a registry megy ugy tonkre, hogy atkodolodik (mondom, ez csak az erthetoseg miatt egy pelda) akkor minden megborul."
Ezt az OS detektálja (pl. úgy, hogy induláskor lefagy), és viszsaállítja mentésből. -
BiroAndras #279 "A tenyekrol (40 millio, 100 nap, XP-hez kepest 2x-es eladas stb.) bebizonyosodott hogy nem helytalloak, vagy bebizonyosodott hogy nem azt jelentik amit allit az MS hogy jelentenek"
Ismétlem : Az derült ki, hogy kicsit szépítgették az adatokat, nem pedig az, hogy teljesen tévesek.
"Tehat mit is kellene elfogadnom? Azt hogy a Vista sikeres?"
Igen.
"En nem azt allitottam hogy a Vista nem sikeres"
Nem te állítottad, hanem valaki más, és én arra reagáltam. Te ezután kezdtél el vitatkozni. Ha nem gondolod úgy, hogy a Vista senkinek sem kell, akkor feleslegesen vitázol.
"Egy erveles amelyik kozmetikazott adatokra epul az a minimum hogy korrekciora szorul"
Értsd már meg, hogy nem a pontos szám a lényeg, hanem a nagyságrend. Az idézett adatokkal csak annyit akartam bizonyítani, hogy a Vista nem bukott meg. -
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. -
remark #277 "Nem idekevertem, csak megemlítettem, hogy a registry-t többnyire nem kell kézzel szerkeszteni."
Szoval nem "idekeverted a GUI-t" csak megemlitetted hogy "tobbnyire nem kell kezzel szerkeszteni".
Amig meg nem magyarazod hogy mi a ketto kozotti kulonbseg nem foglalkozok a hozzaszolasod tovabbi reszeivel, mert ugy erzem mintha direkt kiforgatnal mindent attol fuggetlenul hogy van-e ertelme vagy nincs annak amit csinalsz. Egyszeruen nem tudom elhinni hogy nem fogsz fel dolgokat (szazadik topiknal a tizezredik alkalommal). Olyan erzes veled beszelgetni mintha te egy alternativ valosagban leteznel ahol a fennt van lennt, a 2x2 az 5, a szavak nem azt jelentik amit az altalam megismert vilagban jelentenek, es az ok-okozat osszefugges se egeszen ugy mukodik mint amihez az ember hozza van szokva. -
remark #276 "Nem jött össze, mert mindenfélét kitalálsz, hogy ne kelljen elfogadnod a tényeket."
Milyen tenyeket? A tenyekrol (40 millio, 100 nap, XP-hez kepest 2x-es eladas stb.) bebizonyosodott hogy nem helytalloak, vagy bebizonyosodott hogy nem azt jelentik amit allit az MS hogy jelentenek (nem a merketingosztalyon dolgozo Kicsi Bill allitja, az MS allitja!!).
Tehat mit is kellene elfogadnom? Azt hogy a Vista sikeres? En nem azt allitottam hogy a Vista nem sikeres, hanem azt hogy ahogyan be akarjak bizonyitani hogy a Vista sikeres, az felrevezeto, ertelmetlen, megalapozatlan, beleertve a te probalkozasaidat arra nezve hogy tenyekkel probald meg a feltetelezesedet alatamasztani, miszerint a Vista egy nagy siker.
"Konkrétan hol is van a cáfolat? Én úgy emléxem, hogy csak szépítgetésről volt szó, nem arról, hogy totál téves az adat."
Az ervelesed pukkadt ki (volt megalapozatlan) en ezt irom. Problajuk legalabb neha megerteni egymast. Egy erveles amelyik kozmetikazott adatokra epul az a minimum hogy korrekciora szorul, de azt se latom nagy tulzasnak ahogy en fogalmazok...
"Konkrétan a marketingesek csinosítgatják a tényeket, ahogy szokták. Hazugságról nincs szó."
Az MS neveben kozmetikazzak az adatokat. Mi a kulonbseg? A ceg neveben nyilatkozatokat tevok a ceget allitjak be ilyennek vagy olyannak. Ez megintcsak nem olyan dolog amibe bele lehetne kotni, te megis megteszed. Ez egyszeruen igy mukodik. Ha a kormanyszovivo aztmondja hogy X akkor azt a kormany neveben mondja. Pont. Ha a marketingesek hibat kovettek el, ki kell oket rugni, es uj marketingstrategiaba kell kezdeni. Ha ezt a dontest nem hozza meg az MS, akkor ezzel a marketingosztaly moge all, ergo a marketingstrategiaval azonosul. Ennyi.
De egyebkent tenyleg nem is ertem hogy miert kell ilyen magyarazatokba belemenni, te meg a nyilvanvalot is megkerdojelezed neha... -
BiroAndras #275 "A Vista sikeresseget probaltad tenyekkel alatamsztani. Nem jott ossze."
Nem jött össze, mert mindenfélét kitalálsz, hogy ne kelljen elfogadnod a tényeket.
"Az ervelesed egy lufi volt ami kipukkadt"
Konkrétan hol is van a cáfolat? Én úgy emléxem, hogy csak szépítgetésről volt szó, nem arról, hogy totál téves az adat.
"az MS-rol pedig ujra bebizonyosodott hogy hazudik"
Konkrétan a marketingesek csinosítgatják a tényeket, ahogy szokták. Hazugságról nincs szó. -
BiroAndras #274 "Hoppa. Hirtelen idekeverte valaki a GUI-t."
Nem idekevertem, csak megemlítettem, hogy a registry-t többnyire nem kell kézzel szerkeszteni.
"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.
"Kezzel szerkesztes ala pl. a notepad-dal valo szerkesztes tartozik. Vagy szerinted nem? "Kezzel" az szerkesztheto amihez nem kell a fajl specialis formatumat felismero GUI/editor vagy api."
Mivel a regedit ugyanúgy adott, mint a notepad, ugyanúgy kézi szerkesztésnek minősül. Vagy azt is mondhatjuk, hogy a notepad is eszköz, amivel hozzáférsz a vinyón tárolt fájlokhoz. A regedit-tel bármelyik program registry bejegyzését szerkeszthetem, ahogy a notepad meg minden ini fájlt kezel.
"Az volt a gond hogy szoveges fajlt minden programnyelv kezel alapbol (ergo mindenkinek tudja hogy hogyan mukodik es hogy mit hogyan kell csinalni), Perl-hez meg be kellett uzemelnem egy uj modult (megkeresni a regisry buhera api-t), es megtanulni hogy mi hogy mukodik."
Az API-t egyszer kell csak beüzemelni.
"Jaj, mar nem birom hogy sose a kerdesre valaszolsz!"
Én a kérdésre választltam szerintem.
"Ini kezlesre is van API"
És az boldogul az összes lehetséges formátummal? Kétlem.
"Ne API-zz nekem, mert nem ezt kerdeztem, ha mar van API (mindkettohoz!!!) akkor tok mindegy az egesz, mert elrontani ugyse tudsz semmit."
De API-zok, mert van API. Nem az a kérdés, hogy hogyan tudjuk minél jobban megnehezíteni a saját dolgunkat, hanem hogy hogyan lehet a leghatékonyabban megoldani az adott problémát.
"Egyebkent meg nem allitom hogy nincs ilyen programnyelv ahol konnyebb megnyitni es kiolvasni a registry-t mint megnyitni es kiolvasni egy ini fajlt (huh, milyen programnyelv lehet az ilyen??), de latom te se tudsz ilyet mondani."
Akkor mondok egyet : C++. De nagyjából bármelyik nyelvet mondhatnám, amelyiken elérhető a megfelelő API.
"A registry _formatumat_ nehezebb elrontani."
Én is ezt mondom.
"a te mysql-es peldad errol szolt, a beirt ertek szokozzel kezdodott, azaz a beirt ertek rossz volt"
Hát nagyon nem. Minden normális konfigfájlban a szóköz csak akkor adat, ha idézőjelben van. Pláne az értékek elején.
De mindenképpen ez a fájl szintaxisa, nem az adaté.
"Nem kell hogy te kezeld az ini fajlt, ha nem akarod"
Egyes formátumokhoz lehet, hogy van API, de mindhez biztosan nem.
"A registry esetben viszont nincs valasztasi lehetoseg"
Nem is kell. Minek választanám a nehezebb utat, aminek semmi előnye sincs?
"regedit is egy gui!"
Akkor a notepad is.
"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ő. Mindennek megvan a helye, és ezt nem nehéz megtanulni, mert millió helyen van dokumentálva.
A mysql vonatkozó részei ellenbensokkal problémásabbak, mivel a hivatalos dokumentáció nagyon szűkszavú, és referencia jellegű (tehát, ha nem tudod, hogy mit keresel, akkor nagy abjban vagy). A netes írások döntő része pedig webfejlesztésről szól amihez egészen más jellegű beállítások kellenek (pl. InnoDB-t alig használnak, nekem meg pont az kell).
"Es a legfobb baj az, hogy nem vilagosan ervelsz."
?
"Ha leirnad egyenesen hogy a registry egyik elonye hogy a fajl formatumat nem lehet elrontani, akkor az ember ertene hogy mit akarsz."
Hát nem ezt írtam le több tucatszor???
"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.
"vagy feldolgozhatod, hasznalhatod shell scriptekben, stb."
A registry-t is.
"Nem a vedelmere fordit kulon figyelmet (nem serul meg kevesbe a registry mint egy barmilyen masik fajl), hanem ha elcseszodik, akkor konnyebben helyre lehet tenni."
A helyreállítás is védelem. Ezen kívül szerintem nem is hagyja direktben felülírni. De a lényeg : a tapasztalat azt mutatja, hogy egyáltalán semmi baj sincs a megbízhatóságával.
"Szoval valasszuk kette azt hogy mi azeselye hogy megserul a registry/ini fajl, es mi a lehetoseg a javitasra ha mar egyszer megserultek a fajlok."
Legyen. Mi az esélye annak, hogy a registry (mint fájl) megsérül? A tapasztalat szerint elenyésző.
Szerintem egy konfig fájlt könnyebb véletlenül letörölni, vagy felülírni.
"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.
"A kulonallo (konfig) fajlok szerintem adnak egy kis plusz biztonsagot. Mert ha megpusztul az egyik konfig fajl, attol meg a masik hasznalhato marad."
Ha a fájlok csakúgy megpusztulnak a rendszerben, akkor ott sokkal súlyosabb problémák vannak. 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. A registry fájlok jól el vannak rakva, nem könnyű őket véletlenül elpusztítani.
"Ha a registry megpusztul, akkor az egeszet lehet nekiallni javitani"
Mivel van róla biztonsági másolat, a legtöbb esetben automatikusan javítódik, és már megy is minden tovább.
"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. De mint mondtam, ilyen probléma esetén sokkal súlyosabb gondok vannak a géppel, csakúgy magától nem szokot elpusztulni egy fájl sem (legalábbis NTFS fájlrendszer esetén).
"Es a registry-t, a fa struktura miatt nehezebb kulonallo fajlokban tarolni"
Nem is kell. Pont az a lényeg, hogy néhány nagyobb fájlban van minden. Könnyebb kezelni, kevesebb helyet foglal, gyorsabb a beolvasás, és a keresés, könnyebb lementeni, stb. -
remark #273 A Vista sikeresseget probaltad tenyekkel alatamsztani. Nem jott ossze. Ennyi a tortenet lenyege. Az ervelesed egy lufi volt ami kipukkadt, az MS-rol pedig ujra bebizonyosodott hogy hazudik (=agymossa az embereket, es en koszi ebbol nem kérek). -
remark #272 >>> "Egyebkent megjegyzem hogy pont azert keverted ide"
Én ugyan nem. <<<
#232 Kagemusha: Azert azt te is elismerheted, hogy van egy hangyanyi kulonbseg az ember szamara olvashato szoveges konfig allomany meg a registry agyonkodolt formedvenye kozott (nem mellesleg: mindket rendszert hasznalom, tudom, mirol beszelek).
#241 BiroAndras: Az a nagy különbség, hogy win-en nagyon ritkán kell a registry-t hekkelni, mert minden fontos dolog GUI-ból elérhető (ha alapból nem is, akkor ügyes emberek írnak hozzá külön progit).
Hoppa. Hirtelen idekeverte valaki a GUI-t. Mikozben pont az irja Kegemusha hogy az ini file GUI nelkul is szerkesztheto (olvashato) a registry meg kodolt (binaris).
Elkezdesz ervelni, hogy nem baj hogy a registry binaris, ugyse kell atirogatni, mert van GUI. Te kevered ide a GUI-t.
>>> "ami a registry egyik hianyossaga: csak segedeszkozzel vagy valami API-t felhasznalva szerkesztheto."
Ez hülyeség. Legalább olyan jól szerkeszthető kézzel, mint egy konfigfájl. <<<
Kezzel szerkesztes ala pl. a notepad-dal valo szerkesztes tartozik. Vagy szerinted nem? "Kezzel" az szerkesztheto amihez nem kell a fajl specialis formatumat felismero GUI/editor vagy api.
"A konfig fájlok hátrányairól van szó a GUI-val szemben. Lényegtelen, hogy mikor a verzió, az számít, hogy mennyire nehéz kezelni, és miért."
Egyreszt nem a konfig fajl hatranyarol van szo a GUI-val szemben hanem a registry es az ini fajlok szerkeszthetosegenek kulonbsegerol, masreszt a mysql-es problemad az implementacio fuggo problema, csak azert mert a mysql-ben van valami ami nem mukodik ugy ahogy te elkepzelted, attol meg az ini nem rosszabb mint a registry. (Mas okbol lehet rosszabb az ini mint a registry, de amit te hoztal fel az egyaltalan nem erv semmire.)
>>> "Pl. perl-ben valamit ki kellett olvasni egy konfig fajlbol. Piece of cake. Aztan valami mast a registry-bol. Eeek. Nem reszletezem."
Mi volt a gond? <<<
Az volt a gond hogy szoveges fajlt minden programnyelv kezel alapbol (ergo mindenkinek tudja hogy hogyan mukodik es hogy mit hogyan kell csinalni), Perl-hez meg be kellett uzemelnem egy uj modult (megkeresni a regisry buhera api-t), es megtanulni hogy mi hogy mukodik.
>>> "Hany olyan programnyelv van amelyikkel egyszerubb a registry-t kezelni mint egy szovegfajlt?"
Nagyjából ahány programnyelvhez van registry kezelő API. Nagy előny, hogy nem kell saját parsert írni, és ha módosítod is, akkor sokkal kisebb az esélyed, hogy elb@szol valamit. <<<
Jaj, mar nem birom hogy sose a kerdesre valaszolsz! Ini kezlesre is van API, es tok jo hogy ha az API-t hasznalod a konfig fajl kezelesere akkor nem kell sajat parsert irni stb. stb. Huuu.
Szoval melyik az a programnyelv amivel konnyebb a registry-t kezelni mint a szovegfajlt? Ne API-zz nekem, mert nem ezt kerdeztem, ha mar van API (mindkettohoz!!!) akkor tok mindegy az egesz, mert elrontani ugyse tudsz semmit.
Egyebkent meg nem allitom hogy nincs ilyen programnyelv ahol konnyebb megnyitni es kiolvasni a registry-t mint megnyitni es kiolvasni egy ini fajlt (huh, milyen programnyelv lehet az ilyen??), de latom te se tudsz ilyet mondani.
>>> "Ha elrontom az egeszet, borul a programom igy is ugy"
"De a registry-t sokkal nehezebb elrontani (hacsak nem szándékossan csinálod)." <<<
Nem. Nem. Nem.
A registry _formatumat_ nehezebb elrontani. Igy ertettem en. Nem mashogy. A registrybe is ugyanugy irhatsz hulyeseget, hulye helyre, mint ahogy beirhatsz hulye kulcs ala hulye erteket az ini fajlba (a te mysql-es peldad errol szolt, a beirt ertek szokozzel kezdodott, azaz a beirt ertek rossz volt) is. Es ha megteszed akkor ugyanugy fejreall a programod, teljesen mindegy hogy registry-bol vagy ini fajlbol olvassa az adatot.
>>> "Egyebkent meg mi ved meg attol, hogy a registry-t rosszul kezelo programot irj meg?"
Semmi. De legalább nem kell parsert írni, ami jócskán csökkenti a hibalehetőségeket. <<<
Nem kell hogy te kezeld az ini fajlt, ha nem akarod, es ha mindenaron a hibalehetoseget akarod csokkenteni. A registry esetben viszont nincs valasztasi lehetoseg, van az api meg az api, meg a gui (regedit is egy gui!).
>>> "Vagy hogy a registry utvesztojeben rossz helyre irj rossz adatot?"
Pici utánnajárás, és már nem is útvesztő. <<<
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.
>>> "Te csak es kizarolag azt hajtogatod hogy a registry fajlformatumat nem lehet elrontani."
Nem csak ezt mondom, de ez egy elég jó érv. <<<
Es a legfobb baj az, hogy nem vilagosan ervelsz. Ha leirnad egyenesen hogy a registry egyik elonye hogy a fajl formatumat nem lehet elrontani, akkor az ember ertene hogy mit akarsz. Es ez egy elony is, ezen nincs mit vitatkozni. Mar az elejen irtam, hogy elonyok-hatranyok. Az hogy a formatum kotott, elony is, de mivel csak specialis eszkozokkel szerkesztheto ez a specialis formatumu fajl, igy van amikor ez az elony inkabb hatrany, felhasznalasi terulettol fugg hogy az ember ezt valasztja-e vagy sem. Pl. ini fajl atfolyathato a standard inputon, igy hasznalhato a parancssorban parameterkent (egesz fajl, vagy egy resze, vagy egy kulcs vagy ...) vagy feldolgozhatod, hasznalhatod shell scriptekben, stb.
>>> "Ettol meg nem lesz jobb a hibaturese. Vagy ha igen, akkor kivancsi vagyok hogy mitol."
Attól, hogy az OS külön figyelmet fordít a védelmére. Pl. van róla biztonsági másolat, ahonnan sérülés esetén visszaállítható. A rendszervisszaállítás is használható erre. <<<
Rossz az ervelesed. Nem a vedelmere fordit kulon figyelmet (nem serul meg kevesbe a registry mint egy barmilyen masik fajl), hanem ha elcseszodik, akkor konnyebben helyre lehet tenni. De ezek a helyreallito ficsorok csak jatekszerek, unix-on is barmit visszallitasz ha elcseszodik, az lehet hogy nem egy next>next>next GUI fogad, de attol meg siman megoldhato.
Szoval valasszuk kette azt hogy mi azeselye hogy megserul a registry/ini fajl, es mi a lehetoseg a javitasra ha mar egyszer megserultek a fajlok.
>>> "Senki se allitotta hogy a registry strukturajabol adodoan serulekeny."
Te állítottad, hogy a központi tárolás sérülékenyebb. Vagy rosszul értettem valamit? <<<
Igen rosszul ertettel. Nem tudsz kulonbseget tenni a registry strukturajabol fakado es a kozponti tarolasbol fakado veszelyek kozott.
A kulonallo (konfig) fajlok szerintem adnak egy kis plusz biztonsagot. Mert ha megpusztul az egyik konfig fajl, attol meg a masik hasznalhato marad. Ha a registry megpusztul, akkor az egeszet lehet nekiallni javitani, es a hibatol fuggoen elofordulhat, hogy semmi az eg vilagon nem megy, beleertve az OS-t is.
Es a registry-t, a fa struktura miatt nehezebb kulonallo fajlokban tarolni ugy, hogy ha barmelyik fajl megserul, a tobbi fajlban tarolt info felhasznalhato maradjon.
Ennyi a kapcsolat a kozott hogy milyen a registry belso szerkezete es hogy mik a kozponti tarolas plusz veszelyei. -
BiroAndras #271 "Abbol meg most mar nem tudod kivagni magad, hogy te magad is (akkor fogalmazzunk igy, nekem mindegy) idezted az MS marketingjet."
Miért akarnám kivágni magam? Azért azt idéztem, mert mást nem találtam. Alaposabb utánnanézés után kiderült, hogy bár szépítgettek az adatokon, azért alapvetően jók nagyságrendi becslésnek, és nekem csak ennyi kellett. -
BiroAndras #270 "Es ez teged hol erint hatranyosan hogy valaki ezt valasztja?"
Sehol. Nem én voltam az, aki az egyik megoldást feleslegesnek mondta. Én csupán reagáltam, és azt probáltam megmutatni, hogy a GUI-nak és a registry-nek is bőven van létjogosultsága. Azt is mondtam, hogy ha valaki már elég profi, akkor valóban kényelmesebb lehet közvetlenül a konfigfájlban turkálni. Én sem írok GUI-t a saját programjaim konfigurálásához, ha sok beállítás van és tudom, hogy csak én fogom használni.
"Neked hajtepes a mysql konfiguralasa, akkor te hasznalj barmi mast amit akarsz."
Hát ha az olyan könnyű lenne. Egy éles program alatt az adatbázis motor lecserélése egy olyan rémálom, ami helyett nagyon sok hajtépést bevállalok.
"A hozzaszolasokat visszaolvasva ugy latom hogy registry vs. konfig fajl a tema."
Az is. mindkettő felmerült.
"Egyebkent megjegyzem hogy pont azert keverted ide"
Én ugyan nem.
"ami a registry egyik hianyossaga: csak segedeszkozzel vagy valami API-t felhasznalva szerkesztheto."
Ez hülyeség. Legalább olyan jól szerkeszthető kézzel, mint egy konfigfájl.
"Akkor te hasznalj 3 eves mysql-t ha mindenaron azt akarod bebizonyitani hogy hanyfele modon lehet szivni a mysql-lel..."
Kénytelen voltam 3 évvel ezelőtt 3 éveset használni. Sjanos még nem lehet a jövőből szoftvert letölteni. Másrészt meg kompatibilitási okokból leragadtunk a 4.0.18-as verziónál. Az éles rendszert nem basztassuk, ha nem muszály. Különösen, ha extra hisztis az ügyfél, és évi sok milliárdos forgalma van.
"Az, hogy te valami regi mysql-lel szivsz, annak mi koze van a temahoz?"
A konfig fájlok hátrányairól van szó a GUI-val szemben. Lényegtelen, hogy mikor a verzió, az számít, hogy mennyire nehéz kezelni, és miért.
"Ez nem az ini fajlformatum hibaja, nem?"
De pontosan annak a hibája.
"kenytelen voltal kezzel belepiszkalni olyasmibe, amihez nem ertettel".
Pontosan. Ha lett volna GUI, sokkal könnyebbeneligazodok rajta. Nem én választottam a konfig fájlok matatását, hanem rákényszerültem.
"Egyebkent meg lovagolsz itt a szintaxis fogalman mikozben elfelejted hogy az adatnak is van szintaxisa ami mindket esetben (ini es registry) odafigyelest igenyel es hiba forrasa lehet."
Igen, de a registry esetén csak az adot szintaxisával kell foglalkozni, ami már könnyítés, a GUI pedig még abban is segít, ha normálisan van megírva.
"Pl. perl-ben valamit ki kellett olvasni egy konfig fajlbol. Piece of cake. Aztan valami mast a registry-bol. Eeek. Nem reszletezem."
Mi volt a gond?
"Hany olyan programnyelv van amelyikkel egyszerubb a registry-t kezelni mint egy szovegfajlt?"
Nagyjából ahány programnyelvhez van registry kezelő API. Nagy előny, hogy nem kell saját parsert írni, és ha módosítod is, akkor sokkal kisebb az esélyed, hogy elb@szol valamit.
"Ha elrontom az egeszet, borul a programom igy is ugy"
De a registry-t sokkal nehezebb elrontani (hacsak nem szándékossan csinálod).
"Szoval ha valaki az ini mellett dont, mert szamara az a legjobb formatum, akkor azzal mi is a baj?"
Semmi, amíg nem én szívok miatta. Nekem az a bajom, ha valaki a registry-t szarozza, ráadásul a saját tudatlansága miatt.
"Milyen szkriptekkel?"
Windows Scripting Host
"Egyebkent meg mi ved meg attol, hogy a registry-t rosszul kezelo programot irj meg?"
Semmi. De legalább nem kell parsert írni, ami jócskán csökkenti a hibalehetőségeket.
"Vagy hogy a registry utvesztojeben rossz helyre irj rossz adatot?"
Pici utánnajárás, és már nem is útvesztő.
"Te csak es kizarolag azt hajtogatod hogy a registry fajlformatumat nem lehet elrontani."
Nem csak ezt mondom, de ez egy elég jó érv.
"Ettol meg nem lesz jobb a hibaturese. Vagy ha igen, akkor kivancsi vagyok hogy mitol."
Attól, hogy az OS külön figyelmet fordít a védelmére. Pl. van róla biztonsági másolat, ahonnan sérülés esetén visszaállítható. A rendszervisszaállítás is használható erre. Elég sok tapasztalatom van win-es gépekkel, és eddig a registry komoly sérülése kizárólag egy sokkal súlyosabb probléma mellékhatásaként jelentkezett (pl. döglött rendszervinyó, letörölt windows könyvtár).
"Ezzel most azt allitod hogy egy unix rendszer biztonsagi szempontbol nehezebben uzemeltetheto."
A konfig fájlok biztonságát tekintve igen. Egyesével minegyiket meg kell keresni, és beállítani, míg a registry-ben egy helyen egyszerre megoldható ugyanez.
"Mi ez a "mindent ugy jobb csinalni ahogy azt az MS szokta" hozzaallas?"
Az MS sokmindent jól csinál, érdemes rá odafigyelni. De nyílván nem mindent ők csinálnak a legjobban, és a körülményektől is függ a legjobb megoldás.
"Es ez hogy jon ide? Mert unixon talan sorra pusztulnak meg a fajlok?"
Te írtad, hogy véletlenül megsérülhet a registry.
"Senki se allitotta hogy a registry strukturajabol adodoan serulekeny."
Te állítottad, hogy a központi tárolás sérülékenyebb. Vagy rosszul értettem valamit? -
BiroAndras #269 "A cikk nem tesz kulonbseget, hogy ipari vagy otthoni kornyezetben akarod-e hasznalni a Win-t."
Mivel a PC-k elenyészően kis részét használják közvetlenül ipari célokra, valószínűleg a cikkírónak meg sem fordult a fejében ez a lehetőség. Másrészt az ipari felhasználásnak is csak kis részénél fordul elő ez a probléma.
Ez olyan, mintha a kaszkadőrök panaszkodnának, hogy az utcai kocsik nem elég biztonságosak és strapabíróak a munkájukhoz. -
BiroAndras #268 "Talan ismered: harom statisztikus elmegy vadaszni..."
Mint minden mást, a statisztikát is lehet jól és rosszul is művelni. Elmagyaráztam, hogymiért működik itt a dolog. Az, hogy valami neked nagy probléma egyáltalán nem jelenti azt, hogy mindenki másnak is.
"Itt meg muszakonkent ramegy egy gepre 20-30 db, azaz egy nap 60-90."
És úgy gondolod, hogy ez a normális másoknál is?
"Egeszen eddig errol beszeltem: az a 16 MB nagyon sokszor okoz gondot."
Idézem a hibaleírást : "Azok a számítógépek, amelyek Intel vagy ARC (RISC) architektúrára épülnek, csak 16 MB (megabájt) memóriát használhatnak a rendszerbetöltési folyamatnak ebben a szakaszában."
Vagyis a 16MB-os határ nem az MS találmánya. Tehát sem az MS, sem a registry felépítése nem felelős a hibáért.
"es ha egy atlagos cegnel ez nem is fordul elo, nekunk momentan epp eleg gondot jelent."
Az állítás az volt részemről, hogy a hiba nagyon ritkán fordul elő. Hogy ti épp a olyan extrém körülményeket teremtetek, ahol előjön, az nem bizonyítja az ellenkezőjét.
Te ezt írtad : "Mellesleg ipari környezetben kissé gyakrabban kell a registry-t matatni, tehát az általad ritkának nevezett eset nem is olyan ritka."
Egy nagyon speciális esettel akarod bizonyítani, hogy valami nem ritka?
"Es pont ez az en bajom: megallas nelkul mennie kell a soroknak, ergo a gepekhez nem ferek hozza"
Ha a gép nem áll le, akkor a bootolás nem gond. Amikor meg leáll, akkor belefér +1 perc, amíg újratelepítődik a gép (pláne ha az alternatíva a hosszadalmas kézi heggesztés).
"masfelol ki birja szerined ezt tarkapacitassal"
Mihez kell tárkapacitás? 1db DVD kell minden géphez, amiről bootolás előtt újretelepítődik a gép.
De akár szkriptet, vagy programot is lehetne írni a registry takarítására.
Vagy ha nem létszükséglet, hogy win legyen a gépeken, akkor célszerű DOS-ra, mert az atomstabil, garantáltan nem önállóskodik, és kényelmesen közvetlenül hozzáférsz minden hardverhez.
"termelovallalathoz menj el."
Számtalan termelő vállalat is jól megvan ilyen problémák nélkül.
És ezeknél is a PC-k döntő többsége az irodákban van. -
Kagemusha #267 ""Megint csak nem az otthoni környezetről beszélek, hanem az ipariról."
Ott lehet, hogy igazad van, de minkett itt inkább az általános használaat érdekel."
A cikk nem tesz kulonbseget, hogy ipari vagy otthoni kornyezetben akarod-e hasznalni a Win-t. Es mellesleg nekem az ipari kornyezetben kell vele szivnom, tehat engem ez zavar. Es arrol sem volt szo sehol, hogy csak es kizarolag otthoni kornyezetet vizsgaljunk. Tehat? -
Kagemusha #266 ""Ugye viccelsz? A hiba súlyosságát azon méred le, hogy a Google hány találatot dob rá? Ne röhögtess!"
Nem értem mi ezzel a problémád. Teljesen nyílvánvaló, hogy egy adott probléma a súlyosságával arányos mértékben zavarja az embereket, akik ezzel arányos mértékben írnak ról a neten. Tehát a találatok száma egy jó első becslés a hiba súlyosságát illetően."
Talan ismered: harom statisztikus elmegy vadaszni...
""...és ha rákötsz X db nyomtatót (persze nem egyszerre)""
Hálózati nyomtató is számít? Mert én üzemeltettem oylan terminál szervert, amire több tucat volt installálva."
Itt meg muszakonkent ramegy egy gepre 20-30 db, azaz egy nap 60-90.
A tucatod ehhez kepest nulla.
""akkor a registry egy idő után bizony megborul! Elfossa magát és ugyan viszonylag egyszerű javítani, de véleményem szerint ez egy oltári nagy hibája a registry-nek."
Azt felejted el, hogy a probléma nem az adatok formátuma, hanem a mennyisége. .ini fájlban is ugyanennyi adat lenne, csak sokkal tovább tartana betölteni. Akkor lenne igazad, ha az egész registry betöltődne egy csomó felsleges adattal, de nem ez történik.
Szerintem az igazi probléma a 16MB-os határ, nem a registry."
Egeszen eddig errol beszeltem: az a 16 MB nagyon sokszor okoz gondot.
""Valamint ha naponta visszakerül hozzád minimum 2 PC ezzel a hibával és ugyanaz többször is, akkor az bizony gyakori hiba. Ja, hogy otthoni környezetben nem fordult még elő? Figyu, mikor kötsz a gépedre egy hónap alatt 1200 nyomtatót vagy bármilyen más USB-s eszközt?"
Fura helyen dolgozhatsz. Az hót tuti, hogy ez se otthon, se egy átlagos cégnél nem fordul elő, következésképpen nem gyakori hiba."
Termelocegnel dolgozok, mi ebben a fura? Orrba-szajba megy a nyomtatojavitas (is) es ha egy atlagos cegnel ez nem is fordul elo, nekunk momentan epp eleg gondot jelent.
"Egyébként rendkívül egyszerű mogoldás van rá: időnként takarítani kell a registry-t, vagy akár image-ből újrarakni az érintett gépeket.
Szegény win magától nem tudja kitalálni, hogy melyik driver-ek feleslegesek."
Es pont ez az en bajom: megallas nelkul mennie kell a soroknak, ergo a gepekhez nem ferek hozza, masfelol ki birja szerined ezt tarkapacitassal, mikor mas -tenylegesen fontosabb dolgokra- sem hajlando kolteni a ceg?
""Tehát ne magyarázd meg nekem a gyakoriságot a Google találataira alapozva, előbb menj el dolgozni egy olyan helyre, ahol 5000 gépből álló hálózatot kell karbantartani és ott mérd le..."
Nos, az MS történetesen nem 5000 de legalább 50000 gépes hálózatot üzemletet (a sajátját)."
Ahol a fentebb vazolt eseteknek nyomat sem talalod.
Jo, nem voltam eleg vilagos: termelovallalathoz menj el. -
remark #265 "De ettől még a registry nem lesz rosz, mint ahogy a linuxosok állítják."
Senki se allitotta ezt. Ne a felelmeidre reagalj, hanem arra ami le van irva.
"De sokkal lassabban, és több hajtépés árán."
Es ez teged hol erint hatranyosan hogy valaki ezt valasztja? Az egesz egyeni preferencia kerdese. Te meg kiosztod az embert hogy miert azt valasztja amit.
Az meg, hogy kinek mi a hajtepes, megintcsak az egyentol fugg. Neked hajtepes a mysql konfiguralasa, akkor te hasznalj barmi mast amit akarsz. Nezd meg milyen szep ez a megfogalmazas: "Én azt szeretem, ha direktben olvashatom, ami a konfig file-okban..." Tessek, itt egy ugyfel, egy igennyel. El lehet kuldeni a fenebe a "hulyesegevel" vagy meg lehet hallgatni.
"Nem registry vs .cfg hanem GUI vs .cfg a téma itt."
A hozzaszolasokat visszaolvasva ugy latom hogy registry vs. konfig fajl a tema. A tobbit (GUI) te keverted ide. Egyebkent megjegyzem hogy pont azert keverted ide, ami a registry egyik hianyossaga: csak segedeszkozzel vagy valami API-t felhasznalva szerkesztheto.
(A mysql...) "Csak 1-2 éve tud ilyet. A GUI-t feltalálták jó 30 éve."
Akkor te hasznalj 3 eves mysql-t ha mindenaron azt akarod bebizonyitani hogy hanyfele modon lehet szivni a mysql-lel...
Egyebkent meg a mysql csak pelda volt, nem ez a tema. A peldat probald meg felfogni. Ja, most nezem hogy arrol is irtal:
"A szopást az okozta, hogy:
1. Nem volt GUI (4.0.18-as verzió). Ileltve valami kis bigyó volt, de azon semmi állítási lehetőséget nem láttam."
Az, hogy te valami regi mysql-lel szivsz, annak mi koze van a temahoz? Ez nem az ini fajlformatum hibaja, nem?
"2. Az .ini fájlban rengeteg dolog nem volt benne, így nekem kellett összevadászni a kapcsolókat. Pl. qrva soká jöttem rá, hogy az InnoDB tábláknak külön konfigja van, és ezért nem volt hajlandó 22 megánál több memóriát használni."
En talan nem ezt irtam? Ime: "kenytelen voltal kezzel belepiszkalni olyasmibe, amihez nem ertettel".
"3. A WinMySQLAdmin saját konfigfájlt használ, ami nem teljesen kompatibilis az eredetivel, de legalább jól felülírja azt."
Az implementacio milyensegenek semmi koze az elviekhez, azaz hogy ini-hez is lehet gui-s konfig programot irni (es van is). Ha megtanultad kezelni, akkor valszeg fogod is tudni valamire hasznalni.
Megint a szokasos tevedesed: nem a registry-t hasonlitod a ini-hez hanem a mysql-t a ... mihez is? windows? mssql?
"4. Nagyon kényes a szintaxisra. Ha az egyenlőségjel körül akár egy szókoz is van, már nem indul el. És persze semmiféle hibajelzés nincs."
Implementacio hibaja vagy ez epp egy feature. Valamint ahogy azt mar irtam: "kenytelen voltal kezzel belepiszkalni olyasmibe, amihez nem ertettel".
Egyebkent meg lovagolsz itt a szintaxis fogalman mikozben elfelejted hogy az adatnak is van szintaxisa ami mindket esetben (ini es registry) odafigyelest igenyel es hiba forrasa lehet.
"5. Nagyon szarul vannak dokumentálva a kapcsolók (ez persze független a témától)."
Igen. Nem a temahoz tartozik. Ahogy a tobbi pont sem.
"Szerintem nem nehezebb a registry-t b@sztatni."
Szerintem meg igen. Akkor most ki nyert? :-D Vagy fogalmazzunk maskent: vannak esetek amikor meg nehezebb a registry-t piszkalni.
Pl. perl-ben valamit ki kellett olvasni egy konfig fajlbol. Piece of cake. Aztan valami mast a registry-bol. Eeek. Nem reszletezem. Hany olyan programnyelv van amelyikkel egyszerubb a registry-t kezelni mint egy szovegfajlt?
>>> "Funkcionalis szempontbol mi valtozott?"
- Egy helyen, rendszerezve vannak a beállítások.
- Automatikusan kezelhetők a júzer függő beállítások.
- Az OS védi a registry tartalmát. (...) <<<
Mondom funkcionalisan: mint eltarolom az adatot, kiolvasom az adatot. Ha elrontom az egeszet, borul a programom igy is ugy is mert ahogy mar emlitettem, az adatnak is van szintaxisa, hiaba szeretned hogy ez mashogy legyen. Azaz mi valtozott? Mas az api. Mas a szerkesztod. Van ini fajlra is olyan api ami megkoti a kezed, es fix szintaxissal dolgozik. Vagy megirod magadnak, mert egy szoveges fajl kezelese nem lehet problema.
Szoval mi a kulonbseg? A kotetlenseg. A konfig fajlt ugy hasznalod ahogy tetszik. Ne ragalj elhamarkodottan, tisztaban vagyok a hatranyokkal. Es az elonyokkel is. Szoval ha valaki az ini mellett dont, mert szamara az a legjobb formatum, akkor azzal mi is a baj?
Es azt is irtam, hogy ha szukseg van a registry (altalad is sorolt) tobbletszolgaltatasaira, akkor azt kell hasznalni.
"- Szkriptekkel sokkal könnyebb állítgatni a registry-t, mint .ini-fájlt szerkeszteni."
Milyen szkriptekkel?
>>> "Nagyobb eselyet latod pl. annak hogy valaki (vagy valaki altal irt gui-s program) egy ini fajlban allitson be valamit rosszul mint hogy a registry-ben?"
Igen. Mint már sokszor mondtam : szintaxis. <<<
Es az adat szintaxisa? Egyebkent meg mi ved meg attol, hogy a registry-t rosszul kezelo programot irj meg? Vagy hogy a registry utvesztojeben rossz helyre irj rossz adatot? Te csak es kizarolag azt hajtogatod hogy a registry fajlformatumat nem lehet elrontani. Az ini formatumat meg el lehet. Masrol is szo van itt azert.
"A registry is több fájlból áll egyébként."
Ettol meg nem lesz jobb a hibaturese. Vagy ha igen, akkor kivancsi vagyok hogy mitol.
"Sok szanaszét szórt fájl sesetén ezeket sokkal nehezebb megoldani."
Ezzel most azt allitod hogy egy unix rendszer biztonsagi szempontbol nehezebben uzemeltetheto. Nem latom be hogy miert lenne igy. Felteszem pl. az oracle-t, kiosztom a jogosultsagokat stb. mentest intezek, mindezt annak megfeleloen hogy az oracle maga mennyire szamit mission critical komponensnek. Mi valtozik ha ugyanezt osszemosom mas komponensek konfiguralasaval, a beallitasokat mas komponensek beallitasaival egyutt tarolom stb. Pl. ha megfekszik az oracle (eluszik a binarisokat es adatokat tarolo particiom) de megmaradnak a konfiguracios allomanyok mert azokat mashova tettem. Mit csinaljak a konfiguracios fajlokkal minden mas nelkul?
Ergo: este valogatja hogy mit hogyan jo csinalni. Mi ez a "mindent ugy jobb csinalni ahogy azt az MS szokta" hozzaallas?
"NTFS fájlrendszernél meg egyébként is nagyon nem jellemző, hogy egy fájl véletlenül megpusztul."
Es ez hogy jon ide? Mert unixon talan sorra pusztulnak meg a fajlok? Olyasmit irj, ami windows-on mashogy van, a tobbi csak toltelek.
"Próbálom erőltetni az agyamat, de nem nagyon emlékszem olyan esetre, amikor a registry megsérült, és ez okozta a win összedőlését. (...)"
Senki se allitotta hogy a registry strukturajabol adodoan serulekeny. Ezt megint te talaltad ki. -
remark #264 Nahat-nahat.
Szoval a marketing valojaban tenyleg maszlag? A 40 millio 100 nap alatt tenyleg badarsag? Elsore miert nem tudtad ezt irni, akkor szuksegtelen lett volna az egesz vita. ;-)
Abbol meg most mar nem tudod kivagni magad, hogy te magad is (akkor fogalmazzunk igy, nekem mindegy) idezted az MS marketingjet. Ha ugy csinaltad hogy nem neztel utana, akkor azert baj, ha meg ugy csinaltad hogy utananeztel, akkor meg az. Ha legkozelebb barmihez hozzaszolsz, akkor megis mit gondoljon majd az ember? Meg szep hogy azt fogom pl. en gondolni hogy "na megint itt a Biro a marketingidezeteivel". Egy szakmai vitaban hol van ennek a helye? Sehol. Ha a marketing lenne a szakmank, akkor rendben lenne a dolog. Ha _kiemelned_ hogy most a marketing soder kovetkezik, akkor rendben lenne a dolog. Az, hogy kenyed-kedved szerint osszemosod a kettot (IT-t a marketinggel), az a hiteledet rontja csak. (Mar nem a mai "szakemberek" kozott (azok a frappans valaszaidat fogjak tananyagkent felhasznalni), hanem a szakemberek kozott.)
"Most alkalmazd ezt minden más cégre is. Nagyon vicces reklámok lennének a TV-ben."
Nem gondolom hogy megvalosithato lenne, ez csak egy erv volt annak alatamasztasara hogy mennyire fogyasztoellenes dolog a marketing. (Nagyon.)
"Csak azt ne akard nekem bemesélni, hogy ezt egyedül az MS csinálja."
Nem, ez egyertelmu hogy nem csak az MS sáros. Az MS-t csak peldakepp hasznalom arra hogy irjak a vilag szemetsegeirol.
"Még a linuxosok sem ártatlanok ezügyben, pedig ők nem is cégek."
Erre mar egyszer celoztam, de nem veled beszelgettem akkor, hogy miert fontos az MS-sel kapcsolatban megjegyezni dolgokat, amiket egy linux-ostol elnez az ember. A ketto (MS-linux kozosseg) nem osszehasonlithato, ugyhogy ne is probaljuk meg osszehasonlitani.
Visszaterve ehhez:
>>> "És nem csak arról van szó, hogy sokat adtak el, hanem hogy az eladások növekednek is."
Ez most mit jelent hogy "novekednek az eladasok"? Mikor, mihez kepest? Konkretumokat please. <<<
Te a #222-ben felsorolt erveket figyelmen kivul hagyva (azokra nem reagalva) hivatkozol az altalam belinkelt cikkekre, azt alatamasztando hogy milyen sok Vista-t adtak el, ergo milyen sikeres a Vista. (Mindket allitas marketingallitas, de hagyjuk.) A cikk is, es az altalam irt kivonat (osszefoglalas+sajat velemeny) is leirja hogy miert nagy tevedes a marketinget hallva levonni azt a kovetkeztetest hogy a Vista sikeres, es olyan mertekben sikeres ahogy azt a marketing lattatni probalja.
Te fogod az egeszet, felresoprod, es bevagsz egy altalanossagot hogy "És nem csak arról van szó, hogy sokat adtak el, hanem hogy az eladások növekednek is." Azt meg nem irod le hogy most mire celzol, mit es hol olvastal amiert ezt irod, mivel tudod alatamasztani az allitasod, es egyaltalan (ezzel kellett volna kezdenem) mi az ertelme az allitasodnak. Mert onmagaban lehet hogy megallja a helyet, de a temahoz egyaltalan nem kapcsolodik, ha megis, akkor csakis azzal a szovegkornyezettel egyutt, ahonnan en is vettem. Ugyhogy: vagy beirod hogy honnan veszed az allitast, vagy hagyjuk.
Olyan vagy mint egy jo ugyesz a birosagon, ossze-vissza teljesen ertelmetlenul rakod ossze az allitasokat, tenyeket, velemenyt, marketinget. A szuggesszio nagyszeru, elered a hatasod azoknal akiknek fogalmuk sincs a temarol, de engem csak felbosszantasz. (Az eskudtszek neked hisz, es igy vegul az artatlan ember bortonbe kerul.)
Es mikor a bosszusagom levezetese celjabol leirom a 45 oldalas valaszomat, akkor meg kijelented hogy nincs erre idod. Ha ertelmesen akarsz beszelni, beszeljunk ertelmesen. Ha nem akarsz, akkor meg ne reagalj folyton ertelmetlensegeket. Koszi. -
BiroAndras #263 "Megint csak nem az otthoni környezetről beszélek, hanem az ipariról."
Ott lehet, hogy igazad van, de minkett itt inkább az általános használaat érdekel.
"Ha már konfig file-okat matatsz, ez nem lehet probléma. Addigra illene eljutnod erre a szintre."
Pont ez az, hogy a júzerek döntő része nem fog és nem is akar eljutni erre a szintre.
És nekem is nehezíti a dolgomat, ha eg angolul nem tudó embernek kell telefonon magyaráznom az angol GUI használatát. Egy konfig fájl kész rémálom lenne. -
BiroAndras #262 "Ugye viccelsz? A hiba súlyosságát azon méred le, hogy a Google hány találatot dob rá? Ne röhögtess!"
Nem értem mi ezzel a problémád. Teljesen nyílvánvaló, hogy egy adott probléma a súlyosságával arányos mértékben zavarja az embereket, akik ezzel arányos mértékben írnak ról a neten. Tehát a találatok száma egy jó első becslés a hiba súlyosságát illetően.
"...és ha rákötsz X db nyomtatót (persze nem egyszerre)""
Hálózati nyomtató is számít? Mert én üzemeltettem oylan terminál szervert, amire több tucat volt installálva.
"akkor a registry egy idő után bizony megborul! Elfossa magát és ugyan viszonylag egyszerű javítani, de véleményem szerint ez egy oltári nagy hibája a registry-nek."
Azt felejted el, hogy a probléma nem az adatok formátuma, hanem a mennyisége. .ini fájlban is ugyanennyi adat lenne, csak sokkal tovább tartana betölteni. Akkor lenne igazad, ha az egész registry betöltődne egy csomó felsleges adattal, de nem ez történik.
Szerintem az igazi probléma a 16MB-os határ, nem a registry.
"Valamint ha naponta visszakerül hozzád minimum 2 PC ezzel a hibával és ugyanaz többször is, akkor az bizony gyakori hiba. Ja, hogy otthoni környezetben nem fordult még elő? Figyu, mikor kötsz a gépedre egy hónap alatt 1200 nyomtatót vagy bármilyen más USB-s eszközt?"
Fura helyen dolgozhatsz. Az hót tuti, hogy ez se otthon, se egy átlagos cégnél nem fordul elő, következésképpen nem gyakori hiba.
Egyébként rendkívül egyszerű mogoldás van rá: időnként takarítani kell a registry-t, vagy akár image-ből újrarakni az érintett gépeket.
Szegény win magától nem tudja kitalálni, hogy melyik driver-ek feleslegesek.
"Tehát ne magyarázd meg nekem a gyakoriságot a Google találataira alapozva, előbb menj el dolgozni egy olyan helyre, ahol 5000 gépből álló hálózatot kell karbantartani és ott mérd le..."
Nos, az MS történetesen nem 5000 de legalább 50000 gépes hálózatot üzemletet (a sajátját). -
BiroAndras #261 "Ok. Tehat a Vista nem indult se olyan jol, ahogy az MS allitja, se olyan rosszul, ahogy az MS allitasara kifakadok allitjak. Akkor most kinek jar a pirospont?"
Nekem. :)
"Mert az egesz problema ott kezdodott hogy az MS ossze-vissza nyilatkozgatott, es szerintem az MS jobban tenne ha mas modszerekkel probalna a piacra hatni, nem a sorozatos marketing maszlagjaival."
Szegény marketingesek mit csináljanak, üljenek le programozni? Szerintem az rosszabb lenne.
"Raadasul a 40 millios hirt te teljes mellszelesseggel tamogattad, tenyek felmutatasa nelkul."
Nem támogattam, csupán idéztem.
"Nem tudom erzodik-e a kulonbseg..."
Nem. Arról van szó, hogy máris qrva sokat adtak el, tehát nem bukás a Vista, mint ahogy sokan szeretnék. Ennyi, nem több.
"Kulon osztaly van gondolom az MS-nel akik az ilyen alhireket kitalaljak es megjelentetik"
Mint ahogy minden normális cégnél van ilyen osztály. Marketingnek hívják.
"Akkor lenne tisztesseges, ha a MS-rol szolo cikkel egy oldalon ott lenne a cafolat is, vagy ott lenne a konkurens termekek hasonlo bejelentesei."
Most alkalmazd ezt minden más cégre is. Nagyon vicces reklámok lennének a TV-ben.
"Ellenkezo esetben megvalosul a piacot hamis hirekkel valo befolyasolas esete..."
Stimmel. Csak azt ne akard nekem bemesélni, hogy ezt egyedül az MS csinálja. Még a linuxosok sem ártatlanok ezügyben, pedig ők nem is cégek.
"Ez most mit jelent hogy "novekednek az eladasok"?"
Azt jelenti, hogy most nagyobbak, mint korábban.
"Mikor"
Most.
"mihez kepest?"
A korábbi állapothoz képest. -
BiroAndras #260 "1) Azt pont te irtad hogy ha megfeleloen be van allitva egy rendszer akkor az r=1 user nem tudja elrontani a rendszert (nincs jogosultsaga). GUI-val se tudja elrontani, meg GUI nelkul se."
Pontosan ezért írtam, hogy nem ez a fő szempont.
"Ugyhogy ha a hazzaertoket nezzuk csak, nem latom miert ne lehetne szeretni az egyszeru es tiszta ini fajlokat."
Sokminden miatt. Például könnyebb elrontani (egy adott szintaxist kell követni, ami ráadásul programonként különbözhet).
"Elonyok es hatranyok. Van aki ezek merlegelese utan az ini mellett dont."
Természetesen. De ettől még a registry nem lesz rosz, mint ahogy a linuxosok állítják.
"A kezdo es nem teljesen hulye juzer a linux-on is szepen meg tudja tanulni a dolgokat."
De sokkal lassabban, és több hajtépés árán.
"Van aki meg tovabb akar lepni, minden aprosagot maga akar beallitani, az meg egybol megy registry-t es ini fajlokat piszkalgatni, es itt jon a kerdes, hogy ezek szamara melyik az egyszerubb, a registry vagy az ini fajl."
Szerintem normál körülmények közt nincs nagy különbség. A registry annyival jobb, hogy nem kell figyelni a szintaxisra. De mondjuk ha sokat kell gépelni (ez azért ritka), akkor a szövegfájl kényelmesebb.
"A buta juzer nem fog se ini-ket se registry-t turkalni, ugyhogy ez nem tudom miert szempont"
Nem registry vs .cfg hanem GUI vs .cfg a téma itt.
"A kerdes csak az, hogy mekkora azon felhasznalok szama, akik ebbe a kategoriaba esnek."
Mondjuk 99%? A júzerek döntő többsége sose lesz olyan profi, hogy a GUI mögé nézzen. És nem is akarják, csak egyszerűen használni szeretnék a gépüket.
"Es aki nem ebbe a kategoriaba esik, annak ne probald meg eladni a gui-s verziodat."
Egy profinak is könnyebb a GUI-t használni, mert valamennyire véd a tévedésektől, és sok esetben sokkal gyorsabb.
"Arrol nem is beszelve, hogy azt sugallod hogy ini fajlokat nem lehet gui-val allitgatni."
Ez nyílvánvalóan nem így van.
"Igen, gui segit egy darabig, de ha mar nem, akkor tok mindegy hogy registry van a hatterben vagy ini fajl, ugyanugy el tudod rontani."
Nem egészen. A registry-ben csak az adattal kel törődnöd, a .ini-t meg formázni is kell. Pl. mint már írtam a MySQL (a régebbi verziók legalábbis) nagyon kényes erre.
"Mysql is osszedob gui-val egy alap ini fajlt"
Csak 1-2 éve tud ilyet. A GUI-t feltalálták jó 30 éve.
"Szoval mi is az ami a szivast okozta a te esetedben? Nem az, hogy a beallitasok ini-ben voltak tarolva, es nem az, hogy a konfiguraciohoz nem volt gui. Hanem az, hogy amit felkinalt a gui (ha egyaltalan megnezted) az nem volt eleg, es igy kenytelen voltal kezzel belepiszkalni olyasmibe, amihez nem ertettel."
A szopást az okozta, hogy:
1. Nem volt GUI (4.0.18-as verzió). Ileltve valami kis bigyó volt, de azon semmi állítási lehetőséget nem láttam.
2. Az .ini fájlban rengeteg dolog nem volt benne, így nekem kellett összevadászni a kapcsolókat. Pl. qrva soká jöttem rá, hogy az InnoDB tábláknak külön konfigja van, és ezért nem volt hajlandó 22 megánál több memóriát használni.
3. A WinMySQLAdmin saját konfigfájlt használ, ami nem teljesen kompatibilis az eredetivel, de legalább jól felülírja azt.
4. Nagyon kényes a szintaxisra. Ha az egyenlőségjel körül akár egy szókoz is van, már nem indul el. És persze semmiféle hibajelzés nincs.
5. Nagyon szarul vannak dokumentálva a kapcsolók (ez persze független a témától).
"Szerinted milyne gyakoriak az ilyen esetek, mikor a gui mar nem eleg, es kezzel kell belepiszkalni a registry-be vagy a konfig fajlokba?"
Tapasztalatom szerint ritka. Pedig én buherálós típus vagyok.
"Es mi van akkor pl. mikor a turkalas elkerulhetetlen, mert pont ez a cel? Azaz mi van azzal mikor a sajat programod hasznalja fel a registry-t vagy az ini fajlokat? Ilyenkor is van amikor egyszerubb ini fajlokkal megoldani a problemat es nem a registry-vel bajlodni."
Szerintem nem nehezebb a registry-t b@sztatni.
"Funkcionalis szempontbol mi valtozott?"
- Egy helyen, rendszerezve vannak a beállítások.
- Automatikusan kezelhetők a júzer függő beállítások.
- Az OS védi a registry tartalmát.
- Sokkal fejlettebb a jogosultság kezelése.
- A fájlrendszer nem erre van kitalálva (sok kicsi fájl esetén nagyon nem optimális), a registry igen.
- Később még fejlettebb szolgáltatások építhetők be (pl. tranzakciók), amit automatikusan minden progi használhat.
- Ha a windows a saját beállításait egy .ini-fájlban tárolná, az kezelhetetlen méretű lenne.
- Szkriptekkel sokkal könnyebb állítgatni a registry-t, mint .ini-fájlt szerkeszteni.
Persze ezen előnyok egy része megvalósítható lenne könyvtárakkal és fájlokkal, de ott nehezebb lenne betartatni a szabályokat.
"Nagyobb eselyet latod pl. annak hogy valaki (vagy valaki altal irt gui-s program) egy ini fajlban allitson be valamit rosszul mint hogy a registry-ben?"
Igen. Mint már sokszor mondtam : szintaxis.
"Az is kulonbseg, hogy "szoveges konfig allomanybol" tobb van, registry-bol egy. Registry halott = minden halott."
A registry is több fájlból áll egyébként. És az OS csinál róla biztonsági másolatokat, meg védi is az illetéktelen csesztetés ellen. Sok szanaszét szórt fájl sesetén ezeket sokkal nehezebb megoldani.
NTFS fájlrendszernél meg egyébként is nagyon nem jellemző, hogy egy fájl véletlenül megpusztul.
Próbálom erőltetni az agyamat, de nem nagyon emlékszem olyan esetre, amikor a registry megsérült, és ez okozta a win összedőlését. Pedig nagyon régóta használok win-t és nagyon sok gépet üzemeltettem már. A registry sérülése általában sokkal súlyosabb problémák tünete (rossz vinyó, súlyos vírusfertőzés, letörölt windows könyvtár, ...), és nem az ok.
"Tok mindegy, az ini fajlt birizgalo gui-t is lehet lokalizalni, meg a registry-t matato gui-t is."
Félreérted. Itten a GUI vs. konfig fájl a téma.
"Meg egy dolog amit sokat ismetelgetsz: a fejlesztesi koltsegek. Ha meg kell irni a gui-t is (azt a fajtat ami tamogatja a tajekozatlan juzert), az mennyivel noveli a fejlesztesi koltsegeket?"
Természetesen jócskán növeli a költségetet. De a bevételeket az egekbe repíti. Egy jó GUI legalább olyan fontos, mint a jó működés, és nem csak az egyszeri júzernek.
Egyébként a GUI fejlesztési költségének döntő része nem a beállítások menüpont.
"Ezeket a fejlesztesi koltsegeket biztos hogy muszaj lenyelnie a tajekozott juzernek?"
Neki is jó a GUI.
"Ergo: a gui-val biro programnak tobbe kellene kerulnie, ha a verseny igazan eles lenne. Es akkor az IT megoldast vasarlo ceg eldonthetné hogy kifizeti-e a kezdoket tamogato gui-t es kezdoket vesz fel, vagy nem fizeti ki a gui-t es profikat vesz fel..."
Ez a kérdés eldőlt több mint 20 éve. Nem csak hogy nagyságrendekkel többe kerül a jó munkaerő, mint a GUI a használt szoftverekhez, de a profik munkáját is nagyságrendekkel gyorsítja.
Próbáljd csak meg elképzelni a mai programok parancssoros verzióját. Elég vicces eredményeket fogsz kapni. Pl. MAX, Visual Studio, Office, stb. -
Kagemusha #259 ...és ez vonatkozik a 253, 254es hozzászólásodra is, remark! -
Kagemusha #258 Kösz, nekem nem sikerült így megfogalmazni, de pont erre gondoltam. -
Kagemusha #257 "Az eccerű júzer bármilyen rendszert képes elrontani, ha nagyon akarja, nem ez a fő szempont. A különbség abban van, hogy egy kezdő, de nem teljesen hülye júzer milyen gyorsan, könnyen, és biztonságosan tudja megtanulni a rendszer konfigurálását, illetve, hogy a buta júzer tudja-e használni."
A user ne konfigurálja a rendszert, hanem használja! Megint csak nem az otthoni környezetről beszélek, hanem az ipariról.
"Szóval profiknak lehet, hogy jobb a konfig fájl, mint a GUI, de senki se születik profinak, és sokkal könnyebb megtanulni egy szoftver kezelését, ha jó GUI-ja van."
Nem figyeltél: nem az átlag user igényeiről beszéltem, hanem a tapasztalt rendszergazda igényeiről. Rendben, tanulja meg GUI-val, de nekem akkor is a konfig file a megfelelő és mint ahogy emlegetted a MySQL-nél, látom a rendszer hiányosságait az én szempontomból.
"Ja, és mégy 1: A GUI-t lehet lokalizálni, a konfig fájlt nem."
Ha már konfig file-okat matatsz, ez nem lehet probléma. Addigra illene eljutnod erre a szintre. -
Kagemusha #256 ""A Windows nem indítható, mert az alábbi fájl hibás vagy nem található: \WINNT\SYSTEM32\CONFIG\SYSTEMced"
A leírása alapján nem tűnik túl gyakori hibának. Meg azért sem, mert a google csak 3 linket dobott ki rá, amiből ez a fórum az egyik, és az MS erről szóló cikke a másik."
Ugye viccelsz? A hiba súlyosságát azon méred le, hogy a Google hány találatot dob rá? Ne röhögtess!
Mellesleg megsúgom neked: gyakori hiba. Az egész ugyanis arról szól, hogy:
"Előfordulhat, hogy a Windows 2000 rendszer nem tudja betölteni a rendszerleíró adatbázist, ha az túl nagy. Ez a probléma akkor jelentkezhet, ha egy folyamat túl sok adatot ír a rendszerleíró adatbázis System nevű alkulcsába. A System alkulcs feladata csak a számítógép rendszerbetöltéséhez szükséges adatok tárolása.
Azok a számítógépek, amelyek Intel vagy ARC (RISC) architektúrára épülnek, csak 16 MB (megabájt) memóriát használhatnak a rendszerbetöltési folyamatnak ebben a szakaszában. A rendszerleíró adatbázis System alkulcsának meg kell osztania ezt a 16 MB memóriát a betöltőprogrammal, a kernellel, a hardverabsztrakciós réteggel (HAL), valamint a rendszertöltési illesztőprogramokkal."
...és ha rákötsz X db nyomtatót (persze nem egyszerre), akkor a registry egy idő után bizony megborul! Elfossa magát és ugyan viszonylag egyszerű javítani, de véleményem szerint ez egy oltári nagy hibája a registry-nek.
Valamint ha naponta visszakerül hozzád minimum 2 PC ezzel a hibával és ugyanaz többször is, akkor az bizony gyakori hiba. Ja, hogy otthoni környezetben nem fordult még elő? Figyu, mikor kötsz a gépedre egy hónap alatt 1200 nyomtatót vagy bármilyen más USB-s eszközt?
Tehát ne magyarázd meg nekem a gyakoriságot a Google találataira alapozva, előbb menj el dolgozni egy olyan helyre, ahol 5000 gépből álló hálózatot kell karbantartani és ott mérd le... -
remark #255 Ok. Tehat a Vista nem indult se olyan jol, ahogy az MS allitja, se olyan rosszul, ahogy az MS allitasara kifakadok allitjak. Akkor most kinek jar a pirospont? Mert az egesz problema ott kezdodott hogy az MS ossze-vissza nyilatkozgatott, es szerintem az MS jobban tenne ha mas modszerekkel probalna a piacra hatni, nem a sorozatos marketing maszlagjaival.
Raadasul a 40 millios hirt te teljes mellszelesseggel tamogattad, tenyek felmutatasa nelkul. Lasd: http://www.sg.hu/cikkek/52396/kitorhet_az_ujabb_szabadalomhaboru
Idezet toled: "Az MS által közölt adat hivatalos, tehát súlya van. Ha nem igaz, azzal csúnyán lejáratja magát az MS, amire semmi szüksége. A te véleményed csupán vélemény. Idézz nekem valakit, akinek van esélye hozzáférni az adatokhoz, és cáfolja az MS állítását."
Aztan most mar igy fogalmazol: "NYílván nem az számít, hogy pont 40 millió, és pont 100 nap alatt."
Nem tudom erzodik-e a kulonbseg... ;-)
Amit erteni kell, hogy ilyen nyilatkozatok, miszerint "2x annyi fogy mint XP a hasonli idoszakban" meghogy "100 nap alatt 40 milliot adtunk el" ez masra se jo minthogy az MS jo hirnevét erositse. Kulon osztaly van gondolom az MS-nel akik az ilyen alhireket kitalaljak es megjelentetik, es ez hozzajarul ahhoz hogy milyen sok ember hasznal Windows-t. Hisz meg a csapbol is az folyik (teljesen tevesen) hogy a Windows milyen jo, milyen sikeres. Piacformalas, korantsem tisztesseges modszerekkel. Akkor lenne tisztesseges, ha a MS-rol szolo cikkel egy oldalon ott lenne a cafolat is, vagy ott lenne a konkurens termekek hasonlo bejelentesei. Ellenkezo esetben megvalosul a piacot hamis hirekkel valo befolyasolas esete... Ezt, ha komolyan venne az ember (marmint a versenyhivatal, kormany, akarki), a torveny buntetné. Nem latom mi kulonbseg van a ceg papirjai arfolyamanak ilyen modon valo feltornazasa es mondjuk a spammerek vagy bennfentes informacio kiszivarogtatasa kozott?
"És nem csak arról van szó, hogy sokat adtak el, hanem hogy az eladások növekednek is."
Ez most mit jelent hogy "novekednek az eladasok"? Mikor, mihez kepest? Konkretumokat please. -
remark #254 "Ja, és a registry tud valamit, amit egy config file soha nem tudhat: kulcs szintű jogosultság kezelést."
Es ez milyen jo.
Oracle is tud sorokat zarolni, meg felhasznalokat kezelni, a notepad meg nem. Megis van aki inkabb a notepad-dal szerkezti a szoveges adatait, mintsem hogy betegye egy adattablaba, es irjon egy programot amivel majd a tablajat kezelni tudja.
Az senki se allitotta hogy a registry-nek nincsenek elonyos tulajdonsagai. De azt ne allitsd, hogy ezek az elonyok bizonyos eseteben nem hatranyok inkabb, amikor celszerubb inkabb egyszerubb formatumot valasztani. Es ha valaki a registry teljes elhagyasa mellett dont, az lehet egy jo dontes is. -
remark #253 "Az eccerű júzer bármilyen rendszert képes elrontani, ha nagyon akarja, nem ez a fő szempont."
1) Azt pont te irtad hogy ha megfeleloen be van allitva egy rendszer akkor az r=1 user nem tudja elrontani a rendszert (nincs jogosultsaga). GUI-val se tudja elrontani, meg GUI nelkul se.
2) Pont ezert nem a GUI a szempont mikor registry meg ini fajl (rendszer konfiguracio) a tema, hanem hogy a hozzaertok kozul ki miert tartja a registry-t elonyosnek, es ki tartja az ini fajlt elonyosnek.
Ugyhogy ha a hazzaertoket nezzuk csak, nem latom miert ne lehetne szeretni az egyszeru es tiszta ini fajlokat. A registry inkabb egy egyfajta adatbazis, annak minden elonyevel es hatranyaval. Elonyok es hatranyok. Van aki ezek merlegelese utan az ini mellett dont. Szoval szerintem nem egyertelmu hogy a registry a jobb megoldas. Sot, teves reflex mindig a registry-t hasznalni, es minden apro beallitast ott tarolni csak azert mert ugyis mindig azt hasznaljuk.
"A különbség abban van, hogy egy kezdő, de nem teljesen hülye júzer milyen gyorsan, könnyen, és biztonságosan tudja megtanulni a rendszer konfigurálását..."
A kezdo es nem teljesen hulye juzer a linux-on is szepen meg tudja tanulni a dolgokat. De, reszben igazad van, es ezt mar leirtam mashol is. A gui tenyleg felkinal egy halom lehetoseget kezdetben, ami segit (kozben nem szabad elfelejteni hogy egyre tobb esetben tamogatja linux-on a kezdoket egy gui). Van aki itt meg is all, es az jol jart a gui-val. Van aki meg tovabb akar lepni, minden aprosagot maga akar beallitani, az meg egybol megy registry-t es ini fajlokat piszkalgatni, es itt jon a kerdes, hogy ezek szamara melyik az egyszerubb, a registry vagy az ini fajl.
"...buta júzer tudja-e használni."
A buta juzer nem fog se ini-ket se registry-t turkalni, ugyhogy ez nem tudom miert szempont (feltetelezve hogy meg mindig a registry/ini fajl buhera a tema). A buta juzernek ott vannak linuxon is meg windows-on is a varazslok, o igy fogja a beallitasokat kivalasztani (azt a kettot ami szamara engedelyezett).
De a kovetkezovel egyetertek, ha a "konfig fajl"-t "konfig fajl es registry"-kent kell erteni:
"Szóval profiknak lehet, hogy jobb a konfig fájl (>>es registry<<), mint a GUI, de senki se születik profinak, és sokkal könnyebb megtanulni egy szoftver kezelését, ha jó GUI-ja van."
A kerdes csak az, hogy mekkora azon felhasznalok szama, akik ebbe a kategoriaba esnek. Es aki nem ebbe a kategoriaba esik, annak ne probald meg eladni a gui-s verziodat. Arrol nem is beszelve, hogy azt sugallod hogy ini fajlokat nem lehet gui-val allitgatni.
"Figyelned kell a szintaxisra is, ami néha elég szigorú, és gyakran a progi nem is szól ha elírtál valamit, csak egyszerűen nem működik (szintén MySQL, qrva sokat szoptam emiatt)."
Igen, gui segit egy darabig, de ha mar nem, akkor tok mindegy hogy registry van a hatterben vagy ini fajl, ugyanugy el tudod rontani.
Mysql is osszedob gui-val egy alap ini fajlt, amit ha akarsz, atkonfigolhatsz. DE van mysql-es konfiguralo gui, amivel meg tovabbi opciokat is at tudsz allitani, DE ha meg ez se eleg, akkor fogod magad es kezzel atirod a konfig fajlt. Szoval mi is az ami a szivast okozta a te esetedben? Nem az, hogy a beallitasok ini-ben voltak tarolva, es nem az, hogy a konfiguraciohoz nem volt gui. Hanem az, hogy amit felkinalt a gui (ha egyaltalan megnezted) az nem volt eleg, es igy kenytelen voltal kezzel belepiszkalni olyasmibe, amihez nem ertettel.
Szerinted milyne gyakoriak az ilyen esetek, mikor a gui mar nem eleg, es kezzel kell belepiszkalni a registry-be vagy a konfig fajlokba? Van windows-on is. Tudom hogy az MS ezt vissza akarja szoritani (hogy turkalni kelljen) de attol meg emberek nap mint nap kenytelenek megtenni. Es mi van akkor pl. mikor a turkalas elkerulhetetlen, mert pont ez a cel? Azaz mi van azzal mikor a sajat programod hasznalja fel a registry-t vagy az ini fajlokat? Ilyenkor is van amikor egyszerubb ini fajlokkal megoldani a problemat es nem a registry-vel bajlodni. Es persze van olyan is mikor a registry "plusz szolgaltatasai" jol jonnek, es akkor a registry-t kell valasztani.
Tudom hogy a registry-t az ini fajlok kivaltasara talaltak ki, es milyen nagyszeru otletnek tunt, de ez nem jelenti automatikusan azt, hogy a registry minden esetben jobb. Ugyanazon adatok mas formatumban tarolasa meg nem hoz onmagaban elorelepest. Funkcionalis szempontbol mi valtozott? Nagyobb eselyet latod pl. annak hogy valaki (vagy valaki altal irt gui-s program) egy ini fajlban allitson be valamit rosszul mint hogy a registry-ben?
Az is kulonbseg, hogy "szoveges konfig allomanybol" tobb van, registry-bol egy. Registry halott = minden halott. Egy konfig fajl halott = egy valami halott. Azt azert meg tudod erteni, hogy van akinek ez szempont...
"Ja, és mégy 1: A GUI-t lehet lokalizálni, a konfig fájlt nem."
Tok mindegy, az ini fajlt birizgalo gui-t is lehet lokalizalni, meg a registry-t matato gui-t is.
A felvetes az volt, hogy eltekintve a gui-tol melyik rendszer jobb (registry vs. ini fajl). Van aki szerint ez, van aki szerint az. Nem az MS hordozza a bolcsek kovét. Rendszerkonfiguraciot nem az r=1 user fog vegezni, akinek esetleg tok jol jon egy lokalizalt gui.
Meg egy dolog amit sokat ismetelgetsz: a fejlesztesi koltsegek. Ha meg kell irni a gui-t is (azt a fajtat ami tamogatja a tajekozatlan juzert), az mennyivel noveli a fejlesztesi koltsegeket? Ezeket a fejlesztesi koltsegeket biztos hogy muszaj lenyelnie a tajekozott juzernek? Ergo: a gui-val biro programnak tobbe kellene kerulnie, ha a verseny igazan eles lenne. Es akkor az IT megoldast vasarlo ceg eldonthetné hogy kifizeti-e a kezdoket tamogato gui-t es kezdoket vesz fel, vagy nem fizeti ki a gui-t es profikat vesz fel... Jelenleg a kerdes igy nem teheto fel. -
remark #252 "Az egész registry-t kinyírni azért komoly feladat. Ha megfelelően van beállítva a rendszer, akkor nem is tudod, mert nincs hozzá jogosultságod. Valamint vissza is lehet állítani (ha jól tudom az XP-nek is van valami ilyesmi funkciója)."
Az osszes "szoveges konfig allomanyt" unix-on "kinyírni azért komoly feladat", ha a rendszer "megfelelően van beállítva ", "mert nincs hozzá jogosultságod". "Valamint vissza is lehet (őket) állítani", ha megis problema lenne.
Hol van itt a kulonbseg? Ott van, hogy a registry-t senki se fogja segedeszkozok nelkul szerelgetni, mig egy szoveges fajlt ha kell megjavitok egy vi-al. -
#251
Ha már így szóbakerült a legmélyebb szintű konfig, nem tudja valaki, hogy a WinRAR-t hogy lehet rábírni Vista alatt, hogy működjön a jobb katt környezeti menü az UAC kikapcsolása nélkül? -
BiroAndras #250 "A rendszer jóságát véleményem szerint nem éppen a rendszermatató GUI programok megléte vagy nemléte dönti el, mint ahogy általad is említett módon, hiába van GUI a registry piszkálásához, ha egyszer r=1 user ül a gép előtt, akinek a hozzá nem értése hatalmas akaraterővel párosul."
Az eccerű júzer bármilyen rendszert képes elrontani, ha nagyon akarja, nem ez a fő szempont. A különbség abban van, hogy egy kezdő, de nem teljesen hülye júzer milyen gyorsan, könnyen, és biztonságosan tudja megtanulni a rendszer konfigurálását, illetve, hogy a buta júzer tudja-e használni.
Mindkét dologban a GUI segít. A GUI-n könnyen megtalálod, hog miket lehet állítgatni. Többnyire nem döntheted romba a rendszert, mert a GUI figyelmeztet, vagy egyáltalán nem engedi a veszélyes paramétereket piszkálni, és megmondja a lehetséges értékeket. A konfig fájlokban néha nincs benne minden paraméter (alapértelmezett értéket használa a progi), így nem is tudod, hogy miket lehet állítani (így jártam pl. a MySQL-lel). Figyelned kell a szintaxisra is, ami néha elég szigorú, és gyakran a progi nem is szól ha elírtál valamit, csak egyszerűen nem működik (szintén MySQL, qrva sokat szoptam emiatt).
Szóval profiknak lehet, hogy jobb a konfig fájl, mint a GUI, de senki se születik profinak, és sokkal könnyebb megtanulni egy szoftver kezelését, ha jó GUI-ja van.
Ja, és mégy 1: A GUI-t lehet lokalizálni, a konfig fájlt nem.