V konkurencnich systemech se tohle vyresilo zavedenim ukladani konfigurace do relacni DB s zurnalem (napr. registry ve windows) uz nekdy pred 15ti lety ....
Mně už asi dvakrát opravdu jen tak samo od sebe a levé pracky opravdu nemám. Zkuste uznat, že ne všechno je dokonalé, a ne se hned do ostatních navážet, děkuji.
Jasne, na win registry se vzdycky snese spousta kritiky, ony samozrejme nejsou dokonale. Ale myslenka ukladat nastaveni systemu nebo aplikaci do databaze neni spatna. Jen bych pouzil neco pruhlednejsiho a otestovaneho. Treba SQLite, tuhle db, tusim, nejaky open-source projektu jiz pouziva (prosim, doplnte me). A pak uz je jen krucek k centralizaci do jedne db spolecne pro cely system. Jen bych pak pouzil MySQL nebo PostgreSQL nebo tak nejak. Proste neco znameho, overeneho a otevreneho. Ne podivne win registry. Jo a ta dababaze by nakonec mohla byt i objektova nebo relacne-objektova, konecne i ruzne ty ruzne settingy se dnes drzi objektoveho schematu - myslim ruzne cleneni do podskupin a zavislosti mezi nimi.
Jasne, ja netvrdim opak. S SQLite sam zkusenosti nemam, uvedl jsem jej jen jako priklad. Proste si myslim, ze databaze maji aplikacim v ohledu konfigurace co nabidnout. Diskutovat o tom, ktera je nejlepsi pro dany ucel (objektova x relacni x objektove-relacni x xml, MySQL x PostreSQL x ...), muzeme cely den :-))
Jasne, nejlepsi je Oracle. Ten vam umozni rozlozit ci zrcadlit vasi konfiguraci po pocitacich okolo cele zemekoule a to i s transakcemi. Budeme si tak navzajem zalohovat konfiguraci alespon na deseti pocitacich v ruznych casovych pasmech a bude to naprosto spolehlive.
Zapomnel jste na podporu streamovanych medii, PL/SQL, technologii Total Recall pro udrzeni historie starsich nastaveni (kvuli navratu k posledni zname konfiguraci), snadnou spolupraci s Oracle enterprise stackem a dalsi.
Zrovna na tu historii jsou lepší soubory – dají se verzovat třeba pomocí Mercurialu (používám na /etc). A když se pak něco „vysere“ dá se snadno vrátit zpátky – pokud tedy člověk ve vhodných okamžicích (či pravidelně) „commituje“ :-) Verzování v databázi je vždycky trochu ‚opruz‘ – ale zase to má jiné výhody.
Z vaseho prispevku citim sarkasmus. Ale verte, ze zhruba to, co popisujete, velke firmy pro sve aplikace vyzaduji. Tedy az na ta casova pasma a zrcadleni "okolo cele zemekoule". Uplne staci par zrcadel do kazdeho aktivniho regionu - EMEA, LATAM, NORAM, JAPAC.
Treba americka pobocka Deutsche Bank po 11. zari 2001 prisla o sedm zamestnancu a vsechna originalni data. Bez funkcnich zrcadel by business uz asi nerozjeli. Podobne si myslim, ze vas prispevek by neocenily spolecnosti sidlici v oblastech suzovanych hurikany, zemetresenimi a dalsimi katastrofami (Kalifornie, Florida, Japonsko, ...).
Ukladat systemove nastaveni do databaze je padle na hlavu. Pokud se tam ulozi neco natolik spatneho, ze uz system kvuli tomu nenabootuje, tak oprava byva dosti obtizna (z live CD je jednoduche poeditovat textove konfiguraky, u binarni databaze by tam musel byt nejaky specialni nastroj a pokud se treba u te DB nejak nabori index tak, ze se to uz nespravi, tak je clovek v loji .... z binarniho blobu se uz nezachrani obvykle nic, z textove konfigurace clovek vystipne poskozenou cast a muze ji zkusit dopsat odjinud (treba z defaultni konfigurace))
Navic implementace ve windows, kdy registry nejdou rozumne zalohovat (ani admin nema sanci si je nekam rozumne zkopirovat) je obzvlaste nestastna (taky spousta aplikaci do registru uklada veci ktere by tam asi patrit nemely (nacachovane thumbnaily), byt to je spis problem tech aplikaci nez systemu, kazdopadne vysledkem je dosti bordel)
Hele, ja tady neobhajuji zadne dogma. Kazdy nastroj ma trosku jine vyuziti a ja netvrdim, ze nastaveni ulozene v db je samospasne. Ok, se systemovymi zalezitostmi souhlasim, tam bychom se pripravili o moznost rucni opravy, tedy bez specializovanych nastroju.
Ale spousta desktopovych aplikaci potrebuje proste uzivateslka data proste nekam ulozit a pak je v poradku nacist. Tak proc to vyvojarum nezjednodusit - typovost ulozenych hodnot, podpora objektove-relacniho modelu, transakce, zurnal (viz. clanek), zalohovani, system opravneni atd, to vse muze vyvojarum pomoci. Protoze tuhle funkcionalitu si stejne vyvojari musi nejak napsat sami. Kdyz uz pouzivame Qt nebo GTK pro GUI, tak proc nepouzit nejakou knihovnu pro jednotne reseni konfigurace pomoci db? Staci jen nebat se porusit zazita dogmata, ze konfigurak *musi* byt textak, popr. xml.
„Tak proc to vyvojarum nezjednodusit - typovost ulozenych hodnot, podpora objektove-relacniho modelu, transakce…“
A kdo jim to zesložiťuje? :-) Vždyť stačí mít nainstalovanou PostgreSQL (s „ident sameuser“) a každá aplikace ať si založí svoje schéma a do něj si nastavení ukládá. Klidně si do těch tabulek může ukládat třeba XML dokumenty :-)
Tak v prvni rade by bylo fajn, kdyby existoval jeden styl konfiguraku, treba nejake DTD v XML. A pak by nebyl problem, aby si kazdy mohl vybrat, jestli chce opravdu textaky v XML (nebo dokonce v necem jinem, co umozni stejne figle), nebo v registrech nebo treba vytetovane na zadech. Tohle by uz byl back-end za nejakym uzivatelsky (programatorsky) privetivym front-endem, ktery by nerozlisoval, jak jsou dane konfiguraky ve skutecnosti zapsany.
Jakmile by tohle existovalo, dalo by se premyslet, jak to implementovat lip a lip. Treba by se nakonec ukazalo, ze nejlepsi by bylo tahle data ukladat na zvlastni diskovy oddil, kde by fungoval zurnal, prava atd... prizpusobene potrebam konfiguraku. Nebo neco jineho (treba soubory v /etc :-)). Podstatne je, ze kazdy by si mohl vybrat, co prave jemu vyhovuje. Nekdo pozaduje rychlost, nekdo zase bezpecnost, nekdo zase aby si mohl konfiguraky cist jako detektivku. A vsechny konfiguraky by vypadaly stejne (a nebo taky ne - neni duvod, proc by cast konfiguraku nemohla byt ulozena jinak nez jina cast - kazdopadne by byly pristupne pomoci jednoho front-endu).
Zapisovani a cteni konfiguraku neni obvykle nejaka kriticka operace, takze to muze byt i pomalejsi, nez by pro dany pripad bylo mozne.
Tohle je nesmysl – použití XML pro konfiguráky je dobré, resp. asi nejlepší, ale není možné vytvořit jedno DTD použitelné pro konfiguráky různých aplikací – leda že bys ten konfigurák degradoval na dvojice klíč hodnota zapsané pomocí XML. Případně bys mohl ono univerzální DTD navrhnout aby neumělo jen klíč=hodnota, ale i strom, obsahující tyto dvojice…
…bystří už možná vědí…
…ano, XML samo o sobě je takovým stromem, XML jako takové je formát a standard, který se dá dobře používat, není potřeba dělat univerzální DTD platné pro všechny aplikace – tohle je úplně zcestný přístup a nepochopení XML. Je také dobré se zamyslet nad sémantikou – pokud budu mít univerzální DTD (či schéma), mám tam prakticky dvojice klíč=hodnota, zabalené do ostrých závorek, tudíž jen tak nevím, co to je za data (obecně nevím, co znamená klíč "abc.wer.sfg", to ví jen ta aplikace, která ho používá) → proto můžeme pro konfiguráky používat jakékoli XML, stačí, když bude validní – sémantice nebudeme* rozumět tak jako tak, ale v případě, že nevnutíme aplikacím nějaké „jediné správné univerzální DTD pro ukládání konfiguráků“, jim dáme možnost naplno využívat výhody XML, protože každá aplikace si může napsat DTD podle vlastních potřeb (aby odpovídalo strukturám, které je potřeba ukládat).
*) z pohledu nějakého univerzálního nástroje nebo API
XML má ve věci ukládání konfigurace problém, kterým trpí i textové konfiguráky. Při změně hodnoty je nutné XML kompletně překopat, což je celkem náročné. Konfigurace stroje v Windows má běžně pár desítek MB textu, a změny musí být rychlé.
Na editaci textu potřebujete textový editor, na editaci XML potřebujete XML editor, na editaci konfigurační DB zase asi editor konfigurační DB. Nevidím to jako zvláštní nevýhodu.
Binární strukturu lze samozřejmě také opravovat. Viz běžné DB, viz fsck. Možnost porušení binárních struktur existuje i na vlastním FS, ale není to důvod kvůli tomu FS zavrhovat. Navíc se podívejte na existující implementaci. Ve Windows k problémům s poškozením konfigurační DB prakticky vůbec nedochází (nebavíme se o hodnotách v té DB), a navíc je vždy udržována Last Known Good Configuration.
Registry samozřejmě lze zálohovat, umí to i backup vestavěný ve Windows. A které aplikace ukládají do registry thumbnails?
Uz se tesim, jak si v MC oteviram nejakou databazi namisto textaku. Doufam, ze tam do te doby dodelaji databazoveho klienta. :-)
BTW, myslenka registry mozna ma neco do sebe, ovsem ne MS prasecina, kde je vse rozptyleno po cele databazi zcela nahodne tak, ze clovek nikdy nedokaze dohledat vsechna nastaveni tykajici se konkretniho programu. Tez, kdyz nekdo prijde s necim, jako je registry, cekal bych, ze jiz od prvni verze k tomu bude opravny nastroj spustitelny z Widli a pro nejhorsi pripady, kdyz uz Widle nenajedou, tez bootovaci disk s opravnou utilitou a podporou FS obvyklych na dane verzi Widli. Na oboji se MS vydlabl s tim, ze se ma zalohovat registry. Uz vidim, jak kazdy honem zalohuje registry po kazdem updatu. Navic clovek nikdy nevi, kdy registry zacalo byt namrsene a jestli uz nezalouhuje nabouranou verzi. A prictete si spolehlivost 3.5" disket...
Jedine, co kdy MS zplodil, bula nepodporovana utilita z doby Win NT 4.0 a od te doby nic. Web se sice hemzi vselijakymi registry cleanery, ale cert jim ver, ze nenadelaji vice skody, nez uzitku.
Textaky maji sice sve slabiny, ale jejich obrowskou silou je opravitelnost ci nahraditelnost i za obzvlaste neprizniveho pocasi, coz se o registry rici neda. Cili ne, dekuji. Spokojim se se zastaralymi textaky, o ktere by si LO ani kolo neoprel.
Nejsem člověk, který by se měl tendenci zastávat MS, nicméně, od dob Windows 98 si systém automaticky dělá zálohu registrů po úspěšném nabootování (to vím zcela jistě, protože jsem si několikrát z ní zachraňoval systém, když po nějakém ne tak docela povedeném experimentu s low-level device driverem nenaběhl).
Jistě, můžeme oprávněně namítat, že Windows 95 a spol. podobnou vlastnost neměly (byť mám neurčitý pocit, že ve Win95B už jakýsi náznak existoval) a že toto řeší následek a nikoli příčinu, ale taky bychom se neměli uchylovat k tvrzením, která byla aktuální před deseti lety, to je jen pozvánka pro fanatické MS trOLy.
Zminka o disketach mi prijde celkem vtipna kdyz si vzpomenu, ze ackoliv MS sam doporucoval udrzovat v registrech jen to nejnutnejsi, po instalaci MS Visual studia nabobtnal registr o vice jak 8 MB :-)
To jsou zase perly. Konfigurace není v Registry náhodně rozptýlená, ale umístěná do cesty, kde jí autor aplikace zamýšlel uložit. A že jedna věc může mít konfiguraci na více místech? Když máte řekněme ekonomický systém na unixu, také má konfiguraci DB a aplikačního serveru na různých místech. Podobně u OOo těžko rozlišit konfiguraci Writeru od zbytku OOo, protože je řada komponent sdílených v rámci celého balíku.
Windows mají na instalačním médiu automatický repair, což je užitečná feature. Záloha Registry se pořizuje automaticky, a vždy máte Last Known Good Configuration, o čemž se vám s konfiguráky může jen zdát. Utilita pro registry cleaning z NT4 se podle všeho starala o HODNOTY zapsané v Registry, ne o vlastní Registry jako úložiště hodnot; a stejné je to s těmi pochybnými "čističi registry" pro lamy. Je to asi podobné, jako byste měl na Linuxu utilitu, která proskenuje /etc a ~/.* na nesmysly (třeba odporující si nastavení, deamony startující z neplatných cest, a duplitity sekcí a klíčů v konfigurácích), a pak tvrdil, že taková aplikace je na Linuxu hrozně potřeba.
Můj Amarok si ukládal informace o písničkách do PostgreSQL → rychlejší vyhledávání a člověk si může snadno selektovat ze svojí kolekce :-) Ale jak jsem přešel na Amarok 2, tak tam už jsem nikde volbu databáze neviděl.
Tak to jste štastný člověk, že se vám to nikdy nestalo. Hm, a dovolím se zeptat, používáte taky krom Poznámkového bloku něco jiného? Děkuji za odpověď. Každopádně jste jeden z mizivého počtu. Mě se tedy problémy s registry nyní úspěšně vyhýbají. Asi to bude tím, že je již nepoužívám. Ubuntu (a mnoho dalších kvalitních distribucí linuxu) je mnohem lepší, bez urážky. Zbavilo mě závislosti na 3D hrách a konečně, díky bohu za ty dary, nezažívám všudypřítomné restarty. Ještě dodám, že na MS Windows jsem měl všechny updaty, sw jsem se snažil aktualizovat jak to šlo (opravdu je smutné, že Windows ještě nemá repozitáře a mnohem jednodušší správu ověřeného sw od poskytovatele OS). Já tedy s registry skoro problémy neměl (pokud jsem si nehrál s jejich obsahem), ale hodně uživatelů, co o PC moc nevědí a pro které by MS Windows mělo být tedy vhodné, mi stále naříká, jak jim nefunguje to či ono. Já abych pak k nim jezdil a opravoval poškozené registry? Hm, děkuji. Dnes už jim říkám, ať si zaplatí "opraváře", já na tohle nervy opravdu nemám. Ale znám i lidi, co mají Vistu a žádný problém prý nemají (to říkají po tom, co jsem jim těžce zprovozňoval wifi - všeobecný problém na Vistě).
Ano, pouzivam, ted jsem mj. pripojeny pres wifi na vistach, ktera mi na nb bezi spolehlive bez reinstalace rok a pul. uptime mam ted 2 dny, vybil se mi ve skole.
To, ze jste byl zavisly na 3d hrach nebyla chyba systemu, ale Vasi slabe vule, tak to sem netahejte.
A uzivatele, kterym se ve vistach neco vysere? Uz se mi stalo, ze mi prisel od kamarada pres IM virus.. Pisu mu, ze tam ma viraka, at nepousti sracky z linku, ke kterym mu nikdo nic nenapise, nebo at nainstaluje antivir. "Ja tam antivir mel, ale vypnul jsem ho, protoze rval, a byl jsem zvedavy co mi to ten znamy posila". Pak to svadejte na OS, kdyby takovy clovek mel linux, a program po nem chtel prava, tak 'su -c' to jisti ;]
mnohem jednodušší správu ověřeného sw - fakt? vite o cem mluvite? treba.. digitalni podpisy potrebne pro import do GAC, ..?
To, že vám osobně funguje wifi rozhodně neznamená, že takto dobře jede všem. Mě taky na XPčkách funguvala skoro vždy, pokud jsem používal sw dodaný výrobcem, nativně velmi blbě, je ale pravda, že Visty nemám, jen u kamaráda. Děkuji nechci. Já bych o tom nepsal, kdybych to nemusel pořád u známých řešit. Zvláštní, že od té doby, co je pořádný ovladač na linuxu, tak už nemám žádné problémy a systém natvivně zvládne každou wifi, co vidí.
O těch 3D hrách byla trochu nadsázka, je vaše věc, že mě berete jako závisláka bez vůle. Ok, je to vaše věc. Když o mě nic nevíte, hned nesuďte, nemám to rád.
Co se týče toho viru, tak jsem tu vaší hlášku opravdu nepochopil, můžete mi to přeformulovat do češtiny? Link místo odkazu ještě skousnu, ale z vaší zprávy nevyplývá, zda se vám to stalo na Windows nebo na Linuxu (ano, opravdu jsme na portálu zabývajícím se linuxem, zajímavé, že). Ale ok, vydedukoval jsem, že mluvíte o Windows. Jasně, že mohu použít sudo (konkrétně v Ubuntu), ale jakmile ho používám, vím, že dávám programu neomezené možnosti. Mě to tedy třískne do očí. Pokud je uživatel tak naivní, že su či sudo dává všude, tak :-D pápálálá.
K té správě - repozitáře těch "lepších" distribucí jsou kontrolovány, nemluvím o těch neoficiálních. Teď tu nechci nic plést, ale mám dojem, že základní repozitáře podepsány jsou ;), mám tak problém třeba u Wine, když nepřidám podpis, to pak správce řve při každé instalaci wine atd.
Abych vám jen vše nevyčítal, opravdu nevím, co je GAC, do příště prostuduji. Asi jsem lama ;). A já se za to nestydím.
MadWifi také nic moc. Nefungovaly "pokročilé" věci typu ad-hoc mode a WPA-PSK, zamrznutí Linuxu při inicializaci driveru, při připojení k síti, do 20 minut po připojení k síti, dočasné zastavení stroje během inicializace driveru a připojování k WiFi atd. Přitom karty Atheros byly považovány za slušně podporované.
Malware už nepotřebuje oprávnění roota. I v kontextu běžného uživatele může malware běžet ve vaší session, odesílat spam, posílat HTTP či DNS požadavky, a stahovat si vlastní "aktualizace".
Ale ne, ext4 pouze natahla "nebezpecnou" dobu pro data z cca 5s na 150 za cenu urciteho narustu vykonnosti. Tedy pokud budu ukladat do db-like storage, tak se s tim nic neporesi, protoze pri padu dojde ke ztrate transakci, tedy i ztraty novych dat (samozrejme pro tohle je pak dulezite, aby DB podporovala ACID, coz o win-registrech pochybuju). Hadat se o tom, zda prijit o posledni transakci nebo o data v tomto pripade je bezpredmetne
To co je opravdu problem je nasledujici:
cp file file1
rm file
<reset/crash>
Obavam se, ze v tomhle pripade ext4 neni uplne to prave orechove
Výhoda DB by byla v transakcích – sice přijdeš o nová data, ale zůstanou ti aspoň ta stará (v případě, že ti to spadně ještě před commitem …nebo krátce po něm) – ale nepřijdeš o všechno.
Ve Window ukládáte informaci do Registry, takže není nutné kompletně konfiguraci mazat a znovu vytvářet. Navíc Registry má transakční mechanismus, takže pro každou konkrétní hodnotu najdete buď novou hodnotu, nebo tu starou (žurnálování Registry). Navíc Windows umožňují ACID transakce, takže můžete transakci začít, zapsat změny do několika různých DB, změnit hodnotu v Registry, založit soubor, přejmenovat soubor, a pak teprve celou tuto transakci potvrdit nebo odrolovat. Jde o využití 3-fázového commitu a transakčního koordinátoru. Skoro bych řekl, že unixům tohle bude ještě chvíli trvat.
FUUUJ, doufam, ze k tou nikdy nedojde na linuxu. Neznam nic lepsiho, nez konfiguracni soubory, akorat by se nemusely vsechny valet v ~, delaji tam neskutecny borde.. A ta vlastnost ext4 o ktere se pise je IMHO neprijatelna. Neco napisu, pak dam ulozit, sem v pohode, myslim si ze to mam ulozene a pak vypnou elektriku... a sem ... vite kde.
Jenže tohle hrozí vždycky -- leda že by sis zapnul synchronní zápis na disk, ale to zase drasticky sníží rychlost (a taky záleží jestli něco nezůstane v mezipaměti přímo na disku -- to by se při výpadku proudu taky ztratilo).
tak jeste jednou, pokud neco napisete (fwrite) date ulozit (fsync) tak o nic samozrejme neprijdete. pokud vsak jen neco napisete (fwrite) tak se pak nedivte ze se to neulozilo..
to je jako v textovem editoru: pisete do dokumentu a pak ho(textovy editor) bez ulozeni vypnete a divite se, ze se neco/nic neulozilo, kdyz to prece pred tim, v jine verzi editoru, ktera mela zapnuto automaticke ukladani po 5sec, vzdy fungovalo..
Tady je trochu problem s tim, ze u mnoha typu souboru aplikacni programator nechce striktne "vynutit ulozeni". Pokud programator dela open("config.tmp"), write(), close(), rename("config.tmp", "config"), tak vicemene chce "budto starou nebo novou verzi dat, je mi to jedno" (POSIX nic takoveho negarantuje, nicmene v podstate vsechny filesystemy se takhle nejak chovaly (az po XFS/ext4/ZFS/vse co dela odlozenou alokaci).
Alternativa open("config.tmp"), write(), fsync(), close(), rename("config.tmp", "config") je zbytecne silna. Aplikaci obvykle nezajima aby na disku byla ta novejsi data - chce budto konzistentni stara, nebo konzistentni nova data (nejlepe aniz by aplikace musela cekat na nejakou diskovou operaci). Coz prostredky POSIXu bohuzel neni jak jadru rict - fsync() je prilis silne. Myslim ze pristup ext4 ve 2.6.30+ (vynutit alokaci a tedy i zapis dat pred metadaty pri close() a truncate()) je vicemene spravny.