Vlákno názorů k článku
Jak jsem instaloval a testoval FreeBSD 5.2 (2)

Jo, je to zajimave, ale test minuta/minuta je na houby. Rozdil mezi FBSD a Linuxem na pracovni stanici porovnavam tak, ze to necham jet s Xkama dokud to jde pouzivat a v tom je (asi) BSD lepsi. Linux po mesici az dvou zpomali protoze sezere skoro vsechnu pamet (vice dister, jadra od 2.2 do 2.6-test1) a nema cim cachovat, FreeBSD se na te same stanici do podobneho stavu jeste nedostalo, protoze zatim vzdy stihly drive vylitnout pojistky, kazdopadne spickovy uptime mam s 5.0 (! hodne unstable, ale nevim jak se to pozna, nic mi tam nespadlo) skoro pulrok.
Takze krom doplneni serverove zajimavejsiho OpenBSD, produkcniho FBSD 4.9, a pro zajimavost by stalo za to dat si Plan9 (prekvapil by asi skoro vsechny), bych jeste s tim vsim udelal test dlouhodoby, treba mesic trvaleho vytizeni. Vic nema asi smysl, protoze je treba kvuli bezpecnosti obcas vymenit jadro a navic nemam poneti, kdo by byl ochoten obetovat na mesic 4 nebo 5 slusnych pocitacu :(

Provozoval jsem dlouhou dobu nekolik (cca 30) zatizenych pocitacu ale uvedene problemy jsem nikdy nepozoroval. A to i pres uptime nekolik mesicu. Nevyzirala tu pamet spis nejaka aplikace s memory leakem?

Myslim, ze to tak presne je. Mam k tomu jednu zkusenost. Jeste loni jsem mel na jednom pocitaci stareho RedHata 7.3 s KDE a jednou za cas jsem se musel odhlasit a prihlasit, protoze cele GUI bylo desne pomale. Jadro si ale chrochtalo i pri uptime 150 dni.

- nikdy som nic poriadne netestoval, nepriek tomu ked pouzijem sedliacky rozum musia mi byt jasne urcite veci.

- problem s castym alokovanim rozne velkych blokov je znamy a je to skor chyba X-ov ako OS. Ked ale proces skonci a spusti sa znova tak pamet je zas volna. Teda server s tym problem nema lebo 1. nealokuje jak divy, 2. nie je nutne pouzivat donekonecna ten isty proces.

- o OpenBSD je zname ze vykonovo je daleko pozadu.

No já mám appserver na kterém naráz pracuje 7 lidí (mají na tom komplet desktop environment Icewm+ROX) v paměťových žroutech GIMP, OpenOffice.org a Mozilla a spol. Honím to na poněkud obsolet 2.4.22-xfs přímo z Knoppixu (já vím, že jsem čuňátko a není to bezpečné). Všechno to jede pochopitelně nonstop (97 days, to byl výpadek elektriky delší než UPS snesla). Žádný memmory leak jsem nezaznamenal, tak se mrkněte co za sprasenou app (nebo X server? - ty jsou pochopitelně na terminálech {X86Free sux}) vám tu paměť vyžere a přestaňte FUDovat.

Mam Debiana stable verzi, tedy jadro 2.4.18, uptime je 130 dnu a zadne zpomaleni diky cachovani se nedeje. Pouzivam ho jako desktop, takze dlouhodoby proces mam akorat mprime, ktery bezi momentalne 72134 min. Takze si myslim, ze je to chyba apliakce, ne jadra.

testovaci SLES8 (PIII 1Ghz, 640MB RAM) s Oracle9i + Oracle9iAS po 80ti dnech uptime vyuziva asi 250MB swapu (pripojuje se nekolik desitek useru). nemyslim si, ze by se vzrustajicim casem nejak radikalne chlemstal pamet nebo mel velkou zatez (a to je aplikacni server + java slusnej zrout..)

no neviem, redhat 7.3 na starom pentiu, kernel 2.4.18-3, uptime 454 dni... bezi na tom kopa javy a je to stale uplne v pohode... :-D