Opinia o opiniowaniu ;)

[Paweł Kołodziej]

Dnia Mon, Jan 22, 2001 at 02:41:31PM +0100, Michal Moskal napisał(a):
> On Sat, Jan 20, 2001 at 11:02:20PM +0100, Paweł Kołodziej wrote:
> > No włsnie. W PLD nie ma developerow, wiec akceptowaniem kategorii bedzie sie
> > musial zajac ktos "niezaangażowany".
> 
> tzn. maintainerow. ;)

jasne. /s/developerow/maintainerow/

> > > glownie o arch mi chodzilo. ale info mmx/nie mmx tez by sie przydalo.
> > 
> > zauważ że procek z cpuinfo może być inny niż architektura pakietów (np 
> > procek to i586 a pakiety z i386).
> 
> I właśnie na tę okoliczność powinno być cpuinfo (np. jakiś dziwny
> cyrix + arch 586 i nie dziala)

OK. mozna.

> > To ze wszystko bedzie trzymane w jakims sql'u (no chyba że w czymś innym
> > będzie łatwiej) wydawało mi się od początku oczywiste. Interfejsy do różnych
> > baz w PHP są, i to nawet całkiem przyjemne. Zrobienie tego w C będzie
> > jednak bedziej skomplikowane. Poza tym potencjalnie mniej osób zna C niż 
> > PHP w stopniu wystarczającym do pisania wmiarę działąjącego kodu i 
> > póżniejszego rozwijania go. Ale jeśli kochasz C i się tego podejmujesz, to
> > może być C. IMHO ważniejsze będzie dobre obmyślenie struktury bazy.
> 
> Może więcej osób zna php. Ale czy oni wszyscy znający chcą
> to pisać? Bo ja tak ;)

Dobra. Pisz w czym sobie chcesz byle tylko dzialalo, i aby ktos z
powiedzmy rok mogl w rozsadnych czasie wyczaic o co w tym chodzi :))))
(BTW a na baza danych = jakis SQL  (IMHO najlepiej postgers) zgodzisz sie
?)

> > > > > Server robi analizy danych, co jakiś czas, np. co 5 minut. Dostęp
> > > > > do wyników jest przez CGI.
> > > > 
> > > > A może analiza danych powinna być "na żądanie" ?
> > > 
> > > to by moglo zbytnio obciazyc server.
> > > ale moze...
> > 
> > e.... wątpie. Ilu userów będzie ściągało opinie ? 10 na minute ? Myśle że
> > nie więcej (nawet w bardzo optymistycznym wariancie). Pozatym
> > wygenerowane statystyki na kazda mozliwą konfiguracje pakietów u 
> > klienta zajeły by kuuuppppeeee miejaca na dysku.
> >
> 
> tzn. mi chodzilo o oglne statystyki a nie dla konkretnego
> klienta.

OK. takie zbiorcze moga byc terze lepeij generowane po przyjsciu nowego
raportu (wtedy mozna by nie przeliczac wszystkiego od noa, tylko
uwzgledniac poprawki -- wlasciwie to mozna polaczyc i 5minut i
"poprawianie statystyk").

> > > > > Próbuje zgadywać co jest przyczyną błędu. Tzn. pakiet
> > > > > ten i ten wydaje się nie mieć wpływu, a ten po upgrejdzie
> > > > > robi kwas. To łatwo statystycznie znaleźć (tzn. serwer sam to
> > > > > zgadnie, a nie userzy mu powiedzą).
> > > > 
> > > > Jesteś pewny że to łatwo zrobić ? IMVHO dobre zrobienie tego (automatyczne)
> > > > to kupa roboty (wcale nie prostej).
> > > 
> > > bynajmniej. prosta analiza statystyczna ;)
> > 
> > dobra. Zobaczymy co Ci z tego wyjdzie (dalej uważam że zrobienie tego
> > dobrze[1] graniczy z cudem).
> >
> 
> moze... trzeba by to przetestowac.

OK. mozne na razie zadowolimy sie czyms co (po stronie serwera)
1. skompiluje sie
2. bedzie w stanie przyjac raport
3. umozliwi userowi popranie jego "konkretnych" statystyk.

(po stronie uzytkownika)
symetrycznie do serwera :)

> > > moge to napisac w jedna noc, ale w
> > > C a nie jakims php ;)
> > 
> > zgaduje: nie znasz PHP i niechce ci się go uczyć ? mam racje ?
> > 
> 
> kiedys sie uczylem i umialem. ale ten język jest imho kapke
> ograniczony...

Jasne, ze php nie zaspokaja mojego zmyslu piekna, ale mimo wszystko jest
dosc praktyczny. No, ale jesli dzisiejsza noc ci wystarczy, to chętnie
obejże to jutro rano napisane chociażby w asmie ;)

> > [1] - dobrze === tak aby użwyanie tego nie wprowadzało więcej zamieszania
> > niż pożytku.
> > 		
> 
> mam nadzieje ze to sprawa dokładnej regulacji ile
> to jest duzo a ile malo.

Podane definicja nie wymaga określenie pojęć "mało" "dużo" a jedynie
istnienie relacji wiekszości ;)

Tak sobie mysle, ze robienie komunikacji serwer -- klient (ten nasz) po
http jest jednak bez sensu. Mysle ze jakis glupiuti "raw protocol" nam
jednak w zupełnopści wystarczy.
Otawrta pozostaje kwestia formatu przesylanych danych (tekstowy (ktory?)
vs binarny -- mysle ze niestety roztrzygnie przypadek).

-- 
Paweł Kołodziej 
pawelk w pld.org.pl 
,,O ile nam wiadomo, komputer nigdy nie popełnił niewykrytego błędu.''
                                                 -- Weisert