Kodovani P°edchozφ Nßsledujφcφ Obsah
Hurd je jßdro operaΦnφho systΘmy podobn∞ jako Linux. Je podporovßn p°φmo Richardem Stallmanem a m∞l by b²t ten prav² GNU operaΦnφ systΘm. Narozdφl od Linuxu se nedr╛φ p°esn∞ nßvrhu UNIXu a mß pon∞kud modern∞j╣φ nßvrh. Jeho prvnφ pou╛itelnΘ verze u╛ existujφ, ale nepat°φ zatφm k nejstabiln∞j╣φm ani k nejrychlej╣φm.
V Φem je tedy tak nov²? Genialita UNIXu spoΦφvala v tom, ╛e jßdro bylo relativn∞ malΘ a jednoduchΘ a tak na n∞m nenφ moc v∞cφ, kterΘ by zastaraly. Hurd to ale dovßdφ je╣t∞ dßl. Pou╛φvß tzv. mikrojßdro Mach. To je jßdro, kterΘ u╛ neumφ skoro nic mimo memory managementu, multitaskingu a jednoduchΘ komunikace mezi procesy. Nap°φklad prßce se sφtφ, nebo diskem u╛ nenφ zßle╛itost jßdra. Toto jßdro pou╛φvajφ i jinΘ systΘmy (jako t°eba NeXtStep). Ty ale fungujφ tak, ╛e majφ monolitickΘ makrojßdro jako jeden z proces∙. V Hurdu u╛ ╛ßdnΘ makrojßdro neexistuje. O v╣echno se starajφ specißlnφ servery. To jsou samostatnΘ programy, kterΘ umφ s ostatnφmy komunikovat v urΦitΘm protokolu. Nejd∙le╛it∞j╣φ je authentication server. Ten za°izuje u╛ivatelskß prßva. Kdy╛ se program chce s jin²m serverem spojit, po╛ßdß o to authentication server a ten rozhodne, jestli m∙╛e a potom spojenφ provede. Dal╣φ d∙le╛it² server za°izuje spou╣t∞nφ program∙. Proto╛e Hurd nemß v podstat∞ ╛ßdnß systΘmovß volßnφ, tedy je tΘm∞° bez API, je mu jedno, jakΘ API emuluje. Standardnφ API je C knihovna, ale m∙╛e se zavΘst i jin² emulßtor, kter² m∙╛e emulovat API t°eba Linuxu nebo jakΘhokoliv jinΘho OS. ZajφmavΘ je, ╛e dφky takovΘ podpo°e r∙zn²ch formßt∙ m∙╛e jako spustiteln² soubor fungovat t°eba program v lispu. Server pro zavßd∞nφ proces∙ potom prost∞ poznß, ╛e se jednß o lispov² soubor a zavede jako emulßtor interpreter lispu. Tφm mizφ rozdφl mezi spustiteln²mi programy, scripty (dßvkami), programy v ostatnφch interpretovan²ch jazycφch nebo t°eba Javov²mi applety.
O filesystΘm se samoz°ejm∞ starß takΘ program. Ten komunikuje v
souborovΘm protokolu. Hurd umo╛≥uje ka╛dΘmu souboru nastavit tzv.
translator. Tedy program, kterΘmu filesystΘmov² server p°edß °φzenφ,
kdy╛ se na n∞j bude p°istupovat. Nap°φklad kdy╛ chci vytvo°it
soubor, kter² funguje jako UNIXovß device - specißlnφ soubor jako com
nebo prn v DOSu , zalo╛φm
normßlnφ soubor a potom jako translator nastavφm vlastnφ server k
hardwarovΘmu za°φzenφ. Ka╛d² u╛ivatel m∙╛e nastavovat translatory
na soubory, kterΘ vlastnφ. Nap°φklad kdy╛ mßm program, kter² funguje
jako filesystΘmov² server pro .zip soubory, a nastavφm jej jako
translator k souboru aa.zip, mohu se potom dφvat do souboru jako
do adresß°e a se zabalen²mi soubory pracovat jako s ka╛d²m jin²m.
JinΘ translßtory potom mohou za°izovat v∞ci jako adresß° /ftp, kde
podadresß° je adresa poΦφtaΦe a za°izuje ftp clienta. Nap°φklad, kdy╛
chci nahrßt soubor 00index ze serveru sunsite.unc.edu napφ╣u n∞co jako:
cp /ftp/sunsite.unc.edu/pub/00index . a v╣e je hotovo. Podobn²
souborov² interface mohou mφt i dal╣φ servery
(TCP/IP, okennφ server apod). Protokoly jsou navr╛eny roz╣i°iteln∞ a tak
je mo╛nΘ dod∞lßvat i dal╣φ slu╛by, ne╛ jsou klasickΘ slu╛by na souborech.
Proto╛e ka╛d² u╛ivatel m∙╛e takovΘ servery startovat a upravovat, m∙╛e p°ed∞lat vlastn∞ cel² operaΦnφ systΘm, ani╛ by tφm ovlivnil ostatnφ. Je celkem hraΦkou psßt takovΘ servery, proto╛e jejich chyby p°i lad∞nφ neohrozφ stabilitu systΘmu a nejsou k tomu t°eba superu╛ivatelskß prßva, jako v UNIXu. Je to prost∞ OS neomezen²ch mo╛nostφ. Hurd je takΘ genißlnφ v tom, ╛e v podstat∞ zru╣il rozdφl mezi knihovnou, programem a jßdrem. Proto╛e programy spolu komunikujφ protokolem, je jim jedno jestli b∞╛φ na jednom stroji nebo na vφce. To znamenß, ╛e Hurd se m∙╛e distribuovat na vφce poΦφtaΦ∙, kde na ka╛d² bude poskytovat n∞jakΘ slu╛by. Navφc to usnad≥uje podporu pro symetrick² multiprocessoring, kterß v makrojßdrech p∙sobφ potφ╛e.
Oproti makrojßdr∙m systΘm∙m tu odpadajφ slo╛itΘ otßzky, jako jestli pat°φ grafika do jßdra. Pokud v makrojßdrovΘm OS nenφ grafika v jßd°e (jako v Linuxu) je nutnΘ, aby systΘm dovolil grafickΘ aplikaci p°φm² p°φstup na hardware, co╛ odporuje jeho filozofii. Takovou v∞c nem∙╛e dovolit aplikaci s prßvy normßlnφho u╛ivatele, proto╛e tφm aplikace m∙╛e zhroutit cel² poΦφtaΦ. Proto v╣echny grafickΘ aplikace musφ mφt superu╛ivatelskß prßva, co╛ ale zase zp∙sobuje nep°φjemnΘ dφry do bezpeΦnosti. V UNIXu se to °e╣φ pomocφ X window. To je grafick² server, kter² za°izuje grafiku za aplikace a proto pot°ebuje prßva pouze on. I toto °e╣enφ ale p°inß╣φ potφ╛e - i X window obΦas obsahuje dφry v bezpeΦnosti, m∙╛e se zhroutit a nechat tak obrazovku v grafickΘm m≤du, nehodφ se p°φli╣ pro aplikace jako jsou poΦφtaΦovΘ hry apod. OpaΦnΘ °e╣enφ - p°idßnφ grafiky do jßdra - zase p°inß╣φ nep°φjemnΘ zv∞t╣enφ jßdra a dal╣φ otßzku, jak komplikovanΘ slu╛by do jßdra dßt - pokud tam zahrneme pouze slu╛bu na zapnutφ grafickΘho modu a namapovßnφ videoram do pam∞ti procesu, znemo╛nφme vyu╛itφ grafick²ch akcelerßtor∙. Druh² extrΘm - zahrnutφ do jßdra celΘho okennφho systΘmu - jsou windows - vznikne neroz╣i°itelnΘ rychle zastarßvajφcφ a velkΘ jßdro.
Na druhou stranu mß mikojßdrov² nßvrh n∞kterΘ problΘmy. Asi nejd∙le╛it∞j╣φ je rychlost. Dob°e napsanΘ makrojßdro je samoz°ejm∞ rychlej╣φ. T∞╛ko se v mikrojßsrov²ch systΘmech implementuje cache. Klasickß cache s pevn∞ danou velikostφ velk² problΘm nenφ, ale takovß cache jako mß Linux je tΘm∞° nemo╛nß. TΘm∞° v╣echno, co jde napsat v mikrojßdrovΘm systΘmu, jde takΘ napsat v makrojad°e. A proto se o Hurdu se vedou nekoneΦnΘ spory mezi RMS a Linusem. Linus je zavil² nep°φtel mikrojßdrov²ch OS a tvrdφ, ╛e to nikdy nebude po°ßdn∞ fungovat. Je pravda, ╛e Hurd nenφ jedin² mikrojßdrov² operaΦnφ systΘm (dal╣φ jsou nap°φklad VSTA, Spring, Plan9) a p°esto nevφm o ╛ßdnΘm, kter² by p°estal b²t experimentßlnφ a stal se b∞╛n∞ pou╛φvan²m.
Dotazy a p°ipomφnky ohledn∞ strßnky posφlejte na hubicka@paru.cas.cz