„Unix jest bardzo prosty. Potrzeba jednak geniusza, aby zrozumiał tę prostotę” – Dennis Ritchie
Powyższe zdanie przypomniał mi ktoś, kto zapytał, co Dennis Ritchie powiedziałby o Uniksie „40 lat później i po wprowadzeniu systemd”.
Myślę, że Dennis powiedziałby to samo.
Większość ludzi, którzy mówią o Uniksie (oraz GNU/Linuksie) jako „nieprzyjaznym” lub „trudnym” systemie, najczęściej porównuje jego interfejs albo do systemów Apple, albo do Windowsa. Interfejs graficzny Uniksa, wydawany przez wielu twórców dystrybucji (Debian, Ubuntu, Mint, Red Hat, SUSE i dziesiątki innych), oparty jest (w dużej mierze) na dwóch zupełnie różnych zbiorach kodu źródłowego (KDE lub Gnome) i ma kilka różnych pomysłów na pulpit.
Zarówno macOS, jak i Microsoft Windows były zaprojektowane przez firmy, które z góry określały, jak ma wyglądać ich interfejs i jak powinien działać, co jest znacząco innym podejściem.
Pod interfejsem graficznym Uniksa i GNU/Linuksa znajduje się interfejs wiersza poleceń, nazywany „powłoką”, złożony z setek małych programów, które są ze sobą luźno powiązane poprzez „strumieniowanie i filtry”. Programy te przestrzegają luźnej konwencji nazewniczej, posiadają podobne opcje, wykorzystują podobne nazwy plików i znaki specjalne, które pozwalają im łączyć się razem w niezwykle potężne „skrypty powłoki” wykonujące różne zadania. Niestety, jak w wielu językach naturalnych, chociaż podstawowe słowa i gramatyka są takie same, od czasu do czasu zdarzają się „wyjątki”, które sprawiają, że dany język jest trudniejszy do opanowania.
Z biegiem czasu, nawet podstawowa składania „powłoki” zmieniła się, gdyż ludzie przyglądali się problemom, które próbowali rozwiązać i modyfikowali „powłoki”, które (w większości) były „kompatybilne w przód”. Bourne Shell, C Shell, KornShell i Bourne Again Shell (Bash) – wszystkie te „powłoki” próbowały usprawnić na swój sposób składnię poleceń.
Ludzie narzekają na „tajemniczość” nazw poleceń, ale zapominają o kilku kwestiach. Po pierwsze, Unix był tworzony na bardzo powolnych terminalach, często wypisujących jedynie pięć znaków na sekundę. Długie, opisowe nazwy poleceń oznaczały nie tylko dłuższe ich wpisywanie (i drukowanie), ale też większą ilość zużytego papieru, pamięci masowej i innych cennych zasobów. Oczywiście, dzisiaj nie jest to problem, ale nazwy poleceń zdefiniowano dawno temu.
Po drugie, „opisowe” nazwy mogą być „opisowe” jedynie w języku, w którym powstawały. Polecenie DIR w DOS-ie było „opisowe”, jeśli znaliśmy angielski i zdawaliśmy sobie sprawę z tego, że oznacza „DIRECTORY”. Dla Hiszpana lub Włoszki nie będzie już tak opisowe, a dla Japonki lub Chińczyka całkowicie utraci swą opisowość. ls, które oznacza „list”, czyli to, co w sumie robi to polecenie, w angielskim jest opisowe. Trudniej jest z opisowością awk, chyba że zdajemy sobie sprawę z tego, że program był napisany przez trzech programistów, których nazwiska zaczynały się od „a”, „w” i „k”.
Po trzecie, interfejsy graficzne są zwykle dobre, jeśli mamy do czynienia z kilkoma obiektami, na których wykonujemy operacje, i jeśli definiujemy je tak, jak projektant interfejsu przewidział. Jednak jeśli zaczynamy pracować z setkami lub tysiącami obiektów, które mogą być niezgodne z tym, co programista miał na myśli, łatwość obsługi naszego interfejsu graficznego gdzieś się zatraca.
Pewien mój przyjaciel zajmował się trzema tysiącami systemów serwerowych w dużym niemieckim banku. Przewodził czterem administratorom systemu. Zapytałem go, dlaczego korzysta z GNU/Linuksa zamiast Windowsa NT. Powiedział: „Jeśli chciałbym używać Windowska NT, potrzebowałbym 2999 administratorów”.
Aktualnie dostępne są programy do administrowania siecią, które pomogłyby mu zarządzać tymi trzema tysiącami systemów WNT, ale skrypt powłoki wykonywał to zadanie równie dobrze.
Unix (i Linux) to w dalszym ciągu „proste” systemy, ale ta prostota musi się balansować z efektywnością i siłą na rynku.
Można się kłócić, czy systemd jest potrzebny, szczególnie jeśli mówimy o pojedynczym laptopie lub sieci LAN. Ludzie twierdzą, że w latach 80. XX w. systemd byłby niepraktyczny, ale teraz lub w przyszTo, co większość ludzi uważa za rzecz „złożoną”, jest po prostu „inne”. Kiedy już się czegoś nauczą, zdają sobie sprawę z tego, że „złożoność” często sprawia, że wykonanie zadania jest łatwiejsze niż próby zmuszenia interfejsu graficznego do realizacji czegoś, czego jego autor nie przewidział.
O jednej kwestii powinna pamiętać każda osoba związana z wolnym oprogramowaniem: nie powinno się w relacjach z nowicjuszami stwarzać pozorów, że trzeba być „geniuszem”, aby korzystać z Uniksa i GNU/Linuksa. To ich jedynie zrazi. Zamiast tego warto im pomóc zacząć, by przekonali się (jak wielu innych przed nimi), że Unix i GNU/Linux są naprawdę przyjazne.
Nasz świat jest coraz bardziej złożony. Wyzwaniem jest opanowanie tej złożoności w taki sposób, że ludzie ją zrozumieją i będą w stanie z nią pracować. Do tego trzeba geniuszy.
Autor:
Jon „maddog” Hall jest autorem, wykładowcą, informatykiem i jednym z pionierów Wolnego Oprogramowania. Od 1994 roku, kiedy po raz pierwszy spotkał Linusa Torvaldsa i ułatwił przeniesienie jądra na systemy 64-bitowe, pozostaje orędownikiem Linuksa. Obecnie jest prezesem Linux International®.
