Stalo se to v USA, někdy v roce 1945, kdy počítač Mark II zase jednou nepracoval tak, jak měl. Technici zkoušeli všechno možné a časem se dostali i ke kontrole všech relé, které vytvářela operační paměť tohoto počítače. A zde našli poněkud kuriózní příčinu chyb - obyčejnou malou můru, která vlétla do útrob počítače. Dostala se až mezi kontakty jednoho relé, a ty svým spínáním záhy ukončily její životní dráhu. Tak ji našli technici počítače, spečenou mezi kontakty relé, které sice bylo sepnuté, ale díky zbytkům můry mezi příslušnými kontakty nevytvářelo vodivé spojení.

Technici příčinu závady pečlivě zadokumentovali - zbytky můry nalepili přímo do provozního deníku - a když měli příště lokalizovat příčinu nějaké chyby, žertem říkali, že jdou zase hledat nějakou můru nebo podobný hmyz. A jelikož americká hovorová angličtina používá pro označení hmyzu slovíčko bug, rázem se z toho stalo odstraňování hmyzu neboli debugging.

Nový termín v počítačové terminologii zdomácněl a dodnes se používá pro označení činnosti, která má za cíl najít a odstranit příčinu nesprávného chování, ať již v hardwaru, nebo v softwaru.

Ne nadarmo se říká, že tak dlouho se chodí se džbánem pro vodu, až se ucho utrhne. Něco podobného se stalo i se zvyšováním rychlostí procesorů - tak dlouho se zrychlovaly, až jim přestala stačit operační paměť.

Procesory se staly tak rychlými, že k dosažení plné rychlosti vyžadovaly extrémně rychlou operační paměť. Taková sice existuje, ale je velmi drahá - tak drahá, že není únosné realizovat s ní celou operační paměť o kapacitě v řádu megabytů.

Existuje však ještě i jiná možnost. Je založena na pozorování, že programy obvykle nesahají do operační paměti zcela nesystematicky, ale právě naopak - po určitou dobu pracují vždy jen s relativně malým úsekem paměti. Proč toho nevyužít a nepřenést obsah tohoto úseku do zvláštní paměti o menší kapacitě, kterou zařadíme mezi procesor a vlastní operační paměť, a která již může být dostatečně rychlá? Bude-li mít procesor štěstí, najde požadovaná data v této malé paměti, a dostane je tudíž s takovou rychlostí, jakou potřebuje. V opačném případě bude nutné "sáhnout" až do pomalejší operační paměti, což ovšem bude trvat poněkud déle. Proto odsud raději načteme hned celý větší blok dat a přeneseme jej do naší rychlé paměti. S velkou pravděpodobností si procesor resp. právě prováděný program záhy vzpomene, že potřebuje něco právě z tohoto bloku, který jsme si předvídavě načetli dopředu.

Malá a velmi rychlá paměť, která se takto zařazuje mezi procesor a "pomalou" operační paměť, a funguje právě naznačeným způsobem, se v angličtině nazývá cache. V češtině se nejčastěji označuje jako vyrovnávací paměť.

Myšlenka načítat dopředu větší celky dat, než jaké jsou právě požadovány, má své opodstatnění i v jiných případech. Zvláště v případě disků - pokud si některý program vyžádá např. načtení jednoho sektoru, je velmi pravděpodobné, že záhy bude požadovat také následující sektor na téže stopě. Než se ale k tomu odhodlá, může se disk pootočit tak, že se následující sektor již nestihne, a je třeba čekat celou obrátku, než se znovu dostane pod čtecí hlavu.

Zde se přímo nabízí myšlenka načítat vždy rovnou celé diskové stopy (což je možné stihnout za dobu právě jedné obrátky), a ukládat je do paměti, která je k tomuto účelu vyhrazena. Požadavky na čtení jednotlivých sektorů je pak možné uspokojovat z této paměti, což je výrazně rychlejší.

Také v tomto případě se hovoří o paměti cache, přesněji o diskové cache paměti (disc cache).

"Vy jste od počítače?" ptá se v jedné známé scénce nic netušící laik. "Proboha, kde?" děsí se duchaplný odborník, který se hned začíná všemožně prohlížet a oprašovat a ustaraně se jakoby sám sebe ptá: "Půjde to nějak vyčistit?"

Nerad bych se někoho dotkl, ale lidé skutečně "od počítače" se mnohdy poznají vcelku snadno. Někteří podle toho, že žijí a pracují převážně po nocích, zatímco ve dne nejsou k zastižení, jiní podle zasněného až nepřítomného pohledu, podle neschopnosti jakékoli rozumné komunikace, podle nepříliš pěstěného zevnějšku apod. Zřejmě je dosti pravdy na tom, že každá činnost člověka nějak poznamenává - natož pak taková, která bezprostředně souvisí s počítači.

Běžný uživatel, který počítač používá jako svůj pracovní nástroj, nemusí znát všechny technické detaily, techniky a postupy, na jejichž základě je počítač postaven a pracuje. Stačí mu umět ovládat ten aplikační program, který ke své práci potřebuje. Může se mu ale stát, že se dostane do takové situace, že se bez detailních znalostí a zkušeností technické povahy neobejde - např. tehdy, když mu jeho počítač vypoví službu, když se jeho aplikační program začne chovat jinak než obvykle, při napadení virem apod. Pak mu nezbývá než najít skutečného člověka "od počítače", který mu dokáže pomoci. Angličtina má pro něj dokonce i vžité označení: guru.

Guru je tedy člověk, na kterého se uživatelé obvykle obracejí v případech nouze o radu a pomoc, protože on je tím, kdo má potřebné znalosti a zkušenosti, nutné k vyřešení jejich problému. Označení "guru" přitom nebývá chápáno nijak pejorativně - guru je prostě ten, kdo umí, ví a zná. Nemusí to být ani někdo, kdo má péči o počítače a jejich uživatele ve své pracovní náplni. Může to být i jiný uživatel, který se o výpočetní techniku zajímá blíže, zkrátka který je poněkud více "od počítače".

Představte si následující scénu, jako vystřiženou z počítačového hororu: v počítačové síti se dva uživatelé přibližně ve stejný okamžik rozhodnou něco si vytisknout na téže sdílené tiskárně. Jejich aplikační programy proto začnou postupně předávat tiskárně jednotlivé znaky, a tato je průběžně tiskne. Vůbec ji nezajímá, jaký je jejich smysl a od koho pochází. Jednoduše je vytiskne - jeden znak od prvního uživatele, pak například dva od druhého, pak hned celé slovo od prvního, od druhého opět jeden znak atd. Výsledek snad ani není třeba pojmenovávat.

Na naší scénce není podstatné to, že jsme ji situovali do počítačové sítě - mohla se stejně tak dobře odehrát na kterémkoli samostatném víceuživatelském počítači, a dokonce také i v jednoúlohovém prostředí, ve kterém právě běžící aplikace průběžně vytváří více než jeden výstupní soubor na tiskárně. Podstatná není ani tiskárna, stejná situace nastává i u některých jiných výstupních zařízení.

Podstatou problému je skutečnost, že šlo o současné využití takového zařízení, které nelze sdílet. Tedy u kterého není možné, aby s ním přímo pracovalo více programů, procesů či úloh současně. Jinak je tomu například u diskových pamětí - zde je docela dobře možné, aby každé jednotlivé čtení či zápis sektoru "patřilo" jiné úloze. Na tiskárně, plotteru a podobných výstupních zařízeních však může tisknout, resp. kreslit v daný okamžik vždy jen jedna úloha, jinak by došlo k nežádoucímu promíchání jednotlivých výstupů.

Právě naznačený problém se samozřejmě musel objevit již u prvních víceúlohových operačních systémů, a byl vyřešen technikou, označovanou jako spooling (od anglického: SPOOL, resp. Simultaneous Peripheral Operations On-Line, neboli: simultánní operace s periferními zařízeními, prováděné ve spřaženém režimu).

Myšlenka spoolingu je velmi jednoduchá. Výstup více úloh na zařízení, které není možné sdílet, je ve skutečnosti průběžně shromažďován na takovém zařízení, které sdílet lze. V námi zvoleném případě tisku na tiskárně by to byl nejspíše disk - výstupní data jednotlivých úloh, určená pro tiskárnu, by se proto ve skutečnosti průběžně ukládala na disk. Z disku by se pak přenesla na tiskárnu a skutečně vytiskla jako celek, a to až v okamžiku, kdy budou připravena všechna. Tedy až poté, co příslušná úloha "dokončí" svůj tisk (přesněji v okamžiku, kdy uzavře příslušný výstupní soubor).

Technika spoolingu se původně používala i pro sdílení "nesdílitelných" vstupních zařízení, především snímačů děrných štítků - z nich se nejprve obsah jednotlivých štítků přenesl na disk a každá jednotlivá úloha si pak svá vstupní data ve skutečnosti četla z disku. Bylo to navíc i výrazně rychlejší, než přímé čtení z pomalých snímačů.

V dnešní době se však spooling používá prakticky jen pro výstupní operace, nejčastěji právě pro sdílení tiskáren. Na myšlence spoolingu jsou pak založeny mimo jiné všechny tiskové servery (print servery).

"Však ono si to nějak pomůže samo", říkáme často v situacích, kdy si sami nevíme rady. Například tehdy, když po nás právě spuštěný program požaduje zadání nějaké hodnoty, výběr z nabídky několika možností či jiné rozhodnutí a my ani netušíme, o co se vlastně jedná. Nebo tušíme, ale jednoduše se nám nechce, někam spěcháme, je nám to jedno apod. Když požadovanou hodnotu nedodáme či potřebné rozhodnutí neučiníme my jako uživatelé, program se obvykle rozhodne sám podle svého, resp. použije takovou hodnotu, kterou si sám určí.

Vezměme si jako příklad textový editor. Tomu musíme vždy říci alespoň to, který soubor chceme editovat - tedy zadat jeho jméno, příponu a umístění (diskovou jednotku, adresář či podadresář resp. tzv. přístupovou cestu k souboru). Nemusíme ale zadat bezpodmínečně všechno - vynecháme-li například přístupovou cestu k souboru, bude jej editor hledat ve svém aktuálním pracovním adresáři. Vynecháme-li příponu souboru, editor si ji obvykle sám doplní, např. na .TXT, .DOC apod. Jméno souboru ale vynechat nesmíme, neboť zde již nemá rozumný smysl, aby si jej editor volil sám.

V některých případech si tedy programy skutečně dokáží "pomoci samy". Pokud jim jako uživatelé explicitně neřekneme jinak, zvolí takovou alternativu resp. použijí takovou hodnotu, kterou mají pro tento případ předem připravenu. V angličtině se pro takovouto hodnotu či alternativu používá termín default, a to buď v roli substantiva (ve smyslu: this value is the default), nebo v roli přívlastku (např.: this is the default value).

Nejvhodnějším českým překladem anglického "default" v roli přívlastku je zřejmě termín "implicitní" - např. implicitní hodnota, implicitní přípona souboru apod. Dobře totiž vystihuje skutečnost, že "implicitní" se použije tehdy, když požadovaná hodnota či alternativa není zadána explicitně.

Doba, kdy všichni museli dělat všechno, je snad již konečně za námi, A to i ve světě počítačů a počítačových sítí. I zde se totiž ukázalo, že je výhodné zavést určitou specializaci jednotlivých komponent počítačových systémů, resp. uzlů sítí.

Vezměme si jako příklad právě počítačovou síť. Jeden z jejích uzlových počítačů může být vybaven velkým diskem, který si ale nenechává jen sám pro sebe. Jeho využití může zprostředkovávat i ostatním uzlovým počítačům, které si na něm mohou uchovávat své soubory. Počítač vybavený velkým diskem tak vlastně nabízí jeho využití jako svou službu ostatním uzlovým počítačům. Staví se tím do role poskytovatele služby - tzv. serveru - zatímco ostatní uzlové počítače, které tyto služby využívají, se dostávají do postavení jeho klientů.

Je-li nabízenou službou již zmíněná možnost uchovávání celých souborů, je její poskytovatel označován jako file server (souborový server). Jiným typickým příkladem serveru je print server (tiskový server), který svým klientům nabízí tisk jejich souborů na své tiskárně. Dalšími příklady mohou být faxové servery, modemové servery apod.

Služby nabízené serverem nemusí mít pouze povahu sdílení technických prostředků - může jít také o poskytování nejrůznějších informací nebo informačních služeb, jako např. u tzv. serveru jmen (name server), který pro své klienty slouží jako jakási obdoba telefonního seznamu či adresáře. Další (dnes velmi oblíbenou) možností, jsou tzv. okénkové servery (window server), které svým klientům zajišťují veškeré zobrazování na jejich displejích (jako je tomu např. v systému X Window).

Pojmy "klient" a "server" se však zdaleka netýkají jen celých počítačů resp. samostatných hardwarových celků. V roli klienta a serveru mohou vůči sobě vystupovat např. dvě úlohy, provozované na dvou různých počítačích, nebo dokonce i na témže počítači ve víceúlohovém prostředí. Jde tedy spíše o vzájemný vztah mezi dvěma samostatnými komponentami, pro který je podstatný charakter jejich vzájemné interakce: poskytování služeb (serverem) resp. jejich využívání (klientem).

Tu situaci jistě znáte i ze svého života: stojí-li proti sobě dva navzájem se vylučující požadavky, není možné vyhovět ani jednomu z nich. Konkrétních podob lze najít hodně - například dvě auta, která vjedou proti sobě do úzké uličky, ve které se nemohou vyhnout - dva lidé, kteří chtějí získat výlučně pro sebe předmět, dostupný jen v jediném exempláři - dvě politické reprezentace, které ... (ale to sem raději nezatahujme).

Řešení těchto zdánlivě bezvýchodných situací (pomineme-li ty politické), mohou být v zásadě dvojího druhu: preventivní, snažící se zamezit tomu, aby příslušná situace vůbec vznikla, a dále takové, které problém řeší až poté, co k němu došlo. Ilustrujme si to právě na příkladu úzké cesty, kde nemohou projet dvě auta vedle sebe. Preventivní řešení by spočívalo v zavedení semaforů na oba konce této úzké cesty, zatímco druhý typ řešení by spočíval v určení toho, kdo má v případě ucpání cesty ustoupit - tj. které auto má vycouvat, respektive dát druhému autu přednost.

Může ale k podobným situacím docházet i v souvislosti s výpočetní technikou? Může, a to nejen tehdy, když se dva lidé "perou" o jeden počítač. Vraťme se na chvíli do doby děrných štítků a představme si víceúlohový operační systém, ve kterém jedna úloha právě tiskne na tiskárně, a náhle si vzpomene, že chce pracovat ještě i se snímačem děrných štítků. Ten však právě používá jiná úloha, která ale zase čeká, až bude mít možnost si něco vytisknout také na tiskárně. A jelikož s každým z těchto zařízení může vždy pracovat jen jediná úloha, a žádná z našich dvou úloh nehodlá "pustit" to zařízení, které již jednou získala, máme zde přímo učebnicový příklad vzájemného zablokování. Existuje pro něj dokonce i velmi přesné pojmenování: deadlock, případně též: deadly embrace (česky pak: smrtelné objetí).

Také zde jsou v principu možné dva druhy řešení: preventivní by znamenalo, že každá úloha musí požádat operační systém najednou o všechna zařízení, se kterými chce pracovat, a která nemohou být sdílena více úlohami současně (tj. nesmí později přijít s dalším požadavkem, který by pak mohl vést ke vzniku smrtelného objetí). Alternativou je možnost odebrat již dříve přidělené zařízení až v okamžiku, kdy ke smrtelnému objetí skutečně dojde - například na základě priorit jednotlivých úloh či jiných kritérií.

Možnost vzniku smrtelného objetí není samozřejmě výhradní doménou děrnoštítkových počítačů. Například ve výpočetním systému s architekturou klient-server může dojít k tomu, že klient čeká na data od serveru, ale ten mu nic neposílá proto, že naopak sám čeká na data od svého klienta - tato varianta smrtelného objetí bývá někdy označována jako starvation deadlock (česky nejspíše: vzájemné vyhladovění).

Jiným příkladem může být taková situace při vzájemné komunikaci dvou zařízení, ve které se každé z nich snaží vysílat, ale druhé nic nepřijímá, neboť má plné vstupní vyrovnávací paměti (tzv. buffery), a nemůže je vyprázdnit, protože čeká na úspěšné odeslání svých dat. Této variantě se pak říká také constipation (zácpa).

Ne nadarmo se říká, že s jídlem roste chuť. Když uživatelé poprvé získali přístup k počítačům, museli nutně být nadšeni jejich možnostmi. Jakmile si ale na ně jen trochu zvykli, začali požadovat více. Jedním z prvních požadavků směrem ke konstruktérům bylo: "Chceme větší operační paměť". "Dobře," odpovídali na to konstruktéři, "má to sice některá technická úskalí - větší rozměry, větší spotřebu, menší spolehlivost - ale v principu to možné je: připravte si ale peněženky, paměť něco stojí." Bylo to však v době, kdy se ceny počítačů jako takových i ceny pamětí pohybovaly oproti dnešku v astronomických výškách. A tak není divu, že se kategorický požadavek uživatelů záhy změnil na mnohem méně imperativní "nešlo by to zařídit nějak jinak?"

Kupodivu šlo. Našel se totiž mechanismus, který dokázal zdánlivě nemožné: nabídnout uživatelům k využití větší objem operační paměti, a přitom je nenutil sahat hlouběji do peněženky a platit za rozšíření operační paměti.

Přitom však šlo v jistém smyslu o podvod - uživatelům se pouze vytvářela iluze toho, že pracují s větší operační pamětí, i když ve skutečnosti byly jejich počítače vybavovány stále stejným objemem paměti.

Vše bylo založeno na pozorování, že programy a jejich data nemusí být v operační paměti vždy celé, a přesto mohou úspěšně běžet. Ve skutečnosti stačilo uložit je celé do vhodné (a především mnohem lacinější !!!) vnější paměti - obvykle na disk - a do operační paměti přenést vždy jen tu část, resp. ty části, kterou úloha nezbytně potřebuje ke svému spuštění. Jestliže se pak kdykoli později ukázalo, že právě běžící úloha potřebuje některou jinou část svého kódu či svých dat, došlo k výměně: z těch částí úlohy, které se právě nacházely v operační paměti, se vybrala taková, kterou úloha momentálně nepotřebovala, tato část se "vrátila" zpět (zapsala) na disk a místo ní se do operační paměti načetla nově požadovaná část úlohy. Docházelo tedy k průběžnému "přetahování" částí úlohy mezi operační pamětí a vnější pamětí - v angličtině se tomu říká swapping.

S právě naznačeným mechanismem je samozřejmě spojena určitá režie, neboť přenést blok dat z disku do operační paměti či naopak určitou dobu trvá. Velikost této režie přitom zavisí na chování samotných úloh - na tom, jak moc sahají do paměti "na přeskáčku". Není jistě principiálním problémem napsat takovou úlohu, která bude zcela záměrně přistupovat k paměti takovým divokým způsobem, že se její jednotlivé části budou neustále přenášet mezi diskem a operační pamětí a režie na tyto přenosy bude zcela neúnosná.

Jak se však pozorováním zjistilo, drtivá většina "reálných" úloh se v tomto ohledu chová mnohem rozumněji - po určitou dobu "sahají" vždy jen do poměrně úzce lokalizované oblasti paměti (proto se také odpozorovanému zjištění říká princip lokality). V důsledku toho pak dochází k výměně částí úloh mezi diskem a operační částí poměrně zřídka a režie, spojená s těmito výměnami, je únosně malá. Navíc ji lze ještě dále optimalizovat vhodnou volbou velikosti přenášených částí, vhodnou volbou strategie pro výběr "nepotřebné" či "nejméně potřebné" části, která se má vrátit z operační paměti zpět na disk apod.

Podstatné je dále to, že celý mechanismus může být implementován takovým způsobem, aby si jednotlivé úlohy nemusely jeho existenci vůbec uvědomovat. Tedy aby veškeré přesuny částí úloh mezi operační pamětí a diskem byly pro samotné úlohy plně transparentní (tj. neviditelné). Úloha (a s ní i ten, kdo ji programuje) se pak může vcelku oprávněně domnívat, že pracuje s "velkou" operační pamětí, jejíž velikost je vlastně omezena jen tím, co se vejde na příslušnou vnější paměť (tedy na disk). Ve skutečnosti však úloha pracuje s mnohem menší operační pamětí, i když o tom ale vlastně vůbec neví.

Vzniká zde tedy disproporce mezi tím, co uživatel a jeho úloha "vidí", a tím, s čím doopravdy pracují. Paměť o velkém objemu, kterou "vnímají" uživatelé a jejich úlohy, je pamětí pouze předstíranou, ve skutečnosti neexistující, a označovanou proto jako virtuální paměť (virtual memory).

Aby se i terminologicky vhodně odlišila paměť, kterou "vidí" uživatelské úlohy, a skutečná, reálně existující operační paměť, zavedly se dva další pojmy: adresový prostor (address space) je to, co "vnímá" úloha, zatímco paměťový prostor (memory space) je tou pamětí, která skutečně existuje. O virtuální paměť se pak jedná v případech, kdy adresový prostor není totožný s prostorem paměťovým.

Adresový prostor a jeho rozsah je určen adresami, které je uživatelská úloha schopna generovat (a ty jsou zase dány šířkou registrů procesoru používaných pro adresování, způsoby adresování atd.). Naproti tomu paměťový prostor je tvořen adresami, které se skutečně používají pro přístup do paměti (tedy tzv. fyzickými adresami), a rozsah je dán objemem skutečně osazené operační paměti. Takže například počítač, jehož procesor pracuje s 32bitovými adresami, nabízí úlohám adresový prostor o velikosti až 4 GB. Ve skutečnosti však může být takovýto počítač vybaven např. jen jedním megabytem "skutečné" operační paměti.

Za virtuální paměť bychom ale měli považovat i případ opačný, který byl velmi častý u 8bitových počítačů. Jejich osmibitové procesory pracovaly se 16bitovými adresami, což odpovídalo adresovému prostoru o rozsahu 64 kB. Tyto 8bitové počítače však byly nezřídka osazovány větším objemem paměti, než je zmíněných 64kB. Paměťový prostor pak byl větší než prostor adresový - a v důsledku toho pak bylo nutné používat i jiné mechanismy pro realizaci virtuální paměti (tedy k tomu, aby se úlohy pomocí "malých adres" dostaly na "velkou paměť").