ˇ Historie a soucasnost ˇ ıho systemu ´ operacn´ UNIX
Aleˇs Nov´ak, V´ıtˇezslav Stˇr´ıbrn´y a Pavel Treutner Verze z 23. kvˇetna 2002
2 ´ a tiˇsten ˇ pouze v plnem ´ znen´ ˇ ı a se seznamem autoru. Tento dokument muˇ ˚ ze b´yt volneˇ distribuovan ˚
Obsah 1
V´yvoj Unixu 1.1 Poˇca´ tky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Hr´acˇ i na hˇriˇsti . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
Souˇcasnost Unixu 2.1 Standardy Unixu . . . . . . . . . . 2.2 Architektura syst´emu . . . . . . . . 2.2.1 J´adro . . . . . . . . . . . . 2.2.2 Proces . . . . . . . . . . . . 2.2.3 Souborov´y syst´em . . . . . 2.2.4 Meziprocesov´a komunikace 2.2.5 Uˇzivatel . . . . . . . . . . . 2.2.6 Knihovny . . . . . . . . . . 2.2.7 Program´ator . . . . . . . . . 2.2.8 S´ıtˇe . . . . . . . . . . . . . 2.2.9 Multithreading . . . . . . . 2.2.10 Paralelizovatelnost . . . . . 2.2.11 Grafick´y syst´em . . . . . . 2.3 Probl´emy Unixu . . . . . . . . . . . 2.4 Pouˇzit´ı UNIXu . . . . . . . . . . . 2.4.1 Datab´azov´y server . . . . . 2.4.2 Webov´y server . . . . . . . 2.5 Rozˇs´ırˇen´ı UNIXu . . . . . . . . . . 2.5.1 NeXT Step . . . . . . . . . 2.5.2 Plan 9 . . . . . . . . . . . . 2.5.3 Linux . . . . . . . . . . . . 2.5.4 NeUnixy . . . . . . . . . .
3
5 5 6
. . . . . . . . . . . . . . . . . . . . . .
9 9 9 9 10 11 13 14 16 16 17 17 17 18 19 19 19 20 20 20 21 21 22
Budoucnost UNIXu 3.1 V´yvoj Unixu . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23 23
3
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
4
OBSAH
Kapitola 1
V´yvoj Unixu 1.1 Poˇca´ tky Na sklonku roku 1964 byl v Bell Telephone Laboratories ve spolupr´aci s Massachussets Institute of Technology a General Electric Company zah´ajen ambici´ozn´ı projekt operaˇcn´ıho syst´emu Multics. Jeho c´ılem bylo vytvoˇrit syst´em, spojuj´ıc´ı vˇsechny tehdejˇs´ı pˇredstavy modern´ıho operaˇcn´ıho syst´emu, tedy interaktivn´ı pˇr´ıstup, bezpeˇcn´a pr´ace v´ıce uˇzivatelu˚ najednou prostˇrednictv´ım vzd´alen´ych termin´al˚u. Pro jeho implementaci byla stanovena n´asleduj´ıc´ı pravidla: 1. Realizaci syst´emu bude pˇredch´azet jeho projekt 2. Vˇsude, kde to bude moˇzn´e, pouˇz´ıt jazyk vyˇssˇ´ı u´ rovnˇe (zvolen byl PL/1) 3. Pˇri realizaci syst´emu pouˇz´ıt syst´em pro interaktivn´ı pˇr´ıstup Aˇc to byl projekt pokrokov´y a velkorys´y, vznikaj´ıc´ı syst´em se uk´azal b´yt pˇr´ıliˇs robustn´ı a teˇzkop´adn´y, nepodaˇrilo se do nˇej zakomponovat nˇekter´e funkce a obsahoval chyby. Proto od nˇej BTL v roce 1969 upustila, nicm´enˇe MIT s GE ho dovedly k praktick´emu pouˇzit´ı1 . Mnoho technik pouˇzit´ych poprv´e v Multicsu dalˇs´ı syst´emy pˇrevzaly, napˇr. hierarchick´y syst´em souboru, ˚ zabezpeˇcen´ı. . . V BTL vˇsak trojice program´atoru˚ Kenneth Thompson, Dennis Ritchie a Brian Kernighan, kter´a pracovala na Multics-u, poc´ıtila potˇrebu relativnˇe nen´aroˇcn´eho, ale pˇredevˇs´ım pouˇziteln´eho syst´emu. Ken Thompson naˇcrtl n´avrh elegantn´ıho, jednoduˇse ovladateln´eho syst´emu a implementoval ho v assembleru pro minipoˇc´ıtaˇc PDP 7. Ostatn´ı program´atoˇri ho doplˇnovali, zaˇcali ale nar´azˇ et na omezen´e hranice moˇznost´ı PDP 7. V roce 1970 pokˇrtil Kernighan syst´em na UNIX - na svˇetˇe byl UNIX V1. T´ym poˇza´ dal o prostˇredky na n´akup v´ykonnˇejˇs´ıho PDP 11, ale zˇ a´ dost byla zam´ıtnuta. Thompson proto pouˇzil menˇs´ı lsti, kdyˇz nab´ıdl v´yvoj syst´emu pro automatizovanou kancel´arˇ (pro intern´ı potˇreby) a finance dostal. Pˇresto mu nemus´ıme vyˇc´ıtat trochu nepoctiv´e jedn´an´ı, protoˇze Unix od t´e doby do dneˇska disponuje rˇadou mocn´ych funkc´ı pro pr´aci s texty. 1 Napˇr´ıklad
ve firmˇe Honeywell
5
´ KAPITOLA 1. VYVOJ UNIXU
6
Tehdy nastal cˇ as pro myˇslen´ı na pˇrenositelnost. Fakt, zˇ e byl cel´y syst´em naps´an v assembleru pochopitelnˇe implikoval, zˇ e pˇrenos na jinou platformu znamenal kompletn´ı pˇreps´an´ı. Thompson pˇrenesl na Unix jazyk Fortran od kter´eho pˇreˇsel k nov´emu jazyku, kter´y nazval B. Byl to interpretovan´y jazyk ovlivnˇen´y jazykem BCPL. Na to nav´azal Ritchie, kter´y jazyk upravil tak, zˇ e byl vhodn´y ke generov´an´ı strojov´eho k´odu, rozˇs´ırˇil o typy a nazval C. Ten se uk´azal (a st´ale se ukazuje) jako velice vhodn´y, nebot’ je pˇri vysok´e efektivitˇe produkovan´eho k´odu plnˇe pˇrenositeln´y. To byl tak´e d˚uleˇzit´y mezn´ık ve v´yvoji syst´emu, nebot’ t´ım byl znaˇcnˇe sn´ızˇ en poˇcet rˇa´ dk˚u, kter´e je nutn´e pˇrepsat pri pˇrenosu na novou platformu. Napsat j´adro operaˇcn´ıho syst´emu v nˇecˇ em jin´em neˇz assembleru byl krok kritizovan´y jeˇstˇe deset let pot´e, ale pˇrinesl sebou mnoho pozitiv. Hlavnˇe d´ıky tomu se UNIX v n´asleduj´ıc´ıch nˇekolika letech rozˇs´ırˇil na mnoho poˇc´ıtaˇcu, ˚ zejm´ena na univerzitn´ı p˚udu. Kdyˇz se BTL dostaly pod AT&T, uvolnila tato firma jeho k´od nˇekter´ym univerzit´am a univerzitu v Berkley povˇerˇila pˇrenesen´ım Unixu na poˇc´ıtaˇce VAX 11. Do t´e doby pˇr´ımoˇcar´y v´yvojov´y strom se v tom m´ıstˇe rozdˇelil a vznikly dvˇe pomˇernˇe odliˇsn´e verze: AT&T, ze kter´e s vzniknul System V, a BSD, ze kter´eho vzniklo mnoho komerˇcn´ıch odnoˇz´ı (SunOS, ULTRIX, OSF/1, NextStep, . . . ) a ke standardu pˇrispˇel zejm´ena prac´ı se s´ıt´ı (Berkley Sockets).
1.2 Hr´acˇ i na hˇriˇsti Historie Unixu je natolik dlouh´a, zˇ e nˇekter´e jeho implementace uˇz upadly v zapomˇen´ı, zat´ımco jin´e existuj´ı teprve kr´atce. Nejprve se zm´ınim o ”tradiˇcn´ıch”: AIX firmy IBM, aktu´aln´ı verze tohoto syst´emu, kter´y nad ostatn´ımi vynik´a zejm´ena paralelizovatelnost´ı, je 4.3.3 Solaris odvozen´y od z BSD vych´azej´ıc´ıho SunOSu firmy Sun Microsystems je tradiˇcn´ı, uˇzivatelsky i program´atorsky pˇr´ıjemn´y Unix HP-UX firmy Hewlett Packard Firma SCO produkuje celou rˇadu Unix˚u, p˚uvodnˇe vych´azej´ıc´ıch z Xenixu (viz. n´ızˇ e) nˇekter´e posledn´ı kompatibiln´ı s Linuxem dokonce i bin´arnˇe Irix od Silicon Graphics, pouˇz´ıvan´y zejm´ena na pracovn´ıch stanic´ıch SGI Vedle sv´eho Netware, vyv´ıj´ı firma Novell i Unix UNIXware DEC mˇela sv˚uj Digital Unix (dˇr´ıve Ultrix), kter´y se po zakoupen´ı firmy Compaqem jmenuje Tru64-Unix Vˇsechny uveden´e Unixy byly komerˇcn´ı, budu pokraˇcovat otevˇren´ymi. Vˇetev BSD se dˇel´ı na OpenBSD, NetBSD a v souˇcasn´e dobˇe nejpouˇz´ıvanˇejˇs´ı FreeBSD
ˇ NA HRI ˇ ˇ STI 1.2. HRA´ CI
7
Linux2 , p˚uvodnˇe d´ılo jedin´eho program´atora, nyn´ı se na jeho v´yvoji aktivnˇe pod´ıl´ı des´ıtky lid´ı Snahy Richarda Stallmana o opravdu otevˇren´y GNU operaˇcn´ı syst´em vy´ustily v Hurd, coˇz je mikrojadern´y (jako j´adro slouˇz´ı Mach) syst´em, jehoˇz asi jedin´ym nedostatkem je (jako u vˇetˇsiny mikrojadern´ych) je rychlost. Nicm´enˇe vzhledem k tomu, zˇ e mikrojadern´a koncepce je opravdu pokrokovˇejˇs´ı, moˇzn´a m´a svou budoucnost jeˇstˇe pˇred sebou. A vyˇctu i nˇekter´e Unixy, kter´e se pˇr´ıliˇs neujaly. Xenix od firem Microsoft a SCO byl ve verz´ıch pro Intel 80286 a Intel 80386 (dokonce i pro i8086, ale to samozˇrejmˇe vzhledem k nulov´ym moˇznostem ochrany tohoto procesoru nelze povaˇzovat za regul´ern´ı OS), ale tak´e proto, zˇ e firma Microsoft zvolila pro sebe typickou obchodn´ı strategii se neujal. V jeho v´yvoji pozdˇeji pokraˇcovalo SCO. V mnoha ohledech revoluˇcn´ı NextStep 3 , jehoˇz pam´atka pˇreˇz´ıv´a mimo jin´e v syst´emu MacOS X
2 viz. 3 viz.
2.5.3 na stranˇe 21 2.5.1
8
´ KAPITOLA 1. VYVOJ UNIXU
Kapitola 2
Souˇcasnost Unixu 2.1 Standardy Unixu Aby bylo moˇzn´e zajistit pˇrenositelnost v syst´emu, kter´y z´aroveˇn vyv´ıj´ı mnoho firem a instituc´ı, jsou velice d˚uleˇzit´e standardy. Standardy se vzahuj´ı na vol´an´ı j´adra, syst´emov´e knihovny, ale i pˇr´ıkazy. Nejuzn´avanˇejˇs´ı 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´e popisuj´ı operaˇcn´ı syst´em na trochu vyˇssˇ´ı u´ rovni abstrakce 1 , takˇze nemus´ı j´ıt nutnˇe o Unix. Probl´em pˇrenosu programu˚ mezi Unixy vˇetˇsinou tkv´ı v tom, zˇ e kaˇzd´y pˇrekladaˇc C m´a sv´e ”specialitky” oproti ANSI C, kter´e pˇri portaci na jin´y syst´em (a t´ım i pˇrekladaˇc) zapˇriˇciˇnuj´ı nutnost u´ pravy k´odu.
2.2 Architektura syst´emu Od sv´eho poˇca´ tku je UNIX koncipov´an jako makrojadern y´ syst´em. Klady tohoto rˇeˇsen´ı spoˇc´ıvaj´ı pˇredevˇs´ım v niˇzsˇ´ı n´aroˇcnosti a celkovˇe vyˇssˇ´ı robustnosti. Objevilo se i nˇekolik mikrojadern´ych Unix˚u, jako napˇr´ıklad GNU/Hurd, kter´y se st´ale vyv´ıj´ı, ale makrojadern´a koncepce st´ale v´yraznˇe dominuje.
2.2.1 J´adro Pˇri startu syst´emu se (obvykle z bootovac´ıho sektoru) nahraje do pamˇeti zavad eˇ cˇ j´adra. Ten nahraje z disku do pamˇeti j´adro a pˇred´a mu rˇ´ızen´ı. J´adro pomoc´ı ovladaˇcu˚ obal´ı hardware poˇc´ıtaˇce a provede spuˇstˇen´ı procesu init. Procesy nikdy nepˇristupuj´ı pˇr´ımo k hardwaru poˇc´ıtaˇce, ale pouze pomoc´ı relativnˇe u´ zk´e mnoˇziny unifikovan´ych vol´an´ı j´adra. Vol´an´ı j´adra d´ale obsluhuj´ı pr´aci se soubory, pr´aci s procesy, meziprocesovou komunikaci a jin´e funkce, kter´e si proces nem˚uzˇ e zajistit s´am. 1 ;)
9
ˇ KAPITOLA 2. SOUCASNOST UNIXU
10
2.2.2 Proces T´ımto se dost´av´ame k d˚uleˇzit´emu pojmu - pojmu proces. Proces je v UNIXu izolovan´a jednotka, kter´a vykon´av´a svou cˇ innost, nenech´av´a se ruˇsit. O kaˇzd´em bˇezˇ´ıc´ım procesu udrˇzuje j´adro informaˇcn´ı strukturu, kter´a obsahuje pˇredevˇs´ım: pid - v syst´emu unik´atn´ı cˇ´ıslo procesu. Co se t´ycˇ e jeho pˇridˇelov´an´ı si m˚uzˇ eme b´yt jisti pouze t´ım, zˇ e proces init m´a jedniˇcku ppid - pid rodiˇcovsk´eho procesu uid - id uˇzivatele, kter´y proces spouˇst´ı - vlastn´ıka procesu euid - id efektivn´ıho uˇzivatele, tedy uid, kter´e urˇcuje privilegia procesu. Od uid se liˇs´ı pri pouˇzit´ı set-uid souboru˚ nebo pokud si proces (nutnˇe superuˇzivatelsk´y) s´am zmˇen´ı identitu seznam otevˇren´ych souboru˚ cwd - souˇcasn´y pracovn´ı adres´arˇ nice - je hodnota d˚uleˇzit´a pro pl´anovaˇc procesu, ˚ rˇ´ık´a mu, jak moc (nebo m´alo) m´a proces dost´avat cˇ asu k bˇehu. Pohybuje se od -20 (nejvyˇssˇ´ı priorita) po 20 (nejniˇzsˇ´ı priorita), kdy proces bˇezˇ´ı pouze pokud uˇz syst´em opravdu nev´ı co dˇelat mapa pamˇet’ov´ych regionu˚ urˇcuje, kde v pamˇeti jsou uloˇzen´e cˇ a´ sti procesu. Proces s´am m˚uzˇ e zˇ a´ dat o zmˇenu velikosti datov´eho regionu (vol´an´ım j´adra brk) Vol´an´ı j´adra Se zˇ ivotn´ım cyklem procesu se poj´ı nˇekolik vol´an´ı j´adra: fork je jedin´ym zp˚usobem, jak m˚uzˇ e vzniknout nov´y proces. Toto vol´an´ı vytvoˇr´ı pˇresnou kopii volaj´ıc´ıho procesu, kter´a se od p˚uvodn´ıho bude liˇsit pouze n´avratovou hodnotou funkce fork exec je zp˚usobem, jak´ym proces prov´ad´ı program. Zavol´an´ım funkce exec se program nahraje do prostoru procesu a pˇred´a se mu vykon´av´an´ı. Z t´eto funkce nen´ı n´avratu exit provede ukonˇcen´ı procesu. Tak´e z t´eto funkce nen´ı n´avratu wait provede usp´an´ı procesu do t´e doby, neˇz nˇekter´e z jeho dˇet´ı neukonˇc´ı cˇ innost (tj. neprovede vol´an´ı exit)
´ 2.2. ARCHITEKTURA SYSTEMU
11
Pokud napˇr´ıklad (viz. obr´azek 2.1) do pˇr´ıkazov´e rˇa´ dky shellu nap´ısˇete "vi", provede shell vol´an´ı j´adra fork, cˇ´ımˇz se vytvoˇr´ı jeˇstˇe jedna pˇresn´a kopie p˚uvodn´ıho procesu shellu, kter´a ale vz´apˇet´ı provede vol´an´ı exec s parametrem ”vi”, cˇ´ımˇz se zp˚usob´ı proveden´ı programu ”vi”, kter´y nˇeco zaˇcne vypisovat na v´ystup a kdyˇz dop´ısˇe, provede vol´an´ı exit, kter´ym skonˇc´ı. Mezit´ım rodiˇcovsk´y proces shellu provedl vol´an´ı wait kter´ym si zajistil, zˇ e se opˇet zaˇcne zpracov´avat aˇz kdyˇz dˇetsk´y proces skonˇc´ı.
sh
exec("vi")
vi
exit()
fork() sh
wait()
sh
Obr´azek 2.1: Pˇr´ıklad vykon´av´an´ı programu
2.2.3 Souborov´y syst´em Souborov´y syst´em byl od poˇca´ tku silnou str´ankou UNIXu. C´ıle jeho n´avrhu byly zobecnit v nˇem veˇsker´e prostˇredky syst´emu (napˇr. periferie poˇc´ıtaˇce) a zajistit zpopravˇnov´an´ı pˇr´ıstupu k nˇemu. To se podaˇrilo zaveden´ım uˇzit´ı tzv. i-node (iuzel), coˇz je pojem v UNIXu skoro stejnˇe d˚uleˇzit´y jako pojem ”proces”. i-node Je to struktura obsahuj´ıc´ı vˇsechny informace o souboru, tedy: typ souboru - zda se jedn´a o obyˇcejn´y diskov´y soubor, nebo (blokov´y nebo znakov´y) soubor, adres´arˇ, nebo pojmenovan a´ roura. vlastn´ıka souboru, identifikaci jednak uˇzivatele a jednak skupiny, o ob´em bude rˇeˇc pozdˇeji pˇr´ıstupov´e pr´ava jsou tvoˇren´a tˇremi skupinami bit˚u, kter´e vyjadˇruj´ı pr´ava pro vlastn´ıka souboru, cˇ lena vlastnick´e skupiny a ostatn´ı uˇzivatele syst´emu, kaˇzd´a po tˇrech bitech, kter´e znamenaj´ı pr´ava pro cˇ ten´ı, z´apis a prov´adˇen´ı souboru (v pˇr´ıpadˇe adres´arˇe prohled´av´an´ı). bloky souboru - v pˇr´ıpadˇe obyˇcejn´eho souboru nebo adres´arˇe seznam bloku˚ na disku, ve kter´ych je obsah souboru 2 velikost souboru v bytech 2 Tak
jednoduch´e to nen´ı, ale popisov´an´ı syst´emu u´ rovn´ı pˇr´ım´ych a nepˇr´ım´ych blok˚u opravdu nen´ı pˇredmˇetem t´eto pr´ace
ˇ KAPITOLA 2. SOUCASNOST UNIXU
12
cˇ asy posledn´ı modifikace obsahu souboru, posledn´ı modifikace i-uzlu a posledn´ıho pˇr´ıstupu k souboru poˇcet odkazu˚ na soubor z adres´arˇov´e struktury. Pokud je toto cˇ´ıslo rovn´e nule, m˚uzˇ e b´yt obsah tohoto souboru odstranˇen (a i-node uvolnˇen) Adres´arˇ je tedy reprezentov´an stejnˇe jako kaˇzd´y jin´y soubor a stejnˇe k nˇemu lze i pˇristupovat, jeho obsah pˇredstavuje seznam dvojic jm´eno souboru - cˇ´ıslo jeho i-node. Vol´an´ı j´adra Pro pr´aci se soubory nab´ız´ı j´adro procesu opˇet nˇekolik vol´an´ı, zde jsou ta nejzaj´ımavˇejˇs´ı: open k otevˇren´ı, popˇr. i vytvoˇren´ı souboru close k uzavˇren´ı otevˇren´eho souboru read k naˇcten´ı zadan´eho poˇctu byt˚u z otevˇren´eho souboru do pamˇeti write k z´apisu zadan´eho poˇctu byt˚u z pamˇeti do souboru mmap pro namapov´an´ı cˇ a´ sti souboru do pamˇeti flock pro uzamˇcen´ı cˇ a´ sti souboru link vytv´arˇ´ı dalˇs´ı reprezenaci souboru v adres´arˇov´e struktuˇre - jm´eno a zvyˇsuje hodnotu poloˇzky ”poˇcet odkazu” ˚ pˇr´ısluˇsn´eho i-node unlink jm´eno maˇze a ”poˇcet odkaz˚u” sniˇzuje. V pˇr´ıpadˇe, zˇ e ho sn´ızˇ´ı na nulu, maˇze obsah souboru a uvolˇnuje i-uzel Adres´arˇ ov´a struktura a odkazy Jmenn´a identifikace souboru vych´az´ı z hierarchick´e struktury syst´emu souboru, ˚ kter´a je asi docela zˇrejm´a. Na jej´ım vrcholu stoj´ı adres´arˇ ‘/’. Ovˇsem nen´ı to tak docela strom, protoˇze odkaz na jeden soubor - resp. i-node (byt’ tˇreba jinak pojmenovan´y) m˚uzˇ e b´yt z v´ıce adres´arˇu. ˚ Kaˇzd´y tento odkaz znamen´a jednu jednotku v hodnotˇe poloˇzky ”poˇcet odkazu” ˚ pˇr´ısluˇsn´eho i-node. Kaˇzd´emu dalˇs´ımu odkazu na soubor se zpravidla rˇ´ık´a hard link, hard proto, zˇ e vˇetˇsina UNIX˚u nab´ız´ı jeˇstˇe takzvan´e symbolick´e linky, coˇz jsou aliasy pro jm´eno a ne pro i-uzel souboru. Pouˇz´ıvaj´ı se pro odkazy mezi dvˇema r˚uzn´ymi diskov´ymi odd´ıly, nebo je pouˇz´ıvaj´ı uˇzivatel´e, kteˇr´ı nemaj´ı opr´avnˇen´ı vytv´arˇet hardlinky na adres´arˇe. Adres´arˇ m˚uzˇ e slouˇzit jako tzv. mount point - bod pˇripojen´ı. Do tohoto adres´arˇe lze pˇripojit souborovou strukturu napˇr. z jin´eho diskov´eho odd´ılu, ale m˚uzˇ e to b´yt tˇreba i vzd´alen´y souborov´y syst´em (nejpouˇz´ıvanˇejˇs´ı jsou NFS - Net File System, AFS - Andrew filesystem, RFS - Remote File System, GFS - Global File System),
´ 2.2. ARCHITEKTURA SYSTEMU
13
disketa, nebo nˇeco u´ plnˇe jin´eho, jen kdyˇz pro to j´adro obsahuje ovladaˇc. Napˇr´ıklad informace o procesech j´adro mapuje do virtu´aln´ıho souborov´eho syst´emu ”proc”, kter´y se zpravidla pˇripojuje do /proc. ˇ ımˇz se dost´av´am k ust´alen´emu stromu adres´arˇu, C´ ˚ kter´y v´ıcem´enˇe pouˇz´ıvaj´ı vˇsechny UNIXy. /bin – z´akladn´ı programy /dev – obsahuje vˇetˇsinou vˇsechny speci´aln´ı soubory, kter´e se v syst´emu nal´ezaj´ı /etc – obsahuje syst´emov´e konfiguraˇcn´ı soubory /home, /u – obsahuje domovsk´e adres´arˇe uˇzivatelu˚ /lib – z´akladn´ı syst´emov´e knihovny /proc – zmiˇnovan´a struktura zprostˇredkov´avaj´ıc´ı vnitˇrn´ı informace j´adra o procesech. Bohuˇzel nen´ı v˚ubec standardizovan´a /root – domovsk´y adres´arˇ uˇzivatele root /usr/bin – obsahuje dalˇs´ı programy /usr/include – headery pro programy v C /usr/lib – dalˇs´ı knihovny /tmp – adres´arˇ pro doˇcasn´e soubory
2.2.4 Meziprocesov´a komunikace V syst´emu, ve kter´em kaˇzd´y proces bˇezˇ´ı ve vlastn´ım adresov´em prostoru nez´avisle na ostatn´ıch, jsou jistˇe velice d˚uleˇzit´e prostˇredky, kter´ymi spolu mohou procesy komunikovat. Ve standardu System V Release 4 je proto nˇekolik zp˚usobu. ˚ Nejnovˇejˇs´ı verze standardu POSIX tak´e obsahuje jejich funkˇcn´ı ekvivalenty, kter´e maj´ı ale trochu jinou syntaxi, z mˇe zn´am´ych syst´em˚u je ale implementuje pouze SunOS. A podle m´ych zkuˇsenost´ı s nimi nen´ı d˚uvod opouˇstˇet skoro dvacet let star´e vol´an´ı podle System V. Roura Roura je velmi pohodln´ym zp˚usobem komunikace mezi procesy zejm´ena pro objem nestrukturovan´ych dat, pouˇz´ıt j´ı lze ale pouze mezi procesy, kter´e jsou spolu v pˇr´ıbuzensk´em vztahu.Roura zosobˇnuje heslo ”Nech at’ kaˇzd´y program dˇel´a jednu vˇec, ale dˇel´a j´ı dobˇre”, kter´e Unix naplˇnuje 3 . M´ısto toho, aby kaˇzd´y program umˇel vˇsechno a jeho chov´an´ı ovlivˇnovaly des´ıtky konfiguraˇcn´ıch parametr˚u, docilujeme k´yzˇ en´eho c´ıle spojov´an´ım schopnost´ı program˚u. Klasick´e je tˇr´ıdˇen´ı, tuto schopnost jistˇe vyˇzadujeme od vˇsech program˚u, kter´e vypisuj´ı seznam cˇ ehosi. Vypisuj´ıc´ı program se ale o tˇr´ıdˇen´ı starat nebude, pokud ho uˇzivatel bude cht´ıt, pˇresmˇeruje jeho v´ystup pˇrez rouru na vstup programu sort, kter´y um´ı tˇr´ıdit podle cˇ ehokoliv. Procesy jsou bratˇri, protoˇze jejich otcem je ten, ze kter´eho je uˇzivatel vyvolal, tedy 3 Takzvan´a
konkretizace
ˇ KAPITOLA 2. SOUCASNOST UNIXU
14
tˇreba shell. Pˇritom program s´am ani nev´ı, jestli jeho v´ystup jde k uˇzivateli na termin´al, do roury, do souboru, nebo tˇreba pˇrez socket do s´ıtˇe internet. Sign´aly Sign´aly jsou asi nejstarˇs´ı, nejprimitivnˇejˇs´ı, ale tak´e nenahraditelnou cestou IPC (InterProcess Comunication). Kaˇzd´y sign´al m´a sv´e cˇ´ıslo. Proces m˚uzˇ e poslat sign´al jin´emu procesu pouze pokud maj´ı stejn´e uid, nebo pokud m´a zas´ılaj´ıc´ı superuˇzivatelsk´e uid. Proces m˚uzˇ e sign´al bud’ ignorovat, nebo v reakci na jeho pˇr´ıchod vyvolat nˇejakou akci. Jedin´y sign´al, s jehoˇz pˇr´ıchodem proces nic nesvede je SIGKILL (zpravidla m´a cˇ´ıslo 9). Pokud proces tento sign´al obdrˇz´ı, okamˇzitˇe konˇc´ı. Fronta zpr´av Fronta zpr´av je mnohem sofistikovanˇejˇs´ı metodou pˇrenosu dat, hod´ıc´ı se pro pˇrenos strukturovan´ych dat. Kaˇzd´a zpr´ava m´a sv˚uj typ, pˇriˇcemˇz proces si m˚uzˇ e (nemus´ı) vybrat, zpr´avu jak´eho typu chce pˇreˇc´ıst (a samozˇrejmˇe poslat). Zpr´avy jsou uloˇzeny v pamˇeti j´adra. Sd´ılen´a pamˇet’ Pokud potˇrebuj´ı procesy sd´ılet urˇcit´y u´ sek pamˇeti fixn´ı velikosti (napˇr. pole nˇejak´ych struktur), nab´ız´ı se pouˇzit´ı sd´ılen´e pamˇeti. N´azev urˇcitˇe navozuje pˇredstavu, co by to tak asi mohlo b´yt. Pouˇz´ıv´a se vˇetˇsinou ve spojen´ı se semafory. Semafory Semafory jsou na UNIXu docela cˇ asto kritizovanou vˇec´ı, zejm´ena ze stran ne-unix program´atoru, ˚ pˇritom pˇredstavuj´ı pouze implementaci semafor˚u podle Dijkstrovy pr´ace z roku 1968. Slouˇz´ı vˇetˇsinou (jak jejich n´azev napov´ıd´a) k synchronizace pr´ace v´ıce procesu˚ s jedn´ım zdrojem.
2.2.5 Uˇzivatel Unix je multiuˇzivatelsk´y syst´em. Kaˇzd´y uˇzivatel je zaveden v souboru /etc/passwd4 , kde jsou o nˇem uloˇzeny n´asleduj´ıc´ı informace: jm´ eno - jm´eno uˇzivatele v syst´emu uid - user id, cˇ´ıslo uˇzivatele v syst´emu, kter´ym je vˇsude identifikov´an, napˇr´ıklad ve zm´ınˇen´e i-node. Uˇzivatel root m´a uid rovn´y nule. Zpravidla maj´ı uˇzivatel´e maj´ı uid ¿ 500 a menˇs´ı cˇ´ısla jsou vyhrazena pro speci´aln´ı uˇzivatele, jako napˇr´ıklad pro r˚uzn´e daemony atd.. 4 Coˇz
je tradiˇcn´ı, pro sloˇzitˇejˇs´ı s´ıt’ov´e syst´emy se ale pouˇz´ıvaj´ı lepˇs´ı zp˚usoby, jako je tˇreba NIS
´ 2.2. ARCHITEKTURA SYSTEMU
15
gid - group id, cˇ´ıslo uˇzivatelovy skupiny, skupiny jsou uveden´e v souboru /etc/group pln´ e jm´ eno uˇzivatele shell kter´y se spust´ı uˇzivateli, kdyˇz se u´ spˇesˇnˇe pˇrihl´as´ı r je domovsk´y adres´arˇ uˇzivatele aˇ home adres´ heslo tam bylo dˇr´ıve, ale ted’ je tento u´ daj (z d˚uvodu˚ bezpeˇcnosti) zakryptov´an uloˇzen v souboru /etc/shadow Pˇrihlaˇsov´an´ı Uˇzivatel se pˇrihlaˇsuje do syst´emu bud’ pˇr´ımo na syst´emov´e konzoli (coˇz je pˇr´ıpad napˇr. Linuxu na osobn´ım poˇc´ıtaˇci) nebo vzd´alenˇe. Dˇr´ıve se pouˇz´ıvaly s´eriov´e termin´aly, coˇz byla jednoduch´a zaˇr´ızen´ı pˇripojen´a pˇrez s´eriov´y kabel. Dnes se pouˇz´ıv´a s´ıt’ov´e pˇripojen´ı, hlavnˇe TCP/IP5 , kter´e umoˇznˇ uje pˇrihlaˇsov´an´ı ke vzd´alen´emu poˇc´ıtaˇc´ı prostˇrednictv´ım Internetu. Nejpouˇz´ıvanˇejˇs´ı protokoly pro vzd´alen´e pˇrihlaˇsov´an´ı jsou telnet 6 a relativnˇe bezpeˇcn´y ssh. Shell Shell je program, kter´y zpracov´av´a pˇr´ıkazy uˇzivatele. Shell˚u existuje cel´a rˇada a uˇzivatel si m˚uzˇ e vybrat jak´y chce (nebo si napsat vlastn´ı). Jmenoval bych klasick´y bsh - Bourne shell, csh - shell se syntax´ı podobnou jazyku C, ksh - Korn shell, bash - Bourne again shell, kter´y je implicitn´ı pro vˇetˇsinu Linux˚u (j´a ho ale pouˇz´ıv´am i na Solarisu), ash - odlehˇcen´a verze bashe. Root Root je uˇzivatel, kter´y sm´ı u´ plnˇe vˇsechno (napˇr. smazat jedn´ım pˇr´ıkazem cel´y syst´em), pˇristupovat k jak´ymkoliv souborum, ˚ zaˇr´ızen´ım a k j´adru. Tato pr´ava zpravidla nem˚uzˇ e delegovat (existuj´ı implementaˇcnˇe z´avisl´e pokusy jako napˇr. v Linuxu Sudo). Protoˇze nˇekter´e syst´emov´e procesy tato pr´ava potˇrebuj´ı, mus´ı b´yt spuˇstˇeny s pr´avy roota, coˇz ovˇsem znamen´a, zˇ e musej´ı b´yt skuteˇcnˇe dobˇre napsan´e, aby neumoˇznˇ ovaly obyˇcejn´emu uˇzivateli (natoˇz pak nˇekomu zvenˇc´ı prostˇrednictv´ım s´ıtˇe) vyvolat neˇza´ douc´ı akci. Uˇzivatel root je vlastn´ıkem veˇsker´ych syst´emov´ych souboru˚ a je jedin´y, kdo m˚uzˇ e zasahovat do konfiguraˇcn´ıch souboru. ˚ Unix poskytuje v´yborn´e moˇznosti administrace, kter´a spoˇc´ıv´a na bedrech uˇzivatele root (resp. tˇech, kteˇr´ı znaj´ı jeho heslo). Root m˚uzˇ e nastavit ostatn´ım uˇzivatel˚um nastavi limit napˇr´ıklad pro poˇcet proces˚u apod., aby minimalizovat jejich moˇznosti zahlcen´ı a n´asledn´emu zpomalen´ı 5 Transmission 6 Kter´ y
Control Protocol / Internet Protocol by se mˇel pouˇz´ıvat maxim´alnˇe v r´amci mal´ych a bezpeˇcn´ych s´ıt´ı
16
ˇ KAPITOLA 2. SOUCASNOST UNIXU
syst´emu. Kromˇe toho existuj´ı r˚uzn´e cesty nastaven´ı pl´anovaˇce procesu, ˚ kter´ymi lze napˇr´ıklad skupinˇe procesu˚ nastavit pevnou cˇ a´ st cˇ asu procesoru.
2.2.6 Knihovny Dosud jsem zm´ınil nˇekolik nejduleˇ ˚ zitˇejˇs´ıch vol a´ n´ı j´adra. Tˇech nen´ı mnoho a vzhledem k tomu, zˇ e se v´yvoj´arˇi Unixu (narozd´ıl od jin´ych) neˇz nˇejak´e pˇridaj´ı zamysl´ı, jejich poˇcet roste jen pomalu. Neobsluhuj´ı nic, co si m˚uzˇ e proces zajistit vlastn´ı silou. Ovˇsem vol´an´ı j´adra jsou pomˇernˇe ”syrov´a”. Proto jsou obalena celou rˇadou knihoven. Asi nejpouˇz´ıvanˇejˇs´ı bude standardn´ı vstupn´ı/v´ystupn´ı knihovna, kter´a obaluje vol´an´ı j´adra open, close, read a write nˇekolika des´ıtkami funkc´ı (pˇritom z˚ust´av´a pˇrenositeln´a). Knihovny jsou k dispozici bud’ jako staticky, nebo jako dynamicky linkovan´e.
2.2.7 Program´ator Program´atorovi nab´ız´ı Unix sˇ irokou sˇk´alu moˇznost´ı, poˇc´ınaje nepˇrekonateln´ym textov´ym editorem vi a konˇce propracovanou schopnost´ı ladit bˇezˇ´ıc´ı proces. Jazyky Pro Unix existuj´ı implementace pro snad vˇsechny mysliteln´e programovac´ı jazyky (s v´yjimkou VisualBasicu a C#). Standardn´ı je pˇrekladaˇc jazyka C podle r˚uzn´ych norem (c89, ansi, k&r). Velmi cˇ asto b´yv´a zahrnut tak´e pˇrekladaˇc Fortranu (i kdyˇz nezn´am nikoho, kdo by ho na Unixu jeˇstˇe pouˇz´ıval). C++ se zat´ım pouˇz´ıv´a mnohem m´enˇe neˇz C, nen´ı ho tˇreba, pˇrestoˇze existuje standardn´ı C++ rozhran´ı pro pr´aci se syst´emem podle System V, na syst´emov´e programov´an´ı se v´ıce hod´ı C, jeho pˇrekladaˇce proto b´yvaj´ı sp´ısˇe nadstandardn´ım vybaven´ım. Kromˇe pˇrekladaˇce je samozˇrejmˇe potˇrebn´y i linker s knihovnami a programy pro pr´ac´ı s bin´arn´ımi soubory (strip, nm, size, ...). Souˇcasn´e Unixy um´ı jak statick´e, tak dynamick´e linkov´an´ı (sd´ılen´e knihovny). V´yborn´y je tak´e program make, kter´y slouˇz´ı k automatizaci procesu sestavov´an´ı programu. Skriptov´an´ı Nelze zapom´ınat na interpretovan´e jazyky. Samotn´e pˇr´ıkazov´e shelly maj´ı mnoho moˇznost´ı pro psan´ı sloˇzit´ych skript˚u a jsou takto cˇ asto pouˇz´ıv´any. Pokud na nˇeco snad nestaˇc´ı nebo se nehod´ı, nab´ız´ı se k pouˇzit´ı napˇr´ıklad awk (Aho-WeinbergerKerninghan), coˇz je programovac´ı jazyk na pr´aci s texty. Stejnˇe jako mnoho jin´ych prostˇredku˚ v Unixu pouˇz´ıv´a tzv. regul a´ rn´ı v´yrazy, kter´e umoˇznˇ uj´ı vyb´ırat text podle sloˇzit´ych pravidel. Awk je uˇz souˇca´ st´ı POSIXu. Standardem se st´av´a tak´e perl, kter´y umoˇznˇ uje pomˇernˇe pohodln´e programov´an´ı, dˇr´ıve se hojnˇe pouˇz´ıval napˇr. jako jazyk pro CGI skripty. Dnes ho jiˇz vytlaˇcuj´ı modernˇejˇs´ı, objektovˇe orientovan´e jazyky jako je Python. Samozˇrejmost´ı jsou virtu´aln´ı stroje pro Javu, Smalltalk, r˚uzn´e typy Lisp˚u . . . .
´ 2.2. ARCHITEKTURA SYSTEMU
17
Ladˇen´ı Unix nab´ız´ı mocn´y a nav´ıc pomˇernˇe jednoduch´y zp˚usob ladˇen´ı programu, ˚ kdy je dˇetsk´y proces ladˇen sv´ym otcem, alternativnˇe lze ladit i bˇezˇ´ıc´ı proces. Tyto funkce zajiˇst’uje vol´an´ı j´adra ptrace, keter´e uˇzivatel pouˇz´ıv´a prostˇrednictv´ım programu˚ jako jsou adb, gdb nebo dbx. Zkoum´an´ı pˇr´ıcˇ in p´adu programu pom´ah´a i to, zˇ e j´adro uloˇz´ı obsah prostoru procesu, pokud je tento ukonˇcen sign´alem, kter´y signalizuje kritickou chybu7 .
2.2.8 S´ıtˇe Pr´ace se s´ıtˇemi je jedna z vyzdvihovan´ych funkc´ı Unixu. Je pravdou, zˇ e prostˇredky pro komunikaci s jin´ymi poˇc´ıtaˇc´ı jsou souˇca´ st´ı j´adra od poˇca´ tku˚ jeho v´yvoje a po dlouhou dobu i protokoly DARPA, kter´e pˇredstavuj´ı nejpouˇz´ıvanˇejˇs´ı souˇcasn´y standard. Nav´ıc technologie STREAMS pouˇz´ıvan´a v j´adru Unixu umoˇznˇ uje opravdovou implementaci sedmivrstevn´eho modelu OSI 8 . Jakmile je nav´az´ano s´ıt’ov´e spojen´ı, je moˇzn´e s n´ım pracovat (jako s tzv. BSD schr a´ nkou - socketem) prostˇrednictv´ım obyˇcejn´ych I/O vol´an´ı j´adra (read, write).
2.2.9 Multithreading Multithreading jakoˇzto moˇznost vykon´av´an´ı v´ıce vl´aken najednou v r´amci jednoho procesu z´aroveˇn byl samozˇrejmˇe znova ”objeven” pomˇernˇe ned´avno, nicm´enˇe Unixy ho um´ı uˇz dlouho. Vˇetˇsina implementac´ı pouˇz´ıv´a standardn´ı POSIX vl´akna (pthreads).
2.2.10 Paralelizovatelnost Souˇcasn´y uˇzivatel osobn´ıho poˇc´ıtaˇce je zvykl´y na zvyˇsov´an´ı v´ykonu stroje zvyˇsov´an´ım v´ykonu jeho komponent. Toto rˇeˇsen´ı ovˇsem neb´yv´a vhodn´e (nebo moˇzn´e) na velk´ych v´ypoˇcetn´ıch syst´emech. Tam se v´ykon mus´ı zvyˇsovat paralelizac´ı u´ loh. O tu se m˚uzˇ e starat bud’ v´yvoj´arˇ (pouˇzit´ım speci´aln´ıch knihoven nebo dokonce speci´aln´ıch jazyku), ˚ pˇrekladaˇc, nebo hardware stroje. Vˇetˇsinou to ale b´yv´a kombinace tˇechto rˇeˇsen´ı. Velice sluˇsn´a rˇeˇsen´ı m´a IBM (SP - Scallable POWER9 Parallel) a Sun Microsystems. Zm´ınit je tˇreba tak´e linuxov´e clustery. To jsou knihovnami (napˇr. Beowulf) nebo speci´aln´ımi j´adry (Mosix 10 ) vytv´arˇen´e syst´emy, poskytuj´ıc´ı vysok´y a sˇk´alovateln´y v´ykon spojen´ım obyˇcejn´ych nebo dokonce zastaral´ych poˇc´ıtaˇcu. ˚ Je11 den takov´y http, sestaven´y z v´ıce neˇz stovky uzl˚u, mezi nimiˇz jsou i ”486ky”, 7 To
je zn´am´a tajupln´a hl´asˇka ”Core dumped” System Interconnection 9 kde to POWER znamen´a ”Performance Optimalization With Enhanced RISC” 10 http://www.mosix.org/ 11 http://www.stonesoup.org/ 8 Open
18
ˇ KAPITOLA 2. SOUCASNOST UNIXU
interpoluje teploty na u´ zem´ı cel´ych USA (bohuˇzel nem´am pˇr´ıliˇs pˇredstavu o sloˇzitosti takov´e operace).
2.2.11 Grafick´y syst´em Grafick´e syst´emy jsou z nˇejak´eho d˚uvodu st´ale jeˇstˇe pro uˇzivatele velmi atraktivn´ı. Nejdˇr´ıve si firmy vyv´ıjej´ıc´ı Unixy vyv´ıjely i vlastn´ı grafick´e subsyst´emy, ale po roce 1984, kdy na byl na MITu zah´ajen rozs´ahl´y projekt s´ıt’ovˇe transparentn´ıho, klient-server okenn´eho syst´emu velmi rychle pˇreˇsly na nˇej. Tak se zrodily XWindows X9, v aktu´aln´ı verzi ”X11 Release6”. Aˇckoliv hol´y Unix je orientovan´y pˇredevˇs´ım znakovˇe, Unixov´e stanice cˇ asto slouˇzily a slouˇz´ı jako v´ykonn´a DTP cˇ i CAD pracoviˇstˇe. XServer XServer program, kter´y spravuje okna a zprostˇredkov´av´a interakci s uˇzivatelem. Okno je obd´eln´ıkov´y (s jistou v´yjimkou extenze ”shape”) objekt (bez r´ameˇcku), kter´y m˚uzˇ e obsahovat jin´a okna, o to co se m´a do okna vykreslovat se ale XServer nestar´a. O vznik a pr´aci oken se mus´ı starat klienti. XClient Kaˇzd´y program, kter´y si v XServeru vytv´arˇ´ı okna, je XClientem. XClient pos´ıl´a XServeru poˇzadavky na vznik okna, na vykreslov´an´ı grafick´ych primitiv (rovn´a cˇ a´ ra, text) do oken a naopak pˇrij´ım´a zpr´avy od XServeru (napˇr. poˇzadavek, aby pˇrekreslil obsah okna, nebo zpr´avu o akci uˇzivatele). Window Manager Jak jsem napsal, XServer se nestar´a o nˇejak´e r´ameˇcky oken apod. To zajiˇst’uje speci´aln´ı XClient - Okenn´ı Manaˇzer. Toolkit Grafick´e funkce XServeru (obalen´e knihovnou Xlib) jsou velmi ”syrov´e”, nebylo by u´ nosn´e, aby s nimi pˇr´ımo pracoval kaˇzd´y, kdo chce ps´at X aplikaci, nav´ıc by se pak vˇsechny programy chovaly r˚uznˇe. Proto existuj´ı r˚uzn´e, objektov´e i neobjektov´e nadstavbov´e knihovny, kter´e obsluhuj´ı prvky jako tlaˇc´ıtka, seznamy, tabulky atd.. Prvn´ı byla zˇrejmˇe sada X Athena Widget set, pozdˇeji se pouˇz´ıval komerˇcn´ı Motif (kter´y se stal vzorem pro mnoho n´asledovn´ıku), ˚ OpenLook od Sunu, v posledn´ı dobˇe se zaˇc´ınaj´ı prosazovat toolkity vyvinut´e pro Linux, jako je Gtk, nebo s C++ spjat´e Qt.
´ 2.3. PROBLEMY UNIXU
19
S´ıt’ov´a transparence Komunikace mezi XServerem a XClienty m˚uzˇ e prob´ıhat bud’ pomoc´ı sd´ılen´e pamˇeti, pokud jsou na stejn´em stroji, nebo pˇrez s´ıt’, v cˇ emˇz spoˇc´ıv´a velk´a s´ıla XWindows.
2.3 Probl´emy Unixu Bohuˇzel i Unix m´a sv´e probl´emy, uvˇedomme si, zˇ e se mus´ı snaˇzit zachov´avat i urˇcitou zpˇetnou kompatibilitu. Za nejhorˇs´ı bych ale oznaˇcil respekt, kter´y pˇred n´ım mnoho lid´ı m´a, a kter´y jim br´an´ı do nˇej proniknout. Dalˇs´ı nepˇr´ıjemnost´ı se st´av´a osmibitov´a znakov´a sada, kter´a br´an´ı nativn´ı implementaci n´arodn´ıch prostˇred´ı. Ide´aln´ı by bylo kompletnˇe pˇrej´ıt na Unicode, ale to samozˇrejmˇe nen´ı nikterak lehk´a z´aleˇzitost. Tak´e klasick´y Unixov´y syst´em pr´av uˇz se d´a povaˇzovat za pˇrekonan´y, byl navrˇzen s maxim´aln´ım d˚urazem na rychlost a nen´aroˇcnost na syst´em. Modularita Unixu ovˇsem dovoluje v pˇr´ıpadˇe potˇreby nahradit st´avaj´ıc´ı zp˚usob vylepˇsen´ym, aniˇz by to znamenalo jin´e z´asahy do zbytku operaˇcn´ıho syst´emu. V tomto smˇeru existuje mnoˇzstv´ı funkˇcn´ıch a vyv´ıj´ıc´ıch se projektu, ˚ napˇr. LIDS. St´al´ym probl´emem operaˇcn´ıch syst´em˚u je bezpeˇcnost. Narozd´ıl od jin´ych, Unix vˇetˇsinou netr´ap´ı probl´emy element´arn´ı bezpeˇcnosti, avˇsak dostateˇcn´ym probl´emem se st´av´a udrˇzovat autorizaˇcn´ı informace o vˇetˇs´ım poˇctu uˇzivatelu. ˚ Zde zm´ın´ım pouze zn´am´y autorizaˇcn´ı syst´em Kerberos, kter´y vznikl v r´amci projektu Athena. Nejvˇetˇs´ı bˇr´ımˇe zodpovˇednosti co se bezpeˇcnosti t´ycˇ e leˇz´ı na administr´atorovi syst´emu. Pro schopn´eho ”roota” by nemˇel b´yt probl´em zabezpeˇcit syst´em proti jak´emukoliv u´ toku zvenˇc´ı ani zevnitˇr.
2.4 Pouˇzit´ı UNIXu Unix nen´ı nikterak n´apadn´y syst´em, naivn´ımu uˇzivateli osobn´ıho poˇc´ıtaˇce se cˇ asto dokonce zd´a, zˇ e zˇ a´ dn´y Unix uˇz nen´ı. To je ovˇsem naprosto myln´a pˇredstava, protoˇze existuje mnoho situac´ı, kde m˚uzˇ e b´yt Unix nahrazen jedin´ym - Unixem.
2.4.1 Datab´azov´y server Jedn´a se zejm´ena o roli serveru v m´ıstech, kde operuje velk´y poˇcet uˇzivatelu˚ z´aroveˇn s objemem dat, at’ uˇz prostˇrednictv´ım aplikace pro obyˇcejn´y znakov´y termin´al, client-server aplikace, nebo tˇreba pouze webov´eho klienta. V takov´ych pˇr´ıpadech se vˇetˇsinou pouˇz´ıv´a datab´aze od dalˇs´ıho v´yrobce (relaˇcn´ı jako napˇr´ıklad Oracle, DB2 a Informix od IBM, Sybase, mySQL, PostgreSQL. . . ). V´yhody takov´eho rˇeˇsen´ı jsou zˇrejm´e: aplikace se udrˇzuje na jednom m´ıstˇe, data jsou aktu´aln´ı, uˇzivatel nen´ı z´av´ısl´y na jednom konkr´etn´ım termin´alu, v´ykon lze (vˇetˇsinou) podle potˇreby (napˇr. r˚ust poˇctu termin´alu) ˚ zvyˇsovat.
20
ˇ KAPITOLA 2. SOUCASNOST UNIXU
2.4.2 Webov´y server Role samostatn´eho webov´eho serveru je pro Unix tak´e jako stvoˇren´a, jednak pro jeho spolehlivost, jednak pro jeho bezpeˇcnost a jednak pro mnoˇzstv´ı moˇznost´ı skriptov´an´ı apod.. . . v neposledn´ı rˇadˇe pro jeho relativnˇe n´ızkou n´aroˇcnost (jako spolehliv´y webov´y server m˚uzˇ e slouˇzit i “vyˇrazen´a 486ka” s Linuxem). A samozˇrejmˇe existuj´ı i mnohem n´aroˇcnˇejˇs´ı aplikaˇcn´ı servery 12 , kter´e, maj´ı-li b´yt pouˇz´ıv´any vˇetˇs´ım poˇctem uˇzivatelu, ˚ ani nem´a smysl provozovat na m´enˇe neˇz dvouprocesorov´em stroji s m´enˇe neˇz gigabajtem pamˇeti. Pro svoji spolehlivost a v´ybornou schopnost pracovat v s´ıti se cˇ asto Unixov´e stroje pouˇz´ıvaj´ı jako poˇstovn´ı servery, routery, firewally apod., kdy se defacto vyuˇz´ıv´a jen omezen´a cˇ a´ st sluˇzeb syst´emu. Dalˇs´ı oblast´ı vˇzdy tak´e byly pracovn´ı stanice, na kter´ych se provozovaly n´aroˇcn´e speci´aln´ı aplikace (CAD apod.), ovˇsem s n´ar˚ustem v´ykonu osobn´ıch poˇc´ıtaˇcu˚ uˇz samotn´y pojem ”pracovn´ı stanice” zaˇc´ın´a pomalu kamenˇet, aplikace kter´e dˇr´ıve byly v´yhrazeny pracovn´ım stanic´ım, se stˇehuj´ı na osobn´ı poˇc´ıtaˇce.
2.5 Rozˇs´ırˇ en´ı UNIXu ”Standardn´ı UNIX” je syst´em s j´adrem obsluhuj´ıc´ım standardn´ı vol´an´ı j´adra podle System V, POSIXu, se standardn´ımi konfiguraˇcn´ımi soubory a standardn´ımi programy, jako napˇr´ıklad shell, s kompil´atorem jazyka C apod.. Ovˇsem takov´a pˇredstava m˚uzˇ e vz´ıt za sv´e pˇri pohledu na nˇekter´e v´yvojov´e vˇetve.
2.5.1 NeXT Step V roce 1986 se Steve Jobs rozeˇsel ve zl´em se zbytkem veden´ı Apple Computer a investoval sv˚uj finanˇcn´ı i duˇsevn´ı kapit´al do nov´eho projektu - v´yvoje komfortn´ıho, objektovˇe orientovan´eho operaˇcn´ıho syst´emu pro pracovn´ı stanice, schopn´eho provozovat i ty nejn´aroˇcnˇejˇs´ı aplikace. Tak vznikla firma NeXT. Z´ahy se uk´azalo, zˇ e neexistuje hardware v cenov´e kategorii kterou si Jobs pˇredstavoval, na kter´em by nov´y syst´em mohl u´ spˇesˇnˇe pracovat, proto NeXT zah´ajila i v´yvoj pracovn´ı stanice NeXTcube, zaloˇzen´e na procesoru Motorola MC68030. Syst´em byl opravdu ”revoluˇcn´ı”, objektov´y, pˇritom ale plnˇe kompatibiln´ı s Unixem BSD 4.3, vyuˇz´ıvaj´ıc´ı j´adra MACH. Jeho standardn´ım programovac´ım jazykem bylo Objective C (C s prvky Smalltalku), k zobrazov´an´ı pouˇz´ıval Display PostScript Level 2 (kter´y mimo jin´e umˇel alfa kan a´ l, ano, pˇred deseti lety!). I kdyˇz vˇsak NeXTcube byla vyvinuta pˇr´ımo pro nˇej, neposkytovala mu potˇrebn´y v´ykon. Po uveden´ı jej´ı tˇret´ı varianty ale dos´ahl v´ykon sˇ piˇckov´ych osobn´ıch poˇc´ıtaˇcu˚ u´ rovnˇe potˇrebn´e pro NeXT Step a z´aroveˇn cena pracovn´ı stanice prolomila cenu 10.000 dolaru, ˚ proto byl dalˇs´ı v´yvoj hardware u NeXTu zastaven a firma se soustˇredila pouze na portov´an´ı syst´emu pro jin´e platformy. Bohuˇzel ale syst´em 12 konkr´etnˇe m´am na mysli Javovsk´e aplikaˇcn´ı servery jako je WebSphere (od IBM) a tˇreba Tomcat
(od ASF)
ˇ I´ UNIXU 2.5. ROZSˇ I´REN
21
nakonec nemˇel obchodn´ı u´ spˇech, byl pomˇernˇe dost n´akladn´y a na pomˇery osobn´ıch poˇc´ıtaˇcu˚ vyˇzadoval vysoce nadstandardn´ı vy´ykon hardwaru (na svou dobu). Na konci devades´at´ych let se Jobs vr´atil k Apple, kde z´ahy na to uvedl nov´y operaˇcn´ı syst´em - MacOS X. Ten uˇz m´a vnitˇrnˇe pram´alo podobnost´ı se starˇs´ımi verzemi MacOSu, mnohem v´ıce m´a spoleˇcn´eho (j´adro MACH z BSD) s NeXTStepem. A nab´ız´ı velmi propracovan´e objektov´e uˇzivatelsk´e prostˇred´ı a z´aroveˇn vysok´y v´ykon. Nen´ı to jedin´a vˇec, kterou po sobˇe NeXT zanechal, v jeho r´amci totiˇz vznikl otevˇren´y standard pro objektovˇe orientovan´y operaˇcn´ı syst´em - OpenStep. Na jeho v´yvoji spolupracovaly nˇekter´e renomovan´e firmy, v jeho r´amci se vyv´ıjej´ı dalˇs´ı programy, bohuˇzel se nezd´a, zˇ e by se jeˇstˇe mohl prosadit.
2.5.2 Plan 9 Tento syst´em nezmiˇnuji asi na prav´em m´ıstˇe, protoˇze defacto nejde o v´yvojovou vˇetev Unixu, ale o zcela nov´y syst´em, kter´y si bere z Unixu pouze to nejlepˇs´ı. Garantem kvality je pˇr´ıtomnost tv˚urc˚u Unixu ve v´yvojov´em t´ymu. Pˇri n´avrhu syst´emu autoˇri neˇsli cestou dodrˇzov´an´ı standardu˚ na m´ıstech, kde by to bylo na sˇ kodu, jak se bohuˇzel nˇekdy dˇeje. Syst´em vznikal v dobˇe, kdy uˇz kontrast v´ykonn´y server – naprosto hloup´y termin´al nebyl tak v´yrazn´y a jako termin´aly se pouˇz´ıvaly stroje s nezanedbateln´ym v´ykonem. Plan 9 13 nese pˇr´ızvisko ”s´ıt’ov´y operaˇcn´ı syst´em” a pokud mu ho nech´ame, pak ho asi nebudeme moci pˇriˇradit zˇ a´ dn´emu jin´emu z existuj´ıc´ıch syst´em´u. C´ılem bylo umoˇznit veˇsker´e zdroje a nejen datov´e sd´ılet a dynamicky distribuovat. Proto byl pˇri jeho v´yvoji kladen d˚uraz na parelelizaci zpracov´an´ı. Jako programovac´ı jazyk bylo zvoleno opˇet C, ale s nˇekolika zmˇenami (omezen´ımi oproti ANSI C). Pˇribyl jazyk na programov´an´ı paraleln´ıch program˚u - Alef. Zmizel klasick´y Unixov´y znakov´y termin´al, m´ısto nˇeho je Plan 9 termin´al, kter´y um´ı grafiku, okna... Syst´em internˇe pouˇz´ıv´a Unicode, tedy by mˇely odpadnout probl´emy se znakov´ymi sadami. Plan 9 se uˇz ale nevyv´ıj´ı. Nen´ı to zdaleka prvn´ı projekt, kter´y pˇres znaˇcnou technologickou vyspˇelost zahubila sˇ patn´a obchodn´ı politika. Volnˇe ke staˇzen´ı z webu BTL je jeho demoverze pro PC.
2.5.3 Linux Asi nem´a smysl unavovat v´as otˇrepan´ym pˇr´ıbˇehem finsk´eho student´ıka, kter´y se sv´ym operaˇcn´ım syst´emem otˇra´ sl zd´anlivˇe pevn´ymi pozicemi ve svˇete softwaru. V jak´em je ale vztahu Linux k ostatn´ım Unix˚um? S klidn´ym svˇedom´ım rˇeknu, zˇ e velmi dobˇre a zˇ e kdo um´ı pracovat s jedn´ım, zvl´adne i druh´e. Linux implementuje vol´an´ı podle System V i POSIXu a programy jsou tedy vˇetˇsinou bez probl´emu pˇrenositeln´e. Nerozluˇcn´ym bratrem Linuxu je pˇrekladaˇc GNU C, v cˇ emˇz spoˇc´ıv´a 13 N´azev
je pˇrevzat z n´azvu jednoho z prvn´ıch (a u´ dajnˇe i nejhorˇs´ıch) sci-film˚u
22
ˇ KAPITOLA 2. SOUCASNOST UNIXU
dalˇs´ı s´ıla Linuxu - pˇrenositelnost, existuje totiˇz mnoho kˇr´ızˇ ov´ych GNU C kompil´atoru˚ pro jin´e platformy. A je snadnˇejˇs´ı vyvinout pro nˇejakou dalˇs´ı pˇrekladaˇc C, neˇz ps´at pro n´ı nov´y, vlastn´ı operaˇcn´ı v´yzkum. D´ıky tomu (a mimo jin´e tak´e d´ıky miliardov´e investici IBM) se Linux dostal z platformy PC tak´e na Alphy a nakonec i na AS/400, kde je prezentov´an jako plnˇe nasaditeln´y syst´em. Jeho kredity jsou zde pˇredevˇs´ım jeho jednoduchost, rychlost a cena. Linux plnˇe osvˇedˇcuje myˇslenku otevˇren´eho k´odu (Open Source). D´ıky tomu jsou mnohem vˇetˇs´ı moˇznosti jeho zkvalitnˇen´ı a sˇ ance na objeven´ı pˇr´ıpadn´ych chyb. Je ovˇsem tak´e tˇreba neoopomenout zm´ınit podobnˇe pojat´e syst´emy, jako r˚uzn´e otevˇren´e vˇetve BSD (OpenBSD, FreeBSD, NetBSD), nebo jin´e GNU, zejm´ena Hurd. D´a se rˇ´ıci, zˇ e pro uˇzivatele oproti Linuxu neznamenaj´ı v´yznamn´y rozd´ıl, ale. . . Linux je zkr´atka moment´alnˇe popul´arnˇejˇs´ı.
2.5.4 NeUnixy Zaj´ımav´e jsou i syst´emy, kter´e sice stoj´ı na naprosto jin´ych hodnot´ach neˇz je typick´e Unixov´e makroj´adro, ale pˇresto implementuj´ı nˇekter´a standardn´ı (zejm´ena POSIXov´a) vol´an´ı a tˇreba i adres´arˇovou strukturu. Za tyto bych jmenoval multimedi´aln´ı BeOS14 , AtheOS15 (velmi podobn´y BeOSu, d´ılem jedin´eho program´atora) a realtimov´y QNX. V´yhody implementov´an´ı standardizovan´e sady funkc´ı (at’ uˇz System V nebo POSIX) jsou zˇrejm´e: portace mnoha programu˚ a knihoven se st´av´a rutinn´ı z´aleˇzitost´ı.
14 Firma Be byla
po krachu koupena Palm Computing, takˇze jsem skuteˇcnˇe zvˇedav, jestli o BeOSu jeˇstˇe uslyˇs´ıme 15 http://www.atheos.cx/
Kapitola 3
Budoucnost UNIXu Skuteˇcnˇe se nepovaˇzuji za natolik pˇredv´ıdav´eho, abych se v t´eto kapitole mohl rozepsat. Za jist´e pokl´ad´am, zˇ e Unix tu s n´ami jeˇstˇe pˇeknou dobu pobude. V rol´ıch zat´ızˇ en´ych datab´azov´ych a aplikaˇcn´ıch serveru˚ je dosud nenahraditeln´y (i kdyˇz se n´as nˇekter´e firmy usilovnˇe snaˇz´ı pˇresvˇedˇcit o opaku).
3.1 V´yvoj Unixu Co se t´ycˇ e v´yvoje j´adra, stejnˇe jako dˇr´ıve se v´yvoj zamˇerˇuje nejintenzivnˇeji na vylepˇsen´ı metod paralelizace zpracov´an´ı. Zaˇc´ınaj´ı se objevovat nov´e procesory, schopn´e re´alnˇe zpracov´avat dvˇe vl´akna v jednom okamˇziku a ty samozˇrejmˇe potˇrebuj´ı syst´emy, kter´e dok´azˇ´ı jejich moˇznost´ı vyuˇz´ıt. Nˇekteˇr´ı lid´e tvrd´ı, zˇ e Unix je zastaral´y a snad i pˇrekonan´y syst´em, nem´am ale pocit, zˇ e by vˇedˇeli o cˇ em mluv´ı. Jak dokazuje napˇr´ıklad zm´ınˇen´y NextStep (viz. 2.5.1 na str. 20) nebo MacOS X, na Unixov´em z´akladˇe lze postavit velice komplikovan´y a takzvanˇe ”modern´ı” syst´em. Definovat pojem ”modern´ı operaˇcn´ı syst´em” je jistˇe obt´ızˇ n´a z´aleˇzitost, ale podle mˇe si toto pˇr´ızvisko Unix zaslouˇz´ı i pˇred jin´ymi, byt’ mladˇs´ımi syst´emy.
23
24
KAPITOLA 3. BUDOUCNOST UNIXU
Literatura [1] Maurice J. Bach. The Design of the UNIX Operating System, PH 1986 – Principy operaˇcn´ıho syst´emu UNIX, Softwarov´e Aplikace a Syst´emy, Praha 1993 [2] Ludˇek Skoˇcovsk´y. Unix Posix Plan 9, Brno 1998 [3] R. W. Stevens. UNIX Network Programming, PH 1990 [4] Bran W. Kerninghan, Dennis M. Ritchie. The C programming language, PH 1978 – Programovac´ı jazyk C Alfa, Bratislava 1988 ´ [5] Libor Forst. Uvod do UNIXu, pˇredn´asˇky na MFF UK 1999 [6] Petr Klika. Historie UNIXu a Linuxu http://fi.muni.cz/. . . 1999 vys´azeno v syst´emu LATEX 2ε
25
