Vlákno názorů k článku
Podíl Windows klesl pod 90 % od nn - Mně by se asi líbilo, kdyby se v...

Můj scanner také nebyl ve Vistě podporovaný. Našel jsem nepodporovaný driver pro 32-bit Vistu, pro 64-bit nic. Tak jsem si koupil lepší scanner, a za odpoledne bylo vyřešeno.

To že ste udělal? To se mi ani nechce věřit. Kdyby řekl linuxák, že si koupil kvůli ovladačům novej scanner, tak máte druhý vánoce.

Na to není potřeba geekovský zásah, to může udělat třeba instalátor napsaný v PyQt nebo ncurses (viz ovladače na nVidii)

Ale to je znovu totéž. Pokud administrace systému a vývoj pro danou platformu jsou tam jednoduché, že je zvládne více lidí, je to přece jen dobře. Proč bychom jednoduché věci měli dělat složitě? Jen proto, aby je mohlo dělat co nejméně lidí, kteří budou nutně muset být chytřejší? Kde chcete sehnat pro každou firmu hromadu těch unixových adminů z osmdesátých let, co chodí v bílých pláštích a galoších, a vyjma přidávání uživatelů a nastavování permisions umí programovat ve třech jazycích? Ten posun je dávno jasný: IT se používá všude, a administrace (a dalších nákladů) nechť je jen nebytné minimum. Obdobně se místo TeXu a Metapostu používají WYSIWYG nástroje, protože grafiky je potřeba spousta, a nemá smysl počet grafiků zbytečně omezovat tím, že by museli umět vyjádřit své grafrické cítění v TeXu a Metapostu. WYSIWYG nástroje jsou tedy také dobré.

Merge změn dvojklikem na .reg soubor je obtížný? Export do texťáku v regeditu (či na command line) je obtížný? Ani jedno si nemyslím. Editace Registry nemá být potřeba, od toho máte konfigurační GUI. Přijde mi to jako stěžovat si, že naFS můžete jen přes FS API nebo nějakou aplikaci. Ale samozřejmě máte regedit, a command line utility (regedit, reg.exe).
Naopak Registry má jisté zásadní výhody. Je to rychlejší vyhledání hodnoty (binární strom vs slow seek konfiguráku), o hodně rychlejší zápis (konfigurák je nutné kompletně přepsat), možnost čtení při zápisu konfigurace (konfigurák se přepisuje, takže zrovna není možné ho číst), a možnost současného zápisu z více aplikací/threadů. Nakonec výhod Registry se snaží dosáhnout i GConf a podobné na Linuxu.

LLVM je zajímavý experiment. .NET i Java optimalizují obdobně. Bohužel řadu věcí automaticky optimalizovat nelze. Například pokud máte větší cache, můžete prodloužit velikost jednotlivého zpracovávaného bloku dat, což za vás LLVM, .NET ani Java neudělají. Dalším hřebíčkem do rakve je fakt, že optimalizace je třeba primárně u malých částí kódu, které se ale často optimalizují v ASM (například explicitní použití MMX/SSE/SSE2 instrukcí).

Řekněme, že o prdeli dosud nebyla řeč. MS KB popisuje troubleshooting. Samotné slovo troubleshooting říká, že asi nepůjde o úplně běžnou aktivitu.

Jak verzujete konfiguraci na unixech? My to ve Windows neděláme (konfigurace není scratchpad), a pokud ano, tak prostě provedeme export větve Registry k danému datu. Ty soubory lze bez problému srovnávat. Tímhle způsobem lze také rychle najít mapování mezi GUI options a příslušnou hodnotou v Registry (ano, člověk by měl hledat v dokumentaci, tohle je quick and dirty way).

Ve Windows použáváme jiné nástroje. Například máme Domain Policy, díky které lze řadu věcí nastavit hromadně pro řadu počítačů. Máme také auditing, takže můžeme například auditovat změny konkrétních částí Registry. Když si k tomu pověsíte event sink na událost, můžete výsledek sypat do nějaké vzdálené DB. Ve výsledku pak víte, kdy a kým bylo co změněno. Pravda je, že jsem to ještě neviděl takhle používat.

Ano, everything is file. Problém je, že řada věcí není file. Deamon není file, zvuková karta není file, okno není file. Objekt je daleko lepší abstrakce. Bohužel v době vzniku unixů objekty ještě moc nebyly, a od té doby se unixy nijak nepohnuly.

Jak optimalizujete uhnixový konfigurák? To by mě fakt zajímalo.

Ano, Windows mají v případě havárie řadu možností, co se s tím dá dělat. Hlavně si ale všimněte, že se jedná o tak řídké události, že řada lidí vůbec neví, že nějaké recovery options existují.

Export Registry mi problémy nedělal, importovat desítky MB jsem nikdy nepotřeboval. Kde je zádrhel?

Jak to uděláte? Buďte konkrétní.

Jak konkrétně budete pracovat s deamonem nebo oknem jako se souborem? Třeba vytváření oken, nebo callback, to by mohlo být zajímavé.

Pojem "Uhnixovy konfigurak" je zjevně překlep, mělo být "unixovy konfigurak". Takže jak?

Možnosti jsou, jak jsem psal.

Kde konkrétně je v daném případě s importem Registry zádrhel?

Pak ovšem vše není soubor, a tento koncept končí na command line.

Zkuste brzdit s doporučeními, a popsat, jak budete optimalizovat konfigurák tak, aby se z něj rychleji četlo či do něj rychleji zapisovalo. Psal jste mi, že je to velmi účinné: "Uvedomte si ze unixovy konfigurak je porad obycejny textovy soubor (everything is file) a podle toho s nim muzete manipulovat, optimalizovat ho (jsou velmi ucinne metody optimalizace vykonu), menit a zalohovat."

Zádrhel jste mi nepopsal. Prostě popište, jaké *konkrétní* problémy se vyskytnou, když importujete veliký .reg soubor. Zatím jste okolo toho jen chodil jako okolo horké kaše.
"Zkuste si nekdy na frekventovanem stroji s windows udelat import .reg souboru o velikosti nekolika desitek MB. Nekdy je to opravdu jedina cesta a MS nastroje vam nahazi pod nohy tolik klacku zebyste dal jejich autorum (pravdepodobne uhrovatym brigadnikum s praxi max. tyden) pesti do tlamy."
"Export Registry mi problémy nedělal, importovat desítky MB jsem nikdy nepotřeboval. Kde je zádrhel?"
"V tom ze jste to nikdy nepotreboval a tudiz nezkusil ze to nejde."
"Kde konkrétně je v daném případě s importem Registry zádrhel?"
"ZADRHEL JSEM VAM POPSAL."

Unixovy konfigurak je soubor a nemusi byt vubec textovy. To je super. A nebyl jste to vy, kdo před pár dny v tomto threadu psal:
"Uvedomte si ze unixovy konfigurak je porad obycejny textovy soubor (everything is file) a podle toho s nim muzete manipulovat, optimalizovat ho (jsou velmi ucinne metody optimalizace vykonu), menit a zalohovat."
http://www.root.cz/zpravicky/podil-windows-klesl-pod-90/240979/

Problém s pomalým čtením a zápisem do konfiguráků se typicky řeší tak, že se zavede interface, skrz aplikace konfiguraci čtou a zapisují. Takovým interfacem jsou ve Windows funkce pro práci s Registry, v Gnome je to GConf, v KDE je to KConfig, na MacOS je to interface pro property listy, v AIXu Object Data Manager. Pak se vezme nějaký backend, do kterého se konfigurace píše. Na Windows jsou to Registry, na AIXu obdobný binární formát, MacOS používá také binární formát (od XML odešli, nebylo dost efektivní), KConfig používá XML, GConf XML soubory. Pokud je back-end textový, je asi třeba k němu držet binární index, a zápis to rozhodně neurychlí (je třeba přepsat texťák, a ještě aktualizovat index).

Teď zkuste myslet vy, a odpovědět mi na tři otázky.
1. Proč je Registry špatně, a KConfig, GConf, ODM a property listy dobře?
2. Proč je správně mít uloženou konfiguraci KMailu pomocí v KConfig, kdežto konfigurace řady jiných věcí prostě *musí* být v textovém konfiguráku?
3. Jak optimalizujete ty textové konfiguráky? Podle vás jsou jsou velmi ucinne metody optimalizace vykonu.

A nemohu si odpustit jednu jízlivou. Pořád vám to připadá "lepsi zabava nez sledovani primeho prenosu z parlamentu", a chcete mě doporučovat, aby se já doucil teorii? ;)

Aha, to je konečně něco rozumného. Jaký systém to byl? Windows řady 9x? Tam je problém popsaný (najít referenci na MS KB je věc na pár desítek sekund - naučte se to také), a týká se pouze situace, kdy běžíte regedit v real mode. Proč ale probírat omezení Windows 9x, které jsou dávno mrtvé?
http://support.microsoft.com/kb/132064

Prosím k věci a konkrétně.

1. Můžete a nemusíte se smířit s tím, že obdobu Registry používá řada systémů, včetně Linuxu. Důvody jsem popsal. Důvod, proč některé unixové aplikace používají textové konfiguráky, které zapisují a čtouve vlastní režii, jsou zjevné: a. dřevní unixy neměly žádné API pro manipulaci s konfigurací; b. v dřevních unixech bylo obtížné napsat cokoliv, takže se autoři aplikací nezdržovali s nějakým gui pro nastavování aplikace, a používali komentované konfiguráky; c. dnes jde o zvyk, a to je, milý pane, železná košile.
2. Vím a znám spoustu věcí. Zpět k věci. Proč je správně mít uloženou konfiguraci KMailu pomocí v KConfig, kdežto konfigurace řady jiných věcí prostě *musí* být v textovém konfiguráku?
3. Opravdu nechápu, proč mi nechcete říci, jak se optimalizují textové konfiguráky. Když něco tvrdíte, tak to buď umíte podepřít fakty, nebo jen plácáte. Zatím to vypadá na tu druhou alternativu. S tím používáním mozku je to sranda - vychovávat můžete svoje děti, ne mě.

Z čeho budu mít užitek? Z toho, že mi řeknete, jak se optimalizují konfiguráky, aby se rychleji četly a zapisovaly? Hmm, a nechcete zaplatit za konzultaci? :))

A ty vy si vždy vyberete jen jednu věc, ke které se umíte "vyjádřit", a zbytek pro jistotu přejdete, aby nebyla vidět vaše neznalost?

Na začátku této otázky stál váš výrok, tak předpokládám, že víte, o čem jste mluvil, a dovedete to rozvést.

http://www.root.cz/zpravicky/podil-windows-klesl-pod-90/240979/

V tom příspěvku jste tvrdil: Uvedomte si ze unixovy konfigurak je porad obycejny textovy soubor (everything is file) a podle toho s nim muzete manipulovat, optimalizovat ho (jsou velmi ucinne metody optimalizace vykonu), menit a zalohovat.

No a mě by zajímalo, jak optimalizujete konfiguráky tak, aby se z nich rychleji četlo, či se do nich rychleji zapisovalo. Předpokládal jsem, že alespoň víte, co jste psal.

Nepřipadá vám to samotnému jako nesmysl? Velikost Registry je v daném případě podobně irelevantní, jako velikost FS, na kterém je ten textový soubor.

Máte ještě podobnou úvahu o rychlejší změně hodnoty v konfiguráku, který kvůli tomu musíte celý přepsat? ;)

Třeba tak, že uživatel vyhledá dané nastavení v GUI, podívá se, a změní ho :). Nebo může provést export nastavení, poté změnu v textové verzi, a import nastavení. Nebo může použít utilitu reg.exe, a tou nastavení změnit. Nebo použije regedit. Vyberte si, máte toho celé menu.

Samozřejmě je mi jasné, že chcete říci "programovat neumí, ale zrovna náááhodou umí regexpy, a má to nastavení v konfiguráku; hle, použije sed, a je hotovo". Mimochodem samotné zadání té akce mi přijde poněkud šroubované, vám ne? ;)

Složitost binary search je logaritmická, složitost slow search lineární. Binary search jasně vyhrává. Více nevidím důvod to řešit.

Velikost Registry i FS jsem označil za irelevantní.

Nepíšu jen o změně hodnoty, ale také o změně hodnoty. Konfigurák musíte kompletně přepsat, což se změnou hodnoty v binární DB ani náznakem nesnese srovnání.

Testovací Windows XP, právě jsem provedl import 224MB souboru .reg. Windows 2000 měly tuším limit velikosti hive na 102MB, opět to šlo konfigurovat.

Praxe je taková, že s importem .reg souborů není žádný problém.

Můžete si všimnout, že jsem netvrdil, že teoreticky nic nebrání tomu, aby to fungovalo. Já to prakticky vyzkoušel. Takže praxe je taková, že to funguje. Vzhledem k tomu, jak nekvalifikované příspěvky sem typicky anonymové píší, si dovolím odhadnout, že v popsaném případu šlo o jeden z následujících scénářů: 1) import na Windows 9x, kde v real mode bylo omezení, které jsem linkoval; 2) překročení nastavené maximální velikosti Registry; 3) corrupted registry hive, nebo jiný obdobný problém; 4) celá příhoda je vymyšlená.

2. Co je za obrovský problém s Registry v tom, když překročíte nastavenou velikost Registry? Není obrovským problémem konfigukáku, který by bez konfiguráku nevznikl, když překročíte kvótu místa na disku? :)
3. Registry Hive teoreticky může být corrupted, stejně jako FS.

Zkuste také své příspěvky podepisovat, nebo si vymyslet přezdívku. Rád bych věděl, se kterým anonymem mluvím. Je to dobré pro udržení threadu.

Co máte pořád s tím arabským jménem? Lael Ophir není arabské jméno, a já rozhodně nejsem křesťan. Zkuste se raději držet tématu diskuse.

Deamon není file, zvuková karta není file, okno není file

Technika everything is file neříká nic o oknech, démonech ani zvukových kartách, ale o jejich komunikaci mezi sebou a se systémem. Vůbec ji nezajímá, kdo si povídá a s kým (samozřejmě pokud má příslušná oprávnění). Zrovna u té zkukové karty je zvukový výstup většinou datový proud, tedy soubor.

Ano, zvuková karta produkuje na konci streamy. Jenže aplikace potřebuje nastavit parametry výstupního zařízení, což interface "všechno je soubor" neřeší. Nakonec stejně skončíte u nějakého IOCTL. Další sranda je callback, který se "všechno je soubor" také nelze provést.

Všimněte si, že u objektové abstrakce není problém vzít objekt deamona, podívat se v jakém je stavu, a zavolat metodu Stop. Jak tohle uděláte u konceptu "všechno je soubor"?

IOCTL je opět ve stylu "vše je soubor". I souborům je nutné nastavovat nějaké parametry (třeba práva nebo je syncnout) a IOCTL je jednotné rozhraní.

Callback by šel udělat metodou "vše je soubor" jako filtr.

Otevřu pojmenovanou rouru (UNIX socket, stdandardní vstup v /proc, ...; podle toho, co používá) toho démona, a podkud to existuje, tak běží a můžu mu tak poslat Stop.

IOCTL s voláními specifickými pro daný interface, které samozřejmě nemůžete generovat pospojováním utilit.

Callback jako filtr? Super představa :). Co třeba notifikace při změně obsahu adresáře? Já myslel, že se používá inotify, a ne filtry na souborový handle.

Jistě, pokud deamon nějaký takový interface má. Na unixu ho mít asi musí, ale bohužel každý deamon jiný. Samozřejmě by unixům slušel services manager, kde by byly služby registrované včetně vzájemných závislostí, a byl by tam standardní interface pro akce typu spustit/zastavit deamon, změnit kontext ve kterém startuje, změnit popis atd. Takhle máte hromadu skriptů, které které komunikují s každém deamonem jinak.

Samostatnou kapitolou v knize "vše je soubor" je /proc. Aby vše bylo souborem (nějak na Linuxu, trochu jinak na jiných unixech, a vůbec na dalších unixech), tak se vytvoří wrapper, který umožní přístup k informacím, a nastavování hodnot. Bohužel soubory jsou špatná abstrakce. Objekty mají vlastnosti, metody, a události (callbacky). Soubory nemají ani jedno, takže ze /proc taháte data v textové formě, a pak je parsujete. Události jsou prakticky vyloučené, a snad jen zápis je vyřešený akceptovatelně. Jaká škoda, že unixy před 20 lety nezavedly objekty.

K věci, prosím

Například pokud máte větší cache, můžete prodloužit velikost jednotlivého zpracovávaného bloku dat, což za vás LLVM, .NET ani Java neudělají.

LLVM zvládne i to. Resp. kde by to zvládl kompilátor při překladu zdrojáku, tam to zvládne i LLVM (třeba přes nějakou konstantu načtenou z runtime). Na druhou stranu větvení kódu tohle nezvládne, přinejmenším ne dynamicky.

Dalším hřebíčkem do rakve je fakt, že optimalizace je třeba primárně u malých částí kódu, které se ale často optimalizují v ASM (například explicitní použití MMX/SSE/SSE2 instrukcí).

Tak se vyrobí tři větve optimalizované v assembleru (to LLVM taky umí) a před spuštěním se napevno vezme ta, která je podporovaná. Vůbec nevidím, kde má větvení kódu navrch.

Aha, LLVM zvládne prodloužit velikost jednotlivého zpracovávaného bloku dat, když si to tak napíšete. Naproti tomu bez LLVM si to tak musíte napsat. Kde je tedy ta výhoda LLVM?

Opět pokud už máte tři optimalizované větve v ASM, tak není třeba LLVM. Samozřejmě to, že se vybere jedna z nich již při inicializaci aplikace, je běžné, a nepřináší to overhead.

Aha, LLVM zvládne prodloužit velikost jednotlivého zpracovávaného bloku dat, když si to tak napíšete. Naproti tomu bez LLVM si to tak musíte napsat. Kde je tedy ta výhoda LLVM?

Ta hlavní výhoda je, že se to optimalizuje až na cílovém stroji tamnímu hardwaru na míru, ne při překladu u vydavatele na pár základních konfigurací.

Opět pokud už máte tři optimalizované větve v ASM, tak není třeba LLVM. Samozřejmě to, že se vybere jedna z nich již při inicializaci aplikace, je běžné, a nepřináší to overhead.

To sice ano, ale přináší to overhead při vývoji, protože musíte to samé napsat třikrát v assembleru, v LLVM to stačí napsat jednou a v C nebo C++ (což samozřejmě snižuje cenu za vývoj a zvyšuje spravovatelnost kódu a taky zjednodušuje portování) a LLVM to optimalizuje automaticky podle aktuální konfigurace stroje (stejně jako by to udělal kompilátor), na kterém se to spustí. Navíc LLVM umí provést ten překlad jen při prvním spuštění, pak už je aplikace rovnou spouštěna optimalizovaná.

Co konkrétně máte na mysli tím "na míru HW"? Problém je v tom, že LLVM a obdobné technologie (včetně .NETu a Javy) mají velmi omezené možnosti optimalizace. Zkuste si napsat kodek v C/C++ bez optimalizace, a nechat jí jen na LLVM, nebo obdobné technologii. Prostým faktem je, že u takové aplikace budete muset napsat více větví, které budete ručně optimalizovat.

Merge změn dvojklikem na .reg soubor je obtížný?

To není merge, ale přepis. Vůbec to neřeší konflikty ani to neumí spojovat více možných větví vývoje konfigurace.

. Je to rychlejší vyhledání hodnoty (binární strom vs slow seek konfiguráku)

Většinou není. Naprostá většina aplikací ten konfigurák projde při spuštění nebo změně, jinak jej drží zpracovaný v paměti. A to je mnohem rychlejší, než se neustále dotazovat do nějakého binárního stromu na disku.

o hodně rychlejší zápis (konfigurák je nutné kompletně přepsat)

Zapisuje se typicky při změně nastavení aplikace a při jejím ukončení a to se tak často neděje, takže tohle není problém.

Merge dvojklikem na .reg soubor je opravdu merge, nikoliv přepis. Konflikty řeší přepisem cílové hodnoty, spojování více konfigurací obdobně. Samozřejmě s .reg soubory si můžete libovolně hrát.

Fakt si myslíte, že ten binární strom je jen na disku? A fakt myslíte, že se po hodnotách se ptáte z Registry pokaždé, když je potřebujete?

Dalším problémem je, že Windows používají komponenty (ano, to slovo už je dnes slyšet i na unixech). Když máte v systému pár tisíc či desítek tisíc komponent, a potřebujete někde skladovat informace o nich, Registry se velmi hodí. S textovými konfiguráky by to šo o dost hůře.

Jinými slovy mi tvrdíte, že pomalé čtení z konfiguráku vlastně není problém, zápis také ne, ale zato "spojování více možných větví vývoje konfigurace" je důležité. K problémům se současným přístupem ke konfiguraci z více threadů či procesů jste neřekl nic. Je to problém, nebo není? Proč GConf prakticky duplikuje Windows Registry, a je to dobře, kdežto Windows Registry je špatně?