Historie a současnost

Historie a současnost operačního systému UNIX Aleš Novák, Vítězslav Stříbrný a Pavel Treutner Verze z 23. května 2002

2 Tento dokument může být volně distribuován a tištěn pouze v plném znění a se seznamem autorů.

Obsah 1 Vývoj Unixu 5 1.1 Počátky............................... 5 1.2 Hráči na hřišti............................ 6 2 Současnost Unixu 9 2.1 Standardy Unixu.......................... 9 2.2 Architektura systému........................ 9 2.2.1 Jádro............................ 9 2.2.2 Proces............................ 10 2.2.3 Souborový systém..................... 11 2.2.4 Meziprocesová komunikace................ 13 2.2.5 Uživatel........................... 14 2.2.6 Knihovny.......................... 16 2.2.7 Programátor......................... 16 2.2.8 Sítě............................. 17 2.2.9 Multithreading....................... 17 2.2.10 Paralelizovatelnost..................... 17 2.2.11 Grafický systém...................... 18 2.3 Problémy Unixu........................... 19 2.4 Použití UNIXu........................... 19 2.4.1 Databázový server..................... 19 2.4.2 Webový server....................... 20 2.5 Rozšíření UNIXu.......................... 20 2.5.1 NeXT Step......................... 20 2.5.2 Plan 9............................ 21 2.5.3 Linux............................ 21 2.5.4 NeUnixy.......................... 22 3 Budoucnost UNIXu 23 3.1 Vývoj Unixu............................ 23 3

4 OBSAH

Kapitola 1 Vývoj Unixu 1.1 Počátky Na sklonku roku 1964 byl v Bell Telephone Laboratories ve spolupráci s Massachussets Institute of Technology a General Electric Company zahájen ambiciózní projekt operačního systému Multics. Jeho cílem bylo vytvořit systém, spojující všechny tehdejší představy moderního operačního systému, tedy interaktivní přístup, bezpečná práce více uživatelů najednou prostřednictvím vzdálených terminálů. Pro jeho implementaci byla stanovena následující pravidla: 1. Realizaci systému bude předcházet jeho projekt 2. Všude, kde to bude možné, použít jazyk vyšší úrovně (zvolen byl PL/1) 3. Při realizaci systému použít systém pro interaktivní přístup Ač to byl projekt pokrokový a velkorysý, vznikající systém se ukázal být příliš robustní a težkopádný, nepodařilo se do něj zakomponovat některé funkce a obsahoval chyby. Proto od něj BTL v roce 1969 upustila, nicméně MIT s GE ho dovedly k praktickému použití 1. Mnoho technik použitých poprvé v Multicsu další systémy převzaly, např. hierarchický systém souborů, zabezpečení... V BTL však trojice programátorů Kenneth Thompson, Dennis Ritchie a Brian Kernighan, která pracovala na Multics-u, pocítila potřebu relativně nenáročného, ale především použitelného systému. Ken Thompson načrtl návrh elegantního, jednoduše ovladatelného systému a implementoval ho v assembleru pro minipočítač PDP 7. Ostatní programátoři ho doplňovali, začali ale narážet na omezené hranice možností PDP 7. V roce 1970 pokřtil Kernighan systém na UNIX - na světě byl UNIX V1. Tým požádal o prostředky na nákup výkonnějšího PDP 11, ale žádost byla zamítnuta. Thompson proto použil menší lsti, když nabídl vývoj systému pro automatizovanou kancelář (pro interní potřeby) a finance dostal. Přesto mu nemusíme vyčítat trochu nepoctivé jednání, protože Unix od té doby do dneška disponuje řadou mocných funkcí pro práci s texty. 1 Například ve firmě Honeywell 5

6 KAPITOLA 1. VÝVOJ UNIXU Tehdy nastal čas pro myšlení na přenositelnost. Fakt, že byl celý systém napsán v assembleru pochopitelně implikoval, že přenos na jinou platformu znamenal kompletní přepsání. Thompson přenesl na Unix jazyk Fortran od kterého přešel k novému jazyku, který nazval B. Byl to interpretovaný jazyk ovlivněný jazykem BCPL. Na to navázal Ritchie, který jazyk upravil tak, že byl vhodný ke generování strojového kódu, rozšířil o typy a nazval C. Ten se ukázal (a stále se ukazuje) jako velice vhodný, nebot je při vysoké efektivitě produkovaného kódu plně přenositelný. To byl také důležitý mezník ve vývoji systému, nebot tím byl značně snížen počet řádků, které je nutné přepsat pri přenosu na novou platformu. Napsat jádro operačního systému v něčem jiném než assembleru byl krok kritizovaný ještě deset let poté, ale přinesl sebou mnoho pozitiv. Hlavně díky tomu se UNIX v následujících několika letech rozšířil na mnoho počítačů, zejména na univerzitní půdu. Když se BTL dostaly pod AT&T, uvolnila tato firma jeho kód některým univerzitám a univerzitu v Berkley pověřila přenesením Unixu na počítače VAX 11. Do té doby přímočarý vývojový strom se v tom místě rozdělil a vznikly dvě poměrně odlišné verze: AT&T, ze které s vzniknul System V, a BSD, ze kterého vzniklo mnoho komerčních odnoží (SunOS, ULTRIX, OSF/1, NextStep,... ) a ke standardu přispěl zejména prací se sítí (Berkley Sockets). 1.2 Hráči na hřišti Historie Unixu je natolik dlouhá, že některé jeho implementace už upadly v zapomění, zatímco jiné existují teprve krátce. Nejprve se zmínim o tradičních : AIX firmy IBM, aktuální verze tohoto systému, který nad ostatními vyniká zejména paralelizovatelností, je 4.3.3 Solaris odvozený od z BSD vycházejícího SunOSu firmy Sun Microsystems je tradiční, uživatelsky i programátorsky příjemný Unix HP-UX firmy Hewlett Packard Firma SCO produkuje celou řadu Unixů, původně vycházejících z Xenixu (viz. níže) některé poslední kompatibilní s Linuxem dokonce i binárně Irix od Silicon Graphics, používaný zejména na pracovních stanicích SGI Vedle svého Netware, vyvíjí firma Novell i Unix UNIXware DEC měla svůj Digital Unix (dříve Ultrix), který se po zakoupení firmy Compaqem jmenuje Tru64-Unix Všechny uvedené Unixy byly komerční, budu pokračovat otevřenými. Větev BSD se dělí na OpenBSD, NetBSD a v současné době nejpoužívanější FreeBSD

1.2. HRÁČI NA HŘIŠTI 7 Linux 2, původně dílo jediného programátora, nyní se na jeho vývoji aktivně podílí desítky lidí Snahy Richarda Stallmana o opravdu otevřený GNU operační systém vyústily v Hurd, což je mikrojaderný (jako jádro slouží Mach) systém, jehož asi jediným nedostatkem je (jako u většiny mikrojaderných) je rychlost. Nicméně vzhledem k tomu, že mikrojaderná koncepce je opravdu pokrokovější, možná má svou budoucnost ještě před sebou. A vyčtu i některé Unixy, které se příliš neujaly. Xenix od firem Microsoft a SCO byl ve verzích pro Intel 80286 a Intel 80386 (dokonce i pro i8086, ale to samozřejmě vzhledem k nulovým možnostem ochrany tohoto procesoru nelze považovat za regulérní OS), ale také proto, že firma Microsoft zvolila pro sebe typickou obchodní strategii se neujal. V jeho vývoji později pokračovalo SCO. V mnoha ohledech revoluční NextStep 3, jehož památka přežívá mimo jiné v systému MacOS X 2 viz. 2.5.3 na straně 21 3 viz. 2.5.1

8 KAPITOLA 1. VÝVOJ UNIXU

Kapitola 2 Současnost Unixu 2.1 Standardy Unixu Aby bylo možné zajistit přenositelnost v systému, který zároveň vyvíjí mnoho firem a institucí, jsou velice důležité standardy. Standardy se vzahují na volání jádra, systémové knihovny, ale i příkazy. Nejuznávanější standardy jsou SVID (System V Interface Definition) podle System V Release 4 z roku 1990 a standardy POSIX (portable operating system based on UNIX), které popisují operační systém na trochu vyšší úrovni abstrakce 1, takže nemusí jít nutně o Unix. Problém přenosu programů mezi Unixy většinou tkví v tom, že každý překladač C má své specialitky oproti ANSI C, které při portaci na jiný systém (a tím i překladač) zapřičiňují nutnost úpravy kódu. 2.2 Architektura systému Od svého počátku je UNIX koncipován jako makrojaderný systém. Klady tohoto řešení spočívají především v nižší náročnosti a celkově vyšší robustnosti. Objevilo se i několik mikrojaderných Unixů, jako například GNU/Hurd, který se stále vyvíjí, ale makrojaderná koncepce stále výrazně dominuje. 2.2.1 Jádro Při startu systému se (obvykle z bootovacího sektoru) nahraje do paměti zavaděč jádra. Ten nahraje z disku do paměti jádro a předá mu řízení. Jádro pomocí ovladačů obalí hardware počítače a provede spuštění procesu init. Procesy nikdy nepřistupují přímo k hardwaru počítače, ale pouze pomocí relativně úzké množiny unifikovaných volání jádra. Volání jádra dále obsluhují práci se soubory, práci s procesy, meziprocesovou komunikaci a jiné funkce, které si proces nemůže zajistit sám. 1 ;) 9

10 KAPITOLA 2. SOUČASNOST UNIXU 2.2.2 Proces Tímto se dostáváme k důležitému pojmu - pojmu proces. Proces je v UNIXu izolovaná jednotka, která vykonává svou činnost, nenechává se rušit. O každém běžícím procesu udržuje jádro informační strukturu, která obsahuje především: pid - v systému unikátní číslo procesu. Co se týče jeho přidělování si můžeme být jisti pouze tím, že proces init má jedničku ppid - pid rodičovského procesu uid - id uživatele, který proces spouští - vlastníka procesu euid - id efektivního uživatele, tedy uid, které určuje privilegia procesu. Od uid se liší pri použití set-uid souborů nebo pokud si proces (nutně superuživatelský) sám změní identitu seznam otevřených souborů cwd - současný pracovní adresář nice - je hodnota důležitá pro plánovač procesů, říká mu, jak moc (nebo málo) má proces dostávat času k běhu. Pohybuje se od -20 (nejvyšší priorita) po 20 (nejnižší priorita), kdy proces běží pouze pokud už systém opravdu neví co dělat mapa pamět ových regionů určuje, kde v paměti jsou uložené části procesu. Proces sám může žádat o změnu velikosti datového regionu (voláním jádra brk) Volání jádra Se životním cyklem procesu se pojí několik volání jádra: fork je jediným způsobem, jak může vzniknout nový proces. Toto volání vytvoří přesnou kopii volajícího procesu, která se od původního bude lišit pouze návratovou hodnotou funkce fork exec je způsobem, jakým proces provádí program. Zavoláním funkce exec se program nahraje do prostoru procesu a předá se mu vykonávání. Z této funkce není návratu exit provede ukončení procesu. Také z této funkce není návratu wait provede uspání procesu do té doby, než některé z jeho dětí neukončí činnost (tj. neprovede volání exit)

2.2. ARCHITEKTURA SYSTÉMU 11 Pokud například (viz. obrázek 2.1) do příkazové řádky shellu napíšete "vi", provede shell volání jádra fork, čímž se vytvoří ještě jedna přesná kopie původního procesu shellu, která ale vzápětí provede volání exec s parametrem vi, čímž se způsobí provedení programu vi, který něco začne vypisovat na výstup a když dopíše, provede volání exit, kterým skončí. Mezitím rodičovský proces shellu provedl volání wait kterým si zajistil, že se opět začne zpracovávat až když dětský proces skončí. sh exec("vi") vi exit() fork() sh wait() sh Obrázek 2.1: Příklad vykonávání programu 2.2.3 Souborový systém Souborový systém byl od počátku silnou stránkou UNIXu. Cíle jeho návrhu byly zobecnit v něm veškeré prostředky systému (např. periferie počítače) a zajistit zpopravňování přístupu k němu. To se podařilo zavedením užití tzv. i-node (iuzel), což je pojem v UNIXu skoro stejně důležitý jako pojem proces. i-node Je to struktura obsahující všechny informace o souboru, tedy: typ souboru - zda se jedná o obyčejný diskový soubor, nebo (blokový nebo znakový) soubor, adresář, nebo pojmenovaná roura. vlastníka souboru, identifikaci jednak uživatele a jednak skupiny, o obém bude řeč později přístupové práva jsou tvořená třemi skupinami bitů, které vyjadřují práva pro vlastníka souboru, člena vlastnické skupiny a ostatní uživatele systému, každá po třech bitech, které znamenají práva pro čtení, zápis a provádění souboru (v případě adresáře prohledávání). bloky souboru - v případě obyčejného souboru nebo adresáře seznam bloků na disku, ve kterých je obsah souboru 2 velikost souboru v bytech 2 Tak jednoduché to není, ale popisování systému úrovní přímých a nepřímých bloků opravdu není předmětem této práce

12 KAPITOLA 2. SOUČASNOST UNIXU časy poslední modifikace obsahu souboru, poslední modifikace i-uzlu a posledního přístupu k souboru počet odkazů na soubor z adresářové struktury. Pokud je toto číslo rovné nule, může být obsah tohoto souboru odstraněn (a i-node uvolněn) Adresář je tedy reprezentován stejně jako každý jiný soubor a stejně k němu lze i přistupovat, jeho obsah představuje seznam dvojic jméno souboru - číslo jeho i-node. Volání jádra Pro práci se soubory nabízí jádro procesu opět několik volání, zde jsou ta nejzajímavější: open k otevření, popř. i vytvoření souboru close k uzavření otevřeného souboru read k načtení zadaného počtu bytů z otevřeného souboru do paměti write k zápisu zadaného počtu bytů z paměti do souboru mmap pro namapování části souboru do paměti flock pro uzamčení části souboru link vytváří další reprezenaci souboru v adresářové struktuře - jméno a zvyšuje hodnotu položky počet odkazů příslušného i-node unlink jméno maže a počet odkazů snižuje. V případě, že ho sníží na nulu, maže obsah souboru a uvolňuje i-uzel Adresářová struktura a odkazy Jmenná identifikace souboru vychází z hierarchické struktury systému souborů, která je asi docela zřejmá. Na jejím vrcholu stojí adresář /. Ovšem není to tak docela strom, protože odkaz na jeden soubor - resp. i-node (byt třeba jinak pojmenovaný) může být z více adresářů. Každý tento odkaz znamená jednu jednotku v hodnotě položky počet odkazů příslušného i-node. Každému dalšímu odkazu na soubor se zpravidla říká hard link, hard proto, že většina UNIXů nabízí ještě takzvané symbolické linky, což jsou aliasy pro jméno a ne pro i-uzel souboru. Používají se pro odkazy mezi dvěma různými diskovými oddíly, nebo je používají uživatelé, kteří nemají oprávnění vytvářet hardlinky na adresáře. Adresář může sloužit jako tzv. mount point - bod připojení. Do tohoto adresáře lze připojit souborovou strukturu např. z jiného diskového oddílu, ale může to být třeba i vzdálený souborový systém (nejpoužívanější jsou NFS - Net File System, AFS - Andrew filesystem, RFS - Remote File System, GFS - Global File System),

2.2. ARCHITEKTURA SYSTÉMU 13 disketa, nebo něco úplně jiného, jen když pro to jádro obsahuje ovladač. Například informace o procesech jádro mapuje do virtuálního souborového systému proc, který se zpravidla připojuje do /proc. Čímž se dostávám k ustálenému stromu adresářů, který víceméně používají všechny UNIXy. /bin základní programy /dev obsahuje většinou všechny speciální soubory, které se v systému nalézají /etc obsahuje systémové konfigurační soubory /home, /u obsahuje domovské adresáře uživatelů /lib základní systémové knihovny /proc zmiňovaná struktura zprostředkovávající vnitřní informace jádra o procesech. Bohužel není vůbec standardizovaná /root domovský adresář uživatele root /usr/bin obsahuje další programy /usr/include headery pro programy v C /usr/lib další knihovny /tmp adresář pro dočasné soubory 2.2.4 Meziprocesová komunikace V systému, ve kterém každý proces běží ve vlastním adresovém prostoru nezávisle na ostatních, jsou jistě velice důležité prostředky, kterými spolu mohou procesy komunikovat. Ve standardu System V Release 4 je proto několik způsobů. Nejnovější verze standardu POSIX také obsahuje jejich funkční ekvivalenty, které mají ale trochu jinou syntaxi, z mě známých systémů je ale implementuje pouze SunOS. A podle mých zkušeností s nimi není důvod opouštět skoro dvacet let staré volání podle System V. Roura Roura je velmi pohodlným způsobem komunikace mezi procesy zejména pro objem nestrukturovaných dat, použít jí lze ale pouze mezi procesy, které jsou spolu v pˇríbuzenském vztahu.roura zosobňuje heslo Nech at každý program dělá jednu věc, ale dělá jí dobře, které Unix naplňuje 3. Místo toho, aby každý program uměl všechno a jeho chování ovlivňovaly desítky konfiguračních parametrů, docilujeme kýženého cíle spojováním schopností programů. Klasické je třídění, tuto schopnost jistě vyžadujeme od všech programů, které vypisují seznam čehosi. Vypisující program se ale o třídění starat nebude, pokud ho uživatel bude chtít, pˇresmˇeruje jeho výstup přez rouru na vstup programu sort, který umí třídit podle čehokoliv. Procesy jsou bratři, protože jejich otcem je ten, ze kterého je uživatel vyvolal, tedy 3 Takzvaná konkretizace

14 KAPITOLA 2. SOUČASNOST UNIXU třeba shell. Přitom program sám ani neví, jestli jeho výstup jde k uživateli na terminál, do roury, do souboru, nebo třeba přez socket do sítě internet. Signály Signály jsou asi nejstarší, nejprimitivnější, ale také nenahraditelnou cestou IPC (InterProcess Comunication). Každý signál má své číslo. Proces může poslat signál jinému procesu pouze pokud mají stejné uid, nebo pokud má zasílající superuživatelské uid. Proces může signál bud ignorovat, nebo v reakci na jeho příchod vyvolat nějakou akci. Jediný signál, s jehož příchodem proces nic nesvede je SIGKILL (zpravidla má číslo 9). Pokud proces tento signál obdrží, okamžitě končí. Fronta zpráv Fronta zpráv je mnohem sofistikovanější metodou přenosu dat, hodící se pro přenos strukturovaných dat. Každá zpráva má svůj typ, přičemž proces si může (nemusí) vybrat, zprávu jakého typu chce přečíst (a samozřejmě poslat). Zprávy jsou uloženy v paměti jádra. Sdílená pamět Pokud potřebují procesy sdílet určitý úsek paměti fixní velikosti (např. pole nějakých struktur), nabízí se použití sdílené paměti. Název určitě navozuje představu, co by to tak asi mohlo být. Používá se většinou ve spojení se semafory. Semafory Semafory jsou na UNIXu docela často kritizovanou věcí, zejména ze stran ne-unix programátorů, přitom představují pouze implementaci semaforů podle Dijkstrovy práce z roku 1968. Slouží většinou (jak jejich název napovídá) k synchronizace práce více procesů s jedním zdrojem. 2.2.5 Uživatel Unix je multiuživatelský systém. Každý uživatel je zaveden v souboru /etc/passwd 4, kde jsou o něm uloženy následující informace: jméno - jméno uživatele v systému uid - user id, číslo uživatele v systému, kterým je všude identifikován, například ve zmíněné i-node. Uživatel root má uid rovný nule. Zpravidla mají uživatelé mají uid 500 a menší čísla jsou vyhrazena pro speciální uživatele, jako například pro různé daemony atd.. 4 Což je tradiční, pro složitější sít ové systémy se ale používají lepší způsoby, jako je třeba NIS

2.2. ARCHITEKTURA SYSTÉMU 15 gid - group id, číslo uživatelovy skupiny, skupiny jsou uvedené v souboru /etc/group plné jméno uživatele shell který se spustí uživateli, když se úspěšně přihlásí home adresář je domovský adresář uživatele heslo tam bylo dříve, ale ted je tento údaj (z důvodů bezpečnosti) zakryptován uložen v souboru /etc/shadow Přihlašování Uživatel se přihlašuje do systému bud přímo na systémové konzoli (což je případ např. Linuxu na osobním počítači) nebo vzdáleně. Dříve se používaly sériové terminály, což byla jednoduchá zařízení připojená přez sériový kabel. Dnes se používá sít ové připojení, hlavně TCP/IP 5, které umožňuje přihlašování ke vzdálenému počítačí prostřednictvím Internetu. Nejpoužívanější protokoly pro vzdálené přihlašování jsou telnet 6 a relativně bezpečný ssh. Shell Shell je program, který zpracovává příkazy uživatele. Shellů existuje celá řada a uživatel si může vybrat jaký chce (nebo si napsat vlastní). Jmenoval bych klasický bsh - Bourne shell, csh - shell se syntaxí podobnou jazyku C, ksh - Korn shell, bash - Bourne again shell, který je implicitní pro většinu Linuxů (já ho ale používám i na Solarisu), ash - odlehčená verze bashe. Root Root je uživatel, který smí úplně všechno (např. smazat jedním příkazem celý systém), přistupovat k jakýmkoliv souborům, zařízením a k jádru. Tato práva zpravidla nemůže delegovat (existují implementačně závislé pokusy jako např. v Linuxu Sudo). Protože některé systémové procesy tato práva potřebují, musí být spuštěny s právy roota, což ovšem znamená, že musejí být skutečně dobře napsané, aby neumožňovaly obyčejnému uživateli (natož pak někomu zvenčí prostřednictvím sítě) vyvolat nežádoucí akci. Uživatel root je vlastníkem veškerých systémových souborů a je jediný, kdo může zasahovat do konfiguračních souborů. Unix poskytuje výborné možnosti administrace, která spočívá na bedrech uživatele root (resp. těch, kteří znají jeho heslo). Root může nastavit ostatním uživatelům nastavi limit například pro počet procesů apod., aby minimalizovat jejich možnosti zahlcení a následnému zpomalení 5 Transmission Control Protocol / Internet Protocol 6 Který by se měl používat maximálně v rámci malých a bezpečných sítí

16 KAPITOLA 2. SOUČASNOST UNIXU systému. Kromě toho existují různé cesty nastavení plánovače procesů, kterými lze například skupině procesů nastavit pevnou část času procesoru. 2.2.6 Knihovny Dosud jsem zmínil několik nejdůležitějších volání jádra. Těch není mnoho a vzhledem k tomu, že se vývojáři Unixu (narozdíl od jiných) než nějaké přidají zamyslí, jejich počet roste jen pomalu. Neobsluhují nic, co si může proces zajistit vlastní silou. Ovšem volání jádra jsou poměrně syrová. Proto jsou obalena celou řadou knihoven. Asi nejpoužívanější bude standardní vstupní/výstupní knihovna, která obaluje volání jádra open, close, read a write několika desítkami funkcí (přitom zůstává přenositelná). Knihovny jsou k dispozici bud jako staticky, nebo jako dynamicky linkované. 2.2.7 Programátor Programátorovi nabízí Unix širokou škálu možností, počínaje nepřekonatelným textovým editorem vi a konče propracovanou schopností ladit běžící proces. Jazyky Pro Unix existují implementace pro snad všechny myslitelné programovací jazyky (s výjimkou VisualBasicu a C#). Standardní je překladač jazyka C podle různých norem (c89, ansi, k&r). Velmi často bývá zahrnut také překladač Fortranu (i když neznám nikoho, kdo by ho na Unixu ještě používal). C++ se zatím používá mnohem méně než C, není ho třeba, přestože existuje standardní C++ rozhraní pro práci se systémem podle System V, na systémové programování se více hodí C, jeho překladače proto bývají spíše nadstandardním vybavením. Kromě překladače je samozřejmě potřebný i linker s knihovnami a programy pro prácí s binárními soubory (strip, nm, size,...). Současné Unixy umí jak statické, tak dynamické linkování (sdílené knihovny). Výborný je také program make, který slouží k automatizaci procesu sestavování programu. Skriptování Nelze zapomínat na interpretované jazyky. Samotné příkazové shelly mají mnoho možností pro psaní složitých skriptů a jsou takto často používány. Pokud na něco snad nestačí nebo se nehodí, nabízí se k použití například awk (Aho-Weinberger- Kerninghan), což je programovací jazyk na práci s texty. Stejně jako mnoho jiných prostředků v Unixu používá tzv. regulární výrazy, které umožňují vybírat text podle složitých pravidel. Awk je už součástí POSIXu. Standardem se stává také perl, který umožňuje poměrně pohodlné programování, dříve se hojně používal např. jako jazyk pro CGI skripty. Dnes ho již vytlačují modernější, objektově orientované jazyky jako je Python. Samozřejmostí jsou virtuální stroje pro Javu, Smalltalk, různé typy Lispů....

2.2. ARCHITEKTURA SYSTÉMU 17 Ladění Unix nabízí mocný a navíc poměrně jednoduchý způsob ladění programů, kdy je dětský proces laděn svým otcem, alternativně lze ladit i běžící proces. Tyto funkce zajišt uje volání jádra ptrace, keteré uživatel používá prostřednictvím programů jako jsou adb, gdb nebo dbx. Zkoumání příčin pádu programu pomáhá i to, že jádro uloží obsah prostoru procesu, pokud je tento ukončen signálem, který signalizuje kritickou chybu 7. 2.2.8 Sítě Práce se sítěmi je jedna z vyzdvihovaných funkcí Unixu. Je pravdou, že prostředky pro komunikaci s jinými počítačí jsou součástí jádra od počátků jeho vývoje a po dlouhou dobu i protokoly DARPA, které představují nejpoužívanější současný standard. Navíc technologie STREAMS používaná v jádru Unixu umožňuje opravdovou implementaci sedmivrstevného modelu OSI 8. Jakmile je navázáno sít ové spojení, je možné s ním pracovat (jako s tzv. BSD schránkou - socketem) prostřednictvím obyčejných I/O volání jádra (read, write). 2.2.9 Multithreading Multithreading jakožto možnost vykonávání více vláken najednou v rámci jednoho procesu zároveň byl samozřejmě znova objeven poměrně nedávno, nicméně Unixy ho umí už dlouho. Většina implementací používá standardní POSIX vlákna (pthreads). 2.2.10 Paralelizovatelnost Současný uživatel osobního počítače je zvyklý na zvyšování výkonu stroje zvyšováním výkonu jeho komponent. Toto řešení ovšem nebývá vhodné (nebo možné) na velkých výpočetních systémech. Tam se výkon musí zvyšovat paralelizací úloh. O tu se může starat bud vývojář (použitím speciálních knihoven nebo dokonce speciálních jazyků), překladač, nebo hardware stroje. Většinou to ale bývá kombinace těchto řešení. Velice slušná řešení má IBM (SP - Scallable POWER 9 Parallel) a Sun Microsystems. Zmínit je třeba také linuxové clustery. To jsou knihovnami (např. Beowulf) nebo speciálními jádry (Mosix 10 ) vytvářené systémy, poskytující vysoký a škálovatelný výkon spojením obyčejných nebo dokonce zastaralých počítačů. Jeden takový 11 http, sestavený z více než stovky uzlů, mezi nimiž jsou i 486ky, 7 To je známá tajuplná hláška Core dumped 8 Open System Interconnection 9 kde to POWER znamená Performance Optimalization With Enhanced RISC 10 http://www.mosix.org/ 11 http://www.stonesoup.org/

18 KAPITOLA 2. SOUČASNOST UNIXU interpoluje teploty na území celých USA (bohužel nemám příliš představu o složitosti takové operace). 2.2.11 Grafický systém Grafické systémy jsou z nějakého důvodu stále ještě pro uživatele velmi atraktivní. Nejdříve si firmy vyvíjející Unixy vyvíjely i vlastní grafické subsystémy, ale po roce 1984, kdy na byl na MITu zahájen rozsáhlý projekt sít ově transparentního, klient-server okenného systému velmi rychle přešly na něj. Tak se zrodily XWindows X9, v aktuální verzi X11 Release6. Ačkoliv holý Unix je orientovaný především znakově, Unixové stanice často sloužily a slouží jako výkonná DTP či CAD pracoviště. XServer XServer program, který spravuje okna a zprostředkovává interakci s uživatelem. Okno je obdélníkový (s jistou výjimkou extenze shape ) objekt (bez rámečku), který může obsahovat jiná okna, o to co se má do okna vykreslovat se ale XServer nestará. O vznik a práci oken se musí starat klienti. XClient Každý program, který si v XServeru vytváří okna, je XClientem. XClient posílá XServeru požadavky na vznik okna, na vykreslování grafických primitiv (rovná čára, text) do oken a naopak přijímá zprávy od XServeru (např. požadavek, aby překreslil obsah okna, nebo zprávu o akci uživatele). Window Manager Jak jsem napsal, XServer se nestará o nějaké rámečky oken apod. To zajišt uje speciální XClient - Okenní Manažer. Toolkit Grafické funkce XServeru (obalené knihovnou Xlib) jsou velmi syrové, nebylo by únosné, aby s nimi přímo pracoval každý, kdo chce psát X aplikaci, navíc by se pak všechny programy chovaly různě. Proto existují různé, objektové i neobjektové nadstavbové knihovny, které obsluhují prvky jako tlačítka, seznamy, tabulky atd.. První byla zřejmě sada X Athena Widget set, později se používal komerční Motif (který se stal vzorem pro mnoho následovníků), OpenLook od Sunu, v poslední době se začínají prosazovat toolkity vyvinuté pro Linux, jako je Gtk, nebo s C++ spjaté Qt.

2.3. PROBLÉMY UNIXU 19 Sít ová transparence Komunikace mezi XServerem a XClienty může probíhat bud pomocí sdílené paměti, pokud jsou na stejném stroji, nebo přez sít, v čemž spočívá velká síla XWindows. 2.3 Problémy Unixu Bohužel i Unix má své problémy, uvědomme si, že se musí snažit zachovávat i určitou zpětnou kompatibilitu. Za nejhorší bych ale označil respekt, který před ním mnoho lidí má, a který jim brání do něj proniknout. Další nepříjemností se stává osmibitová znaková sada, která brání nativní implementaci národních prostředí. Ideální by bylo kompletně přejít na Unicode, ale to samozřejmě není nikterak lehká záležitost. Také klasický Unixový systém práv už se dá považovat za překonaný, byl navržen s maximálním důrazem na rychlost a nenáročnost na systém. Modularita Unixu ovšem dovoluje v případě potřeby nahradit stávající způsob vylepšeným, aniž by to znamenalo jiné zásahy do zbytku operačního systému. V tomto směru existuje množství funkčních a vyvíjících se projektů, např. LIDS. Stálým problémem operačních systémů je bezpečnost. Narozdíl od jiných, Unix většinou netrápí problémy elementární bezpečnosti, avšak dostatečným problémem se stává udržovat autorizační informace o větším počtu uživatelů. Zde zmíním pouze známý autorizační systém Kerberos, který vznikl v rámci projektu Athena. Největší břímě zodpovědnosti co se bezpečnosti týče leží na administrátorovi systému. Pro schopného roota by neměl být problém zabezpečit systém proti jakémukoliv útoku zvenčí ani zevnitř. 2.4 Použití UNIXu Unix není nikterak nápadný systém, naivnímu uživateli osobního počítače se často dokonce zdá, že žádný Unix už není. To je ovšem naprosto mylná představa, protože existuje mnoho situací, kde může být Unix nahrazen jediným - Unixem. 2.4.1 Databázový server Jedná se zejména o roli serveru v místech, kde operuje velký počet uživatelů zároveň s objemem dat, at už prostřednictvím aplikace pro obyčejný znakový terminál, client-server aplikace, nebo třeba pouze webového klienta. V takových případech se většinou používá databáze od dalšího výrobce (relační jako například Oracle, DB2 a Informix od IBM, Sybase, mysql, PostgreSQL... ). Výhody takového řešení jsou zřejmé: aplikace se udržuje na jednom místě, data jsou aktuální, uživatel není závíslý na jednom konkrétním terminálu, výkon lze (většinou) podle potřeby (např. růst počtu terminálů) zvyšovat.

20 KAPITOLA 2. SOUČASNOST UNIXU 2.4.2 Webový server Role samostatného webového serveru je pro Unix také jako stvořená, jednak pro jeho spolehlivost, jednak pro jeho bezpečnost a jednak pro množství možností skriptování apod.... v neposlední řadě pro jeho relativně nízkou náročnost (jako spolehlivý webový server může sloužit i vyřazená 486ka s Linuxem). A samozřejmě existují i mnohem náročnější aplikační servery 12, které, mají-li být používány větším počtem uživatelů, ani nemá smysl provozovat na méně než dvouprocesorovém stroji s méně než gigabajtem paměti. Pro svoji spolehlivost a výbornou schopnost pracovat v síti se často Unixové stroje používají jako poštovní servery, routery, firewally apod., kdy se defacto využívá jen omezená část služeb systému. Další oblastí vždy také byly pracovní stanice, na kterých se provozovaly náročné speciální aplikace (CAD apod.), ovšem s nárůstem výkonu osobních počítačů už samotný pojem pracovní stanice začíná pomalu kamenět, aplikace které dříve byly výhrazeny pracovním stanicím, se stěhují na osobní počítače. 2.5 Rozšíření UNIXu Standardní UNIX je systém s jádrem obsluhujícím standardní volání jádra podle System V, POSIXu, se standardními konfiguračními soubory a standardními programy, jako například shell, s kompilátorem jazyka C apod.. Ovšem taková představa může vzít za své při pohledu na některé vývojové větve. 2.5.1 NeXT Step V roce 1986 se Steve Jobs rozešel ve zlém se zbytkem vedení Apple Computer a investoval svůj finanční i duševní kapitál do nového projektu - vývoje komfortního, objektově orientovaného operačního systému pro pracovní stanice, schopného provozovat i ty nejnáročnější aplikace. Tak vznikla firma NeXT. Záhy se ukázalo, že neexistuje hardware v cenové kategorii kterou si Jobs představoval, na kterém by nový systém mohl úspěšně pracovat, proto NeXT zahájila i vývoj pracovní stanice NeXTcube, založené na procesoru Motorola MC68030. Systém byl opravdu revoluční, objektový, přitom ale plně kompatibilní s Unixem BSD 4.3, využívající jádra MACH. Jeho standardním programovacím jazykem bylo Objective C (C s prvky Smalltalku), k zobrazování používal Display PostScript Level 2 (který mimo jiné uměl alfa kanál, ano, před deseti lety!). I když však NeXTcube byla vyvinuta přímo pro něj, neposkytovala mu potřebný výkon. Po uvedení její třetí varianty ale dosáhl výkon špičkových osobních počítačů úrovně potřebné pro NeXT Step a zároveň cena pracovní stanice prolomila cenu 10.000 dolarů, proto byl další vývoj hardware u NeXTu zastaven a firma se soustředila pouze na portování systému pro jiné platformy. Bohužel ale systém 12 konkrétně mám na mysli Javovské aplikační servery jako je WebSphere (od IBM) a třeba Tomcat (od ASF)