Vlákno názorů k článku
PC-BSD: jednoduchý desktop je prima

No to je uzasne, tak SuSe ktere zabira cca 10MB RAM je podle autora nanic a nejake BSD, ktere zabira stejne je super ????
Na 128MB autor pouziva KDE na obou systemech .... coz je hovadina a s OS to nema co do cineni, oba budou kurna pomale a OO na tom bude nepouzitelny (blba ze mne nikdo delat nebude, UNIXu jsem videl dost !!!!)

Jo dat tam IceWM tak to je jina, ale pak to bude bezet rychle jak na Linuxu a jedno jakem, tak na BSD dokonce i na OpenSolarisu !!!!!

Akorat ze na Linuxu bude bezet i DVB TV budou tam behat i zvukovky jako M-Audio (pres alsa), tablety etc.

Jakmile zacnete swapovat, tak poznate vyhody FreeBSD.

Jina vec je, ze na zaklade teto jedne vlastnosti nikdo prechazet nebude :-)

To se mi nezda, nevim jak do souboru, ale do swap part. rozdil zase tak dramaticky nebude.
rozhodne ne na kernelu 2.6.x

Kdyz jsem mel 32MB ram tak jsem swapoval dost a dokud jsem nevycerpal celou pamet tak jsem o nicem moc nevedel, ale kdyz dosla celkova pamet i se swapakem, tak zacal disk klepat hlavickama jak blbi .... ale to nevidim jako chybu.

Je teda pravda, ze jsem BSD nikdy nenasadil na nic velkeho skousel jsem FreeBSD a NetBSD.

> Jakmile zacnete swapovat, tak poznate vyhody FreeBSD.

Můžete být konkrétnější? (prosím technické vysvětlení nebo benchmark, ne dojmy)

Bohuzel nemohu. Na zaklade indikaci z konferenci jsme si nechali od jedne zahranicni firmy zpracovat analyzu. Jednak k jejimu publikovani nemam svoleni (myslim, ze nikdo od nas) a za dalsi nebyla zrovna nejlevnejsi.

Zkousel jsem PC-BSD , pekne, funkcni, mel jsem to na stroji s 256 MB RAM + 512 MB swap, je zajimave, ze pri rozbalovani 800 MB archivu (tar.bz) pomoci Ark se jaxi zhroutilo s tim , ze dosla pamet, na stejne konfiguraci s Linuxem (tusim ze jsem tam cpal Suse) vsechno fungovalo pomaleji, ale pri testovani s tim samym archivem a tim samym programem nebyl zadny problem .

Tim nechci nic hanet, nebo chvalit ,je to jen muj postreh...

Je to sice uz mimo ramec tematu, ale ...
... pokud ma uzivatel nastavne limity zdroju a proces(y) je vycerpaji, tak je to standardni chovani v Unixu obecne. Navic rada programatoru ani nevi, jak se chovaji limity systemovych zdroju a zapominaji odchytavat prislusne signaly pri soft limitech (schvalne, kdo ze zdejsich prgacu na to mysli?). V Debianu jsou defaultne limity neomezene. Ve FreeBSD je datasize omezeny na 512MB.

Druha vec je, proc Ark spotrebovava pamet? Pokud je aplikace spravne napsana, tak nemuze pri rozbalovani tar.gz dojit k vyrazne spotrebe pameti (jeste tak mozna pri sestavovani seznamu souboru, ale pri rozbalovani ne)

Suma sumarum je problem jinde nez v OS. (Cimz nechci rict, ze nejsou ve FreeBSD problemy.)

Problem samozrejme JE V OS.

Pokud BSD spadne, kdyz procesy sezerou veskerou pamet, je to HODNE SPATNE.

Rozumne systemy aka Linux, Solaris, Windows pri sezrani RAM nasadi OOM killer (muze se jmenovat ruzne) system NESMI spadnout.

Nevim jak je to v Linuxu ted, ale stary OOM killer ve 2.4.x v pripade potizi zkratka sejmul proces, ktery alokoval nejvic RAM.

Omyl, beru zpet, spatne jsem pochopil puvodni prispevek.

Ja na to myslim. Kolikrat jsem se uz zamyslel a dospel k zaveru, ze odchytavat u tehle utilitky signaly je zbytecne, protoze stejne nic chytrejsiho nez spadnout udelat nemuze ... velke programy jsou jina zalezitost, ale zrovna dekompresni program ? Co by mel v reakci na vycerpani limitu delat ? Zobrazit chybovou hlasku a skoncit ? :-)

Jinak, mozna ten Ark rozbaluje ten soubor do pameti. MC to obcas dela.

To, ze na to myslite, vas jenom cti. Bohuzel jste spis vyjimka. Pokud proces dostane signal o vycerpani soft limitu zdroju, tak by je mel prestat spotrebovavat. Tj. ukoncit napr. rozbalovani a ohlasit duvod preruseni akce. Podobne, jako se deje pri nedostatku mista na HDD atd.

(Pro ostatni na vysvetlenou: pri dosazeni soft limitu se procesu posila prislusny signal, na ktery ma proces cas bezpecne zareagovat; pri dosazeni hard limitu OS proces bez milosti ustreli).

To, ze spadne proces, je pro uzivatele problem viz. prispevek, na ktery jsem reagoval. Tim se ztrati stavova informace aplikace (musite napr. opet nastavit pracovni adresar, otevrit posledni soubor atd.). Kolikrat to pak uzivatel musi neuspesne zopakovat, aby mu doslo, proc se tak deje.

At uz Ark rozbaluje takto velke archivy do pameti nebo je tam nejaka buga, neni to pro Ark prilis prizniva vlastnost.

Premyslel jsem, jak to myslite s tim pracovnim adresarem a po chvili mi to doslo: ano, typickou tridou programu ktere by MELI tyto signaly chytat jsou programy pro Xka, protoze dokonce i v pripade ze nemuzou udelat nic lepsiho nez zobrazit okno s hlaskou "bylo dosazeno soft limitu, aplikace bude ukoncena, [OK]" (jakoze vetsinou MUZOU udelat vic), je to o poznani lepsi nez nic. Kolikrat jsem pustil aplikaci trikrat a teprve pak otravene jeste jednou z xtermu jen abych konecne videl jake pise chybove hlasky. Commandline aplikace ma vyhodu, ze cast chybovych hlaseni za ni ohlasi bash (ktery hlasi signal kterym byl prerusen posledni proces).

Jinak, na vysvetlenou, hlavnim rozdilem mezi soft a hard limitem je ze soft limit muze aplikace (i neprivilegovana) zvysit, hard limit ne. Se signaly je to slozitejsi: je pravda, ze pri prekroceni limitu na cas procesoru se posle signal, a to SIGXCPU na soft a SIGKILL na hard, ale treba vycerpani pameti se bez ohledu na druh limitu (soft, hard, hardware) hlasi jako chyba ENOMEM na navratu z funkce, krome pripadu kdy dojde pri rozsirovani stacku, v tom pripade se bez ohledu na druh hlasi signalem SIGSEGV. Naopak signal SIGPIPE neni spojen s zadnym porusenim limitu, ale jinak se jedna o stejny pripad.

Mimochodem, co to vlastne je ten Ark ? Vi to nekdo ?

Já to vím, co mi dáš, když Ti napovím? ;-) Všimni si posledního písmenka a dej to do Google.

aha.