Arch Hurd (diskuse)

[lukve]

vsetka cest tymto ludom. mozno sa vyvoj hurdu pohne rychlejsie dopredu.

[Saljack]

Vysvětlí mi někdo, jakou výhodu má Hurd oproti Linuxu, BSD atp.

[frdrx]

Je jinej. To stačí, ne?

[Jakub Jermář]

Treba zde.

The Hurd is a very modern design. It is more modern than Linux or the BSDs, because it uses a microkernel instead of a monolithic kernel. It is also more modern than Apple's Darwin or Microsoft's NT microkernel, since the it has a multi-sever design, as opposed to the single-server design of Darwin and NT. This makes the Hurd an ideal platform for students interested in operating systems, since its design closely matches the recommendations of current operating system theory. In addition, the Hurd's modular nature makes it much easier to understand than many other kernel projects.

[Bedňa]

Preklep multi-sever = multi-server

[Jakub Lucký]

Jako velkou výhodu vidím fakt, že jeho jméno je vzájemně/dvojitě rekurzivní akronym, jako spornou (ne)výhodu se označuje mikrojádro

a když ještě tak 30 let vydržíš, tak vyjde... ;)

[Grunt]

Příloha:

• hurd_color.pdf (404841 bytů)

To je vtip? Když si vzpomenu jaký humbuk dělal Microsoft kolem Singularity. No a toto je podobný princip. Mikrojádro, servery a komunikace mezi nimi pomocí kontrolované IPC. Ale vsadím se, že dokud dokuď se s tím zase nedobelhá Microsoft(dokud zase Bill Gates nevmyslí sto let používaný inovátorský způsob používání jader), tak zůstanou Mikrojádra tam kde jsou (Mac nepočítám). Do přílohy jsem přibalil takový menší (a trošičku starší) přehled.

[Ondrej 'SanTiago' Zajicek]

Ne, mikrojadro je uplne jiny koncept, nez koncept trusted compiler (tedy ten, ktery po mnoha letech oprasil Microsoft se Singularity).

[Grunt]

Jo? Je to možné. Já to četl v CHIPu se nad tím rozplývat nějakého Němce. Dokonce se nestyděl tam udělat právě tu sedmikrásku a popisovat IPC, tak jsem nabyl dojmu, že to ani nic jiného než mikrojádro být nemůže.

[Ondrej 'SanTiago' Zajicek]

Co jsem o tom cetl, tak Singularity je zalozene na principu, ze pri duveryhodnem prekladaci neni treba vyuzivat hardwarovou ochranu pameti, nebot ochrana pameti je zajistena semantikou jazyka a staticky prekladacem. V takovem pripade odpada klasicke rozdeleni jadro-program.

[zz9]

pekne, nemel by jste to i v cestine?

[Grunt]

V češtině jsem nic moc asi krom jejich stránek nenašel. Ale anglicky jsou dostupné i různé záznamy z přednášek, konferencí, atd.

[pht]

Vysvětlí mi někdo, jakou výhodu má Hurd oproti Linuxu, BSD atp.

Hurd je mikrojádro. Linux je monolitické jádro. Mikrojádro je designově mnohem robustnější, protože v privilegovaném režimu procesoru běží jen velmi malý základ (u kterého se v některých případech dá ověřit bezchybnost matematickým důkazem) a zbytek OS, jako např. ovladače na disk, souborový systém, síť, ... běží jako nezávislé procesy. Naproti tomu v monolitickém jádře (linuxu) je tohle všechno součástí toho jednoho privilegovaného jádra. Pokud v Linuxu havaruje ovladač grafické karty, dojde k pádu celého systému a musíte restartovat počítač, pokud havaruje grafická karta coby proces v mikrojádru, stačí restartovat ten ovladač.

[vlastikroot]

Pokud v Linuxu havaruje ovladač grafické karty, dojde k pádu celého systému a musíte restartovat počítač, pokud havaruje grafická karta coby proces v mikrojádru, stačí restartovat ten ovladač.

No ono to je spíš tak že grafika z neznámých příčin nejde (zmrzne, nezobrazuje co má, v intel driverech už je dokonce detekce zmrznutí GPU), ale zbytek systému vesele běží dál. Pokud tam teda není nějaká brutální chyba, nebo prasecká realizace. Stačí reload toho modulu. Mi přijde stejné jako u toho mikrojádra, když máme moduly.

Nějak jsem asi nepochápal k čemu to mikrojádro je. x86 architektura je tak skoro navržená že kernel v ring0 a zbytek v ring3, obsluha page faultu atd. Moc se nestává, že by linux zmrz (spíš hodí oops a člověk si toho snad ani nevšimne) a pochybuju, že by to hurd vydržel (nečekaná reakce HW, reversované drivery, binární sračky).

[majvan]

ja by som to videl takto: v principe je zakladny rozdiel v tom, ze mame oddelene pamatove priestory, cize odpada mnoho problemov spojenych so zlym adresovanim. Samozrejme, mnoho inych problemov zostava.

[vlastikroot]

No mě je jasný, že mají oddělenou paměť. Ale pokud se programátor toho ovladače v linuxu trochu snaží, tak se špatný adresování taky nestane. A IMHO většina driverů v linuxu na tom neni uplně zle.

[Drašar]

Linux a jine systemy pouzivajici monoliticke jadro dost omezuji svobodu uzivatele. U techto systemu si uzivatel tezko muze napsat a pouzivat vlastni ovladac napr. souboroveho systemu bez prav roota. Existuji sice ruzne berlicky typu FUSE, nicmene zavedeni FUSE ovladace muze opet jenom root, coz je zase jiste omezeni.

Vyhodou koncepce HURDu je zejmena to, ze uzivatel muze prakticky cokoliv bez vyssich privilegii a zaroven nemuze ohrozit beh systemu. Toho je dosazeno izolaci jednotlivych procesu (ovladacu, ...), nicmene je zde potreba nejak efektivne vyresit meziprocesovou komunikaci, kvuli ktere se porad resi vhodne mikrojadro.

[Roger]

Prave ze to vydrzi - dokonce jsem videl nejake grafy, kde ukazovali, jak klesa vykon pri X restartech ovladace (treba sitovky) za sekundu. Zadni kernelovi panici ani podobne veci (resp. pravdepodobnost je mnohem mensi, protoze privilegovaneho kodu je minimum), binarni ovladace vam nemohou hrabat do jadra atp.

Proste jen same vyhody a socialni jistoty :)

[vlastikroot]

Jenže u tý grafiky ten driver ani nepozná, že se nic nezobrazuje. Všecko jde jak má. A driver by prostě padat neměl, opravdu bych nechtěl driver kterej když selže inicializace karty hned to jde skusit znovu Mě přijde že to je jen snaha odložit opravu kódu s tim, že to přece funguje, tak proč to patchovat. To už by bylo lepší udělat na kernel.org seznam shit HW kde by se vypsalo co zaručeně nepoužívat, pokud člověk chce stabilní systém

[Josef Kufner]

A driver by prostě padat neměl

To je ale jen přání a navždy to přání bude. Žádný kus software není dokonalý a nikdy nebude. Takže pokud je možné chránit sw před chybama jiného sw, tak by se toho mělo využít.

Zrovna předevčírem jsem zjišťoval proč mi umírá systém s KMS při zhasnutí displeje. Kdyby to nebyl monolit, tak bych si alespoň mohl přečíst log...

[Grunt]

Zrovna předevčírem jsem zjišťoval proč mi umírá systém s KMS při zhasnutí displeje. Kdyby to nebyl monolit, tak bych si alespoň mohl přečíst log...

To lze všelijakými obezličkami obejít, ale jinak souhlasím.

[Josef Kufner]

Nejjednodušší obezličkou je KMS vypnout

[ch-in-A]

nez jsem prisel ze je to kms, tak pomahalo uspani a probuzeni.

[Bedňa]

Žádný kus software není dokonalý a nikdy nebude.

Toto nieje pravda, väčšinou je práve problém s HW tým že sa driverov pridávajú rôzne hacky aby to chodilo aj na nespolahlivom HW, tak potom to občas ide, občas nie.
Podľa mňa je ideálne keď sa o to aby sa neprepísala alokovaná časť pamäte iným procesom, alebo nevytuhlo jadro na interuptoch má starať HW, čo myslím zatiaľ napr. x86 nezaisťuje. Myšlienka multi-serverového systému je super, ale po drobných zmenách v jadre a vylepšení ochrany procesov od výrobcov HW stratí opodstanenie a pokiaľ nebudú pri HURDe stáť tí najlepší, ako pri Linuxe, tak nemá šancu sa niekde dostať, musel by niečim očariť.

[Josef Kufner]

Žádný kus software není dokonalý a nikdy nebude.

Toto nieje pravda.

Dokaž to.

[bhy]

bych řekl, že nejde takové tvrzení dokázat, ani jeho opak, vzhledem k nedeterminističnosti vesmíru a tak.

[Jakub Lucký]

nešlo by to u extrémně malého software dokázat matematicky (nikoliv dokonalý, ale bezchybný)?

[Amarok]

Dokazal bych to takto: za predpokladu, ze se presne definuje, co se od programu ocekava a program ve vsech pripadech toto splnuje, tak je dokonaly. Jako priklad bych uvedl program head, presne se da definovat, do jake mnoziny spadaji vstupni data a jak se maji zobrazit na vystupu, vse probiha za kazdych okolnosti podle definice (i kdyz se mu preda binarni soubor, jelikoz je vse predem definovane a jsou osetreny vyjimky). Predpokladam, ze nikdo nemuze dokazat opak (jasne ze komplexnejsi programy dokonale pravdepodobne nebudou).

[Bedňa]

Žádný kus software není dokonalý a nikdy nebude.

Toto nieje pravda.

Dokaž to.

Tu je kus kódu

[pht]

Jádro linuxu bohužel není jen o hardware. Jak jsem říkal, je tu také spousta čistě softwarových věcí. Síť, filesystemy, atd. Každá z těch věcí může mít chyby a zhavarovat nebo poskytnout neautorizovaný přístup do systému.

[pht]

Nějak jsem asi nepochápal k čemu to mikrojádro je.

Rozdíl mezi ovladačem v Hurdu a v Linuxu je něco jako rozdíl mezi normálním programem v Linuxu a v DOSu.

[Grunt]

No ono to je spíš tak že grafika z neznámých příčin nejde (zmrzne, nezobrazuje co má, v intel driverech už je dokonce detekce zmrznutí GPU)

Přesně. Např. v Nouveau je inicializační sekvence přímo v binárním kódu pro daný GPU, jenomže ono se spíš stává, že když už vytuhne grafika, tak takovým způsobem, že na nějakou inicializační sekvenci nebo RESET přerušení z vysoka kálí a nezbývá nic jiného než ji odpojit od přívodu elektrické energie.

Mi přijde stejné jako u toho mikrojádra, když máme moduly. Nějak jsem asi nepochápal k čemu to mikrojádro je. x86 architektura je tak skoro navržená že kernel v ring0 a zbytek v ring3, obsluha page faultu atd. Moc se nestává, že by linux zmrz (spíš hodí oops a člověk si toho snad ani nevšimne) a pochybuju, že by to hurd vydržel (nečekaná reakce HW, reversované drivery, binární sračky).

Možná by bylo vhodné dodat, že GNU/Hurd nebyl ani tak koncipován na nějaké desktopové brutality, ale spíše na poklidný chod na serverech (či spíše na tehdejších mainframech). Sám už se degraduje tím jaké ovladače vůbec má (na Desktop spíše něco nemyslitelného, ale vzhledem k množství dostupného HW se ani není co divit), ale třeba pro clustery nabízí úplně nové možnosti využití.

[Ondrej 'SanTiago' Zajicek]

Pokud v Linuxu havaruje ovladač grafické karty, dojde k pádu celého systému a musíte restartovat počítač, pokud havaruje grafická karta coby proces v mikrojádru, stačí restartovat ten ovladač.

Coz je pekna idea, ale v praxi narazi na hromadu problemu:

1) na x86 obvykle neni IOMMU (i kdyz casy se pomalu meni), takze zarizeni jako takove ma pristup k cele pameti. Takze pokud ovladac napr. spatne naprogramuje bus-master transfery z PCI zarizeni, tak muze klidne prepsat libovolnou pamet a shodit tak cely system.

2) ovladac, ktery chybne obsluhuje interrupty, muze snadno zablokovat celou interrupt line a tim zablokovat funkcnost vsem zarizenim, ktere ji sdili. Tady by zase pokrok mohly prinest message signaled interrupts.

3) Zarizeni na PCI muze snadno pri spatnem chovani zablokovat PCI sbernici. Spatne chovani muze byt zpusobeno chybou ovladace. V takovem pripade proste pocitac zatuhne. Zde mozna (nevim) pomuze PCIexpress.

[pht]

To je omezení (některého) HW. Spousta HW tím netrpí, a spousta kusů jádra ani nepracuje přímo s HW (VFS, síťový stack, ...)

[Ondrej 'SanTiago' Zajicek]

To je omezení (některého) HW. Spousta HW tím netrpí,

Asi treba drivery USB zarizeni tim netrpi, ale body 1)-3) trpi prevazna vetsina netrivialnich PCI zarizeni (a nejspis i PCIe).

[kuly]

Řešíte hlouposti, prostě to ještě nikdo nedotáhl do uspokojivě použitelného stavu, a ještě dlouho to tak bude - zvláště v případě Hurdu. Tečka.

[R]

USB komunikacia je tiez netrivialna zalezitost. Jedna chyba v USB driveri a cely USB stack zblbne (v Linuxe mam osobne vyskusane). Toto mikrokernel nevyriesi - bude to sice samotny proces, ale zblbne to rovnako.

[Josef Kufner]

A pokud je root připojený na usb disku, máme problém...

[pht]

USB ovladač a stack budou pravděpodobně 2 procesy, takže pokud to není systematická chyba USB, tak to mikrokernel vyřeší.

[zajca]

A jak to teda dopadlo s tím, že je Mach zastaralý apd... #nějak jsem se v tom ztratil
Port na L4 se nepodařil tak se budou mrvit v Machu?!
nebo jak to je?

[Grunt]

Yup. Mach už není moc v kurzu a oficiálně je jiné jádro Work in Progress. Ale to už je několik roků. Bohužel to nikoho moc nezajímá. Teda pokud se něco nezměnilo.

[Drašar]

Jestli si dobre vzpominam, tak problemem Machu je velice pomala IPC, nicmene vse ostatni funguje obstojne. Proto je zatim bran jako "default" u-kernel, dokud se nenajde/neimplementuje nic lepsiho.

[dayvee]

Arch Hurd ? Arch (has been) hurt!

[Martingt89]

Podla toho co tu pisete mi vychadza ze je to krok v pred. Avsak by ma zaujimalo ked uz dostanu jadro do pouzitelneho stavu, ako je to s kompatibilitou ovladacov pre linux a hurd? Myslim budu ich upravovat ci nanovo pisat? A do akeho segmentu smeruje toto jadro?

[pozortucnak]

A co AmigaOS? To je monolit nebo mikrojadro?

[AnachronyX]

Poslední verze 4.x je označována jako mikrojádro.

[kraven]

navrhujem FreeDOS + Arch = ArchDos :)

[Amarok]

Já žasnu. Nejlepší distro kombinované s nejlépe koncipovaným jádrem. Co víc si můžu přát :) Snad mě to nezklame, až to vyzkouším.

[Grunt]

Jen tak mě napadlo, že to vlastně není žádná distribuce, ale pravý stalmanovský GNU systém, že? Jinak už velmi dlouho existuje GNU/Hurd Debian i s instalátorem.

[Petr]

A uz jste ho i zkusil? Ja ano ... :-/

[Grunt]

Bohužel Debian ješte ne. Zatím jen superunprivileged. Zkoušel jsem to, ale nedostal jsem se přes instalaci a jádro instalátoru je stejně jen obyčejný Linux.

[Vykook]

Skoda ze tam nedali spis XNU z Darwina, kdyz uz nic jinyho, tak ma alespon finalni verzi za sebou

[skywaker]

Viete co je na zamyslenie? Ked si clovek porovna ako dlho sa vyvija Hurd a Minix3 ktory sa bol vypusteny len nedavno tak si kladiem otazku preco Minix3 sa vypracoval do takeho stavu ako je teraz a aktivne sa vyvija narozdiel od Hurdu kde vyvojari stale nieco riesia a nevedia vyriesit... odporucam skusit Minix je to o niecom inom. aj ked nie je GNU.

[Jakub Jermář]

Mam takovou teorii, ze je to castecne tim, ze MINIX 3 je koncepcne daleko jednodussi nez Hurd a umi toho daleko mene. Napr. jeste do nedavna nemel strankovanou virtualni pamet. Na rozdil od Hurdu neni delany pro viceprocesory a neumi swap. Co jsem tak koukal, tak moc nepocita s tim, ze by bezel na necem jinem nez x86 a co si pamatuju z Tanenbaumovy prednasky, tak ma staticky alokovane procesy s docela malym limitem. Na druhou stranu vyvojari MINIX 3 evidentne neztraceji cas cekanim na nejakou spasnou myslenku jak naprogramovat dokonaly multiserverovomicrokernelovy system a proste ten svuj system vesele programuji a vylepsuji dal a dal.

[Vykook]

Zkousel jsem naposled 2.0 na tomhle paradnim stroji Byl tam ale jenom chvilicku, uz ale ani nevim proc

[Milan Lajtoš]

Ja dúfam, že Linus v tajnosti pracuje na Linuxe 3, ktorý bude mikrokernel. ;)

[Jakub Lucký]

Personally, I'm not interested in making device drivers look like user-level. They aren't, they shouldn't be, and microkernels are just stupid.

… even if the Hurd didn't depend on Linux code (and as far as I know, it does, but since I think they have their design heads firmly up their *sses anyway with that whole microkernel thing, I've never felt it was worth my time even looking at their code), I don't believe a religiously motivated development community can ever generate as good code except by pure chance.

My personal opinion of Mach is not very high. Frankly, it's a piece of crap. It contains all the design mistakes you can make, and even managed to make up a few of its own.

In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people.

nepochybně

[Jakub Jermář]

To v te anglictine psal nejaky mikrokernelovy panic, ne?

[Jakub Lucký]

jj Linus Torvalds

[Jakub Jermář]

Vzdyt ja vim Akorat jsem si nemohl nerypnout.

[Amarok]

Nevim v jakem roce tohle Linus rikal, ale koncem minuleho roku uznal, ze je Linux/jadro tak nafoukle a nepretrzite roste, ze se obava budoucnosti. Jestli jsem spravne pochopil koncepci mikrokernelu, tak by prave Hurd mel byt proti gigantickemu nafouknuti "imunni", jelikoz jako jadro dokaze zustat pomerne kompaktni.

[Milan Lajtoš]

Preto v tajnosti... Linus v debate s Tannenbaumom tiež povedal, že

"True, linux is monolithic, and I agree that microkernels are nicer."

. Názory jednoznačne mení, čo je dobré.