Hymnu pochwalnego część kolejna (cz. 3)

Ten wpis jest komentarzem to tekstu pana Adama Golańskiego (eimi) o rz...

Wreszcie konkrety!

W dzisiejszym komentarzu zajmę się 3 zarzutami jakie autor stawia nowoczesnemu Linuksowi:

• Brak zgodności z FHS (Filesystem Hierarchy Standard)
• Programy *Kit, Udisk, nie przeznaczonych dla powłoki
• Wykorzystywanie rozbudowanego programu systemd

Jedna hierarchia plików aby nimi wszystkimi zarządzać

Hierarchia systemów plików w systemach Uniksopodobnych to bardzo ciekawy temat.

W raz z rozwojem Uniksów narastała potrzeba rozwoju struktury podstawowych folderów. A mnogość samych systemów tylko się przyczyniała do mnogości własnych rozwiązań różnych producentów.

Problem nie ominą Linuksa. Ale został w miarę szybko dostrzeżony. W 3 lata po upublicznieniu pierwszej wersji (0.1) jądra Linux, powstał standard FHSND w wersji 1.0. Miał on za zadanie uporządkować hierarchię systemu plików w różnych dystrybucjach Linuksa.

Standard się przyjął, i był intensywnie rozwijany przez kolejne 4 lata, zdobywając dobrą opinię. W 97' wydana została nowa wersja standardu, tym razem przeznaczona dla wszystkich Uniksów. Jego ostatnia wersja 2.4 pochodzi z 2004 roku.

FHD jest też jedną z podstaw standardu LSB (Linux Standard Base) który określa podstawowe możliwości które powinny oferować wszystkie dystrybucje Linuksa.

FHD nie jest jednak doskonały. I jak autor zauważył, szczegółowość i drobiazgowość FHD przy rozróżnianiu na główne katalogi i te pod /usr/, są uznawane coraz częściej za zbędne. Oczywiście takie podejście jest CAŁKOWICIE zasadne! /usr/ powstał TYLKO dlatego, że zabrakło miejsca na dysku a można było wykorzystać drugi. (A /home/ powstało dlatego, że twórcy Uniksa dostali 3 dysk i łączna powierzchnia przekroczyła 3 MegaBajty!!!)

Jak to się stało, że ten podział przetrwał tyle lat? Tego pewnie nikt nie wie. Najprawdopodobniej nikt nie zadał sobie pytania, "Czy na ten problem mamy lepsze rozwiązania?".

FHD jak każdy standard ma też kilka drobniejszych problemów.

A więc czy to źle, że społeczność Linuksowa szuka nowych rozwiązań?

Jak najbardziej nie. FHD i kontrowersje z /usr/ to przykład na zdrową krytykę założeń na których obecnie się opieramy, i sensowy opór przed nadmiernymi komplikacjami.

Czy konsola jest przenośna?

Temat ważny przy omawianiu Console/PackageKitów i Udisk ale też i systemd.

I należy tutaj przytoczyć pewną anegdotę z książki pt. "Unix Sztuka Programowania" Erica S. Raymonda.

Mistrz Foo powiedział kiedyś do odwiedzającego go programisty: "W jednej linii skryptu powłoki znajdziesz więcej natury Uniksa niż w dziesięciu tysiącach linii kodu C" Programista dumny ze swojej biegłości w języku C, odparł: "Jak to być może? Przecież to w języku C zaimplementowano jądro Uniksa!" [... dalsze wymiany "W jednej linii skryptu.." i "Ależ..."] Mistrz Foo odpowiedział: "To wszystko prawda. Niemniej jednak w jednej linii skryptu powłoki znajdziesz więcej natury Uniksa niż w dziesięciu tysiącach linii kodu C" Programista zaśmiał się i wstał, aby odejść, ale Mistrz Foo skinął na swojego ucznia Nubiego, który napisał na tablicy jedną linię skryptu powłoki. I rzekł Mistrz do programisty: "Mistrzu programisto, spójrz na ten potok. Czyż jego implementacja w C nie zajęłaby dziesięciu tysięcy linii? Programista mamrotał pod wąsem, analizując to, co napisał Nubi, aż w końcu musiał zgodzić się z Mistrzem. "A ileż godzin spędziłbyś implementując i sprawdzając ten potok w C?" "Wiele -- przyznał programista -- ale tylko głupiec poświęciłby czas na to, podczas gdy czeka na niego tyle wspaniałych zadań." "Więc kto lepiej zna naturę Uniksa? -- spytał Mistrz Foo. -- Ten kto pisze dziesięć tysięcy linii, czy ten kto dostrzegając pustość zadania z pisania rezygnuje?" Usłyszawszy to, programista doznał oświecenia.

Pokazuje też, że filozofia Uniksa to tak na prawdę ocenianie, które rozwiązanie jest lepsze.

I tutaj dochodzimy do dzisiejszej bolączki konsoli/powłoki. Ta nie jest przenośna. Skrypty pisane pod jedną powłokę nie będą działały pod inną powłokę. Skrypty pisane pod jedną powłokę nie będą działały pod tą samą powłoką JEŚLI wszystkie zależności nie będą spełnione.

Skrypty powłoki to rozwiązanie takie samo jak inne. Ma swoje zady i walety.

Mając to na uwadze przejdźmy do kolejnych problemów podkreślanych przez naszego ukochanego autora.

A może by tak Kit na integrację innych Kitów z konsolą?

*Kit to próba odpowiedzi na niejednolitość rozwiązań jakie mogą zapewnić powłoki. Sterowanie procesami? Rozbudowane ale niejednolite! Zarządzanie aplikacjami i ich zależnościami? (Mniej lub bardziej) Rozbudowane ale (totalnie) niejednolite! Zarządzanie uprawnieniami? (Mniej) Rozbudowane ale niejednolite!

Skrypty powłoki nie oferują oczekiwanego rozwiązania. A jak zauważył Mistrz Programista, kto chce poświęcić czas na ponowne wynajdywanie koła?

Istnienie Kit'ów jest więc zasadne. Rozwiązują konkretne skomplikowane sposoby. Pozostaje jeszcze kwestia trudności obsługi owych z poziomu skryptów.

Ta jest iluzoryczna. Kity wykorzystują DBus. A ten jak najbardziej jest obsługiwany z konsoli np. przez dbus-send. Do tego jest potrzebna specyficzna wiedza, ale ta jest dostępna.

Tak więc obsługa Kit'ów z konsoli jest możliwa!

Dzięki takiemu podejściu rozwiązano też problem niejednolitości. Nie tylko pomiędzy różnymi systemami, ale też pomiędzy możliwościami konsoli a zwykłych języków programowania.

Z Udisk jest podobnie. Jednolite rozwiązanie, dostępne z konsoli (tylko nie bezpośrednio), obsługujące nawet najbardziej skomplikowane konfiguracje.

systemd arcy-przestępca desktopowego półświatka!

Z powyższego tekstu uważny czytelnik może się zorientować, że integrację systemd ze skryptami powłoki zapewniają te same narzędzia co z *Kit'ami.

Pozostaje jeszcze kwestia złożoności systemd i przydatności tego poza "desktopami".

systemd jest bardzo modułowy. Cała gama funkcji i rozwiązań może być włączania i wyłączana z systemd podczas kompilacji lub przez pliki konfiguracyjne. A dokumentacja dokładnie opisuje wszystkie funkcje.

Tak samo developerzy systemd starają się aby jego "twarde" wymagania (czyli takie bez których systemd nie będzie w ogóle działać) były minimalne (glibc, libcap, dbus).

Oczywiście największą zaletą systemd jest jednolitość. Skrypty dla Init.d często były specyficzne dla dystrybucji i mogły powodować problemy jeśli chciało się je przystosować do obsługi innych dystrybucji (skrypty uruchomienia dziedziczą wszystkie problemy konsoli).

Ale systemd to nie tylko jednolity desktop, ale też serwery. O ile tak uruchamianie systemu nie odbywa się zbyt często (a przynajmniej taki jest cel), to całkowity czas kiedy serwer nie działa powinien być jak najmniejszy. A systemd jest szybki. Szybki restart czy zimny start jak najbardziej przemawiają do administratorów.

Zupełnie inaczej sytuacja ma się w chmurze i przy masowej wirtualizacji. Możliwość szybkiego startu setek lub nawet tysięcy instancji może oznaczać konkretne oszczędności, lub większy zysk. Dlatego RedHat stara się wprowadzić systemd do swoich serwerowych produktów.

Podsumowanie

IT w miejscu nie stoi i ciągle się rozwija. Nowe technologie, nowe problemy, nowe wyzwania. Linux też ciągle rozwija się aby sprostać tym wymaganiom. Nie jest więc niczym szczególnie niepokojącym, że ciągle trwa zdrowa dyskusja nad założeniami przyjmowanymi w przeszłości, ani w tym, że ciągle powstają nowe odpowiedzi na stare pytania które nabrały nowych znaczeń.

Nowoczesny Linux nie zdradził też w żaden sposób filozofii Unixa. Ta w końcu jest na tyle uniwersalna i ponadczasowa, że przetrwa wszystko inne ;)