Motto na początek (inspirowane „Skrzypkiem na dachu”):

• Wszelkie darmowe unixy to dzieci komputerowych maniaków, a więc siłą rzeczy nie są dla zwykłych śmiertelników. Teraz łata się te systemy, aby je cokolwiek obłaskawić i przystosować dla mas. No, i pomimo wysiłków milionów “bazarowych” programistów idzie to topornie… A być może właśnie dlatego… - mówił Guru. Tewje milczał.
• Ja wiem… - Keyto nie wyglądał na przekonanego.
• Ech, Keyto. Linuksowe towarzystwo, by przyspieszyć prace zatrudnia za pieniądze programistów. To raz. A gdzie powstały unixy? To dwa. Nie były to systemy na Biurko, to trzy. KDE i GNOME są łatami, podsystemami, jeśli razi Cię słowo łata, dołączonymi do kompletnego systemu. Jak kiedyś Windows 3 był nakładką na DOS. Długo będziesz udawał, że tak nie jest? Nie chodzi o porównanie funkcjonalności, ale idei. Windows był od początku systemem łatwym.
• Masz rację – zgodził się Tewje.
• Ależ reb Tewje! UNIX, Linux, zwał jak zwał, ma zupełnie inną filozofię konstrukcji. Mówienie, że KDE to łata, to nieporozumienie! - Keyto zdawał się być lekko poirytowany i dłuższą chwilę wyłuszczał swoje racje.
• Masz rację – zgodził się Tewje.

W tym miejscu Michuk nie wytrzymał:

• Ależ, reb Tewje, jeśli on ma rację i on ma rację… Obaj naraz nie mogą mieć racji!

Tewje popatrzył na niego i powiedział po prostu:

• Masz rację.

A teraz po kolei, wyłuszczanie moich racji.

Rozdział 1: UNIX

Ta historia rozpoczyna się - jak to zwykle bywa - dawno, dawno temu, za górami, za lasami, morzami (a nawet oceanem), w Stanach Zjednoczonych Ameryki, w miejscu zwanym Bell Laboratories. W firmie owej stał komputer. Niby nic w tym nadzwyczajnego, ale w roku 1969, kiedy owe wydarzenia biorą swój początek, komputer nie był zjawiskiem powszechnym. Nie istniały jeszcze komputery osobiste, firmy Microsoft, Novell czy Apple. Żadnych flame wars… Ot, piękne, romantyczne czasy. A propos – czas pracy maszyn znanych nielicznym wybrańcom, czyli komputerów, był na wagę złota (wszak czas to pieniądz). I tu pojawił się problem. Pewna maszyna, dokładniej DEC, model PDP-7, stała bezczynnie. Nic więc dziwnego, że przydzielono do niej jednego z największych guru informatyki – Kena Thompsona, aby coś z tym fantem zrobił. Przecież komputer się marnuje! Tompson zwołał innych guru, w tym pracującego już wcześniej nad programowaniem systemów operacyjnych Dennisa Richie i wespół stworzyli wczesną wersję systemu UNIX. Rozwijali go jeszcze czas jakiś bez większego rozgłosu, wykorzystując w późniejszym okresie inne maszyny (na przykład PDP-11/20). Specjalnie dla UNIX-a opracowali język programowania „C”, a potem… Życie się bardzo skomplikowało.

Rozdział 2: Zasady

Dla tych, którzy tego nie wiedzą: programy komputerowe nie są tworzone tak, że „siada się do klawiatury i się pisze”. To mit, rozpowszechniany przez zamieszkujących miejsce zwane Holywood. Programy powstają w głowach ich autorów, przelewane są potem na papier (tak – na papier), nierzadko modelowane w postaci diagramów UML i dopiero gdzieś na końcu całego procesu implementowane. Implementacja to nic innego, jak nadanie konkretnych kształtów – konkretnych instrukcji kodu języka programowania - pomysłom opracowanym drobiazgowo wcześniej. Ważne jest to, że na samym początku konieczne jest przyjęcie jakichś fundamentalnych zasad, swoistego dekalogu, którego złamanie w okresie implementacji jest absolutnie niedopuszczalne. Porządek musi być, zwłaszcza w naukach ścisłych, zwłaszcza w matematyce i programowaniu. Inaczej program nie zadziała prawidłowo, co więcej - jego modyfikacje mogą być później niemożliwe.

Jak każdy system, tak i UNIX opiera się na pewnych fundamentach. Najważniejszy z nich?

Rozdział 3: Reguła KISS

Tak naprawdę jedyną, kardynalną zasadą przyświecającą twórcom ojca systemów Linux, BSD, Mac OS X i wielu innych, była reguła KISS. Wszystkie inne zasady to już jej konsekwencje. Niedaleko pada jabłko od jabłoni, zatem i owa zasada przeszła z matki na dzieci. Wzorcowo stosowana jest ona choćby w dystrybucjach Slackware, Arch czy Crux. Sukces ma wielu ojców, tak więc do sformułowania reguły KISS przyznają się informatycy (a dokładnie – wiąże się ją z hackerami z MIT), ekonomiści, matematycy, biolodzy… Wymieniać można długo. Jeśli ktoś interesuje się filozofią, wie, że podobną zasadę sformował nijaki William Ockham (tzw. Brzytwa Ockhama), który żył w latach (około) 1285-1349. Na pewno nie miał komputera i nie był ekonomistą (choć kto go tam wie). Osobiście sądzę, że reguła KISS jest stara „jak Matka Ziemia”… Ale, ale, może w końcu napiszę, co głosi.

KISS jest akronimem od „Keep It Simple, Stupid” (ang.), co po polsku znaczy „to ma być proste, głupku”. Jeśli komuś wydaje się to nieco obraźliwe – taki był cel. Obecnie rozwinięcie to trochę się łagodzi i funkcjonuje ono pod postaciami: “Keep it Simple and Stupid” (to ma być proste i głupie), “Keep It Short and Simple” (to ma być krótkie i proste) lub “Keep It Small and Simple” (to ma być małe i proste). Polacy nie gęsi i swój odpowiednik mają – BUZI (Bez Udziwnień Zapisu, Idioto). Nie wiem, kto to wymyślił, ale naprawdę genialny przekład. Do kompletu dodajmy jeszcze co pisał wspomniany Ockham (uwaga, będzie łacina): Non sunt multiplicanda entia sine necessitate - istnień nie należy mnożyć ponad potrzebę, co tłumaczy się też jako: Bytów nie mnożyć, fikcyj nie tworzyć, tłumaczyć fakty jak najprościej. I to sformułowanie cenię najbardziej..

Jak wiadomo, w programowaniu cel można osiągnąć różnymi drogami. Czy wszystkie są jednakowo dobre? Nie! Lepsze są te prostsze.

Są bowiem:

• prostsze do napisania,
• prostsze w konserwacji,
• prostsze w przerabianiu,
• prostsze w przekazywaniu projektu komuś innemu,
• prostsze w przenoszeniu na inne platformy sprzętowe,
• bardziej „odporne” na błędy i…
• często po prostu szybsze.

Z resztą jeśli nie programujecie – zapytajcie o zdanie jakiegoś doświadczonego programistę. Mała szansa, że się z tym nie zgodzi.

Pierwszą konsekwencją reguły KISS jest:

Rozdział 4: Reguła DRY

Don’t Repeat Yourself – nie powtarzaj się. Kiedy pisze się program, można postawić na dwie strategie: pisać kod linia pod linią, a kiedy zorientujemy się, że to co akurat mamy napisać już było, korzystamy z najlepszego przyjaciela informatyka, czyli sekwencji „kopiuj – wklej”. Nie jest to najlepsze rozwiązanie. Zamiast tego wymyślono tak zwane procedury (funkcje). Procedurę z powtarzającym się kodem piszemy raz, a wywołujemy ją wielokrotnie. Ale to jeszcze mało. Aby było to wygodne w użyciu, elastyczne i naprawdę spełniało zasadę prostoty, należy postępować według zasady:

Jedno zadanie – jedna procedura.

Otrzymamy wiele pojedynczych funkcji, mówiąc obrazowo „klocków”, z których każdy zapewni nam jakąś pojedynczą funkcjonalność. Kiedy jeden z klocków wymaga poprawy, nie ma sprawy – poprawiamy go, bądź też przepisujemy na nowo. Reszta kodu nawet się o tym „nie dowie”, byle klocek zapewniał identyczną funkcjonalność (i zgodność interfejsów programistycznych).

Zasada ta obowiązuje również w systemach operacyjnych. A już na pewno w rodzinie UNIX. Mówiąc nieco infantylnie, UNIX to kernel (silnik) tworzący środowisko (nie mylić ze środowiskiem graficznym…) i cała masa programików użytkowych – takich „klocków”, po jednym jako remedium na jeden problem. Kiedy mamy do rozwiązania problem złożony – z dostępnych „klocków” budujemy złożone rozwiązanie.

Rozdział 5: Prostota konstrukcji a prostota użytkowania

Zaznaczam raz jeszcze: prostota systemów z rodziny UNIX tyczy się ich konstrukcji. Nijak się to ma do prostoty użytkowania. Chociaż… popatrzmy na poniższy, głupiutki przykład:

srv@srv # ps aux | grep kowalski | 
grep program_obslugi | tee log.txt

Załóżmy teraz, że Kowalski nie wie co to jest polecenie ps, polecenie grep, tee i ten dziwny znaczek pionowej kreski. Nie wie zatem, jak to poskładać, aby działało. Niech zatem administrator zrobi mu skrypt i sprawa załatwiona.

Może bardziej przekonywujący przykład: powszechnie znany i lubiany program MPlayer. Jest to - przypominam - dość toporny w obsłudze program konsolowy. Choć sam go używam, nie mogę zmusić się do nauczenia jego komend na pamięć, bo… istnieje nań nakładka graficzna, która zapewnia mi odpowiednią funkcjonalność. Jeden problem – jedna procedura. Osobny program odtwarza film, osobny zapewnia mi interfejs. Sam MPlayer to świetny program. Nie podoba Ci się jego tekstowy interfejs? Napisz inny. Nie umiesz programować? Znajdź inny, już napisany. A jakże – istnieją. Jedna funkcjonalność (doskonała), aby w ogóle wyświetlić film, inna dla prostoty obsługi (wybierz ją sam).

Analogicznie jak w Mac OS X. System Darwin – zapewnia, że to w ogóle działa. Interfejs Aqua - jest bohaterem legendy.

Rozdział 6: Inne zasady

Reguła KISS implikuje jeszcze inne konsekwencje. Na przykład to, że wszystko jest plikiem. Złośliwi dodają: „nawet kiedy nie jest”. I cóż z tego? Doświadczeni programiści wiedzą, że fundamentalnych zasad trzeba się trzymać z żelazną konsekwencją. Inaczej cel nie zostanie osiągnięty, inaczej wpędzimy się w rolę mitycznego Syzyfa: już, już kończymy projekt, ale jeszcze to a tamto nie działa i poprawiamy od początku. Może to, jak pisałem wcześniej, wydawać się toporne i dziwne od strony użytkownika, ale niekoniecznie jest dziwne od strony konstrukcji systemu. I już kilkadziesiąt lat działa.

Podobnie to, że każde polecenie to osobny proces, że interpreter poleceń jest po prostu procesem użytkownika. Te fundamentalne zasady zostały przyjęte, sprawdziły się i działają. No i przynoszą korzyści.

Rozdział 7: Klocki

Podstawową korzyścią wynikającą z princypiów systemu UNIX jest to, że po pierwsze: każdy składnik może być wymieniony na inny, byleby zamiennik zachowywał przyjętą funkcjonalność. Nie podoba Ci się bash? Użyj tcsh. Nie podoba się KDE? Istnieje Xfce.

Osobną sprawą jest, iż przyjęta filozofia zdeterminowała niesamowitą elastyczność systemu. Od systemów wbudowanych, poprzez desktopy, serwery, mainframe, po superkomputery. Ale czy da się powiedzieć, patrząc na system w urządzeniu zwanym routerem, że to kompletny system? Bo…

Rozdział 8: Cóż znaczy: kompletny system?

Kiedyś pisałem artykuł w którym poruszyłem temat kernela i systemów operacyjnych w ogóle. Państwo pozwolą, że się zacytuję: jeśli chodzi o system operacyjny, to w przyrodzie funkcjonują „dwie definicje. Ogólnie, najczęściej, przyjmuje się, że system operacyjny jest to jeden program, który działa w komputerze nieustannie od momentu uruchomienia systemu aż do jego wyłączenia (bądź restartu). Wszystkie inne programy są programami użytkowymi. W tym ujęciu system operacyjny to pojęcie jednoznaczne z kernelem. Inaczej mówiąc, można postawić znak równości pomiędzy słowem kernel a technicznym pojęciem systemu operacyjnego. Jeszcze inaczej: kernel ma za zadanie stworzyć środowisko dla innych programów.

Powszechnie jednak określenia „system operacyjny” używa się dla wszystkich programów dostarczanych przez producenta w odpowiedzi na zamówienie na środowisko pracy. Stąd też przyjęło się mówić Linux na całość systemu, choć nazwa ta oznacza w istocie sam kernel.” Koniec cytatu.

Cóż zatem oznacza „dorabianie funkcjonalności”, bądź też, na przykład „łatanie systemu poprzez dodawanie na siłę środowiska graficznego”? (Patrz motto na wstępie.)

Jeśli przyjmiemy pierwszą definicję – sam kernel (Linux) to kompletny system operacyjny. Wszystko inne to aplikacje użytkowe. Zalicza się więc do nich i interpreter bash, i serwer grafiki, i programy środowiska KDE. O żadnym dorabianiu funkcjonalności nie ma mowy. A może właśnie jest mowa – tyle, że w każdym przypadku, niezależnie czy mówimy o programie GIMP, czy edytorze „vim”. Ciekawe, że w tym ujęciu w systemie Windows - lub OS/2 - nie jest inaczej. Też mają kernele i programy użytkowe. Można napisać, że Areo (interfejs Visty) jest dorobiony do kernela systemu Windows? W tym ujęciu, można.

Jeśli przyjmiemy definicję drugą… To nie ma o czym mówić, bo w tym ujęciu nie ma czegoś takiego jak „kompletny system”. Debian GNU/Linux to kompletny system i kropka. Tak samo jak GoboLinux, tak samo jak MS Windows XP, tak samo jak OS/2 Warp któryśtam. Tak samo jak system wbudowany w router czy firewall, czyż nie?

Posłowie

W powyższym tekście jedynie dotknąłem tematu. O filozofii systemów rodziny UNIX można napisać opasłe tomiszcze, w końcu system powstał blisko 40 lat temu. Chciałem jednak zwrócić uwagę na to, że co dla jednych jest wadą – dla innych stanowić może nieocenioną zaletę.

Przede wszystkim zaś na to, że nie wolno mylić fundamentalnej filozofii projektu, która zapewnia mu nieograniczone wręcz możliwości dostosowawcze z rzekomym nieprzystosowaniem go do potrzeb zwykłego użytkownika. W końcu - co obchodzi zwykłego użytkownika, co drzemie pod jego interfejsem graficznym? To, co jedni nazywają „łataniem”, ja nazywam dorabianiem nowych funkcjonalności i nie jest to wyłącznie zabawa w słówka. UNIX został tak właśnie pomyślany, aby w każdym momencie można było doń dopisywać wciąż nowe i nowe „klocki”. Nawet takie, o których jeszcze nam się dziś nawet nie śni.

P.S. Następny odcinek będzie mniej filozoficzny a bardziej konkretny, gdyż omówię w nim start systemu. Ale to już w nowym roku. Więc:

if( data_czytania < to_date( swieta ) )
	WriteLine( „Wesołych Świąt i szczęśliwego nowego roku” );
else if( data_czytania > to_date(swieta) and
	data_czytania < to_date( nowy_rok ) )
	WriteLine( „Szczęśliwego nowego roku” );
else
	WriteLine( „Wszystkiego najlepszego w nowym roku :)” );