21-letnia Polka naprawiła Linuxa. I ma dla nas ważną lekcję
Ta usterka przez dwie dekady dręczyła użytkowników klasycznego środowiska linuxowego - Enlightenment E16. Kamila Szewczyk zamiast narzekać zdecydowała się ją… po prostu usunąć. Zrobiła coś, czego nikt nie potrafił przez dekady.
Młoda programistka, 21‑letnia Kamila Szewczyk, znalazła i naprawiła błąd w kodzie menedżera okien Enlightenment E16. Błąd, który siedział tam od około 2006 r. I który potrafił zawiesić cały pulpit jednym… za długim tytułem okna. Nie dość, że zawstydziła starszych kolegów i koleżanki, to jeszcze na dodatek była uprzejma poświęcić swój czas i opisać na swoim blogu, jak odkryła, zdebugowała i poprawiła błąd. Niezwykle przyjemna lektura.
Co to w ogóle jest Enlightenment E16 i kto go jeszcze używa?
Enlightenment to jeden z najstarszych wciąż rozwijanych menedżerów okien dla Uniksa i Linuksa. Projekt wystartował w 1997 r., a gałąź E16 (DR16) pojawiła się w 1999 r. - i żyje do dziś, choć większość świata dawno przesiadła się na nowsze wcielenia Enlightenment albo na zupełnie inne środowiska.
Czytaj też:
E16 ma dziś status „kultowego reliktu”: lekki (Kamila podaje ok. 24 MB peak RSS), mocno konfigurowalny, przyjazny klawiaturowym wyjadaczom, do tego wciąż „ładny” w swoim retro‑stylu. To typ oprogramowania, które nie goni za modą - zamiast tego latami szlifuje to, co już ma. Nowe wersje to głównie poprawki błędów i drobne usprawnienia, a nie kolejne warstwy funkcji, których nikt nie potrzebował.
Właśnie w takim, pozornie „domkniętym” projekcie, od dwóch dekad czekał sobie błąd, który potrafił zamrozić cały pulpit.
Jak zawiesić cały pulpit jednym PDF‑em
Scenariusz, od którego zaczęła się cała historia i który Kamila opisuje, brzmi znajomo, w sumie niezależnie od używanego systemu: ostatnia chwila przed zajęciami, dopieszczanie slajdów, kilka plików PDF z wykładem i zadaniami. Kamila, doktorantka na Uniwersytecie Saary, otwiera jeden z plików w Atrilu - i nagle cały desktop się zamraża. Zero reakcji. Twardy reset sesji X11 z TTY.
Błąd jest się w pełni powtarzalny: ten konkretny PDF = natychmiastowy freeze. Winowajcą okazuje się tytuł pliku. Mechanizm w E16 działa tak: jeśli tytuł jest za długi, to menedżer próbuje go „przeciąć” w środku i wstawić w tytule okna interfejsu wielokropek: początek tytułu…koniec tytułu. Brzmi rozsądnie. Problem w tym, że implementacja tego dopasowywania używa wariantu metody Newtona - i robi to bez żadnego limitu iteracji.
W uproszczeniu: funkcja próbuje oszacować, ile znaków trzeba „wyciąć” ze środka, żeby zmieścić się w zadanej szerokości. Liczy średnią szerokość znaku (piksele na znak), porównuje aktualną szerokość z limitem, a potem koryguje liczbę usuwanych znaków - w górę lub w dół - na podstawie tego, jak bardzo się „przestrzeliła”. Mamy przybliżenie, mamy „pochodną” (średnią szerokość znaku), poprawiamy wynik i liczymy jeszcze raz.
Niestety metoda Newtona to algorytm, który - pisząc kolokwialnie - może się rozjechać. Może nie zbiegać w ogóle, może oscylować między dwoma punktami, może się „rozbiec” w nieskończoność. Dlatego w podręcznikach zawsze pojawia się ten sam, nudny, ale kluczowy punkt: limit iteracji i sensowna tolerancja błędu.
W E16 tego limitu nie było. Pętla działała „dopóki nie zadziała”. A w przypadku tytułu PDF‑a Kamili wpadła w idealną pułapkę: dwustanową oscylację. Raz usuwała 8 znaków, potem 11, potem znowu 8, potem 11… i tak w kółko. Tekst był za każdym razem przeliczany, fonty mierzone, ale warunek zakończenia nigdy nie był spełniony. Efekt z punktu widzenia użytkownika: cały pulpit zamrożony, bo menedżer okien kręci się w nieskończonej pętli, próbując dopasować tytuł okna.
Trzy linijki filozofii w trzech poprawkach do kodu
Kamila przygotowała łatkę do wersji E16 1.0.30 (wydanej w sierpniu 2024 r.). Poprawka jest zaskakująco prosta. Po pierwsze, wprowadza limit iteracji - 32 kroki. Jeśli po 32 próbach algorytm wciąż nie znalazł idealnego dopasowania, a aktualny wariant tytułu mieści się w zadanej szerokości, to po prostu go akceptuje. Jeśli się nie mieści - zwiększa liczbę usuwanych znaków o 1 i próbuje jeszcze raz. Koniec z nieskończonym kręceniem się w kółko.
Po drugie, limit dla parametru nuke_count: liczba usuwanych znaków nie może spaść poniżej 1. To zabezpiecza przed kuriozalnymi przypadkami, w których korekta w dół powoduje, że „ogon” tytułu zaczyna nachodzić na „głowę” - dostajemy wtedy dziwne, zdegenerowane ciągi znaków.
Po trzecie, limit dla cw, czyli średniej szerokości znaku: nie może spaść poniżej 1. Dzięki temu nawet jeśli pomiar szerokości tekstu zwróci coś patologicznego (np. zero), to nie zamienimy wzorów na krok Newtona w dzielenie przez zero.
„Nowe” kontra „skończone”. Co ta historia mówi o współczesnym sofcie
Kamila wprost mówi, że lubi E16 właśnie dlatego, że to oprogramowanie jest w pewnym sensie „skończone”. Nie w znaczeniu „porzucone”, tylko: ma zestaw funkcji, który jest wystarczający, a kolejne wydania to głównie poprawki błędów i drobne usprawnienia, a nie niekończący się strumień nowinek. „W kółko dostarczamy niestabilność, której nie musimy dostarczać”, jak pisze.
Kamila w swoim poście na blogu przywołuje bardzo świeże przykłady: choćby wpadkę w jądrze Linuksa 6.6 LTS, gdzie poprawka w gałęzi stabilnej sprawiła, że wywołanie fgetxattr(54321, NULL, NULL, 0) - które powinno po prostu zwrócić błąd EINVAL - powodowało crash kernela. Łatka została szybko wycofana, ale przez kilka dni w stabilnym jądrze istniał banalny wektor DoS.
Do tego dochodzi jeszcze afera z backdoorem w XZ Utils - bibliotece kompresji, która trafiła do dystrybucji w wersji z potencjalnie celowo wprowadzonym, zaawansowanym backdoorem. Kamila opisuje moment, w którym na laptopie z Debianem Sid w trakcie kompilacji kodu czyta o XZ 5.6.0 i z przerażeniem sprawdza, czy przypadkiem nie ma tej wersji w systemie.
Na tym tle „stare, nudne” oprogramowanie rozwijane przez mały zespół z niewielką liczbą funkcji i powoli malejącą liczbą bugów zaczyna wyglądać jak całkiem rozsądna strategia. Mniej wektorów ataku, mniej niespodzianek, mniej feature’ów, których i tak nie użyjesz.
Co z tego wynika dla zwykłego użytkownika (który nie pisze własnego menedżera okien)
Jeśli na co dzień żyjesz w świecie elektroniki użytkowej, to ta historia brzmi znajomo także poza Linuksem. Telefony, telewizory, routery, konsole - wszystko żyje w trybie ciągłej aktualizacji. Nowe funkcje, nowe integracje, nowe UI, nowe bugi.
Kamila sugeruje bardzo pragmatyczne podejście: jeśli nie musisz, to nie goń za każdą nową wersją. Zostań na świeżym, ale stabilnym wydaniu - najlepiej LTS - i pozwól, żeby liczba błędów w tej konkretnej gałęzi z czasem malała. Aktualizować łatki bezpieczeństwa, ale nie rzucać się na każdą „rewolucję” w interfejsie czy zestawie funkcji.
To nie jest recepta dla wszystkich - są scenariusze, w których trzeba mieć absolutnie najnowsze biblioteki, sterowniki czy API. Ale dla ogromnej części użytkowników i administratorów to podejście „żyj z tym co działa i patrz, jak maleje liczba bugów” jest po prostu rozsądne. I bardzo odświeżające.
