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

Zmiany w Ubuntu doprowadzą do rozłamu w ekosystemie Linuksa?

Strona główna Aktualności

Pisanie oprogramowania na Linuksa powinno być łatwe: dobre wysokopoziomowe biblioteki, świetny kompilator GCC z narzędziami wspomagającymi, dostęp do zaawansowanych IDE, od Eclipse po Kdevelop. Jednak tak jakoś już jest, że wielu niezwiązanych ze środowiskiem Open Source programistów nie chce nawet myśleć o pisaniu na Linuksa – i to wcale nie dlatego, że byłoby to marnotrawieniem czasu na mało popularną (w porównaniu choćby do OS-a X) platformę. Problem jest w czymś innym – w rosnącej niekompatybilności Linuksów ze sobą.

Jeszcze w pierwszych latach XXI wieku wydawało się, że pomimo wielkiej swobody wyboru, jaką cieszyli się użytkownicy Linuksa na swoich desktopach (aż za wielkiej, chciałoby się powiedzieć), sprawy idą w dobrym kierunku. Inicjatywy takie jak freedesktop.org pozwalały na budowanie aplikacji, które będą działały na praktycznie każdym desktopie uruchamiającym X Window System (choć w praktyce dotyczyło to przede wszystkim KDE i GNOME), a Free Standards Group i Linux Standard Base dbały o to, by zachowana była także zgodność na niskim poziomie. I działało to dobrze – większość „linuksowego” oprogramowania dało się skompilować też na FreeBSD, zachowana była też binarna zgodność między dystrybucjami, do tego stopnia, że statycznie linkowane aplikacje z paczek RPM RedHata, można było po przepakowaniu uruchomić np. na Debianie czy Slackware.

Efekty tych wysiłków widoczne są do dzisiaj – wciąż można używać tych samych plików konfiguracyjnych i konsolowych narzędzi do zarządzania OpenSUSE, Fedorą, Arch Linuksem czy Mandrivą. Jak zapewne zauważyliście, na liście tej nie pojawiło się Ubuntu – i nie bez powodu. Canonical, wydawca tej być może najpopularniejszej dystrybucji, robi co może, aby swoje związki z Linuksem zamaskować, a co więcej, ostatnio decyduje się na rozwiązania, które mogą zakończyć erę kompatybilności pomiędzy dystrybucjami.

Nie chodzi tu wcale o środowisko graficzne Unity, powszechnie uważane w linuksowym światku za potworka. Unity jest w końcu tylko nakładką na biblioteki GNOME (co prawda wymagającą niewspieranych w innych dystrybucjach łatek na biblioteki GTK), ale łatwą do zastąpienia w razie czego innymi środowiskami graficznymi, włącznie ze standardowym GNOME czy KDE. Problem pojawił się znacznie głębiej. Canonical ogłosił niedawno chęć wprowadzenia demona Upstart bezpośrednio do warstwy użytkownika. Gdy to się stanie, Canonical będzie dysponował niemal w całości własną platformą, dzielącą z innymi dystrybucjami jedynie wybrane komponenty, takie jak jądro Linuksa czy szyna komunikacji D-Bus, a różniącą się menedżerem systemu, menedżerem sesji, czy interfejsem użytkownika.

Dla wyjaśnienia: przez wiele lat linuksowe dystrybucje wykorzystywały demona init, zajmującego się obsługą zadań podczas uruchomienia komputera. Demon ten był całkowicie synchroniczny, wykonanie kolejnego zadania było możliwe dopiero po ukończeniu poprzedniego, jego zadania trzeba było planować z wyprzedzeniem, a ich uruchamianie możliwe było tylko przez zmiany stanu samego demona, co w praktyce czyniło init wyjątkowo kiepskim rozwiązaniem dla desktopów, do których ciągle coś podłączamy.

W 2010 roku Lennart Poettering z Red Hata przedstawił nowego demona init, o nazwie systemd. Przyniósł on znacznie lepszą kontrolę zależności między usługami, pozwalał na współbieżne uruchamianie zadań podczas startu, a także wywoływanie ich na żądanie (np. w odpowiedzi na połączenie sieciowe czy wiadomość z szyny D-Bus). Jego podstawowym ograniczeniem było uzależnienie od linuksowego jądra – nie nadawał się do implementacji w systemach *BSD. Dla linuksowych dystrybucji nie był to jednak kłopot. Na nowego demona startu przeszły już m.in. OpenSUSE, Fedora, Mandriva i Arch Linux. Deweloperzy Debiana odmówili – gdyż rozwijają odmianę swojego systemu na jądrze FreeBSD (Debian GNU/kFreeBSD), jednak umieścili oficjalne pakiety systemd w gałęzi testowej. Co najistotniejsze, deweloperzy menedżera urządzeń udev zdecydowali się na wprowadzenie jego kodu do systemd. A co z Ubuntu i jego pochodnymi?

Podobno w grę weszły czynniki ambicjonalne. Kilka lat przed pojawieniem się systemd, Canonical dysponował już własnym zamiennikiem dla init – bazującym na zdarzeniach demonem Upstart, zapewniającym asynchroniczność, ale i kompatybilność ze starymi skryptami init. Pojawił się on jako domyślny w Ubuntu 9.10 i ChromeOS-ie, przez chwilę był też obecny w Fedorze i OpenSUSE (a później zastąpiony przez systemd). Dziś znajdziemy go przede wszystkim w Ubuntu i pochodnych dystrybucjach – cała reszta linuksowego świata wybrała bardziej zaawansowanego, choć zrywającego ze zgodnością ze starymi skryptami systemd.

Póki jednak z perspektywy twórców dystrybucji różnica między systemd i Upstartem sprowadzała się do niekompatybilnych API systemu zarządzania zadaniami, nie było to szczególnym problemem. Jednak wyprowadzenie tych demonów z warstwy systemowej to zupełnie inna para kaloszy. Poettering przyznaje, że myślał o uruchamianiu systemd w sesji użytkownika, pełnym przeniesieniu na niego GNOME i KDE, ale z pomysłu tego zrezygnowano: linuksowe aplikacje zaczęłyby mieć problemy z kompatybilnością między dystrybucjami: oprogramowanie napisane na OpenSUSE mogłoby nie uruchomić się na Ubuntu.

Teraz na taki krok zdecydował się Canonical, czyniąc z Ubuntu jeszcze większego linuksowego outsidera. Czy znowu zresztą tak bardzo linuksowego? Wejdźcie na stronę główną Ubuntu, zobaczcie, ile razy użyte jest tam słowo „Linux”. Podpowiemy: ani razu, podczas gdy na stronie głównej OpenSUSE Linux wspomniany jest siedmiokrotnie. Ubuntu jest najwyraźniej bliskie pójścia w ślady Androida – przekształcenia się w system operacyjny, który korzysta tylko z wybranych komponentów GNU/Linux.

Może to dla Ubuntu dobrze, i biznesowo decyzja taka będzie miała sens. Ale w sytuacji, w której taki Steam wydaje swojego klienta wyłącznie na Ubuntu, i wcale nie jest pewne, że będzie on w przyszłości wspierany na innych dystrybucjach Linuksa, posunięcie to jest bardzo kiepskie dla całego ekosystemu Linuksa. Czy będziemy więc kiedyś musieli uruchamiać „emulatory Ubuntu” na Linuksie, tak jak dziś uruchamiamy emulatory Androida?

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.