Pod Windows už lze neoficiálně rozběhnout i Arch Linux

Nebo lépe: cup all -y

Kdepak, vyzkoušel jsem Chocolatey, ale to není alternativa k WSL, jde prostě jenom o balíčkovací systém pro Windows a to není to co potřebuju. Na WSL oceňuju, že je to komplet Linuxová příkazová řádka se vším všudy. Nepoužívám přes to žádné aplikace vyžadující Xka, a ani nic co by potřebovalo device files, takže se mně naštěstí žádná omezení které uvádíš netýkají.

systemd-metrod ? ;-)

Virtuální plochy pro mně přestaly být zajímavé v okamžiku kdy jsem si pořídil druhé LCD, do té doby jsem je taky používal. Aktivity jsem nepobral nikdy.

Dokumentace nezmiňuje implementační detaily, které se mohou lišit v dalších verzích, a na které nemáte (a nesmíte) spoléhat.
https://blogs.msdn.microsoft.com/oldnewthing/20160826-00/?p=94185

Ad To pak využití mezi procesy zcela vylučuje - ano, to je snad zjevné z dokumentace.

Ad Linux překládá pro sdílené VMA adresu v jádře na "fyzickou" (typu inode + offset) a hashuje až podle této adresy - nemá moc smysl si z Win32 API vybrat thread synchronization funkci, a vyčítat jí, že není to interprocess synchronization. Windows mají řadu synchronizačních mechanismů různého určení. Třeba Critical Section Objects, které propadají na kernel space až pokud je třeba. Pak jsou tu (celkem nové) Slim Reader/Writer (SRW) Locks, condition variables, one-time initialization, interlocked variable access atd.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms681924(v=vs.85).aspx

Ad celý současný návrh jádra Windows vylučuje jakékoliv uvažování o použití v řídicích aplikacích a kdekoliv, kde na časování záleží - Windows NT nejsou RTOS. Ovšem kernel Linuxu se svými gigantickými locky (svého času včetně BKL), overcommittingem a dalšími features na tom také není nic moc. Ve Windows můžete použít například RT extension IntervalZero RTX, nebo jsou tu Windows CE.

Ad neuvěřitelně nízká technologická úroveň mnoha řešení ve Windows - nějaké konkrétní příklady? Zatím jste si akorát vybral jeden synchronizační mechanismus, a srovnáváte ho s úplně jiným mechanismem na Linuxu.

Ad v dnešní době je pro využití výkonu nutné implementovat mnoho algoritmů vícevláknově - to jistě ano. Proto nechápu, proč řešíte synchronizaci procesů a nikoliv threadů.

Ad Z měření a testů různých projektů, které nakonec kvůli uživatelům přidávají port pro Windows vyplývá, že WaitOnAddress má nejmenší overhead - to mě zajímá. Máte k tomu nějaké zdroje, nejlépe týkající se srovnání výkonu Win32 sync primitiv? Mimochodem uvědomte si ale že každé z těch primitiv má jiné výhody a nevýhody. WaitOnAddress je rychlý, ale má to svou cenu jinde.
Ad NtWaitForKeyedEvent - to je použité mimo jiné v SRW Locks

Ad implementace kritických sekcí se několikrát zásadním způsobem ve Windows nepovedla - byla poplatná své době. Mimochodem v té době jste ještě na Linuxu neměli ani funkční threading, s tím že LinuxThreads za funkční opravdu nelze považovat. A z toho jak je threading do kernelu dopatlaný asi musí vstávat vlasy hrůzou každému. Nejpřiléhavější popis, který mě napadá, je refactoring kladivem, bruskou a lepicí páskou.

Ad dreaded "out of memory" exception; z pohledu determinizmu katastrofa - a jako alternativu byste doporučil Linux, který "deterministicky" lže o úspěšné alokaci paměti (overcommitting), a když ta lež praskne, tak náhodně odstřeluje procesy (OOM Killer)? Většina OS má problém když dojde na OOM, ale zrovna Linux je na tom velmi špatně.
Ad další berlička s mnoha voláními do jádra, která jen zajišťuje to, že původní pomalá volání půjde použít bez padání aplikace - se kterými mnoha voláními? Sám jste linkoval: CriticalSection API... similar to mutexes on pthreads in Linux, has a fast-path where no transition to kernelspace via a system call is needed. Critical Section Objects se časem zrychlily, ale problém je v tom, že vývojáři hrabali na nedokumentované části struktury. Kvůli tomu nezrychlily tak jak by mohly.

Ad základ jádra je napsaný celkem dobře a po aplikaci RT patchů... - které jsou tuším nepodporované... Navíc píšete o 350us. S RTX se na Pentiu dostanete na worst-case 2-30us, podle HW. Plus RTX běží i pokud jádro NT z nějakého důvodu spadne.
Ad RTX... bez náhrady HAL alternativním jádrem OS, ještě k tomu uzavřeným, které pouští RT tasky mimo plánovač Windows a vlastně z Windows dělá jen paravirtualizovanou doménu pro nepodstatné úlohy a správu - RTX HAL nenahrazuje, ale rozšiřuje. Všimněte si, že není potřeba změna jediného řádku zdrojáku NT, ani jeho nový překlad. NT tasky se pak používají pro úlohy, které nejsou časově kritické. Netvrdil bych že jsou "nepodstatné", nebo že jde jen o správu.

Ad Linux již mnoho let používá tam, kde to lze, mechanizmy Read Copy Update (RCU), které přispívají k řádovému zvýšení propustnosti. RCU mechanismus je k dispozici i jako knihovny pro user-space http://liburcu.org/. Dohodlo se již MS s IBM na poskytnutí patentů k této technologii vyvinuté v rámci vývoje jádra Linux tak, aby konečně začalo nabízet tento mechanizmus i v rámci MS WIN a NT API? - lock-free synchronization techniques se ve Windows používají dlouho, například ve Vistě se zvyšoval počet míst kde jsou použity. Ohledně API: Win32 nabízí Interlocked Singly Linked Lists, pro C++ je tu Parallel Patterns Library, .NET má Concurrent Collections. O dohodě mezi MS a IBM nevím, ale nevylučuji že existuje.
https://msdn.microsoft.com/en-us/library/ms684121%28VS.85%29.aspx
https://msdn.microsoft.com/en-us/library/dd504870.aspx
https://msdn.microsoft.com/en-us/library/dd460718(v=vs.110).aspx

Ad s tím Futexem na WIndows, chodí alespoň ten ve WSL mezi procesy - pokud máte na mysli SRW Locks, tak ne. Ve Windows se používá multithreading. Na Unixech sice také zjistili že existují thready, a dokonce konečně existují použitelné implementace i mimo Solaris :), ale autoři kódu to asi ještě nepostřehli.
Ad Běží v této oblasti nějaký vývoj - pochybuji, bylo by to jako vyvíjet podporu děrných štítků. Ale můžete použít events, mutexes, semaphores, timer objects, a samozřejmě Interlocked API.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms684122(v=vs.85).aspx

Mimochodem produktivnější než ptát se mě, který se C/C++ vyhýbá jak může, je obrátit se na dokumentaci nebo knihu Windows Internals. Tohle je šesté vydání, sedmé bude vycházet teď na podzim. Okolo stran 180-210 se řeší synchronizace.
http://materias.fi.uba.ar/7508/WI6/Windows%20Internals%20Part%201%20(6th%20Edition).pdf

Moj ty Boze! Spolu s Michaelom Kocabom volam: "Tak to uz je moc! To je snad zlej sen!"

To je zdejsi M$ maskot lulan, tomu se widle patchujou 3s, a bootujou za 1s. Restart je pak jedinej zpusob jak patchnout opice, a je to zcela vporadku ... ;D

Jestli se chces vazne kralovsky pobavit, tak si pohraj s tim jejich XP modem ... to sou totiz defakto virtualni XPcka, a presne podle toho se to naprosto demente chova, a to co ti nejede jinde v tom stejne nezprovoznis. Napriklad pokud to mas v domene, tak to znamena, ze musis mit v domene i ty XPcka a chova se to jako dalsi PC ... vcetne nutnosti to administrovat ... lol. A samo neustale to pada a pada a pada, takze kdyz si nahodis vmware player, tak to jednak pobezi, druhak to nerezesere materskej system a zatreti to budou realny XPcka, takze na nich pobezi presne to co na XPckach.

BTW: Uz sem mel v ruce asi 50 stroju, ktery byly po instalaci win10 zcela nefunkcni ... protoze nemeli sit. Ti curaci v M$ neumej integrovat drivery ani pro ty nejbeznejsi sitovky na trhu ... ani toho blbyho realteka kterej je vsude to proste nenajde. lol

Nejmin 15 let se mi nestalo, ze by tux nenastartoval a nemel sit. A to vcetne vsemoznych obskurnich kousku HW, u kterych sem ani nedoufal, ze by to mohlo chodit.

Ad tomu se widle patchujou 3s, a bootujou za 1s - tady si zase někdo vymýšlí

Ad si pohraj s tim jejich XP modem - ten jsem nikdy nepoužíval. Navíc je určený pro Win7, ne Win8/10. To VHDX se dá použít v Hyper-V, a nevidím důvod, aby to padalo jinak nebo víc než ve VMware.

Ad Uz sem mel v ruce asi 50 stroju; curaci v M$ neumej integrovat drivery ani pro ty nejbeznejsi sitovky na trhu - hmm, a co si třeba driver přidat na instalační média? Neumíte? Aha.

Ad Nejmin 15 let se mi nestalo, ze by tux nenastartoval a nemel sit - zato já pravidelně řešil problémy s WiFi, které nikdy nefungovalo jak by mělo. Většinou vůbec, jindy po dlouhém přemlouvání (stahování, kompilace) a s hromadou problémů včetně tuhnutí systému.

@ j

Zrovna včera jsem známé na notebooku s win 10 řešil, že jí nešel zvuk. Na latopu přes fn - zaplý. Na liště ikonka - zaplý, ovladač hlasitosti byl na max, zařízení reproduktor - vybráno. Sranda. Takže vyhledat potíže - ono to občas od win7 pomůže a taky je to jednoduší než hledat na MS nějakou radu typu přeiinstaluj ovladač. No a jak to dopadlo? Dám vyhledat potíže a ejhle: zařízení -> sluchátka. Úplně něco jiného než ukazuje v nastavení. Ok, pár dementních otázek průvodce, ale pomohlo. Po restartu zase nastavené debilně na sluchátka. A víš co je sranda? V tom NTB nikdy sluchátka nebyly - Nikam ho nenosí a sluchátka nemá :-D To je výkon. Člověk by se i zasmál, resp. zasměje, ale jinak je to k pláči. Takové školácké a laciné chyby v OS . . . .

Buď driver, nebo zdířka sluchátek. Ty zdířky typicky detekují vložení konektoru pomocí spínače. Je to mechanicky titěrné, a často to odchází, takže pak zařízení trvale chybě indikuje, že jsou připojena sluchátka. Ale v mlze je jasně vidět, že to není chyba driveru ani HW, ale OS :D

konektor odchazi kdyz se casto pouziva, nikoliv kdyz uzivatel nema, nepouziva sluchatka a nikdy je do toho konektoru nezasunul
...
kdo podle tebe muze za to ze se Windows chtej a (a beznym uzivatelum i automaticky) restartovat? OS nebo slot na ExpressCard?

Ad konektor odchazi kdyz se casto pouziva, nikoliv kdyz uzivatel nema, nepouziva sluchatka a nikdy je do toho konektoru nezasunul - konektor častěji odchází, když se používá. Ve skutečnosti nevíte jestli ho uživatel (nebo jeho kolega, partner/ka, děcko) použil. Konektor samozřejmě může odejít i pokud se použije jen jednou, a otázka je, jestli je potřeba alespoň to jedno použití. Takže závěr je ten, že to může být driver nebo konektor, s tím že konektor jste nevyloučil. Chápu že vy máte předpřipravený závěr, který pak "vidíte v mlze". Já radši fakta, než abych věřil nesmyslům.

Ad kdo podle tebe muze za to ze se Windows chtej... restartovat - a co si o tom myslíte vy?

"Ve skutečnosti nevíte jestli ho uživatel"

Vím, dotyčný NTB by totiž do nedávna můj a kupován byl nový. Takže
"Chápu že vy máte předpřipravený závěr, který pak "vidíte v mlze". Já radši fakta, než abych věřil nesmyslům."
e zase další <|> z té tvojí huby o věcech o kterých ho.no víš. Ale drze rýpat, to jo. Se divím, že radši nesedíš na podpoře MS a neradíš každému ať přeinstaluje drivery nebo rovnou OS.

" Buď driver, nebo zdířka sluchátek. Ty zdířky typicky detekují vložení konektoru........ že jsou připojena sluchátka. Ale v mlze je jasně vidět, že to není chyba driveru ani HW, ale OS :D"

Až na to, že to v nastavení ukazuje ty reproduktory, takže buď to správně identifikuje pokažený konektor jako sluchátka a debilně zobrazuje v nastavení, nebo debilně identifikuje konektor ( je teda ale chybný ) a správně zobrazuje v nastavení. V obou případech je to špatně. Na tom je hezky vidět, že logické myšlení a chápání psaného textu nezvládáš a v hlavě máš nas..no . . . To je přesně to, co předvádíš pořád. Link si najdeš (informaci) ale zpracovat ji a začlenit do problematiky nebo života tak, abys nebyl za debila, to už nedokážeš.

No jasně, konektorem to být nemůže, protože notebook byl "do nedávna [váš] a kupován byl nový". To že to není konektorem prokážete buď tak že najdete jinou příčinu (klidně to může být ten driver, nebo i něco jiného), nebo tak že testem vyloučíte, že by to byl konektor. Problém jste sice podle všeho zatím nevyřešil, ale už víte, že já mám v hlavě nasráno, když upozorním, že to může být i konektor. To svědčí jednak o tom že nechápete ani triviality, a pak (což je zásadnější) o tom že jste nevychované vulgární hovado, jedním slovem lůza. Takže za mě: naučte se slušnosti, nebo jděte do hajzlu.

"No jasně, konektorem to být nemůže, protože notebook byl "do nedávna [váš] a kupován byl nový". To že to není konektorem prokážete buď tak že najdete jinou příčinu "

Jsi idiot? Já ti nenapsal že to není konektorem ale že vím, že se nepoužíval, protože jsem ten notebook měl skoro celou jeho dobu já. Jak jsem psal. Ani psanému textu nerozumíš, tak se nepouštěj do nějakých rozborů, vole. Samozřejmě že mě to s tím konektorem nenapadlo (protože ho nikdo nikdy na tom ntb nepoužíval) a ani jsem neveděl že takové chyby mohou vzniknout a samozřejmě že to vyzkouším nebo otestuju - a to proto, že neodsuzuji informace jenom proto, že je vyřkne nějaká <|> ale třídím je podle toho, jaké jsou a jakou mají hodnotu a začlením je do rozhodování. Tak jak ti to celou dobu píšu. Pak se po takových výlevech a 0 chápavosti a volovinách co třepeš nediv, že ti člověk nadává nebo píše sprostě, protože jinak absolutně nezapojuuješ tu palici ani trochu . . .

Jste lůza a děláte z diskuse žumpu. Naučte se slušnosti, nebo běžte do hajzlu. S přátelským pozdravem, Lael

No ty mě tak budeš poučovat, takové jelito . . .

Ad "Tak to uz je moc! To je snad zlej sen!" - přesně to jsem si říkal, když jsme ten VMware řešili :)