Existuje nějaké konečné řešení tohohle problému, které je bezvýhradní, tzn. funguje nezávsile na tom, kam se swapuje a podobně? Jak to dělají ostatní operační systémy? Existuje OS, u kterého by tohle bylo vyřešeno principiálně korektně?
Jak fungují takové ty linuxovité operační systémy co vyvíjí NSA nebo kdo a tvrdí, jak jsou strašně bezpečné? Může být systém strašně bezpečný, když se nechá nějakou přístupovou patternou vytuhnout?
Zdravim
Pro me ten clanek vysel dost pochmurne, jako by to bylo neco strasnyho. Nerikam ze to je v poradku, ale satci se podivat na to mnozstvi bezicich linuxu. Dokonce ani me se nestalo ze by my system vytuhnul (16MB RAM + 15MB SWAP). (swap jsem pozdeju pridal po te co jsme si vsiml ze jsem se v fdisku prepsal). Na tyhle sibenicni kombinaci jsem i kompiloval jadro a vydrzelo to.
Docela by me zajimalo jak maji tohle vyresene ostatni OS, nejen ty unixove. O Win9x se bavit nebudeme, ty mrznou i kdyz maji pameti dost, ale porovnani s NT+ by mohlo byt zajimave, treba vyjde najevo ze v linuxu je to mnohem lepe udelane :-)
Zdenek
Když budete většinu té paměti používat jako cache, tak se ničeho obávat nemusíte. Pokud pustíte tolik procesů, že ji celou sežerou a ještě swapují, tak deadlock hrozí. Jinak na desktopu je to jedno, když desktop jednou za půl roku spadne, tak se nic nestane. Ale na kritický server bych to nedával.
NT a OS/2 jsou úplně odlišné. Jinak OS/2 swapuje tak, že má jeden swap soubor na některém filesystému. Při swapování (snad --- zdrojáky nemám) žádnou paměť nepotřebuje, ale deadlock se tam vyskytnout může při růstu souboru.
Swap soubor je vždy udržován tak, aby v něm bylo aspoň 1M volného místa. Pokud v něm je míň, systém ho okamžitě začne zvětšovat. Pokud se během zvětšování souboru vyplácá i ten 1M, systém udělá něco jako kernel panic. (nestalo se mi to nikdy, ale teoreticky to asi možné je). Na kernel panic také spadne, pokud se ten filesytém se swap souborem zaplní a swap není možno zvětšit.
OS/2 je také možno přepnout do takového režimu, že všechny alokace paměti mají předalokované místo ve swapu --- pak to žere spoustu swapu, ale vytuhnutí nehrozí.
Pardon, ze mluvim upolne mimo clanek. ALE NENI mi JASNY, proc se vsichni cpou do Linuxu, jako treba IBM a dalsi, kdyz je tu FreeBSD, NetBSD, OpenBSD a kdo neni OPUT, tak vi, co to je za systemy a kde se nachazi Linux :-\ Tohle asi nejak nepochopim. Zlaty FreeBSD.... Kdo zna treba LGPL, etc,... Predpokladam, ze k tomu maji ony velke firmy a jini jedinci "duvody", proc pouzivaji Linux, ja jsem jej pouzival na desktopu docela dlouho, ale po tom, co jsem jednou nainstalil FreeBSD, tak mi pripada, ze jsem byl pekne mimo, kdyz jsem se v Linuxu "hrabal" na desktopu, nemluvim ani o routerech a serverech,....
Pardon, doktl-li jsem se nekoho,... jen nejak nechapu, proc nejde IBM do FreeBSD? Asi jsem mimo misu. Fakt pardon. Pokud by se zde ale nasla nejaka uprimna dobra duse, ktera mi to treba na dvou radcich vysvetli, pak ji budu moc vdecny. S pozdravem a pranim pekneho dne Dan :-)
Aneb KDE na FreeBSD.
http://www.starhill.org/nevazne/1.png
http://www.starhill.org/nevazne/2.png
http://www.starhill.org/nevazne/3.png
Opravdu se omlouvam, muj prispevek sem do diskuze nepatri, prominte mi to prosim.
Samozrejme nevim co vede IBM k investicim do Linuxu, nicmene odhaduji, ze je to prave GPL - tedy to, ze kdyz oni neco vylepsi a zverejni, tak na tom nikdo nemuze stavet svoje uzavrene proprietarni reseni (na rozdil treba od situace Apple-FreeBSD, kde do zdrojaku FreeBSD jsou propagovany bugfixy, ale uz ne prilis nejaka vylepseni nebo nove veci).
No flames, please - jde jen o muj osobni nazor.
-Yenya
K FreeBSD mne vedla jeho rychlost, robustnost na siti (vetsina site v Linuxu jest stejne z FreeBSD, OpenBSD, NetBSD, si to prectete v konfigurakach). Pak tez PORADEK ve FreeBSD, zatimco v Linuxu, je ehm, slusne receno "neporadek".
Pak tez,...
pkg_add -r xmms
nebo treba:
pkg_add -r kde
pkg_add -r licq
(samo stahne, nainstali, vyresi zavislosti,.....) Pokud se Vam nelibi, muzete tez kompilovat, no problem.
Tedy system portu a baliku, neco o tom poctete a az budete SILET z ruznych "zavislosti" na verzcih ruznych knihoven a podobne v Linuxu, pak sahnete po FreeBSD, kde je to nadherne vyreseno.
Kompilace jadra,.... NADHERA.....
Veci by se naslo vicero.
Vsak na netu je kolem teto problematiky hodne,... Samozrejme mate moznost volby, ja Linux taktez podporuji, ale utekl jsem od nej.... Vse se doctete, kdyz budete chtit, ja Vam nic nevnucuji, to jsou me sobni duvody "migrace" z Linuxu na BSD :) Abych Vas nejak neurazil, to jsem fakt nechtel,.... a nechci.
Post Scriptum: Mne hraje SB Live! uplne v poklidu.
Pekny den Vam preji.
Dan.
- Debian ma take stahovani balicku ;-)
- Jestlize jsou v Linuxu sitovitosti prevzate z *BSD, tak proc kvuli nim prechazet na *BSD, kdyz uz je mam tak jako tak stejne ;-)
- RPM zavislosti jsou prima, kdyz vim, ze pokud to naistaluju, tak tomu nebude nic chybet. A kdyz se mi to nelibi tak --nodeps a nic se netestuje
- atd, atd ...
Ale na zaver to NEJDULEZITEJSI:
Proc bych prechazel, kdyz mi vsechno funguje jak ma a uptime mi konci pouze pokud nekdo vyrazi pojistky?
Jednou jsem s FreeBSD trochu pokusnicil.
System portu: je fakt krasa. Ted jedu na Gentoo a zavislosti to resi taky samo. V RH jsem se na tom obcas opravdu pekne vyradil ;-)
Poradek v systemu: Jo, to opravdu je. V Gentoo ho mam taky, je fakt, ze muj minuly RH to postradal...
Kompilace jadra je fakt pohoda, ta se mi velmi libila.
Dost dobra mi prisla i kvalitni a ucelena dokumentace (Handbook). Ackoliv Gentoo ma dokumentaci taky na slusny urovni. U RH si popravde nepamatuju, nakonec jsem vzdy pomoc nekde nasel...
Naopak, proc jsem nezacal FreeBSD pouzivat poradne byl zpusob NATovani. Zkousel jsem tenkrat tusim 5.0 rc neco a NATovani se tam nedelo primo v jadre, ale nejakou userspace ptakovinou. Problem byl v jeji dost nizke konfigurovatelnosti (aspon oproti iptables z linuchu) a na ty psi kusy, co jsem s tim potreboval provadet se to nastavovalo fakt dost blbe a vykonost se mi zdala nizsi nez u iptables z linuxovyho jadra. Takze to byl duvod u me...
S Gentoo linuxem jsem spokojen a momentalne nevidim duvod proc prechazet... Ale nic nemusi byt navzdy, presel jsem z redhatu, proc bych nekdy nemohl prejit z linuxu ze? Ale dnes to nebude...
Zdar vsem unixarum, linuxarum, BSDckarum, plan devitkarum, OS dvojkarum, jablickarum i tem oknarum! A taky vsem ostatnim :-)
Bereme-li tento článek jako závěr celého vydařeného seriálu, je, myslim diskuse na toto téma adekvátní. Nejsem systémový prog., ale praktické zkušenosti potvrzují to, co lze v seriálu najít. Linux má oproti BSD na úrovni systému jednu velkou nespornou přednost, podporu SMP (ta je u FreeBSD stále mizerná). Nemá v tom IBM náhodou prsty ? Dále pak má podstatně větší paletu driverů (dnes funguje na Linuxu téměř vše).
Na jednoprocesorovém stroji s hardwarem kompatibilním s BSD je však vítěz jasný, FreeBSD. A to jak pro server, tak i pro desktop. Práce na FreeBSD desktopu je nesrovnatelně pružnější a přijemnější. Lépe vyřešená obsluha přerušení, lepší nakládaní s pamětí jsou velmi znát.
Problém je v tom, že takové diskuse na obecné úrovni se často hemží trolly. Série článků tomu úspěšně odolávala porovnáváním velmi konkrétních záležitostí v obou systémech a zřídkavým tvrzením, že jedno řešení je "lepší" než druhé. Myslím si, že otázka výběru mezi oběma systémy je častěji filozofická a sociální než pragmatická na základě nějakých parametrů.
Takovyhle reci jsem uz slysel a cetl opravdu hodne, ale zatim jsem nikde nevidel realny dukaz. Mel jsem tu moznost videt a sahnout si jak na BSD, tak na Linux a nenasel jsem vyznamnejsi rizdily, co se tyka architektury, ani spravy (jen ze v BSD je napriklad pouzitelnych nekolik etc, takze hledat konkretni konfigurak vezme chvili casu, ale v nekterem z nich to urcite je). Ale rychlost prace je na obou systemech velmi podobna. A pokud si myslite, ze neni tak bych rad videl dukaz. Tvrzeni ze to tak je, protoze je to pravda neberu.
Jde jen o moje praktické zkušenosti.
Opírám se jen o instalace na stejném HW, pravda v případě desktopu není úplně nejnovější, desktop (Athlon 1G, 128 Mb RAM, 20 Gb disk, PCI Realtek, vse ostatní integrovano na desce). Měl jsem zde pár Linuxů (Debian, Xandros), a FreeBSD 4.7 nyní upgradované na 4.9. Běží řekněme nějaké kde, konsole, mysql, apache, eclipse, firebird, sem tam OO. Rozdíl mezi Linuxem a FreeBSD je markantní. Velkou nevýhodou FreeBSD byla absence nativní podpory javy, to se však cca před rokem změnilo.
Server - FreeBSD od využití starého HW (lze pořád instalovat snadno na 8Mb, na P75, 16Mb, ISA net lze s uspěchem provozovat i malé databáse - mysql, apache pro několik uživatelů, atd. blabla),
po jednoprocesorové IBM xServery (ne všechny jsou kompatibilní s FreeBSD), kde Linux běží většinou slušně, FreeBSD ještě lépe.
Nyní se většinou snažím nejdříve instalovat FreeBSD, když to nejde (a u novějšího HW to zas tak řídká událost není) tak Linux. Kromě většího výkonu a většího 'pořádku', je i množství nutných patchů během delší doby o něco nižší než u Linuxu.
Linux vůbec není špatný, má výhodu ve svém rozšíření , podpory i nového HW, množství povedených jednoúčelových distribucí, atd., a používám jej také. Kde lze ale použít FreeBSD, tak mu dám přednost. Odmyslíte-li si obálky distribucí ala Xandros, které se snaží vše udělat za vás, tak mi (z uživatelského pohledu) filozofie obou systému moc rozdílná nepřipadá.
Většina zde zmíněných věcí ale nemá s tímto seriálem nic společného a za to se omlouvám. Původní přispěvek chtěl jen potvrdit z praktického hlediska to, co jsme se v tomto seriálu dozvěděli. Dotknul-li jsem se tím zarytých Linuxářů, doporučuji jim přečíst si seriál ještě jednou.
Samozrejme, ze mne jste se nedotknul, jen se mi nelibi kdyz ctu spoustu nazoru, ze lepsi je "dosadte vlastni OS" a ostatni jsou pomale, nevyhovujici, atd. bez dalsi ch veci. Muzu rict, ze BSD nam krasne jelo jako router na stare 386 a Linux jako webserver s malou databazi na i486 s 16MiB RAM (dokonce XFS, jako FS) a oba pripady bez problemu, takze volba systemu prameni spos z blizke znamosti, nez rychlosti.
S tymi drivermi, ci uz na linuxe alebo BSD je to tak, ze nech si kupite cokolvek, 80% to pobezi len pod windows...
Add rychlost:
"Rozdíl mezi Linuxem a FreeBSD je markantní."
Nemohli by ste byt konkretnejsi (predtym ako sa pustim do tahania neviemkolkych CD po pomalej linke ;-)
Preco sa pouziva linux? Lebo niekto(kedysi) povedal, ze linux je super a uz to bolo. Vtedy som o nejakom freeBSD ani nepocul. Na freeBSD sa mi tiez nepaci, ze hrozne dlho trva, kym releasnu nove verzie. Ale hlavne ta HW podpora.
Co se tyce te HW podpory (ze reaguju s takovym zpozdenim) - to do znacne miry souvisi se zpusobem "vyroby" kodu. Nejsem si jist aktualnimi pravidly, ale pred par lety platilo, ze na to, aby mohl byt ovladac zahrnut do distribuce FreeBSD, musel ho napsat bud' vyrobce hardwaru, nebo alespon nekdo (jiny) kdo mel oficialni specifikace vyrobce. Pouzivani ruznych "pseudo implementaci" vzniklych reverznim inzenyrstvim Windowsovskych ovladacu ci neceho takoveho bylo zcela vylouceno. Nejsem si jisty, ze se to vzdy dodrzovalo a dodrzuje dokonale, ale kazdopadne to siri podporovaneho hardware ani rychlosti rozsirovani toho seznamu neprospiva. Na druhou stranu to spise prospiva spolehlivost systemu. Otazka je, jak hodne to vadi. V podstate jde o to, kolik lidi vybira v poradi "problem" -> "vhodny OS" -> "hardware na kterem to dobre pobezi" - coz je (IMHO) preferovana filosofie FreeBSD teamu - a kolik lidi k danemu hardware napasovava OS - ktery tak tedy musi bezet na "cemkoliv".
Rozsireni Linuxu a jeho podpora ze strany velkych korporaci nebyla nikdy dana jeho kvalitami. Realne vzato je (i po tech investicich ze strany firem jako IBM, Oracle apod.) jednoznance nejhorsi unix like system ze vsech, ktere jsou alespon trochu rozsireny. Proto napriklad velke frflani v IBM ze strany AIX specialistu, ze maji z duvodu firemni politiky prosazovat neco co je o nekolik kvalitativnich trid pod urovni stavajiciho AIXu.
Jedinym duvodem byla nutnost konsolidace sektoru. Stavajici situace nekolika jen omezene kompatibilnich proprietarnich unixu uz byla neunosna. Bylo treba se sejit nekde uprostred a tim prostredkem se stal Linux. Sice nestoji (nestal) za moc, ale proste se tam postupne nacpe upraveny kod z proprietarnich unixu a za par let bude umet to same, trh bude na jednom unix like systemu a v konecnem dusledku na tom vsichni vydelaji (s vyjimkou Microsoftu).
Duvod proc byl jako stred kde se vsichni sejdou zvolen Linux a ne *BSD bude skutecne treba hledat v te licenci.
vyznieva to dost zufalo, takze by bolo vhodne sa zmienit, ze je niekolko projektov co pouzivaju swap cez NFS (napr LTP) a krasne funguju, tiez kazdy pouziva loopback na zapis (ako by sa inak robili obrazy diskiet?). no a do imidzu cd umiestneneho na imidzi dvd (na NFSku) sa zapisovat neda :)
poucenie: neswapujte do suboru na loopback device na NFS
Low-memory deadlock v Linuxu nenastava ani pri swapovani do souboru, teda aspon pokud konkretni filesystem podporuje bmap(). Jadro si totiz v okamziku swapon(2) zjisti, kde dane bloky jsou, a pak uz je nemusi dohledavat - takto je swapovaci soubor v podstate jen trochu fragmentovana swapovaci partition. Urcite to plati pro ext[23], temer urcite ne pro NFS. Podobna situace je asi i u jadra 2.6 a veci ktere vyuzivaji device mapper (LVM, RAID-0 a 1) - tam by se swapovani na LV nebo RAID-[01] volume melo obejit bez low-memory deadlocku.
-Yenya
co nam (vam:-) brani alokovat nejaku pamat, ktora sa bude pouzivat iba a only na proces zapis dirty stranok na disk? ono to uz bolo v podobnej suvislosti spominane aj v clanku, ale mozno som to len blbje (ne)poxopil ;)... proste vyhradime povedzme 1 MB, ktory sa nebude na nic ine pouzivat.. pri dnesnych pamatiach je to smiesne mnozstvo a neviem si predstavit, pri akej prilezitosti by to na tuto ulohu nemohlo stacit. Akoze riesenie je to prasacke, ale podla mna riesi vsetko. alebo do toho vobec nevidim a placam kraviny ;-)
Takže správně bych měl při psaní každého LKM počítat maximální hloubku stacku? Hmm, to jsem naposled dělal u jednočipů. Čekal bych, že žádný SKUTEČNÝ OS to nemůže požadovat.
Hlášky jako "X pages enough for anybody" už jeden kdysi trousil, a všichni vědí, jak to dopadlo.
Mozna kecam, ale tusim,ze je to tak, ze na stack mate 8MB, pak je jedna stranka volna(zamknuta) a pak nasleduje stack dalsiho vlakna. Teoreticky se muze stat, ze kdyz se zanorite dost hluboko, tak ze prepise stack jinemu vlaknu. Tenhle limit se urcite da nekde zmenit.
Nova podpora vlakenen umoznuje mit lokalni instance promennych pro kazde vlakno(definuji se jako __thread). Pro ty se pouziva gs segmenovy registr.
To je mozna duvod proc mi pada na 2.6 aplkace bezici
pod JRE 1.1.8.
Ivan
Rika se, ze 4kB zasobniku je na proces a 4kB na interrupty. Pokud nebudete deklarovat pole jako automaticke promenne a nebudete pouzivat alloca a nebudete mit rekurzivni funkce, tak na ten limit asi nenarazite.
V kernelu neni virtualni pamet, takze tam nejde alokovat stranky zasobniku podle potreby.
Tenhle seriál je zaměřen pouze na jádra systémů, problematikou userspacových programů se nezabývá. Ani ji nepovažuji za důležitou, neboť na oba systémy jdou nainstalovat stejné programy. Gnome nebo KDE si můžete nainstalovat jak na Linux tak na FreeBSD a "prostý uživatel" pak nepozná žádný rozdíl.
Nedávno tady byl článek od Michala Káry, jak se instaluje FreeBSD 5.
Srovnání licencí --- to nemá žádnou informační hodnotu, to je pouze flamebait.