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

Tomasz Kłoczko kloczek at rudy.mif.pg.gda.pl
Wed Apr 9 14:46:46 CEST 2003


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 at rudy.mif.pg.gda.pl*



More information about the pld-devel-pl mailing list