SPECS: duke3d.spec (HEAD)

[Tomasz Kłoczko]

On Mon, 7 Apr 2003, Piotr Szymański wrote:

> Tomasz Kłoczko (Monday 07 of April 2003 05:26)
> > Podaj choć jeden merytoryczny argument przemawiający za rozbiciem na
> > kilka katalogów :)
> Jeden mi przyszedl :) Ze mam porzadek na dysku, przeciez idac twoja idea to 
> mozna wywalic nawet glowna strukture i zrobic wszystko w / bez 
> usr,boot,etc...

No jakby nie patrzeć to nie masz racji bo pominiecie /usr i wstawianei 
czegoś wprost do /lib, /bin i /sbin ma sens ze względu na bootstrap (i co 
wąłsnei w taki własnei sposób jest uzasadniane takze w FHS czy starszym 
FSSTND).

> Zalezy mi na przejrzystym drzewie katalogow, zamist 5k binarek w usrbin wole 
> 2k w usr/bin i 2,5k w usr/x11r6/bin. Przynajmniej wtedy mam pewnosc ze jak 
> odpalam cos z usr to nie bedzie wymagalo x'ow.

2k a 2.5k to w sumie i tak coś co się miesi między 2^11 a 2^12 czyli przy 
wyszukiwaniu połówkowym różnicy w prędkosci dosępu nie będzie. A do /usr w 
sumie jeżeli wszystko dział nie ma potrzeby zaglądania bo to jest swego 
rodzaju zasobnik z zasobami systemowymi które się na bieżąco używa i 
baaardzo żadko przegląda :)
Konsekwencja tego bedzie takze to że to raczje tylko na jednym katalogu 
bedzie można założyć hash atrybut .. a nie na kilku.
Co do /usr i X11 to w tej chwili masz tam już sporo aplikacji które 
używaja bibliotek X11. W niektórych przypadkach wrecz cieżko rozstrzygnąć 
gdzie w sumei werzuciś apliakcje bo ta sama binarka mozę pracować jako 
term jak i X display klient.
Po drugie zapominasz o pewnych konsekwencjach uproszczenia o których już
pisałem które sa bardzo ważne z punktu neimal automatycznego zamykanai 
dróg dla pewnych błedów typowo powstajacych czy to na etapie pisania 
programu czy to jego kompilowanai i linkowania. Masz mniejsża ilość 
narażenia systemu na pojawienie się np. niezgodnych ze sąbą bibliotek 
które zaleznie od tego co byłoby w /etc/ld.so.path mogłby być używane 
powodujac typowy lib clash.
Zwróć uwagę ze zaczynamy oprogramowanie traktować na skalę masowa .. 
tysiać, dwa tysiace .. kilkanaście tysiecy binarek. Metodologia wraz ze 
zmiana skali także powinna się zmienaić żeby nie narażać całość na 
rozsnace ze skalą pojawianie się pewncy klas błędów.

Po za tym wybaczcie.. widziałem conajmniej kilak setek działających
systemów. Spora ich ilość to były jednostki dostępowe na których pracowało
kilkadzisiat do kilkuset ludzi. Potencjalnie każdy mógł tam wydzielić
/usr/X11R6 dla innej grypy .. tylko do diaska dlaczego z tej możliwości
niemal nikt nie korzysta ? :) .. mniejwiecej tak samo jak to ze mogę 
także potencjalnie pójść się wykompać teraz w morzu (sensu w tym jednak 
byłoby mało :)

Wszystko to wyniak z pewnego zakodowania że "tak się robić powinno".
Przekonanie to jest tak duże że pomysł zmiany rodzi w pierwszym podejściu
irracjonalny sprzeciw, a opamietanie przychodzi dopietro jak się
zastanowić nad tym głebiej "a gdyby jednak tak to co ?" gdzie wnikać sie
zaczyna w konsekwencje takiej zmiany. Wtedy okazuje się że znikaja w sumie 
iluzoryczne/potencjalne możliwości ale pojawiają się inne jak 
najbardziej namacalne :)

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*