2.2 vs 2.4 -- propozycja

[Jacek Osiecki]

On 24 Jul 2001, Arkadiusz Miskiewicz wrote:

> Jacek Osiecki <joshua w ceti.pl> writes:

> > > Nikt nie będzie forsował wywalenia na zbity pysk 2.2. Po prostu by
> > > default było by 2.4, a kto by chciał dalej maintainować kernelem 2.2

> > A czemu nie może być na odwrót, skoro przejście 2.2->2.4 jest prostsze niż w
> > drugą stronę? I większość osób nie potrzebuje "ficzerów" 2.4. Jeśli ich

> Może dlatego, że nie lubię trzymania się starszych rzeczy jeśli mogę
> mieć lepsze.

No to może od razu 2.5.x?

> tylko dla mnie. Niby dlaczego w sporej części dystrybucji Linuxa mamy
> 2.4 by default + 2.2 ?

Pogoń za numerkami. Zobacz sobie takiego debiana, uznawanego za
najbezpieczniejszą dystrybucję. I jaki kernel jest w stable? Bynajmniej nie
2.4...

> > 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.

> > A dlaczego przejście trudniejsze? Choćby dlatego, że trzeba się bawić w
> > downgrade pakietów, 
> 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ć :-(

> > 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.

> > Niestety, używam PLD na tyle długo że widzę tutaj dwie tendencje: jedna,
> > która mi się podoba, to stawianie na stabilność, natomiast jest też grupka
> > która chce tylko ślepo gonić za wyższymi numerkami.
> 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...

> > 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?
A wpadka z "najnowszym, lepszym" openssl, z którym openssh nie działa?
A możliwość upgrade'u glibc bez upgrade'u iconv (zdaje się, że nadal jest to
możliwe)?

Takie kwiatki pojawiają się co chwila, bo ktoś zobaczy wersję pre-alpha i
wrzuca ją do dystrybucji...

> > Założę się, że jak tylko 2.2 wyląduje w /supported, to nie minie parę
> > tygodni a już przejście na 2.2 będzie wymagało chorych kombinacji.
> Spekulacje.

Ale nie bezpodstawne.

> > > Póki co to się nie zanosi na PLD 1.0.

> > ... 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...

> > > Nikt 2.2 nie skasuje. Będzie leżało nadal (tylko już nie defaultowo).

> > A w Chinach jest wolność wypowiedzi o ile się dostanie zgodę milicji :-)
> > Zrozum, wyrzucenie 2.2 do /supported to koniec 2.2 w PLD - i tym samym
> > koniec PLD na wielu serwerach.
> 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.
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ć" :-(

> > No to czemu nie zrobić możliwości PROSTEGO wyboru - i wrzucić oba kernele i
> > zależne od nich pakiety do katalogów 2.2 i 2.4? Zamiast tego chcecie na siłę
> > wsadzać 2.4 i potem "zgaduj zgadula" co nie działa, dlaczego i gdzie szukać
> > odpowiedniego pakietu.
> 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?

> > 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.

> > > 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...

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. 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.

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

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ę. Tyle, że developerzy zdają się robić wszystko, żeby to
     zdanie zmienić :-(

Pozdrawiam,
-- 
Jacek Osiecki
joshua w ceti.pl