2.2 vs 2.4 -- propozycja

[Arkadiusz Miskiewicz]

Jacek Osiecki <joshua w ceti.pl> writes:

> > Może dlatego, że nie lubię trzymania się starszych rzeczy jeśli mogę
> > mieć lepsze.
> No to może od razu 2.5.x?
I co tu pleciesz. Kernele 2.5.x zawierają eksperymentalne cuda i z
definicji są unstable.

> > tylko dla mnie. Niby dlaczego w sporej części dystrybucji Linuxa mamy
> > 2.4 by default + 2.2 ?
> 
> Pogoń za numerkami. 
Pogoń za features. np. XFS - super sprawa i nie mam z nim tych
kłopotów które miałem z reiserfsem - ale tylko w 2.4.

> Zobacz sobie takiego debiana, uznawanego za
> najbezpieczniejszą dystrybucję. 
I najbardziej zacofaną (same stare programy)...

> I jaki kernel jest w stable? Bynajmniej nie
> 2.4...
Jasne jest, że jak się stanie w miejscu i zacznie dopieszczać
określoną wersję danych pakietów to będzie się miało świetnie
działającą dystrybucję tylko... bez masy przydatnych opcji jakie dają
inne dystrybucje zawierające nowsze oprogramowanie.

> > > A Ty chcesz żeby instalowało się 2.4 niezależnie od tego czy komuś się to
> > > podoba czy nie, a potem "róbta co chceta" i zmuszanie ludzi do
> > > kombinacji.
> > A Ty chcesz 2.2 niezależnie od tego czy komuś się to podoba czy nie, a
> > potem ,,róbta co chceta'' i zmuszanie ludzi do kombinacji.
> 
> Jeszcze raz - przejście "w górę" ZAWSZE jest łatwiejsze.
Tak tylko chodzi o stopień trudności przejścia w dół. NIE JEST on
DUŻY.

> > No i cóż w downgradowaniu jest tak trudnego w porównaniu z
> > upgreadowaniem? Ta jedna opcja rpma (--oldpackage) jest tak trudna do
> > nauczenia?
> 
> Nie. Ale tak się składa, że za chwilę ktoś przekompiluje glibc pod 2.4. A
> nawet jeśli nie, to nagle się okaże, że nie można zrobić downgrade'u, bo np.
> rpm-a się nie da zdowngrade'ować i inne tego typu problemy. Używam PLD na
> tyle długo, że mam podstawy się tego obawiać :-(
Zaraz... o czym w ogóle piszesz? Po co downgradować rpma zmieniając
kernel z 2.4 na 2.2?

> > > od których wcześniej czy później coś zacznie być
> > > zależne, potem pojawi się jakiś rpm zależny od kernela itp...
> > Znów czyste spekulacje.
> Oparte na wcześniejszych doświadczeniach.
Konkretnie napisz co to za doświadczenia.

> > Ja używam i robię PLD od samego jej początku i nie widzę ,,tylko
> > ślepego gonienia za wyższymi numerkami''. Te wyższe numerki mają swoje
> > uzasadnienie (np. tcpdump/libpcap swego czasu czy, teraz aviplay,
> > mplayer, tetex). 
> 
> Tylko że przez te numerki co chwila coś nie działa...
Akurat w przypadku powyższych pakietów te numerki sprawiły, że w końcu
działa.

> > > I potem mamy piękne
> > > bulby takie jak niedziałające ssh 
> > Cóż mi ssh działa doskonale (2.9p2).
> 
> A wpadka z zepsutym patchem na kernel i w związku z tym niedziałające
> openssh przy ipv6 w kernelu?
Nie wiem o jakiej wpadce mówisz jako, że mam kernel 2.4.5-1 + openssh
2.9p2 i nie mam żadnych problemów (a ipv6 używam).

Jest problem ze wszystkimi Linusowymi kernelami 2.2.x, które są
ZWALONE na dzieńdobry jeśli chodzi o ipv6 i mamy na to dirty patche.

> A wpadka z "najnowszym, lepszym" openssl, z którym openssh nie
> działa?
Działa, działa. To, że my o czymś nie wiemy (tego, że openssh sobie
sprawdzał wersję openssl at runtime) nie oznacza, że to jest błąd w
openssl.

> A możliwość upgrade'u glibc bez upgrade'u iconv (zdaje się, że nadal jest to
> możliwe)?
To nasz błąd i nie ma tu znaczenia czy to nowe czy jakieś stare glibc.

> Takie kwiatki pojawiają się co chwila, bo ktoś zobaczy wersję pre-alpha i
> wrzuca ją do dystrybucji...
Błędów się nigdy nie ustrzeże. I nie ma aż tak wielu wersji
pre-alpha. To kilka pakietów maksymalnie (podaję z pamięci :)

> > > ... bo jest niestety grupka "numerkowców", którzy nie potrafią się pogodzić
> > > z tym że jakiś pakiet działa dobrze i stabilnie i muszą wrzucić zamiast
> > > niego numerek wyżej... a to że to jest prealpha to już nie zwrócą
> 
> > Bajki opowiadasz. Nie zanosi się na PLD 1.0 bo NIE MA OSOBY KTÓRA BY
> > SIĘ ZA TO ZABRAŁA. Możemy bez problemu zamrozić aktualny stan PLD w
> > postaci brancha i dopieścić go, a w efekcie wypuścić release tylko daj
> > nam release managera, który doprowadzi sprawę do końca!
> 
> Ja jako główny problem widzę właśnie "pływające" pakiety, które już dawno
> mogłyby być zostawione w spokoju...
Tak możemy gadać bez końca. Powiedz które pakiety i porozmawiamy o
tym czy był sens je aktualizować czy nie. I nie mówię tu o nowych
softu wypuszczanych przez ich autorów jako stable bo to normalne, że
takie lądują w cvsie możliwie najszybciej po ich wypuszczeniu przez
autorów.

> > Spekulacje. A może dzięki 2.4 PLD znajdzie się na wielu nowych
> > serwerach?
> 
> Bardzo wątpię. Jak ktoś ma postawić strategiczny serwer, to NA PEWNO nie
> będzie go stawiał na niestabilnym kernelu.
No i znów gadka stabilny czy nie. Dla jednych jest stabilny dla innych
nie i tyle. W ten sposób to mogę powiedzieć, że 2.0 jest o wiele
bardziej stabilny i powinniśmy do niego wrócić. 

> Swoją drogą, znam paru adminów, którzy bardzo chętnie by przeszli na PLD. A
> dlaczego działają na debianie? Bo nie chcą się przejechać na "nowych,
> lepszych" wersjach oprogramowania, radośnie wrzucanych do dystrybucji.
> Jak powiedziałem im o planowanym przejściu na 2.4.7, to reakcja była taka:
> "cóż, można się było spodziewać" :-(
I dlatego potrzeba stable brancha. HEAD ma zostać tak jak jest. Są
admini lubiący stare, dopracowane oprogramowanie jak i Ci którzy lubią
świeże mięsko (niby dlaczego freshmeat.net jest tak popularny?). Dla
mnie PLD jest świetną dystrybucją bo niemal zawsze znajdę tu to czego
potrzebuje i to w aktualnej wersji, a nie jakiegoś starocia z przed
kilku lat.

> > Bo to NIE JEST proste z technicznego punktu widzenia (chodzi o
> > nagłówki na builderach). Pozatym OBA kernele leżą na ftp, a jedynie
> > brakuje zależnych od nich pakietów z powyższego powodu technicznego.
> 
> No to może najpierw doprowadzicie do możliwości wrzucenia na ftp KOMPLETU
> pakietów dla obu kerneli a dopiero potem będzie zabawa w przymusowy upgrade
> do 2.4.7?
Tak, najprościej jest objechać i kazać/poprosić o naprawienie. Dasz
rozwiązanie problemu to się zrobi... Bez sensu jest tworzenie osobnego
chroota tylko po to by kompilować soft z nagłówkami 2.x != defaultowy
kernel. A rotacja za pomocą np. symlinków w /usr/src/* znów spowoduje
problemy przy upgradach pakietów kernelowych na builderach itd.

> > > Owszem, ten gość trochę przesadzał - choć dzięki jego "głupiemu" uporowi
> > > uniknął paru brzydkich bulb w 2.2.
> > > A Wy chcecie dać jako domyślny kernel 2.4.7, które ledwo co zaczęło być
> > > _akceptowalne_... a błędów pojawi się jeszcze bez liku.
> > Nie ma nic idealnego. Jest tylko kwestia oceny zalet w stosunku do
> > wad. 2.4 miały tą problemy z VM i to była wada przewyższająca zalety,
> > a jako, że została usunięta to w mojej opini zalety przeważają nad
> > wadami i dlatego jestem za 2.4 by default (choć 2.4 używam od początku
> > i nie narzekam)
> 
> 2.4. jest kernelem na tyle rozbudowanym, że NA PEWNO ma błędów jeszcze za
> dużo, by zostać uznanym za dopuszczalny. Podstawy twierdzenia? 2.0.x były
> DUŻO mniej złożone i miały w sobie znacznie mniej "niebezpiecznego" kodu
> (sterowniki AGP, vfl, chipsety "experimental" itp.), a poważne błędy
> pojawiały się przy wysokich sublevelach! Z 2.2. było podobnie... 2.4
> wprowadza tyle innowacji, że potencjalnych błędów jest bardzo wiele.
Dobra ale 2.2 też zawiera błędy. Wszystko zawiera błędy! Jeszcze raz
powtórzę: 2.4 jest dla mnie lepsze niż 2.2! Przynajmniej ipv6 działa
jak należy nie to co w 2.2 i mam XFS. Nie mam prawa narzekać na 2.4 bo
jak narazie spisują się u mnie doskonale.

> > > > Mamy iść do przodu, a nie stać w miejscu.
> > > Proszę bardzo. Tylko wtedy w ogóle nie ma sensu mówić o dystrybucji jako
> > > takiej - bo NA PEWNO nigdy nie powstanie.
> > Teraz mamy się sprzeczać o definicję dystrybucji? 
> 
> Powiem tyle: trudno mówić o dystrybucji, jeśli jej użytkownik nie zna dnia
> ani godziny, gdy jego system straci możliwość update'ów. A PLD niestety jest
> na dobrej drodze do takiego właśnie stanu...
No to posłuchaj. Mam jeden serwer z RedHatem 7.0 z updatami. Zasada
jest taka, że jak wszystko działa do się go nie dotyka. Okazało się,
że będzie tam potrzebny mysql i phpmyadmin... Niestety, wersja php
dostarczana z rh7 (jak i w updatach) jest stara i nie działa z
phpmyadmin. Teraz pozostaje zaktualizować php ale ... rh nie dostarcza
nowszej wersji php dla 7.0 czy 7.1! No i co mi
pozostaje... zrekompilować samemu (tona *-devel w tym krb5-devel itd)
albo wziąść z rawhide tyle, że nowe php z rawhide wymaga kilograma 
nowych bibliotek, a to pociąga za sobą kolejny kilogram programów.

Na dodatek jeśli wezmę coś z rawhide i jeśli okaże się broken to
jestem lekko ugotowany - musiał bym posiedzieć i popoparwiać jakieś
tam rawhidowe programy. Mając PLD mogę być pewien, że w ciągu kilku
godzin (a w ostateczności dni) błąd zostanie poprawiony (co więcej sam
go mogę poprawić)...

Nadal chcesz mi wmawiać, że trzymanie się określonych wersji programów
i kompletnie ich nieaktualizowanie, a jedynie maintainowanie to
najlepsza metoda?

> Wcześniej gonitwy z glibc - i trzeba było wybierać: albo zostać z aktualną
> wersją WSZYSTKICH programów, albo ryzykować bilet w jedną stronę na wyższe
> glibc. 
Nie zdajesz sobie najwyraźniej sprawy ILE BŁĘDÓW poprawiane jest w
glibc pomiędzy releasami. Aktualizacja glibc to konieczność.

> Gdy to jeszcze było na serwerze koło którego się siedzi, w
> najgorszym wypadku groziło parę godzin ręcznego grzebania przy konsoli. Przy
> serwerze zdalnym taka sytuacja jest NIEDOPUSZCZALNA.
Ów rh7 mam zdalnie. I dziękuję bardzo za taką dystrybucję... wolę PLD
ale niestety przez jakiś czas jej nie przeinstaluję :/

> I po prostu admini zostaną postawieni po raz kolejny przed takim wyborem...
> i może się skończyć tym, że wybiorą. Inną dystrybucję :-(
Trudno. 

> P.S. Może moje wypowiedzi brzmią radykalnie, ale po prostu PLD już napsuło
>      mi nerwów nie raz i nie dwa... mimo to nadal uważam je za dobrą
>      dystrybucję.
Mi co prawda nie napsuło nerwów ale rzeczywiście zdaża się, że coś
zostanie skopane i z jakiegoś powodu nie działa. Tyle, że w większości
przypadków taka sytuacja jest wychwytywana w ciągu kilku godzin/dni i
poprawiana. Nikt nikogo nie zmusza do używania najnowszych wersji
programów szczególnie jeśli pojawiły się na ftpie niedawno.

>      Tyle, że developerzy zdają się robić wszystko, żeby to
>      zdanie zmienić :-(
Można by tu spróbować stosować bardziej restrykcyjne reguły
przerzucania pakietów z test do PLD-1.0 np. min. 1/2 tyg leżenia w test
przed przerzuceniem itd. W tym czasie być może niedoróbki były by
wychwycone.

> Jacek Osiecki

-- 
 Arkadiusz Miśkiewicz, AM2-6BONE, 1024/3DB19BBD
 IPv6 ready PLD Linux at http://www.pld.org.pl/
My jsme Borg. Odpor je marný, budete asimilováni