Dlaczego nie Linux?

Dlaczego nie Linux? System wydaje się mieć wszystko co trzeba, by rozpowszechnić się na komputerach PC: publicznie dostępny, otwarty, z całkiem bogatą ofertą oprogramowania użytkowego, wolny od nacisków i ograniczeń nakładanych przez koncerny software-owe i wreszcie, co wcale nie jest najmniej ważne, można go mieć za darmo. Tyle tylko, że w praktyce zawsze znalazło się coś takiego, co mnie zniechęcało do tego systemu i w konsekwencji nie jest on dzisiaj zainstalowany na żadnym z moich osobistych komputerów (przypominam, że na tym blogu nie piszę o serwerach: tam Linux ma swoje stałe miejsce). Co to takiego? Najlepiej chyba będzie, jeśli opiszę na przykładach.

Podejście pierwsze: rok 1995

O Linuksie słyszało się już od jakiegoś czasu, ale jako o systemie eksperymentalnym, bardzo trudnym w obsłudze, raczej dla hakera¹ niż dla „zwykłego” użytkownika. Postanowiłem jednak sprawdzić, na ile system ten może stanowić alternatywę dla Windows na komputerze wprawdzie nie hakera (którym nigdy nie byłem i nie jestem), ale jednak zaawansowanego użytkownika. Nie ukrywam, że dodatkowym bodźcem stała się wprowadzona w lutym 1994 roku ustawa o prawie autorskim, zapowiadająca kres pirackim instalacjom Windows. Wprawdzie w pierwszej wersji przewidziano abolicję dla oprogramowania pozyskanego i zainstalowanego przed wejściem w życie ustawy, ale było oczywiste, że zapis ten nie oprze się naciskom ze strony lobby koncernów software-owych i rzeczywiście po jakimś czasie został zniesiony poprawką do ustawy.

Pobrałem instalację dystrybucji Slackware 2.2 w postaci obrazów dyskietek 3,5". Dyskietek było kilkadziesiąt. Cóż to była za operacja: do dyspozycji miałem modem o „zawrotnej” prędkości 2400 bit/s (tak, tak... bitów, nie megabitów). W dodatku przy ówczesnej jakości łączy telekomunikacyjnych zrywanie transmisji było na porządku dziennym, a i prędkość rzadko kiedy osiągała teoretyczne maksimum. Męczyłem się z tym jakieś dwa tygodnie (oczywiście nie siedziałem przy komputerze non stop, tylko wykorzystywałem wolne chwile), aż wreszcie miałem przygotowany zestaw nośników instalacyjnych.

Dysponowałem wówczas komputerem z procesorem AMD 486 100 MHz, 64 MB pamięci RAM i wolną powierzchnią dyskową około 2 GB, którą mogłem przeznaczyć na instalację Linuksa. Do codziennej pracy zainstalowany był Microsoft Windows 3.11 i działał całkiem sprawnie.

Podstawowa instalacja przebiegła bez większych problemów, jeśli nie liczyć czasu jej trwania. „Schody” zaczęły się dopiero wtedy, gdy spróbowałem uruchomić środowisko graficzne. Pomijam już problemy tego typu, że obraz na moim monitorze był przesunięty (a pod Windows było wszystko dobrze) i straciłem parę dni na szukanie w Internecie, analizę i poprawianie plików konfiguracyjnych, aż wreszcie uzyskałem właściwe położenie i rozdzielczość. Prawdziwy problem stanowiło koszmarnie długie uruchamianie się środowiska graficznego i bardzo wolna praca, w praktyce uniemożliwiająca uruchamianie jakichkolwiek aplikacji użytkowych poza x-terminalem, zegarem i gadżetem z ruchomymi oczami.

Okazało się, że wydajność mojej maszyny wystarczy od biedy do pracy z Linuksem w środowisku znakowym, o interfejsie graficznym właściwie nie ma mowy. Jako użytkownik systemu Windows nie chciałem rezygnować z pracy w stylu „dostajesz to, co widzisz” i wracać do konsoli znakowej. Stwierdziłem, że czas Linuksa jeszcze nie nadszedł.

Podejście drugie: rok 1999

Cztery lata trwało, zanim zdecydowałem się dać Linuksowi drugą szansę. Impulsem była dołączona do czasopisma PC World Komputer z grudnia 1998 r. płyta instalacyjna z dystrybucją S.u.S.E. Linux 5.3. Według opisu dystrybucja ta miała być bardziej „dla ludzi”, łatwiejszą instalację i konfigurację miało zapewniać zintegrowane narzędzie YaST (Yet Another Setup Tool).

Miałem wtedy maszynę z procesorem AMD K5 PR100 (mniej więcej odpowiednik Pentium 100 MHz), pamięcią RAM 128 MB i 5 GB wolnej powierzchni dyskowej.

Nie starałem się tym razem tworzyć konfiguracji mającej zastąpić system Windows. Chciałem raczej zobaczyć w jakim kierunku rozwinął się Linux od czasu moich pierwszych prób ze Slackwarem i czy stał się choć trochę bardziej przyjazny dla komputerów biurkowych.

Niewiele pamiętam z tego okresu. Przede wszystkim, jako niehakerowi, bardzo spodobał się YaST, dzięki któremu większość zadań związanych z instalacją i konfiguracją systemu mogłem wykonać bez edytowania skryptów. No, nie wszystkie, bo ciągle jeszcze miałem monitor i grafikę, które nie chciały poprawnie wyświetlać obrazu w pożądanej przeze mnie rozdzielczości bez poważnej ingerencji w ustawienia X-serwera. Poza tym stwierdziłem, i to już nie było pozytywne doświadczenie, że zestaw programów użytkowych dostarczonych na płycie dystrybucyjnej jest dla mnie zdecydowanie niewystarczający, zaś doinstalowanie nowych pociąga za sobą bardzo duże koszty: wymaga pobierania ogromnej ilości megabajtów z Internetu, a ja wciąż jeszcze miałem wtedy łącze modemowe i płaciłem za każdy bajt. Doszedłem zatem do wniosku, że czas używania Linuksa na moim osobistym komputerze jeszcze nie nadszedł, chociaż dystrybucja S.u.S.E. pozostała w mojej pamięci jako ta, do której być może warto będzie powrócić w przyszłości.

Podejście trzecie: rok 2001

Tym razem się zawziąłem. W oparciu o SUSE 7.0 postanowiłem zbudować instalację systemu operacyjnego w pełni obsługującą język polski (to znaczy polskie znaki i słowniki, interfejs pozostawiłem w języku angielskim) a także cały posiadany wówczas sprzęt, a było tego trochę: oprócz wspomnianej wcześniej jednostki centralnej opartej na procesorze AMD K5 PR100 z pamięcią 128 MB był jeszcze sprzętowy akcelerator DVD Creative dxr2, drukarka Lexmark 1000, skaner Plustek OpticPro 4800P, napęd dysków wymiennych Iomega ZIP 100 na port równoległy. Wszystko razem działające bezproblemowo pod kontrolą Windows 98.

Z tą konfiguracją męczyłem się całe dwa tygodnie (oczywiście nie siedząc stale przy komputerze, ale poświęcając prawie cały czas wolny), zaś uwagami do instalacji zapisałem cały szkolny zeszyt 16-kartkowy. Mimo to nie udało mi się osiągnąć całkowicie satysfakcjonującego rezultatu. A oto szczegóły:

• Akceleratora DVD w ogóle nie udało mi się uruchomić. Znalazłem wprawdzie jakiś stary projekt mający na celu obsługę tego urządzenia pod Linuksem, ale były dostępne tylko pliki źródłowe, w dodatku dostosowane do starszej wersji środowiska X Window. Musiałbym samodzielnie dokonać adaptacji, co by wymagało edycji źródeł i dogłębnej znajomości środowiska. Nie czułem się na siłach.
• Drukarka Lexmark 1000 jest typową drukarką „windowsową” i w owym czasie nie była jeszcze obsługiwana przez Linux. Znalazłem wprawdzie jakiś eksperymentalny hakerski sterownik, ale wykorzystywał on emulację PostScriptu. Efekt – strona, która z poziomu Windows drukowała się trzy minuty, pod Linuksem potrzebowała kilkunastu minut, przy czym system był tak obciążony, że podczas drukowania nie dawało się nic robić. Jakby tego było mało obsługiwany był wyłącznie nabój kolorowy, podczas gdy ja chciałem używać wymiennie koloru i czarnego. Tak więc obsługę drukarki zmuszony byłem uznać za niezadowalającą.
• Skaner Plustek OpticPro 4800P na listach kompatybilności sprzętu był (i jest nadal) wymieniany jako w pełni obsługiwany przez interfejs SANE. Sterownik (wówczas była to wersja, o ile dobrze pamiętam, jakieś 0.8.x) udało mi się pobrać i zainstalować. Pierwsze wrażenia były pozytywne, bo skaner ruszył. „Schody” zaczęły się, gdy spróbowałem zwiększyć rozdzielczość skanowania powyżej 100 dpi: z urządzenia dały się słyszeć przeraźliwe zgrzyty, listwa skanująca zaczęła się poruszać z jakąś dziwną, znacznie wolniejszą niż normalnie prędkością, po czym uderzyła w ograniczniki. Musiałem wyłączyć skaner z uwagi na groźbę jego fizycznego uszkodzenia. Dodam, że sprzętowa rozdzielczość skanera wynosi 300 dpi, zaś jego obsługa w systemie Windows (od 3.10 do 98, NT i 2000, do XP nie ma sterownika) nie napotyka na żadne trudności, niezależnie od rodzaju i prędkości portu równoległego. Z uwagi na powyższe, algorytm obsługi skanera w systemie Linux uznałem uznać za błędny.
• Instalacja sterownika do napędu Iomega ZIP wymagała kompilacji jądra systemu, a zatem pobrania całego środowiska programistycznego, z kompilatorem gcc, bibliotekami, źródłami jądra itp., w sumie około 200 MB danych. Sama kompilacja na moim sprzęcie trwała kilkanaście godzin. O dziwo, wszystko zakończyło się sukcesem i napęd zaczął działać. Zapomnieć musiałem jedynie o współdzieleniu portu równoległego (pod Windows 98 ZIP i skaner pracowały na tym samym porcie), czego Linux nigdy nie umożliwiał i nie umożliwia do dzisiaj. Sukces uznałem za okupiony zbyt dużym nakładem pracy i kosztów: pod Windows instalacja sterownika do ZIP-a trwa kilka minut, a rozmiar pliku instalacyjnego do ściągnięcia to kilkadziesiąt kB.

Mając gotową instalację Linuksa i działający na tej samej maszynie Windows 98 (na oddzielnych partycjach dyskowych) postanowiłem zrobić test szybkości działania programów użytkowych pod kontrolą obydwu systemów. Tak się złożyło, że miałem do dyspozycji pakiet aplikacji biurowych StarOffice 5.2 w wersji dla Windows i w wersji 5.1 dla Linuksa. Wprawdzie to nie dokładnie to samo, ale uznałem, że wersje są na tyle bliskie sobie, iż nie powinno to zbytnio wpływać na wynik, orientacyjnego w końcu, testu.

Po zainstalowaniu oprogramowania pod Linuksem (pod Windows używałem go na co dzień) i przeprowadzeniu testów z kilkoma przykładowymi plikami stwierdziłem, że praca z oprogramowaniem biurowym pod Linuksem jest orientacyjnie dwa razy wolniejsza, niż na tej samej maszynie pod Windows 98. Dotyczyło to zarówno czasu uruchamiania się programów, operacji na plikach, jak też czasu odpowiedzi programu na polecenia wydawane przy pomocy klawiatury lub myszy.

Tak więc w roku 2001 czas Linuksa na komputerze biurkowym w dalszym ciągu dla mnie nie nadszedł. Zbyt dużo pracy koniecznej do skonfigurowania systemu, problemy ze sprzętem, wolna praca, brak istotnych korzyści.

Lata 2010 – 2011

To nie było jedno podejście, tylko cała seria. Bezpośrednim bodźcem było zestarzenie się systemu Windows 98, który nie tylko stracił wsparcie ze strony Microsoftu, ale również ze strony nawet najbardziej konserwatywnych programistów aplikacji użytkowych. Chciałem zatem zbadać możliwość postawienia Linuksa zamiast (kosztownej) aktualizacji systemu Windows.

Dysponowałem już wówczas komputerem Siemens Scenic 800, którego konfigurację przedstawiłem w jednym z pierwszych artykułów. Komputer był początkowo wyposażony w 256 MB pamięci RAM, rozszerzonej później do 640 MB.

Testowanymi dystrybucjami były: OpenSuse 10 i 11, Ubuntu 10 i 11, Fedora 11, Mandriva 209 Spring, 2010 Spring, 2011.0, Mageia 1, Debian 5.0 Lenny i jeszcze kilka innych, mniej znanych.

Skąd tyle testowanych dystrybucji? Głównie z powodu jednego problemu: prawie żadna dystrybucja nie była w stanie wykryć i zainstalować sterownika do interfejsu PCMCIA z kontrolerem na magistrali ISA, zainstalowanego w moim komputerze. Nie byłby to wielki problem, gdyby nie fakt, że do połączenia z Internetem używałem (i używam do dzisiaj) modemu GSM Sierra Aircard 850 (wcześniej 860) w postaci karty PCMCIA właśnie, czym zaś jest (albo może raczej czym nie jest) Linux bez Internetu, to każdy, kto miał kiedykolwiek kontakt z tym systemem, wie doskonale.

Można by powiedzieć: sam jesteś sobie winien. Dlaczego Linux miałby obsługiwać jakiś egzotyczny kontroler, w dodatku na zabytkową magistralę ISA? Z dwóch powodów: po pierwsze, jest on wykrywany przez każdą wersję systemu Windows wprost „z pudełka”. Rozszerzenie jest rozpoznawane jako "Kontroler PCMCIA Plug and Play SCM SwapBox Family", a sterownik jest uniwersalny, wspólny dla całej grupy urządzeń. Czyżby Linux nie umożliwiał implementacji takiego uniwersalnego sterownika? Drugi powód jest poważniejszy: otóż napisałem, że prawie żadna dystrybucja nie była w stanie obsługiwać mojego kontrolera. „Prawie” to znaczy, że jedynym wyjątkiem okazała się Mandriva, wykrywająca urządzenie automatycznie i instalująca sterownik wprost z nośnika, bez konieczności szukania czegokolwiek w Internecie. To jednak oznacza, że linuksowy sterownik istnieje. Dlaczego nie mają go inne dystrybucje? Co ciekawe, nawet Mageia powstała jako odgałęzienie projektu Mandriva, już tego kontrolera nie obsługuje.

Interesująca okazała się sprawa z Debianem. Otóż podczas instalacji systemu zauważyłem, że karta modemowa zainstalowana w gnieździe PCMCIA dostała zasilanie i uzyskała połączenie z siecią komórkową, co jest sygnalizowane miganiem na zielono lampki kontrolnej. Jednak po zakończeniu instalacji i uruchomieniu systemu z dysku twardego modem był nieaktywny. To by świadczyło, że Debian ma właściwy sterownik, tylko z jakichś powodów nie jest on instalowany. Próbowałem pytać na forach dyskusyjnych Debiana: nikt nic nie wie.

Pozostałem zatem przy Mandrivie. Zainstalowałem wersję Mandriva One z płyty CD, żeby szybko stwierdzić, że wersja ta zawiera stosunkowo ubogi zestaw oprogramowania. Wszystko właściwie trzeba pobierać z Internetu, co przy połączeniu przez sieć GSM nie bardzo mi odpowiadało.

Spróbowałem zatem zainstalować Mandrivę Free, która z racji dystrybucji na płytach DVD oferuje więcej aplikacji w pakiecie i tu niespodzianka: po uruchomieniu instalatora okazało się, że „nie widzi” on ani dysku twardego, ani napędu DVD. To znaczy: nie widzi napędu, z którego sam wystartował! Tu aż chciałoby się zawołać, parafrazując znane powiedzenie: takie rzeczy, to tylko w Linuksie! Poradziłem sobie w ten sposób że zainstalowałem Mandrivę One, a płyty z Mandivą Free zdefiniowałem jako dodatkowe repozytoria.

Przyszła kolej na uruchamianie urządzeń peryferyjnych. Z góry założyłem, że nie będę uruchamiał napędu dyskietek Iomega ZIP (pamięci flash są znacznie wygodniejsze, szybsze i pojemniejsze) ani karty Creative dxr2 (jak się kiedyś nie udało, to po upłynięciu dłuższego czasu od zakończenia produkcji tym bardziej się nie uda). Chciałem jednak, aby pozostały sprzęt był w pełni obsługiwany. A tymczasem:

• Skaner Plustek Optic Pro 4800P działał, ale tylko do rozdzielczości 100 dpi. Błędy, które występowały w sterownikach sane 0.8.x po latach powtórzyły się w wersji 1.x. Być może nikt spośród społeczności zajmującej się Linuksem nie był zainteresowany wspieraniem tak starego urządzenia, ale mnie jako użytkownikowi nie uśmiecha się wyrzucanie sprawnego sprzętu tylko dlatego, że Linux go poprawnie nie obsługuje.
• Karta graficzna Ati All-In-Wonder zadziałała, ale tylko jako grafika. Zintegrowany na karcie tuner TV nie dał się uruchomić: Linux nie wspiera tego układu. Spróbowałem uzyskać obraz na odbiorniku telewizyjnym podłączonym przez wyjście TV-out, ale przy X-serwerze obsługującym układ Ati Rage Pro nie było to możliwe. Po długich poszukiwaniach w sieci znalazłem rozwiązanie: należy zainstalować X-serwer obsługujący standard VESA. Rzeczywiście: po instalacji tego X-serwera i ustawieniu „telewizyjnych” parametrów odświeżania, na podłączonym odbiorniku TV pojawił się obraz. Próba odtworzenia pliku video zakończyła się jednak kompletną porażką. Filmy odtwarzane płynnie na tym samym komputerze pod kontrolą Windows, pod Linuksem zacinały się niemiłosiernie. Wydajność serwera VESA okazała się nad wyraz marna.
• Pod Windows miałem skonfigurowane udostępnianie połączenia internetowego za pośrednictwem bezprzewodowej karty Planet. Niestety Mandriva nie wykryła tej karty i nie zainstalowała sterowników. Szukanie w Internecie na niewiele się zdało. Wpadłem na pomysł, jak się okazało niefortunny, aktualizacji jądra systemu do najnowszej wersji. Po zakończeniu tej operacji okazało się, że przestał działać modem GSM i straciłem połączenie z Internetem. Przeglądając log systemowy stwierdziłem, że przy inicjalizacji modemu generowany jest komunikat, iż nie można przypisać portu COM z powodu braku zasobów. Czyli: ze starym jądrem zasoby były, z nowym – zniknęły. Znowu: takie rzeczy, to tylko w Linuksie! Odechciało mi się dalszej zabawy.

Przy okazji instalacji Mandrivy 11 postanowiłem wypróbować nową wersję 4.x środowiska graficznego KDE. Koszmar! Na słabszym sprzęcie w ogóle nie daje się pracować, w dodatku nie ma bezpiecznej drogi powrotu do KDE 3. Jeśli Linux ma się rozwijać w kierunku efekciarstwa pożerającego ogromne zasoby mocy obliczeniowej komputera, jak to ma miejsce w przypadku Windows, to dla mnie nie stanowi żadnej alternatywy.

Mandriva 2011 okazała się ostatnią oficjalną dystrybucją tego systemu. Pod koniec 2011 roku projekt upadł. Wprawdzie ukazała się jeszcze beta wersji 2012 przygotowana przez społeczność już bez wsparcia firmy Mandriva, ale był to już naprawdę „łabędzi śpiew”. Tak więc „padła” ostatnia znana mi dystrybucja Linuksa obsługująca (choć nie do końca) posiadany przeze mnie sprzęt.

A więc co: mam zmieniać komputer? Kupować nowy modem, skaner, kartę graficzną? Zmieniać sieć bezprzewodową? Wydać pieniądze na sprzęt, żeby uruchomić „darmowego” Linuksa? Nie, dziękuję. Przynajmniej dopóki nie muszę.

Ostatnie podejście: zima 2012

Nie, nie próbowałem po raz kolejny instalować Linuksa na moim komputerze stacjonarnym. Poprzednie doświadczenia wystarczą mi zapewne na długo. Stawszy się jednak właścicielem notebooka Toshiba 3440CT chciałem spróbować, czy jakaś dystrybucja nie będzie w stanie zastąpić zainstalowanego na nim, bardzo już wiekowego Windows 98.

Ze względu na stosunkowo słabe parametry sprzętu, a przede wszystkim małą pojemność dysku twardego, zajętego w dodatku przez system Windows z którym na razie nie chciałem się rozstawać, wybór padł na Puppy Linux, minidystrybucję mającą możliwość uruchamiania z pamięci flash.

Pierwszy problem polegał na tym, że BIOS mojego komputera nie ma możliwości uruchamiania systemu operacyjnego z pendrive'a. To jednak niewielka przeszkoda. Wystarczyło zainstalować Plop Boot Manager (dostępny tutaj) i sprawa rozwiązana. Następnie przygotowałem startowy pendrive z systemem i rozpocząłem testowanie.

Pierwsze wrażenie było całkiem pozytywne. System wystartował i pracował dosyć żwawo, zważywszy korzystanie z pendrive'a a nie z dysku twardego, co stanowi dość istotny czynnik spowalniający, zwłaszcza że mój komputer posiada interfejs USB 1.1, a nie 2.0.

Dalej już tak dobrze nie było. System nie wykrył karty sieciowej SpeedTouch na PCMCIA. O ile o takiej marce zapewne mało kto słyszał, to o ORiNOCO wie już chyba każdy, kto choć trochę poważniej interesuje się sieciami bezprzewodowymi. Właśnie układ ORiNOCO, albo jakiś jego klon stanowi „serce” mojej karty sieciowej. Zaglądam do opisu sterownika dla Windows: ten sam sterownik obsługuje 64 modele kart sieciowych. A więc to nie jest żadna „egzotyka”, tylko de facto standard przemysłowy. Nie po raz pierwszy okazuje się jednak, że uniwersalne sterowniki są prawdziwą piętą achillesową Linuksa.

No to może na USB? Podłączam adapter inventel model UR05g. Tajwański, ale pod Windows bardzo dobrze działa. Nic z tego. Puppy Linux nie wykrywa takiego sprzętu.

Może zatem zrezygnować z domowej sieci bezprzewodowej (ale w imię czego!) i połączyć się z Internetem przez modem komórkowy? Wszak mam do dyspozycji modemy Sierra Aircard 850 i 860 na PCMCIA. Dalej nic z tego. System nie rozpoznaje sprzętu.

Tak więc znowu mam działającego Linuksa, ale bez możliwości połączenia z Internetem. Próbowałem „szczeniaczki” Slacko i Wary z tym samym skutkiem. Mam dosyć, zostaję przy Windows 98.

Co mi najbardziej przeszkadza w linuksie?

Przede wszystkim, jak łatwo wywnioskować z tego co napisałem powyżej, problemy ze sterownikami do sprzętu. Użytkownik Windows może się nie przejmować: może kupować to, co mu najbardziej pasuje ze względów użytkowych, finansowych, emocjonalnych czy jakichkolwiek innych, a sterownik, jeśli go nie ma w systemie, dostanie od producenta urządzenia.

W przypadku Linuksa trzeba mieć albo system zainstalowany przez producenta komputera (np. laptopa czy netbooka), co jest najlepsze bo wtedy wszystko pasuje, albo mieć sprzęt w miarę „na czasie”, niezbyt stary, bo stare sterowniki są usuwane z dystrybucji systemu i nie najnowszy, bo może się okazać, że nie zostały jeszcze opracowane, albo mieć po prostu szczęście, co się zresztą zawsze przydaje. Mało tego: nawet jeśli sterownik istnieje, to jeszcze nie znaczy, że da się łatwo zainstalować. Czasem trzeba kompilować moduły jądra, a to z kolei oznacza konieczność zainstalowania w systemie całego środowiska programistycznego: kompilatora, bibliotek, plików nagłówkowych, w dodatku wszystko musi być zgodne co do wersji z dokładnością do ostaniej cyferki po ostatniej kropce i zajmuje kilkaset MB na dysku. Jeśli celem jest zainstalowanie tylko jednego sterownika, na przykład do karty sieciowej, całość przypomina strzelanie do komara z armaty.

A co ze sterownikami od producentów? Dlaczego ich nie ma, a nawet jeśli są to obsługują tylko kilka komercyjnych dystrybucji, stanowiąc raczej wyjątek potwierdzający regułę?

Przede wszystkim nie jest możliwe opracowanie sterowników w postaci binarnej. Nawet dystrybucje Linuksa korzystające z tego samego modelu pakietów binarnych, jak rpm czy deb, różnią się szczegółami w takim stopniu, że pakiet z jednej dystrybucji nie pasuje bez przeróbek do drugiej. A najpopularniejszych dystrybucji jest co najmniej kilkanaście, wszystkich nie da się chyba zliczyć. W dodatku tam się wszystko ciągle zmienia. Nowe wersje jądra systemu pojawiają się co kilka miesięcy, czasem nawet tygodni, zaś sterowniki urządzeń, bardzo silnie związane z jądrem, z reguły nie dają się przenosić pomiędzy wersjami. Tak więc producent, który by się wpakował w coś takiego, miałby niekończącą się pracę z aktualizacją oprogramowania, na opracowywanie nowych modeli urządzeń pewnie by mu już czasu i środków nie starczyło.

Dlaczego zatem, zgodnie z postulatami środowiska programistów i hakerów związanych z ruchem wolnego oprogramowania, producenci (a przynajmniej większość) nie dostarczają sterowników w wersji źródłowej, co by pozwoliło społeczności na łatwe ich dostosowanie do dowolnej dystrybucji, albo nie udostępnią szczegółowej dokumentacji technicznej urządzeń, co by pozwoliło hakerom samodzielnie opracować dobre sterowniki? Myślę, że odpowiedź jest prosta. Takie działanie znacznie ułatwiałoby produkcję „klonów” urządzeń, albo ich funkcjonalnych odpowiedników, ujawniałoby myśl techniczną, która mogłaby komuś dopomóc, po dołożeniu własnych badań i usprawnień, do produkowania urządzeń lepszych lub tańszych, stanowiących trudną konkurencję na rynku. Dla postępu technicznego mogłoby to być nawet bardzo dobre, ale nie każdy producent chce się na coś takiego godzić. Moim zdaniem ma prawo.

Tak więc programiści linuksowi w wielu wypadkach skazani są na „inżynierię wsteczną” polegającą na analizie sterowników dla innych systemów operacyjnych (najczęściej Windows), „rozszyfrowywaniu” schematów urządzeń (w dobie układów scalonych o wysokiej skali integracji rzadko się to udaje, chyba że ma się do dyspozycji wyspecjalizowane laboratoria), analizie działania układów, a na koniec – na metodę prób i błędów. Prowadzi to nie tylko do ogromnego zaangażowania sił i środków, ograniczenia liczby obsługiwanych urządzeń, ale i do powstawania kodów obarczonych poważnymi usterkami, choćby takimi jak opisywałem na przykładzie mojego skanera.

Drugi problem, który mnie osobiście daje się we znaki, to zmienność i różnorodność systemów linuksowych oraz wpływ tych cech na oprogramowanie użytkowe.

W przypadku systemów Windows przez długie lata panowała zasada wstecznej kompatybilności. Nawet zmieniając system operacyjny na nowszy, nawet w przypadku takiego „skoku” jak od Windows 3.11 do XP nie byłem zmuszony do wymiany całego oprogramowania. Miałem i mam nadal dowolność w wyborze wersji aplikacji. Mogę aktualizować lub nie, jeśli na przykład starsza wersja z jakiegoś powodu (choćby ze względu na mniejsze wymagania systemowe) bardziej mi odpowiada. Jakiekolwiek aktualizacje i poprawki instalowane w systemie operacyjnym nie mają prawa wpływać na działanie zainstalowanego oprogramowania użytkowego, a „wypadek” jaki się przydarzył przy okazji service pack-a 2 dla Windows XP wywołał ogromne niezadowolenie użytkowników, chociaż dotyczył stosunkowo niewielkiej liczby aplikacji (za to „znaczących”, jak na przykład AutoCAD). Mogę używać nie zmienionej konfiguracji systemu przez wiele lat, a jeśli po jakimś czasie przyjdzie mi do głowy jakieś nowe zastosowanie, bez trudu znajdę i zainstaluję odpowiednie oprogramowanie, jeśli tylko jest przeznaczone dla aktualnie używanej wersji Windows. Nikogo (ani mnie, ani producenta oprogramowania) nie musi obchodzić, jakie poprawki mam (lub nie mam) w systemie. W szczególnych przypadkach koniecznych rozszerzeń, jak na przykład .NET Framework czy Visual C++ Runtime jest to jasno powiedziane, instalator tego „pilnuje”, a same rozszerzenia są łatwe do zdobycia i zainstalowania.

A jak jest w Linuksie? Najbezpieczniej jest, jeśli oprogramowanie użytkowe pochodzi z repozytoriów danej dystrybucji. Pakiety instalacyjne na ogół nie są wymienne nie tylko pomiędzy różnymi dystrybucjami (choć niby to Linux i to Linux), ale nawet pomiędzy wersjami tej samej dystrybucji. Pociąga to za sobą konieczność wymiany całego oprogramowania użytkowego przy każdej poważniejszej aktualizacji systemu, a pamiętać należy, że zmiany zachodzą tu znacznie częściej niż w przypadku Windows. No to może nie aktualizować? Zainstalować jakąś dystrybucję która działa na danym sprzęcie, zainstalować potrzebne oprogramowanie zgodne z tą dystrybucją i eksploatować do końca życia systemu? Zachęcające, tylko żeby po latach nie przyszło nam do głowy, że przydałby się jeszcze jakiś malutki programik do zastosowań, których kiedyś nie przewidzieliśmy. Wtedy się okaże, że nie możemy pobrać go z repozytorium, bo repozytoria zniknęły, paczka instalacyjna od nowszej wersji nie pasuje, ze źródeł skompilować się nie da, bo nie ta wersja kompilatora, bibliotek itp. Tak więc nie aktualizować, to stworzyć środowisko, które szybko się „zamknie” uniemożliwiając rozbudowę, zaś aktualizować, to ciągle grzebanie w systemie i zmienianie aplikacji. Ja na takie zabawy nie mam czasu. No a jeśli stara wersja jakiegoś jednego programu bardziej pasuje niż nowa, a dla innego nowsza wydaje się lepsza? Takie rzeczy, to niestety nie w Linuksie.

Trzecia sprawa, to uzależnienie systemu do Internetu. Może w krajach o bardziej rozwiniętej infrastrukturze teleinformatycznej nie stanowi problemu, że system musi być stale przyłączony do sieci i to przez łącze o dużej przepustowości i bez limitów transferu. Inaczej nic się nie da zrobić: każda aktualizacja systemu to ściąganie setek megabajtów, zainstalowanie najprostszego programu może wymagać tego samego ze względu na konieczność spełnienia różnych „zależności”, kompilacja programów dystrybuowanych w postaci plików źródłowych (choćby niewielkich) wymaga zainstalowania, potężnego objętościowo, środowiska programistycznego. Może jestem staroświecki (jako „dinozaur” mam chyba do tego prawo), ale w pełni doceniając zalety Internetu wolałbym być w sieci wtedy, kiedy chcę. Systemy „przywiązane” do Internetu jakoś mi nie leżą, a ściąganie ogromnych ilości danych w polskich warunkach może poważnie uderzyć po kieszeni.

Pomarzyć któż nam zabroni

Czasem się zastanawiam, jaki powinien być Linux, żeby na komputerach domowo – biurowych stanowić realną konkurencję dla Windows. Taka konkurencja byłaby z punktu widzenia użytkownika bardzo wskazana. Może wtedy włodarze Microsoftu zastanowiliby się głębiej nad swoją polityką wymuszania zakupów, śrubowania cen i kontrolowania komputerów swoich klientów. Wydaje mi się, że dla zaistnienia takiej konkurencji konieczne byłoby spełnienie następujących postulatów.

• Opracowanie uniwersalnego, wspólnego dla wszystkich dystrybucji binarnego pakietu instalacyjnego dla aplikacji. Taki pakiet winien zawierać instalator pozwalający automatycznie umieścić potrzebne pliki w systemie i skonfigurować aplikację do uruchomienia. Powinien być w miarę możliwości samowystarczalny, a jeśli miałyby występować jakieś „zależności”, to instalator powinien o tym informować, zaś do ich spełnienia powinno wystarczać zainstalowanie co najwyżej kilku dodatkowych pakietów.
• Opracowanie uniwersalnego, wspólnego dla wszystkich dystrybucji, niezależnego od wersji jądra systemu, binarnego formatu sterownika dla urządzeń peryferyjnych. Takie rozwiązanie mogłoby wymagać wprowadzenia pośredniej warstwy wirtualizacyjnej pomiędzy sterownikiem a jądrem.

Czy taki system byłby jeszcze Linuksem? Tego nie wiem. Nie słyszałem, żeby ktokolwiek planował rozwój systemu w takim właśnie kierunku, a nie będąc hakerem ani programistą systemowym sam nie mogę się do tego przyczynić. Tak więc marzenie pozostaje marzeniem.

1 Polska Wikipedia podaje dwa znaczenia słowa „haker”: osoba o wysokich praktycznych umiejętnościach informatycznych, albo osoba która wyszukuje i wykorzystuje luki bezpieczeństwa w oprogramowaniu komputerowym. Ja konsekwentnie będę używał określenia „haker” w tym pierwszym znaczeniu.