Názory k článku Jak jsem vracel licenci k Windows – Acer 2014

Já tady vidím jednoho trolla, kterého celý root krmí už několik let.

1. Bezpečnostní díra zůstává bezpečnostní dírou, i když není vystavená na inetu.

2. Vaše prohlášení o jedné bezpečnostní chybě za deset let je nadále zjevně nesmyslné.

Pokud byly nahrazeny soubory na FS (jako že byly), můžete se dostat do problémů, které jsem tu už popisoval. Staré binárky běžící v RAM mohou mít problém s novými resources a executables. Samozřejmě pokud na stroji neděláte nic důležitějšího než psaní dopisů a sledování filmů, tak na tom moc nezáleží. Ale stejně dobře to můžete udělat až po restartu, který trvá hluboko pod minutu.

Restart, jako reboot hluboko pod minutu? LOL :-D Sám jste tady uznal, že nelze dopředu vědět, jak dlouho bude restart trvat, protože instalace aktualizací, a teď tady vyplodíte takovouhle hovadinu. To je vás agitátorů tady víc, nebo schizofrenie? :-D

"Staré binárky běžící v RAM mohou mít problém s novými resources a executables. "

No, možná tak na vidlích.

To si musíte vybrat. Buď jste nainstaloval aktualizace a teď chcete restartovat, což je pod minutu. Nebo jste je nenainstaloval, a instalují se během restartu. Pak to samozřejmě může trvat déle.

Ad Staré binárky běžící v RAM mohou mít problém s novými resources a executables; možná tak na vidlích - co tomu problému na Linuxu předchází? Máte tam snad nějaký mechanismus, která říká, že když třeba aktualizuji Gimp včetně pluginů, a stávající instance staré verze otevře plugin z nové verze, tak to nutně musí fungovat? Nebo máte nějaký podobný mechanismus pro resources? Tipnu si: prostě spoléháte na to, že to nějak dopadne.

teď chcete restartovat, což je pod minutu.

Určitě. A pak sis vytáhl ruku z nočníku. Ještě jsem neviděl Windows server, který by se restartoval pod minutu. Natož při aktualizaci.

Nebo jste je nenainstaloval, a instalují se během restartu. Pak to samozřejmě může trvat déle.

Nikoliv. Během restartu se instalují prakticky vždy, jak už jsme si mnokohrát rozebrali, naposled zde, což ti ovšem nijak nebrání v dalším bezuzdném žvanění.

Budete se divit, ale naprostá většina slušně napsaných programů pozná, že s tím pluginem nemohou pracovat a nenatáhne ho. Dál je na Linuxu vyřešena koexistence starších a novějších verzí (číslo verze je součástí názvu příslušných souborů), takže tam mohou zůstat i ty starší pluginy a smazat se až se smaže starý GIMP (a ty GIMPy mohu mít vedle sebe ve více verzích, pochopitelně, taky; ale ne na woknech).

A resources máte také verzované? BTW vyrobit problém a nechat jeho řešení na autorovi aplikace je cesta, jak přivést uživatele do neštěstí.

Ad GIMPy mohu mít vedle sebe ve více verzích, pochopitelně, taky; ale ne na woknech - nechce se mi to zkoušet, ale proč by to nemělo jít?

Nevím, čemu říkáte "resources". Pokud tím myslíte zdrojové kódy, tak ty, pochopitelně, verzované jsou.
Nevím, proč by mě měl přivést do "neštěstí" systém, který garantuje bezkonfliktní spolužití více verzí SW na jednom HW.

U těch win se většinou, pokud se pamatuji, instalují soubory, které už číslo verze v názvu nemají, takže se to tlouct může. Proto taky instalační exe zpravidla maže starší verzi programu.

Připomínám, že třeba takový Excel má problém otevřít i dva soubory z různých adresářů, pokud se jmenují stejně. Zrovna včera jsem musel v práci jeden an 10 minut přejmenovat... :Q

A ty po nich chceš, aby dokázali spustit dva různý exáče... Přiznej se, že ty jsi pil?

Ad Excel má problém otevřít i dva soubory z různých adresářů, pokud se jmenují stejně - o je dané historicky objektovým modelem. Kdyby ho MS změnil, přestala by fungovat spousta maker. Nicméně přejmenovávat soubor je trochu lameřina, když si můžete pustit dvě instance Excelu.

je dané historicky objektovým modelem. Kdyby ho MS změnil, přestala by fungovat spousta maker.

To by bylo neštěstí srovnatelné s nárazem komety a vyhynutím dinosaurů. Lemplové.

Na Excelu běží, řečeno nadsazeně, půlka známého vesmíru. Takže by to byl průšvih.

Resources jsou řekněme součásti aplikace, které netvoří kód. Bitmapy, ikony, fonty, texty, datové tabulky atd.

Ad proč by mě měl přivést do "neštěstí" systém, který garantuje bezkonfliktní spolužití více verzí SW na jednom HW - tak si zkuste nastudovat, co je race condition. Třeba se vám to podaří pochopit, a přečte si znovu o co jsem vám psal dříve. Zamykání souborů je právě tak věc, která umožňuje aplikacím na jednom stroji spolupracovat bez problémů.
http://en.wikipedia.org/wiki/Race_condition

"To si musíte vybrat. Buď jste nainstaloval aktualizace a teď chcete restartovat, což je pod minutu."

Na to už se nedá napsat ani LOL, tohle je prostě žvást.

"co tomu problému na Linuxu předchází?"

Třeba se používá verzování. To na widlích neznáte? Nebo se update sdílených částí provede až při restartu služby/aplikace. Tohle je asi taky pro vás nepředstavitelné. Dokonce se to na kritických systémech dělá tak, že se používají paralelní systémy, kdy jeden běží, duhý se updatuje a pak se to překlopí. Mechanismů je víc. Spoléhání se na to, že to bude fungovat, je spíš doménou widlí.

M$ na widlich neumi ani zaridit, aby byly v systemu jeho vlastni dllka, proto si 80% softu sebou taha vsemozny distributable balicky, takze instalujes 10s aplikaci a dalsi 1/2 hodiny tyhle sragory, ktery si uz trebas 10x instaloval, ale to si M$ neumi ani zjistit.

Ad se update sdílených částí provede až při restartu služby/aplikace; paralelní systémy, kdy jeden běží, duhý se updatuje - obojí samozřejmě můžete dělat i ve Windows. Používá se to často u serverových aplikací. U MS Office to jaksi postrádá smysl, protože ten minutový restart nikoho nezabije.

Ad na to už se nedá napsat ani LOL, tohle je prostě žvást - samozřejmě záleží na HW. Na mém desktopu i notebooku je reboot vždycky hluboko pod minutu, a s aktualizacemi v naprosté většině případů.

Tak minutový nebo hluboko pod minutu? Hluboko pod minutu má restart např. desktop PC, které jsem instaloval zrovna pro kolegu - AMD Kaveri se starším SSD. UEFI + boot do grafiky od ZAPNUTÍ PC: 8 sekund, restart 11 - 12 sekund - Debian GNU/Linux. U Windows na stejném HW nedosažitelná meta i se zapnutým Ultra Fast Boot nebo jak se ta featura jmenuje (stejně to ušetří jen cca 2 s oproti Fast Boot a lepší je to nepoužívat, protože pak to neinicializuje ani USB klávesnici při startu, takže v Grubu není možné vybrat).

No a na linuxu se to používá vždy.

"Na mém desktopu i notebooku je reboot vždycky hluboko pod minutu, a s aktualizacemi v naprosté většině případů."

Jak jsem psal výše, Brouk Pytlík :-)

Spíš jeho RAMka vždycky dostane vnuknutí, co v ní má být, ještě před tím, než začne přistupovat na disk. Asi nejaká telepatie z Redmondu...

Redhat 5.1 - wiki píše release date 22.5.1998 . Opravdu je tohle relevantní?

Ubuntu 14.10 - proč používáš testovací bety nových funkcí, kde se na stabilitu ani podporu nehraje? To se nedivím, že pořád řešíš nějaké problémy.

Mne nevadi, ze som mal nejaky problem s prvym alebo poslednym distrom. Ale to, ze podobne muchy malo skoro vsetko medzi tym (co da tyka cisto desktopu). Mal som aj lepsie chvilky ale celkovo od 1998 (to som uz taky stary?) nic moc.

To nepochybne. Su napr. ludia ako ja alebo autor clanku, ktori take veci nakoniec prehryznu.

To vizelo loliku, nahledy na obrazky do thumb.db si generuje rozsireni exploreru ... lol. A proto je k nalezeni na netu 3/4M stranek na tema, jak to vypnout.

Drahý Jeronýmku, náhledy generuje shell za použití COM komponenty, která exportuje interface IThumbnailProvider. COM komponenta třetí strany, která má generovat thumbnail, může samozřejmě leaknout handle nebo ztuhnout. A protože například codec packy píšou prasata (nakonec je to open source), často kód zmrší.

Popis interface:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb774614(v=vs.85).aspx
Příklad thumbnail handleru
https://code.msdn.microsoft.com/CppShellExtThumbnailHandler-32399b35#content

Další nepovedenou shell extension je například TortoiseSVN.

Co je nepochopitelného na tom, že když někdo zamkne soubor, tak je zamknutý? Vypínání stroje bych do toho netahal, seklá extension nejvýš zpozdí shotdown Exploreru a uživatel ho pak odstřelí na logoff screen.

Ad zavru explorer, mel by si ten byt schopen sestrelit procesy, ktere si pustil - jsou to knihovny, nikoliv procesy. Explorer by je měl ukončit i pokud jsou seknuté, ale nebudu to kvůli vám testovat. Pokud by je neukončil, odstřelíte Explorer na logoff screen. Tu samozřejmě vidíte i přes RDP, takže ušetříte za gatě a košili. BTW server můžete vypnout vzdáleně i bez GUI. A pokud by snad všechno sehlalo, zavoláte někomu kdo je poblíž serveru, ať na chvíli podrží ten power button.

Loliku, ZADNA komponenta treti strany NEEXITUJE, to je jen tvoje fantasmagorie.

Ehm??

"Restartovat kvůli tomu celý server je lameřina"

... a restartovat kvuli widnows update vam jako lamerina vazne neprijde ?? :D

Raději ani nebudu komentovat "spolehlivost" restartu IIS v podobném stavu. Různé pokusy s iisreset a net stop samozřejmě vychcípnou na timeout, čímž se služba dostane do nedefinovaného stavu, kde už na žádné další příkazy nereaguje, akorát vyhazuje chybové hlášky. Pak ještě můžete strávit dlouhé chvíle pokusy o ruční zabití procesů, no a nakonec skončíte stejně u toho rebootu.

Pokud pokusy o restart IIS lehnou na timeout, reboot by proces prostě po dvaceti sekundách odstřelil. To samozřejmě můžete udělat i bez rebootu. Tedy pokud nejste na nějakém Unixu, a nesnažíte se odstřelit zombie proces :)

Opravdu se bavím. Např.

- http://forums.iis.net/t/1183454.aspx?IIS7+Problem+w3wp+exe+process+that+wont+be+killed

- http://serverfault.com/questions/589515/cant-close-iis-worker-process-cant-soft-restart-windows

Zjevně s tím máš hovno zkušenost, tak nemudruj.

Jak už někdo psal, vy a kolega "j" se vyjadřujete jako řidiči hovnocucu. Pokud vám rodiče nedali základy slušného vychování, zkuste alespoň respektovat podmínky diskuse. Máte je napsané pod formem, do kterého příspěvek píšete. O vulgarity v diskusích tu nikdo nestojí. Jestli se podle toho neumíte zařídit, tak do diskuse raději nepřispívejte.

V popsaných případech bych si tipnul na problém s antivirem. Zvlášť kombinace antiviru, SMB a přerušení toho SMB spojení může dělat problémy. Prvním krokem by byl pokus o reprodukci problému bez antiviru. Pokud se problém nevyskytne, poradí support autorů antiviru. Pokud se problém přesto opakuje, doporučuji MS support ($259 US per incident, if the analysis reveals that a customer’s problem was the result of a product bug or defect, Microsoft will refund the cost of the support incurred). Samozřejmě také můžete vzít debugger a pustit se do práce sám.

Copak, uz ti z tech tvych blabolu vyschlo? Jestli tu nekdo o neco nestoji, tak o tvoje blaboly.

Myslím že pořád řádově lepší, než ty nesmysly co tu plodíte vy.

doporučuji MS support ($259 US per incident

Tak ten byl dobrej!!! :-)))

Pokud se sekne interaktivní aplikace, Windows se zeptají. Servisy se po timeoutu prostě ukončí, ovšem mohou požádat o víc času.

A nekdy si navic pro ten reboot budes muset "dojit fyzicky", protoze ani shutdown -f ti nepomuze. Jeste ze virtualy lze vypnout natvrdo, a u fyzickyho zeleza na to mam karty (ktery nastesti nebezej na widlich).

Když už se tady bavíte o procesech, pár dní zpět jsem zažil něco, o čem tady LO blábolil posledních pár let, a to "OOM Killer" v praxi, ovšem na widlích :-D

Mám 4 GB RAM (víc bohužel do svého NTB nenacpu) a zapnutý swap s velikostí přes 6 GB. Měl jsem spuštěno dost aplikací (pochopitelně bez virtuálních ploch opruz), dělal jsem na větším projektu. Najednou mi začala vyskakovat hláška, že widlím dochází paměť (WTF?) a že mám ukončit proces XYZ. Koukám, že zabráno bylo tak 3,8 GB, žádná aplikace neměla přes 1 GB. Tak jsem to ignoroval, přece mám poměrně velký swap, že. No a najednou LUP a widle mi bez ptaní shodily Eclipse. Tomu říkám progresivní přístup :-D Swap je na widlích asi jen pro parádu.

Dodatek k virtuálním plochám, pro které prý mají widle podporu: nedávno jsem opět vyzkoušel, zda by nebylo něco použitelné, no a... nebylo.

Zkoušel jsem nView - ubohost, některá okna to zobrazovalo na všech desktopech, i když jsem nechtěl, jiná se naopak nechtěla zobrazovat všude, i když jsem chtěl, přepínání ploch tristní, vždy jsem musel čekat, než se znovu vykreslila všechna okna... nepoužitelné. No, možná tak do 5 aplikací, ale to zase nepotřebuju virtuální plochy :-)

Ještě jsem vyzkoušel Dexpot, prý nejoblíbenější aplikaci. Je pravda, že to bylo o něco lepší, než nView, ale jen do doby, než mi zčernala všechna okna, respektive černé byly obsahy většiny stávajících a všech nových a to včetně tlačítek min-max-off v liště. Černý byl i spodní toolbar včetně start menu :-D Jediné řešení byl násilný restart power buttonem.

Mam uzasne zazitky s dvoumonitorouvou konfiguraci. Bomba je predevsim se k tomu pripojit pres RDP. To pak takhle spustis nejakou funkci, vyskoci na tebe dialogovy okno, jenze ono vyskoci na tom "druhem" monitoru, ktery pres RDP jaksi nevidis.

Takze zkouset vic virtualnich ploch bych se asi neodvazil.

Java má špatný memory management, vyžaduje souvislý paměťový prostor. Navíc má nastavenou maximální velikost poolu. Eclipse měl svého času tuhle hlášku:
https://s3.amazonaws.com/dfc-wiki/en/images/e/e8/Ide_OutOfMemoryError.png

Ad widle mi bez ptaní shodily Eclipse - to je nesmysl. Když se nedostává paměti, Windows prostě aplikaci nepřidělí další paměť. Je na aplikaci, jak se s tím popere.
Podle všeho u vás měl Eclipse nějaký resource leak, který sežral celý Java pool, a způsobil pád aplikace.

Ad mi zčernala všechna okna, respektive černé byly obsahy většiny stávajících a všech nových a to včetně tlačítek min-max-off v liště - tohle je většinou výsledek memory corruption, nějaká aplikace vám přepsala offscreen buffer(s), například nějakým shaderem. Alternativně to může být problém driverů grafické karty.

Ad Java memory management - nevím jak to vypadá dneska, ale na 32-bitových Windows byl s Javou dost problém právě z toho důvodu, že adresní prostor aplikace musel být souvislý. Nejde o omezení Windows, ale Javy.
OS běžně přiděluje paměť nesouvisle, mimo jiné protože v adresním prostoru aplikace jsou knihovny. Aplikace chce 64kB paměti, dostane na ně pointer. Je jen na OS, kde v adresním prostoru aplikace ten nový blok je.

Z prezentace IBM:
Java Heap:
Allocates max heap on startup
Occupies contiguous memory
Allocates Java objects in contiguous memory
vizte třetí slide tady: http://www-01.ibm.com/support/docview.wss?uid=swg27019232&aid=1

Na normalnim systemu pridelim aplikaci klidne ram v rozsahu 0 - xyz jako jediny kontinuum presto, ze to bude 80 bloku rozhazenych vsude mozne, realne totiz vubec nepotrebuje vedet, kde to misto je, protoze to je vec toho systemu. Ale to ti uz taky bylo receno.

Ad na normalnim systemu pridelim aplikaci klidne ram v rozsahu 0 - xyz jako jediny kontinuum - to je samozřejmě nesmysl. Aplikace mají v adresním prostoru knihovny, takže ten adresní prostor není (resp. nemusí být) souvislý. Většině aplikací je to jedno, protože paměť alokují postupně podle potřeby. Javě od Sunu ne, protože na rozdíl od většiny ostatních aplikací natvrdo vyžaduje (vyžadovala) souvislý adresní prostor. Ale to už jsem psal, a dokonce linkoval.

Asi jste přehlédl, že pisatel na něhož reagujete napsal jasně "na normálním systému" nebo jste nepochopil, že touto informací pisatel vyloučil OS Windows...

On totiz vubec netusi, co je to virtualni pametovej prostor, stejne jako netusi, ze prideliv fyzickou RAM od 0 ani nejde, protoze tam budou ruzny jiny veci. Ale pro aplikaci se to tak klidne jevit muze.

Ostatne, adresovat vic nez 4GB na 32bit systemu to je pro M$ taky cerna magie.

Přečti si k tomu něco. Tam nejde o fyzickou kontinuální paměť, ale kontinuální virtuální paměť přiřazenou jádrem procesu. Win32 XP do poloviny plného rozsahu virtuální paměti pro proces mapují jeho dllka, takže místo něco pod 3GB (32bit OS) si to JVMko mohlo namapovat jen něco pod 1.5GB. Tehdy JVM SUNu potřebovalo souvislý blok (prý měli datové struktury na heapu oindexované a potřebovali souvislý blok (samozřejmě virtuální) paměti pro heap).

Jiné implementace JVM to nepotřebovaly a ta oraclovská už dnes asi taky nepotřebuje. V každém případě na 64bit OS s tím problém není žádný, tam je rozsah virtuální paměti dostatečný.

To je jedna z dalších věcí, u kterých jsem na LO nereagoval, protože z jeho nesmyslných vyjádření k této ryze technické věcí je jasné, jak moc této problematice (ne)rozumí ;-) a připadalo mi to pak jako pověstné házení perel sviním.

To ale nebyla reakce na Laela, ten to psal správně :-)

Co z toho, že zrovna tady o mapování knihoven píše (spíše výjimečně) správnou informaci, když kousek vedle k tomu psal krávovinu? Přijde ti to opravdu broukpytlíkovské - někde chytne nějakou informaci a honem s ní do diskuze aniž by to chápal do dostečné hloubky a šířky. Ale budu si muset dát pozor, kde přesně reaguju i když už je těžké se v té záplavě jeho příspěvků orientovat :-D

Ad kousek vedle k tomu psal krávovinu - kde jsem k té věci psal krávovinu? To že něčemu nerozumíte vy ještě neznamená, že to mu nerozumějí ani ostatní.

"Tehdy JVM SUNu potřebovalo souvislý blok (prý měli datové struktury na heapu oindexované a potřebovali souvislý blok (samozřejmě virtuální) paměti pro heap)."

Myslím, že tahle diskuze vznikla naprosto zbytečně, protože to bylo na W7 x64.

Ad oraclovská implementace to už dnes asi taky nepotřebuje - to jsem hledal a nenašel. Jen nějaká zmínka na blogu o tom, že tahle feature se do JVM7 nedostala. Máte prosím nějaký zdroj?

to jsem hledal a nenašel.

Tak už nic neřeš, nepřepínej a hlavně - po ničem nepátrej

Bohužel nemám a vlastně jsem o tomto problému až dosud vůbec nevěděl. Provozovat cokoliv kritičtějšího nebo důležitějšího na winxp (win obecně) mě nikdy nenapadlo.

Omyl. Pro velikost oblasti paměti tam, pokud si dobře vzpomínám, byla signed proměnná, takže 2GB jsou strop. Ovšem dá se přidělit -1,7GB, to zase neumíme my.

1. Adresní prostor aplikace, tedy to o čem je řeč, je virtual address space, nikoliv physical address space. Mapování virtual address space na physical one je co čemu se říká virtual memory.
Pokud nevidíte problém, tak to zkusím vysvětlit v dobré víře. Knihovny jsou v adresním prostoru aplikace. Pokud máte hypoteticky 2GB adresního prostoru aplikace, a knihovny se v adresním prostoru nacházejí na 0.5GB, 1GB a 1.5GB, tak největší souvislý blok paměti nebude větší než 0.5GB. Příklad je pouze ilustrativní, ve skutečnosti se knihovny v adresním prostoru rozmisťují trochu jinak.
2. prideliv [sic] fyzickou RAM od 0 ani nejde - víte jaký je rozdíl mezi souvislým blokem paměti a blokem začínajícím na adrese 0? To první znamená "nepřerušovaný", to druhé "začínající od nuly", a fakt to není totéž.

Přesně v těchto případech se ukazuje, že nemáte nejmenší představu o čem mluvíte.

A proč jsou ty knihovny takto rozházené a nejsou pohromadě v jednom bloku?

Buďto kvůli bezpečnosti, aby útočník nevěděl, kde tu funkci najít, nebo jim nikdo neřekl, že procesor dokáže hardwarově přehazovat adresy...

Díky. Koukal jsem na rozložení adresního prostoru v linuxu http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory/ , tam jsou mmapy s náhodným offsetem, ale pohromadě v jednom bloku. Výkonově to neumím posoudit.

Jak psal jkolega, knihovny nejsou pohromadě právě kvůli ASLR, tedy proto aby útočník nenašel funkci vždycky na tom samém místě.

Ten link je fajn, ale bohužel vám nedá představu o skutečném adresním prostoru aplikace v reálném provozu. Hledal jsem pro Linux něco jako tu mapu co jsem linkoval pro Windows, ale nenašel jsem.

A nebo http://sinewalker.wordpress.com/2007/03/04/32-bit-windows-and-jvm-virtual-memory-limit/

Viz nahoře. Chlapi, trochu si to nejdřív nastudujte. Laelovi to vyčítáte/me, tak nebuďte stejní.

Ad souvislou oblast virtuální paměti dostane každý proces, který si vyžádá dostatečně velkou oblast voláním malloc(3) - pokud je k dispozici tak velký kus paměti v adresním prostoru aplikace (podmínka nutná, nikoliv postačující).

Adresní prostor aplikace je samozřejmě virtual address space, nikoliv physical address space. Nicméně jsou v něm natažené knihovny (které jsou jak známo in-process), takže heap nemusí být souvislý. Obecně vzato vám každá alokace paměti může vrátit blok začínající v libovolné části adresního prostoru aplikace. Jinými slovy ten nový blok nemusí navazovat na blok který jste dostal při minulém volání HeapAlloc(). Aplikacím to běžně nevadí, protože alokují paměť podle okamžité potřeby. Java je (byla) výjimkou, z důvodu velmi podivného designu jejího interního memory managementu.

Nejlépe se to asi dá demonstrovat na mapě paměti procesu:
http://blogs.msdn.com/blogfiles/tess/WindowsLiveWriter/ShowmethememoryToolforvisualizingvirtua_96C2/image_2.png

Ty hnědé bloky v pravé polovině obrázku jsou DLL v horní části paměťového prostoru, a adresní prostor aplikace fragmentují. I když máte X nealokovaného místa v adresním prostoru, největší souvislý blok má velikost Y, kde Y<X. Na 32-bitových Windows mohla Java získat cca 1.2GB souvislý blok, víc ne. Aplikace alokující paměť v menších blocích mohly alokovat výrazně více.

Ty hnědé bloky v pravé polovině obrázku jsou

... mapa tvého mozku, ale do takových detailů snad nebylo nutné zacházet.

AU! Moje bránice trpí a pes se na mě nechápavě dívá, čemu se furt u té bedny řehtám :-D

Já bych teda spíš myslel, že mapa jeho mozku jsou ty bílé oblasti (v legendě označeny jako FREE) :-D

Já bych teda spíš myslel, že mapa jeho mozku jsou ty bílé oblasti (v legendě označeny jako FREE)

Nene, to je chybějící zbytek obsahu dutiny lebeční... No a zelené oblasti jasně označené "virtual" jsou agitační čipy implantované na marketingovém výplachu mozkovny, bohužel zahrnují jen zacyklený, úzce specializovaný algoritmus s omezenou inteligencí, jak vidno z této diskuse.

Vy jste ale necita neempatický! Ve stavu mé rozbolavělé bránice, namožených břišních svalů a uslzených očí tady pustit takovou věc, způsobující další salvu smíchu! :-D

Tímto žádám redakci o ban pro uživatele Lol Phirae z důvodu opakovaného porušování podmínek diskuse. Konkrétně jde o body 1 a 2. Děkuji, Lael Ophir

Leck mich im Arsch. Děkuji, W.A. Mozart

1. Windows zaserou adresní prostor aplikace dllkama - a jak asi myslíte, že se knihovny používají na ostatních OS? :D Ta míra fragmentace záleží na tom kolik a kterých DLL si aplikace zavede, plus na náhodě (ASLR).

2. Čemu říkáte "cokoliv většího"? Java na 32-bitových Windows limit heap size okolo 1.2GB.
Ad není souvislá oblast - jenže to "normálním" aplikacím nevadí. Nebo vy snad píšete aplikace tak že na začátku požádáte o heap větší než 1.2-1.6GB, a do něj pak cpete všechno? Koukněte se na MS SQL Server nebo Oracle. Když potřebují sort area, provedou prostě alokaci paměti o potřebné velikosti. Jestli te nově alokovaný blok přiléhá k předchozím alokacím je úplně jedno. V Sunu akorát zmršili Javu, nic víc a nic míň. Nakonec i JRockit uměl na 32-bitových Windows 2.5GB heap.

3. JVM alokuje (alokovala) na všech platformách stejně, a všude měla podobné problémy. Podle kolegy Sun předělal memory management Java. Navíc v 64-bitové verzi Javy je adresní prostor daleko větší, takže je to tam celkem jedno.

Ad Gratuluji jak Windows tak JVM ke skvělé práci. Opravdu. Takovou míru diletantství aby člověk pohledal - takže jste se dozvěděl něco o Javě a Windows, a když neznáte situaci jinde, máte potřebu hodit kamenem. Zajímavý jev.

No ale teď jste si naběhl a koledujete si o celou košatou větev v tomhle vlákně, ve kterém vám bude vysvětlováno do omrzení, že Java to (alokaci paměti) dělá(la) stejně (blbě) ve všech OS, protože milý LO se v téhle oblasti cítí velmi kovaný a považuje se tady za odborníka největšího z čehož mu nutně vyplývá závěr, že se pletete vy a je nutné vás o tom přesvědčit a zachránit vás od života v iluzi. Pro tohle svaté tažení je schopen použít jakýchkoli možností, aby dosáhl svého cíle o kterém je bezvýhradně přesvědčen, že je správný (i kdyby se měl cestou dovědět, že je totálně mimo), ať už jsou ty možnosti správné, pravdivé, reálné nebo jsou totálně mimo mísu a ať už mají z tématem jakoukoli souvislost či nikoli, důležitý je totiž jím vytyčený cíl, o kterém ani na chvíli nezapochybuje. Jejda! Já právě teď popsal jak se chovají psychopati! No teda! :-O

Někteří vědí, že Java vyžaduje (resp. vyžadovala) spojitý heap. Ostatní si to mohou přečíst tady:
https://blogs.oracle.com/moazam/entry/why_can_t_i_allocate

Pointa mého příspěvku byla v tom, že jste psychopat a vy začnete o Javě, tím jen potvrzujete pointu mého původního příspěvku :-D

Je pěkné že umíte napsat slovo psychopat. Sice zjevně netušíte co znamená, ale na tom přece nezáleží :)

Ad aplikace VYŽADUJE souvislý prostor, prostě alokuje [velký blok]. A nespoléhá na to, že více různých alokací se trefí zrovna vedle sebe - souhlas, tak se to dělá asi všude. Kde vidíte rozdíl mezi Windows a jinými OS?

Ad na Win32 je pro alokaci signed int - zdroj? Co koukám do dokumentace, vidím tam unsigned __int64 pro x64 a unsigned long pro x86.

Ad cokoliv většího říkám 2GiB - pár MiB pro kód - jak už jsem psal kolegovi, knihovny jsou v adresním prostoru aplikace (na Windows i Unixech), a používají ASLR, což vyžaduje entropii. Jinými slovy nemůžete mít zavedených pět knihoven jednu za druhou na konci adresního prostoru, protože by pak ASLR nemělo smysl.

BTW na co potřebujete na 32-bitovém systému víc než ~1.2-1.6GB souvislý blok paměti? Viděl jsem zatím jedinou aplikaci, která měla tenhle požadavek, a to byla 32-bitová Java od Sunu (buď té firmě země lehká). Všichni ostatní alokují paměť v blocích podle aktuální potřeby.

Ad DB, které používám já používají vaše oblíbené worker process - worker process je proti threadingu výrazně pomalejší.
Ad že to jsou oddělené procesy mohou celkově využít i na 32b více než 4GiB RAM (s PAE) - k tomu snad nepotřebujete worker procesy. Už SQL Server 2000 uměl na 32-bitových Windows pracovat s 32GB RAM, a běžel u toho v jednom procesu.

"a jak asi myslíte, že se knihovny používají na ostatních OS?"

Zkompilují se jako position independent a s pomocí relokační tabulky se připojují kamkoli se to jednotlivým procesům hodí, nejlépe lineárně za sebe. Jak prosté, milý Watsone.
Po pravdě, tak debilně, jako to je ve Windows, to snad nikdo jiný neřeší.

Po pravdě, tak debilně, jako to je ve Windows, to snad nikdo jiný neřeší.

Ty woe neblbni, dyť mu prdne cévka! :-)))))

Ad position independent a s pomocí relokační tabulky... OMG. Position independent code (PIC) je takový kód, který nemá reference na absolutní adresy, a je možné ho zavést na jakoukoliv adresu (pokud zanedbáme alignment). Relokační tabulka se ho netýká.
Problémem v tom, že Intel x86-32 nemá RIP-relative addressing, takže má výsledný PIC dost mizerný výkon. x86-64 má RIP-relative addressing, a Windows ho používá.

Relokační tabulka se týká něčeho úplně jiného. Kód není position independent, a při zavedení se může relokovat. Ve Windows mají DLL preferovanou adresu, na kterou jsou předkompilované a kam se preferuje jejich zavádění, pokud (není použito ASLR) && (v address space procesu je místo). Pokud (je použito ASLR) || (místo pro DLL v address space procesu není volné), knihovna se relokuje na jiné místo v paměti. Na x86-64 se používá RIP-relative addressing, takže je těch relokací minimum.

Ad nejlépe lineárně za sebe - to je fakt super nápad. Slyšel jste někdy o buffer overflow, return-to-libc a ASLR? ASLR vyžaduje nějakou entropii adresního prostoru, nikoliv naskládání knihoven za sebe.

Proč máte tuhle úchylnou potřebu, na webu tématicky zaměřeného na úplně jiné OS, všem tady sdělovat jak (blbě) něco dělají Windows?

Kdybyste věděl o čem je řeč, mohl byste popsat mechanismus na Linuxu, Solarisu nebo jiném systému, a třeba bychom se oba bychom mohli něco nového dozvědět. Jenže to vyžaduje jisté znalosti a zkušenosti, které podle všeho nemáte. Na dohadování se o EULA ovšem samozřejmě kvalifikaci máte :D

Kdyby jste pochopil, že nemám potřebu diskutovat s psychopatem ať už o dané věci vím či nevím cokoli (diskutovat můžu v obou případech, v první něco přispěju, v druhém se něco dovím), třeba by jste toho nechal, že? Pointa je upozornit na to co jste za vyšinutého člověka, ne s vámi diskutovat.

Vaše starost o moji osobu je až dojemná. Faktem je, že k tématu nic nemáte.

Relokační tabulka obecně byla myšlena, to je opravdu trochu obecnější pojem, než si asi myslíte. Konkrétní v tomto případě global offset table. To je jako byste tvrdil, že NTFS nemá nic společného s filesystemem.
ASLR cílí na něco úplně jiného než ochranu před přetečením. Najdete to třeba na smart kartách k uložení klíčů atp.

Jestli ten windowsí brajgl v adresovém prostoru procesů (klidně tomu říkejte "entropie") má cílit na vyšší robustnost a rychlost, tak ovšem musím konstatovat, že se mu to zoufale ne- a nedaří. :)

BTW: Entropie... To zní opravdu lépe než bordel. :D Děkuji za inspiraci.

Abych nebyl brán za slovo - určitě se najdou tací, co by ji mezi techniky ochrany před BO zařadili, ale primárně není a užitečnost v této oblasti je poměrně pochybná.

Ad ASLR cílí na něco úplně jiného než ochranu před přetečením - mluvíme o stejné věci?
http://en.wikipedia.org/wiki/Address_space_layout_randomization

Ad windowsí brajgl v adresovém prostoru procesů (klidně tomu říkejte "entropie") má cílit na vyšší robustnost a rychlost - když o něčem nic nevíte, jsou vaše výroky poněkud mimo. ASLR máte samozřejmě i na Linuxu, a jeho účelem je úplně stejně přidání entropie (nebo chcete-li bordelu ;)) do layoutu adresního prostoru:
http://en.wikipedia.org/wiki/Address_space_layout_randomization#Linux

BTW když hovoříme o Linuxu, tak ten v linkování dynamických knihoven výkonem rozhodně nevyniká. PIC s global offset table fakt není dobré řešení.

PIC s GOT není žádný velký výkonnostní problém, protože se to týká jen statických dat knihoven. ASLR je i na Linuxu, to nerozporuji, jen tvrdím, že praktický význam pro bezpečnost je naprosto marginální, a to bez ohledu, co o tom kdo píše. A to píšu právě proto, že o tom vím přeci jen více, než jen co se dočtete někde na wikipedii.

ASLR samozřejmě má přínos, a navíc je to jen část opatření, která mají zkomplikovat exploit.

"Ad widle mi bez ptaní shodily Eclipse - to je nesmysl."

Víte co, viděl jsem to na vlastní oči 50 cm před sebou, tak mi tady laskavě netvrďte, že je to nesmysl.

"Podle všeho u vás měl Eclipse nějaký resource leak, který sežral celý Java pool, a způsobil pád aplikace."

Ne, nic takového neměl, bežel si v klidu na pozadí bez jakékoliv činnosti.

"Ad mi zčernala všechna okna, respektive černé byly obsahy většiny stávajících a všech nových a to včetně tlačítek min-max-off v liště - tohle je většinou výsledek memory corruption, nějaká aplikace vám přepsala offscreen buffer(s), například nějakým shaderem. Alternativně to může být problém driverů grafické karty."

Mně je úplne jedno, co to způsobilo. Pro mě je rozhodující výsledek a to ten, že jsem musel komp vypnout natvrdo. Nic jiného se s tím dělat nedalo. Výsledek: použitelné virtuální plochy ve widlích je oxymoron.

BTW nic jiného nového kromě toho Dexpotu tam nebylo. Ani se to nestalo po hibernaci nebo zapnutí, prostě přijdu k běžícímu kompu a na monitoru je černo.

To je jednoduchy ...

1) mel si sedej zakal
2) vymejslis si
3) muze za to tvoje klavesnice
4) muze za to tvuj neautorizovany HW
5) muze za to apliakce treti strany
5) muze za to tvoje babicka

Ale v zadnym pripade za to nemuzeou widle, to se proste nemuze stat, protoze widle jsou jedinej naprosto dokonalej kus SW v tomhle vesmiru.

=====
"Podle všeho u vás měl Eclipse nějaký resource leak, který sežral celý Java pool, a způsobil pád aplikace."
=====
Ne, nic takového neměl, bežel si v klidu na pozadí bez jakékoliv činnosti.
=====

OutOfMemoryError je v javě celkem běžná chyba, tady bych opravdu OS nevinil. Daleka větší pravděpodobnost je chyba aplikace, která vyčerpala paměť JVM a ta ji ukončila s OutOfMemoryError. Udělat v kódu takovou chybu je celkem snadné.

Je zajímavé, že Eclipse to sestřelilo zrovna v tu chvíli, kdy systém hlásil, že má nedostatek paměti, nikdy dříve k tomu nedošlo. A taky je zajímavé, že "spadla" zrovna ta aplikace, která měla v danou chvíli zabráno nejvíce paměti a kterou mi widle doporučovaly ukončit. Pár dní zpět mi stejná hláška vyskakovala pro firefox, ovšem tenkrát k "pádu" nedošlo, protože jsem FF aktivně restartoval sám.

Ad Eclipse to sestřelilo zrovna v tu chvíli, kdy systém hlásil, že má nedostatek paměti - a fakt to hlásil systém, a ne třeba JVM nebo ten Eclipse? Jinak paměť aplikace může být označená jako neswapovatelná, pak vám samozřejmě swap nepomůže.

System Windows má nedostatek paměti. Doporučujeme ukončit aplikaci blabla.

"Jinak paměť aplikace může být označená jako neswapovatelná, pak vám samozřejmě swap nepomůže."

Tak se mohlo odswapovat něco jiného. Ze 4 GB Eclipse zabíralo necelou čtvrtinu.

Ad tak se mohlo odswapovat něco jiného - to se samozřejmě mohlo. Pokud ovšem někdo označil dostatečné množství paměti jako neswapovatelné, tak není co swapovat.

Tenhle problém jsem ještě neviděl. Windows ale samozřejmě běžně umí fungovat s alokací paměti větší než RAM, protože od toho tam ten swap je. Takže se někde něco podělalo. Eclipse, jiná aplikace, servis. Samozřejmě to může být i bug kernelu, ale pak by to asi hlásilo víc lidí.

Já to viděl poprvé v životě a doufám že i naposled.

Popravdě, mě jemupřímně jedno, co si myslí LO. Já jsem přesvědčen, že widle mi sestřelily Eclipse jednoduše proto, že zabíraly nejvíc paměti.

Až budu zase na widlích (padla poslední překážka, která mi bránila trvalému přechodu na linux) a budu se nudit, tak to zkusím, protože o pár dní dřív widle řvaly kvůli nedostatku paměti a "doporučovaly" ukončit Firefox, protože tehdy zrovna on zabíral nejvíc paměti. A, jak jsem psal, 6 gigový swap widle bohorovně ignorovaly.

To zcela zjevně není normální chování systému. Procházel jsem s vámi některé možné příčiny problému. Věřte samozřejmě čemu chcete. Akorát upozorňuji, že je dobré si uvěřovat to čemu se rozhodnete věřit. Jinak dopadnete jako pánbíčkáři nebo svíčkové báby :)

Ad Widle swap pouzivaji asi leda tak na to, aby do nej kopirovaly obsah cache - LOL, vy dokážete pobavit.

Ad viděl jsem to na vlastní oči 50 cm před sebou - co jste viděl? To že aplikace zmizla, nebo že Windows odstřelily proces? Ani jedno nijak nedokazuje existenci OOM Killeru ve Windows (a ani nemůže, protože tam prostě není). Znovu upozorňuji, že Java má v konfiguračních parametrech maximální velikost heapu. Pokud ji překročíte, aplikace při pokusu o další alokaci paměti dostane buď null pointer nebo výjimku. Typicky se pak stane jedna z následujících věcí:
A. Aplikace nedostatek paměti korektně obslouží. Vyhodí chybovou hlášku, operace selže, ale jinak se jede dál. To je případ MS Office, MS SQL Serveru, Oracle apod.
B. Aplikace udělá něco jiného, například se okamžitě ukončí.
C. Výjimka není ošetřena, a aplikace sletí.
D. Aplikace zkusí použít null pointer, a sletí.

Ad Eclipse nějaký resource leak, který sežral celý Java pool, a způsobil pád aplikace; nic takového neměl, bežel si v klidu na pozadí bez jakékoliv činnosti - takže resource leak vylučujete na základě toho že Eclipse "běžel v klidu na pozadí"? Ti jste tomu moc nedal :)

Ad Výsledek: použitelné virtuální plochy ve widlích je oxymoron - špatně. Výsledek: daný build Dexpotu a/nebo driverů měl problém.

"Ani jedno nijak nedokazuje existenci OOM Killeru ve Windows"

Já jsem netvrdil, že tam je, proto jsem ho dal do závorek.

Odpověď o dva posty výše. Prostě mi widle sestřelily aplikaci pro nedostatek paměti navzdory velkému swapu.

VirtuaWin ne takový úplný základ a mám dojem, že už ani neprobíhá žádný vývoj. Navíc přepínání ploch spočívá, stejně jako u nView, ve skrývání a zobrazování oken, takže nepoužitelné.

Ad přepínání ploch spočívá, stejně jako u nView, ve skrývání a zobrazování oken, takže nepoužitelné - tohle je přístup, který volí většina implementací virtuálních ploch. Co je na něm nepoužitelné?

To, že opravdu nemíním při každém přepnutí čekat, až se mi překreslí desítky oken.

"tohle je přístup, který volí většina implementací virtuálních ploch"

Jo, na widlích.

Ad opravdu nemíním při každém přepnutí čekat, až se mi překreslí desítky oken - na co byste čekal? Okna jsou v offscreen bufferu, jen se zobrazí. Tedy od Visty výše.

"na co byste čekal? Okna jsou v offscreen bufferu, jen se zobrazí. Tedy od Visty výše.."

Na to, až se zobrazí, postupně po jednom. Ale to je fuk, to zobrazování je jen jeden z problémů.

Zajímavé. Vzhledem k tomu, že se desítky oken běžně dají zminimalizovat a obnovit do původního stavu prakticky okamžitě, tipnul bych si na problém toho VirtuaWin. Pokud například (zbytečně) volá repaint na každé okno, může to při větším počtu oken nějakou dobu trvat, zvlášť pokud jsou aplikace ve swapu. Ovšem i autor ve FAQ uvádí nějaká nastavení s dopadem na výkon.

Tohle je bohužel obecně problém SW který píšou amatéři, a nevěnují dostatek času ladění.

Vždyť jsem psal, že APLIKACE jsiuo nepoužitelné. A dělá to i nView od nVidie. Prostě celé virtuální plochy jsou na widlích úděsné, hlavně pro někoho, kdo je zvyklý na naprosto plynulé přepínání z linuxu, který to zvládne i s animací.

U aktualizací systému by se to i dejme tomu dalo chápat. Někteří ale dokonce místo řešení konkrétního problému radši pokaždé ztratí dva dny kompletní reinstalací Windows a to už mi pochopit trochu problém dělá.

Ještě bych doplnil, že problém je podle italského soudu v situaci, kdy zákazník koupí počítač, až poté má akceptovat EULA, a rozhodne se ji neakceptovat. Technicky přitom není problém EULA nechat zákazníka odsouhlasit na webu při koupi stroje, a pravděpodobně je možné to učinit i před rozbalením stroje.

Ale loliku, ty samozrejme vubec netusis, ze autorske pravo je v EU harmonizovano, a tudiz rozhodnuti libovolneho soudu je pro tento ucel dostatecne. A kupodivu v ramci EU plati dokonce precedencni pravo, tudiz jiny soud by rozhodne nemel rozhodovat jinak, pokud k tomu nebude velmi vyznamny duvod.

Drahý Jeronýmku, autorské právo je v EU harmonizováno jen částečně. Navíc se evropská legislativa musí přenést do lokální legislativy, což nějakou dobu trvá, a členské státy mohou přidat spoustu vlastních úprav, což také ve velkém dělají.

Ad v ramci EU plati dokonce precedencni pravo - jenže dost jinak, než si ho představujete. Soudy členských států nemají přijímat soudní rozhodnutí, která jsou v rozporu s evropským právem. Ovšem rozhodují podle lokálních právních úprav, které mohou být (a jsou) odlišné od evropské legislativy.

Představte si to jako vrstvo národní legislativy, podle které soudy rozhodují. Nad tím stojí další vrstva evropského práva, se kterou nesmí být národní právo v rozporu.

Ještě jednodušší popis: EU může stanovit, že prodej potravin musí probíhat bezpečně a hygienicky. ČR v takovém případě musí do nějaké doby upravit své zákony tak, aby odpovídaly legislativě EU. Přitom může například z vlastní vůle navíc stanovit, že se pečivo smí prodávat jen balené.
Pokud pak někdo v ČR prodá nebalený rohlík, má problém. Nicméně na rozhodování v Itálii to nemá žádný vliv.

Navíc může ČR určit řadu dalších podmínek, které EU nijak neřeší. Například může stanovit, že české produkty musí být v obchodech označeny malou českou vlaječkou a nápisem "co je české, to je dobré".

Pokud jde o rozhodování na úrovni unijních soudů, například ECJ, tak princip právního procedentu neplatí. Samozřejmě ale od soudu lze oprávněně očekávat konzistenci v jeho rozhodnutích.

Je už jasnější, že "rozhodnuti libovolneho soudu je pro tento ucel dostatecne" je nesmysl?

Poznámka pro právníky: pokud se v čemkoliv mýlím, uvítám opravu.

autorské právo je v EU harmonizováno jen částečně
Tento problém s licencemi se netýká autorského práva, ale závazkového práva.

Navíc se evropská legislativa musí přenést do lokální legislativy
To je nepřesné. U některého typu evropské legislativy platí, že její implementace je ponechána na jednotlivých členských státech (typicky jde o směrnice). Ovšem pokud vznikne občanům škoda vinou chybějící či nesprávně implementované sekundární legislativy, může být daný stát žalován u ECJ a navrhovatel s největší pravděpodobností uspěje. V případě nařízení a závazků plynoucích z mezinárodních smluv je jejich účinek přímý a nadřazený národní legislativě. Viz Costa v. ENEL, Francovich v. Itálie...

Ad v ramci EU plati dokonce precedencni pravo - jenže dost jinak, než si ho představujete.
Některé rozsudky ECJ mají jednoznačně precedenční charakter -- např. ty dva výše uvedené mezi ně patří. Nejde v nich o to, že by národní soudy neměly vydávat rozhodnutí jež jsou v rozporu s evropským právem -- to je přece přirozené, že ne. Jde v nich o založení závazné normy, jež před rozhodnutím nikde nebyla konstatována a jež se daným rozhodnutím stává závaznou a má charakter obecného právního předpisu.

A vůbec nejlepší nápad je nacpat blikací matlací dlaždicoidy taky na serverový OS. Protože kro nemá na serveru dotykovou obrazovku, jako by nebyl!

Zapomněls na Win ME, tam byl jako výchozí shell BSOD. :-D