r   e   k   l   a   m   a
r   e   k   l   a   m   a

Zwalczaj ogień ogniem: desktopowy Linux coraz mniej uniksowy, coraz bardziej jak Windows?

Strona główna Aktualności

Przez ostatnie kilka miesięcy zdarzyło się autorowi poruszyć kilkukrotnie kwestie związane z rozwojem opensource'owych systemów operacyjnych. Tematy związane z systemd, nowym demonem init dla Linuksa (i tylko dla Linuksa), czy rosnące trudności przenoszenia oprogramowania pisanego na Linuksa na systemy z rodziny *BSD okazały się całkiem interesujące dla P.T. Czytelników. Tym razem spróbujmy się więc przyjrzeć temu, co dzieje się z Linuksem z bardziej „filozoficznej” perspektywy. Dlaczego „filozoficznej”? Często używa się takich określeń, jak „filozofia systemu”, czy „filozofia oprogramowania”, mając na myśli fundamentalne założenia, czy ideologię stojącą za danymi rozwiązaniami. W takim to sensie będziemy mówili o „filozofii Linuksa”, czy „filozofii UNIX-a” – bo oczywiście nie o miłość do mądrości tu chodzi. A po co komu takie spojrzenie? Może choćby tylko po to, by zdać sobie sprawę z tego, czym Linux (dla purystów: GNU/Linux) kiedyś był, czym się stał i czym może stać się w przyszłości.

A sprawa ta powinna dla osób zainteresowanych technologiami informatycznymi być ważna. Bez względu na trendy rynkowe, Linux stał się jednym z kluczowych elementów infrastruktury IT tej planety. Od maleńkich urządzeń typu embedded, przez telefony, tablety, settopboksy, macierze NAS, po wysoce wydajne serwery i superkomputery – wszędzie tam znajdziecie jądro Linuksa, dostosowane do danej architektury, otoczone warstwą oprogramowania dopasowaną do wykonywanych przez dane urządzenie zadań. Tym jednak, co wywiera największy wpływ na rozwój Linuksa, nie są wcale potrzeby tych wszystkich urządzeń, lecz kwestia dla Linuksa zawsze trudna, zawsze kontrowersyjna – zastosowania desktopowe. Czemu tak jest, skoro odsetek użytkowników Linuksa na PC, nawet korzystając z najbardziej optymistycznych dla „pingwina” badań, nie przekracza 5 procent? Odpowiedź jest całkiem prosta: wśród deweloperów Linuksa, odsetek użytkowników Linuksa na desktopie na pewno mocno przekracza te 5 procent… a że bliższa koszula ciału, to i desktopowe potrzeby mają na rozwój tego systemu znacznie większy wpływ, niż sugerować by to miała rynkowa rola desktopów z Linuksem.

Korzenie Linuksa tkwią przecież jednak zupełnie gdzieś indziej, niż na desktopie. Choć rekurencyjny akronim, stanowiący nazwę tego systemu otwarcie głosi: Linux Is Not UNIX, to przecież nawet Richard Stallman nie jest w stanie zaprzeczyć, że filozoficznie i historycznie Linux wyraźnie wywodzi się z wszelkiej maści Uniksów, których architektura powstawała w latach siedemdziesiątych i osiemdziesiątych zeszłego stulecia. Mamy więc monolityczne jądro, zajmujące się obsługą procesów, siecią, obsługą peryferiów i dostępem do systemu plików, mamy warstwę sterowników sprzętowych, bądź wbudowanych w jądro, bądź dołączanych jako moduły, mamy warstwę użytkownika, implementującą bibliotekę standardową języka C (libc), mamy jakąś powłokę systemową (shella), obsługę wielu użytkowników, warstwę graficznego interfejsu (zwykle X Window System). Cała ta architektura znajduje odbicie w standardzie POSIX (akronim od Portable Operating System Interface), wymyślonym w latach osiemdziesiątych, aby zachować zgodność oprogramowania pomiędzy licznymi uniksopodobnymi systemami, takimi jak AIX, HP/UX, IRIX, UnixWare czy Solaris. Oprócz zgodności z POSIX i wywodzenia się z oryginalnego Uniksa z Bell Labs, systemy te miały jedną rzecz wspólną: uruchamiano je przede wszystkim na dużych serwerowych maszynach, były więc projektowane z myślą przede wszystkim o takich zastosowaniach.

Gdy powstawał Linux, na desktopach w praktyce istniało tylko Windows – radząc sobie z desktopowymi potrzebami całkiem dobrze. System Microsoftu musiał przejść długą drogę, aby pod marką Windows Servera stać się konkurencją dla uniksopodobnych serwerowych OS-ów, ale równie długą drogę musiał przejść Linux, by choćby próbować stać się konkurencją dla Windows na desktopie. Na dziś na pewno podróż ta lepiej udała się Microsoftowi – tam gdzie kiedyś widzieliśmy AIX-y czy HP-UX-y, tam coraz częściej można spotkać Windows Server, ale nie to jest przedmiotem naszych rozważań. Idąc w stronę zastosowań desktopowych, Linux się zmieniał – i z roku na rok było w nim coraz mniej filozofii Uniksa.

Czym jest ta filozofia Uniksa? Mike Garncarz napisał swego czasu książkę pt. „The Unix Philosophy”, mówiącą o tym, jak oprogramowanie powinno wyglądać, by być zgodne z duchem Uniksa. Oto jego dziewięć tez:

  1. Małe jest piękne.
  2. Niech każdy program robi jedną rzecz, ale dobrze.
  3. Buduj prototypy tak szybko jak to możliwe.
  4. Przenośność jest ważniejsza od wydajności.
  5. Przechowuj dane w prostych plikach tekstowych.
  6. Wykorzystuj już napisany kod wielokrotnie.
  7. Wykorzystuj skrypty powłoki by zwiększyć przenośność i wielokrotność zastosowań.
  8. Unikaj zaborczych interfejsów użytkownika.
  9. Niech każdy program działa jak filtr danych.

Piękne to tezy, ale czy są one tym, czego mogliby chcieć użytkownicy desktopów? Trudno definitywnie odpowiedzieć na to pytanie, ale jedno jest pewne – odkąd Linux zaczął coraz lepiej nadawać się do zastosowań desktopowych, coraz mniej było w nim Filozofii Uniksa. Przyjrzyjmy się najbardziej wyraźnym przykładom:

  • Wszystkie dystrybucje GNU/linuksowe powinny trzymać się standardowej hierarchii systemu plików (FHS). Hierarchia ta to nic innego jak tylko formalizacja hierarchii systemu plików z BSD, opisująca zastosowania tych wszystkich katalogów w rodzaju /sys, /lib, /proc, /usr – i wcale się jakoś zasadniczo nie różniąca od tego, co było w Uniksie Version 7 w 1979 roku. Powinny, ale coraz częściej zaczynają się od FHS odżegnywać. Przykładowo Fedora stawia na wrzucenie wszystkiego co się da do /usr i tworzenie jedynie symbolicznych linków w miejscach, gdzie FHS ich oczekuje. Podobnie też coraz częściej media montowane są przez Udisk w taki sposób, że praca z nimi z konsoli tekstowej staje się bardzo niewygodna. Czy deweloperzy Udiska się tym przejmują? Skądże – otwarcie deklarują, że ich program nie jest przeznaczony do wywoływania w skryptach czy interfejsie tekstowym. Słusznym sposobem rozmawiania z Udiskiem jest wysyłanie jego demonowi komunikatów przez interfejs D-Bus. Twórcy Uniksa obracają się w grobach.
  • Przez ostatnie kilka lat w Linuksie namnożyło się różnych Kitów. Mamy ConsoleKit, PolicyKit, PackageKit itp. Wszystkie one są praktycznie nie do wykorzystania przez skrypty, za to łatwo wywołuje się je przez ich interfejsy programowania. Wszystkie one też stały się niezbędne, by w ogóle desktopowego Linuksa uruchomić. A jak się zachowują? Ano ze zgoła nieuniksowym rozmachem – taki ConsoleKit potrafi odpalić sobie kilkadziesiąt procesów, zarządzając ich interakcjami z ze zwykłymi uniksowymi procesami (pomyślano go jako rozwiązanie pomostowe) w dość skomplikowany sposób.
  • W zeszłym roku praktycznie dokonało się przejście linuksowego mainstreamu na demona systemd. Kiedyś żartowano, że danemu oprogramowaniu brakuje tylko kuchennego zlewu do kompletu funkcjonalności... patrząc na dokumentację systemd przestaje to być śmieszne. Demon ten robi wszystko, co się tylko da – nie tylko zastępuje starego inita, ale też integruje się ze wspomnianymi Kitami (a nawet je zaczyna zastępować), zarządza dyskami, uwierzytelnieniem użytkowników, i usługami sieciowymi, a kontroluje się go przecież nie przez proste skrypty, lecz tekstowe pliki z opcjami, parsowane następnie przez binarne narzędzia. Zostaje tylko wyrzucić tekstowe pliki, zastępując je centralnym Rejestrem – i będziemy mieli tak pięknie jak w Windows.

Jeszcze więcej takich przykładów można by znaleźć w rozwoju linuksowych desktopów, takich jak Gnome czy KDE, coraz trudniejszych przecież do przeniesienia na inne uniksopodobne systemy. Wyraźnie widać trend rozwoju Linuksa nie jako następcy komercyjnych Uniksów, ale jako opensource'owego desktopowego OS-a, który miałby być wygodną alternatywą dla Windows, dla ludzi, którzy wcześniej z „okienek” korzystali. Nie trzeba się już przejmować przenośnością kodu, można zapomnieć o uniksowych gniazdkach i rurach, skoro mamy do rozmów między procesami D-Bus, porzuca się pisanie skryptów, zastępując je binarnymi narzędziami czytającymi płaskie pliki konfiguracyjne…

Pozostaje tylko czekać, aż te trendy odbiją się na rozwoju samego jądra. W końcu te wszystkie wytyczne filozofii Uniksa miały jeden powód – uczynić życie sysadminów lepszym. Ale dziś większość działających na świecie instancji Linuksa nie ma żadnego administratora, potrzeby tej grupy stały się drugorzędne, więc z czasem zacznie się myśleć o planistach (schedulerach) budowanych czysto pod desktop, czy też stałym binarnym interfejsem jądra dla sterowników, by można było je instalować na Linuksie tak, jak robi się to na Windows.

Nic w tym złego, w końcu Linux Is Not a UNIX. Problem pojawi się dopiero wtedy, kiedy ktoś zechce przenosić oprogramowanie, nawet niekoniecznie już na jakieś BSD, ale np. na OS-a X czy Androida. Szybko odkryje, że oprogramowania pisanego dla Linuksa już się nie przenosi – trzeba je przepisywać od nowa, gdyż zależy ono od tak wielu monolitycznych komponentów standardowego desktopu Linuksa, że na niczym innym niż desktopowy Linux nie pójdzie. Może nawet przyjdzie moment, że na nowo trzeba będzie wymyślać specjalnego Linuksa dla serwerów i chmur?

r   e   k   l   a   m   a
© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.