Názory k článku
HelenOS nikdy nebude dokončený, říká jeho autor Jakub Jermář

Pěkný rozhovor.
Jen mě zaujalo:
,,Když havaruje VFS, tak je konec. Vy sice můžete pořád přepínat mezi konzolemi, ale už nejste schopni vůbec nic podstatného udělat."

A co takhle ten havarovaný ,modul zresetovat?

Hm, a nedělá se to tak že se znovu zavede z úložného zařízení? A když nejde VFS... :)

A co takhle ten havarovaný modul zresetovat?

Ano, tohle je něco, co třeba lidé kolem MINIXu uvádějí jako univerzální všelék a opakují to téměř jako svou mantru :)

Samozřejmě restart spadlého serveru může krátkodobě pomoci, ale problém to ve skutečnosti neodstraní. Pokud je třeba ve VFS serveru nějaká chyba nebo neošetřený stav, tak je velmi pravděpodobné, že se po restartu projeví znovu — dříve či později.

V současné době v HelenOSu tedy spadlé servery nerestartujeme, i když jsme o tom už párkrát uvažovali alespoň jako o jakémsi prostředku poslední záchrany (potřebovali bychom k tomu zřejmě nějaký session manager, který zatím nemáme).

Chceme, aby VFS ani jiný esenciálně důležitý systémový server prostě nepadal, a toho se snažíme dosáhnout jak kvalitním kódem a správným "softwarově-inženýrským" přístupem, tak různými pokusy o formální verifikaci správnosti kódu.

>> různými pokusy o formální verifikaci správnosti kódu.

Můžeš se o tom trochu rozepsat (nebo odkázat na nějaké vaše texty)?

Stav asi před rokem jsem popsal v tomto článku:

Martin Děcký: A Road to a Formally Verified General-Purpose Operating System, in Proceeding of the 1st International Symposium on Architecting Critical Systems (federated with CompArch 2010), LNCS 6150, Jun 2010

Aktuálně pracujeme na dvou dalších článcích s konkrétními výsledky. Vše je samozřejmě stále work-in-progress, ostatně jako celý HelenOS :)

Největší problém je např. selhání komunikace se záznamovým HW, u kterého se kvůli poruše zařízení nebo rušení komunikační cesty prodlouží doba odezvy nebo sníží rychlost komunikace (zmetek USB kabel), uvolnění konektoru (častý případ u SATA a eSATA), rušení komunikace bezdrátovým vysílačem (WIFI, kabely (někdo přiskřípl kabel nebo ho přejel kolečkovou židlí),.. ).
To není dodnes ošetřené ani na Windows, ani na Linuxu, ani na MacOS,...
Řeší to jen tím, že když vyprší timeout, tak to zkusí znovu, třeba ještě párkrát a pak konec a data jsou nepřístupná, ty co se měly uložit většinou ztracená, program co je ukládal přestane komunikovat s OS a ten ho na timeout ukončí nebo dokonce spadne VFS nebo více částí OS apod.
Přitom uživatele vůbec neupozorní, že došlo k problému s komunikací se zařízením XY, nezeptají se zařízení na jeho aktuální SMART stav, nebo že došlo ke snížení přenosové rychlosti kvůli chybám a tak se začaly přenosy opakovat, ..
a nevypíšou ten stav a tu chybu na obrozaovku se zvýrazněním překročených nebo chybných parametrů.

A uživatel marně čeká co se bude dít a doufá, že se to snad rozběhne, že jen nějakej proces zrovna zaměstnal víc procesor,...
Pak nastane chvíle, kdy na to zařízení má zapsat jinej proces nebo dokonce přímo z OS a výtuh a nebo zas jen zpomalené reakce.

Uživatel po dlouhém čekání zvolí restart, a musí jak inspektor procházet logy co se stalo a když se ani ty logy neuložily, tak je nahranej a detektivka začíná. Přitom by stačilo napsat na obrazovku srozumitelnou řečí co se děje, proč se reakce systému zpomalily, co nastalo za chybu, případně to zkusit i odeslat třeba po síti nebo uložit na jinej HW v lokálním počítači nebo v síti(parametry serveru na chyby by byly přednastavené a uložené v paměti už od načítání OS),...

Obavam se ze pokud bude projekt psan v C/C++, tak "pokusy o formalni verifikaci spravnosti kodu" zustanou jenom pokusy.. (za predpokladu ze neplacam blbosti a stale pouzivate C/C++)

Neuvazovali jste treba o nejakem kulturnejsim (rekneme funkcionalnim) jazyku?

Osobne jsem presvedcen ze pokud je cilem spolehlivost a stabilita, funkcionalnim jazykum se nic nevyrovna

Obavam se ze pokud bude projekt psan v C/C++, tak "pokusy o formalni verifikaci spravnosti kodu" zustanou jenom pokusy

Problém není v programovacím jazyku, ale v množství abstrakce a sémantické informace, která je v kódu nějak implicitně nebo explicitně obsažena. Souhlasim, že lze asi s jistou básnickou licencí obecně říci, že Java se verifikuje snadněji než C a funkcionální jazyky se verifikuji snadnějí než imperativní jazyky, ale v praxi jde vždy o to, jaké vlastnosti a jakým způsobem chcete verifikovat, jak se poperete s nerozhodnutelností a state space explosion apod.

Nástroje pro formální verifikaci céčka existuji, např. Frama-C, VCC.

Neuvazovali jste treba o nejakem kulturnejsim (rekneme funkcionalnim) jazyku?

Nevidím na céčku nic nekulturního. Každý programovací jazyk lze používat kulturním i nekulturním způsobem.

Ovšem budoucímu použití nějakého funkcionálního jazyka nebo alespoň imperativního jazyka s funkcionálními prvky (typu Groovy) se rozhodně nebráníme. Až budeme umět chodit, můžeme se učit běhat :)

To mi přijde jako pevná víra ve widlí filosofii. Autoři HelenOSu viditelně aspirují na kvalitu místo kvantity. Restart služeb třetí strany ostatně nevyloučili, pouze se snaží maximálně odladit životně důležité části svého systému.

nemate pravdu a vasa predstava je na urovni uzivatelskeho pohladu (nic v zlom)
ale pozrite si situaciu kedy si restart nemozete dovolit - napriklad pri riadeni kritickych systemov - tam pravidelny restart ala windows nieje jednoducho mozny a je nutna verifikacia - napriklad ak vase komponenty su vzajomne zavisle a maju zlozity vnutorny stav.

Proč výrobci v poslední době tak moc o ty mikrokernely stojí?

Minix, Hurd i HelenOS jsou salónní teoretické projekty, u kterých není drajv na nasazení od praxe. Autoři si s tím hračičkují, miliskují se, ale prioritou není praktické nasazení a snaha to rychle prakticky co nejdříve nasadit.

Naproti tomu existuje řada skutečných mikrokernelových systémů. Leckde je to i nezbytné z důvodu spolehlivosti, kterou takový systém může nabídnout. PLus řadu dalších vlastností.

Ale Linus jednou řekl, že mikrokernel je blbost, tak prostě je. A všichni budou tvrdit jak je špatný, protože to řekl Linus. Jiný důvod není.

i linus zacal s linuxem jen pro zabavu.
ale byl prvni tak ma nejvetsi pozornost a slavu.

verim, ze jednou i ten slavny hurd bude pouzivan v produkcnim systemu.

co rekl linus o mikrojadru vychazi z dosavadni prakticke zkusenosti,
myslim, ze jeho slova budou platit jeste maximalne 10 let.
pak bude mikrojadro skoro vsude.

zaujimave ... takze to ze winNT architektura je v podstate mikrokernel (resp urcity hybrid) je nepodstatne :-)

anyway mikrokernel je skvela vec na implementaciu hypervisora. a myslim ze tam vyvoj aktualne aj smeruje.

>>winNT architektura je v podstate mikrokernel

Slůvko .reloc v mých 344 ovladačích v adresáři Drivers říká něco jiného.
NT nesplňuje žádné z kritérií pro mikrokernel. Zkuste nějaké jmenovat.
P.S. Že to řekl Balmer s vyplazeným jazykem se nepočítá. XD

NT jádro obsahuje:
• Podporované FS, na kteých smí být OS, vč. práv
• Podporované způsoby rozdělení disku (MBR, GPT)
• Kompletní práci s registrem
• Uspávací režimy včetně obcházení errat některého HW
• Ad-hoc rozhraní pro některé důležité ovladače (pci, ntfs, tcpip...) - falešná modularita

http://en.wikipedia.org/wiki/Architecture_of_Windows_NT

Problém mikrojádra je výkon. Přepínání mezi procesy a přiřazování stránek paměti je zátěž. Dokud jsou jen desítky user procesů a celý systém jede v reálu, výkon je v pohodě a systém je tak výkonný, jak ho všichni známe. Ale jakmile se masově nasadí user-space na všechno, tak najednou poběží tisíce, ne-li desetitisíce modůlů, každý s vlastním adresním prostorem. X86 podporuje hardwarově jen 128 procesů, nepletu-li se, při vyšším počtu musí OS vyměňovat položky v tabulce procesů s těmi uloženými jinde. S takovou superzátěží může systém masově užívající user-space zapomenout na výkonnou síť, editaci hudby a vlastně na celé komerční využití. Vždyť i ta fréza se zláme o sklíčidlo dřív, než mikrojádro ráčí přesypat 4000 služeb, jak si možná žádá plánovač, a popoběhnout s naší aplikací. (Tady trochu přeháním, systém můžeme ořezat o grafické rozhraní, vypnout si na chvíli přerušení a je to :-)
Jedině že by se věc vydala cestou posunu kompromisu od efektivních k vysokoúrovňovým jazykům a v budoucnu získaný výkon procesorů se investoval do spolehlivosti systému.

X86 podporuje hardwarově jen 128 procesů, nepletu-li se, při vyšším počtu musí OS vyměňovat položky v tabulce procesů s těmi uloženými jinde.

Předpokládám, že tady hovoříte o Task State Segmentu. Ten má ovšem velikost 8192 položek a většina operačních systémů (včetně Linuxu a Windows) jej stejně nepoužívá pro přepínání vláken — používají klasický softwarový context switch.

Samozřejmě na x86 nejde TSS úplně vypnout (stejně jako segmentace), takže jedna položka v TSS tabulce je skutečně vždy vyplněna, ale po celou dobu běhu Linuxu, Windows i HelenOSu zůstává konstantní. Většina jiných platforem (včetně x86-64) žádnou analogii TSS nemá.

BTW: Nemyslím si, že existuje důvod, aby počet modulů/úloh v mikrojádrovém systému, který provádí několik činností (dejme tomu workload typického desktopu), rostl k tisícům. Už v žádném případě není důvod, aby mikrojádrový systém, který řídí frézu, měl 4000 modulů. Chápu argumentaci přehánením, ale ani s přeháněním by se to nemělo přehánet :-D

Servery v mikrojádrovém systému nemají granularitu tříd, ani nereprezentují jednotlivé instance objektů. Dovedu si představit mnohaprocesorový stroj vyřizující stovky požadavků na sekundu, na kterém budou běžet tisíce serverových úloh. Takové konfigurace dnes ale běží i nad monolitickými systémy.

Závěrem: Určitě nelze zpochybňovat overhead mikrojádrové architektury, ale také by se neměla démonizovat. Není to daň jen tak za nic. Je to daň za explicitní zachycení architektury systému v jeho kódu, vzájemnou izolaci komponent, kompozici složitého systému z jednoduchých stavebních kamenů apod.

ani som nevedel, že niečo také existuje. veľa ľudí robí dobrú robotu a pritom o nich málokto ie. Projektu HelenOS a každému, čo sa do toho zapojí, prajem veľa úspechov.

Jakube, jestli to tady budeš číst, můžu se zeptat, co tě vedlo ke startování nového projektu na zelené louce? Nezvažoval jsi zapojit se do Hurdu?

(hodně respektuju lidi, kteří mají drajv pustit se do něčeho obtížného i bez vidiny nějakého bezprostředního zisku, ale přijde mi, že pod Hurdem by mohlo být stejný množství srandy s větší šancí na praktickou využitelnost investovaného úsilí...)

>> nechtějí Hurd vydat do té doby, dokud nebude úplně hotový, dokonalý a nebude plnohodnotnou náhradou linuxového jádra

A není to prostě proto, že Hurd ještě na vydání není zralý? (nevím, ptám se)

hurdovi lidi jsou znova a znova fascinovani dalsimi a dalsimi mikrojadry
na ktere je treba hurd portovat, i proto jim to tak trva.

zacli s machem, pak L4, pak L4sec, tedka nejaky coyotos.

Nechci rozhodně mluvit za Jakuba Jermáře, ale z mého pohledu vidím asi tak tři důvody, proč pracujeme na vlastním mikrojádrovém OS.

Tak to prostě začalo: Jak už říkal Jakub v rozhovoru, původní kořeny HelenOSu jsou v jeho školních zápočťácích a projektech. I pro nás ostatní to vždy bylo "learning by doing" a to jde podle mě rozhodně lépe, když člověk pracuje vlastním tempem na vlastním projektu, než když se musí zapojovat do práce "cizí" komunity. Aniž bych měl něco proti zapojování se do rozjetých projektů, je asi lepší, když to člověk dělá už jako zkušený programátor.

Historické souvislosti: Před pár lety se Hurd zmítal v dilematu, zda má být postaven nad Machem nebo L4, a byl rozhodně ještě méně použitelný než nyní. O MINIXu se pro změnu ještě před pár lety hovořilo jen jako o "tom výukovém operačním systému z knihy Andyho Tanenbauma", jako plnohodnotný OS ožil až s příchodem verze 3.

Vlastní design: Pár lidí z HelenOS týmu si myslí, že design Hurdu je příliš deformován potřebou být "UNIX compliant" a fungovat jako drop-in náhrada Linuxu nebo BSD kernelu v rámci GNU. Podobně se nám nelibí některá konkrétní rozhodnutí v MINIXu. V případě L4 některé z nás zase odrazuje ne přiliš hezký zdrojový kód.

Zkrátka chceme dělat věci po svém a tak, jak si myslíme, že to je správně. Jestli je to dobrá cesta, to ukáže čas :)

Díky za odpověď a přeju hodně srandy a úspěchů :)

Když jsme si s Jakubem povídali, tak i na to přišla řeč. Nakonec to ale v rozhovoru není. Důvodem pro vlastní projekt prý bylo především to, že chtěl mít vlastní výtvor, který má plně pod kontrolou a může ho směřovat tam, kam bude sám chtít.

Děkuju.

Stejně mi to ale přijde trochu zvláštní, mít projekt, který sice můžu směřovat, kam chci, ale který funguje daleko hůř (předpokládám) než jiný podobný už existující projekt...

Chápu to (a sám dělám) u věcí, kde ten projekt můžu poměrně rychle dostat do stádia funkčnosti ve všech pro mě podstatných oblastech, ale u takového molochu jako je jádro OS...

Nicméně určitě je mi to daleko sympatičtější než vytváření tisícé první "originální" distribuce Linuxu :)

to je podľa mňa len dobre. totiž, je fajn zaradiť sa do nejakého projektu, dostať nejaké to čísielko a enjakú oblasť na starosti - no dobré je tiež niečo viesť a riadiť, kam sa to bude uberať.

dobrý príklad je ubuntu, ktoré niekde ide. veľa ľudí s tým súhlasí a používa ho, iné skupiny si myslia, že by to malo ísť iným smerom. a keďže môžu viesť projekt aspoň čiastočne vlastnou cestou, tak to aj robia.

pri všetkých tých malých projektoch (myslím teraz veľkost v KB/MB, nie v počte ľudí) je dôležitá špecializácia. no a ak to ide iným smerom, ako by sa malo ísť, tak to niekto forkne, laebo začne robiť niečo podobné na zelenej lúke.

Aj reactos (operacny system - teraz alfa verzia 0.3.13) sa dostal do Google SoC. Tam dokonca "hrozi" aj urcita kompatibita s Windows XP - XP vraj konci podpora v roku 2012. Reactos snad dosiahne verziu 0.4.

Skoda, ze nerozumiem operacnym systemom a som asi "stary pes", ktoreho "uz nenaucia nove kusky".

ReactOS jsem zkoušel asi před dvěma roky a bylo to úplně tragicky nestabilní. (Což je škoda, protože svobodná reimplementace WinXP by byla bomba)

Protoze vyvoj dnes jednoznacne smeruje k operacnim systemum s gigakernelem, ktery obsahuje nejen ovladace zarizeni, ale i spravce oken a webovy prohlizec. Samotny uzivatelsky prostor se odehrava pouze ve webovem prohlizeci, odkud uzivatel muze delat vsechno.

Ale vazne. Trochu mi v tom rozhovoru chybi, cim se ten HelenOS nejak odlisuje, tedy krome toho, ze je to mikrokernel. Je to malo technicke.

Beru to, ze je to spis forek - ale jen pro orientaci - soucasny kernely maji uz skoro vsechno v modulech, ne? Jakej je rozdil mezi modulama a mikrokernelem?
PS. na me je to technicke docela akorat...fakt, je ze bych jeste snesl nejakou dalsi technickou informaci

Jakej je rozdil mezi modulama a mikrokernelem?

Moduly beží v kernelovém režimu CPU a ve společném adresovém prostoru se zbytkem kernelu. V mikrokernelu beží v kernelovém režimu mnohem méně kódu, "moduly" jsou od sebe vzájemně odděleny v samostatných adresových prostorech, komunikují pouze pomocí dobře definovaných rozhraní a běží v uživatelském režimu.

Výhod a nevýhod obou přístupů je mnoho — jako v mnoha jiných případech se ani tady nedá univerzálně rozhodnout, co je obecně lepší a co je obecně horší přístup. Pokud se s tím někdo dosud nesetkal třeba na nějaké přednášce o principech operačních systémů, lze určitě začít třeba články na Wikipedii.

Co si vzpomínám, když jsem se hrabal ve zdrojácích, tak mě překvapilo, že spusta služeb jádra (v monolitickém smyslu) je v HelenOS implementovaných pomocí asychnronního předávání zpráv. Když uživatelský proces chce otevřít soubor, tak pouze požádá mikrojádro o přesměrování požadavku, jádro prakticky okamžitě vrátí komunikační deskriptor a uživatelský proces může dělat cokoliv jiného, dokud ovladač patřičného souborového systému se neozve. Pak si spolu vyjednají parametry „služby" otevření souboru (například otevření jen pro čtení), obě strany mohou kdykoliv relaci přerušit (třeba když neporozumí požadavku) a nakonec z toho vypadne identifákor otevřeného souboru, ze kterého proces opět obdobným způsobem čte. Oproti monolitickému jádru to má výhodu, že uživatelský proces není blokován po dobu vyřizování služby (ať už tím, že selhává čtení z blokového zařízení, nebo protože je prostě chyba v ovladači souborového systému). Je to jako kdyby se do Linuxu integroval D-bus nebo ORBIT a aplikace si povídaly s jednotlivými moduly přímo bez účasti jádra jádra (to by řešilo jen identifikaci a autorizaci komunikujících stran, něco jako dnes funguje NETLINK nebo sysfs). Na druhou stranu to má svoji režii a psát událostní smyčky na každé volání služby je otrava. Mám dojem, že se to chtělo řešit nějakou standardní knihovnou, která by programátorovi aplikace ušetřila prsty.

Na druhou stranu to má svoji režii a psát událostní smyčky na každé volání služby je otrava. Mám dojem, že se to chtělo řešit nějakou standardní knihovnou, která by programátorovi aplikace ušetřila prsty.

Základní smyčku událostí (rozskok podle čísla metody) je stále nutné v HelenOSu psát ručně, i když již delší dobu uvažujeme o tom, jak tenhle boilerplate kód generovat automaticky. Stay tuned .. :)

Na druhou stranu, pro složitější komunikaci (kdy se komunikační protokol mezi klientem a serverem sestává z více atomických zpráv) není nutné vracet se do té top-level smyčky událostí, ale lze psát kód, který díky našemu IPC frameworku vypadá v podstatě standardně sekvenčně, ale přesto funguje asynchronně.

Ahoj,
dik za velmi zajimavy rozhovor z tyhle problematiky, ktera je mi uplne cizi, ale o to vic me zajima.
Cili jestli to chapu, hurd je taky typu mikrokernel a mam dojem, ze je ho mozny skloubit v ramci debianu 5 s gnu obalem. Je tohle taky cesta pro helenos? Najdeme dalsi debian s helenos? Zkusil tady nekdo nasadit hurd v debianu? Proc? :)
dik

hurd je vrstva a serverove programy nad mikrokernelem (mach, l4....)
nad jakymkoliv mikrojadrem/jadrem lze vytvorit posix vrstvu a pridat GNU
user-space software.

nekde snad vzali jadro z windows NT, obalili posix vrstvou a nad tim pousteli
GNU programy.

takze je to jen vec investovane prace a casu. i helenos muze mit posix api.

nekde snad vzali jadro z windows NT, obalili posix vrstvou a nad tim pousteli GNU programy.

To někde nevzali, ale udělal to (a pořád udržuje) oficiálně Microsoft. Jmenuje se to Interix.

myslel jsem geNToo, ale to byl aprilovy zert jak jsem zjistil.
http://www.gentooexperimental.org/nt/

To ne Hurd je GNU GPL takže nelze použít pro uzavřené projekty.

V MAC OS X je použit XNU což je kombinace kernelu BSD a Mach.

http://upload.wikimedia.org/wikipedia/commons/f/f2/Diagram_of_Mac_OS_X_architecture.svg

>> V MAC OS X je použit XNU což je kombinace kernelu BSD a Mach.

Když už je o tom řeč, máte někdo představu o tom, proč vlastně Apple BSD jádro nad ten mikrokernel posadil (podobně jako MS)? Kvůli nějaké teoretické budoucí rozšiřitelnosti o jiné machovské subsystémy? Už toho někdy využili, nebo to alespoň plánovali? Pokud vím (a moc toho o tom teda nevím :), i věci, kde bych to tak nějak čekal (Grand Central Dispatch) běží až nad BSD kernelem...

A MS? Ten už mikrokernel nějak pořádně využil?

No něco snad najdete zde:

http://www.root.cz/clanky/mac-os-x-je-taky-unix-1-historie/

Ten seriál jsem četl, ale nepamatuju se, že by tam byla odpověď :)

GCD je implementovany nad BSD/Posix API proste proto, ze pouziva Posix pojem jako semafor a umoznuje aplikacim standartne ridit flow mezi execution units ("thready") nejakeho tasku, tj. pro Posix aplikaci se nemeni struktury - navazane na zbytek Posix API - pro rizeni toku programu, ale "jenom" identifikace jednotlivych paralelizovatelnych exexcution units (funkci/bloku/...). Aplikace potom resi jenom identifikaci/roz­delovani prace, nikoliv jejich mapovani do fyzickych threadu potazmo procesu... vyhoda je jasna: nemusim resit konfiguraci pro kazdy stroj, procistil/zkratil se mi kod, aplikace je regulovana momentalni dostupnosti CPUs/zdroju OS bez meho zasahu, tj. spravu a kontrolu obsazenosti thread-poolu deleguju na GCD...

Jeho implementace je tak take prenositelna (http://libdispatch.macosforge.org) mezi Posix-like OS, tedy aby jej mohly vyuzit standardni POSIX aplikace bezici na *BSD, dokonce s upravami i na Linuxu a NT - tady ale mame omezeni vyplyvajici z nutnosti pouzit Clang compiler.

Jinak hlavni motivace pouzit mikrokernel pro OSX (mozna obecne) je primarne potreba lepsich struktur pro stavbu OS. User-space ma dost prostredku zavest libovolnou potrebnou miru abstrakce, ale vetsine OS vcetne Linuxu takova vnitrni struktura chybi. OSX je hybrid ponechavajici cely VFS i network stack na implementaci od BSD, ale diky Machu pod prdeli se muzou kdykoliv rozhodnout postavit dalsi mezivrstvu mezi vlastnim HW a vyssim subsystemem i mezi subsystemy navzajem. Tj. umoznuje jim to lepsi interceptovatel­nost. To ze se rozhodli nechat bezet Mach a BSD spolu ve stejnem adresnim prostoru (nezabere memory protection z procesoru) a oboje v ring0 chapu "jenom" jako performance benefit... rozpojit to _lze_.

Predstavte si jak by mohli implementovat Spotlight (fulltext search nad objekty v systemu, pro jednoduchost nad soubory): zadny z FS (a dejme tomu ani VFS) to nepodporuje, tj. nerozesila eventy o vytvoreni/pre­sunu/smazani/­... souboru. Pak muzu na vstupu do Posix callu vytvorit kontext kde zaznamenam o jaky soubor a jakou operaci se jedna a jakmile BSD/(V)FS provede zapis, dostane se do Machu message s pozadavkem na konkretni ukon nad driverem. Tuhle I/O (Kit) zpravu muze ale v mikrojadru zachytit i muj spotlight-events-listener, ktery ji na zaklade obsahu kontextu muze zpracovat (upravit svuj index). Takhle transparentne mam poresene vsechny FS v systemu aniz to kterykoliv z nich tusi... a ano - tuhle featuru by jste mohl implementovat i na urovni BSD kernelu a jeho VFS, ale v pripade ze se Apple rozhodne zamenit BSD za Linux (:-)), bude fungovat bezezmeny dal... obdobne mohou takhle implementovat transparentni cache, ..., pro cokoliv mezi HW/BSD.

Apple kernel development docs: http://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/KernelProgramming

Díky moc za obšírnou odpověď.

V podstatě jsem to teda zas tak moc nepřestřelil: Mach použili proto, aby v budoucnu *mohli* udělat nějaké zajímavé věci, ale zatím toho moc nevyužili.

V tom seriálu, co je tady, se píše jenom krátce o lepší kontrole nad drivery - jsou i nějaké další příklady toho, co reálně (ne jen potenciálně) využívá výhod Machu pod BSD kernelem?

> zadny z FS (a dejme tomu ani VFS) to
> nepodporuje, tj. nerozesila eventy o
> vytvoreni/pre­sunu/smazani/­... souboru.

Ted nevim jestli se bavite jen o Apple nebo i o FS/VFS obecne. Pokud to druhe, tak protipriklad je treba Linux a fanotify().

Moc nerozumím otázce, ale BSD použili jednak aby zefektivnili některé úlohy a aby získali POSIX API. Krom toho vytáhli z BSD řadu dalších vlastností (VFS, síť, audit, MAC, atd.)

Na druhou stranu důvodem pro použití Mach kernelu byl jednak NeXTSTEP a jeho výborné vlastnosti jako stabilita a vyzrálý SMP (mluvíme o 2. polovině 90.let) a také jeho Mach object formát tedy krom jiného využili jeden "exe" pro více architektur - přinejmenším PPC, Intel příp. ARM. Mach dělá v Darwinu vlákna, multitasking, procesy (ty jsou v BSD vrstvě "předělané" do unixového modelu), RT, IPC (opět v BSD vrstvě transformované na sys-v IPC) atd.

>> Moc nerozumím otázce, ale BSD použili jednak aby zefektivnili některé úlohy a aby získali POSIX API.

Myslel jsem ji přesně naopak: proč nepoužili samotné BSD? Co získali tím, že ho posadili nad Mach?

(možná se ptám úplně blbě, v těchhle věcech se fakt moc nevyznám :)

Tak pak je odpověď v druhé části.

Vlákna a SMP byly určitě lepší v Machu (+ IO kit). Lepší :-) v BSD se to tou dobou teprve rodilo. Navíc měli celý systém postavený jen na Machu ze kterého ten vývoj vycházel.

Cau - prvne samozrejme blahopreju k dilku - zajimalo by me ale co prinasi HOS noveho - zda je k dispozici seznam nejakych inovaci nebo jak o nem autori premysli do budoucna? Jak uz nekdo psal - rozhovor je celkem malo technicky. Jinak preju uspesny dalsi vyvoj! :)

Pár informací je k nalezení na naší wiki

• http://trac.helenos.org/wiki/FAQ
• http://trac.helenos.org/wiki/ReleaseNotes/0.4.3
• http://trac.helenos.org/roadmap

Je ale pravda, že spoustu věcí týkajících se zajímavých vlastností a plánů zatím zkrátka držíme ve svých hlavách, protože náš "core" tým je poměrně malý a nikdo na HelenOSu nepracuje opravdu full-time.

Žádnou podrobnou roadmap s výhledem na 10 let dopředu a končící položkou "world domination" teda nemáme. Asi je to škoda, ale den má zkrátka jen 24 hodin :)

Řada lidí se nás ptá "jak můžete čekat, že HelenOS bude někdo používat, když nevypadá ani jako Linux ani jako Windows?" Moje odpověď je:

1. My nikoho nenutíme HelenOS používat a nejsme nijak závislí na tom, jestli ho někdo používat bude nebo ne. Vyvíjíme ho pro vlastní potěšení.

2. Celkově módní vlna zájmu o operační systémy je v současné době v dolní půlce periody. Průměrný uživatel dnes nepotřebuje vidět dál než na to, jestli má jeho webový browser záložky na správném místě, nezajímá ho jakou má verzi jádra systému apod. Nelze tedy očekávat, že se bude aktivně zajímat o alternativní operační systémy, pokud má něco, co "funguje". Neočekávám, že bychom oslovili masy,

3. HelenOS nikdy nebude tak dobrý Linux jako je Linux (jen HURD může být tak naivní, že si myslí, že bude lepší Linux než Linux). Hodnota HelenOSu je v jeho originalitě. Pokud bude dostatečně odlišný, určitě se najde někdo, komu se Linux zajídá a ocení, že některé věci řešíme přesně naopak.

Mel bych par dotazu ...

Netrpi mikrokernel vykonove oproti monolitickemu jadru?

Chapu, ze v konceptu mikrojadra je samotny kod bezici v privilegovanem rezimu pomerne maly, dobre udrzovatelny, robusni, mene nachylny na chyby, pokud je ovsem vse co lze vystrceno do userlandu musi dochazet mnohonasobne vicekrat ke "context switch" ?

Nemuze byt tedy v tomto zakopan pes? Dokazu si predstavit, ze pokud se napr. jedna komponenta "zblazni" dokaze saturovat cely system jen rezii zprav, jak se vlastne pozna takova vadna komponenta a rozhodne se, ze ji je treba napr. restartova?

Jak se vlastne takovy system debuguje pri programovani, myslim tim kdyz se vse odehrava dost asynchrone?

Netrpi mikrokernel vykonove oproti monolitickemu jadru?

Ano, komunikační overhead IPC bude vždy v principu o něco větší než běžné volání funkce. Většina vývoje kolem mikrojader v 80. a 90. letech se právě točila kolem toho zoptimalizovat tento overhead co nejvíce.

Myslím si ovšem, že v dnešní době už ten fyzický overhead nehraje takovou roli. Koupit si o 10 % rychlejší procesor kvůli overheadu mikdrojádrové architektury je triviální a je to rozumná investice, protože za odměnu můžeme získat modulární, snadno udržovatelný a bezpečný kód. Údržba složitého monolitického softwaru, kde drobná chybka v málo podstatném modulu může způsobit pád celého systému, se jeví jako mnohem dražší a dlouhodobá investice.

musi dochazet mnohonasobne vicekrat ke "context switch"

Tohle je tak trochu nepochopení. V dobře navrženém mikrojádrovém systému dochází (za předpokladu asynchronní komunikace) ke zhruba stejnému počtu přepnutí kontextu jako v monolitickém systému — především z důvodu preempce nebo blokování.

Mikrojádrové systémy se zkrátka nesmí programovat tak, že se vezme "monolitický" sekvenční kód s funkčními voláními a ten se mechanicky převede na synchronní zasílání zpráv. Když se vhodně využije asynchronicita komunikace, koncepty jako future a promise a rozumný způsob předávání dat, tak se převážná část overheadu redukuje na nutné minimum.

jedna komponenta "zblazni" dokaze saturovat cely system jen rezii zprav

Počet zpráv, které může mít jedna komponenta v jeden okamžik "ve vzduchu", je omezen. Další zprávy si frontuje ve vlastní režii a tudíž ne více času, než je naplánována plánovačem. Takže jedna komponenta nikdy nezasaturuje celý systém.

Jistě se může stát, že nějaký proces bude soustavně "vyžírat" veškery procesorový čas, který mu plánovač dá, ale to se pochopitelně může stát i v monolitickém systému.

ji je treba napr. restartovat

Jak jsem už psal někde výše, restart podle mě nic neřeší :)

Jak se vlastne takovy system debuguje pri programovani, myslim tim kdyz se vse odehrava dost asynchrone?

Souhlasím, že debuggování asynchronní komunikace je složitější než debuggování sekvenčního kódu. Je potřeba sledovat komunikaci a všechny komunikující strany. V principu to dost připomíná ladění síťové komunikace ..

Na druhou stranu, v dohledné době budou mít procesory asi jen víc a víc jader a hardwarových vláken, takže luxusu přehledného sekvenčního kódu si stejně asi moc neužijeme :)

"Myslím si ovšem, že v dnešní době už ten fyzický overhead nehraje takovou roli. Koupit si o 10 % rychlejší procesor kvůli overheadu mikdrojádrové architektury je triviální a je to rozumná investice, protože za odměnu můžeme získat modulární, snadno udržovatelný a bezpečný kód. Údržba složitého monolitického softwaru, kde drobná chybka v málo podstatném modulu může způsobit pád celého systému, se jeví jako mnohem dražší a dlouhodobá investice."

Matematická poznámka: cena za upgrade hardware ale roste lineárně s počtem strojů, zatímco cena údržby software obecně nikoliv. Takže když jich máte opravdu hodně...

cena za upgrade hardware ale roste lineárně s počtem strojů

Cena za údržbu software zase roste s jeho velikostí. A dokonce bych se nebál tvrdit, že rychleji než lineárně.

Jestli vyjde ten trade-off v konkrétním případě lépe pro monolitický nebo modulární systém, to se skutečně nedá obecně a univerzálně rozhodnout. Netvrdím, že můj MP3 přehrávač musí řídit mikrojádrový operační systém složený z 25 komponent. Ale v případě jaderné elektrárny bych zase usínal hůře, kdybych věděl, že ji řídí program napsaný v jediném modulu :)

"Cena za údržbu software zase roste s jeho velikostí. A dokonce bych se nebál tvrdit, že rychleji než lineárně."

To je dost možné, ale software je jeden, zatímco strojů na kterých běží můžou být statisíce. Chtěl jsem tím podotknout, že ta skutečnost, že se to jádro lépe udržuje a vyvíjí, by se nakonec měla odrazit na nějaké produktivní vlastnosti - vyšší rychlost, vyšší spolehlivost, menší paměťová náročnost, spotřeba proudu nebo já nevím co ještě (tipoval bych, že spolehlivost bude horký kandidát). Pokud ne, tak na velkém počtu strojů vždycky "asymptoticky" prohraje.

>> ta skutečnost, že se to jádro lépe udržuje a vyvíjí, by se nakonec měla odrazit na nějaké produktivní vlastnosti

Z toho, co jsem tady tak zaslech, tak mi třeba jako hodně dobré přišlo to dobře definované rozhraní mezi servery. Na tom by mohl jít postavit třeba upgrade za běhu, což by mohla být hodně produktivní vlastnost...

(viz třeba Erlang...)

Přesně tak. Hlavní výhoda QNX není ani tak to, že je mikrokernel, tedy že se super udržuje, ale hlavně spolehlivost daná (zde zavrhovanou) schopností restartovat jednotlivé služby za běhu, což se ale nevyužívá jenom pro případ pádu, které budou reálné, i když budete mít svou část formálně verifikovanou (např. u jaderné elektrárny těžko může systém říct: balím to, dokud to neopravíte), ale taky pro aktualizace.

Mimochodem formální verifikace má jeden zásadní problém: samotná definice, podle které se ověřuje, může obsahovat chyby :-)

> Jak se vlastne takovy system debuguje pri programovani
Debugovani takovych systemu ma sva specifika, na prvni pohled to mozna vypada zahadne, ale v praxi to muze byt i pohodlnejsi nez treba desktop monolyticka aplikace. Tady muzete mit porad spustene procesy, ktere komunikuji s tim debugovanym, muzete je behem toho ovladat, nejsou zamrzly a kdyz objevite v jedne komponente chybu, tak ji opravite a restartujete. Kdyz vam pak dobre funguje vyhledavani komponent a obnovovani spojeni, tak je z ladeni radost :-)

...radost si pocist.

Pěkný projekt - ale zajímalo by mne, proč jste na první možnou a pak všechny vyšší úrovně nevytáhli objektový derivát C s možností podhodit název objektu-modulu a soubor s ním (ano, hrozí špagetový kód)? Protože modularita chodí poměrně nedaleko objektového návrhu a psát to klasickou cestou je cesta akorát k blobu (Linus sám říká, že jádro je daleko od jeho původních představ). Navíc by jste mohli pracovat v oblasti, kde začal NextStep a web v dnešní podobě vůbec.

Sice jsem některým věcem v dotazu úplně neporozuměl ("objektový derivát"), ale obecně se dá říci, že třeba interní API mikrojádra HelenOSu mají objektový charakter.

Odpověď na skoro všechny dotazy typu "proč jsme něco neudělali jinak" je bohužel taková, že den má jen 24 hodin. Některé věci jsou v současné době implementovány jen provizorně, spousta funkcionality chybí, spoustu věcí chceme předělat a možná ještě víc věcí bychom chtěli předělat, kdybychom měli energii zamyslet se nad nimi ještě lépe a důkladněji.

Ovšem HelenOS je open source projekt a pokud si myslíte, že můžete přispět dobrou myšlenkou nebo ještě lépe patchem, budete srdečně vítán!

Nebyly by nekde screenshoty?

Povedené. :-)

A proc by clovek mel travit dvakrat tolik casu udrzovanim webovych stranek ve dvou jazykovych variantach, kdyz ta ceska ma prinos pro naproste minimum uzivatelu (zvlaste kdyz se jedna o software zamereny nikoliv na laiky, ale na odborniky, kterym anglictina stejne nedela vetsi potize)?

Jen tak žertem - máš představu, kolik normálních lidí už si ani nedovede představit život bez vymožeností, jež by byly nevznikly nebýt lidí jako jsou matfyzáci? :-D

Nejak jsem nepochopis o cem/k cemu HelenOS je a kam smeruje ?

NN

Tak si to přečti znova. Žádnej stres.