stan Ac

[Jakub Bogusz]

On Wed, Jul 07, 2004 at 02:03:30PM +0200, Paweł Sikora wrote:
> On Tuesday 06 of July 2004 16:23, Wojciech 'Sas' Cieciwa wrote:
> 
> > - rozbabrany sparc,
> 
> jesli wylaczymy grsec na sparcu do czasu poprawienia zrodel,
> to mozna juz budowac 2.6.7-1.20.
> w innym wypadku, trzeba zrobic cos z tym:

[...]
> init/built-in.o(.text+0x224): In function `init':
> : undefined reference to `grsecurity_init'

Gdzieś grsecurity jest nie dopisane.

Ale jak można cokolwiek poprawić, skoro co najmniej raz dziennie jest
świeży cset i zamiast tylko poprawić poprzednio występujący błąd
trzeba, wrr, uaktualniać ileś rzeczy, wrr, poczynając od konfiguracji
(przeważnie jest aktualna tylko dla 1-2 architektur) i, wrr, iluś
łat.  Dla przykładu teraz, wrr, jakieś wrr się nie nakłada, wrr.

Tu są potrzebne dwie linie (branche) z jądrem 2.6.
To co jest jest dobre na linię rozwojową.
Ale brakuje linii stabilnej, gdzie byłoby dłużej trzymane _to samo_
jądro, bez najnowszych csetów, tylko z poprawkami błędów wyłapanych przy
testowaniu. I w przypadku np. wykrycia kolejnego błędu security
wystarczyłoby nałożyć łatę na tę wersję i puścić do Ac. Wiedząc, że tam,
gdzie działała poprzednia wersja (dziurawa), to nowe, załatane, też
zadziała - a nie ujawni się nowy błąd w parę dni wcześniej
uaktualnionych sterownikach czy podsystemie. Przy wymianie z 2.6.5 na
2.6.7 czy też snapshot post-2.6.7 do takiej pewności daleko.

Pytanie czy 2.6.x jest już na takie zamrożenie gotowe (2.4.x dla Ra
zostało na dobre zamrożone po raz pierwszy przy 2.4.18...).
Bo jeśli nie - to... za wcześnie na używanie 2.6.x na produkcji.


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/