To będzie historia o standardach. Dokładniej: o ich istnieniu, ich przestrzeganiu i nieprzestrzeganiu. A także o tym, że pozory mylą. Każda historia ma swój początek, tę zacząć by można w 2002 roku, ale… Z początkami jest ten problem, że zawsze można spojrzeć wstecz i wstecz, na wydarzenia wcześniejsze, które rzucają więcej światła, dając tym samym szerszy pogląd na wszelkie sprawy. Tak wiec zróbmy, cofając się do Linuksowej prehistorii.

Jest rok 1993. Od dziesięciu lat trwają kierowane przez Richarda Stallmana prace nad systemem GNU. Przed dwu laty, fiński programista Linus Torvalds publikuje kod kernela Linux. Efekt? Trwają prace nad dystrybucją GNU/Linux o nazwie SLS. Dosłownie za kilkadziesiąt dni Patrick Volkerding oficjalnie ogłosi rozpoczęcie inspirowanego nią projektu Slackware. Nie będzie jedyny. Dokładnie miesiąc po nim, Ian Murdock powoła do życia dystrybucję Debian. A inni? W Kalifornii programiści pracują nad systemem SunOS, przemianowanym później na Solaris. Inni biorą udział w ulepszaniu systemów z rodziny BSD. A propos – Mac OS jeszcze trochę poczeka na swoje X.

Wspólny mianownik wymienionych projektów to wywodzący się z końca lat sześćdziesiątych UNIX. Ken Tompson i Dennis Richie podczas jego tworzenia postawili na kilka fundamentalnych zasad, które przestrzegane były z żelazną konsekwencją. Między innymi – zasada prostoty. Tym, którzy podczas użytkowania systemu uniksowego narzekają na jej brak, nie wolno zapominać, że chodziło o prostotę konstrukcji – nie koniecznie użytkowania. Konsekwencją tej zasady, zwanej również regułą KISS było między innymi to, że w systemie UNIX wszystko jest plikiem. Nawet kiedy nie jest, jak mawiają złośliwi. Od samego początku wiadomo więc było, że plików u Uniksie będzie dużo. Nawet bardzo dużo. Opracowana przez ojców Uniksa koncepcja uporządkowania tego uniwersum danych, realizowana była w projektach potomnych różnie. Nic zatem dziwnego, że w pewnym momencie zrodził się pomysł, aby zrobić z tym porządek.

Pojawia się FHS

Free Standards Group to niedochodowa organizacja, w skład której wchodzą między innymi przedstawiciele firm: IBM, Dell, HP, Intel, Sun, Oracle, Novell i Red Hat. W 1993 roku, w wyniku prowadzonych przez nią prac, światło dzienne ujrzał FSSTND – Filesystem Standard. Pierwszy dokument standaryzujący hierarchię plików, ograniczający się jednak tylko do dystrybucji systemu Linux. Niecały rok później, 14 lutego 1994 roku, w wyniku poszerzenia, zarówno grona, jak i zakresu prac opracowano Filesystem Hierachy Standard, znany powszechnie jako FHS. Niemała w tym zasługa społeczności BSD, co z kronikarskiego obowiązku niewątpliwie należy odnotować.

Co zawiera dokument FHS, którego wersję oznaczoną numerem 2.3 możemy oglądać dziś? Przede wszystkim – kompletny opis referencyjnego drzewa katalogów dla systemów z rodziny UNIX. Opisana zawartość katalogu głównego i podkatalogów, nie ogranicza się jednak do suchej listy ich nazw i położenia. Podana została także domyślna lista plików oraz, co nie mniej ważne – cel istnienia poszczególnych katalogów. Także to, jaki charakter mają dane w nich zawarte. Spójrzmy choćby na tabelę, jaka znalazła się w omawianym dokumencie:

(FHS, ver. 2.3, s. 2)

Pliki konfiguracyjne mają być zatem statyczne oraz nieudostępniane. Słusznie – raz przyjęta konfiguracja nie ma w zwyczaju w kółko się zmieniać, wszak fakt, że urządzenia działają poprawnie wskazuje na to, że zawartość plików z ustawieniami jest odpowiednia. Podobnie, to na jakich ustawieniach działa nasza maszyna nie musi być przedmiotem debaty publicznej. Jest to, można by rzec – prywatna sprawa między maszyną i administratorem. Analogicznie wygląda sprawa dodawania nowych użytkowników, czy zmiany komunikatu wyświetlanego podczas startu sytemu. Odwrotnie – zawartość katalogu obsługiwanego przez program dostarczania poczty jest i owszem – zmienna, oraz jak najbardziej wystawiona na widok publiczny. Sprawą dobrej konfiguracji jest już to, aby publikę tworzyły wyłącznie osoby uprawnione.

Co jeszcze można wyczytać z FHS? Przyjrzyjmy się krótko, co dokument ów mówi o katalogu /bin. Oto kilka przykładów:

• Katalog ma być dostępny dla każdego użytkownika.
• Nie zawiera żadnych podkatalogów.
• Zawiera programy niezbędne w najbardziej podstawowej pracy (na przykład w trybie jednego użytkownika).
• Opracowano listę plików, które muszą się w nim znaleźć. Dopuszcza się jednak stosowanie dowiązań symbolicznych do plików położonych fizycznie w innej lokalizacji.
• Konieczne jest aby katalog zawierał polecenia „[” (do niezorientowanych – tak, to jest polecenie) i „test” mimo, że mogą one być zaimplementowane w powłoce (na przykład w interpreterze bash).

Podobnie opracowano resztę zalecanych katalogów, co oczywiste, a także te opcjonalne. Przykładem może być tutaj proc, który będąc specyficznym dla konkretnych konstrukcji kernela – nie musi występować we wszystkich implementacjach systemów rodziny UNIX.

Kolorowa rzeczywistość

Sprawa jest zatem jasna, ale z drugiej strony… Zawsze można zrobić coś szybciej i lepiej, czyż nie? Mac OS X / Darwin należy oczywiście do rodziny UNIX. Tyle tylko, że katalog użytkowników nosi w nim nazwę Users. No, nie dość, że nie home to jeszcze pisane z dużej litery. Podobnie katalog Library.
W dokumencie FHS przewidziano szczególny katalog na dane serwerów: srv. I co? I nic – dosłownie. W sporej części dystrybucji w ogóle się go nie używa. FTP? Istnieją rozwiązania, które przewidują na przykład istnienie podkatalogu ftp w obrębie katalogu użytkowników. Miejsce przyłączania nośników wymiennych to już prawdziwy Hyde Park, a przecież standard przewiduje nań katalog media. Katalog opt używany jest w ogóle dość dowolnie. W niektórych dystrybucjach instalowany jest w nim OpenOffice.org. Ich twórcy stwierdzili widocznie, że pakiet ten jest oprogramowaniem dodatkowym. Takie bowiem programy, co do zasady, katalog opt zawiera. Inni, przeciwnie, uważając OpenOffice za składnik systemu umieszczają jego binaria w /usr/bin. Przykłady można mnożyć.
Dlaczego standard nie jest ściśle przestrzegany? Po prostu dlatego, że nie jest obligatoryjny. Twórcy opłaca się uznawanie ogólnych ustaleń, gdyż potencjalny użytkownik nie musi na nowo odkrywać Ameryki i w przypadku zmiany jednego systemu na drugi, czuje się jak u siebie. W związku z tym – faktycznie, w miarę upływu czasu, widać, że standardy są stosowane coraz konsekwentniej, ale ogólnie, sprawa jest otwarta.

GoboLinux: ładowanie systemu i przedsmak tego co nas czeka…

GoboLinux

Istnieje jednak system, przy którym wspomniane powyżej nieścisłości, są drobne, niewinne i nie warte uwagi. Powstała w 2002 roku z inicjatywy Hishama Muhammada dystrybucja wierna jest w prawdzie zasadzie, że wszystkie pliki leżą w obrębie katalogu głównego, ale poza tym, łamie wszelkie inne, dotyczące rozmieszczenia plików.

GoboLinux, bo o nim tu mowa, to brazylijska dystrybucja, którą można przetestować, bez konieczności instalacji na dysku. System uruchamia się z płyty, a instalator podobnie jak w przypadku MEPIS-a czy Ubuntu dostępny jest po uruchomieniu środowiska graficznego. W przypadku problemów z uruchomieniem, należy zwrócić uwagę na moment w którym podczas startu, próbuje on automatycznie skonfigurować X serwer (komunikat: „Starting X11 detection ( to skip)…”). Podczas monitu naciakamy klawisz escape i kolejno wybieramy: język angielski (en_US), chyba, że dysponujemy znajomością portugalskiego, bądź niemieckiego, następnie układ klawiatury (przykładowo: „qwerty/pl.map”) i na deser ręcznie uruchamiamy serwer X (po prostu wpisujemy „startx” i naciskamy Enter). Tak, na marginesie: ci, którym nieobca jest znajomość modułu UnionFS mogą w wygodny sposób przyłączyć do działającego systemu nośnik, na którym możliwy jest zapis danych. GoboLinux korzysta bowiem z technologii składania modułów, takiej jaka wzorcowo zaimplementowana została w dystrybucji SLAX. Wracając do systemu plików…

Katalog główny zawiera sześć podkatalogów:

System – Wszystkie pliki systemowe. Jego podkatalogi to odpowiedniki „tradycyjnych” etc (Settings), boot (Kernel/Boot), dev (Kernel/Devices), tmp (Variable/tmp), proc (Status) i tak dalej…
Mount – Jest to jedyny katalog do przyłączania dodatkowych systemów plików. Wszystkie podkatalogi, do których będą przyłączane nośniki optyczne, pamięci USB czy systemy zdalne są umieszczone bezpośrednio wewnątrz niego.
Users – Po prostu, odpowiednik uniksowego home lub windowsowego Dokuments and Settings bądź Users. Nic dodać, nic ująć.
Files – Katalog zawiera pliki, które choć używane w systemie nie przynależą bezpośrednio do żadnego programu. Mogą to być na przykład czcionki lub tapety pulpitu.
Depot – Określany także jako „repozytorium plików użytkowników”.
Programs – No, tutaj można krótko – pliki programów, ale…

GoboLinux ma jedną cechę, niewątpliwie unikalną. Osoba widząca ów system po raz pierwszy może odnieść wrażenie, że jego twórcy, to… hmm… ekscentrycy, lecz zaproponowana organizacja plików ma pewną przewagę nad systemami plików uniksowej współbraci. Ale po kolei. Każdy program w systemie, posiada odrębny podkatalog w Programs. Dokładniej, w podkatalogu danego programu znajdują się następne, po jednym na poszczególne wersje programu. Przykładowo, jeśli mamy zainstalowane dwie wersje interpretera bash, zainstalowane są one odpowiednio w /Programs/Bash/2.05 i /Programs/Bash/3.1, (dla wersji 2.05 i 3.1 rzecz jasna). Ponadto, każdorazowo towarzyszy im podkatalog Current będący dowiązaniem symbolicznym do tego, który zawiera aktualną wersję programu.
To nie koniec. Tak naprawdę, najlepsze jeszcze przed nami. Podkatalog każdej wersji zawiera z kolei całą hierarchię, w skład której wchodzą prywatne dla danego programu bin, doc, include, man czy share i tak dalej. Tworzą one swego rodzaju mikroświat dla każdej z wersji zainstalowanych aplikacji. Dzięki takiemu podejściu możliwe jest użytkowanie różnych wersji programów, używających, zauważmy, różnych bibliotek i różnych plików konfiguracyjnych. Wersji – zarówno starszych, jak i eksperymentalnych, bez konieczności rezygnowania z tych aktualnych – stabilnych.
Zastrzeżenia co do dużej przestrzeni dyskowej potrzebnej dla tego typu rozwiązania są bezzasadne. Od czegóż jest mechanizm dowiązań symbolicznych? Poprawne zorganizowanie wszystkich plików i dowiązań nie jest oczywiście zadaniem prostym, ale jak widać możliwym.
Zastosowana koncepcja hierarchii plików ma jeszcze jeden plus, a jest nim zarządzanie pakietami oprogramowania. Jak mówią sami twórcy dystrybucji – jej „system plików jest managerem pakietów”. Zauważmy bowiem, że podkatalogi Programs tworzą kompletną bazę danych zainstalowanego oprogramowania, a i reszta plików w systemie rozmieszczona jest równie konsekwentnie. Dystrybucji GoboLinux nie dotyczy zatem wieloletnia dyskusja o wyższości formatu deb (lub rpm) nad Świętami Wielkiej Nocy.

GoboLinux: przykładowy pulpit, odpalony GoboLinux Manager

Drugą, obok nietypowej hierarchii plików unikalną cechą systemu są dość nietypowe skrypty startowe. W rodzinie potomków systemu UNIX, istnieją dwie szkoły. Pierwsza, czyli skrypty tworzone na sposób Systemu V (Red Hat, Debian…) i druga, reprezentowana przez BSD (FreeBSD, Slackware…). W GoboLinux rozwiązano to jeszcze inaczej. W katalogu /System/Settings/BootScripts umieszczono pliki zawierające kompleksową procedurę obsługi, tak startu (BootUp), jak i zamykania (Shutdown) systemu. To znaczy cała procedura w jednym pliku. Pomocnicze skrypty dla obsługi poszczególnych programów umieszczono w /System/Links/Tasks.

Zasłona spada

Już kilka chwil, poświęconych na przemierzanie hierarchii systemu GoboLinux, utwierdza w przekonaniu, że jest ona całkowicie inna i nie ma wiele wspólnego z hierarchią „tradycyjną”. Pozory mylą. Tak naprawdę jego twórcy byli bardziej przebiegli niż się to na pierwszy rzut oka wydaje. Prawda jest bowiem taka, że system ów nie jest pozbawiony klasycznej struktury katalogów! Jak się to zaraz okaże, zdaje się on być hymnem pochwalnym na cześć mechanizmu dowiązań. System ten posiada bowiem pewne specyficzne polecenie – gobohide. (A także specjalny moduł kernela o tej samej nazwie.) Z konta administratora, wykonajmy gobohide -l w katalogu głównym… I wszystko jasne. Pojawiają się znajome: bin, etc, usr, proc i tak dalej. Fakt, iż bin jest w gruncie rzeczy dowiązaniem symbolicznym do katalogu /System/Links/Executables nie ma większego znaczenia. Tak naprawdę w ogóle nie ma większego znaczenia fakt, które z plików czy katalogów są zbiorami „rzeczywistymi”, które zaś dowiązaniami. Najważniejsze, że GoboLinux nie jest całkowicie oderwany od reszty uniksowej rodziny. Upraszcza to znacznie zadanie w przypadku instalacji nowych aplikacji, szczególnie tych, które nie są dedykowane dla Gobo, a dla systemów standardowych. Jak życie uczy – standardy są dobre. Może nie ze względu na ich jakość, ale na pewno dlatego, że są „standardowe”.

GoboLinux: zasłona zapada, wraca /etc i /usr

Na zakończenie zwróćmy uwagę, że GoboLinux został stworzony w oparciu o „dystrybucję” LFS… Ale, to już inna historia.