static-routes

[Tomasz Kłoczko]

On Wed, 6 Nov 2002, Jacek Konieczny wrote:

> On Wed, Nov 06, 2002 at 10:14:59AM +0100, Tomasz Kłoczko wrote:
> > On Wed, 6 Nov 2002, Artur Flinta wrote:
> > > On Wed, 6 Nov 2002 09:51:16 +0100 (CET)
> > > Tomasz Kłoczko <kloczek w rudy.mif.pg.gda.pl> wrote:
> > > > Prędzej od razu zaczniemy używać 2.5 .. i tak wiadomo, że 2.6 będzie
> > >
> ...
> > > BTW, z tego co mi się wydawało to 2.4.x jest dosyć popularnym jajkiem i
> > > sporo osób z PLD tego używa. 
> > 
> ...
> > I jeszcze raz .. w tym wypadku warto uwzględniać potencjalny czas trwania
> > cyklu wypuszczenia 2.0.
> 
> Weź pod uwagę, że wiele osób chce na bierząco korzystać z rozwoju PLD na
> swoich maszynach produkcyjnych. To co porponujesz spowoduje sytuacje, 
> w której dostępne będzie PLD-1.0, przestarzałe z założenie i tzw. HEAD,
> którego instalowanie na produkcyjnej maszynie byłoby dość ryzykowne
> (chociażby z powodu kernela 2.5/2.6).
> 
> Zauważ, że akatualna popularność PLD wynika z tego, że dawało ono wciąż
> rozwiające się, ale w miare stabilne środowisko na serwery. Opierając
> dalszy rozwój o kernel 2.5 praktycznie to przekreślisz.
> 
> IMHO PLD powinno być, po wypuszczeniu 1.0, rozwijane w podobny sposób co
> ostatnio: 
> - STABLE, oparte o kernel 2.4, na bierząco rozwijane z użyciem
> nowego oprogramowania, ale bez rzeczy eksperymentalnych, czy w inny
> sposób podejżanych.
> - NEST, gdzie można testować cokolwiek
> 
> STABLE od 1.0 różniłoby się tym, że możliwe byłoby przechodzenie na nowe
> glibce, gnomy itp. Ale pod warunkiem że one wogóle mają szansę działać 
> i nie są oficjalnie uważane za "unstable" czy "experimental".

Tym samym dalej bedziemy mieli małe szanse mieć mały dystans od up-to-date 
do tego co bedziemy mieli.
I jeszcze raz .. rozpoczyna się devel cykl. Na to żeby wytestować glibc, 
gcc i to jeszcze na kilku arch pół roku to dość wystarczajcy okres.

Po drygie: "siedząć" na szczycie zmiana w kernelu:
- odpada nam zabawa z integroaniem dużej ilosci patczy z tym co na 
  bieżącjest potrzebne (Linus dość energicznie integruje to co mzoę być 
  już zintegrowane)
- w razie zauważenia błedół mamy większe szansę ze ktoś kto wogóle jest w 
  stanie skompletować potzrbną poprwakę skompletuje ją w znośnym czasie,
- używajac 2.5 bedziemy aktywniej rozwijać kernel i/lb choćby bedzie nas 
  lepeiiej widzieć jako grupę -> łatwiej będzie się nam promować PLD po za 
  Polską.

Chodzo rzecz prostą .. mianowicie o to że niejako ucieczka w przód 
dać nam może kolejną zauwazalną różnicę miedzy PLD i resztą -> przyciagnie 
do nas kolejne osoby. Jest to niewątpliwie wyzwanie. Takie wyzwanie możemy 
podjąć właśnie teraz lub możliwie szybko (im okres używania 2.4 będzie 
krótszy tym lepiej). Zauważ, że pracujac wczęniej juz na 2.5 w momencie 
kiedy wyjdzie 2.6 powidźmy że włsnie w okolicach czerwca zaknięcie 2.0 
będziemy w stanie zrobić dużo szybciej, a co ważniejsze wszyscy będą juz 
obstukani z nowymi mozliwaciami koejnej wersji kernal .. tym samym lepiej 
będa te mozliwośći utylizować w zasaobch dystrybucyjnych (od rc-scripts 
zaczynając a na innych rzeczach zależnych od kernela kończąc).
Kąsków w 2.5 które można próbowac gryźć w 2.0 jest sporo: USB, lepsze 
wsparcie do FB, NFS4, lepszy accounting i raportowanie bieżącego stanu 
większej ilości elemrntów zarżadzanych przez kernel), lepsza skalwalność, 
za kawałek lepsze wsparcie do ipv6 i kupa innych zreczy z któryuch 
integroaniem musielibyśmy się teraz męczyć sami decydujac się na 2.4 
(zakładam, że przejściowo na poczatku prac nad 2.0 kernel 2.4 będzie 
jednak używany przejściowo ale przez jednak możliwie krótki czas).

Jeszcze raz: oparcie się o devel kernel 2.5 to jest niewątpliwie wyzwanie
.. ale wyzwanie które IMHO *warto* podjąc możliwie szybko.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*