Oddzielenie mechanizmu od polityki czyli dlaczego Uniksy wydają się trudne?

Od razu zaznaczę, że (wzorując się na Ericu Raymondzie) gdy piszę o Uniksie mam na myśli dowolny system pochodzący od kodu pierwszego Uniksa z Laboratoriów Bell lub jego pochodnych, bez względu na to czy może być uznany za UNIX pod względem prawnym czy nie. Zwłaszcza FreeBSD i Linux są Uniksami.

Projektanci Uniksa i jego pierwsi programiści kierowali się pewnym niepisanym kodeksem zasad, które należy stosować przy projektowaniu i kodowaniu oprogramowania. Były one później w różny sposób opisywane, posłużę się tutaj dość zgrabną syntezą przywoływanego już Erica Raymonda (The Art of Unix Programming). Czwarta z podanych przez niego reguł brzmi:

Reguła oddzielania: Oddzielaj politykę od mechanizmu; oddzielaj interfejsy od głównej części programu.

Uzasadnieniem tej reguły jest fakt, że zbiór polityk dotyczących np. interfejsu zmienia się dość często. Jej trwałe połączenie z mechanizmem (engine) programu sprawia, że po pierwsze sama polityka często nie odpowiada nowym oczekiwaniom użytkowników, a po drugie próby zmieniania polityk kończą się często destabilizacją engine'u. W tradycji uniksowej oddzielenie interfejsu od modułów wykonawczych jest często realizowane przez osobne projektowanie tzw. front-endu i back-endu. Przykładem może być apt i Synaptic, Smplayer i mplayer, etc. Inną metodą jest np. pisanie bibliotek usługowych w C, które będą sterowane jakimś osadzonym językiem skryptowym. Przykładem takiego podejścia jest Emacs i stosowany przezeń język Lisp. Sztandarowym przykładem oddzielania mechanizmów od polityki jest system X. Serwer X potrafi rysować jedynie najprostsze elementy typu linie, elipsy czy pojedyncze piksele. Nie dostarcza żadnego z elementów interfejsu i nie zajmuje się obsługą okien. To zadanie należy do menedżerów okien, posługujących się odpowiednimi bibliotekami np. GTK czy Qt.

Dla zaawansowanych użytkowników stanowi to o potędze systemów Uniksowych, które można bardzo konkretnie dostosować do potrzeb użytkownika. Wolność w Uniksie to nie tylko wolność licencji, ale również wolność wyboru! Niestety, dla początkujących użytkowników stanowi to często barierę nie do pokonania. Kosz tego rozwiązania jest bowiem taki, że kiedy użytkowników może określić politykę, najczęściej musi ją określić. Nowicjusze, często przytłoczeni bogactwem inwentarza, wracają do systemów "prostszych". Niemniej, o słuszności reguły oddzielania można się przekonać chociażby przeglądając zrzuty ekranu środowisk KDE czy GNOME od pierwszych wersji do chwili obecnej. Style interfejsu zmieniają się dość szybko, ale podstawowe funkcje serwera X pozostają bez zmian. Co jednak zrobić z użytkownikami, którzy doświadczają od początku zetknięcia z Uniksem konieczności nieustannego wyboru: BSD czy Linux, Debian czy Fedora, KDE czy GNOME, .rpm czy .deb, apt‑get czy aptitude itp...?

Wydaje się, że z myślą o tych użytkownikach powstały dystrybucje mające działać out-of-box. W Linuksie będzie to Ubuntu, w Uniksach rodem z Berkeley: PC‑BSD. Wykrywają elegancko sprzęt, instalują sterowniki do kart graficznych, upraszczają życie dostarczając określone środowisko i pakiet narzędzi. Jest w tym jednak pewne niebezpieczeństwo. Systemy te, moim zdaniem, często przyzwyczajają użytkowników do lenistwa i wygodnictwa, unikania samodzielnego rozwiązywania problemów. W konsekwencji zamiast zmniejszać liczbę zdezorientowanych użytkowników często zwiększają liczbę użytkowników nierozgarniętych. Nie dotyczy to może w takim stopnie PS‑BSD co Ubuntu, ale jednak. Idealny system uniksowy powinien być łatwy do ogarnięcia, ale jednocześnie motywujący do dalszego rozwoju. Wcielonego ideału pewnie nie ma, dla mnie najbliżej niego znajduje się Debian. Plasuje się gdzieś pośrodku między Uniksem ekstremalnie łatwym i rozleniwiającym (Ubuntu) a Uniksem ekstremalnie trudnym, często demotywującym (FreeBSD). Prosty, ale potężny instalator i narzędzia konfiguracyjne, przyjazna społeczność oraz świetna dokumentacja sprawiają, że chce się poznawać system, iść w głąb. Po standardowej instalacji wszystko działa, ale jednocześnie użytkownik czuje się zachęcony do zajrzenia pod maskę. Ułatwia start, ale nie odbiera wolności. Oczywiście wiele osób nawet używając Ubuntu będzie chciało rozwijać swoją znajomość systemu i umiejętności obsługiwania go, wielu jednak pozostanie w miejscu.

Wystarczy zajrzeć na popularny polski serwis (a nawet "centrum"...) dotyczący Ubuntu, żeby się o tym przekonać: setki wpisów o zmianie tapet i dyletanckie podejście do opisywanych zagadnień to tylko niektóre z jego cech charakterystycznych. W tym świetle trzeba podkreślić bohaterską wręcz cierpliwość moderatorów z forum ubuntu.pl, którzy przypominają o konieczności przejrzenia poprzednich wpisów zanim się opublikuje nowy, o czytaniu FAQ, etc. Uważam, że jest to bardzo pedagogiczne podejście do tematu :‑)

Ostatecznie dochodzimy do szerszego zagadnienia: dla jakiej grupy użytkowników są przeznaczone systemy uniksowe? Początki znamy - był to system pisany przez programistów, dla programistów. Jest jednak również faktem, że pierwszą killing-app Uniksa był troff - zestaw narzędzi do składu tekstu, a więc oprogramowanie przeznaczone dla użytkowników nietechnicznych. Jest to pewien paradoks tego systemu. Jestem przekonany, że potencjalnie każdy może używać Uniksów w domu lub w pracy, ale nie każdy będzie w stanie przekroczyć barierę mentalną i techniczną, aby się na to zdobyć. Kluczową sprawą jest chęć rozwoju swoich umiejętności i znajomości obsługi komputera i systemu operacyjnego. Co ciekawe, FreeBSD w przeciwieństwie do Linuksa wcale nie chce przyciągnąć do siebie jak największej liczby osób, nie obiecuje gruszek na wierzbie, ale z pewnym dystansem pokazuje możliwości systemu i zachęca do wypróbowania. Z drugiej strony trudno dziwić się rzeszom użytkowników Linuksa, którzy przekonują, że tego systemu bez problemu można używać na desktopie lub w biurze. To prawda, można go używać bez problemu, ale nie każdy będzie do tego zdolny. Widzę to chociażby po mojej żonie: usunąłem jej na laptopie Vistę i zainstalowałem Debiana Squeeze z KDE 4 - system chodzi sprawnie, szybko i stabilnie, jest ona zadowolonym użytkownikiem Linuksa. Ale czy sama poradziłaby sobie z instalacją i konfiguracją? Wątpię.

Swoją drogą uwielbiam sytuacje, gdy siedzę na Debianie, z Amaroka lecą miłe dźwięki, Firefox wyświetla strony, w tle siedzi OpenOffice, a ja czytam na jakimś forum, że Linux nie nadaje się na desktop, że jest taki i owaki. Prawie zawsze jest to krytykowanie według schematu: "nie umiem tego obsłużyć, więc jest do niczego". Ta naiwna krytyka jest dla wielu użytkowników Linuksa powodem do uśmiechu. Bodaj jedyną sytuacją, kiedy można poczuć się zaniepokojonym epitetem "linuksiarz" jest wizyta na forum poświęconym BSD. Tak, tam "linuksiarz" oznacza zazwyczaj nierozgarniętą łajzę, której wydaje się że cokolwiek już wie o obsłudze Uniksa...

Podsumowując: pierwotną grupą docelową Uniksa byli programiści, w związku z czym projektanci systemu i narzędzi nie przejmowali się np. złożonymi interfejsami. Co więcej oddzielając engine od interfejsu często umożliwiali obsługę jednego programu na wiele sposobów, gwarantując tym samym rozszerzalność narzędzi i zwiększając wolność użytkowników. Jednak dla osób przyzwyczajonych do zasady Jedynego Słusznego Sposobu często Linux wraz ze swoim bogactwem wydaje się zbyt skomplikowany i zniechęcający. Jak to zmienić? Chyba nie ma złotej metody. Unix musi pozostać Uniksem, ale można pokazać potencjalnym użytkownikom, że to co uważają za wadę tego systemu (złożoność) jest jego główną zaletą, która nawet im pomoże rozwinąć się i polepszyć umiejętności techniczne. I na koniec cóż z tego, że jak podkreślają niektórzy, w zastosowaniach deksktopowych Unix ma zaledwie nikły procent udziału. Jeszcze w pierwszej połowie XX wieku przyzwoite wykształcenie też było udziałem niewielkiej grupy społeczeństwa, ale to przecież nie jest wadą wykształcenia?