SPECS: tmpwatch.spec - rel 9 - expanded pl description - default c...

[Radoslaw Zielinski]

Paweł Gołaszewski <blues at pld-linux.org> [01-11-2004 20:39]:
> On Mon, 1 Nov 2004, Radoslaw Zielinski wrote:
[...]
>>> A niby dlaczego? "Bo poczta nie może ginąć"?? Przecież to bzdura, na
>>> tej
>> Właśnie dlatego i nie widzę w tym nic bzdurnego.
>>> zasadzie nie możnaby było usuwać logów, nie możnaby było usuwać plików
>>> tymczasowych...
>> Poczta, logi i pliki tymczasowe to trzy zupełnie różne rzeczy.
> Pliki tymczasowe - zgoda.
> Nie mówimy tu o poczcie, ale o *kwarantannie*

O kwarantannie *poczty*, czyli o *poczcie*.

> Czyli czymś co jeżeli było odrzucone powinno być:
> - przejrzane
> - zarchiwizowane, jeżeli trzeba
> - wywalone jeżeli śmieć
> - zarchiwizowane jak leci
> - jeżeli nikt się tym nie zainteresował - do śmieci po odpowiednio długim
>   czasie [1]

> Jaką widzisz tu różnicę w porównaniu z logami? Ja nie widzę żadnej.

Sposób powstawania.

Z logami zawsze, prędzej czy później, trzeba coś zrobić -- można nimi
zapchać każdy nośnik oprócz /dev/null.  Jeśli wiesz, że możesz kiedyś
potrzebować logów, to na pewno skonfigurujesz sobie ich archiwizację
(ja np. nigdzie nie mam potrzeby trzymania ich *zawsze*).

Poczta ma inną specyfikę.

Jeśli chodzi o wirusy, to nie ma problemu: możesz im ustawić domyślne
kasowanie natychmiast -- jak ktoś chce, to sobie odblokuje.  Tylko
wymyśl (i zaimplementuj) wcześniej metodę z gwarancją 0% false positives.

> [1] - pozostaje zdefiniować ile wynosi ten czas. Znaczenie słowa
> "kwarantanna" mówi o 40 dniach... Ja proponowałem od początku 60 dni,
> co chyba jest w pełni wystarczające.

Koniecznie potrzebujesz terminu przeliczalnego na jednostki SI?
IMHO dwa lata to akceptowalny kompromis.

-- 
Radosław Zieliński <radek at karnet.pl>
[ GPG key: http://radek.karnet.pl/ ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-pl/attachments/20041101/973f8c0c/attachment.sig>