Nezaspal Linux dobu s monolitickým jádrem?

Je to jiný přístup ke stejné problematice. Architektura mikrojádra je výrazně komplikovanější a má větší overhead. Navíc se to (podle vývojářů Hurdu) velmi špatně ladí, protože je třeba sledovat velké množství událostí a dějů v nezávislých částech jádra. U Hurdu konkrétně je problém v samotném startu projektu. Nebylo to obvyklé „od nejmenšímu k většímu“, ale rovnou se vymyslela halda skvělých a moderních věcí, ale chyběli lidé k jejich implementaci.

Zas takove psani historie to neni, pamatuji se, ze jsem o tomto pristupu slysel ve spojitosti s bell labs a tim systemem, co delali po Planu9, a u te myslenky se tam odkazovali hluboko do minulosti. Pak si jeste vybavuji system z doby nekdy pred 10 lety, ktery se vlezl na jednu disketu a byl v nem i webovy prohlizec.

Plan 9 měl jisté zajímavé vlastnosti. Nicméně MS má obrovskou koncentraci kapitálu, lidských zdrojů i know-how. Navíc je čím dál větší procento aplikací psané v .NETu, takže půjdou na novou architekturu poměrně snadno přenést. Díky tomu má možnost projekt slušně teoreticky podložit, a uvést ho v život nejen v laboratoři, ale i na trhu. MS úspěšně uvedl na trh DOS, Windows, Windows řady NT, a řadu dalších technologií, takže to asi celkem umí.

Dost pochybuji. Viděl bych to na jeden z dalších marketingových hrobečků firmy Microsoft. Ale souhlasím s tím, že je MS dost silný na to, aby mohl plýtvat prostředky na podobné nesmysly a ustál to.

BTW – DOS není vynález firmy Microsoft. DOS existoval dávno před tím, než Bill Gates vylezl ze střední školy.

Proř by to nebylo realizovatelné? Brání tomu něco konkrétního?

Co třeba Microsoft Bob? Taky „převratný vynález“, který je dnes jen hrobečkem.

A co má s diskutovanou tématikou společného Microsoft Bob? Dokazuje nějak jeden neúspěšný projekt firmy, že jiný naprosto odlišný projekt musí být také neúspěšný?

Bob i WinFS jsou převratné vynálezy, u kterých by bylo hezké, kdyby se nasadily, ale umřely. Naprosto stejně to vypadá se Singularity. Mimochodem Singularity není první, kdo s něčím takovým přišel, daleko pokročilejší Inferno (které umělo i běžet na jiném operačním systému nebo distribuovaně) také pohořelo.

UNIXy jsou děravé, jako cokoliv jiného v IT průmyslu. Nezávislost na platformě je fikce, ne realita. Webové aplikace jsou díky HTML interfacu ve srovnání s desktopem pořád chudými příbuznými. Multiplatformní knihovny představují kompromis, který na každé platformě vypouští část její funkcionality. Navíc uživatelé na každé platformě čekají něco jiného. Na MacOS chtějí menu jako součást horní lišty, a minimum nastavování někde ve File/Preferences (OOo/X11 je mimochodem zcela katastrofickou ukázkou mizerného portu). Ve Windows čekají menu v okně aplikace, ukládání nastavení do Registry a konfigurační dialog v Tools/Options. Na Linuxu se zase nosí komentované textové konfiguráky.
Důkazem mého tvrzení o multiplatformním SW je fakt, že úspěšného multiplatformního SW je minimum. A kde je aplikace úspěšná na více platformách, tam je zpravidla silně upravená pro cílovou platformu (viz MS Office pro Mac). Výjimek je jen pár.

Neposlouchejte Laela, on nic neumí a nic vám neřekne, jen bezduché plácání, nic víc. Odkazovat na školu fakt může jen člověk, který se tu ohání školními znalosti, ale praxi má nulovou.

Proč byste měl skrptovat právě a jen spouštěním programů s parametry, a následným parsováním výstupu? Má to řadu omezení, o některých jsem psal. Objektové programování je dobrý nápad, a právě PowerShell ukazuje, jak ho velmi dobře využít i při skriptování. V praxi většinou neexistují relevantní důvody, proč se OOP vyhýbat.


Proč byste chtěl stahovat antivirus bez nutně otevření prohlížeče? I dnes asi najdete antivirus na FTP nějakého výrobce, ale uniká mi důvod.

Ten výběr prohlížečů vnucený od EK je samozřejmě pěkně nesmyslný. Za chvíli bude MS jako autor produktu mít instalační wizard o 100 krocích. Krok 21: vyberte prohlížeč, sto možností. Krok 21, vyberte přehrávač multimédií, dvě stě možností. Krok 67, vyberte kalkulačku, tisíc možností. Krok 99, vyberte instant messenger, stovky možností. Samozřejmě k tomu bude MS dotlačen, aby byl zachován svobodný trh. A samozřejmě tím nijak nebudou dotčeny svobody MS, protože v EU platí svobody jen pro toho, koho má EK zrovna v lásce. Ostatním může EK udělovat kdykoliv jakékoliv pokuty, bez pravidel, bez pevných kritérií. Fuj.


Fakt vám připadají miliony uživatelů Seznamu k věci, když se bavíme o uživatelích desktopů? Oni totiž uživatelé Seznamu na ty servery zpravidla neinstalují kdejakou blbost obsahující malware, nezakazují aktualizace atd.

Linux je zabezpečen jedinou věcí, a to je jeho zanedbatelná rozšířenost. Digitální podpisy nejsou při instalaci nutné na Windows ani na Linuxu, a podporované jsou na obou platformách. Ovšem ve Windows jsou podepsané i ty nainstalované soubory, aby bylo možné podpis v případě potřeby později ověřit. Navíc pokud změníte či smažete soubor, který je součástí Windows, tak se automaticky nahradí původní verzí. Rootovské akce sice vyžadují heslo, ale pokud víte něco o X11 events (na Windows window messages), tak jste si všiml, že lze odchytit a podvrhnout stisky kláves (a řadu jiných věcí). Ve Windows to řeší Secure Desktop, což je ta šedivá obrazovka použitá u zpráv UAC.


Počítač s unixem jistě není pro každého. Také si všimněte, že cestu na stůl uživatelů našly ty systémy, které se používají i spravují celkem jednoduše. DOS, MacOS, OS/2, Windows. Unixy se nikdy na desktopu neuchytily, protože jsou k uživatelům vysloveně nepřátelské. Linux přinesl jistá vylepšení, ale zjevně to nestačí. Nedodělky, nefungující aplikace, složitá správa, chybějící a mizerná lokalizace, GUI jako když pejsek a kočička vařili dort, nemluvě o výrazně odlišných stylech GUI pro různé aplikace (Qt vs GTK vs Java). A pro autory SW je to zjevně také problém. Několik frameworků, ale ani jeden není funkcemi srovnatelný s platformou Windows. Dokumentace ve srovnání s MSDN mizerná, školení na trhu prakticky nejsou.

Naštěatí tu ale máme i systémy jako Windows a MacOS, které jsou psané pro uživatele.

Zas někdo ladí Svobodnou Evropu, místo aby četl Rudé Právo?

Jako v tom starém vtipu, kde na schůzi chlapi poslouchají, jaké je to v tom Sovětském Svazu skvělé, jaký je tam pořádek, jak jsou plné obchody a dělníci pracují rádi a z plných sil…
Přihlásí se Franta Novák a povídá: „No víte co, já jsem v tom Sojuzu byl, a měli tam pěkný bordel, v obchodech regály prázdné, kolbeni se v pracovní době flákali po městě a chlastali vodku.“
A na to školitel: „Novák, míň cestovat, víc číst!“

Proč M$ sám ve svém NEjnovějším, NEjrychlejším a NEjbezpečnějším prohlížečí používá nějaký vykopávkový Trident a ne tolik propagovaný .NET? Možná proto že by pak byl ještě pomalejší než kdybych ho napsal v tom BASICu na Spectru ;-)

Milý Radovane, až napíšete nějakou velkou aplikaci, budete tohle vědět sám. Kvalitně napsaný kód nemá smysl přepisovat do nového prostředí jen proto, že je nějaké nové prostředí k dispozici.
.NET je o trochu pomalejší, než nativní aplikace. Ale kdybyste o projektu Singularity něco málo věděl, tak by to bylo asi i to, že oddělení procesů pomocí invariant je výrazně rychlejší, než tradiční oddělení procesů. Takže co tratíte na pomalejším .NETu, to zase získáváte na nižší režii správy procesů. Najdete to pod heslem Singularity na Wikipedii, v jednom z linkovaných PDF dokumentů, včetně výsledků měření.
No a teď sde můžete zase vrátit ke svému ZX Spektru.

MSIE je komponentový, FF je velký binární BLOB. Trident je multithreadový, Gecko pořád ne. MSIE je možné rozšiřovat na úrovni browseru i stránek, FF jen velmi omezeně. MSIE běží v sandboxu, FF ne. Zato měl FF za minulý rok více děr než MSIE. No tak nevím..

Ne, to není ten sandbox. To jen zase nevíte, o čem mluvíte.

FF je komponentový, založený na XUL. FF lze rozšiřovat velmi detailně na úrovni browseru i stránek, právě díky XUL. MSIE stále s velkým odstupem vede v počtu kritických chyb a dlouhé době, než jsou dostupné opravy. Navíc MSIE dodnes neumí správně vykreslovat stránky a nepodporuje XHTML ani SVG.

FF NENÍ komponentový, je to velký binární BLOB. Rozšiřovat ho lze, ovšem doplňky nejsou kompatiblní ani mezi minor verzemi. Spolu s pomalým XUL je to dohromady velká hrůza.
MSIE umí vykreslovat stránky správně. Naopak řada stránek pořád nejde korektně ve Firefoxu.

FF NENÍ komponentový, je to velký binární BLOB

Prosimte, bez si o tom neco precist a do te doby uz mlc, svou blbost jsi tady ventiloval jiz dostatecne.

FF je komponentový, jediný „binární blob“ je jádro, které zpracovává XUL.

XUL je zpětně kompatibilní. Nekompatibilní jsou některé doplňky, které spoléhají na nedokumentované vlastnosti (což je ale i spousta aplikací ve Windows a doplňků pro IE). Navíc XUL je (na rozdíl od doplňků do IE) multiplatformní.

MSIE neumí vykreslovat stránky správně: http://www.gtal­bot.org/Browser­BugsSection/MSI­E8Bugs/ Ve FF je oproti tomu bugů naprosté minimum (v současné verzi jeden) a řada stránek nejde korektně ve FF, protože ta řada stránek je špatně napsaná (spoléhá na chybné chování IE místo na standardizované chování).

Velice zalezi, co Vam tam bezi. Syscally jsou uz dost optimalizovane a k castemu prepinani kontextu dochazi jen u nektere zateze. Napriklad u nfsd (a podobnych), ktere bezi v kernel mode, zmenou na diskutovanou architekturu 100% prodelate.

IMO to uspech mit nebude, stejne jako ho nemel Plan9, ktery mel nahradit UNIXy – ty ale byly proste dostatecne dobre, takze do prechodu se nikomu nechtelo.

Každý OS má jazyk, který je pro něj nativní. Například unixy mají definici interfacu v C (POSIX). Pokud má OS typu Singularity API kompletně v .NETu, tak vývojáři asi nebudou psát aplikace v C. Problém není v tom co programátoři (ne)zvládají. Problémem je fakt, že programátoři v principu dělají chyby. C/C++ jednak svádí k chybám, a potom ty chyby často končí tichým vyhnitím aplikace (Valgrind a podobné nástroje řeší malý kousek problému).

Ta dokumentace nic nemění na tom, že je to hnusný hack (jako kdyby se to nedalo vyřešit při resolvení symbolů, sám jsem už udělal několik takových knihoven – nebo Windows nic jako LD_PRELOAD neumí?), který navíc lze velmi snadno obejít.

Tak na prvním místě je třeba opakovat, že je blbost brát do ruky debugger a patlat s ním, když je věc zdokumentovaná. Na Linuxu je to pravda s dokumentací mizerné, a proto se časato leze do zdrojáků. Naštěstí jiné systémy mají lepší dokumentaci.
Detaily implementace Protected Mode mě moc nezajímají. Pracuje to podle dokumentace, a to je důležité. Navíc autor nijak neprokázal, že dochází k modifikaci kódu knihovny. Jedná se jen o jeho odhad. Klidně může jít o běžný API hooking.

Nejde o API hooking, který funguje přes exportované symboly (= změna adresy funkce), jde o hnusný hack, při kterém se mění kód knihovny, resp. se přepisuje prolog funkce, který lze navíc jednoduše obejít (= fakt super zabezpečení) a je úplně jedno, jestli je to zdokumentované a prodávané jako „super technologie“ (což MS dělá).

To nema cenu… s nim se neda debatovat, jen tady mele svoje marketingova moudra, FUD a blaboli o vecech, kterym nerozumi.

Minule jsem mu tady uvadel skvely priklad „zabezpeceni“ vypnutim kusu kodu, ktery zpusobuje zbesile spamovani aplikacniho logu ve Windows prostym klikanim v napovede (CHM soubory). Reseni MS? No, popiseme to v KB a je to vyreseno. Zdokumentovana chyba jiz neni chyba, to je vlastnost! Je dira v ActiveX? Naco to opravovat, proste to pres killbit „vypneme“, chyba „zmizi“, opraveno! Ze tam ten nebezpecny kod porad je a kdokoliv ho muze kdykoliv zase zapnout, to je jedno. Hlavne ze uz to neni videt, zametli jsme to pod koberec, opraveno!

A k věci?
O killbits jsme už mluvili. A ukázalo se, že opět netušíte, která bije.

Ano, to jsme mluvili… nic rozumneho z tebe nevypadlo. Pokud nadale zastavas nazor, ze se vadny deravy kod opravi tim, ze zmenim hodnotu v registru, tak je opravdu zbytecne se bavit dal. Normalni clovek si muze tak jedine poklepat na hlavu nad takovymhle „opravovanim“ bezpecnostnich der.

Ještě jednou: ten link nijak nedokazuje, že došlo ke změně kódu knihovny. Jde pouze o domněnku. Na tom opakování té domněnky nic nezmění :)

Zajímavé, že najednou ani neumíte číst v dokumentaci: Detours intercepts Win32 functions by re-writing the in-memory code for target functions ;)

Tak potom to dokázáno asi je :). Otázkou je důvod. Hooking se dá obejít, kdežto detours se obcházet nedají. Že by tohle byl důvod?

A ještě detail. Změny zavedeného kódu se používají i v jiných situacích. Například syscall se ve Windows realizuje použitím instrukcí INT 2E nebo SYSENTER/SYSCALL, podle typu procesoru. To se řeší tak, že se do paměti namapuje stránka se správnou verzí kódu. V tomhle případě je to forma optimalizace.

Zjistil jsem něco o detours. Jsou produktem MS Research, který je rutinně používá při svých pokusech na Windows. Dali dohromady detours jako framework, kde označíte funkci, poskytnete pre-processing code (běží před původní funkcí), post-processing funkci (běží jako poslední), a máte k dispozici pointer na původní funkci (včetně zachování těch prvních pár instrukcí).

Běžný hooking má proti detours nevýhody. Konkrétně neřeší interní volání přesměrované funkce v rámci knihovny, a navíc se dá obejít (calls on pointers obtained from the LoadLibrary and GetProcAddress APIs early in an applications execution). Viz kapitola 4 linkovaného dokumentu, kde se porovnává více metod.

http://resear­ch.microsoft.com/pub­s/68568/huntu­senixnt99.pdf

Při troše znalosti věci to nakonec není prasárna, ale poměrně elegentní a dokumentovaná technika ;)

Přesměrované funkce v rámci knihovny může řešit mov edi,edi, které lze snadno přepsat krátkým jumpem a kvůli kterému to tam vůbec je. Ale stejně daleko čistší řešení je int 3.

Detours se dají obejít ještě jednodušeji, stačí přepsat kus paměti předem známou hodnotou. U hookingu stačí navíc při startu aplikace zahookovat jmenovanou funkci GetProcAddress – a zkuste to obejít.

Při troše znalosti věci je to prasárna, ze které se dělá ctnost. Dobré je to tak na debugging (nicméně to dobře mate backtrace, takže ani tam bych to nepoužíval – od toho máme int 3), ale ne pro produkční nasazení, jak to udělal a propaguje MS.

Přečtěte si ten link. The major drawback to breakpoint trapping is that debugging exceptions suspend all application threads. In addition, the debug exception must be caught in a second operating-system process. Interception via break-point trapping has a high performance penalty. Konkrétně je Breakpoint Trap je 17× pomalejší, než detour, viz table 1 v kapitole 4.
Zahookováním GetProcAddress určitě nedocílíte přesměrování volání, které provádí interně daná knihovna (hook na messagebox nebude fungovat u volání messageboxu přímo z knihovny).
Short jump místo mov edi,edi je samozřejmě možný. Jenže musíte být schopen umístit cíl skoku do vzdálenosti povolené short jumpem. A zkuste něco nacpat do –128 až +127 bytů od vstupního bodu. V kapitole 2.2 uvidíte, jak se u detours řeší skok (far jump), a kam se umisťuje kód hooku (sekce .detours).
Osobně nevidím důvod, proč by detours nešly používat v produkci. Vidíte nějaký konkrétní důvod?

Detour NENÍ nástroj debugging. V produkčním prostředí můžete potřebovat změnit funkcionalitu existující aplikace. Není to nijak neobvyklý požadavek. Jedna z možností je použití detours při „živém“ patchování, kdy se nahradí příslušná funkce v knihovně (nebo kernelu) bez nutnosti zastavit aplikaci, službu nebo OS.
Operační systémy zpravidla nebrání aplikaci přepsat vlastní kód. Důvodem jsou například techniky dopředné modifikace kódu, které mohou aplikace používat.
Protected Mode je funkční opatření, které zahrnuje víc prvků. Jedním z nich je i omezení některých akcí doplňků browseru. Dalšími jsou omezení přístupu k disku a k registry, a omezení možnosti posílat některé window messages. Tato opatření zjevně mají smysl.

Detours se obcházet nedají? Ha ha ha, to je přímo PR vytržené od MS, přitom si to stačí zkusit a zjistíte, že obejít to je velmi jednoduché, protože tam je vždy prolog funkce, čili ani není potřeba někde hledat v paměti, je tam vždy to samé:

mov edi,edi

push ebp

mov ebp,esp

A jen tak mimochodem by mě zajímalo, jak obejdete hooking, aniž byste musel dělat analýzu kódu toho hooku?

Vážený pane. Nedělejte ze mne blbce. Dokumentaci samozřejmě znám zpaměti. Vy se oháníte MSDN a berete ji za Bibli, já, který o tom vím mnohem víc než Vy vím, že je psána i s nádechem marketingu, protože je veřejně dostupná. Microsoft Vám tam rozhodně nenapíše, že celý ten jeho slavný Protected Mode je implementovan pomocí crackerských technik (a technik používanými počítačovými viry ještě z dob MS-DOSu).

Veškerá implementace toho Vámi vyzdvihováného „sandboxingu“ je řešena v user space. Prakticky není problém jej obejít a jak už jsem napsal, několikrát jsem to i musel dělat. Také píšete nesmysly. Browser i doplňky mají přístup k disku. Pokud už to nejde přímo, jde to obskurdní metodou pomocí broker procesu. Broker Proces může byt povolen v uživatelském profilu, není potřeba mít práva administrátora.

Celý ten sandboxing je k smíchu. IE úspěšně zablokuje posílání zpráv do normálního procesu a duplikování handlů mapované paměti, už ale neblokuje přístup do sdílené paměti přes její jméno (což se mi zrovna hodilo). Není taky problém umožnit doplňku pracovat s okny cizích aplikací, třeba je schovávat, nebo z ních získávat data. V konečném důsledku není problém pro doplněk malovat po obrazovce dle libovůle a tak různě maskovat svou činnost. Co mě dost překvapilo, je třeba to, že doplněk IE může instalovat hooky, což je zásahy do celého systému a používají je třeba keyloggery.

Shrnuto podtrženo: – detours používají crackerské techniky a techniky virů – pouze otravují slušné návrháře, kteří si při produkci nemohou dovolit obcházet oficiální API – naopak ochrana proti podvratnému kódu je nulová, protože Detours lze snadno obejít. – Detours také řeší jen následek, nikoliv příčinu. Možná to je ochrana proti spuštění nechtěného kódu došlého třeba přes buffer overrun, na druhou stranu, je to řešení vedoucí spíš k problémům, než k vyřešení daného problému. Konečně, proč by přes buffer overrun nemohl přijít kód, který řeší i obcházení Detours.

A ještě k vašemu nesmyslu k „urbans legends“. Prohlížeč nespouští kód stažený z internetu. Prohlížeč pouze vytvoří process, který obsahuje kód stažený z internetu. A předtím se samozřejmě má zeptat uživatele, jestli to tak chce. A v ideálním OS by ten proces samozřejmě měl mít limitovaná práva. Já vím, že lidé jsou hlupáci a odklepnou kde co, ale tímto způsobem to fakt řešit nelze.

MSIE maskuje přístup k registru. Viděl jsem to na vlastní oči. Přímo v debuggeru. Když najdu čas, pošlu vám „Call Stack“, abyste to viděl taky

MSDN Library je dokumentace, a jako každá oficiální dokumentace je to obdoba bible pro křesťany. Autoritativně popisuje chování systému. Chování v MSDN nepopsané se může kdykoliv změnit. Odchylku od popsaného chování je možno považovat za chybu produktu. Takhle totiž funguje dokumentace (seznamte se). Jinak kolik víte o vývoji demonstruje dostatečně dobře fakt, že místo přečtení dokumentace řádíte s debuggerem. Předpokládám, že kdybyste opravoval auta, tak byste používal místo dokumentace raději šrobovák a rentgen, a pak po nocích pak luštil ze snímků, jak má ta převodovka asi fungovat :)
Veřejně přístupné dokumenty jsou obecně psány s vědomím, že budou čteny veřejností. Jestli tomu říkáte marketing, tak je to sice smyšlenka, ale klidně tomu dál věřte.
Win32 sandboxing je řešený v user space? Já neznám implementační detaily, ale mám za to, že při spouštění binárky NT provedou srovnání nějakých metadat (cesta, hash atd) s databází, a na základě výsledku pak případně pustí kód s access tokenem, který má ořezaná práva. Pokud je to jinak, prosím vysvětlete (nemluvíme o filtrování zobrazování messageboxů, ale o přístupu k souborům a Registry). A zkuste to doložit spíš dokumetací, než to zkoušet s debuggerem :)
Browser spuštěný v Protected Mode NEMÁ přístup k disku a Registry (to je věc sandboxingu). Broker process tam samozřejmě být musí, protože jinak byste z takového browseru nemohl třeba uložit soubor. Design je to dobrý, protože snižuje dopady případného exploitu. Spuštění nežádoucího kódu v kontextu browseru (děravý doplněk nebo browser) pak totiž neznamená automaticky možnost provádět veškeré akce, které může provádět uživatel. Broker process by malware mohl využít, ale broker nemusí umožnit browseru každou blbost (třeba zápis do existujícího souboru).
Filtrování messageboxů je pokud jsem si všiml opatření navíc k Win32 sandboxingu.
MSIE Protected Mode samozřejmě řeší následek, a ne příčinu. Příčinou případného exploitu je chyba v kódu, a tu před jejím zjištěním těžko řešit. Takže pak není od věci se zabývat i následky, nemyslíte?
Prohlížeč samozřejmě spouští kód stažený z internetu. Když si stáhnete executable, nabídne vám jeho spuštění. Když si stáhnete Adobe Flash (na stažení se by default zeptá), spustí ho pak klidně automaticky. A i když jsem nepsal doplňky MSIE, tak mám za to, že mohou běžet v procesu browseru (viz třeba in-process ActiveX komponenty).
v ideálním OS by ten proces samozřejmě měl mít limitovaná práva – vítejte ve Windows. MSIE má nižší práva, než ostatní aplikace spuštěné uživatelem. Mimo jiné nesmí na disk, nesmí do Registry atd. Kupodivu se vám to nelíbí, a naopak to krizitujete. Není to trochu nekonzistentní? Možná se vám jen v daném případě nehodilo do krámu, že má MSIE ořezaná práva. Sice to není špatný nápad, ale protože jste neuměl přečíst sekci What's New v dokumentaci, tak jste zjištěním fakt úplně zbytečně trávil dlouhé hodiny s debuggerem. To asi naštve ;)
předtím se samozřejmě má zeptat uživatele – chcete, aby se vás browser při vstupu na každou druhou stránku ptal, jestli opravdu chcete spustit Adobe Flash? LOL, to by bylo zábavné. Ještě lépe by se vás měl ptát pro každý jednotlivý objekt. Chcete spustit objekt Adobe Flashe, první ze třiceti na stránce? Ano. A druhý ze třiceti? Ano. A třetí? … Prohlížení Youtube by pak byla celkem výzva :)

Končím tuto trapnou diskuzi. Připomínáte mi studenta fyziky, který vysvětluje jadernému fyzikovi princip štěpné reakce. Být profesor na vysoké škole, vyhodím vás ze zkoušky s nedostatečnou, po první větě.

Maucta.

PS: Opravdu netušíte o čem píšete,… a vaříte z vody. Možná jste si přečetl MSDN a možná se ho pokoušel pochopit, ale ono to je právě všechno úplně jinak. Můj cíl nebyl debuggerem pošpinit IE nebo Microsoft, ale upozornit pouze na určitý „fenomén“. Předchozí dva roky jsem každý den pracoval jen na doplňcích pro IE, a v debuggeru jsem ho viděl každý druhý den. Nechtějte, abych vám ukazoval a popisoval třeba chyby v jeho HTML parseru, kolikrát mi to žuchlo v nějakém šíleném DOM stromu jen proto, že jsem do DOM zasahoval v době, kdy IE neměl náladu. A co je horší, že to co fungovalo v IE6, nefungovalo v IE7 a už vůbec ne v IE8. Zákazníka… tohle většinou vůbec nezajímá

Překvapí vás chyba v HTML parseru? Mě by naopak překvapilo, kdyby nějaký HTML parser ani jednu chybu neměl.
Mě například překvapilo, že byste jako vývojář doplňků chtěl zobazit dialog při každém použití doplňku. Nepraktické vám to asi nepřijde, a další komentář k tomu nemáte. Nebo byste na jedné straně chtěl běžet doplňky s limitovanými právy, ale když MSIE běží s limitovanými právy, tak to o pár řádků jinde kritizujete. U MSIE Protected Mode kupodivu nevidíte omezení dopadů případného exploitu, i když je to celkem zjevné.
K tomu začátku s dokumentací jen tolik, že zřejmě nechápete princip, na kterém stojí dokumentace systému. Jinak byste nepsal nesmysly o vyhazování studenta po první větě.
Nechcete diskutovat? No dobře, jestli nemáte co říci k věci…

Sorry, opravdu nemám k Vašemu nesmyslnému tlachání nic co dodat.

Přeji hezký den.

Škoda, že píšete o nesmyslném tlachání, ale nedovedete napsat nic konkrétního. Samozřejmě pěkný den i vám.

Srovnejte si nápovědu ve Windows s nápovědou v Linuxu, a bude to silně ve prospěch Windows. Srovnejte lokalizaci, a srovnejte vývojářskou dokumentaci MSDN s čímkoliv na Linuxu. Opět zůstává Linux o míle pozadu.


Ten obchodní model je fajn, ale má jeden zásadní problém. Support totiž neuživí vývoj. Abyste dostal ze supportu stejné peníze jako z prodeje licencí, muselo by 100% uživatelů koupit support pro svůj open source, v ceně vyšší než když dostanou jen licenci (musíte zaplatit i ten vlastní support). Jenže support si koupí jen velmi malé procento uživatelů. Když si ho koupí velmi optimistických 10% uživatelů, tak by museli na supportu zaplatit v průměru více než 10× tolik, na kolik by je vyšla licence. A support jednoho desktopového OS za 20000 Kč? To asi ne :)

Bohužel to zajištění bezpečnosti jazykem (to zní fakt hrozně :) ) si vezme daň na výkonu. Výkon srovnatelný s dnešními systémy to může přinést jen díky tomu, že na druhé straně odbouráte režii hardwarového oddělení procesů.

Zdravím,

Pokud si pamatuji, tak jak na Wikipedii, tak i v odborné literatuře se člověk dočte, že Linux je (nebo bývá nazýván) „hybridní“ kernel. To z toho důvodu, že nejnutnější základ je založen na monolitické struktuře a spousta dalších věcí (nejen ovladače) jsou ve formě modulů, které lze prostě do jádra načíst (i za plného provozu) až je to požadováno (a naopak, když už jej není potřeba, lze jej z jádra vyjmout).

Myslím, že není vůbec nutné trvat na zavedených architekturách jader, ale spíš vybírat a implementovat z nich ty nejužitečnější vlastnosti. A mám dojem, že přesně o to se Linux (respektive, jeho vývojáři) snaží. :)

„Hybridní kernel“ je novotvar-patvar. Jakmile nemá kernel všechny rysy a žádné jiné rysy než vybrané, je z něj hybrid. Taková kategorizace je na nic. To bychom také mohli 75% prodaných vozů říkat „mezitřídní vozy“.

… nebo se tomu bude rikat tak, jak se to dneska prodava, hybridni automobil… Ale ouha, dle tve teorie to je vlastne na nic… Vyhrab hlavu z pisku a oplachni si ksicht…

…a hybridní automobil říkat Trabantu, protože má akumulátor…

Hybridní kernel není novotvar ani patvar, to jen vy nechápete, co znamená. Nejde o jakékoliv jádro nevyhovující vybraným rysům, jde o jádro, které je navržené tak, že se částečně chová jako monolitické a částečně jako mikrokernel. Typický příklad je jádro Windows NT, kde část ovladačů běží v user space (á la mikrokernel) a část v kernel space (á la monolitický kernel).

Pokud pominu to, že servery nemají běžet v kernel space, ale v user space, tak ve Windows „kernel-space servery“ volají metody jiných „kernel-space serverů“ přímo, což je věc, která v mikrojádře být nesmí a kterou se udělal monolitický kernel s tím nepatrným rozdílem, že se linkuje až u uživatele a ne u distributora.

Aha. Takže NT kernel je vlastně velký binární BLOB, bez pevně definovaného interfacu jednotlivých částí, a bez modularity. Tak totiž vypadá klasický monolitický kernel. Padají z vás pěkné nesmysly.

Modulární monolitické jádro je protimluv. Zkuste se podívat na význam slov monolit a modul.
BLOB? Vy zase perlíte. Na jedné straně BLOB se zadrátovanými funkcemi, se kterými nic neuděláte. Na druhé straně komponentový systém s definovaným interfacem, který lze modifikovat a rozšiřovat. Podle vás je obojí binární BLOB, protože běží v jednom adresním prostoru? Aplikaci složená z desítek komponent je ve vašem světě také binární BLOB?

Neřekl bych, že je to protimluv – alespoň vycházeje z definic pojmů „monolitické jádro“ a „modul“. Bylo by to jádro sestavené z modulů, jejichž provázání a vnější presentace odpovídá jádru monolitickému – zkrátka pouze „otevření“ na binární úrovni toho, co je běžné na úrovni zdrojových textů.

Spousta lidí si to zřejmě vůbec neuvědomuje, ale to, čím se mikrojádro liší od monolitického jádra diametrálně a nejzásadněji, je právě vzájemné provázání jednotlivých komponent – u monolitického jádra analogické klasické knihovně, ale u mikrojádra analogické distribuovanému systému!

Všechny kernely se z vnějšku chovají stejně. Konkrétně se starají o správu zdrojů, a poskytují nějaké další služby vyšším vrstvám SW.
U mikrokernelu je otázku, který rys je nejdůležitější. Jako nejužitečnejší vidím rozdělení kernelu na komponenty, a používání definovaného interface pro jejich komunikaci. Samotné oddělení komponent do samostatných procesů a způsob jejich komunikace je samozřejmě také rys typický pro mikrokernel, ale bohužel zabíjí výkon.

No to právě ne – leda až na úrovni nějaké standardní knihovny. Ale je rozdíl, jestli kvůli alokaci paměti provedu něco jako INT 0×80 nebo musím poslat zprávu – která obecně skončí v nějaké frontě, zablokuje proces do doby, než na odpovídající server dojde řada, nebo způsobí přepnutí na daný server – podle implementace. Vazby v takové architektuře jsou odlišné od těch „monolitických“ – není třeba řešit race conditions, protože servery obecně nejsou (protože nemusejí být – jeden z rysů mikrojader) řešeny jako reentrantní, naopak je třeba spravovat rozsáhlé fronty požadavků (jež jsou v monolitických jádrech buď zamaskovány do front synchronisačních mechanismů, nebo jsou řešeny částečnou či úplnou nepreemptivitou jádra). Oba přístupy mají své klady a zápory.

V monolitickém jádře se systémové služby chovají jako knihovna, zatímco v mikrojádře jde spíše o peer-to-peer komunikaci nezávislých objektů pomocí formalizovaného univerzálního protokolu. Podstatným rysem mikrojader není rozdělení na komponenty (to může být i monolitické jádro – moduly), podstatným rysem mikrojader je fakt, že tyto komponenty _musejí_ mít formu procesů, jejichž hlavní (v ideálním případě jediné) rozhraní je tvořeno mechanismem asynchronních zpráv. Právě tato myšlenka stála u zrodu architekury mikrojádra a je její nosnou ideou.

Samozřejmě konkrétní interface a sada poskytovaných služeb se liší. Ale obecně interface kernelu nemusí mít nic společného s jeho implementačními detaily. Klidně můžete s monolitickým kernelem komunikovat přes frontu zpráv, když to tak někdo napíše, a RTOS může používat INT 0×80 nebo SYSENTER.

Monolit znamená jednolitý. Tedy jediný binární BLOB, který obsahuje veškeré funkce jádra, a jediným definovaným interfacem je interface vnější. Kernel Linuxu ten koncept modifikuje možností zavést moduly, i když kernel nemá stabilní interface ani ABI.
Používání IPC je u mikrokernelů technická nutnost, protože jsou servery v seperátních procesech. Ovšem syscall je také formou IPC.
Jednou z nectností klasických mikrokernelů je jejich slabý výkon. Právě proto se koncept mikrokernelu nedostal do mainstreamových OS.

Není to technická nutnost, je to vlastnost, na níž je ta architektura založená. I systém s mikrojádrem může být ve výsledku jediný veliký, jednolitý binární soubor – viz např. MINIX. Součástí kódu jádra jsou i kódy serverů, jež se po jeho spuštění stanou samostatnými procesy. Tyto servery spolu vůbec – čistě technicky – nemusejí komunikovat přes zprávy, protože spolu sdílejí adresový prostor (dokonce nic nebrání tomu, aby sdílely i symboly). Přesto si posílají zprávy – protože to je myšlenka mikrojader – univerzální protokol založený na zprávách. Přičemž vůbec nejde o nějaký hybrid – je to plně v souladu s myšlenkou mikrojader: samostatné procesy, posílající si zprávy; jejich hardwarové oddělení (mechanismy MMU) _není_ požadováno, může to být pouze výhoda, pokud se podaří (ale nemusí – protože to povede ke snížení průchodnosti).

Jinak výkon mikrojader sice je principiálně vždycky nižší, než u monolitických jader, ale průměrně připadá na režii spojenou s tím cca 12–14%, tj. není to zas taková tragédie. Na platformách bez ochrany paměti (dnes nejčastěji v embedded branži) je to podstatně méně – v těchto případech je totiž přepnutí procesu zhruba stejně náročné, jako vyvolání syscallu.

Osobně bych architekturu mikrojader označil za sice zajímavou, ale z praktického hlediska problematickou. Zatím přináší více nevýhod, nežli výhod. Je to taková obdoba objektově orientovaného programování pro oblast operačních systémů, ale vzhledem k povaze této oblasti se zde projevují hlavně ty zápory.

Pokud nemáte servery HW oddělené, tak přicházíte o proklamovanou spolehlivost mikrokernelů. Stačí jeden špatný zápis do paměti v libovolném serveru, a celý systém je dole. Designeři NT ke sdílení adresního prostoru uvedli, že výkonová cena oddělení serverů by byla příliš vysoká, a i mikrokernelový systém je stejně v praxi odstaven pádem FS, IPC či dalších kritických komponent.
U MINIXu vemte v úvahu, že se jedná o výukový systém.
Na nezpůsobilosti mikrokernelů pro mainstreamové nasazení se shodneme my dva, a zjevně i velká většina IT světa.

Hybridní kernel jsou Windows NT, Linux je tvrdě monolitický, protože všechny moduly běží v kernel space.

Chcete opravdu tvrdit, že je Jelinek natolik negramotný, že v jednom odstavci 3× napíše archytektura s tvrdým Y? Tomu nevěřím.

Ne, ta „Y“ nebyla prace pana Jelinka. Nicmene, tezko neco vysvetlovat autorvy takto hodnotneho protiargumentu…

To si nerozumíme. Linux není mikrokernelový systém. Udělat z něj takový systém by byla OBROVSKÁ spousta práce. Přitom i nesrovnatelně jednodušší úkoly (rentrance kernelu, multithreading) trvaly mnoho let. Takže by autoři strávili pár let změnou koncepce, a de facto stavbou nového kernelu s použitím kusů stávajícího kódu. To není realistické. Navíc čisté mikrokernely mají závažné problémy s výkonem. Proto se do mainstreamových OS nikdy nedostaly. Nejblíž jsou jim asi Windows, kde jsou z architektury mikrokernelu použity jen vybrané rysy.

Zcela bez urážky si upřímně myslím, že jako se vám matlají pravidla pravopisu, porušujete je a nedetekujete jejich porušování, tak se vám podobně matlají i jiné věci. Při uvažování si hlavě vyrábíme mentální modely, které je třeba stavět podle pravidel. Je třeba detekovat chyby v tom modelu, a neshody modelu s realitou. Podle mého názoru v tomhle selháváte v důsledku stejné poruchy, jakou demonstruje váš pravopis. Pokud jste přesto šťastným a úspěšným člověkem, považoval bych to samo o sobě za úspěch. Znovu opakuji, že tohle je můj názor, a nesnažím se vás nijak urážet.

Ale já nenapsal, že jste psal, že Linux je mikrokernelový systém. Na tom že není mikrokernelový se shodneme. Zřejmě vás vůbec nenapadlo, že by konstatování „Linux není mikrokernelový systém“ mohlo být něco jiného, než nesouhlas s vaším názorem. To bohužel předvádíte pravidelně. Prostě to nevidíte, tak jako nevidíte Y ve slově monolYt.

Tradiční mikrokernelový design není použitý v ŽÁDNÉM mainstreamovém OS. Důvodem jsou problémy s výkonem. To se tu ale probíralo mnohokrát.

FUSE je wrapper na straně kernelu, který do něj byl přidán poměrně nedávno, a být by tam vůbec nemusel. S mikrokernelem má FUSE společnou jednu jedinou věc, a to že kód FS pak běží v user space (a s mizerným výkonem). Nakonec ale můžeme tvrdit, že Windows 3.0 také měly mikrokernelové rysy. FS totiž běžel v user space :). Že je nesmysl kvůli takové věci hovořit o mikrokernelových rysech OS? Jistě, to u Linuxu a FUSE také.

To jste zase něco vyplodil Človíčku :-D

Vy jste to nenapsal? Aha, Takže výrok " <citte>To si nerozumíme. Linux není mikrokernelový systém. Udělat z něj takový systém by byla OBROVSKÁ spousta práce.", v kontextu mého předešlého výroku a významu dalšího textu z citovaného odstavce ve vašem příspěvku, znamená asi, že jste přiletěl z Marsu… No to se stává pravidelně zase u vás. Nehledě na to, že o inteligentnosti vašich narážek jsem už mluvil, a taky jsem vám (už mockrát) říkal, že se nemusíte tolik snažit, aby jste sám svým jednáním potvrzoval, že mám pravdu. :-p

Hahaha. Srovnávat FUSE s Dosovým filesystémem je asi jako porovnávat dvoukolový kočár tažený koňmi s nejnovějším modelem Lamborgini. Hm, stejně těžko muže někdo soudný tvrdit, že Win 3.x mělo mikrokernelový rysy, když win 3.x byly pouze grafickou nadstavbou nad DOSEM. A to ani nemluvím o tom, že MS DOS moc nerozlišoval mezi privilegovaným a neprivilegovaným režimem. :-D

V příspěvku, na který jsem reagoval, jste psal: „Lael tady porad dokola tvrdi, ze vzor microkernelu je pro Linux nepouzitelny“. A to jsme si opravdu nerozumněli, protože já tvrdil něco trochu jiného.

To je samozřejmě také zajímavost. Napíšu svůj názor na váš problém, a dám jasně najevo, že se nejedná o snahu vás urazit. Samozřejmě vy si v reakci neumíte urážku odpustit. Typické, nepřekvapí.

U Win 3.0 je FS běžící v user space je mikrokernelový rys úplně stejně jako FUSE u Linuxu. Tím srovnáním se vám snažím vysvětlit, že ani jedno nedává systému relevantní znaky mikrokernelové architektury.

Navrhuji to uzavřít s tím, že my dva spolu prostě nemůžeme vést rozumnou komunikaci.

Ano, nabýdku příjmám.

Ještě než to však skutečně uzvřeme, měl by jste si uvědomit kdo koho začal napadat, takže si ty ublíženecký řeči laskavě odpusďte…

Zkusme se smířit s tím, že i to napadání interpretujeme každý jinak.

Já bych ani neřek. Pokud někoho napadáte, urážite, či ponižujete vy, tak je vše v naprostém pořádku, ne. Ale běda, jakmile někdo udělá totéž vám…

> Tradiční mikrokernelový design není použitý v ŽÁDNÉM mainstreamovém OS. Důvodem jsou problémy s výkonem. To se tu ale probíralo mnohokrát.

No jo, QNX se vůbec nepoužívá a ta firma měla už dávno zkrachovat, jen mají hloupého účetního a ten na to ještě nepřišel :) Navíc všechny kritické real-time aplikace, které na něm běží (třeba řídící software jaderných elektráren) mají problémy s výkonem :)

Jak už někde napsal, s tou propiskou je to urban legend.

V principu souhlasím, že novější technologie není nutně lepší pro daný účel. Na druhé straně typicky bývá lepší. Jinak bychom dodnes používali parní stroje, zubaři by bolest zubů léčili jejich vyrváním kovářskými kleštěmi, jako anestezii před amputací byste dostal půl litru vodky, a firmy i jednotlivci by dodnes jely na unixech :)

Nemá smysl přepisovat Linux jako mikrokernel. Byla by to obrovská spousta práce, a bez většího efektu. Navíc stejně za pár let přijdou systémy postavené úplně jinak, proti kterým budou NT působit technologicky stejně zaostale, jako unixy proti NT. Ale z Linuxu je dobré si vzít lekci pro příště. Na začátku je třeba udělat kvalitní návrh. Ne jen tak plácat dohromady kód podle dokumentace starších systémů, a doufat, že z toho nějak samospádem vyleze dobrý design (což se zjevně nestalo).

Dobrá, přiznávám se. Samozřejmě máte pravdu, Space pen v této podobě je pouhá legenda, ale v tu chvíli mě nenapadlo lepší srovnání. Chtěl bych se tedy omluvit všem, které jsem zbytečně mistifikoval. Ale musíte uznat, že myšlenková podstata není zcela nesmyslná.

Jak jsem psal, vaše myšlenka je v podstatě správná. Ovšem nové technologie zpravidla plní potřeby lépe, než ty staré. Jsou totiž vyvíjeny právě pro odstranění nevýhod těch starých technologií. Proto se dnes například amputace provádí v anestezii, a ne za živa po požití půl litru vodky. Proto s sebou dnes můžete nosit telefon a browser, a nemusíte používat telegraf a chodit zjišťovat informace do univerzitních knihoven.

Windows kernel a kvalitni navrh? Mam pocit, ze to se tu uz jednou rozebyralo, a moc kvalitne to zrovna nepusobilo… ;)

No, ale co, kazdemu jeho nebe… no ne?

Architektura NT je zcela nepochybně lepší, než architektura Linuxu nebo starých unixů. Když se to tu rozebíralo, tak se to zvrhlo v nesmyslné diskuze o adresářové struktuře, umístění logů a podobné ptákoviny, které s kernelem nemají nic společného. Samozřejmě každému co jeho jest. Pokud někomu vyhovuje v extrému třeba děrná páska nebo TTY, je to jeho věc.

Clovicku LOL :-D

Nj, ono, by se to nebylo byvalo zvrtlo, kdyby nekteri WinPR flameri radeji zamerne neodvraceli tema ve chvili kdy zacelo vyplouvat na svetlo sveta jak prasacky je tam reseno napriklad vetveni podle archytektury a typu procesoru… podobne jak jste to predvedl v reakci na citat z knihy pana Jelinka…

No radeji zastaraly Linux (nebo Unix)a dernou pasku, s jistotou, ze bude fungovat. A kdyz ne, tak budu mit alespon sanci vysledovat co se zhruba stalo. Rozhodne nebudu brat moderni vymakany, system ktery ve chvili kdy dojde k nejake chybe tak jedine ceho je schopen, tak modre podbarvit orazovku a napsat odusevnelou hlasku, ze system byl zastaven, aby nedoslo k poskozeni hardware…

MINIX? To je ten kernel, co už asi 10 let do roka nahradí kernel Linuxu? Něco jako rok Minixu? :) Kdo vám proboha namluvil, že když user space nemá přímý přístup k jádru, tak je kernel monolitický? K posledním odstavci: Unixy proti NT jako Trabant proti Praze Aero, to moc nesedí. Asi jste se střelil do nohy.

Á, moje chyba. Z jiného soudku. Windows 7 mají údajně už dnes více uživatelů, než Linux. Zřejmě se opakuje situace z beta testů Windows 2000, kdy měla nevydaná verze Windows také více uživatelů, než všechna distra Linuxu dohromady. Zajímavé.

Ta procenta se berou typicky ze statistik reprezentativního výběru webových serverů. A MS si samozřejmě udělá čáku za každý prodaný kus, protože z něj má zisk. Mozilla Foundation nebo Sun si zase udělají čárku za každé stažení Firefoxu či OOo, i když si lidé stahují SW kvůli upgradu na poslední verzi, nebo produkt vůbec nepoužívají. Já například stáhl asi postupně 5–10 verzí OOo, a vyjma testování jsem nepoužíval ani jednu.

O počtech uživatelů nevydaných MS produktů si myslete to, že takových uživatelů je na webu za pouhých sedm měsíců víc, než jich stačil Linux nasbírat za 17 let.

s/jakoikyvy/ jako vy

Webové statistiky jsou to nejpřesnější, co máme.
Ano, Mozilla prezentuje počty stažení FF (a Sun počty stažení OOo). Ty čísla jsou ale naprosto o ničem. FF stahuje řada lidí jako upgrade z předchozí verze, po reinstalaci OS apod. Přes tu miliardu stažení má FF jen asi čtvrtinový podíl na webu. OOo také každý stahuje (já stáhl postupně asi 5 verzí na testování), ale prakticky nikdo ho nakonec nepoužívá.

Klidně do sbírky svých bludů zařaďte několik dalších, mě je to upřímně jedno :)

Webové statistiky jsou Možná nejpřesnější co máme, ale konkrétní použitelné hodnoty v nich nelze hledat. Pouze v jakem pořadí (dle četnosti) se identifikují stroje, které komunikují s serverem, zabírajícím data pro tyto statistiky. Z toho ovšem (vzhledem k možnostem konfiguraci mnoha systému unixového typu), proxy v cestě apod, lze odvozovat opravdu jen málo – ale to už se tu taky probíralo nejmíň tisíckrát.

Zase špatně čtete. Ja jsem psal jasně a pouze, že Mozilla své statistiky prezentuje jako počet stažení. Nikde už však nebyla ani zmínka o tom jak moc je, či není používána. Tenhle problém má MS.

„Klidně do sbírky svých bludů zařaďte několik dalších, mě je to upřímně jedno“. Nemějte obavy, dávám si veliký pozor, abych od vás nic závadného nepochytil :-D – když už jsme u těch vzájemných zdvořilosti. ;)

Ja si zase zakoupil asi 5 licenci na windows, z nichz jsem nepouzil ani jednu.

Ovšem za těmi agresivně nastavenými podnikovými proxy jsou Windows, takže to nebude ke škodě Linuxu. Hypotéza utajeného Linuxu je blud. Vychází z toh, že dotyčný má Linux, jeho kamarád Franta má Linux, Jarda má taky Linux, ve škole v labu je Linux, takže je Linux úplně všude. Když není vidět ve statistikách, je nutné hledat důvod, proč tam není. Skutečnost je ale jiná. Linux se prostě používá minimálně. V počtu uživatelů ho předhodí i nevydaná verze Windows.

Za těmi agresivně nastavenými proxy byly unixové (Linux či BSD) terminály. A to podvrhování User-Agent řetězců je známá věc, která dělá statistikům problémy.

> V počtu uživatelů ho předhodí i nevydaná verze Windows.

Na to jste přišel kde? Já našel tato čísla:

While Linux is flirting with the 1% usage share mark, Windows 7 has grown to no less than 0.42% of the operating system market. [Softpedia, 2. června 2009]

4 Linux 2.02%

5 Windows 7 1.24%

[W3 Counter, statistiky za červenec 2009]

Linux 1.05%

Windows 7 0.89%

[marketshare.hit­slink.com, statistiky za červenec 2009]

Samozřejmě i tohle je dobrý součet špatných čísel (stačí vidět ty rozdíly v hodnotách). Stejně statistická odchylka pro takovéto výzkumy je v řádu jednotek procent (běžně až kolem 5 %), takže vše může být úplně jinak ;)

Píšou to na (l)živě, a vycházejí z údajů rankings.cz a netmonitor.cz. Na http://market­share.hitslin­k.com/ se pravda Linux ještě drží o 0,16% nad Windows 7. ČR je holt progresivní.

http://www.zi­ve.cz/text.as­px?textartimg=1&ar­ticle=148228

„se odborně nazývá hybridní“ – moc čtete Wikipedii. MS mluví o modifikovaném mikrokernelu. A jak jsem psal, nemá smysl vytvářet novou umělou kategorii, a házet do ní naprosto rozdílné věci (modifikovaný mikrokernel a modifikovaný monolitický kernel).

Naštěstí existuje autorita, která ví zcela přesně, jak správně pojmenovat architekturu NT kernelu. Tou autoritou samozřejmě není nějaký výrobce nebo designer, ale Sten, diskutér z rootu :)

Už jsem to vysvětloval, ale zkusím znovu. Windows NT mají mikrokernelovou architekturu s jednou významnou odchylkou. Tou je fakt, že servery běží v kernel mode (což je nutné kvůli výkonu). Proto se takové architektuře říká modifikovaný mikrokernel.

Ne, tou autoritou jsou lidé, kteří se teorií operačních systémů zabývají (např. Andrew Tannenbaum) a nejsem to ani já ani vy a ani PR oddělení MS.

Windows NT mají mikrokernelovou architekturu s jednou významnou odchylkou – jsou implementovány jako modulární monolitické jádro, takže nejsou mikrojádro:

The Windows NT kernel is known as a hybrid kernel. However some kernel developers disagree, arguing that all essential parts of the system are executed in kernel mode, thus making it a monolithic kernel that is structured similarly to a microkernel.

The reason NT is not a micro-kernel system is that nearly all of the subsystems providing system services, including the entire Executive, run in kernel mode (in the same address space as the microkernel itself), rather than in user-mode server processes, as would be the case with a microkernel design.

Další důležitou vlastností, kterou má NT společnou s monolitickými jádry, je to, že všechy objekty v executive jsou ve společném namespace (a společném prostoru handlů) a lze tak k nim přímo přistupovat z jiných ovladačů (případně u špatně pojmenovaných může snadno dojít ke kolizi jmen, což dobře známe z některých starých verzí Linuxu), čímž se porušuje striktní oddělení serverů v mikrojádrech (což ale porušuje už to, že běží v kernel mode ve společném adresním prostoru).

MS PR oddělení tomu říká modifikovaný mikrokernel, protože to lépe zní, ale ve skutečnosti jde o modulární monolitické jádro, velmi podobné tomu, co má Linux; zásadní rozdíl je akorát stabilní API a možnost některé moduly (omezené tím, co chtějí provádět) spouštět v user space.

Windows NT's kernel mode code further distinguishes between the „kernel“, whose primary purpose is to implement processor and architecture dependent functions, and the „executive“. This was designed as a modified microkernel, as the Windows NT kernel does not meet all of the criteria of a pure microkernel.
http://en.wiki­pedia.org/wiki/Win­dows_NT

Operating systems that follow both of these principles are often called pure microkernel systems. Operating systems that follow the first principle only strict modularity and strong encapsulation but not the second, are sometimes called modified microkernel or macrokernel operating systems.
http://techne­t.microsoft.com/en-us/library/cc750820­.aspx

Jako hřebíček do rakve pak hybridní kernely na Wiki: A hybrid kernel is a kernel architecture based on combining aspects of microkernel and monolithic kernel architectures used in computer operating systems. The category is controversial due to the similarity to monolithic kernel; the term has been dismissed by some as simple marketing. The traditional kernel categories are monolithic kernels and microkernels (with nanokernels and exokernels seen as more extreme versions of microkernels)…
Dále se tam mluví o hybridní kernelu jako quasi-category ;)
…The reason NT is not a micro-kernel system is that nearly all of the subsystems providing system services, including the entire Executive, run in kernel mode (in the same address space as the microkernel itself), rather than in user-mode server processes, as would be the case with a microkernel design. – což je přesně to, o čem jsem psal.
http://en.wiki­pedia.org/wiki/Hy­brid_kernel

Linux například identifikuje drivery pomocí major a minor number, což samo o sobě působí dlouhou řadu problémů. O name space se má smysl bavit teprve pokud by byl tenhle pravěk předělán tak, aby konečně překonal sedmdesátá léta minulého století.

> http://en.wiki­pedia.org/wiki/Win­dows_NT

Kde vpravo nahoře je kernel type: hybrid. Navíc je tam informace „Routines from each [kernel and executive] are directly accessible, as for example from kernel-mode device drivers“, což je věc, který v mikrojádře být nesmí, tam smí být pouze nepřímo přístupné přes IPC.

> http://techne­t.microsoft.com/en-us/library/cc750820­.aspx

Termín macrokernel se běžně používá jako synonimum pro modulární monolitický kernel, např. Linux nebo MacOS X. Jen tak mimochodem, ten první princip (modularita a zapouzření) splňuje i MacOS X (a vlastně i Linux 2.6) a nechcete doufám tvrdit, že MacOS X je mikrokernel?

> Dále se tam mluví o hybridní kernelu jako quasi-category ;)

s následnou informací, že je to ve skutečnosti monolitické jádro

> The reason NT is not a micro-kernel system is that nearly all of the subsystems providing system services, including the entire Executive, run in kernel mode (in the same address space as the microkernel itself), rather than in user-mode server processes, as would be the case with a microkernel design. – což je přesně to, o čem jsem psal.

Což je ten důvod, proč NT nejsou mikrojádro, tedy jsou buď hybridní nebo spíše monolitické jádro.

Důvod proč spolu servery u mikrokernelu komunikují pomocí IPC je čistě technický. Vzhledem k oddělení procesů totiž nemají jinou možnost. Pokud jsou servery v kernelu, tak tu možnost mají. Vidíte tedy nějaký důvod použití IPC? Leda byste chtěl komunikaci z nějakého důvodu zpomalit.
Linux je modulární leda na úrovni zdrojáku :)

> Důvod proč spolu servery u mikrokernelu komunikují pomocí IPC je čistě technický. Vzhledem k oddělení procesů totiž nemají jinou možnost. Pokud jsou servery v kernelu, tak tu možnost mají. Vidíte tedy nějaký důvod použití IPC?

Pokud jsou servery v kernelu a slinkují se dohromady (nepoužijí IPC, které je nezbytné alespoň pro to zapouzdření), tak už to není mikrojádro, ale monolitické jádro – úplně stejně totiž linkuje Linux moduly s jádrem.

> Linux je modulární leda na úrovni zdrojáku

Hmm, aha, a proto nemá fungující moduly od třetích stran, jako jsou ovladače AMD a nVidie, že?

Už jste někdy slyšel o dynamickém linkování? A fakt myslíte, že například v user space se z nějakého důvodu in-process komponenty nepočítají jako komponenty?
Možnost zavedení modulů do monolitického kernelu je rozšířením jeho původního konceptu. Můžete tomu říkat modifikovaný monolitický kernel ;)

Shrnu to tedy polopaticky:

1. Mikrojádro a priori NENÍ bezpečnější, než monolitické jádro! Jestliže v systému s mikrojádrem spadne např. proces-plánovač, jste ve stejném loji, jako byste byl v systému s monolitickým jádrem.

2. Mikrojádro a priori NENÍ přehlednější, než monolitické jádro! Přehlednost kódu jádra systému je přeci dána přehledností jeho zdrojových textů – stejně, jako můžete napsat přehledně a modulárně monolitické jádro, můžete napsat nepřehledně mikrojádro. Přirovnal bych to k Pascalu – přestože je to teoreticky poměrně čistě navržený jazyk, napsat v něm při praktickém programování některé konstrukce aspoň trochu elegantně občas hraničí s nemožností. Výsledkem je, že teoretická čistota a přísnost architektury si vynutí mnohem horší hacky při praktickém využití, než kdybych měl k disposici trochu více volnosti a benevolence na té architektuře.

3. Mikrojádro a priori JE pomalejší! Komunikace mechanismem zpráv si zkrátka vždycky vynutí větší množství přepnutí kontextů, než monolitická architektura, a přepnutí kontextu JE obecně vždycky náročnější činnost, než pouhý přechod do privilegovaného režimu. Navíc průchodnost dále snižuje fakt, že požadavky nejsou vyřizovány podle času, přiděleného procesu, ale podle pořadí, v jakém je vyřizují servery – zatímco v monolitickém jádru proces např. žádající paměť ji dostane v rámci jednoho systémového volání (buď okamžitě, nebo v závislosti na zbývajícím času – podle toho, je-li i samotné jádro preemptivní), u mikrojádra, i když má dostatek času, bude jeho požadavek zařazen do fronty a proces zablokován, než bude žádost vyřízena. Tento fakt ztěží eliminuje nějaký budoucí procesor – podobně jako třeba to, že od jistého počtu přerovnání je algoritmus třídění zvaný quicksort rychlejší, než algoritmus probublávání – to platí s papírkama na stole, stejně jako na jakémkoli turingovsky orientovaném stroji.

4. Mikrojádro činí vývoj složitější! Mikrojádro vám vyrobí z počítače na vašem stole distribuovaný systém, což není to, co by si normální člověk přál (pokud to zrovna není masochista). Tento fakt opět nezmění žádný procesor budoucnosti typu Iludium pjů 36 s výbušným modulátorem, který se bude vyrábět za 20 let.

5. Mikrojádro vzniklo snad někdy začátkem 80. let a uplynulých téměř 30 let „budoucnost“ zatím neustále ukazuje, že to opravdu není pravé ořechové.

GNU/Hurd je právě odstrašujícím příkladem, v co se takové mikrojádro může zvrhnout. Myslím, že brutální vražda spáchaná vývojářem Hurdu na tazateli banálního „kdy už to bude hotové?“ není daleko. ;-)

" 3. Mikrojádro a priori JE pomalejší! Komunikace mechanismem zpráv si zkrátka vždycky vynutí větší množství přepnutí kontextů,"

Je mýtus a nesmysl. Dvě aplikace se umí dohodnout bez toho, aniž by proběhl jediný context-switch navíc. Stačí jí k tomu sdílená paměť fungující jako fronta a nějaký zámek – úplně postačí spin-lock a případně nějaký event object pro případ, že by server neměl co dělat (aby se uměl zastavit a čekat). Kernel s tím nemusí mít nic společného. Na dvoujádrovém procesoru při poslání a vyzvednutí požadavku neproběhne ani jeden context-switch.

Synchronní požadavky vyžadují zastavení jedno procesu (zpravidla na event objektu), což představuje jeden context-switch navíc (vlastně dva, jeden do jádra a jeden z jádra). Po vyzvednutí požadavku a zpracování pak následuje uvolnění čekajícího procesu, což může být otázkou opět dvou context-switchů, opět do jádra a z jádra. V porovnání s běžným voláním to může být o jeden context-switch navíc,… ale nemusí.

Synchronní volání mohou být realizována třeba branou přímo do serveru, bez účasti jádra. Volající proces zavolá server, dojde k přepnutí přímo do serveru a ve stejném vláknu, avšak v jiném kontextu proběhne volání serveru. Server se chová jako by byl v kernelu, ale beží v user-space, akorát má jiná práva.

Obecně si myslím, že síla mikrokernelu je ve větších možnostech přidělování práv jednotlivých ovladačů a jejich základní izolace. Pak se nestane, že ovladač tiskárny poškodí ovladač disku chybným zápisem do paměti. Lépe se i řeší zabezpečení počítače, protože ovladače, byť mají větší práva, nemají šanci ovlivňovat činnost jiných ovladačů, třeba ovladač pro šifrovaný filesystem se nemusí bát, že někdo jiný získá přístup k jeho dešifrovaným datům. Víme, jak špatně se řeší v dnešní době „doinstalování“ neověřených ovladačů. Všelijaké podpisování a autorizace jsou jen polovičním řešením. Úplná izolace je pak úplné řešení, kdy se opravdu počítač stává nástrojem a nikoliv pánem. Kdy i BFU zvládne nainstalovat ovladač k foťáku, aniž by k tomu potřeboval práva superuživatele… protože ovladač k foťáku získá právo pouze na zásuvku, ke které je připojení foťák a uživatelský kontext uživatele, který jej instaloval.

Není to mýtus, ani nesmysl, ale holý fakt!

1. Dvě aplikace (Čto éto takóje? Máte na mysli procesy?) spolu můžou komunikovat jak chtějí, ale zde se bavíme o vyřizování volání API jádrem. U monolitické koncepce k žádnému přepnutí kontextu nedojde, pouze k přepnutí do privilegovaného režimu a obsloužení systémového volání je provedeno v kontextu volajícího procesu. U mikrojádra má proces k dispozici jen jedno volání – něco jako Send/Rec apod. K systémovému volání tedy musí připravit zprávu, zavolat send/rec, ten přepne do privilegovaného režimu a pošle systémovému procesu zprávu, obvykle zablokuje volající proces a nechá naplánovat nový proces – v optimálním případě ten, kterému byla poslána zpráva. Dojde k přepnutí kontextu na systémový proces, vyřízení volání, připravení odpovědi a její odeslání volajícímu – tj. vyvolání plánovače, přehození kontextů, uvolnění volajícího a přepnutí zpět do neprivilegované úrovně volajícího procesu, který si zprávu vyzvedne.

2. Různé brány apod., vynucující programovat servery reentrantně, přísně vzato nemají s myšlenkou mikrojádra nic společného, ale naopak, jdou proti ní! Základní myšlenkou mikrojader je omezení vzájemné imperativní komunikace pouze na zprávy a izolace funkčních modulů pouze do procesů.

Navíc mi smysl vašeho příkladu komunikace dvou procesů poněkud uniká – uvádíte klasickou ukázku synchronizace dvou procesů nad sdílenou strukturou a ta je nezávislá na tom, jde-li o mikrojádro, nebo monolitické jádro. Neboli to nemá k rozebíranému tématu žádnou argumentační relevanci. Kdybych přesto chtěl váš příklad použít k dokumentaci rozdílu činnosti monolitického a mikrojádra, vypadalo by to takto:

1) Monolitické jádro – proces A zavolá jádro k získání sdílené paměti (provede se v jeho kontextu – A), k získání semaforu (opět v kontextu A), dále např. pomocí zprávy pošle klíč a semafor procesu B (v jeho průběhu pravděpodobně dojde k přepnutí na proces B, který si zprávu přečte a při následném vstupu do kritické sekce – jenž se provede v kontextu B – zůstane zablokován v privilegovaném běhu kontextu B; postupně dojde k přepnutí na kontext A, který pokračuje v činnosti). Proces A připraví data, uloží je do sdílené paměti a opustí kritickou sekci (stane se v kontextu A, dojde k uvolnění a naplánování B, přehození kontextu na B). B je uvolněn a pokračuje v kritiké sekci čtením dat.

2) Mikrojádro – proces A pošle zprávu systémovému procesu, že chce sdílenou paměť (přehodí se kontext a naplánuje se správce paměti MEM, který zařadí požadavek do fronty a až na něj dojde řada, zpracuje ho a připraví odpověď pro A). Dojde k přehození kontextu na A, A připraví zprávu pro nějaký proces IPC, že chce semafor, dojde k přehození kontextu na IPC, zařazení do fronty, až dojde řada, připraví odpověď, přepnutí na A. A pošle klíč + semafor procesu B – v tomto bodě to proběhne stejně, jako u monolitického jádra. B chce vstoupit do kritické sekce, proto připraví odpovídající zprávu pro proces IPC, přepne se kontext na IPC, zařadí se do fronty, při zpracování se přijde na to, že v kritické sekci už je A, takže požadavek zůstává nevyřízen a proces B je nadále blokován. Až dojde řada na A, zapíše data, připraví zprávu pro IPC, že opouští kritickou sekci, pošle mu ji – přepnutí kontextu na IPC, zařazení do fronty, vyřízení, při němž je požadavek spárován s žádostí B, která je tímto vyřízena a po přepnutí kontextu z IPC na B je B odblokován a pokračuje v kritické sekci. Rozdíl v počtu přehazování kontextů oproti monolitickému jádru jsem ani nepočítal.

Aha, tak já měl na mysli jiný mikrokernel. Ten co jen přiděluje práva aplikacím / procesům a jednotlivé procesy pak spravují služby celého OS. Takže všechny ovladače jsou v user-space, grafika je v user-space, disk je v user-space, síť je v user-space a v kernelu je jen plánovač a správce paměti (a to ještě jen virtuální paměti, přidělování stránek, heap je v user-space) a správce přímého vstupu k HW (přidělování portů a mapované paměti)

Každá aplikace pak má přidělenu třeba sadu bran, oblasti mapované paměti HW, nebo api pro přímý přístup k HW.

Takovou architekturu jsem ještě neviděl.

A jak tedy funguje „váš“ mikrokernel? :-) Jak probíhá přidělení paměti procesu, když o paměť se stará „proces-správce paměti“? Jak probíhá načtení bloku, když o disk se stará „proces-ovladač disku“? Tedy – jak jinak to probíhá, když ne přes zprávy a přepínání kontextů? Proces, jehož kód (část jehož kódu) může také probíhat v kontextu jiného procesu pomocí volání nějaké brány, nebo také nemusí, podle potřeby – to jde zcela mimo základní myšlenku mikrojádra. Nejen mikrojádra, to jde zcela mimo myšlenku koncepce procesu jakožto autonomní, základní výkonné jednotky jakéhokoliv multitaskového operačního systému. Když se podíváte třeba na zdrojáky Minixu, což je učebnicový mikrokernel, zjistíte, že to funguje přesně tak, jak jsem napsal výše.

P.S.: poznámka o ovladačích je na místě – jak bylo napsáno výše – když potřebuje ovladač přístup ke sběrnici, no tak ho bude potřebovat, ať je v monolitickém jádru, nebo v mikrojádru. Mikrojádro jisté zabezpečení přináší – např. pokud chyba v ovladači způsobuje přímý zápis do paměti, kam nemá, třeba chybným ukazatelem. Ale situacím, kdy ovladač předá zařízení chybnou adresu pro DMA přenos apod. samotné mikrojádro nijak zabránit nemůže.

Odpověď je o příspěvek níze. DMA lze samozřejmě naprogramovat blbě, ale pomocí nějakeho DMA API které si předané adresy předtím zkontroluje už to bezpečnostní problém není. DMA API je už tak lowlevel funkce, že její umístění do kernelu je víc než logický krok…

více, viz má představa hybridního jádra níže.

A jak tedy funguje „váš“ mikrokernel? :-) Jak probíhá přidělení paměti procesu, když o paměť se stará „proces-správce paměti“? 

A kdo rika, ze musi byt nejaky proces-spravce pameti? Napr. v HelenOSu si proces vytvori pomoci syscallu oblast virtualni pameti na kterou kdyz sahne, tak mu kernel naalokuje a namapuje fyzickou pamet. To co popisujete vy je specificke jen pro nektera mikrojadra.

Jo a kdo neskace taky neni mikrokernel, co? :-)

V tom vasem seznamu me zase prekvapuje, ze v nem figuruje sched, getnext, ready a unready. Sice mam za to, ze to jsou spis normalni Minixove funkce, ktere ty systemove procesy mohou diky sdilenemu adresovemu prostoru volat primo, ale prave neco takoveho je pro mikrokernel zbytecne.

Kdyz se jeste zastavim u toho Minixu, tak ten ma jeste syscally na PIO, coz je uplne zbytecne, protoze PIO se da delat z userspacu. Znamena to snad, ze Minix take neni mikrojadro?

Mel jsem na mysli SYS_DEVIO a spol (vsechno SYS_* resp. obsah adresare system). Akorat si ted nejsem jisty, zda to nejsou typy zprav, kterym rozumi ty dve systemove sluzby. Ale i kdyby, tak jsou to vlastne zakuklene syscally, protoze jsou implementovany v kernelu.

Jsou to typy zpráv, které zpracovává systémový server, takže z hlediska architektury mikrokernelu je to naprosto OK.

Nerikam, ze to neni OK, ale je to proste sluzba, kterou poskytuje jadro. Je to uplne to same, jako kdyby na to byl dedikovany syscall, ale pomalejsi. Podivejme se na to, jak se takovy pozadavek pravdepodobne zpracovava (upozornuji, ze ted pouze odhaduji, jak to muze fungovat). Uzivetelsky proces udela syscall, rikejme mu SEND a jako parametry mu preda SYS_DEVIO, cislo portu, velikost, indikaci cteni/zapis a pripadne hodnotu pro zapis. Po prepnuti do privilegovaneho rezimu jadro bezi v kontextu procesu, ktery syscall zavolal. Obsluha syscallu SEND vezme parametry a soupne je do fronty kernelovemu threadu, kteremu se honosne rika systemovy server. Ten si pozadavek z fronty vyzvedne a zpracuje ho. Potom odpovi a puvodni proces, ktery ceka na odpoved, se muze vratit do userspacu.

Takze rozdil mezi mikrokernelem, ktery umi vice syscallu, a timto modelem je v tom, ze v prvnim pripade se ten syscall zpracuje v tom threadu/procesu, ktery syscall zavolal, zatimco v pripade druhem se ten syscall vlastne postoupi jinemu threadu/procesu, ktery ale ovsem taktez bezi v jadre. Samotny kod obou mikrokernelu bude potom srovnatelne velky (pokud podporuji srovnatelne sluzby) a na izolaci chyb to nebude mit zadny vliv. Pouze na rychlost. Akademicky zamereni fanousci mikrojader pak mohou mit prijemny pocit z toho, ze ten syscall realizovali poslanim zpravy.

To slovo vice je samozrejme relativni. Pouzil jsem to ve smyslu vice nez tolik, kolik staci na IPC. Samozrejme, ze rozdil mezi mikrokernelem a monolitickym jadrem se projevi v absolutnim poctu podporovanych syscallu. Minix a HelenOS kolem 30(±), Linux a Solaris radove vic (>100?).

O principu minimality jsem v teto diskusi jiz psal. To ze si otec mikrokernelu L4 neco zadefinuje mi muze byt docela jedno, protoze L4 je jen jednim z mikrojader a odmitam predstavu, ze jedine L4 je ten spravny mikrokernel. Viz moje narazka na absurditu tohoto principu v pripade synchronni/asyn­chronni IPC.

Jenze ja na rozdil od Tebe nerikam, ze neco mikrokernel neni. Podle mne jsi si precetl nejakou chytrou knihu o tom, co je to mikrokernel a ted mas utkvelou (ale chybnou) predstavu, kterou vnucujes ostatnim a ohanis se pritom L & T. Znamena to snad, ze kdyz nejsem T., tak nemuzu neco naprogramovat a rict o tom, ze to je mikrokernel? Obzvlast kdyz to mikrokernel je? Prece nebudu programovat monolit a rikat o tom, ze je to mikrokernel (nebo naopak), ne?

Jasne jsme si tady ukazali, ze Minix ma v kernelu spoustu veci, ktere tam podle principu minimality nepatri. Znovu se ptam: znamena to snad podle Tebe, ze Minix take neni mikrokernel? Pokud ne, tak se ptam: a proc by tedy podle stejneho meritka melo znamenat, ze HelenOS neni mikrokernel? Mimochodem, princip minimality nerika nic o poctu syscallu, ale o sluzbach poskytovanych jadrem.

Kdyz se kouknes treba na Wikipedii, tak tam o mikrokernelech najdes clanek, ktery ma prijatelnou definici mikrokernelu – a to se jedna o clanek tezce opracovavany panem Heiserem z projektu OKL4. Take tam zminuji princip minimality, ale spravne upozornuji na to, ze toho vetsina kernelu z ruznych duvodu nedosahuje. Takze odkud se vzala ta Tvoje uzoucka definice, do ktere se zadny mikrokernel nevejde? Urcite ji nemas od T.

Těch „chytrých knih“ a dalších materiálů, s nimiž jsem pracoval, bylo přeci jen za ta léta poněkud více, takže jedna knížka za to fakt nemůže. Co naprogramuješ si můžeš nazývat jak chceš, ale nesmíš se pak divit, dojde-li k nedorozumění.

Tady narážíš na další možnou věc nedorozumění – co si představuješ pod pojmem „jádro“. To, co běží v supervisor módu? To, co je procesem voláno přes trap procesoru? To, co se provede v caller-kontextu? I z logiky toho, že se bavíme o _mikro_jádru, snad plyne, co měl autor toho termínu na mysli. MINIX to z tohoto pohledu nenarušuje. Pokud bychom použili nějakou obecnější definici, která třeba říká, že je to vrstva softwaru nezbytná k využívání prostředků počítače uživatelskými programy, pak pojem mikrokernel naprosto ztrácí smysl, protože ovladače a systémové servery dohromady celkem jednoznačně tvoří jádro – které určitě není zrovna žádnou „mikro-“záležitostí a z pohledu takovéto definice se nijak neliší od monolitické koncepce.

Ty jo to uz spolu zaciname resit docela elementarni veci :-) Kdyz to vezmeme od lesa, tak v monolitu je jadro kod, ktery bezi v privilegovanem rezimu, ma nejaky svuj adresovy prostor a vetsinou se najde v jednom zdrojovem podadresari, ktery se jmenuje nejak jako kernel (srovnej s Minixem), sys, uts, 9 nebo nejak jinak. No a v pripade mikrojadra ma smysl tuto definici recyklovat s tim, ze v tom privilegovanem kodu vetsinou chybi file system, networking a device drivery. Vyjmute casti jsou potom presunuty do userspace.

Cili Minix kernel je i to, co bezi jako system server. Kdo neveri at tam bezi a nebo at si radsi precte 3. kapitolu Minixoveho paperu Reorganizing UNIX for Reliability:

The kernel is responsible for low-level and privileged operations such as programming the CPU and MMU, interrupt handling, and IPC, and contains two tasks (SYS and CLOCK) to support the user-mode parts of the operating system 

Takze kdo tady pouziva nejakou jinou terminologii? :-)

A to vis, ze prunik disjunktnich mnozin je prazdny? :-) Pokusim se ukazat rozpor mezi obema pany, i kdyz si nemyslim, ze by se zrovna Tanenbaum pokousel o vysloveni nejakeho rigorozniho principu minimality syscallu:

Princip L: Liedtke vyslovil princip minimality, ktery rika, ze co nemusi byt v kernelu (a myslel tim kod bezici v privilegovanem rezimu), v nem byt nema.

Princip T: Vsunme pro nase ucely Tanenbaumovi do ust princip syscallove minimality, ktery rika, ze syscallu ma byt co nejmene.

Pozorovani 1: Minix ma mene „pravych“ syscallu nez mikrojadra zalozena na L4.

Pozorovani 2: Minix ma vice funkcionality v jadre nez je nutne (SYS_DEVIO a dalsi) a nez maji jadra zalozena na L4.

Z toho dostaveme:

Princip L + Pozorovani 2 ⇒ Minix ma v jadre cosi navic, co tam byt nemusi a tim padem to neni cistokrevny mikrokernel.

Princip T + Pozorovani 1 ⇒ L4 ma nejak moc „pravych“ syscallu, takze tim padem to neni cistokrevny mikrokernel.

Takze v tom pruniku neni ani L4 ani Minix.

Samozrejme, ze pocet „pravych“ syscallu lze omezit na jeden IPC syscall, ktery by se jmenoval nejak jako IpcProcessThis­MsgInAnotherThre­adAndReply(), ale je to pekna blbost. Uz jenom proto, ze by pak podle Tveho pohledu existoval jen jeden opravdovy mikrokernel – takovy, ktery by umel prave jen tento syscall (a byl zaroven minimalni i z pohledu Liedtkeho).

Z Linuxu take neudelam mikrokernel tak, ze pridam kernel thread, ktery bude z nejake fronty vytahovat joby ulozene syscallama. Je to asi tak na urovni debaty, zda pridavat specializovane syscally nebo cisla ioctlu (v kontextu nasi diskuze cisla zprav).

Taky se mi zda, ze mas nejaky chaos v tom, cim se v operacnich systemech zalozenych na mikrojadrech oznacuje kernel. Prave z te citovane (dejme tomu) Tanenbaumovy vety je videt, ze podle Tveho nazoru (mikrokernel != kernel) by byl Minixovy mikrokernel take prazdny, protoze ta veta do kernelu radi programovani CPU a MMU, handlovani interruptu, IPC a ty dva systemove tasky. Takze jestli kernel je mimo mikrokernel, tak co v tom Minixovem mikrokernelu teda zbyde?

Termin kernel se v tomto kontextu samozrejme pouziva zamenitelne s terminem mikrokernel. To ze se pouziva predpona mikro jen znamena, ze ve srovnani s monolitickymi kernely je tento kernel malinky (nikoliv nejmensi mozny). A proto je mozne L4, Minix, HelenOS a dalsi klasifikovat jako mikrokernel.

Co se týče mě, ztotožňuji se s Liedtkeho či Tanenbaumovou představou o tom, co nazývat pojmem „mikrokernel“. </cite<

Jeste me napadlo, ze se nemuzes ztotoznovat s obema zaroven, protoze si prave kvuli principu minimality odporuji. Ale muzes se jednou ztotoznovat s jednim a podruhe s tim druhym.

Ad bod 2) je krásná politická odpověď. Jak ukázat, že na nějakém systému jde udělat něco složitější. Asi těžko bude někdo uvažovat čistý mikrokernel, kde i plánovač (včetně semaforů) a správce paměti je samostatný modul. Uvažme tedy hybridní kernel, kde některé moduly (typicky moduly, bez kterých počítač není počítačem, jako moduly pro paměť, plánování, systémovou desku) mají monolitickou architekturu a další moduly, které nemusí mít typický počítač, (jako je zvuk, grafika, disk, a jiné), mají spíš mikrokernelovou architekturu.

Prostě nelze mikrokernel implementovat v mikrokernelu, stejně tak jako je nesmysl, aby java byla napsaná v javě, případně C# byl napsaný v C# :-)

Vždycky tam někde bude sedět obyčejný, ale nutně ořezaný monolitický kernel.

Vždyť samotná myšlenka, řekl bych přímo definice, mikrokernelu je založená na tom, že vlastní jádro – proto MIKROjádro – tvoří jen nezbytná část mechanismu IPC pro komunikaci procesů – tj. posílání zpráv – a vše ostatní zajišťují servisní procesy. 

A to jste slysel kde? Myslim, ze zadna exaktni definice pojmu mikrokernel neexistuje. Tim spis ne takova, ktera by rikala, ze kdyz existuji i syscally, ktere nejsou IPC, tak to neni mikrokernel. Jde spis o to, aby ten mikrokernel nabizel nejakou zakladni sadu sluzeb a zbytek, jako je zejmena: file system, networking a device drivery byly userspacove procesy komunikujici pres IPC.

Jochen Liedtke (L4) formuloval princip minimality, ktery rika, ze vsechno co nemusi byt v kernelu tam byt nema, ale a) je to takovy typicky samozvany princip a b) to vede k absurditam. Uvedu priklad: v L4 se kvuli principu minimality implementuje jen synchronni IPC. Asynchronni L4 jadro neumi, protoze ji lze postavit nad synchronni (a naopak) a tudiz by tam byla uz navic. V posledni dobe, zejmena kvuli vyuziti narustajiciho paralelismu v procesorech, ale nekteri vyvojari L4 dochazeji k zaveru, ze i ta asynchronni IPC by nebyla k zahozeni, ale kvuli principu minimality ji do samotneho jadra proste nedaji. Misto toho vse resi pomoci ruznych userspacovych udelatek postavenych nad synchronni IPC. Vysledkem samozrejme je, ze to neni tak efektivni, jak by mohlo byt.

Jestliže tedy do kódu, jenž se bude provádět v kontextu volajícího, zařadíte i správu paměti, správu procesů, kompletní IPC a ovladače systémové desky, no tak dostanete přesně to, čemu se říká monolitické jádro. :-) 

Zde se asi neshodneme.

Ani v případě monolitických jader není nikde řečeno, že veškerý hardware musí být spravován ovladači v reentrantním jaderném kódu – např. klasický Unix měl na odkládání paměti na disk proces „swapper“, dále speciální proces „init“, na grafiku proces „X“, tiskárna měla svůj server dokonce i v jinak monotaskovém MS-DOSu – tento fakt z nich ale ještě systémy založené na mikrojádru nedělá. :-) 

No on ten swapper byl vlastne jen kernelovy thread bezici v kontextu procesu p0 (~ jakoby procesu jadra). To ze si na neco udelam specialni kernel thread nebo dokonce proces, ktery ale bezi v adresovem prostoru jadra, neznamena, ze z te veci delate mikrokernel. To by ty sluzby totiz jeste musely bezet v userspacu. Takze ze ma Minix dva specializovane jaderne procesy je hezke, ale klidne by to mohl delat ten kernel.