Vlákno názorů k článku Proč není Hurd ani po dvaceti letech hotový? od anonym - Mě v článku chybí kritické srovnání koncepce microjádra...
-
anonym (neregistrovaný)
Mě v článku chybí kritické srovnání koncepce microjádra a monolitu. Představa, že microjádro je jednoznačně technicky nadřazeno monolitu, je najivní.
1. Microjádro má obecně nižší výkon a větší latenci. Nové náklady vytváří přepínáním kontextů mezi mikrojádrem a dodatečnou vrstvou serverů. Navíc roste režie na úkoly vyžadující komunikaci mezi mikrojádrem a servery.
2. Linux obsahuje technologie, které přinášejí některé výhody tradičně spojované s mikrojádry. Například Linux umí na požádání nahrávat, vykonávat a uvolňovat kód v jádře (jaderné moduly), rozhraní FUSE umožňuje vytvořit ovladač běžící mimo jaderný prostor...
3. Větší spolehlivost microjádra je mýtus. Důsledky pádu kritického serveru (např. poskytujícího virtuální souborový systém) jsou v praxi de facto stejné jako důsledky pádu celého jádra. Nejde provést izolovaný "seamless" restart tohoto serveru, aniž by spadly kritické procesy operačního systému.
4. Existují efektivní univerzální způsoby, jak vykonat kód a přitom zabránit kódu v čítení/zapisování mimo svojí alokovanou paměť. (Jde o některé experimentální patche kompilátoru GCC, virtualizace a chráněný přístup do paměti...) K oddělení paměťových prostorů různých subsystémů jádra není potřeba měnit architekturu jádra.
5. Co když potřebuji do jádra novou funkcionalitu? V Linuxu stačí zavést jeden jaderný modul. V microjádře může být problém daleko těžší, protože může být třeba současně a synchronizovaně pozměnit několik serverů a microjádro. Například vytvořit patch ksplice pro systém s microjádrem by bylo extrémně obtížné. -
Sten (neregistrovaný)
Jako modifikovaný mikrokernel to popisuje Microsoft, protože to hezky zní, ale ve skutečnosti je to hybridní jádro, což je ale vlastně monolitické jádro programované jako mikrojádro. Linuxový systém modulů, FUSE a CUSE je tomu hodně podobný (i když u Windows se ty user-space servery využívají víc).
-
martin (neregistrovaný)
Mě v článku chybí kritické srovnání koncepce microjádra a monolitu. Představa, že microjádro je jednoznačně technicky nadřazeno monolitu, je najivní.
Tak co se týká kocenptu, tak je mikrojádro obecně jistě technicky nadřazeno monolitu. O tom není pochyb. To, s čím se mikrojádra potýkají jsou implementační problémy.
ad 1. To mi přijde stejné jako hodnocení, že 1:1 kernel má obecně nižší výkon a větší latenci než N:1 příp. diskuse 1:1 vs. N:M nebo režie virtualizace atd. atd.
ad 2. To ano, ale chybí ta izolace.
ad 3. Pád VFS není zrovna běžný pokud ho nesejme ovladač, což běžné je. A to právě izolace řeší. O mýtus se nejedná.
ad 4. O tomhle nevím, ale působí to na mne jako "chtěli bychom stejné vlastnosti jako mikrojádro, ale nechceme (veřejně) připustit, že to mikrojádro řeší lépe". Také to může být cesta, jak z Linuxu to mikrojádro udělat, protože změna architektury linuxu formou revoluce je neprosaditelná.
ad 5. Mě to tedy přijde u mikrojádra daleko jednodušší právě díky izolaci a definovaných rozhraních. Nehledě k tomu, že si v případě mikrojádra dokážu představit vcelku jednoduše fault-tolerant rozšíření na úrovni subsystémů.
-
anonym (neregistrovaný)
ad 1. Přepínání kontextu je extrémně drahá operace. Mikrojádra mají obecně podstatně nižší výkon (řádově procenta) než monolitická jádra. Nízký výkon je i hlavní problém u HURDu.
ad 3. Neřeší to problém, stále je špatný ovladač. Mimochodem Linux umí izolovat problémové ovladače souborového systému přes rozhraní FUSE. Proč by se měla vůbec vyplatit izolace ovladače virtuálního souborového systému do samostaného serveru?
ad 4. Například Microsoft myšlenku řízeného jaderného kódu celkem úspěšně rozvíjel v experimentálním projektu Singularity. Podle mého názoru monolitické jádro s řízeným kódem řeší vcelku nepodstatný problém izolace subsystémů lepším způsobem než mikrojádro.
ad 5. I monolitické jádro může mít jasně definovaná izolovaná API/ABI rozhraní.
-
martin (neregistrovaný)
ad 1. Právě ono přepínání kontextu je implementační problém (ve většině případu vázaný na i386) a nikoli koncepční. Koncepce mikrojádra nepředepisuje jakým způsobem je provedena izolace. Řádově o procenta nižší výkon je až na výjimky nezajímavý. Virtualizace vám sebere to samé (ne-li víc) a nikoho to nepálí. Výkon HURDu bych u projektu, který je de facto stále na začátku, neřešil.
ad 3. Řeší. Restartuje se ovladač a jede se dál. Chyby, především ty ve spojení s HW, budou existovat vždy. Jde o to, jak se v praxi řeší situace, kdy nastane výjimka. A co se týká vyplatit vs. nevyplatit tak je to stejné jako jestli se vyplatí programovat objektově nebo neobjektově.
ad 4. Tak zrovna Singularity je také typ mikrojádra. Jen s tím rozdílem, že režii kontextového přepínání i386 řeší jinak. Nicméně se subsystémy tváří také jako procesy.
ad 5. Jistě, ale tato existence v monolitu nijak neovlivňuje možnosti změn v mikrojádře.
-
„ad 1. Přepínání kontextu je extrémně drahá operace. Mikrojádra mají obecně podstatně nižší výkon (řádově procenta) než monolitická jádra. Nízký výkon je i hlavní problém u HURDu.“
Přepínání kontextu může být i extrémně levná operace. Záleží na implementaci a okolnostech.
A znovu, Hurd není jediný mikrokernelový operační systém.
„ad 3. Neřeší to problém, stále je špatný ovladač. Mimochodem Linux umí izolovat problémové ovladače souborového systému přes rozhraní FUSE. Proč by se měla vůbec vyplatit izolace ovladače virtuálního souborového systému do samostaného serveru?“
Protože nebude kerneleovým kódem a jako taková nezhroutí při problémech systém. Ten bude stabilní jako skála.
Další, ještě významnější pak je, že pro user space se programuje luxusněji, rychleji a efektivněji, než cokoli co je v jádře, nebo aspoň háčky v jádře.
Třetí důvod – souborový systém může být distribuovaný přes celou počítačovou síť.
Čtvrtý důvod – možnost restartu driveru i vfs při problémech. Tak jak to dělá Linux v kernelu to ani vzdáleně nedělá izolaci a spolehlivost jaká je v mikrokernelu.
Tvůrce Unixu napsal před časem knížku. Jeden z věcí, co by dnes na unixu změnil je jeho příliš silou závislost na filesystému a přesném rozložení adresářů.
„ad 4. Například Microsoft myšlenku řízeného jaderného kódu celkem úspěšně rozvíjel v experimentálním projektu Singularity. Podle mého názoru monolitické jádro s řízeným kódem řeší vcelku nepodstatný problém izolace subsystémů lepším způsobem než mikrojádro.“
Neřeší. Možnosti chyb v Singularity jsou daleko rozsáhlejší. Kód, který musí být stabilní aby systém byl stabilní v Singularity je mnohem větší, než u mikrokernelů.
Například musí běžet bezchybně celá virtuální mašina .NETovského kódu a její překlad do strojáku.
Pomíjím to, že Singularity není operační systém, ale virtuální stroj. To už můžete za oprační systém prohlásit třeba JVM, bude to totéž.
-
Lael Ophir (neregistrovaný)
ad 4. Singularity nevyžaduje .NET runtime, ani toho času kompletní .NET runtime neposkytuje aplikacím.
Singularity je operační systém. Píše se pro něj v C#, resp. čemkoliv co překládá do CIL (".NET" jazyky). U klasického OS byste mohl tvrdit, že to není OS, ale runtime jazyka C :)
Podle mě je budoucností právě Singularity. Vyjma architektury mikrokernelu nabízí navíc možnost formální verifikace prakticky celého kódu, což projekt napsaný v C nikdy nemůže nabídnout. To by mělo vyřešit celou škálu problémů se spolehlivostí a bezpečností SW. Výkon vypadá ve srovnání s klasickými systémy dobře. Některé věci jsou výrazně rychlejší (IPC), jiné trochu pomalejší; výsledek je srovnatelný.
-
„Mě v článku chybí kritické srovnání koncepce microjádra a monolitu. Představa, že microjádro je jednoznačně technicky nadřazeno monolitu, je najivní.“
Já to vezmu ironicky. Představa, že deset miliónů řádek kódu v monolitickém jádře bude absolutně bezchybná, protože jakákoli chyba v monolitickém jádře znamená, že už nelze zaručit spolehlivost a stabilitu – je naivní.
Právě proto se mikrojádra dělají. Koncept unixu stál v době, kdy unix kernel měl pár tisíc řádek zdrojáku.
Momolit v tak rozsáhlé podobě jako Linux existuje jen proto, že se na jeho vývoji podílí enormní množství vývojářů. Ono se to časem projeví při dalším růstu Linuxu.
„1. Microjádro má obecně nižší výkon a větší latenci. Nové náklady vytváří přepínáním kontextů mezi mikrojádrem a dodatečnou vrstvou serverů. Navíc roste režie na úkoly vyžadující komunikaci mezi mikrojádrem a servery.“
Stejně tak obecně programovací jazyk C má menší výkon, než ručně optimalizovaný stroják. Skript v bashi má obecně nižší výkon, než přepsat totéž do čistého jazyka C. Perl skript má rovněž mnohem nižší výkon, atd.
Koncept XWindows má nižší grafický výkon, než přímé volání grafiky třeba ve Windows, nebo QNX.
Stejně tak koncepty operačních systémů sálových počítačů, kde se volaly přímo rutiny na zápis na diskový sektor určitě měly větší výkon, než zápis přes filesystém Linuxu.
Prostě píšete hovadiny. U mikrojádra je nutný dobrý návrh mikrojádra a komunikace. Pokud se navrhne špatně, výkon je mizerný. Pokud se napíše dobře, výkon je dobrý.
Je to stejné jako s tím, že když budete zapisovat na disk přímo sektory, Váš výkon bude větší, než „rozežrané“ služby kernelu Linuxu pro práci se soubory.
To je totéž.
„2. Linux obsahuje technologie, které přinášejí některé výhody tradičně spojované s mikrojádry. Například Linux umí na požádání nahrávat, vykonávat a uvolňovat kód v jádře (jaderné moduly), rozhraní FUSE umožňuje vytvořit ovladač běžící mimo jaderný prostor...“
Demogogický argument. Základní výhodu mikrojádra, totiž spolehlivost a necitlivost na chyby v driverech bez dopadu na stabilitu systému.
Dále možnost nativně mít distribuovaný systém na více počítačích tvářících se jako jeden počítač s jedním operačním systémem.
Možnost vývoje driverů stejně luxusně jako běžného user programu.
A desítky dalších.
Tento argument neobstojí, protože Linux kernel je ten poslední, který by dával výhody mikrojádra. Je to poslední rozšířenější operační systém, který je tvrdý monolit. Ani Windows, ani Mac OS, stejně jako řada dalších operačních systémů už nejsou čistým monolitem.
„3. Větší spolehlivost microjádra je mýtus. Důsledky pádu kritického serveru (např. poskytujícího virtuální souborový systém) jsou v praxi de facto stejné jako důsledky pádu celého jádra. Nejde provést izolovaný "seamless" restart tohoto serveru, aniž by spadly kritické procesy operačního systému.“
Pište do Blesku. Víc k tomuto nemám co dodat.
Samozřejmě že to lze, zejména tehdy, pokud je mikrojádro použito k tomu, že všechna zařízení včetně filesystému a včetně fyzických počítačů jsou několikrát.
Mikrojádro dokáže fungovat nad více počítači, více systémy.
„4. Existují efektivní univerzální způsoby, jak vykonat kód a přitom zabránit kódu v čítení/zapisování mimo svojí alokovanou paměť. (Jde o některé experimentální patche kompilátoru GCC, virtualizace a chráněný přístup do paměti...) K oddělení paměťových prostorů různých subsystémů jádra není potřeba měnit architekturu jádra.“
Mikrojádro pěkně prosím neodděluje pouze paměťové prostory.
Co když neselže paměť, ale něco jiného?
Spolehlivost mikrojádra je prostě dána jeho architekturou.
„5. Co když potřebuji do jádra novou funkcionalitu? V Linuxu stačí zavést jeden jaderný modul. V microjádře může být problém daleko těžší, protože může být třeba současně a synchronizovaně pozměnit několik serverů a microjádro. Například vytvořit patch ksplice pro systém s microjádrem by bylo extrémně obtížné.“
Když potřebujete novou funcionalitu, tak jí naprogramujete asi tak 100× snadněji, než v monolitu, protože programovat pro kernel je méně efektivní, než pro user space.
Jsou věci, které jsou pro mikrojádro obtížnější a naopak.
Nicméně zažil jsem hodně demagogických argumentů proti mikrojádru, ale málokterý byl tak demagogický jako těchto 5 bodů.
-
Michal Kára (neregistrovaný)
"Když potřebujete novou funcionalitu, tak jí naprogramujete asi tak 100× snadněji, než v monolitu, protože programovat pro kernel je méně efektivní, než pro user space."
ROFL! A proto se HURD vyvíjí už 20 let, zatímco Linux byl doveden do použitelnosti za zlomek této doby :-D
-
To je argument jak stehno, fakt.
Existuje X úspěšných mikrokernelových systémů dotažených do konce. Velmi úspěšných.
Viděl jsem souseda hrát na klavír a šlo mu to blbě. Závěr Michala Káry => hraní na klavír nikdy nemůže znít pěkně.
Skvělý pokus jak jeden neúspěšný příklad zobecnit na všechno. Jen tak dál!
-
Michal Kára (neregistrovaný)
Řekl bych, že do první použitelné verze Linuxu bylo investováno méně, než do celého (pořád ne použitelného) Hurdu doteď.
Milan Ponkrác: To neměl být argument, spíš takové rýpnutí, které jsem si nemohl odpustit. Pokud jste ho pochopil špatně, tak se omlouvám :-) Ale ten rozdíl mezi teorií, podle které jsou mikrokernely o mnoho světelných let vepředu, oproti praxi, kde ten rozdíl zdaleka takový není, je IMHO do očí bijící.
-
Já jsem ten argument pochopil velmi dobře a správně.
Protože rýpnutí do toho, že soused špatně hraje na klavír, a proto je koncepce klavíru špatná – je docela zajímavou psychologickou sondou do Vašeho způsobu myšlení. A díky tomu jsem pochopil, že řada lidí ztotožňuje Hurd a jeho vlastnosti s vlastnostmi mikrojádra.
Zvláštní je, že nikdo nezmiňuje, že třeba mikrojádrový operační systém minix, který používal i sám Linus a o kterém se vyjádřil, že bez jeho inspirace by Linux nikdy nevznikl – to se nehodí nikomu do krámu, co?
Hurd je prostě jeden z velmi mála neúspěšných mikrojádrových operačních systémů kolem kterých je mnoho úspěšných mikrojádrových systémů.
Všechno co si přečtete o mikrojádře na masových zdrojích jako je wikipedie je prostě lež. Linuxových nadšenců je příliš mnoho, mají čas a jsou příliš aktivní na to, aby pustili pravdu o mikrojádře ven a dovolili přezentovat jeho úspěšné a vynikající vlastnosti.
Kdo chce najít pravdu o mikrojádře, musí si uvědomit, že je poněkud pokroucená linuxovým ideocentrem pravdy. A musíte hledat jinde, číst si nezaujaté věci a přemýšlet. Na české wikipedii třeba jsou o mikrojádře dokonalé sci-fi bajky a pověsti (napsat kdo za to může je zakázané slovo – takže Ker, pak následuje šlág a končí er, když to napíšete přímo, root to nepustí).
Mikrojádro je velmi úspěšný koncept. Pokud zvládnete dobře navrhnout mikrojádro (pár desítek tisíc řádků kódů), což chce trochu více zkušeností, než monolit, pak už se na tom v zásadě nedá nic zkazit. Nad návrhem mikrojádra je třeba přemýšlet a hodně. Ale pak už jsou obrovské výhody.
Podívejte se na QNX, či na řadu dalších systémů. Kromě Linuxu budete jen stěží nacházet operační systém, který by si z koncepce mikrojádra něco nelíznul.
-
Michal Kára (neregistrovaný)
Podle vaší reakce soudím, že jste to pochopil špatně. Když už se budeme držet toho klavíru, tak by to bylo asi takhle: Miloslav Ponkrác tvrdí, že kytara je příšerný, nešikovný hudební nástroj, zatímco klavír je super hudební nástroj a že se na něj dají zahrát 100x lepší písničky než na kytaru.
A já přitom mám souseda, co má docela hudební talent a hraje na klavír. Hraje na něj relativně slušně. Není to špatné, ale není to tak nijak výrazně lepší než moje hra na kytaru. Takže si logicky odvodím, že s tím páně Ponkrácovým tvrzením to v praxi nebude až tak horké :-)
Jinak, moje argumentace není založená jen o HURDu. Ano jsou jiné mikrojádrové systémy, lepší (vaše argumentace, že HURD je neúspěšný proto, že se snaží převést UNIX/Posix koncepty na mikrojádro zní rozumně). Prostě důkaz sporem - pokud by opravdu mikrojádrová architektura byla _v praxi_ o tolik výhodnější, jak tvrdíte, tak by mikrojádrové systémy musely monolity totálně převálcovat. Což se ale neděje - v praxi se používají monolity, mikrojádra i kombinace obou přístupů.
-
>> Všechno co si přečtete o mikrojádře na masových zdrojích jako je wikipedie je prostě lež.
Není to trochu přehnané? Např.:
However, Jochen Liedtke showed that Mach's performance problems were the result of poor design and implementation, and specifically Mach's excessive cache footprint.[10] Liedtke demonstrated with his own L4 microkernel that through careful design and implementation, and especially by following the minimality principle, IPC costs could be reduced by more than an order of magnitude compared to Mach. [...] Furthermore, performance does not seem to be the overriding concern for those commercial systems, which instead emphasize reliably quick interrupt handling response times (QNX) and simplicity for the sake of robustness.
-
Yenya (neregistrovaný)
Tak zrovna rychlost vývoje bych spíš přičetl "otevřené atmosféře" okolo vývoje kernelu v 90. letech než technickým aspektům. Linus se snažil řídit vývoj tak, aby kód v kernelu byl "dost dobrý", ale hlavně aktuálně dostupný, namísto čekání na teoretický "ideální" kód, resp. "ideální" rozhraní. Pro Linux bylo vždycky prioritou mít aspoň nějaký kód a být schopen ho vyměnit/upravit, až někoho začne fakt hodně štvát.
A dalším faktorem může být, že HURD jako GNU projekt určitě vyžaduje vzdání se práv ve prospěch FSF (v ČR naštěstí nemožné), zatímco přispěvatel Linuxu si zachovává veškerá práva ke svému kódu.
-
Tedy člověče, kritizujete někoho za demagogii, ale přitom si nevidíte na špičku nosu. Jste asi zarytým příznivcem mikrokernelu.
Miliony řádků kódu mikrojádrem neodpářete, žádá si je trend zesložiťování počítačů. Když někde něco klekne v user space, tak to stejně vynutí restart všeho závislého a akorát se ušetří čas POSTu.
Ad stroják>C>bash... To už trolujete?!? Autor kódu si zvolí kompromis mezi efektivitou vývoje a efektivitou běhu. To si myslíte, že to někdo neví?
U x86 je přepínání procesů pomalé. Nazýváte to jen pomalou implementací, která se doladí? Poradíte jako Cimrman Intelu, aby přikreslil tranzistor semhle a támhle a Otellini Vám zlíbá nohy?
Linux přináší některé výhody. Nerozumíte slovu některé? Navíc neshoditelnost je pseudovýhoda, protože, jak jsem psal výše, restartem serveru se závislé věci stanou nekonzistentní a efekt je stejný, jako restart normálního stroje.
Kde jste přišel na to, že Widle nejsou čistý monolit? Jejich zdrojový kód jsme neviděli, ale podle zkompilované velikosti a známých funkcí v nich obsažených mají Widle zhruba stejně kódu v jádře jako Linux a navíc tam natvrdo implementují své FS, což je u Linuxu volitelná věc a neomezuje ho. Naproti tomu Widle z jiného FS nenabootujete.
Co když neselže paměť, ale něco jiného? - To je dvojsečný argument. Navíc, pokud jádro zjistí, že je nestabilní HW, mělo by okamžitě zastavit systém. Pokusy o restarty služeb jsou jistá smrt pro spolehlivá data!
...protože programovat pro kernel je méně efektivní, než pro user space. - Tady je asi jádro pudla Vašich omylů. Ale nebudu dělat blbého. Jistě myslíte vývojově. Ale to si nemyslím. S relokací rozdíl v práci s pamětí ani nepoznáte. Výkon zase poznají všichni ostatní.
No, můžete si gratulovat, jak jste mi utroloval čtvrt hodiny života. -
Lael Ophir (neregistrovaný)
Windows opravdu běží spoustu kódu v kernel mode. Akorát je to na rozdíl od Linuxu modifikovaný mikrokernel. Tzn. modularita na úrovni kernelu, definovené interfaces. FS samozřejmě nejsou natvrdo implementované v jádře; vizte ntfs.sys, fastfat.sys, cdfs.sys. Bootovat lze jen z NTFS (v minulosti i z FAT), ale to je trivialita.
-
ded kenedy (neregistrovaný)
<cite>Windows opravdu běží spoustu kódu v kernel mode. Akorát je to na rozdíl od Linuxu modifikovaný mikrokernel.</cite>
to je hezky marketingovy nesmysl. mikrokernel od monolitu odlisuje prave to, kolik kodu bezi v privilegovanem rezimu. a ve windows v jadre bezi i takove zverstva jako GDI, registry, etc.
-
Yenya (neregistrovaný)
> U mikrojádra je nutný dobrý návrh mikrojádra
> a komunikace. Pokud se navrhne špatně, výkon
> je mizerný. Pokud se napíše dobře, výkon je
> dobrý.Tohle tesat do kamene. Dobrý návrh rozhraní je důležitý u všech programových systémů (knihovny, síťové protokoly, ...).
Já bych si ale dovolil dodat, že dobrý návrh rozhraní je _fakt_ těžký, až bych řekl nemožný. Často nevíte, jak se změní svět za pár let a jak "kreativní" budou uživatelé vašeho rozhraní.
A tady je právě důvod neúspěchu HURDu. Podle mě dobrý programový systém musí spíš být připravený na to, že rozhraní stejně nenavrhne dobře, a být připravený snadno to rozhraní vyměnit, než investovat úsilí do návrhu "ideálního" rozhraní. Je asi jasné, že změnu rozhraní v monolitickém Linuxu uděláte velmi snadno, zatímco v mikrokernelu ne.
Mikrokernel z principu buduje rozhraní tam, kde mnohdy žádná rozhraní ani nejsou potřeba. Je to v jiném adresním prostoru, pak na přístup holt potřebujeme rozhraní.
-
Yenya (neregistrovaný)
Já bych si dovolil přidat ještě další aspekt, který dosud v diskusi nezazněl (aspoň jsem si nevšiml):
6. Vzájemnou izolaci umožňuje dnešní hardware jen na úrovni procesů uvnitř CPU. Ale počítač je přece daleko víc než jen CPU.
Co uděláte v případě, že ten údajně neprivilegovaný ovladač řekne třeba síťové kartě, aby další packet nakopírovala na adresu, na které se zrovna náhodou nachází kód mikrojádra? A neříkejte IOMMU, protože v současných počítačích nemáte za IOMMU všechna zařízení. Nebo že bych do té síťové karty poslal nový firmware, který bude tak často přenášet data po sběrnici, že celý počítač bude nepoužitelný.
Aby se tomuto zabránilo, muselo by být verifikovatelné nejen jádro, ale i ovladače a firmwary. A tím se dostáváme na úroveň složitosti monolitického systému, nebo vlastně "díky" asynchronnosti mikrokernelových serverů ještě k daleko vyšší složitosti.
Neříkám že mikrojádra nemají žádné použití, ale pro "obecný" operační systém běžící na všem od mobilu přes desktopy po mainframe a superpočítače IMHO není jiná alternativa než víceméně monolitický kernel.
