[undefine@aramin.net: Fwd: SOURCES: pygopherd-conf.patch (NEW) - root dir for PLD]

[The Undefined]

On Thu, Sep 02, 2004 at 01:07:45AM +0200, Michal Chruszcz wrote:
> > czyli wolisz bałagan?
> > spoko, nikt Ci nie broni... ;)
> 
> Bałagan? O czym Ty mówisz? W końcu to Ty chcesz zrobić rozpierduchę! 
ja? wydaje Ci się.

> Oczywiście, przeniesienie danych aplikacji (jak to miało miejsce 
> przykładowo w phpMyAdminie), które nie mają nic wspólnego z 
> przeznaczeniem /home/services jest jak najbardziej na miejscu, ale tylko to 
> jedno. Nic więcej.
zdefiniuj proszę _co_ dokładnie ma być w /home/services wg Ciebie.
Katalogi domowe demonów? 
czy coś jeszcze?

> > zresztą - czy ja coś mówię że coś chcę? nic na siłę przecież nie robię.
> > co więcej - nic nie robie, tylko sobie ... ee..
> 
> Tak, jak zwykle trollujesz...
a ty bredzisz. i co? będziemy sie prześcigać na.. cośtam?

> > a to się zgadza... dlatego chyba nikt tego nie forsuje na siłę...
> > ale przy nowych aplikacjach imho warto by to było robić "z głową".
> 
> Nowych - oczywiście. Ale odpowiednich, a pyghopherd z powyższym patchem 
> *jest* zrobiony z głową.
nie jest robiony z głową. ten patch ustawia domyślne miejsce na
dokumenty serwowane gopherem na katalog /home/services. Zdajesz sobie z
tego sprawę? Uważasz że tak powinno być?

IMHO:
- domyślna strona gophera/httpd powinna znaleźć się w /usr/share
- admin jak mu się domyślne "powered by cośtam" nie podoba powinien to
  sobie zmienić na /srv czy /gdzie/tylko/ma/ochote/chocby/nawet/home/services.

masz lepszy pomysł? Uzasadnij go popierając się FHS-em ;)

> > wg mnie to może być w
> > /home/services/httpd/apache/apache-2/php/php-5/programs/webmails/...
> > mi to rybka. I tak u siebie zrobię po swojemu. Ale jest niezgodne z FHS
> > ;)
> 
> Że co? Przecież /home jest miejscem na katalogi _domowe_ użytkowników. A to, 
> że user postgres jest dostarczany w celu obsługi bazy, to ląduje w 
> services, a nie w users.
ok, to teraz uzasadnij ten sam przykład ale na podstawie bohatera
gopherd z aktualnego tematu ;)

> > > Ponieważ każda przeprowadzka danych obsługiwanych przez daemony niesie
> > > ze
> >
> > czyli danych programów? no to chyba /var/lib jest dla nich właściwym
> > miejscem?
> 
> Powtarzam po raz kolejny - zgadzam się, że statyczne dane aplikacji jak 
> webmaile itp. powinny wylądować w /usr/share, ale w innych przypadkach nie. 
#define inny przypadek?

> I na ten przykład rozbudowując sobie jakikolwiek serwis oparty o virtual 
> hosty, /srv jest idealnym miejscem na przygotowanie przejrzystej struktury. 
> Ale robiąc jedną usługę /home/services nadaje się świetnie ze swoimi 
> standardowymi katalogami. W końcu należy unikać redundacji.
yy?
dlaczego niby?
miejsce na dane serwowane czyms tam jest w /var/ albo /srv. A napewno
nie jest w /home/services. /home/services z tego co rozumiem i co
jeszcze podpada pod FHS nadaje się jako miejsce na katalog domowy
użytkowników na których może być konieczność logowania się. Na gophera
nie ma potrzeby logowania się.

> > pokaż mi gdzie to pisze. w FHS nic nie widzę na ten temat ;)
> > co więcej, wg
> > http://www.pathname.com/fhs/pub/fhs-2.3.html#HOMEUSERHOMEDIRECTORIES
> > #v+
> > /home is a fairly standard concept, but it is clearly a site-specific
> > filesystem. [9] The setup will differ from host to host. Therefore, no
> > program should rely on this location.
> > #v-
> 
> Ale chyba nie będziesz wrzucał do jednego worka, znaczy katalogu, userów 
> automatycznych (czyt. przywożonych z paczkami), co i zwykłych?
ok, punkt dla Ciebie. Czyli /home/services dla użytkowników którzy
wymagają logowania się jak na przykład postgres, mysql. Tyle i.. chyba
tylko tyle. W żadnym wypadku nie widzę powodu dla jakiego miałby się
tutaj znaleźć gopher. 
Ale skoro uważasz że troluję i że nie mam racji to napewno mi go zaraz
wskażesz, prawda? :)

> > > LOL
> > > To *nie* jest rozwiązanie. Gdyby każdy tutaj tak robił, jak
> > > proponujesz, to mielibyśmy dziesiątki jednoosobowych PLD.
> >
> > nad którymi jest CDG
> > ;)
> 
> Nad kloczkiem też? A może nad nami ze strony kloczka?
kloczka nie ma w ramach naszego univers^H^H^H^H^HPLD.

-- 
Andrzej 'The Undefined' Dopierała
UNIX && Linux administrator, Adam Mickiewicz University WMiI
PLD Linux Developer             HomePage: http://aramin.net/
JID: undefine w piastlan.net    e-mail: undefine w pld-linux.org