Linux wypełniał pamięć. Program ładujący pobierał wciąż kolejne i kolejne kilobajty kodu. Bez namysłu i bez emocji. W końcu jakich emocji można się spodziewać po programie ładującym? Bit za bitem, bajt za bajtem, kolejne porcje danych powstałe w ciągu lat wspólnej pracy wielu mądrych ludzi tworzyły w pamięci duszę systemu. Kawałek po kawałku. Aż do ostatniego bitu.
Program ładujący spojrzał na swoje dzieło.
- Twój czas jeszcze przyjdzie. - powiedział tylko i zabrał się za ładowanie obrazu initrd. Podobnie jak poprzednio, pracował szybko i sprawnie. Kiedy wszystkie potrzebne dane były na swoim miejscu, przekazał wreszcie dowództwo do kernela, usuwając się jednocześnie w cień. Kernel ożył. Nie powoli, nie ospale. Wystartował nagle, jakby pracował już całe godziny. I wtedy nagle wszystko zgasło.
Szalony programista z zadowoleniem puścił klawisz reset.
- Wszystko działa. Dokładnie tak, jak zaplanowałem… Tylko co dalej? - zamyślił się.
Programista był wprawdzie Szalony, ale poza tym genialny. Pracy nie poprzedzał fazą projektowania, tylko siadał i pisał, tak więc teraz miał do wyboru co najmniej trzy drogi. Co najmniej.

Rozdział 1: Początek – program ładujący

Jak wygląda start systemu? Pytanie to nie zaprząta zazwyczaj głowy zwykłemu użytkownikowi komputera. Ot, włącza guzik zasilania, idzie do kuchni zaparzyć kawę i kiedy wraca, może wprowadzić hasło w pole przygotowane na ekranie. Czasem jednak w głowie bardziej dociekliwego, zafascynowanego komputerami entuzjasty rodzi się pytanie „jak to właściwie działa?” Nie jest to żadna magia. Co do tego wszyscy się zgadzamy. Więc jak? Po prostu – komputer wykonuje serię rozkazów uporządkowanych w jakiś logiczny sposób. Ale skąd „wie” co i kiedy uruchomić? W końcu system nie jest to jeden, wielki, wykonywalny program. Jest ich dziesiątki, a niekiedy i setki, więc jak nad tym panuje?

Przede wszystkim - niezależnie od tego w jaki sposób przygotujemy system do obsługi wszystkich potencjalnych programów, na samym wstępie muszą zostać przeprowadzone pewne czynności. Ustaliliśmy już, że zasilanie zostało włączone, kawa zaparzona, sprzęt wygląda w porządku. Pierwszym programem, który ma przyjemność wykonać zawarte w nim polecenia jest program rozruchowy, zwany też boot managerem lub boot loaderem. Na tym etapie działania komputera nie mamy jeszcze do czynienia z żadnym systemem operacyjnym. Mamy po prostu program ładujący, który spod wskazanego w pliku konfiguracyjnym miejsca na nośniku danych odczytuje plik kernela systemu i ładuje go do pamięci. Jest to jasne jak słońce. Mniej jasne jest to, że często program ładujący ma jeszcze jedno zadanie. Ładuje mianowicie obraz initrd. Cóż to takiego?

Rozdział 2: initrd

Nazwa initrd pochodzi od angielskiego „Initial RAM disk”. Jest to plik zawierający obraz systemu plików. Idea jest taka: w pamięci komputera tworzony jest RAM-dysk. (RAM-dysk, przypominam, jest to wyselekcjonowany fragment pamięci operacyjnej, który dla reszty systemu „widziany jest” jako stały nośnik danych - taki wirtualny dysk twardy rzec by można.) Zawartość tegoż RAM-dysku przechowywana jest w pliku initrd. Oczywiste pytanie? Po co się tak męczyć skoro można użyć dysku twardego po prostu? Oczywista odpowiedź? Przede wszystkim, niezależnie od tego, czy uda się przyłączyć jakikolwiek „dysk” - system operacyjny ma do dyspozycji system plików. Wirtualny. Dalej - załóżmy, że mamy fajny, nowy, super-nowoczesny dysk Ultra-SAS-SATA X, (powszechnie będą dostępne za 55 lat, ale my już go mamy gdyż należymy do Układu). W chwili obecnej kernel nie ma pojęcia jak obsłużyć taki dysk, a przypominam, że kernele monolityczne, a Linux do takich należy, mają wyłączność na obsługę sprzętu. Skoro kernel „sam z siebie” nie wie jak, to zapewne ma moduł do jego obsługi. Gdzie jest moduł? Na dysku oczywiście. I mamy błędne koło, bo do niego właśnie usiłujemy się dostać. Smutne i tragiczne? Ależ nie. Można załadować ten moduł dzięki wspomnianemu „patentowi” z obrazem initrd. System plików w obrazie initrd zawiera moduł, więc kernel obsługuje dysk, więc system zadziała. Super. Od razu uprzedzam pytania w stylu: „Jak to jest, że kernel nie może się „dobrać” do dysku, a boot-manager mógł?”. Boot-manager i działający system operacyjny to dwa odrębne cyfrowe wszechświaty. Kiedy działa boot-manager - nie ma systemu operacyjnego i vice versa, więc w zasadzie w ogóle nie ma co porównywać. Poza tym, nigdzie nie jest napisane, że boot-manager ma pobierać obraz kernela z dysku zawierającego główny system plików, czyż nie? Kilka lat temu sam korzystałem z komputera, który uzbrojony był w dysk SATA i system Red Hat 8.0. Katalog „/” umieszczony był na dysku SATA, którego kernel wspomnianej wersji Red Hata „nie widział” umieszczony był więc na małym, starym „zwykłym” dysku IDE wraz z boot-managerem i odpowiednio spreparowanym obrazem initrd właśnie. Oczywiście przykładów zastosowania initrd jest więcej.

Weterani i kombatanci linuksiarze pamiętają zapewne jak kiedyś instalowało się Slackware. Trzeba było wygenerować sobie dwie dyskietki. Pierwsza zawierała program ładujący i kernel. Druga? Obraz initrd (nazywała się rootdisk), którego najważniejszym rezydentem był? Program setup (instalator systemu) oczywiście! Ale, ale…

Ja tu tak teoretycznie, a można przecież przeprowadzić:

Doświadczenie 1:

Najprościej i najbezpieczniej skorzystać z jakiejś dystrybucji LiveCD. Na pierwszy ogień weźmiemy SLAX-a 6, więc:

1. Uruchamiamy system z płytki.
2. Tworzymy katalog /initrd
3. Odnajdujemy plik /mnt/live/mnt/hdc/boot/initrd.gz i rozpakowujemy jego zawartość - czyli plik initrd do katalogu /initrd. Można użyć programu Ark „spod prawego przycisku myszki” w KDE.
4. Tworzymy katalog /initrd/mount
5. Wykonujemy: root@slax: /mount -o loop /initrd/initrd /initrd/mount
6. W katalogu /initrd/mount możemy pooglądać co zawiera „tajemniczy” obraz initrd. Zwracam uwagę na skrypty, których działanie omawiane było w artykule SLAX… jak to działa
7. Koniec doświadczenia.

Nie wdając się w dalsze dywagacje, z obrazem initrd, (czy niekiedy bez niego,) mamy przygotowany, działający system operacyjny. Trzymam się tutaj definicji, według, której system operacyjny to kernel, a wszystkie inne programy to programy użytkowe. Mamy także przygotowany system plików. Zwracam uwagę na niuans: przygotowany - nie znaczy, że wszystkie podsystemy są przyłączone! Wręcz przeciwnie. Dla kernela ważne jest, że istnieje wirtualny system plików, który może ograniczać się do pustego katalogu głównego „/”. Przyłączanie „dysków” to osobna historia.

Teraz przyszła pora na uruchomienie, najlepiej automatyczne, tego wszystkiego co niezbędne do właściwej pracy. Grafika, dźwięk, mysz, sieć, serwer www, programy do dzielenia się plikami w sieci lokalnej i tak dalej, i tym podobne. I tu zaczynają się przysłowiowe schody, bo różnie z tym bywa. Oj różnie…

Rozdział 3: Poziomy pracy systemu:

Jako punkt odniesienia przyjmijmy zasadę, że Linux jest systemem wielozadaniowym. Jest to jakby pryzmat, przez który należy patrzeć na poszczególne jego zachowania, aby właściwie je zinterpretować. Owa wielozadaniowość jest dla statystycznego użytkownika tak oczywista, że na co dzień nikt się nad nią nie zastanawia. Z punktu widzenia maszyny sprawa jest prosta - ma uruchamiać wiele zadań. Ważnym jest, abyśmy zdawali sobie sprawę (tak rzeczywiście), że dla maszyny nie ma wielkiej różnicy między przeliczaniem obrazów, przeliczaniem zadań serwera www, a przeliczaniem słów w edytorze tekstu. Tak czy tak - są to operacje logiczno-arytmetyczne. Podział logiczny, na aplikacje biurowe, sieciowe, czy gry jest sensowny jedynie dla nas: użytkowników. I z punktu widzenia użytkownika właśnie, wielozadaniowość nie jest to takie znowu oczywiste zjawisko. Bo cóż to właściwie znaczy?

• Że użytkownik może uruchomić kilka aplikacji?
• Że do komputera może zalogować się wielu użytkowników?
• Że wielu użytkowników może uruchomić wiele aplikacji?

Jeżeli myślimy o wielozadaniowości w tych kategoriach, to tak naprawdę mówimy o aplikacjach, które uruchomione w danej chwili umożliwiają określone funkcjonalności systemu. Napiszę to może dobitniej. Linux sam z siebie to nie jakiś Transformer. Uruchomiony – działa tak jak został skompilowany. Resztę załatwiają uruchomione w jego środowisku aplikacje. Jeżeli uruchomimy na naszej maszynie hipotetyczny, minimalny zestaw aplikacji, mamy wprawdzie możliwość uruchamiania wielu programów, ale jedynie w trybie tekstowym i jedynie pod warunkiem, że fizycznie siedzimy przed komputerem. Dodatkowe programy mogą zapewnić możliwość logowania się wielu użytkowników. Jeszcze inne programy działanie sieci, a co za tym idzie możliwość logowania się wielu użytkowników przez sieć. Taki ’sshd’ na przykład sprawia, że dzięki protokołowi ssh, do naszej maszyny mogą zalogować się użytkownicy pracujący na innych maszynach. Jeszcze inne programy – „organizują” grafikę, dźwięk i tak dalej, i tak dalej… Mówiąc inaczej - określone funkcjonalności zapewniają nam określone programy. Dokładnie - określone zestawy programów. Te zestawy programów zapewniające określone funkcjonalności określają tak zwane poziomy pracy systemu. Przyjęło się, że poziomów tych jest osiem. Oznaczanych od 0 do 6 oraz poziom „S” (lub „s”). Przyjęło się również następującą ich interpretację:

Slackware, runlevel 3

Jak już napisałem - „tak się przyjęło” i tak to wygląda na przykład w Red Hacie czy Fedorze, ale jak nietrudno się domyślić istnieje cała litania wyjątków od tej „zasady”. Przykładowo:

Debian - domyślnym trybem jest 2, przy czym jest to tryb wielu użytkowników, w którym może działać sieć, środowisko graficzne, dźwięk i wszelkie inne dobrodziejstwa techniki. Poziomy 3-5 nic tu nie znaczą, albo - jak kto woli - znaczą to samo co poziom 2.

Ubuntu - jak wyżej, w końcu oparte jest na Debianie.

Slackware - tryby 2 i 4 są nieużywane, ale skonfigurowane tak jak poziom 3.

Jeszcze „śmieszniej” jest jeśli chodzi o to, który poziom ustalany jest w danej dystrybucji jako domyślny. I tak:

• Debian / Ubuntu - poziom 2,
• Slackware - poziom 3, (który oznacza, notabene, mniejszą funkcjonalność, niż Debianowy poziom 2),
• Gentoo - poziom 3,
• Red Hat / Fedora - poziom 3 lub 5,
• SUSE / openSUSE - poziom 5,

Slackware, runlevel S

To tak, żeby nie było monotonnie i nudno… Choć w sumie, ja tam bym wolał, żeby na tym polu akurat było i nudno, i monotonnie… Aktualny poziom pracy systemu możemy sprawdzić wykonując w konsoli:

# runlevel

jako root, zaś jako zwykły śmiertelnik:

$ who -r

A wracając do startu systemu…

Rozdział 4: Init:

Pierwszym programem wykonywanym w przygotowanym do pracy środowisku jest zazwyczaj program init. Program ten znajduje się w katalogu /sbin, zaś jego plik konfiguracyjny to /etc/inittab. W systemie Linux program init jest kluczowy. Dlaczego? Jest on bowiem „przodkiem wszystkich innych procesów” (przepisane z podręcznika man). Szerzej o tym procesie - w drugiej części „sagi”.

Teraz, wystarczy napisać, że w jego pliku konfiguracyjnym znajduje się dość istotna dla dalszego startu linia. Przykład (z dystrybucji Debian):

si::sysinit:/etc/init.d/rcS

Wskazany jest tu plik, który będzie wykonywany podczas startu. Plik ten ma nam ustawić aplikacje działające podczas startu - czyli na poziomie „S” pracy systemu. Jest to dość istotne, gdyż później poziomy pracy mogą się zmieniać. Ot, choćby root wykona w linii komend polecenie init 1 i zapewnia sobie wyłączność do administracji, „administruje”, następnie wykonuje init 5 i my – zwykli użytkownicy znów możemy wtrącać swoje trzy grosze. Podczas tego przełączania poziomów wykonywane są odpowiednie skrypty, które odpowiednio ustawiają środowisko. Są jednak programy, które winny wykonać się tylko raz. Taką partycję wymiany na przykład chcielibyśmy raczej uaktywnić na początku pracy komputera, aby potem działała bez względu na to jaki poziom pracy umyśli się nam ustawić, czyż nie? A już na pewno nie na rękę byłoby, aby tę partycję włączać i wyłączać w kółko podczas przełączania poziomów. Nie miałoby to po prostu większego sensu. Wracając do programu init.

/etc/inittab zawiera również inną ciekawą linię:

id:2:initdefault:

jest to domyślny poziom systemu. Jeśli nasz Slackware (tak dla przykładu) ma tutaj ustawiony poziom 3, edytując ową linię możemy sprawić, żeby domyślnie uruchamiała się nam „graficzka”. Oczywiście trzeba jeszcze wiedzieć, że w Slackware poziom wielu użytkowników z grafiką to poziom 4, a nie 5 jak (na przykład) w Red Hacie. Linia w przykładzie przepisana jest z kolei z Debiana, w Debianie zaś 2 to „pełna funkcjonalność”.

W ogóle /etc/inittab zawiera same ciekawe linie: cóż system ma począć podczas naciśnięcia ctrl-alt-del, co ma zrobić kiedy „padnie” zasilanie, ile ma być dostępnych konsol wirtualnych…

Rozdział 5: niezwykle krótki rozdział o uruchamianiu programów

Programy zapewniające nam funkcjonalności systemu, uruchamiane są zazwyczaj nie „tak po prostu”, ale poprzez odpowiednie skrypty. Skrypty te przechowywane są zazwyczaj w katalogu /etc/init.d. Znajdują się tam przykładowo:

• alsa - uruchamia oprogramowanie, dzięki któremu słychać muzykę,
• apache2 - uruchamia serwer www,
• gdm - włącza graficzny manager logowania użytkowników,
• samba - uruchamia udostępnianie zasobów w sieciach lokalnych,
• urandom - skrypt, który wywoływany podczas startu, restartu i zatrzymywania systemu zapamiętuje informacje dla generatora liczb losowych…

Aby nie przynudzać - przejście na konkretny poziom pracy systemu to po prostu wywołanie w określonej kolejności, odpowiednich skryptów. Najczęściej z katalogu /etc/init.d, choć nie jest to regułą.

Programista myślał i myślał… Znał powszechnie stosowane sposoby uruchamiania i zamykania (tak - nie zapominajmy o zamykaniu - w końcu czasem komputer trzeba zresetować, a może nawet wyłączyć,) aplikacji podczas zmiany poziomów pracy systemu. Żaden mu nie odpowiadał. Styl BSD? Trudny w pielęgnacji. Może styl SysV? Może, któryś z mniej popularnych? Pomyślał jeszcze chwilę i ta właśnie chwila spowodowała, że spłynęło na niego olśnienie.
- No! To jest to! Teraz będzie chodziło szybciej i lepiej! - zawołał i natychmiast zabrał się do pracy.
Gdyby programiści pracujący nad takimi systemami jak Solaris, Debian czy Slackware zobaczyli kod wpisywany przez Szalonego na ekranie, otworzyliby szeroko oczy ze zdumienia i zzielenieli z zazdrości… O ile w ogóle cokolwiek by z tego zrozumieli.

Rozdział 6: Styl BSD

Jak najprościej wywołać skrypty aplikacji potrzebnych podczas pracy na konkretnym poziomie pracy systemu? To proste - trzeba napisać odpowiedni skrypt. Rozwiązanie takie stosowane jest w systemach rodziny BSD i niektórych dystrybucjach Linuksa, jak na przykład Slackware czy CRUX.

W katalogu /etc/rc.d znajdują się skrypty rc.S, rc.0, rc.4, rc.6 i tak dalej… W skryptach tych znajdują się eleganckie wywołania skryptów uruchamiających poszczególne programy, bądź też samych programów. Co to znaczy eleganckie? Dla przykładu:

if [ -x /usr/bin/gdm ]; then
    exec /usr/bin/gdm -nodeamon
fi

Co po polsku znaczy mniej więcej tyle: „Jeśli istnieje graficzny menadżer logowania GNU - uruchom go. Eleganckie znaczy więc kontrolę, czy to czego oczekujemy od systemu w ogóle jest wykonalne. Ogólnie zasada jest więc chyba prosta. Tworzymy skrypt, który wprowadza maszynę na poziom startowy („S”), a następnie poziom docelowy - na przykład 4, który dla dystrybucji Slackware oznacza „pełną funkcjonalność”. Analogicznie – tworzymy skrypt do uruchomienia aplikacji zapewniających funkcjonalność dla poziomu administratora, skrypt do restartu systemu, i tak dalej. Czy można inaczej?

Rozdział 7: Styl SysV

Tak jak poprzednio posługiwaliśmy się przykładem Slackware, tak teraz pomęczymy trochę jego niewiele młodszego brata – dystrybucję Debian. Jest on bowiem kanonicznym przykładem dla tego stylu ustawiania poziomów pracy systemu, który nawiasem mówiąc jest w Linuksie dominujący. Tu sprawa jest ciekawsza, a na pierwszy rzut oka – wręcz magiczna. Ale do rzeczy.

Doświadczenie 2:

Przygotujmy na naszym komputerze katalog. Nie ma tu znaczenia jakiej dystrybucji używamy. Nasze doświadczenie zadziała nawet w Slackware - użyjemy standardowych poleceń. Niech katalog nazywa się „skrypty”.

keyto@serwer:~/$ mkdir ~/skrypty
keyto@serwer:~/$ cd ~/skrypty

Dobrze. Teraz w owym katalogu przygotujmy trzy pliki w następujący sposób:

keyto@serwer:~/skrypty$ echo '#!/bin/bash' > 01_skrypt
keyto@serwer:~/skrypty$ echo 'echo Wykonuje skrypt 01' >> 01_skrypt

Następne dwa pliki tworzymy w podobny sposób, tyle tylko, że wszystkie sekwencje ‘01′, zastępujemy kolejno sekwencjami ‘02′, ‘03′. Oczywiście, jeśli chcesz, to możesz Czytelniku wygenerować ich nawet 100. Sugeruję posłużyć się klawiszem strzałki górnej w celu przywołania ostatniego polecenia i jego modyfikacji. Następnym krokiem będzie nadanie naszym pseudo skryptom atrybutu wykonywalności:

keyto@serwer:~/skrypty$ chmod 700 *skrypt

A teraz najciekawsze. Jak wiadomo, możemy uruchomić dowolny skrypt, przykładowo:

keyto@serwer:~/skrypty$ ./01_skrypt
Wykonuje skrypt 01

Można wywołać ich kilka, na przykład:

keyto@serwer:~/skrypty$ ./01_skrypt; ./02_skrypt
Wykonuje skrypt 01
Wykonuje skrypt 02

Na razie mało odkrywcze. Co jednak w przypadku, kiedy chcemy wywołać wszystkie skrypty, a jest ich nie pięć a sto pięć. Ba! Albo kiedy drugim użytkownikiem naszego PC-ta jest Swawolny Dyzio, który dopisał jeszcze dwa skrypty? (To, że swawolny, nie znaczy, że nie jest dobrym skrybą skryptów, czyż nie?). To jak? Wypisać wszystkie pliki i mozolnie „wklupać” we wierszu poleceń? Oczywiście, że nie. W systemie jest pewne polecenie, z którego teraz skorzystamy:

keyto@serwer:~/skrypty$ run-parts .
Wykonuje skrypt 01
Wykonuje skrypt 02
Wykonuje skrypt 03

Ciekawe? Proszę nie ignorować kropki po nazwie polecenia. Przypominam, że ta kropka nie oznacza końca zdania. Jest to po prostu nazwa bieżącego katalogu.

W podobny sposób Debian radzi sobie z wywoływaniem skryptów startowych. Proszę zajrzeć do następujących katalogów. Na początek do /etc/rcS.d Te skrypty wykonują się na starcie. Przykład z mojego komputera (fragment):

keyto@serwer:~/skrypty$ ls -1 /etc/rcS.d
S02mountvirtfs
S04udev
S05bootlogd
S10checkroot

i tak dalej, i tak dalej. Nazwy jak widać zaczynają się od sekwencji ‘S’ plus liczba. Chodzi o to, że program ‘run-parts’ uruchamia skrypty w kolejności alfabetycznej. Jeśli chcemy, aby dany skrypt uruchamiał się wcześniej lub później, wystarczy zmienić ten numer. Na przykład z ‘S04udev’ na ‘S76udev’. (Ale nie róbcie tego! To tylko możliwość – nie znaczy, że wyjdzie systemowi na zdrowie!)

Podobną sytuację zastaniemy w katalogach: od /etc/rc0.d do /etc/rc6.d. Ważne jest także to, że cała zawartość analizowanych przez nas w tej chwili katalogów to łącza symboliczne tworzone poleceniem ‘ln -s’. Nie ma sensu, ani potrzeby kopiować poszczególnych plików. „Oryginały” siedzą sobie spokojnie w katalogu /etc/init.d, a ich nazwy nie są poprzedzone żadnymi numerami. Innymi słowy katalog /etc/init.d zawiera cały zbiór skryptów startowych. Jeśli chcemy aby, na przykład skrypt ‘gdm’ (uruchomienie menedżera logowania rodem z GNOME w środowisku graficznym) uruchamiał się automatycznie przy starcie systemu, wykonujemy komendę:

roor@serwer:/ # ln -s /etc/init.d/gdm /etc/rc2.d/S99gdm

A propos graficznego menedżera logowania. Dzięki numerom w nazwach skryptów można osiągnąć znany z MS Windows (R) efekt, kiedy to system wprawdzie ciągle ładuje zadane aplikacje, ale użytkownik już widzi gotowy ekran logowania. Trzeba po prostu przesunąć uruchamianie programu gdm trochę wstecz. Choć, czy to ma właściwie sens? Pozostawiam osądowi Czytelnika.

Wywoływanie skryptów może również następować dzięki następującej komendzie:

for i in /etc/rcS.d/S??*
do
    (...)
done

Czyli: dla każdego pliku znajdującego się w katalogu /etc/rcS.d/ o nazwie pasującej do wzorca „S” plus dwa znaki plus cokolwiek wykonaj…

Debian korzysta zarówno z tego sposobu jak i programu run-parts. Czy sposób uruchamiania aplikacji na potrzeby poziomów pracy systemu stosowany w Debianie jest „lepszy” od tego stosowanego w Slackware? Trudno orzec. Jak już wspomniałem – w Slackware trzeba mozolnie wpisać sto drugi, sto trzeci, sto czwarty skrypt, który przyjdzie nam ochota zastosować, w Debianie jest to jak gdyby prostsze, ale z drugiej strony… Edytując pliki jesteśmy teoretycznie bardziej świadomi tego co się z naszym systemem będzie działo. No i w slackware-owym skrypcie można sobie robić komentarze. Dla Debiana i „rodzinki” przygotowano za to specjalne programy: konsolowy update-rc.d, czy KsysV (wchodzi w skład środowiska KDE), które ułatwiają zarządzanie dowiązaniami symbolicznymi do skryptów na poszczególne poziomy pracy.

KSysV w Debianie

Oczywiście można jeszcze inaczej.

Rozdział 8: GoboLinux

GoboLinux jest inny. Umówmy się, że to fakt, a faktach się nie dyskutuje. Skoro jest inny, to i sposób jego uruchamiania, czy zamykania nie może być standardowy. Ogólnie przypomina on ten znany z BSD, z jedną wszakże różnicą. W Gobo zastosowano skrypty zawierające kompleksową procedurę startu i analogicznie kompleksową procedurę zamykania systemu. W Slackware trzeba było tak naprawdę przejść przez kilka skryptów (czyli na przykład dwa), przykładowo rc.S i rc.4 dla startu systemu w trybie „pełnym” (ze środowiskiem graficznym). Natomiast w Gobo skrypt BootUp (znajduje się on w katalogu /System/Settings/BootScripts) zawiera wszystkie kroki uruchamiania systemu. Od początku do końca. Analogicznie, towarzyszy mu skrypt Shutdown. Sam Czytelniku domyśl się do czego służący. (Ot – taka „zagadka”.)

Około północy zadzwonił telefon. Guru ociągając się ściszył telewizor i odebrał słuchawkę.
- Michuk z tej strony. Mamy problem - usłyszał. Nie namyślając się długo, rzeczowo podjął temat:
- Hę?
- Keyto zdobył kody źródłowe systemu Szalonego Programisty. Wykradł, czy coś… Próbował je rozpracować do potrzeb artykułu, ale ugiął się pod ogromem złożoności i nie wytrzymał tego obciążenia…
- A tak prościej!? - nie wytrzymał Guru.
- Zwariował.
- Rany Boskie! Oglądałeś je?
- Oczywiście, że nie.
- I co teraz? Trzeba coś zrobić - zmartwił się Guru. Nie wiadomo jednak czy tym w jakim stanie znajdował się Keyto, czy tym, że ze zrozumieniem kodu Szalonego był poważny problem.
- Psychiatra, Linus Torvalds i RMS w drodze…

Post scriptum:

• Po pierwsze: Z tym dyskiem „Ultra-SAS-SATA X” to był oczywiście taki żart. Oczywiście będą dostępne dopiero za 57 lat.
• Po drugie: Niniejszy artykuł opisuje oczywiście start systemu należącego do rodziny UNIX. Start systemu Windows zostanie opublikowany na wortalu jakiwindows.org, o ile portal zostanie w końcu uruchomiony.
• Po trzecie: Ciąg dalszy nastąpi, a w nim trochę o życiu systemu, czyli głównie o katalogu /proc, choć nie tylko…