Steve Ballmer: Linux je větší hrozba než Apple

Overcommitting lze samozřejmě vypnout. Jestli ti vadí OOM killer, tak tím se ho zbavíš (resp. pořád tam bude, ale nikdy se neaktivuje). Druhá možnost je aktivovat swapd a nechat dynamicky zvětšovat swap.

Důvodem overcommittingu není ani tak fork a COW, ale to, že linuxové knihovny (hlavně libc) kvůli rychlosti alokují paměť po velkých kusech. Pokud se ti ani to nelíbí, není problém to přenastavit v libc.

Dalším zábavným side effectem je to, že autoři apikací neošetřují nedostatek paměti, protože vědí, že to stejně skončí OOM Killerem, a ne selháním alokace.

To je fakt nebo mýtus? Pokud se vypne overcommitting, tak samozřejmě může selhat i alokace.

Bohužel pak celem záhy dojde paměť, protože Linux je mimořádně žravý.

Což je právě vlastnost glibc, kterou lze při kompilaci změnit.

Po jak velkých kusech glibc alokuje paměť, že to vede k nutnosti overcomittingu?

Většinou po velkých mocninách dvojky a naalokovanou paměť potom půlí (a čtvrtí a osminuje atd.) při přidělování mallocem. Ano, je to obrovské plýtvání, ale je to velmi rychlé, minimálně to fragmentuje a ve spojení s overcommittingem to celkem dobře funguje.

Overcommitting prakticky nikdo nevypíná, protože by mu rychle došla paměť.

Na routerech se vypíná běžně, právě aby nemohl zasáhnout OOM killer a router rozbít. S docházením paměti tam většinou nejsou problémy a to routery mívají velmi málo paměti.

Používání forku bohužel nezměníte nastavením při kompilaci. To, že použití forku vede k velké spotřebě paměti, je platný argument.

I tomu by šlo zabránit, stačilo by fork + exec dvojku upravit na clone(CLONE_VM) + exec (stačí přidat ptrace na spuštění a máte windowsí CreateProcess).

Velké mocniny dvojky jsou pěkný výraz. Můžeme to zkusit znovu. Po jak velkých kusech glibc alokuje paměť, že to vede k nutnosti overcomittingu?

To nelze říct přesně, ten algoritmus výpočtu změny velikosti při volání sbrk je poměrně složitý a záleží na velikosti požadované paměti, paměti již alokované a i nějakých statistikách. Občas nabere zbytečně moc paměti, třeba i více než dvojnásobek toho, co se reálně využije.

Routery jsou příklad na nic. Sám dobře víte, že počet procesů, které na routeru běží, se prakticky nemění. Nesnese to srovnání s běžným desktopem, na kterém běží obrovská spousta aplikací, a paměťové nároky se každou chvíli mění.

No a u desktopu zase není nejmenší důvod nemít zapnutý overcommitting (víte, kolik by sežraly jen KDE kvůli COW v knihovnách? A víte, že ve Windows to taky žere?), tedy i buď swapd (což je obdoba windowsího automaticky se rozšiřujícího swapu ve FS, což ale bez rozumného horního limitu znamená nebezpečí uswapování stroje) nebo OOM killer.

Jinými slovy vykydání chléva linuxového memory managementu se nechystá. Linux bude dál aplikacím slibovat paměť, kterou nemá, a když pak dojde na lámání chleba, tak bude sofistikovaně odstřelovat procesy. K tomu budou aplikace pro jistotu ještě lhát o tom, kolik chtějí paměti, protože přece mají overcomitting. To je fakt humus. Nechápu, jak někdo může používat takový hnus, a jakkoliv kritizovat memory managemet Windows, který je zjevně výrazně lepší.

Hmm, takže Windows aplikacím řeknou, když není paměť, a aplikace buď spadne, skončí nebo to zkusí znovu. První a druhá možnost je obdobná OOM killeru s tím rozdílem, že spadne/skončí něco, co zrovna potřebuji (co jiného by zrovna v tu chvíli alokovalo paměť, že), zatímco OOM killer zabije něco, co velmi pravděpodobně nepotřebuji (protože ta aplikace už dlouho nic nedělala, má vysoký nice ap. - ta kritéria jsou dost sofistikovaná). Při té třetí, nejlepší možnosti (z hlediska kvality programu) naproti tomu ani nespustím Správce procesů, abych mohl nějakou nepotřebnou aplikaci zabít, případně se ani nepřihlásím, protože na to nebude paměť a běžící kvalitně napsané aplikace neskončí, ale budou čekat, až nějaká paměť bude. Děkuji, raději ten OOM killer.

S tím výkonem a fragmentací mi to pořád není jasná. Pokud aplikace chce 4kB paměti, a glibc požádá řekněme o 1MB, tak stejně paměť v tu chvíli nedostane. V nejlepším případě paměť dostane ve chvíli, kdy aplikace poprvé přistoupí ke stránce, kterou údajně dostala. Nijak se to ale neprojeví na fragmentaci fyzické paměti. Jediné, co může dojít vylepšení, je fragmentace adresního prostoru aplikace. Ovšem jen za předpokladu, že adresní prostor rozšiřuje ještě nějakým dalším způsobem (třeba mmap). A i to se nakonec dá řešit jinak a lépe.

Ano, jde o fragmentaci adresního prostoru aplikace a smyslem je to, že glibc má strom alokací (které odpovídají nějakému velkému naalokovanému úseku a v něm půlce, půlce té půlce atd.), díky čemuž alokace a dealokace v adresním prostoru aplikace jsou velmi rychlé (je málo stromů, protože se alokuje po velkých kusech) a minimálně fragmentují (nejsou žádné sofistikované velikosti, jen mocniny dvojky a bloky v rámci jednoho stromu mohou přesahovat přes hranici stránky)

Sofistikovaný algoritmus na nedeterminisatické odstřelování procesů je moc pěkná věc. Když chcete, aby pro váš proces malloc opravdu fungoval jak má, můžete ho imunizovat proti OOM Killeru. On potom systém odstřelí něco jiného.

Aplikace sama se, pokud neběží pod rootem, nemůže imunizovat. Jinak pořád je to lepší stav, než když všechny aplikace čekají na paměť, protože malloc vrací nulu, a tak ani nelze spustit Správce procesů, kterým by šla paměť uvolnit - prostě takový jednoduše proveditelný deadlock přímo v návrhu systému (docela se divím, že toho ještě žádný vir nevyužil).

Linusovi nemá smysl psát. Zavedl memory management Linuxu do bažiny, a to díky tomu, že na začátku nebyl schopný udělat slušný návrh.

Mě návrh používající overcommitting a OOM killer přijde velmi slušný. Prosím nezapomínej, že Linus stavěl na POSIXu, tudíž si nemohl dovolit ignorovat fork a worker processy a s toho plynoucí problém se zabranou a nevyužitou pamětí, pokud by se overcommitting nepoužíval. Jak jsem ale psal výše, v případě, že dojde paměť, tak je úplně jedno, jestli overcommitting byl nebo nebyl použit - něco stejně spadne, případně bez overcommittingu to může dopadnou ještě hůř, celý systém se dostane do paměťového deadlocku.

Když aplikaci ve Windows selže alokace, může s tím ještě řadu věcí dělat. Například danou akci prostě odmítnout. Zkuste si to u MS SQL Serveru, MS Exchange, Oracle a dalších. Prostě dostanete hlášku typu "nelze alokovat dalšách 123456 bytů", a operace selže. Není důvod, aby kvůli tomu jakýkoliv proces padal.

Ale pouze v případě, že je ještě dost paměti to hlášku vůbec sestavit.

Pro management aplikací nepotřebujete pouštět Task Manager. Jistě víte, že není problém zastavit servis nebo odstřelit proces ze vzdáleného stroje.

Což má některé zásadní nevýhody, například to hodně blbě budu dělat na notebooku bez připojení k síti nebo když máte jen jeden počítač. Stejně tak povolit tam přístup přes síť na takovou službu je potenciální bezpečnostní díra.

Také není problém nastavit procesu, nebo sadě více aplikací, limit na zdroje.

Limity na zdroje umí i Linux (ulimit).

A aplikace může reagovat na selhání alokace mimo jiné zmenšením interních bufferů apod.

Tím se (pravděpodobně jen dočasně) zachrání ta aplikace, ale ne celý systém.

Na stroji běží věci, které tam běžet mají. OS je tam od toho, aby aplikace běžel, a ne aby "sofistikovaně" vybíral, které z nich "zřejmě" potřebujete.

Pořád jsem raději, když v nouzových případech (jako je nedostatek paměti) poběží to, co v tu chvíli zřejmě potřebuji, než to, co v tu chvíli zřejmě nepotřebuji, ale jinak to tam běží, protože se to běžně používá (třeba Samba, Apache, SQL server ap.). Zřejmě ti nějak nedochází, že nedostatek paměti je extrémní problém a systém si s tím musí nějak poradit - pokud možno tak, aby se z toho dostal, i kdyby aplikace odmítaly spolupracovat.

Když jsme u DoS pomocí vyčerpání paměti, tak to je věc, která u Linuxu skončí tím, že OOM Killer postřílí, co mu přijde pod ruku. Takže váš škodící program bude mít paměti velkou spoustu, a vše ostatní umře

Jedna z věcí, kterou OOM killer bere v úvahu, je také sežraná paměť. Pokud nějaká aplikace žere paměť jako divá, dokonce tak, že má víc, než ostatní aplikace dohromady, tak ji OOM killer sestřelí, protože evidentně s ní nebude něco v pořádku (shell ani jiné utility tolik nesežerou). Jinak samozřejmě root a jeho aplikace mají právo veta (případně mají k dispozici mlock a mlockall, takže mohou dojít do stavu, že naalokovanou paměť budou mít, ať se děje, co se děje), tam by cesta ke shození systému byla. Ale když už něco získá práva roota, tak nemá cenu shazovat systém na vyžrání paměti :)

Kdyby Linux měl od začátku threading a lepší alternativu k fork/exec, nebyl by overcomitting třeba.

Mohl bych vědět, co POSIXového měl Linus použít místo fork/exec?

Jakýkoliv vzdálený přístup ke stroji je potenciální bezpečnostní díra, takže to nepovažuji za argument.

Pokud nejde o šifrované a klíčem nebo heslem podepsané spojení, je to obří díra. Pokud je to šifrované a klíčem nebo heslem podepsané, potřebuje to paměť (minimálně na šifrovací klíč), která v tom okamžiku není, takže to nemůže fungovat.

Musíme si vyjasnit důležitou věc. Na Windows když dojde paměť, tak to znamená, že aplikace nedostane DALŠÍ paměť. Co má alokováno, s tím může fungovat. Když další alokace neprojde, může se podle toho zařídit. Není co zachraňovat - jde o stav jako každý jiný.

Z hlediska aplikace to je celkem normální stav. Z hlediska systému ne - nejsou zdroje pro nové a to ani servisní aplikace, systém se dostal do slepé uličky a pokud se nějaký proces neráčí ukončit (nebo spadnout, pokud neošetřuje alokace) nebo alespoň uvolnit nějakou paměť, tak se z ní už ani nedostane. Normální stav je to jen v případě, že není důvod spouštět nové aplikace ani alokovat další paměť, což ale u běžné práce ani u běžného server není téměř nikdy - na druhou stranu je to důvod, proč se na routerech overcommitting nepoužívá.

Obhajujete zjevně špatný model jen proto, že je použitý v Linuxu?

Ne, obhajuji zjevně špatný model jen proto, že pokud dojde k závažnému problému (což z hlediska systému nedostatek paměti je, to doufám chápe i MS) funguje lépe, než ten dokonalý model ve Windows. Jinak pokud ti vadí, tak Linux má tu krásnou vlastnost, že není vůbec žádný problém to změnit - na rozdíl od Windows :)

To, že použití forku vede k velké spotřebě paměti, je platný argument.

Jakým způsobem vede používání fork + exec k vyšší spotřebě paměti než používání CreateProcess? Na co se ta paměť navíc spotřebuje?

WMP používá stejné dialogy jako Notepad

Ale vypadá úplně jinak. Stejně tak Internet Explorer. A stejně tak Office.

bohužel mezi nimi není prakticky pro uživatele žádný zajímavý SW

Nj, není tam ani MS Word ani MS Internet Explorer a dokonce ani MS Windows Vista :/

Nikdo dnes nedovede nabídnout totéž v podobném rozsahu.

Ale dovede, KDE tohle mají daleko propracovanější, třeba system-wide podporu všemožných protokolů, celosystémové Single-Sign-On, KWallet, propojení e-mailu, adresní knihy, mapy, kalendáře a IM, KRunner se Strigi a tak dále a tak dále. A to KWord (MS Word) ani nemusí vypadat a ovládat se úplně jinak než Kate (Poznámkový blok) a Amarok (Windows Media Player) - mám na mysli třeba způsob ovládání menu nebo jako vypadá dialog nastavení, aby bylo jasno.

Už ve Windows 95 jste mohl vidět objektové foldery v Exploreru, například Control Panels.

KDE 3 to mělo taky („system:/“), v KDE 4 to zavrhli jako blbost, což opravdu je, protože to nemá nic společného se správou souborů. Ale já měl na mysli spíš SFTP nebo HTTP DAV, což Windows dodnes úspěšně neumí.

KDE se teprve s Plasmou pomalu dostává tam, kde byl MS před 14 lety.

MS před 14 lety uměl widgety? Já myslel, že to byla jedna z velkých novinek Windows Vista (pardon, to jsou vlastně gadgety). Plasma je převážně přepsaná Superkaramba, není to nic převratně nového. Jen tak mimochodem, KDE uměly widgety v době, kdy to ještě neuměl ani MacOS X.

Single sign on je koncept, který MS prosazoval před více než 10 lety, a dnes je to stejně úsměvné, jako prosazovat elektrifikaci.

Nepsal jsem, že by SSO byla v KDE novinka, KDE to umí přibližně 5 let. Ale i přes úsměvnost jeho prosazování jej Windows dodnes pořádně neumí. Ale to je spojené s tím, že Windows neumí transparentně přistupovat ke vzdáleným souborů jinak než přes SMB (no, vlastně je tam i nějaká částečná podpora nezabezpečeného FTP) a nemají žádného správce hesel jako je KWallet, tak vlastně ani nemají možnost nějak SSO propagovat do systému.

KWord je hračka, zkuste OpenOffice. Ten je bohužel pomalý, a vypadá úplně jinak, než cokoliv na Linuxu (protože je to obšleh MS Office dialog po dialogu, menu po menu).

KWord není hračka, na psaní běžných dokumentů úplně stačí. A na rozdíl od MS Wordu si bez problémů poradí i s ISO ODF.

OpenOffice umí používat dialogy prostředí, ve kterém běží, tedy i dialogy z KDE. Jinak menu v OOo se liší daleko víc od menu v MS Wordu, než se microsoftí šachy liší od těch v MacOS X.

zkuste poslední KWordu používat na 7 let starém distru

Naprosto bez problémů, proto taky KDE/Qt má styly. Změnou stylu se jednoduše změní vzhled ovládání všech aplikací najednou a pořád všechny vypadají stejně.

MS má od Windows 95 poskládaný Windows Explorer z COM objektů. Všimněte si, že v Exploreru je každé kontextové menu, toolbar, speciální adresář (desktop, recycle bin, control panel), property sheet pod. nějaký COM objekt. Je to skládačka, kde můžete dílky přidávat či nahrazovat.

Něco jako KParts?

SFTP ani WebDav nemůžou fungovatjako běžný FS. Neumí totiž například zamykání.

<irony>Samozřejmě, bez zamykání to přeci nemohou ostatní aplikace používat. Jak jen to KDE dělá, že to funguje?</irony>

MS má podporu WebDav a FTP, ale z popsaných důvodů nemůže být plnohodnotná.

To, že FTP neumí zámky, nějak brání MS v implementaci šifrování a toho, aby se dalo k FTP přistupovat z libovolné aplikace bez nutnosti mít to FTP předem připojené?

Single Sign On je primárně o tom, že máte JEDEN uživatelský účet.

SSO je primárně to, že se přihlásíš jednou a jsi přihlášen všude, aniž bys musel znovu zadávat heslo (viz Wikipedia). Počet účtů je limitace pro ty, kteří neví, že to limitace není.

To by mě bez ironie zajímalo, jak KDE docílí toho, aby aplikace dokument na FTP zamkla, jako na lokálním FS

A proč by to měla zamykat? To se s tím bez zámků nedá pracovat? (mimochodem na rozdíl od Windows linuxové aplikace soubory většinou nezamykají)

Jistě je možné SFTP implementovat ve Windows stejně, jako je implementované FTP. Otázka je, proč to děl

To se nedivím, když ani to FTP není implementované pořádně.

jeden na to, další na ono, ale žádný pořádný

To bych rád věděl, jaký má Windows pořádný souborový systém na NAND média. Ne, FAT ani NTFS na to opravdu není dobrá volba.

Když mám doménový účet ve firmě, přihlásím se kamkoliv, kde mám právo, a použiji jakýkoliv prostředek, ke kterému mám právo. Když mám hromadu účtů ve svém KDE, tak se nepřihlásím ani na konzoli jiného stroje, natož z toho jiného stroje na tiskárnu,

Když mám doménový účet ve firmě, přihlásím se kamkoliv, kde mám právo, a použiji jakýkoliv prostředek, ke kterému mám právo. Když mám hromadu účtů ve svém KDE, tak se nepřihlásím ani na konzoli jiného stroje, natož z toho jiného stroje na tiskárnu, ke které mám heslo na svém desktopu.

Možná by nebylo od věci si zopakovat definici SSO. Nic o cizích konzolích a omezení na doménu se tam nepíše :)

ale nakonec můžete nadále věřit tomu, že KDE je průkopníkem Single Sign On. Křesťani věří tomu, že Ježíš změnil vodu ve víno, a přesto je nechají volně chodit po ulicích.

A Wokenáři věří tomu, že SSO a doména jedno jest :)

Například když DB otevře soubor, měla by ho zamknout, jinak hrozí, že ho omylem otevře jiná instance DB engine, a dojde k závažnému problému.

Databáze samozřejmě své soubory zamykají a z toho důvodu nemohou fungovat přes FTP (SFTP umí soubory zamykat).

Jak jsem psal, (S)FTP nelze implementovat pořádně.

Hmm, aha, takže neexistence zámků je důvod, proč nelze implementovat ani šifrování FTP ani připojování on-demand. Fakt super argument. Ale u MS se tomu nedivím.

Pro která NAND média?

Flash a SSD disky, IDE CF a další média, která se při přepisování pořád toho samého sektoru celkem rychle zničí.

Osobně bych doporučil počkat na SSD s lepšími parametry, protože současným SSD po čase dost ubírá výkon wear leveling.

Super, takže neexistence vhodného FS je problém technologie. Ale opět se tomuto argumentu u MS nedivím (viz argumenty jako že necertifikované ovladače jsou viníky HW problémů ve Windows zatímco u neoficiálních linuxových ovladačů k HW, ke kterému ani není dokumentace, je to vina celého Linuxu).

Bez ohledu na sportohledně definice Single Sign On se můžeme shodnout na tom, že původní tvrzení o tom, že KDE vyniká v SSO je nesmysl, a Linux je tradičně léta pozadu.

Nemůžeme, v připadě SSO je KDE stále o mnoho let napřed před MS (viz SSO pro všechny protokoly podporované KDE a pro všechny webové služby, ve Windows se teprve IE7 naučilo SSO pro webové služby a to ještě jen částečně). Opět opakuji, že SSO není doména, protože si to evidentně pleteš. Jinak doménu s SSO lze celkem bez problémů rozběhat i v Linuxu (např. přes SFTP nebo Kerberos + NFS)

V případě Linuxu je problémem omezená podpora HW, a fakt, že neexistuje možnost před koupí zjistit, jestli dané zařízení bude opravdu fungovat. MS má svůj Hardware Compatibility List. HW na něm uvedený musí vyhovovat daným kritériím, a prochází přísným testováním. Na Linuxu nejvýše zjistíte, že zařízení jednomu Frantovi údajně nějak fungovalo.

A co Ubuntu Hardware Compatibility List?

STFP nemá s doménou nic společného

Samo nemá, ale lze jej použít pro implementaci domény (třeba pomocí PAM + sshfs + KDE).

Nečekáte snad, že WinAmp bude mít klasické okno, nebo Flight Simulator a Age of Ampires budou používat ovládací prvky stejně jako zbytek aplikací

U her to chápu, je to součást stylu celé hry, ale WinAmp mě tím vždycky hrozně štval (taky jsem jej nikdy nepoužíval).