Kernel Traffic #158 For 18 Mar 2002

Zanim ktokolwiek odnotuje, że jest to wiadomość Nie Na Temat na różnych listach mailingowych, na które ją wysłałem, pomyślcie o skutkach, jakie może mieć dla Linuksa. Dodatkowo, mimo iż wielu z Was może nie być obywatelami Stanów Zjednoczonych, ostatnie wydarzenia związane z międzynarodowymi prawami skierowanymi przeciwko cyberprzestępstwom, piractwu i tym podobnym mogą sprawiać, iż prawo USA będzie się odnosiło również do Was; pomijając już fakt, iż Wasza firma może nie mieć możliwości prowadzenia interesów w USA ze względu na takie prawo. Z tego powodu rzeczywiście JEST to na temat, a chwila do zastanowienia się i zareagowania na takie rzeczy jest _PRZED_ wyryciem ich w kamieniu, a nie po.

Jeżeli jeszcze o tym nie słyszeliście, SSSCA przedstawiono dziś Senackiej Komisji Handlu (SCC, Senate Commerce Committee) (http://slashdot.org/articles/02/03/01/1423248.shtml?tid=103 -- relacje i kilka odnośników, łącznie ze szkicem projektu ustawy). SSSCA, jeśli przejdzie, będzie wymagała, aby wszystkie interaktywne, cyfrowe urządzenia, włączając w to Wasze PC-ty, posiadały wbudowane zabezpieczenie przed kopiowaniem. Zabezpieczenie takie zapobiegałoby przeglądaniu, kopiowaniu, przenoszeniu czy ściąganiu cyfrowych mediów, jeżeli urządzenie nie jest autoryzowane do takich czynności. Projekt ustawy zakłada też, iż przestępstwem jest obchodzenie takich zabezpieczeń, włączając w to produkcję oraz handel czymkolwiek, co nie zawiera takiego zabezpieczenia, lub je obchodzi.

Nawet jeśli nie będzie SSSCA, zarówno przemysł rozrywkowy, jak i rynek IT są zgodne: musimy mieć jakieś zabezpieczenie przed kopiowaniem. Mimo że nie polemizuję z faktem, iż wiele filmów, utworów i innych mediów jest dystrybuuowanych nielegalnie, bez zgody ich właścicieli, oraz że właściciele praw autorskich potrzebują jakiegoś rodzaju zabezpieczenia, jednak nie jest to właściwy sposób na zwalczenie problemu, a czynienie tego może mieć, i prawdopodobnie będzie miało, drastyczne i daleko sięgające konsekwencje nie tylko dla przemysłu IT ale też dla przemysłu rozrywkowego oraz konsumentów.

Wielu z nas jest coraz mocniej związanych i zależnych od Wolnego Oprogramowania (typu GNU GPL, czy podobnych), zwłaszcza systemu operacyjnego Linux. Ten rodzaj oprogramowania jest rozprowadzany razem z kodem źródłowym, co pozwala każdemu je modyfikować w zależności od własnych potrzeb. Linux stał się popularny do tego stopnia, że wiele firm, szczególnie tych, które oferują różnego rodzaju usługi związane z Internetem, na nim polega. Ze względu na wolną naturę Linuksa oraz innego Wolnego Oprogramowania, bardzo ciężko jest podać konkretne liczby obrazujące liczbę systemów, w których używa się takiego oprogramowania. Niektórzy z Was, tak jak ja, mogą szacować liczbę takich systemów w Waszej firmie lub zasobach wiedzy. Jaki ma to więc związek z SSSCA?

Jak zaświadczy każdy programista warty swej ceny, z odpowiednimi zasobami wszystko, co da się zaprogramować wewnątrz komputera, da się zaprogramować również na zewnątrz, lub obejść. W przypadku takiego zabezpieczenia przed kopiowaniem, jakiego wymagałoby SSSCA, zasoby potrzebne do jego obejścia to tylko kod źródłowy systemu operacyjnego komputera i/lub kod źródłowy aplikacji używanych na komputerze (taki jak jeden z wielu dostępnych, darmowych odtwarzaczy video/audio). Zgodnie z treścią SSSCA oraz DMCA i innych podobnych praw, oczywiste jest, iż Wolne Oprogramowanie stałoby się nagle przedmiotem ustawodawstwa. Taka legislacja może logicznie wymagać, aby to oprogramowanie było osądzone jako nielegalne. Decyzja tego typu może mieć poważne konsekwencje zarówno dla przemysłu IT, jak i dla rynku rozrywki czy dla pojedynczego konsumenta. Konsument czy przemysł rozrywkowy mogą o tym niewiele wiedzieć, ale duża część technologii, od której obecnie zależą, jest dostarczana niskim kosztem przez Wolne Oprogramowanie. Spróbujcie zabrać to oprogramowanie -- nagle robienie interesów zacznie kosztować o wiele więcej i klient być może przestanie mieć ochotę za to płacić.

Zostawiając z boku skutki godzące w Wolne Oprogramowanie, co z konsekwencjami dla tych, którzy nie używają takiego oprogramowania? Wyobraźcie sobie domowy film video, który nakręciliście na urlopie w ostatni weekend. Teraz macie ochotę wysłać go do krewnego, przyjaciela, kogokolwiek, przez Internet, lub umieścić go na Waszej stronie, aby wszyscy mogli go obejrzeć. Z wieloma sugerowanymi technikami zabezpieczeń byłoby to niemożliwe, lub niezwykle trudne. Niektóre z tych technologii wymagają na przykład cyfrowych znaków wodnych umieszczanych na mediach. Nagrywarki CD, kamery cyfrowe, itp. nie są w stanie ich robić. Zabezpieczenie przed kopiowaniem działa w taki sposób, iż sprawdza istnienie takiego znaku wodnego, a jego nieobecność uniemożliwia odtworzenie lub przesłanie przez Internet danego medium, a właśnie na tym może Wam zależeć. Nici z wysłania krewnym Waszej najnowszej produkcji, czy wystawienia jej na stronie internetowej, aby cała rodzina mogła ją ujrzeć. Dodatkowym problemem są wszystkie obecnie stosowane nośniki, włączając w to CD i DVD, które, mimo iż są teraz Waszą legalną własnością, mogą nie pracować w nowych odtwarzaczach z proponowanym sprzętem zabezpieczającym przed kopiowaniem. Nie bylibyście w stanie kopiować CD, taśm, czy czegokolwiek, co jest Waszą prawną własnością i co macie prawo użytkować, chociażby słuchając tych płyt w Waszym odtwarzaczu samochodowym.

Mógłbym kontynuować, ale uważam, iż jest to wystarczająco długie i daje do myślenia. Poza tym, mam trochę roboty. Zbliżają się wybory, więc pomyślcie o tym, co reprezentuje osoba, na którą będziecie głosować. Zastanówcie się nad napisaniem listu do kongresmena czy innego podmiotu ustawodawczego, do czasopisma (mój list został kiedyś opublikowany, więc nie jest to niemożliwe), gazety, itd. Wiele osób przyjmuje postawę, że nie mogą nic zrobić by coś zmienić. Mogę powiedzieć, że mają rację, ponieważ jest tak wielu ludzi z takim podejściem, że żaden z nich nic nie robi, i rzeczywiście nie czynią tym żadnych zmian. Ci, którzy je czynią są tymi, którzy przyjmują pozycje; a Ci, co przyjmują pozycje są tymi, przez których takie idiotyczne prawa są przyjmowane. Zgadnijcie którzy to ludzie?...

Witajcie w Korporacjach Zjednoczonych Ameryki.

Problem polega na tym, że jeżeli nie będziesz trzymał się procedury uruchamiania Sojuszu Zaufanej Platformy Obliczeniowej, nie będziesz mógł już dostać się do ujednoliconych, zgodnych z zasadami, treści w Internecie.

Rozwiązanie jest proste: stwórz swoją własną treść i dziel się nią ze swoimi przyjaciółmi. Ale w ten sposób nie dostaniesz filmów z Hollywood.

Problem tkwi w tym, że zabezpieczenie przed kopiowaniem będzie efektywne tylko wtedy, gdy na użycie komputera nałożysz iście sowieckie restrykcje.

Niektóre potężne korporacje chcą efektywnego zabezpieczenia. Z tego względu będą one starały się takie restrykcje nałożyć.

Próba ta ostatecznie się nie powiedzie. Tak samo nie udał się Związek Radziecki, ale w czasie jego tworzenia był, i będzie czymś uciążliwym.

Nie bądź tego zbyt pewny. Jeżeli ,,kilku'' wie, w jaki sposób te przeszkody obejść, wydadzą służące do tego narzędzia, które użyć będzie mógł każdy.

Kilka osób jest w stanie użyć nowego exploita na przepełnienie bufora, o wiele więcej osób potrafi użyć rootkita.

Pozwólcie, że podzielę się paroma informacjami z ludźmi, którzy mogą być zainteresowani alternatywami dla BK:

Conajmniej jedna osoba udzielająca się w projekcie jądra posługuje się w pracy nad nim prywatnym repozytorium arch, więc wydaje się być wykonalnym używanie tego. Jestem pewien, że dalsze testy, poprawa wydajności, lepsza dokumentacja i parę usprawnień istniejącej funkcjonalności będzie potrzebne, zanim będę mógł powiedzieć ,,arch jest tak dobry, że nie macie żadnej wymówki by go nie używać w pracy nad jądrem''. Jest jednak interesujące, że ktoś już eksperymentuje z tym narzędziem w pracy z jądrem.

Pracuję nad paroma narzędziami, które pomogą zaimplementować automatyczne, przyrostowe i obustronne bramki pomiędzy arch, Subversion i BK.

Przygotowałem dokument opisujący stan, w jakim znajduje się arch oraz opcje, które jeszcze muszą się pojawić, zanim arch się stanie niewątpliwie najlepszym rozwiązaniem. Zajrzyjcie pod adres:

http://www.regexps.com/survey.html

Chciałbym dostać jakieś informacje (poza listą) od ludzi, którzy są zainteresowani używaniem arch do pracy nad jądrem, ale jeszcze tej pracy nie zaczęli. Jakie istotne cechy i możliwości są waszym zdaniem potrzebne? Pamiętajcie, aby wspomnieć w waszych listach elektronicznych, czy mogę was cytować (domyślnie założę, że nie mogę, ale że mogę anonimowo parafrazować interesujące wiadomości oraz zgłaszać zagregowane wyniki).

Ludzie *naprawdę* powinni mieć możliwość używać więcej niż jednego systemu kontroli wersji.

Być może Arch i Subversion nie przechowują całości metadanych trzymanych w BK. To oznacza tylko, że bramka $INNY_SYSTEM->BK wymagałaby poprawiania ręcznego. Koncepcyjnie nie różni się to zupełnie od wysyłania ,,zwykłych starych łat'' pocztą elektroniczną pod adres $OPIEKUN.

Zrobienie funkcjonalnej *dwukierunkowej* bramki BK<->Arch leży w interesie wszystkich. (Włączając w to ciebie, Larry)

Takie rozwiązanie zamknie usta wszystkim fanatykom open source i zredukuje liczbę ludzi obsługiwanych przez Bitmover do tych, którzy naprawdę *chcą* używać rzeczy Larrego, bo są one lepsze, a nie tylko dlatego, że nie ma innej '90%' ewentualności.

Chciałbym zobaczyć Larry'ego i Toma siedzących razem w jedym pomieszczeniu i obmyślających *łatwy* sposób na to, aby $OPIEKUN mógł wyciągać łaty zarówno z Arch jak i z BK. (Opuściłem tu Subversion, bo nie spotkałem nikogo biorącego udział w tym projekcie, kto zainteresowałby się poczynieniem jakichkolwiek zmian przydatnych deweloperom jądra)

Zacznij używać arch i sam sobie odpowiedz na pytanie, czy na pewno tego chcesz. Używanie arch w tej chwili jest mniej więcej tak samo mądre, jak używanie BK trzy lata temu. Cort zrobił to 2 lata temu i było to wystarczająco bolesne. Przekonanie ludzi do archa w tym momencie jest naprawdę najszybszym sposobem zabicia tego projektu. Takie narzędzia potrzebują czasu na to by dorosnąć i jeśli chcesz pomóc projektowi arch, to bądź przygotowany na tyle pracy, ile Cort włożył w BK. Poświęcił temu sporo wysiłku i czasu.

I dlaczego Arch, a nie subversion? Nad Subversion pracuje więcej ludzi, Collab włożył w to kupę pieniędzy, pracuje nad tym człowiek od Apache, a Arch ma tylko jednego człowieka bez pieniędzy i kupkę skryptów w języku powłoki. Daj spokój. W życiu nie ma nic za darmo, jeśli jeden człowiek i trochę dłubania może rozwiązać ten problem, to byłby już on dawno temu rozwiązany.

Nie lubię bramek, bo one zmuszają wszystkich do posługiwania się tylko funkcjonalnością dostępną w najsłabszym z systemów. To jest dokładnie tak samo jak z systemami stereo. Nie wydaje się 4000 dolarów na świetny system po to, żeby przyłączyć do niego głośniki za 5 dolarów. Takie coś będzie do kitu, jest tak dobre, jak najsłabsza część. Jest zupełnie przeciwnie niż napisałeś, Troy; nie jest w naszym najlepszym interesie stworzenie bramki BK<->$INNY_SYSTEM, bo to oznaczałoby, że BK jest tylko tak dobre jak każdy inny system. To po prostu głupie. Jeśli chcesz to zrobić, to zrób to, ale nie staraj się wcisnąć mi tej pracy, udając, że to jest dobre dla BK, skoro nie jest. Sprowadzanie BK do poziomu przeciętnego systemu zarządzania wersjami nie ma sensu i jest stratą czasu.

Rozważam dodanie paru rozszerzeń do CVS, tak by uzupełnić braki, które kiepsko wpływają na moją produktywność. Ponieważ oczywiście dobrze by było mieć zupełnie wolne (nawet na GPL ;-) narzędzie, które nie powinno się składać z nieakceptowalnych kompromisów w procesie tworzenia jądra, chciałbym dowiedzieć się jak, według użytkowników BitKeepera, wygląda najmniejszy zbiór poprawek, które sprawiłyby, że CVS zyskałby szerszą akceptację. Oczywiście ogromny zbiór cech, które ma BitKeeper, jest imponujący, ale chciałbym zawęzić te rzeczy do zarządzalnego zbioru.

Każdy komentarz będzie cenny dla wolnych projektów tego rodzaju, dostarczy conajmniej cennych wskazówek.

Moja wymarzona opcja?

cvs dontcommit file.c

Co to powinno robić? Zaznaczać zmiany w file.c jako moje prywatne, których system nigdy nie próbuje umieścić w oficjalnym drzewie. Najlepiej by było gdyby diff udawał, że nie ma żadnych zmian.

Zatem, gdy ściągam drzewo, potem robię jakieś brudne sztuczki, żeby się skompilowało i robię cvs dontcommit, cvs nie powinien nic pokazać, a cvs commit nie powinien próbować wysyłać czegokolwiek. To byłoby fajne.

1. działające łączenia
2. oddzielne włączanie całych łat, etykiety
3. narzędzie graficzne do łączenia w obie strony, takie jak ma bitkeeper (to może wydać się mniej podstawowe dla człowieka, który nigdy tego nie używał, ale zaoszczędziło mi wiele godzin)
4. rozproszone repozytoria
5. możliwość wymiany zbiorów zmian pocztą elektroniczną

Chciałbym móc robić zmiany w moim lokalnym drzewie, gdy jestem z dala od internetu.

Chciałbym, aby było możliwe zrobienie nowej gałęzi dla pewnych nowych rzeczy związanych z VM, gdy siedzę w samolocie, bez potrzeby ,,rejestrowania'' gałęzi w systemie kontroli wersji źródeł działającym na prywantnej stacji roboczej Linusa.

Kolejną rzeczą, którą trzeba wziąć tu pod uwagę jest to, że będą tuziny, jeśli nie setki, ludzi tworzących równolegle gałęzie drzewa. Jak kiedykolwiek uda Ci się przekonać rsynca do ich włączenia?

Prawdopodobnie wymagania normalnych deweloperów różnią się od wymagań właścicieli drzew. Normalny deweloper zawsze pracuje na oficjalnych drzewach.

Być może to ekstremalne, ale obecnie pracuję nad kodem, który zawiera z dwanaście zbiorów zmian na 100 plikach. Wiele z tych plików jest zmienianych przez wiele zbiorów zmian. Są zatem dwie rzeczy:

1. Jeśli mam dwa zbiory zmian zaaplikowane do jednego pliku i wykonam pewną zmianę tego pliku, to z którym zbiorem zmian będzie ona związana?
2. Możliwość przesunięcia kilku zmian z jednego zbioru zmian do drugiego, to znaczy: dzielić te cholerne łaty!

Na początek powiedziałbym: zbiory zmian są pojęciem pierwszej kategorii, proponuję też integrację z tkdiff.

6) Możliwość sensownego archiwizowania i zmieniania nazw katalogów. CVS nie wie nawet, czym jest katalog.

7) Wsparcie dla archiwizowania linków symbolicznych, plików urządzeń, kolejek fifo, itp.

jest 'zabójczą cechą' bk i jedynym powodem, dla którego spędziłem kilka ostatnich dni kopiąc Larrego, żeby zrobił parę mniej znaczących poprawek.

Przypuśćmy na przykład, że chcę zrobić Linusowi ,,push'' fragmentów dotyczących reiserfs z mojego drzewa.

Stara metoda:

• diff linux-vanilla linux-dj >dj.diff
• grepdiff reiser dj.diff | xargs -n1 filterdiff dj.diff -i >reiser.diff
• skopiowanie tego pliku do reiser-1.diff reiser-2.diff, tak by każdy diff miał tylko jeden 'temat'
• vi reiser1.diff, wycięcie niepotrzebnych fragmentów
• powtórzenie tego dla wszystkich pozostałych plików
• sprawdzenie, czy łaty dobrze się nakładają na ostatnie jądro Linusa.

(Jeśli w trakcie któregokolwiek z powyższych kroków Linus wypuści nowe pre, dotykające któregokolwiek z plików, do których odnoszą się łaty, to zsynchronizuj wszystko na nowo i wróć do kroku #1)

To zabiera sporo czasu. A dla bardziej skomplikowanych kawałków, to już w ogóle.

Nowa metoda:

• bk pull
• bk citool
• oznaczenie plików z reiserfs jako cset
• ukrycie fragmentów w delcie, które nie mają związku z 'tematem' tego csetu (To właśnie to, nad czym Larry pracował dla mnie przez ostatnie kilka dni. Większość z tego jest zrobione, wymaga tylko paru drobiazgów.)
• Jeśli już zgrupowałem razem cset, generuję diff.

Jeśli w trakcie któregoś z tych kroków Linus zmieni którykolwiek z tych plików, robię bk pull, i przy odrobinie szczęścia, bk robi wszystkie nieprzyjemne rzeczy za mnie i w razie czego odpala narzędzie do rozwiązywania konfliktów.

Wydaje się, że liczba kroków jest podobna, ale ze względu na szybkość wykonywanych tu operacji, bk wygrywa bezapelacyjnie.

Nie znam niczego innego niż bk, co posiada połączoną funkcjonalność citool oraz fmtool. Mój schemat używania tego nie jest zgodny ze zwykłym podejściem, sugerowanym w minihowto Jeffa, przy którym miałbym wiele 'tematycznych' drzew dla każdego zbioru zmian, który chcę przekazać Linusowi. Przy diffie sięgającym 6MB, potrzebowałbym utrzymywać wiele takich tematów, ale, na całe szczęście, zasady bk mogą być łatwo naginane tak, by pasowały do moich leniwych wymagań.

Zamierzam wypróbować to w następnej rundzie łączenia z Linusem (to jest częściowo powód, dla którego nie przekazywałem mu nic ostatnio). Tak szybko jak tylko uda mi się przeprowadzić, zafunduję sobie długą zabawę z bk, by zobaczyć jak szybsze i łatwiejsze stanie się moje życie.

Stosuje się tu zwykłe zastrzeżenie dla Larrego. Wypróbuję tego, a jeśli okaże się, że nie działa, to powrócę do mojego starego sposobu pracy.

To jest świetny przykład Dave, i to jest właśnie ten rodzaj informacji zwrotnej, którego potrzebują deweloperzy narzędzi do zarządzania wersjami. Oto moja aktualna lista cech, których nie ma CVS, a które są ważne dla deweloperów jądra (lub dla mnie).

1. Przechowywanie wybranych metadanych i-węzłów (to znaczy linków, rurek, katalogów, właściciela, ...)
2. Możliwość zmiany nazw plików
3. Oznaczanie całych zbiorów zmian (tzn. globalne oznaczenie łatanych plików)
4. Zaawansowane narzędzie do wykrywania konfliktów w trakcie łączenia (tzn. cechy tkdiff/gvimdiff)
5. Wsparcie dla zdalnych repozytoriów z gałęziami
6. Łączenie i śledzenie zmian w wielu gałęziach na raz (tzn. łączenie odbywa się raz)

Pierwsze są od jakiegoś czasu na mojej prywatnej liście przebojów. Dobra implementacja 5 i 6 jest najprowdopodobniej najtrudniejsza, ale wydaje się także kluczowym elementem dla deweloperów jądra, ze względu na ważność posiadania wielu drzew. Nie przejmuję się wynikami testów CVS, bo wszystkie problemy mogą najprawdopodobniej być rozwiązanie przez dodanie administracyjnych metadanych w celu cache'owania i paru innych dodatków. Jednakże, wydaje mi się, że jeżeli okaże się, iż Arch i PRCS są dość interesujące, to mam nadzieję, że trochę ludzi się nimi zajmie i zobaczy jak blisko są tego, co jest potrzebne. Mój szacunek dla BK został jeszcze wzbogacony przez tę dyskusję, ale ciągle będę wolał wolną (w domyśle GPL) licencję. ;-)

Na razie umieściłem drzewo 2.5 na bk://linuxvm.bkbits.net/linus-2.5

To co tam jest, jest automagicznie mirrorowane z katalogu domowego Linusa na kernel.org przez skrypt /home/riel/pushpull.sh, który uruchamiany jest z mojego crontaba.

Idealnie by było, gdyby Linus uruchamiał to z własnego crontaba i umieszczał dane na bk://linux.bkbits.net/linux-2.5 ;)

jakiś czas temu (w czasach 2.4.2), stworzyłem łatę, która pozwala na używanie pod Linuksem wielu procesorów ix86 działających przy różnych szybkościach.

Łata robi następujące rzeczy:

• Upewnia się, że są ustawione odpowiednie flagi (na wypadek jeśli byłyby nieodpowiednie) przed uaktywnieniem XMM/FXSR.... Odpowiednie oznaczają wspólny podzbiór udostępnianej funkcjonalności.
• cpu_khz staje się oddzielnym polem dla każdego procesora i jest wykorzystywane w fast_get_timeofday(). Przesunięcie od ostatniego tyknięcia zegara również musi być obliczane oddzielnie dla każdego procesora.

Łata działa dobrze, ale ma dość ograniczony zasięg: Nie próbuje nauczyć schedulera faktu, że procesory są różne. Wynika z tego, że proces, który działa na wolniejszym procesorze nie dostaje żadnej ekstra premii. Ma pecha... (Jakieś dynamiczne wyważanie priorytetów w zależności od cpu_khz nie powinno być zbyt trudne do zaimplementowania przy obliczaniu punktów dla procesu, ale na razie chciałem uprościć to tak, jak to się da.)

Załączam łatę do 2.4.16.

W bilbiotece zlib zostały znalezione dwa słabe punkty, króre mogą być wykorzystane do DoS, bądź nawet w bardziej niecnych celach. W chwili obecnej dystrybucje udostępniają już nową wersję zlib, co uodporni programy, które używają tej dzielonej biblioteki.

modutils ma opcję --enable-zlib, która pozwala modprobe i insmod czytać moduły skompresowane przez gzipa. Jeśli zbudowaliście modutils z --enable-zlib i używacie insmod.static, musicie przebudować modutils po aktualizacji zlib. To dotyczy jedynie sytuacji, gdy modutilsy zostały zbudowane z --enable-zlib (domyślnie ta opcja jest wyłączona) i jednocześnie używacie statycznej wersji modutils.

ftp://ftp.kernel.org/pub/linux/kernel/people/dwmw2/linux-2.4.19-shared-zlib.bz2

To jest przeniesienie współdzielonego zliba z 2.5.6. Wykonuje całą alokację pamięci na początku, więc _zakładam_, że opisany problem tam nie występuje.

Zaaplikowanie może wymagać nieco więcej zachodu niż byś chciał.

Sądzę, że ta łata:

http://cvs.samba.org/cgi-bin/cvsweb/rsync/zlib/infblock.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.6&f=u

jest bliższa temu, czego potrzebuję. Wygląda na to, że dostawcy załatali jedynie implementację zlib z ppp (drivers/net/zlib.c). Nie mogę jednak znaleźć tej łaty w zaktualizowanym .src.rpm jądra redhata. Chyba będę musiał zaaplikować tę łatę ręcznie.