[80] Zase výpady prý... No, zkusme přejít k technickým věcem.
Na prvním místě můžeme vzít v úvahu ten návrh Linuxu. Viděl jste Linusův mail, který jsem linkoval? Myslíte, že takhle vypadá správný přístup k designu operačního systému?
Monolitický kernel je zastaralá koncepce společná dřevním unixům, Windows 95, OS/2 a Linuxu. Linus v podstatě žádný design systému (hodný toho výrazu) neprováděl, a prostě napsal to, co byl schopen v jednom člověku nejsnáze implementovat. Vyjma jiných věcí napsal kernel bez preempce, stejně jako byly napsány dřevní unixy. Tolik k design decision a a monolitickému kernelu.
Kernel thready jsou opravdu o něčem jiném, než servery (terminologie ze světa mikrokernelů, uvozovek netřeba). Samozřejmě user mode daemoni či jejich obdoba jsou na většině systémů, ale to není k věci.
K preempci kernelu: původní "návrh" kernelu Linuxu byl nepreemptivní. Jakmile se nějaké volání propadlo do jádra, zůstalo tam do doby, než obsluha volání v jádru skončila. Je to společné Linuxu a dřevním unixům. Samozřejmě latency trpí, a výkon v SMP je velmi mizerný. Bylo třeba dodělat zámky na hromadě kernelových struktur, a předělat scheduler. Scheduler není takový problém, ale zámky ano, protože je to změna na veliké spoustě míst. Výsledkem je (po dlouhých letech údajně stabilní) option CONFIG_PREEMPT, ke které se vrátím. Protože to ale trvalo dlouho, kdosi přišel s tím, že by pro začátek stačila preempce na nejhorších místech, a byl vymyšlen ošklivý hack jménem CONFIG_PREEMPT_VOLUNTARY (podívejte se na detaily implementace, to je fakt síla). CONFIG_PREEMPT_VOLUNTARY sice zajišťuje možnost preempce kernelu jen na pár místech, ale je fakticky stabilní. Výsledkem je, že se zvuk uživatelům neseká vždy a všude, ale jen když systém trochu zatíží :). Kernel s CONFIG_PREEMPT je bohužel dodnes tak nestabilní (a výkon tak nekonzistentní), že jej žádné běžné distro nejede (nebo jede? ukažte mi takové). A v nějaké starší dikusi jsem linkoval vyjádření vývojálů kernelu, kde byla option CONFIG_PREEMPT označena za dobrou pro debugging jádra, ale uživatelům bylo doporučeno ji nepoužívat.
I/O management se netýká file systémů. Podívejte se, jak Linux řeší obsluhu interruptů. Pokud přijde interrupt, zakáží se všechny interrupty, a probíhá obsluha toho, co přišlo. Zatím co obsluhujete přerušení nějakého méně nedůležitého zařízení, které může počkat, uteče vám třeba přerušení od zvukové či síťové karty. Ve Windows může interrupt s vyšší prioritou přerušit obsluhu interruptu s nižší prioritou. Detaily popisoval i Mikuláš Patočka na rootu, viz link níže. Upozorňuji, že od roku 2003 se ani v jednom systému obsluha přerušení výrazně nezměnila. Co jsem se minulý měsíc díval na použití makra local_irq_disable(), je ve zdrojáku Linux kernelu 2.6.16-rc3 použito na 413 místech. http://www.root.cz/clanky/porovnani-linux-freebsd/
Rozdělení na moduly vypadá na příklad ve Windows tak, že máme Hardware Abstraction Layer. Linux má místo něj hromadu ifdefů. Ve Windows také drivery nejsou součástí kernelu - kernel má stabilní API pro kernelové moduly (včetně driverů). Linkovaná "mapa kernelu" je graficky pěkná, ale o modulech neříká vůbec nic. Tedy pokud nemáte na mysli novotvar "modularita na úrovni zdrojáků" :))
X11 protokol je pomalý, na tom se shodneme. Největší problém je v hromadě zbytečných round tripů. Ovšem rozdělení na klient a server part komunikující s jistým overheadem i v rámci jednoho stroje věci také nepomáhá. Dokumentace X11 protokolu dost trpí, protože řada serverů se snaží o bug-to-bug compatibility, existuje dlouhá řada X11 extensions s různou úrovní dokumentace, a často to vypadá tak, že aplikace běhají správně jen proti X11 serveru, pro který jsou psané.
Důvod, proč X11 server není multithreadový, je jasný. Linux totiž multithreading až do kernelu 2.6 neměl, resp. ve 2.4 měl v takovém stavu, že to byla ostuda (LinuxThreads). Řada unixů na tom svého času byla dost podobně. Pokud nějaký web server jede za pomoci workprocessů namísto threadingu, bývá to typicky proto, že threading na dané platformě stojí za starou bačkoru. Nutno říci, že multithreading byl na NT už v návrhu, a je provedený lépe, než umožňují pozdější dodělávky (třeba na Linuxu).
"message se vyridi rychle jsou latence male" - to byl doufám vtip
Serializaci přístupu ke GPU vůbec neřešte. Je to totiž jako řešit, jak zhasíte svíčku v hořícím domě.
Ještě ke grafickým primitivům a X11. Základní funkcí GDI ve Windows je to, že si vyberete zařízení, a řeknete "chci 5cm velkou kružnici červené barvy, vyplněnou zeleně". Co se nestane - ať už si vyberete konzoli, Remote Desktop session, nebo tiskárnu, vyleze z toho 5cm velká kružnice správné barvy. GDI se postará o rozměry, a dokonce o shodu barev díky podpoře profilů zařízení. Vyjma toho vám umožní vyrobit 6-kanálové separace atd. Ovšem WPF jde ještě dále, když přehazuje na GPU grafické karty i vyšší grafická primitiva, a tedy HW akceleruje rastrování fontů (font cache ve video RAM), antialiasing, ClearType, ale i věci typu zrcadlení ap. Srovnejte X11 s GDI a WPF ve Windows, a s Core Graphics na MacOS X. Smutné srovnání pro X11.
Lidé si nechají vtlouct do hlavy spoustu věcí. Na strojárně naučí lidi technickým písmem i myslet, výuka základů unixu zase u neobvykle vysokého procenta lidí po pár měsísích vzbudí lásku k vi a bušení hromady příkazů na konzoli. Po nějaké době používání Gimpu jeho ovládání člověku už nepřijde tak příšerné. Podobně autoři aplikací si typicky myslí, že interface jejich aplikace je vlastně OK, bez ohledu (mnohdy smutnou) na realitu. Tak to prostě je, s tím se nedá moc dělat. Leda hledat testery mimo současné uživatele.
Shodneme se, že support i dokumentace by vždy mohly být na ještě lepší úrovni. Vy byste možná dal přednost zdrojáku a kontaktu na vývojáře. Firmy ale dávají přednost tomu, aby zdrojáky byly pod zámkem, a vývojáři ukrytí za hromadou lidí ze support dept. Důvody jsou zjevné: ze zdrojáků pod zámkem nemůže opisovat konkukrence, a vývojáři nemusí řešit opakované a stupidní dotazy (zeptejte se na obojí u Oracle a IBM coby známých propagátorů open source). Navíc si nemylím, že by vývojáři byli vhodní na support, a supporti na vývoj.
