> > nooooo.. zrovna tohle mne na fbsd dost se*e.. ty ruzne limity a vubec > > vetsina > > hardcoded hodnot ma velikosti nekdy z 80tych let a je to cele naprd... > > Takze nejake limity nakonec stejne potrebujes a muzes jen spekulovat > nad zpusobem, jak je zadavat, jestli maji byt staticke, nebo se pokusit > o nejakou umelou (a tedy jiste v nekterych situacich omylnou) umelou > inteligenci ...
^-- Je ale rozdiel mat konzervativne limity, ked hned aj nastavene historicky, a mat nepouzitelne limity. Co sa tyka limitov pre IPC, ma FreeBSD nepouzitelne limity. Co sa tyka "umelej inteligencie", nemozno ju odmientat bezdovodne. Ano, da sa menovat viac pripadov kde takato "ui" bola viac na skodu ako na osoh, ale dnes sa v mnohych oblastiach javi ako odovodnena, uzitocna a uspesna; par prikladov: 1) Kompilatory pouzivaju geneticke algoritmy na optimalizaciu. 2) Dynamicke kompilatory ako napr. Java HotSpot technologia davno prekonali optimalizacie mozne pri pouziti statickych kompilatorov. 3) Zjednodusila sa sprava programov, veci, ktore sa museli pracne ladit, sa dnes ladia same. Dva velmi uspesne priklady za vsetky: EnterpriseDB a Oracle 10g. 4) Rozsiahla studia vykonnosti ZFS ukazala, ze v oblastiach, kde ma ZFS autotuning, prakticky nie je mozne najst lepsie nastavenia, ako nastavi zmieneny autotuning. V zasade "ui" implementovanu rozumnymi pravidlami nad rozumnymi metrikami povazujem za daleko spolahlivejsiu, ako inteligenciu prirodzenu, teda aspon pokial sa bavime o regulacii dobre popisanych procesov (co vsetky vyssie uvedene su). Samozrejme, takato "ui" nenajde exelentne nestandardne riesenie, ktore najde clovek; to ale v tomto pripade nikto po nej nechce. J. -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
