[rfc] HOME-ETC.txt [by³o: Re: Wolna amerykanka w PLD?]

Tomasz K³oczko kloczek w rudy.mif.pg.gda.pl
¦ro, 9 Kwi 2003, 14:46:46 CEST


On Wed, 9 Apr 2003, Pawe³ Go³aszewski wrote:

> On Wed, 9 Apr 2003, Tomasz K³oczko wrote:
> > > Ca³a dyskusja powinna siê sprowadziæ do tego jak nazwaæ tê zmienn±. Bo
> > > to, ¿e powinna byæ bezwzglêdna jest oczywiste. Podstawowym argumentem
> > > za jest to, ¿e ³atwiej robiæ patche. W robieniu patcha te¿ nie ma
> > > du¿ej filozofii.
> > Wybacz ale programy nie pisze sie tak, a nie inaczje tylko dlatego ¿e
> > komu¶ jest co¶ ³atwiej zrobiæ. Po drugie mo¿e napisa³eby¶ dlaczego
> > powinno byæ to jako zmienna ze ¶wie¿k± bezwzglêdn± bo oczywiste to nie
> > jest, a co wiêcej napisa³em ju¿ dlaczego tak sie nie powinno robiæ. Po
> > trzecie zapominasz, ¿e ca³o¶æ dotyczy relokowania zasobów l±dujacych do
> > tej pory *w katalogu domowym u¿ytkownika* i ¿e w przypadku tak
> > okre¶lonej klasy zasobów nie ma najmniejszego sensu robiæ czegokolwiek
> > co by powodowa³o ¿e jakim¶ cudem mog± siê wywêdrowaæ z tej lokacji.
> > $HOME w tym wypadku ma byæ *sta³ym* elemetem ¶cie¿ki .. tak jak to do
> > tej pory by³o. Chcesz to sobie robiæ inaczej ? prosze bardzo ..
> > manipuluj na w³asny u¿ytek ta zmienn±. Nikt Ci tego nie broni i nei
> > musisz do tego preparowaæ choæ jednej linijki patcha.
> 
> 1. Dlaczego to lepiej jakby by³a zmienna bezwzglêdna - kilka osób ci ju¿ 
> mówi³o tutaj o korzy¶ciach z tego. Przeczytaj.

Pawe³ .. przecie¿ masz zmienn± bezwzgledn±. Nazywa siê $HOME. Po co
jeszcze jedna ? Jakies upiêkszenie ? Czy mo¿e porostu w³a¶nie btrak
¶wiadomo¶ci, ¿e pe³na kontrola ju¿ nad tym jest (?) i to na du¿o wieksza
ilosæ sposobów ni¿ Ci siê wydaje. W sumie tylko neiaka tradycja my¶lenia
wbija np. Ciebie zeby do takich zreczy nie uzywaæ $HOME.

Tak czy inaczje $HOME jest tak¿e wykoprzystywane w wielu innych miejscach. 
Dot±d oznacza³ on katalog wspólny do pewnych dzia³a jak i kaytalog g³ówny 
do tego ¿eby *w ramach* $HOME trzymaæ inne zasoby w tym i konfiguracyjne.
Wszystko do takweigo modelu jest przystosoweane. Powtórze, ¿e w pierwotnym 
zamy¶le ca³osæ by³a pomy¶lana jako sposób na relokacje w *ramach $HOME* 
tylko zasobów konfiguracyjnych.

Wszelkie inne kombiacje z wyjrzedzaniem z tymi zasobami po za $HOME s± ju¿
bardzo lu¼n± interpretacj± po za wszelkie dotychczasowe standardy 
trzymania zasobów prywatnych uzytkownika.
tak mocno chcesz zeby wytykali Cie palcem jako kogo¶ kto nagle po ponad
Cwieræ wieku zauwa¿y³ ¿e "potencjalnie" mo¿na to z³amaæ .. i to tak bez 
¿adnego w sumie powodu tylko dlatego ¿e w sumie mo¿na to zrobiæ przy
okazji zmian które maja ¶ci¶le okre¶lony cel (?)

Nie Pawe³. Tego typu podej¶cie jest ju¿ WARIACTWEM i uzasadnionym tylko 
"potencjalnym" ryzykowaniem narazania kogo¶ na co¶ czego sam nie u¿ywasz 
i jestem przekonany ¿e nie u¿yjesz (mowa o uwspólnianiu konfiguracji).
Wiesz na ile róznych sytuacji typu róne tmp race i inne w ten sposób 
narazasz ca³osæ ? Zauwa¿, ¿e zwykle to co robi sie w ramach $HOME nie
podlega ¶cis³emu i szczegó³owemu audytowi. Dlaczego ? Ano dlatego ¿e 
wiadomoze zasoby tutaj obecne b±d± nale¿eæ do  konkretnego i tylko jednego 
u¿ytkownika.

Przyk³ad: cvs u¿ywa $(HOME) do przechowywania .cvspass. Narazisz siê na 
ryzyko u¿ywania tych samych hase³ z kim¶ innym bo akurat chcia³e¶ mieæ
taka sama konfiguracjê KDE jak kumpel ? Czy to naprawdê tak trudno
rozpropagowaæ co¶ takiego poprzez skopiowanie plików ? Czy napradê 
u¿ywanei takeij samej konfiguracji jak znajomyy musi byæ zwi±zane z 
u¿ywanienm dok±³dnei tych samych plików ?

Wybacz Pawe³ ale w ca³ym tym zamieszaniu zdajesz sie zachowywaæ jakby
"potencja³" pewnej zmiany przys³oni³ Ci zdrowy rozs±dek. Ludzie z powodu
takiego typu zapatrzenia i braku krytycyzmu s± w stanie pope³niæ czaami
naprawdê paskudne bezeceñstwa. Widz±c tego typu zapêdy i w³a¶nie brak 
*krycznego* podej¶cia przy pe³nym "entuzja¼mie" je¿eli tak dalej pójdzie 
nie poziostanie mi nic innego jak powiedzieæ tym zmianom proste "NIE" i to
tylko dlatego, ¿e w za¶lepieniu wrêcz próbuje siê z tego zrobiæ ju¿ nie 
co¶ u¿ytecznego co jaka¶ karykaturê.

Jeden przez drugiego chêtnie dodaje "popieram" ale nikt jako¶ nie zadaje
sobie pytañ typu "a co by by³o gddyby tak ? " maj±c na my¶li za³o¿enie
¿eby próbowaæ testowaæ pomys³ przy mo¿liwie najmniej korzystnych
scenariuszach (tak jakny tylko patrzenie "pozytywne" na to mia³o wogóle
racjê bytu).

> 2. To, ¿e to rzeczy dotychczas by³y w katalogu u¿ytkownika nie znaczy, ¿e 
> tam musz± byæ. Sam podawa³em kilka bardzo u¿ytecznych przyk³adów, gdzie 
> ulokowanie w innym miejscu by³oby bardzo porz±dane

Poda³e¶ doka³dnie jeden przyk³ad polegajacy na uwspolnieniu konfiguracji.
Otó¿ powtórze, ¿e wspólna konfiguracja jest na poziomie systemowych plików
konfiguracyjnych. Czego wiecej Ci tu trzeba ? Widzia³e¶ choæ jeden 
przypadek przy którym¶ kto¶ cmokna³ "fajnie by³oby mieæ co¶ takiego" ?

> 3. Przyk³ady, które podawa³e¶ w ¿aden sposób nie s± wyeliminowane przy 
> zmiennej bezwzglêdnej.
> 4. Wrêcz nawet okre¶lenie w zmiennej, ¿e co¶ jest =$HOME/etc jest znacznie 
> bardziej naturalne. Kiedy¶ jak zaczyna³em u¿ywaæ home_etc w pierwszym 
> odruchu co¶ takiego w³a¶nie zrobi³em :)

Podaj mi choæ jeden praktyczny przyk³ad nie ³amiacy np. FHS czy innych
który uzasadnia³by my¶lenie o zasobach konfiguracyjnych *u¿ytkownika* jako
takich które mog³by byæ w jakim¶ przypadku po z katalogiem domowym
u¿ytkownika.

Jeszcze raz. Pro¶ba o skupienie siê na mozliwie w±sko okre¶lonych celach.
Takich które z za³o¿enia da siê przez ograniczon± i ma³± ilo¶æ stopni
swobody przeanalizowaæ pod kontem konsekwencji. Bêdzie za ma³o to siê co¶
do³o¿y ale na pocz±tek niech bedzie jednak niezbêdne minimum. A nie niech
do diaska wogóle bêdzie za ma³o i to z powodów czysto praktycznych jak
choæby u¿ywana ju¿ przez Ciebie czy kilka inncyh osóbrelokacja do ~/etc.

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*



Wiêcej informacji o li¶cie dyskusyjnej pld-devel-pl