GNU Hurd 0.5, GNU Mach 1.4 a GNU MIG 1.4

U příležitosti oslav 30. výročí založení projektu GNU byl vydán GNU Hurd 0.5 spolu s GNU Mach 1.4 a GNU MIG 1.4. Cílem projektu GNU Hurd je nahrazení unixového jádra sadou serverů běžících nad mikrojádrem GNU Mach. GNU MIG je nástroj potřebný pro překlad GNU Hurd a GNU Mach. Mikrojádro GNU Mach spolu s GNU Hurd je obsaženo například v distribucích Debian GNU/Hurd nebo Arch Hurd.

29.9.2013 04:56 | Ladislav Hagara | Nová verze

Komentáře

[Nereknu]

Je to mrtvej projekt. To i helenos je v hodne vecech mnohem dale...

[SKK]

jo, zase příklad linuxáckého štěpení sil a defragmentace vývoje

[stativ]

Ááá, pán je asi suterén a všechny nás tu uzemňuje těmi svými termity.

Náš administrátor shledal tento komentář závadným.

Vulgární

Zobrazit komentář

[SKK]

ups, neuvědomil jsem si, kam to píšu, prosím zcenzurovat nebo rovnou smáznout...

[potato]

Když si někdo neuvědomuje ani kam to píše, ani co píše, tak to pak opravdu těžké.

[Peťa]

Tak to je hnus velebnosti

- 1 000 000

[mankind_boost]

Defragmentace? Ríli?

[Axi]

[pacholik]

Těším se na verzi 1.0 v roce 2043.

[Rezza]

Nespletl ses a nemelo to spis byt 2143?

[xkomczax]

Nene, dobře to spočítal: k 30. výročí verze 0.5, tudíž "dvojnásobná" verze, 1.0, bude k dalším třicetinám

[Jirka W.]

Já myslel, že mají hotovu tu lehčí polovinu.

[eee]

Spatne jsi to spocital. Nevis ze 80 % prace se udela za 20 % casu? Musime pockat na verzi 0.8 a pak cas vynasobit peti.

[w4rr10r]

2+1*4/3

Half Life 3 confirmed

[mankind_boost]

http://i1.kym-cdn.com/photos/images/original/000/562/514/34a.gif

[Jan Přech]

To je dobré, takže mám ještě třicet let na to, abych si změnil patičku

[Josef Kufner]

A jsou tam nějaké zajímavé novinky, nebo ty nové verze vydali jen kvůli výročí?

[Luboš Doležel (Doli)]

Jsou to zajímavé projekty se zajímavým konceptem, bohužel nejsem přesvědčen, že tento koncept dokáže - hlavně co do výkonu - konkurovat dobře odladěnému monolitu. Dobře odladěný monolit může být srovnatelně stabilní jako mikrokernel. Další přednosti jako že uživatel může mít vlastní ovladače (třeba pro filesystém), které nemohou ohrozit stabilitu systému jako celku, jsou v dnešní době pasé.

Vzhledem k tomu, jak málo lidí na těch projektech dělá, se to ale ani v budoucnu asi nikam nepohne

[petr_p]

nejsem přesvědčen, že tento koncept dokáže - hlavně co do výkonu - konkurovat dobře odladěnému monolitu.

Je jen otázkou času, kdy SMP umře na neškálovatelnosti. Tak jako SMP nahradilo jednoprocesorové systémy. Domnívám se, že budoucnost je ve věcech jako big.LITTLE, Tile, Power/Cell. Tady jsou monolitické systémy hodně nemotorné.

Další přednosti jako že uživatel může mít vlastní ovladače (třeba pro filesystém), které nemohou ohrozit stabilitu systému jako celku, jsou v dnešní době pasé.

Fuse, GIO, D-bus. To je opravdu pasé. Právě s rozvojem vícevláknových systémů, kdy máte dedikovaný (softwarový) server na každou kravinu, dostává mikrojádro nový směr. Když virtualizace je už všude (jmenné prostory), pak je celkem jedno, jestli server běží v uživatelském nebo jaderném prostoru. Přepínání kontextu nemá smysl řešit, když si můžete (a často kvůli topologii musíte) vyhradit procesory na určité služby.

[Michal Kubeček]

Už před dvaceti lety bylo každému soudnému člověku naprosto jasné, že koncepce monolitického jádra je beznadějně zastaralá a odsouzená k zániku a že pouze mikrojádro má budoucnost. Jen ti natvrdlí vývojáři to pořád ještě nepochopili… :-)

[asdfasfasfasf]

i do linuxoveho jadra se dostavaji nejake veci z oblasti mikrojader.

[Michal Kubeček]

[SARCASM SIGN] (jak jsem byl právě upozorněn na IRC, z mého příspěvku nemusí být každému na první pohled jasné, že se jedná o ironii)

[Heron]

Upřímně řečeno, když se mrknu počet jaderných procesů, který stoupá s každou novou verzí jádra, tak mám pocit, že se z linuxu ten mikrokernel stává (opačnou cestou) rychleji, než z Hurdu. Ono to sice až tak úplně nesouvisí (jaderné procesy a mikrokernel), ale už je jich tam (na každé CPU) opravdu hodně.

[Michal Kubeček]

To bych tak úplně za známku mikrokernelovatění nepovažoval. Navíc IMHO většina kernel threadů stejně jen obsluhuje buď softirq nebo nějakou workqueue pro něco, co není praktické dávat do defaultní (a samozřejmě dost narostl počet instancí samotného worker).

Jako známku přibližování bych viděl spíš věci jako FUSE, ale i tam je pořád docela zásadní rozdíl v tom, že v Linuxu se používá jen PL 0 (kernel) a 3 (userspace), takže jakýkoli kód je z hlediska oprávnění buď plně kernel space (s absolutními právy) nebo plně userspace.

[petr_p]

Nechci se hádat o slovíčkách, ale jaké číslo ringu má proces, neříká o stupni mikrojadernosti nic. To je jen implementační detail na zajištění bezpečnosti. Podle mě můžete všechno nacpat do jednoho (neprivilogované) ringu a na principu se nic nezmění. Principem totiž je oddělení jednotlivých ovladačů a komunikace mezi nimi přes k tomu určené rozhraní. A protože jednotlivé procesy si nevidí do paměti, tak nezbývá než se spolehnout na IPC a řešit všechny ošklivosti spojené s asynchronní podstatou protokolu. A s dobře řešeným protokolem přichází vlastnosti jako je restartovatelnost služeb nebo jejich vzájemná zastupitelnost. Je pravda, že i těch pár věcí, co nesou známky mikrojadernosti, je nahony vzdálena ideálu mikrojaderných služeb, ale to se snad časem podá 「doufající smajlík」.

[Michal Kubeček]

To je jen implementační detail na zajištění bezpečnosti.

IMHO velmi podstatný detail - kvůli tomu se to koneckonců dělá.

A protože jednotlivé procesy si nevidí do paměti, tak nezbývá než se spolehnout na IPC a řešit všechny ošklivosti spojené s asynchronní podstatou protokolu.

Což v případě linuxových kernel threads neplatí ani v hodně vzdálené aproximaci.

[Honz]

It hurds me...