Fedora ma już 15 lat – co z nią zrobi IBM?

Sytuacja zaczęła się powoli zmieniać w roku 2002. Najpierw rozpoczęto proces ogólnoświatowego regulowania znaków towarowych z czerwonym kapeluszem i wstrzymano drugi obieg dystrybucji. Innymi słowy, system dalej był darmowy, ale nie wolno było zarabiać na wydawaniu go np. w gazecie – tak długo, jak gdziekolwiek pojawiało się logo lub nazwa Red Hat. Swoją drogą, pierwsi poradzili sobie z tym Polacy: efektem było wydanie systemu Aurox Linux, identycznego z protoplastą, ale bez znaków towarowych. Następnym krokiem było usunięcie z systemu wszystkich komponentów o niejasnej licencji, jak kodeki MP3. Wreszcie, rozwój Red Hata został rozwidlony na płatną wersję (Enterprise Linux), wydawaną co kilka lat oraz projekt „ciągły”, bez wsparcia, mniej stabilny, za to żwawiej rozwijany: nowe wydania miały miejsce co pół roku. System nazwano Fedora Core. Fedora to rodzaj kapelusza, z „Core”, czyli rdzeń, oznacza podział systemu na repozytoria rdzenne i pakiety dodatkowe. Podział ten zdążył się rozmyć z biegiem czasu i obecnie system nie nazywa się już Core. Z końcem zeszłego miesiąca wydano wersję 29. Był to gorący okres dla Red Hata, bowiem mniej więcej równocześnie ogłoszono wydanie systemu Fedora 29, Enterprise Linux 7.6 oraz sfinalizowanie negocjacji dotyczących przejęcia firmy przez IBM. Co nowego możemy zobaczyć w tych wydaniach i jak będą wyglądać kolejne, opracowywane już pod okiem nowego właściciela?

O ile Red Hat uchodzi za system będący platformą dla innych produktów, Fedora usiłuje prezentować się jako system ogólnego przeznaczenia. Zawiera zbiór nowoczesnych środowisk graficznych oraz łatwą metodę dołączenia dostawców oprogramowania firm trzecich oraz programów „ostrzej” licencjonowanych. Jest dobrym wyborem dla ludzi wierzących w słuszność postawy „follow the money” stanowiącej, że najlepszym rozwiązaniem jest stosowanie oprogramowania najbliżej zgodnego z projektem o porządnym finansowaniu. Nie tylko łatwiej w ten sposób o zapewnienie jakości, ale przy okazji obcuje się z oprogramowaniem, którego znajomość może się okazać atutem w karierze zawodowej. Wiele piętrowo sforkowanych dystrybucji Linuksa to jedynie złożone eksperymenty i amatorskie kompilacje pełne niedoróbek. Z Fedorą jest trochę inaczej. Ale też można się poparzyć.

Nowe wydania Ubuntu oraz najpopularniejszych Linuksów „na biurko” przyciągają odświeżoną estetyką, Fedora wraz z każdym kolejnym wydaniem serwuje coraz bardziej nudny zbiór nowości. Można powiedzieć, że tak jest uczciwiej, ale noty wydawnicze faktycznie są mniej ekscytujące. Oczywiście, wersja 29 zawiera nowe GNOME i LibreOffice, ale główne zmiany to przede wszystkim ciąg dalszy wielkiej batalii o pełną migrację na Python3. To część większej inicjatywy, przez zbliżony proces przechodzi GNOME oraz.. Ansible, czyli redhatowe narzędzie automatyzacji masowych wdrożeń (jeden z ułatwiających życie gratisów, dzięki którym Ubuntu wygląda pociesznie). Podbito również libc oraz binutils. Miłą zmianą jest także migracja na najnowszego Perla i przejście ze wszystkimi pakietami dodatkowymi na repozytorium MetaCPAN. Dbałość o Perla słabnie w świecie open source, coraz mocniej inwestującym swój czas w Pythona (co ma swoje uzasadnienie). Pozostałe aktualizacje dotyczą podnoszenia wersji komponentów wymaganych przez platformy OpenShift/OpenStack. To doskonała poszlaka, pokazująca priorytety inwestycyjne Red Hata. W końcu nadejdzie przecież menedżer wydania, zamrozi wersje pakietów Fedory z konkretnej daty i rozpocznie proces stabilizowania ich, celem opracowania wersji ósmej RHELa.

Owe zamiary widać o wiele wyraźniej, gdy spojrzymy na zmiany w najnowszym Red Hacie. Rozkręcająca się od kilku lat moda na ciągłe dostarczanie (continuous delivery) i pęd do coraz nowszych wersji oprogramowania sprawiły, że kryteria aktualizacji komponentów są nieco mniej restrykcyjne dla wersji siódmej, niż dla RHELa 6, ale dotyczy to raczej komponentów mniej kluczowych, jak środowisko graficzne i przeglądarka Firefox. Jądro Linux to w dalszym ciągu załatana wersja 3.10, tym razem dostarczająca zbiór łatek z erraty wydanej w międzyczasie (m.in. w kwestii problemów w VMWare, które istotnie bywały dokuczliwe podczas próbnych wdrożeń na ESXI).

Wydanie 7.6 wprowadza nowe szyfry w SSH i TLS oraz rozszerzenia dot. uwierzytelniania, między innymi względem domeny Active Directory – miła niespodzianka. Pakiety programistyczne również zaktualizowano, ale nie tak odważnie, jak w Fedorze: na przykład Perl to dalej 5.16. Takiego GNOME można bezkarnie podmienić do wersji 3.28, ale liczba skryptów Perla zlepiających internet w całość jest zbyt duża, by wymieniać jego wersję na znacząco nowszą, pełną unieważnień (deprecations). Oczywiście, plany wycofania platformy Python 2 trwają nadal: pakiet oznaczono jako przeznaczony do usunięcia w poprzedniej wersji.

Nie oznacza to, że RHEL stoi w miejscu. Wersja 7.6 potrafi się zainstalować nie tylko na serwerach, ale także na zaskakująco nowym sprzęcie mniej dedykowanym, obsłuży np. platformę Skylake i magistralę Thunderbolt 3. Ciekawiej robi się na innych obszarach – takie zabawki jak sudo, audit i SELinux są obecnie aktualizowane znacznie szybciej, niż w RHELu 6. Wiąże się to zapewne z niższym kosztem implementowania zgodności ze STIGami (normami bezpieczeństwa dla urządzeń militarnych). Taniej jest wciągać nowsze wersje, niż łatać stary baseline. Ale wśród aktualizacji jest trochę niespodzianek. Kontroler systemd pozostał w antycznej wersji 219 – co jest sporym rozczarowaniem biorąc pod uwagę nowości z nowych wersji, zwłaszcza w porównaniu z rozleniwiającą w tej kwestii Fedorą. Ale fikuśny menedżer zarządzania zdalnego Cockpit podniesiono do wersji 173! Cockpit dalej nie jest domyślnie włączony w RHELu, głównie dlatego, że nie był włączony w wersji 7.0. Inaczej jest w Fedorze Server, gdzie od początku Cockpit słucha na porcie 9090 (jako PID 1! Matko jedyna!).

Zatem istotnie, Fedora potrafi uprzyjemnić życie i przyzwyczaić do nowości, ale nie wszystkie z nich są portowane w dół do Red Hata. RHEL7 bazuje na wydaniu Fedora 21 i w wielu miejscach dalej będzie to widać – na przykład w odrażającym menedżerze partycjonowania w instalatorze. Nieintuicyjne rakowisko, wprowadzone w wersji 18, ma się dobrze w RHELu 7.6, podczas gdy w Fedorze, po wielu latach krzyków „nie narzekajcie, jest świetny, idźcie z duchem czasu!” na Bugzilli, parę wersji temu dodano innego menedżera, do złudzenia przypominającego ten z pierwszej Fedory. Programistów takie rzeczy często nie interesują, ponieważ konfiguracja instalacyjna i tak jest dodawana w postaci ręcznie edytowanego pliku odpowiedzi (kickstart), ale czasami konieczność ręcznego przejścia przez instalator i użerania się z poprawnym utkaniem partycji potrafi nieźle napsuć krwi.

Aby nie dać się rozpieścić przez Fedorę i nabrać trochę doświadczenia w pracy z systemem w wydaniu korporacyjnym, można wybrać czystego Red Hata. Przez pewien czas było to możliwe wyłącznie poprzez program CentOS, czyli RHELa ogołoconego ze wszystkich redhatowych pakietów, acz od pewnego czasu możliwe jest zainstalowanie pełnego Red Hat Enterprise Linuksa, w postaci identycznej z tą płatną. Pozwala to zapoznać się z narzędziami do zarządzania licencją i subskrypcją firmy Red Hat, używanymi we wdrożeniach objętych obsługą techniczną (np. na firmowym serwerze). Bowiem aby otrzymywać aktualizacje i automatycznie raportować błędy, konieczna jest aktywna subskrypcja Red Hat Network. Możliwe jest otrzymanie darmowej, rocznej subskrypcji dla programistów, bez obsługi technicznej i dodatkowych bonusów. Konieczne jest wyrażenie zgody na to, że tak zainstalowany system będzie wykorzystywany wyłącznie w celach programistycznych we własnym zakresie – testowanie swoich pomysłów, stacja robocza w pracy itd. Zakazane jest wdrażanie systemów opartych o tak zdobytego Red Hata oraz zarabianie na produktach stworzonych w oparciu o nią. Subskrypcja jest imienna.

Można ją otrzymać, rejestrując konto w sieci Red Hat Network. Sama rejestracja na portalu nie daje żadnych rozszerzonych dostępów do materiałów ani wsparcia technicznego, pozwala jednak mieć imienne konto, do którego przypisywane są subskrypcje dla wszystkich produktów firmy. Posiadając takie konto, możemy pobrać oficjalny obraz instalacyjny systemu Red Hat oraz zainstalować go na maszynie wirtualnej lub fizycznym komputerze. Domyślny profil instalacyjny to „pusty” serwer: tekstowe środowisko pracy i dostęp przez SSH.

Instalowanie oprogramowania jest niemożliwe bez rejestracji. Oczywiście da się to obejść, ręcznie konfigurując program yum i wywalając narzędzia monitora subskrypcji, ale w takim przypadku łatwiej będzie po prostu sięgnąć po CentOSa. Rejestrację da się przeprowadzić przez program Subscription Manager. Jeżeli w naszym profilu nie dodaliśmy subskrypcji dla programistów, rejestracja nie powiedzie się i wyświetli komunikat o konieczności przeczytania i zaakceptowania regulaminu, dostępnego pod (oczywiście nieklikalnym i złamanym w połowie!) linkiem w domenie redhat.com. Prawidłowa rejestracja pozwoli od razu dostrzec wartość systemu: „out-of-box” dostępne są tuziny repozytoriów z obsługiwanymi wersjami produktów OpenStack, Ansible i Satellite oraz programowania firm trzecich: Oracle, Java oraz… Microsoft .NET Core! Owe repozytoria służą do przygotowania systemu pod bycie platformą dla aplikacji. Wystarczy podłączyć odpowiednie repozytorium i zainstalowany system staje się przygotowany do hostowania aplikacji. W zasadzie bezkosztowo można go np. wyeksportować i posłać w chmurę celem masowego wdrożenia.

Domyślne repozytoria programistyczne podlegają obsłudze technicznej (oczywiście nie w ramach darmowej subskrypcji!): przygotowanie serwera na Fedorze zazwyczaj odbędzie się bezproblemowo, ale w przypadku problemów jesteśmy zdani na siebie/forum/społeczność. Jeżeli jednak problemy sprawia proces instalacji środowiska zdefiniowanego w repozytoriach od Red Hata, posiadacze obsługi technicznej są uprawnieni do natychmiastowego narzekania i żądania naprawy. Nie znaczy to, że wszystkie problemy są zawsze rozwiązywane od ręki. Wiele rzeczy potrafi „utknąć” na wieki w Bugzilli, ale to typowe. Każdy, kto próbował cokolwiek załatwić w firmowej obsłudze Microsoftu, Oracle i VMWare wie, o czym mówię. Red Hat bywa tutaj podobny.

Jak będzie wyglądać rozwój Red Hata po przejęciu przez IBM? Zapewne przez najbliższe kilka lat nic się nie zmieni. Łatwo jest podgrzewać atmosferę i np. krzyczeć, że oto wywalane jest wsparcie dla pakietu KDE, ale tak naprawdę nie ma to żadnego znaczenia. Nikt nie odczuje braku wsparcia dla KDE w systemie Red Hat Enterprise Linux. Nikt poważny nie używa nowego KDE na RHELu, bo to bez sensu, ten system służy do czego innego. Rzecz której na pewno można się spodziewać, to większa integracja rozwiązań Red Hata z chmurą IBM. W obecnym RHELu w ogóle tego nie widać, jedyne zmiany pod tym kątem to póki co wsparcia dla sterownika wirtualnego przełącznika (vSwitch) IBM Cloud. Być może więcej będzie widać u następcy. Kolejne wydania Enterprise Linux wychodzą coraz rzadziej, każde kolejne po przerwie rok dłuższej niż w przypadku poprzednika. Plasuje to wydanie systemu RHEL 8 mniej więcej na połowę przyszłego roku. Tymczasem o wydaniu ósmym wiadomo bardzo mało. Wersji beta jeszcze nie ma. Wersje podglądowe są rozpowszechniane w bardzo ograniczonym zakresie i udostępnione tylko nielicznym: na Bugzilli pojawia się kilka raportów o błędach celujących (target release) właśnie w EL8. Czyżby właśnie postępowały prace nad większą integracją z IBM?

Trudno powiedzieć. Deal przejęcia przez IBM był okryty tajemnicą, więc być może nie chciano jej zdradzić publikując betę RHELa pełną integracji z IBM Cloud. Z drugiej strony jednak nowa platforma aż się prosi o to, by wydawać wersje próbne i przyzwyczajać programistów do nowych wytycznych. Najproszte wytłumaczenie jest jednak takie, że w kwestii związania z IBM, w obecnym Red Hacie jeszcze nic nie jest gotowe i miną lata, zanim będzie.

Co zatem z Fedorą? To ciekawsze pytanie. Fedora Project w ogóle nie zareagował na oświadczenie o przejęciu swojego głównego opiekuna. IBM z kolei jasno wyraził swój zamiar zaangażowania (commitment) we wsparcie projektu Fedora. Takie przekazy zwyczajowo generują nieunikniony strumień bullshitu i myślenia życzeniowego, utrudniającego dojście do prawdy, która i tak obecnie jest na etapie wróżenia z fusów. Oto hipotezy:

IBM faktycznie będzie dalej wspierał Fedorę, bo tak powiedzieli. To bardzo optymistyczne przekonanie, któremu zagrażają dwa zjawiska. Po pierwsze, doświadczenie – przejęcia projektów przez gigantycznych graczy zazwyczaj kończą się rzezią. Na przykład Oracle przejechał walcem po Solarisie i mocno utrudnił życie użytkownikom Javy. Po drugie, takie słowa padają niemal za każdym razem. Microsoft mówił tak, gdy przejmował Skype’a. Obiecywał też niesamowite rzeczy w przypadku Yammera i LinkedIn. Dlatego tak wielu bało się o GitHuba. Dlatego tak wielu boi się o Fedorę. Amerykańskie prawo ma wręcz na tę okazję oddzielną definicję dla obiecanek tego typu: „forward-looking statement”, która w praktyce sankcjonuje bezkarność takich deklaracji, klasyfikując wszelkie słowa w jej ramach jako maksymalnie optymistyczną manifestację potencjalnie najlepszej woli. Innymi słowy, jak coś nie wyjdzie, to nie szkodzi. Bo tak naprawdę te obietnice nie były na serio.IBM nie będzie wspierał Fedory, bo jest zły i niedobry. Alternatywnym poglądem jest od razu nakreślenie najczarniejszego scenariusza i postulowanie, że niedługo cała Fedora się złoży, bo IBM nie ma czasu na zabawę. Oczywiście, kapitalistyczny pragmatyzm bardzo często jest słuszny, ale warto pamiętać, że Fedora nie zajmuje się tylko paczkowaniem emulatorów do GameBoya i środowiska graficznego Sugar dla komputerów w państwach piątego świata. Spora część procesu wydawniczego RHELa to bazowanie na pracy projektu Fedora. Mają one nawet wspólną Bugzillę. Ubicie projektu może się okazać zwyczajnie nieopłacalne i najwyżej nastąpi powrót na podział do repozytorium Core i Extras, jak przed wiekami. IBM nie będzie wspierał Fedory, ale to nie szkodzi, bo jest to projekt społecznościowy, a społeczności są niezniszczalne i nie potrzebują pieniędzy. To zaskakująco popularna hipoteza. Jest powtarzana bardzo często i zazwyczaj z nieodmienną gorliwością jej wyznawców. Za przykład stawiany jest Debian. I w zasadzie Debian jest tutaj kontrprzykładem: jeżeli ktoś chce wspierać projekt niefinansowany przez jakiś gigantyczny byt biznesowy, niech to będzie właśnie Debian. Fedora jest uzależniona od pieniędzy Red Hata i jeżeli strumień gotówki od nich się skończy, to społecznościowa kroplówka może nie wystarczyć. Jednocześnie na pewno wybuchnie wielka schizma i zinstytucjonalizowany fork (żeby to jeden!) , dzielący bazę użytkowników na jeszcze mniejsze grupy i skazujący sam projekt na los zbliżony do OpenOffice, który nie umarł, ale zarazem nie zalicza się do szczególnie żywych

Najnowszą Fedorę można pobrać na stronie projektu. Zarówno Fedora 29 jak i RHEL 7.6 bardzo dobrze działają pod Hyper-V, da się je więc bez problemu przetestować w systemie Windows 10, bez konieczności instalowania dodatkowego oprogramowania. O ile oczywiście nadzorca Hyper-V dalej pracuje po przeprowadzeniu aktualizacji do najnowszej wersji systemu. Właśnie tak – to też nie działa poprawnie w wydaniu 1809. Być może czytaliście aż nadto o tym, jak proces aktualizacji kasuje pliki, a sam system uszkadza archiwa ZIP. Tymczasem okazuje się, że psuje on również Hyper-V. Nie zdążyliśmy o tym napisać na portalu. Złośliwi mogą teraz powiedzieć, że problemów z Windows 10 jest więcej, niż rąk do pracy!