Vlákno názorů k článku
Steve Ballmer: Linux je větší hrozba než Apple od mm - Zefyrin Xyrdal nebo Opher Lael či jak se...

Windows Embedded lze instalovat bez grafiky řadu let. Běžná instalace Windows pravda vždy obsahovala GUI, a nevidím na tom nic špatného. Ještě jednouy píšu, že přes doplňováním pomocí tabů se na NT doplňovalo pomocí F-kláves. A PowerShell že je na půli cesty? Hochu, zkuste se na PowerShell trochu podívat. Unixové shelly jsou nesmírně primitivní záležitost, která spočívá ve spouštění příkazů, a následném parsování textových výstupů. PowerShell je objektový, takže můžete vzít seznam objektů typu Service (obdoba deamonu), vyfiltrovat objekty které mají vlastnost State nastavenou jako Stopped, a zavolat na ně metodu Start. Mimo jiného můžete třeba získat seznam oken na obrazovce, vyfiltrovat je podle názvu, a zminimalizovat. Unixové shelly jsou pravěk.

MS přišel s antialiasingem písma v Microsoft Plus! for Windows 95, které bylo uvedeno s Windows 95. Pokud jsem si všimnul, tak Linux má s antialiasingem v řadě aplikací problémy dodnes. Absence pořádného Multiuser Multitaskingu jsem si nějak nevšiml, ale třeba mi vysvětlíte, co máte na mysli. Správu programů pod běžným uživatelem řešit nemůžete, protože na to nemáte permissions, stejně jako na unixech. Vektorová grafika je ve WPF standardem. Compiz je proti WPF parodie, protože jde jen o kompozitní desktop s efekty pro pubescenty, ze kterých musí obdobníci na uživatelský interface pupínky (gumová okna a efekt dopadajících kapek vody jsou největší prohřešky). Zkuste se někdy podívat na zásady návrhu interface. Zjistíte, že efekty nesmí člověka rušit. Aero/WPF potom není jenkompozitní desktop, ale také HW akcelerace vykreslování obsahu okna, včetně jednotlivých písmen, HW antialiasingu fontů a skládání obsahu okna přes HW akceleraci. K tomu interface v .NETu, který nabízí věci, které Linux mít ještě dlouhá léta nebude (pokročilá typografie, integrace multimédií). Ve WPF není problém udělat krychli, která na stěnách přehrává video, a celé se to zrcadlí na desce umístěné pod tou krychlí. Zajímavé je, že stačí popsat tu scénu v XML (XAML), a WPF zařídí zbytek - žádné programování, je to použití základních služeb platformy.

Stabilita Windows je taková, že zákazníci Unisysu mají od roku 2001 průměrnou availability nad 99.99%, a to bez clusteringu. Samozřejmě se nebavíme o počítači, který si někdo spatlal doma na stole.
http://www.unisys.com/products/enterprise__servers/high_d_end__servers/availability/

Online defragmentace neohromí, ale pomůže. A z čeho vycházíte, když tvrdíte, že ext3 fragmentuje méně, než NTFS? Silné přesvědčení, nebo nějaká fakta? Pro Linux tuším už existuje jiný FS s online defragmentací, snad XFS. Ovšem FS na Linuxu jsou příšerný příběh. Hromada mizerných FS, jeden umí žurnál, další kvóty, jiný NFS, další ACL a NFs, jiný kompresi. Některé FS dlouhá leta neměly funkční nástroje typu fsck. Ve Windows je od první verze funkční NTFS s žurnálem, a nyní s ACID transakcemi (které Linux obšlehne možná za pár let). Abyste to ocenil, musíte vědět, že ACID se nedává pod jazyk ;)

.NET začal tak, že Sun mohl mít hodně, ale chtěl víc. Teď nemá nic, a potácí se už leta před krachem. Výkonově je na tom .NET o dost lépe, než Java, a rozsahem funkcí daleko lépe. Windows mají .NET jako primární API, to je fakt (podívejte se na vývojové nástroje). A asi o tom nevíte (ne, určitě nevíte), ale MS píše OS postavený komplet na .NETu. Výhodou bude, že nabídne řádově vyšší spolehlivost a bezpečnost, než cokoliv napsaného v nespolehlivém C/C++. Managed prostředí (.NET, Java) totiž umožňuje matematicky prokázat vlastnosti kódu. No, možná se do uvedení takového systému dočkáte nových ikonek v KDE ;)

Správa barev není záležitostí ovladače. Nevíte, o čem mluvíte. Správa barev je věcí systému. Každý monitor má jiný barevný prostor (rozsah zobrazitelných barev), totéž každá tiskárna. Windows korigují barvu veškeré grafiky pomocí profilů zařízení tak, aby byly barvy věrně zobrazené i vytištěné (tedy pokud máte správné profily).

Začátky MS máte odkud? Jedna paní povídala? A jestli potřebujete otcovský vzor, a ne slušně navržený systém, tak diskusujete na špatném místě.

No nevím, ale funkčnost imperativního kódu (C#, Java apod.) se podle mě dá matematicky dokazovat velice těžko. A i u čistě funkcionálních jazyků číhají záludnosti typu nekonečné rekurze. Obecně je statická analýza kódu NP těžký problém. Souhlasím s tím, že "managed" (strašné slovo) jazyky jsou na tom z tohoto hlediska líp než jazyky s ukazateli, ale v zásadě je to zlepšení pouze o půl třídy. Nic zásadního z hlediska možnosti "matematického dokazování" neřeší. Protože pokud umíte zanalyzovat cykly a rekurze, zvládnout analýzu alokace paměti a přístupy do ní přes ukazatele je poměrně triviální. Nesprávný ukazatel nahraďte špatným indexem do pole (nebo naopak) a jsme tam, kde jsme byli.

Ono to ostatni blaboleni lol ophira stoji za podobne prd.

Vzdycky kdyz ty kydy ctu, rikam si jestli nemluvi o nejakych jinych Windows libovolne verze nez ktere jsem videl lehnout kvuli kazde kravine, nezridka ihned po instalaci.

Zvlastni, ze na stejnem hw mi Debian Unstable jel takrka bez ztraty kvetinky az do vymeny hw (vcetne disku) a paklize se nemenil i disk, tak i potom.

Asi ho MS plati jako doplnkovou reklamu pro ty, co pouzivaji na rootu adblock.

Teda na win embeded bych desktop mit nechtel, to rovnou QNX a budu mit vice pouzitelneho SW :-D. Pokud o tom hodlas dlouze polemizovat, nainstaluj si na embeded CS3 a Autocad 2008, pak se muzeme bavit o jejich pouzitelnosti.

Kaslu ti na pravek, chci vysledky a ty s linuxem/unixem mam. K cemu je mi OS do ktereho musim dobastlovat tuny SW (zhruba $10k jen za cast pracovnich nastroju) abych mel to, co mam na linuxu zdarma a ve vynikajici kvalite?

Stabilita virtualizovanych windows za nejakym dobrym firewallem a na certifikovanem HW? Srovnaval jsi s daty od RH nebo Novellu a pokud ano, odkud je mas?

Plus vysel PO vydani w95.

Meles o FS ze kterych kazdy umi neco ale proc nesrovnavas s XFS ktery umi vsechno, zeby zamerne?

Na Windows Embedded není problém nainstalovat CS3 nebo Autocad 2008.

Pokud máte na Linuxu zdarma, co potřebujete, buďte dloluho a šťastně živ. Naprostá většina

XFS umí všechno? Namátkou proti NTFS neumí ACID transakce ani kompresi. Dále to netřeba rozebírat - neumí totéž, co NTFS.

To ale prijdou o to panensky ciste prostredi a moc embeded uz nebudou ;-)

Vy jste takovy "papirovy clovicek", tyhle typky mam rad :-))

Photoshop také není typická aplikace pro embedded systém. Naopak třeba digitální self-service minilaby se na Windows Embedded provozují běžně. Ono je to celkem triviální. Stačí běžný HW, Windows Embedded, a aplikace se píše prakticky stejně, jako pro běžné Windows.

http://www.dedem.it/ingles/pdf/scheda%20DIGIPRINT%20eng%20rev%200.pdf

Hlavne se pri konstrukci nesmi zapomenout na velke tlacitko reset. :-)

...pro případ pádu X11 serveru, nebo pádu primární aplikace... Nebo vám nepadá X11 server, KDE a aplikace pro něj?

Anebo tam dáte Linux a napíšte tu aplikaci jenom jednou ;)

Samozřejmě řadu věcí můžete napsat jen jednou. Desktopové a embedded aplikace se ale liší určením, a proto i provedením. Na desktopu budete asi běžnou spustitelnou aplikaci, na embedded systému to bude náhrada grafického shellu (aplikace bude full screen, nepůjde minimalizovat atd). Na desktopu budete aplikaci ovládat klávesnicí a myší, na embedded systému asi trouch screenem a možná tlašítky, a tedy bude odlišný interface. Na embedded systému také bude potřeba nějaká autorizace (karta, zaplacení částky), atd.

Ale krátkozrací lidé to mají hrozně jednoduché. Prostě by to napsali pro Linux, a bylo by hotovo.

Příkazovou řádku ve Windows používám ve velmi často třeba já. Mezi běžnými uživateli to pochopitelně není rozšířené. Proto existují ty GUI aplikace, které uživateli sestaví soubor s výpisem souborů v adresáři, a podobné příšernosti.

Pokud jsem si všiml, do lidí nepíchám, a mluvím k věci. Přečtěte si ještě jednou thread diskuse, a zeptejte se sám sebe, jestli do někoho píchám.
PS: Zdar Albánii.

Linux mal antialiasing písma skôr? tak prečo je dodnes taký mizerný?

To je vec nazoru. Mne prijde antialiasing v Linuxu daleko hezci nez ve Windows XP (uznavam, Visty bych si na disk nedal, mozna az ten jejich SP2 co MS radsi prejmenoval na Windows 7 protoze s Vistou si urthnul ostudu).

a preto sa na webe vyskytuje toľko návodov na deuglification Linuxu?

Muzu poprosit o jeden?

To zní jako názor znalce :). Podívejte se, jak vypadají dnes MS vývojové nástroje, a jak vypadá dokumentace API.

.NET je z 90% zkopírovaný z Javy? Pěkná blbost. .NET je funkčně o tolik rozsáhlejší, že to jaksi není možné. .NET byl sice napsán a sestaven z dalších MS projektů (COM+ 2.5, ASP+, Next-Generation Web Services) proto, že Sun nechtěl MS dovolit Javu rozvíjet, ale zato Javu rychle předstihl. Když jsme u toho, tak Java vychází z Oaku, a předchozí pokusy s virtuálními stroji zahrnují třeba BCPL ze šedesátých let, nebo VisualWorks. Java, hnusná kopie, brr ;)

Napadlo vás někdy, že za většinou chyb a bezpečnostních problémů současného SW stojí používání C/C++? Přetékání bufferů, zápisy mimo hranice pole, resource leaks, chyby pointerové aritmetiky, absence výjimek u frameworků. Managed jazyky samy o sobě tohle řeší. Nemluvě o možnosti matematicky prokázat nějaké požadované vlastnosti SW. Jestli tohle nevidíte, sedíte si na očích.

.NET mi spíš připomíná další kámen na cestě ke Smalltalku :)

Přetékání bufferů, zápisy mimo hranice pole, resource leaks, chyby pointerové aritmetiky, absence výjimek u frameworků. Managed jazyky samy o sobě tohle řeší.

Hmm, takže za problémy může Céčko, protože ve slušně napsaném C++ nic takového nenastává :) C++ totiž tohle také řeší (sice dovoluje programátorovi tu kontrolu obejít, ale když programátor není prase, tak to řeší).

Nemluvě o možnosti matematicky prokázat nějaké požadované vlastnosti SW.

Něco jako BitC? Mimochodem .NET umí formální verifikaci?

Programátoři dělají chyby, a managed prostředí je jedním ze způsobů, jak jejich počet omezovat. Navíc se na rozdíl od C/C++ chyby zpravidla projevují deterministicky (třeba výjimkou), a ne přepsáním čehosi kdesi v paměti, a následnými průšvihy.

.NET sám o sobě má prvky formální verifikace. Singularity na formální verifikaci kódu stojí (procesy jsou oddělené jen přes invarianty, ne klasickým process modelem).

To je ale malinko něco jiného, než matematické dokazování správnosti kódu. S prvním odstavcem v podstatě souhlasím, ikdyž mě zajímají spíš jazyky, které jsou trošku na jiné úrovni - např. Scala. Singularity je jistě zajímavý projekt, zkusím si zjistit více.

Inspiroval jste mě ale k jednomu experimentu - více případně za pár dní na mém blogu.

Matematické dokazování požadovaných vlastností kódu (nikoliv jeho správnosti) je opis pro model checking. Ono v C/C++ se velmi těžko dokazuje, že například nemůže dojít k deadlocku, když řada konstrukcí typu strcpy nebo přístupu k poli může mít zcela nepředpokládané side effecty.

Singularity je zajímavý koncept, protože díky izolaci procesů přes invarianty nemá overhead klasického izolace procesů (a kernelu). Systém založený na Singularity bude zřejmě největším pokrokem v designu OS od příchodu Multicsu, a zároveň bude řešit řadu problémů s bugy a bezpečností. HW už na to dozrál, teorie také, a teď je čas na mainstreamovou implementaci.

Možnost deadlocku nesouvisí s jazykem. Deadlock je možné způsobit v libovolném jazyce - klasický příklad

process A:
acquiremutex(X)
acquiremutex(Y)

process B:
acquireMutex(Y)
acquireMutex(X)

se dá zpáchat v libovolném jazyce. Chápu, že v C/C++/Pascalu apod. se dá snadněji způsobit katastrofa, ale i v těchto jazycích lze programovat poměrně bezpečně a používat vysokoúrovňové knihovny a vyhnout se přímému použití ukazatelů. Experiment, na který se chystám, se toho týká.

Oddělení procesů přes invarianty nemá nic společného s formální verifikací, to je jen vedlejší efekt použití managovaného jazyka. Kde jsi našel, že .NET umí formální verifikaci? Jediné, co jsem našel, je, že se verifikuje, jestli je kód bezpečný nebo není.

A verifikace zda je kód bezpečný nebo není (což není zrovna korektně psané, že), to snad není prvek formální verifikace?

Ano, je to prvek formální verifikace, ale není to celá formální verifikace. Formální verifikace totiž kromě bezpečnosti zkoumá, jestli to bude dělat to, co to dělat má.

Proto jsem tvrdil, že .NET má prvky formální verifikace, a ne že umí formální verifikaci. To totiž není věc platformy. Platforma neví, jaké vlastnosti by měl daný kus kódu mít, aby dělal to, co autor zamýšlel. Ovšem managed platforma formální verifikaci *umožní provést* dalšími nástroji, na rozdíl od C/C++, které ji v podstatě vylučují.

A co to BitC? To je C s formální verifikací.

Thready jsou rychlejší, než work procesy. To je známý fakt. Thready v rámci procesu sdílí adresní prostor, takže není třeba TLB flush. Synchronizační primitiva jsou také rychlejší. O nevýhodnosti threadů vyprávějte autorům Apache, Oracle a dalších aplikací, které dávno používají multithreading.

Vážně, managed prostředí jako primární API.

KDE má parodii na color management, Linux potom žádný color management na systémové úrovni nemá. To víte, v době vzniku X11 se color management nenosil.

Linux je návrhem srovnatelný s NT? LOL. Proč tedy nemá preemptivní kernel, proč kernel 2.0 pořád neměl threading, proč je I/O pořád řešené tak příšerně, proč existuje hrůza vzaná OOM Killer? To snad i OS/2 byla napsaná lépe.

Pro unix a linux, tedy pokud se za posledni tyden neco nezmenilo, existuji minimalne 4 kvalitni implementace spravy barev. Z toho minimalne 2 komercni na dost dobre (vysoke) urovni.

Odpoved na vsechna vase "proc?": Proc je tedy windows v porovnani s linuxem tak zoufale pomaly, kdyz je papirove dokonaly a proc se musi MS snizovat k benchmarkum kde linux bezi na predpotopnim HW aby test prohral (viz. samba v get-the-facts)?

4 system-wide implementace správy barev? Na to bych se i podíval. Mohu se zeptat, které to jsou?

Kdo říká, že je windows v porovnani s linuxem tak zoufale pomaly? Není to jen zbožné přání? Ale neodbíhejme od tématu. Když je Linux 2.x návrhem srovnatelný s NT, proč tedy nemá preemptivní kernel, proč kernel 2.0 pořád neměl threading, proč je I/O pořád řešené tak příšerně, a proč existuje hrůza vzaná OOM Killer? To je zjevně velmi špatný návrh.

Google ti napovi, chytraku.

Je to snadno pozorovatelny fakt, zeptej se uzivatelu windows nakolik jsou spokojeni se svym systemem po pul roce bezneho pouzivani. Nechces se zeptat primo vyvojaru kernelu? Kontakty jsou verejne ;-)

proč tedy nemá preemptivní kernel

Protože to nepotřebuje?

proč kernel 2.0 pořád neměl threading

Ze stejného důvodu, proč Windows dodnes nemají fork.

proč je I/O pořád řešené tak příšerně

To jako proč se celá paměť používá jako cache?

proč existuje hrůza vzaná OOM Killer?

Aby, když se zblázní aplikace, se ten stroj neuswapoval k smrti, jako to udělají Windows.

Preemptivní kernel není potřeba? Aha. Tak proč se autoři kernelu dlouhá léta (neúspěšně) snaží o jeho implementaci? Že by kvůli latency? ;)

Jenže on threading potřebuje. Apache, Oracle a další dnes používají threading i na Linuxu. Použitelná implementace threadingu přitom přišla až s kernelem 2.6, jako dodělávka. Fork byl pěkný model možná tak v sedmdesátých letech.

Nejde o cache. Jde o způsob obsluhy zařízení, interruptů.

Ale kdepak. OOM Killer je implementovaný proto, že Linux má obrovskou spotřebu paměti. On totiž fork vede k tomu, že stránky nového procesu jsou značeny jako copy-on-write. Kernel tedy musí mít paměť, kterou by případně přidělil, kdyby aplikace do daných stránek opravdu zapsala. A protože té paměti má málo, tak autoři memory managementu řekli "no tak budeme o paměti lhát, a když dojde na lámání chleba, tak vylosujeme nějaký proces, a odstřelíme ho". To vede ke skvělé situaci, kdy aplikace požádá o paměť, dostane jí přidělenou, a když se do ní snaží zapsat, tak kernel prostě odstřelí nějaký proces, který se mu znelíbil. 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. Nakonec proč se starat o nedostatek paměti - kompiluje to, a dokonce to nějak funguje ;)

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.

Overcommitting lze samozřejmě vypnout. Bohužel pak celem záhy dojde paměť, protože Linux je mimořádně žravý. Jestli swapd pomůže, to je otázka.

Po jak velkých kusech glibc alokuje paměť, že to vede k nutnosti overcomittingu? Obávám se, že to *není* příčina uvedení OOM Killeru.

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

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.

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?

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

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.

Nerad bych opakoval, co psali jiní, takže viz níže link o spotřebě paměti u subprocessů. Ono když má DB engine alokováno 1GB paměti, a provede se běžný fork/exec (například shell out kvůli chybějícím API pro management), tak to s pamětí pěkně zacvičí.
http://developers.sun.com/solaris/articles/subprocess/subprocess.html
Možná se dá problém obejít, ale je otázkou, jestli v souladu s POSIXem, a jestli to aplikace fakt dělají. Další problém jsou worker processy a CoW memory. Prostě thready jsou thready, a už to vědí i autoři Oracle, Apache a dalších.

To, že glibc alokuje po nesmyslně velkých kusech, je zřejmě spíš důsledek overcomittingu. Navíc mi není jasné, jak to zlepší výkon a sníží fragmentaci, když kernel Linuxu stejně přiděluje paměť až při prvním přístupu ke stránce. Každopádně overcomitting je prasárna, k tomu porušení porušení normy jazyka.

Ve Windows samozřejmě také existuje CoW, ale protože se používá threading a ne worker procesy, a nepoužívá se zběsilá sekvence fork/exec, tak není potřeba lhát o paměti, a pak náhodně střílet procesy, když paměť dojde. Asi měl Linus strávit více času návrhem, a ne spatlat kernel na rychlo, hlavně aby to něco dělalo.

Hele zkuste napsat rovnou Linusovi, adresu ma verejne dostupnou.

A on přes noc přepíše kernel i aplikace, že? :)

Chcete snad vyresit svuj problem a kdo jiny to muze realizovat nez autor aplikace? Verim ze zabar Linus vyslechne a zapracuje vsechny pripominky experta jakym je LO a svet bude ruzovejsi nez ordinace v ruzove zahrade.

Já nemám problém, protože Linux používám zcela výjimečně. Linus sice asi může změnit řadu věcí v memory managementu, ale dalo by to velkou spoustu práce. A výsledek by nebyl k ničemu, pokud by zároveň nenastala změna v alokátoru glibc, a aplikace nezačaly používat inteligentnější konstrukce, než worker processy a fork/exec. Jinými slovy když se něco spatlá na začátku, později se to velmi špatně opravuje.

clone je Linux-specific, portabilní to není. BSD by mělo mít něco podobného. Aplikace to asi nepoužívají, proč taky, když máme overcommitting? :)

Výkon se zvyšuje a fragmentace se snižuje tím, že se to nemusí kromě kernel space (tzn. u fyzického umístění stránek) řešit složitě ještě v user space (tzn. u umístění mallocnutých dat na haldě). Normy kterého jazyka? Ani POSIX ani ISO C nic o overcommittingu neříkají (ISO C říká, že paměť z mallocu existuje po dobu trvání procesu nebo dokud není freenutá, což Linux nijak neporušuje).

Ty procesy se nestřílejí náhodně, je na to docela sofistikovaný algoritmus. Linux o paměti nelže, free i top vypisují přesné informace :)

Co kdybys napsal Linusovi, čím z POSIXu měl nahradit fork/exec nebo jak to měl implementovat, aby nebyl potřeba overcommitting?

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

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.

Správně. POSIX ani ISO C neříkají nic o tom, že když aplikace dostane paměť, a pak k ní zkusí přistoupit, tak jí OS možná odstřelí, protože tu paměť ve skutečnosti nemá.

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.

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. Jistě víte, že v případě Linuxu prakcitky žádná fáze návrhu neproběhla.

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.

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. Také není problém nastavit procesu, nebo sadě více aplikací, limit na zdroje. A aplikace může reagovat na selhání alokace mimo jiné zmenšením interních bufferů apod. Jestli vám připadá lepší ten popsaný cyklus "Linux lže o dostupnosti paměti, aplikace lžou a potřebě paměti, a když podvod praskne, tak se holt metodou sofistikované náhody něco odstřelí", tak máte o kvalitním memory managementu dost svérázné představy.

Celkem mě překvapuje, že podle vás OOM Killer odstřelí něco, co "zřejmě" nepotřebujete. 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.

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. V případě Windows mohou všechny aplikace dále spokojeně fungovat s pamětí, kterou mají, a případně požadavky vyžadující další alokaci mohou odmítnout. Hlavně je to ale na Windows deterministické, systém neslibuje co nemá, a pak nemusí náhodně odstřelovat.

Linus stavěl terminálový emulátor, a později opisoval komerční unixy podle manu a manuálů. Nenapsal POSIX compliant systém, ale kopii tradičních unixů ze 70. let, bohužel bez plánování a rozmyslu, a tedy řekněme divoce. Kdyby Linux měl od začátku threading a lepší alternativu k fork/exec, nebyl by overcomitting třeba. A když už zmrším návrh, a pak se škrábu na hlavě, že OS má problémy běžet s malým množstvím paměti, tak můžu buď upravit návrh, nebo se vrhnout ještě dále do té bažiny "lže každý o všem, a nikdo neví, kdy a co bude třeba odstřelit".

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?

Pokud server potřebuje alokovat paměť, aby řekl že nemůže alokovat paměť, tak autor udělal něco špatně.

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

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ý.
Na Linuxu je to jinak. Aplikace dostaly paměť přes malloc nebo přes CoW při forku, a když se k ní později snaží přistoupit, tak kernel zjistí, že tu paměť ve skutečnosti nemá. V takovém případě je samozřejmě problém DALEKO závažnější. Na lež o paměti se přišlo, a protože se lhaním při alokaci paměti norma jazyka C nepočítá, tak je odstřel nějaké aplikace asi jediným řešením.

Pokud jde o DoS sežráním dostupné paměti, tak tam se asi shodneme, že jsou jediným opravdovým řešením limity na paměť. OOM Killer není ochranou před DoS.

Co POSIXového měl Linus použít místo fork/exec? Uvědomte si, že Linus NEPSAL a NENAPSAL POSIX compliant systém. Linux má třeba ne-POSIXový clone(), a stejně mohl mít od začátku i něco typu CreateProcess(). Stejně tak mohl mít od začátku threading, který už v té době měl třeba Solaris. Obojí by ovšem vyžadovalo víc invence, než jen přepisovat prastaré unixy.

Upřímně nechápu, proč se snažíte obhajovat model, který je zjevně špatný. Asi se shodneme, že OS nemá při alokacích lhát že paměť je k dispozici, a aplikace nemá lhát o tom kolik paměti vlastně chce. Obhajujete zjevně špatný model jen proto, že je použitý v Linuxu?

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 :)

Windows mají autentizované spojení všude od NT 3.1 (NTLM). V té době unixy pro ilustraci masivně používaly nebezpečný telnet. Autentizace nutně nevyžaduje alokaci další paměti. Navíc Windows udržují oddělený memory pool pro user space a kernel mode.

Windows nemají problém s tím, když není další paměť. Není důvod, aby neběžely. U tradičních unixů sedmdesátých let mohl nedostatek paměti vyústit v havárii, což byla také primární motivace zavedení limitů.

Znovu opakuji, že OOM Killer není ochrana proti DoS vyčerpáním paměti. Je to způsob, jak konsolidovat situaci, když se provalí fakt, že kernel slibovat paměť, kterou ve skutečnosti neměl. Pokud se chcete chránit před vyčerpáním paměti, máte na obou platformách k dispozici limity, a ve Windows navíc notifikace (na jakýkoliv performance counter si můžete nastavit skript, včetně volné paměti). Na Linuxu není možné overcomitting nepoužívat, protože díky špatnému designu (mimo jiné užívání fork/exec) je spotřeba paměti velmi vysoká.

prakticke prihlady:

soft naalokovano pouziva se (RSS) swap vypnut
db2 bez pripojenych useru 338M 85M
apache2.2 49M 12.2M
db2 itma 75M 13.8M
db2 ldap autoriazacni agent 191M 31M
db2 health agent 169M 26M
db2 watchdog monitor 214M 33M
mysql 118M 15M

a to zamerne nevytahuju takove perly jako Sun Glassfish 980MB alloc 128MB used ci Oracle10g.

u normalni masiny ten overcommiting proste vypnout nemuzete aniz byste mel desitky GB veliky swap. Tomu rikate dobry memory management? Jak by v tomto pripade mel vypadat pak ten spatny?

Spatny vypada jako ten z Redmondu.

Nechtělo by to trochu argumentace? Ten člověk popisuje poměrně závažný problém správy paměti na Linuxu, který se ve Windows nevyskytuje.

DB2, Apache2, MySQL, Glassfish a Oracle na normální mašině. LOL :) To běháš i ve Windows?

Vždyť jsem psal, že glibc (a případně i ty aplikace) předpokládá overcommitting a podle toho alokuje a pokud se to někomu nelíbí, tak si to má přenastavit. Mimochodem u MySQL i Oracle lze alokační strategie nastavovat v konfiguraci, v Linuxu jsou prostě přizpůsobené na overcommitting ;)

Linux lže o tom, že aplikaci přidělil paměť, a aplikace s tím počítají, takže lžou o tom, kolik paměti potřebují. To je v podstatě dokonalý hnus.

Ale funguje to rychleji a spolehlivěji než ve vyšperkovaných Windows. Navíc to nemůže paměťově deadlockovat.

Fakt to funguje rychleji a spolehlivěji? Z čeho při takovém tvrzení vycházíte? A jak jsem psal o kus vedle, DoS alokací padměrného množství paměti rozhodně není vyloučen použitím OOM Killeru. Jenom vám OOM Killer vybije hromadu procesů, zatím co ve Windows ty procesy mohou dále spokojeně běžet s pamětí, kterou už mají.

jo to beham i na windowsech. na svem notasu mi bezi soucasne oracle, db2, websphere 6.1, data studio, tivoli continual backup a par drobnosti. Pro mne to nejsou aplikace pred kteryma bych mel nejakou mimoradnou uctu ci hruzu - pouzivam je bezne denne. potrebuji ale podle vypisu z windows monitoringu zjevne mene pameti nez v linuxu.

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?