FreeBSD kernel panic: vm_thread_new: kstack allocation failed

[Jozef Babjak]

> > 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.