Názory k článku Revoluce: Microsoft vydává DirectX pro Linux (ale jen pro Windows 10)

to uz by bylo lepsi kdyby vzali nejake unixove jadro s licenci co by microsoftu vyhovovala, pridali vlastni ovladacovou strukturu do jadra a meli k tomu unixovy i svuj windowsovy userspace.
to by byla bomba winapi nad unixovym kernelem :-)

A co z toho? Co z toho pro ně? Co z toho pro nás?

bylo by to pouzitelne narozdil od WSL, kde temer nic nefunguje.

souhlas. nebo opustit operacni system a delat jen office, c#, azure, visual studio a kompiler pro linux :-)

Něco málo jste vynechali, pánové: pro začátek kompletní Active Directory včetně GPO.

Pokial by chceli ist 15 rokov naspat do minulosti, tak asi ano. Inak kombinacia AD a kratko zijucich kontajnerov alebo k8s podov je smrtelna; pripajat a odpajat ich do/z domeny je tak otravna cast, ze sa nikto neobtazuje.

A ked ich nemate na serveroch, tak naco ich mat na klientoch? Plus su tu mobilne zariadenia, ktore tiez treba nejako manazovat, podporu AD+GPO nemaju, a tak aj Microsoft ma na to Intune.

Případně Microsoft Exchange Server. ;-)

Jšetě před Interixem bylo to ve Windows NT toto:

https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem

Ono je to presne naopak.
Uz cez 10 rokov sa tu na roote fnuka, ze Microsoft opusti Windows a prejde na linux, alebo ze Windows pobezi na Linuxe.
No dnes je stav presne opacny, existuju linuxy beziace na Windowse.

A tym normalny clovek straca potrebu instalovat nejaky linux ako primarny OS.

Aby som parafrazoval tvoje "Lol" - myslis ten oparcny system co ma stale problem z HW?

[oss]
Nepovidej. Muzes dodat podklady, ktere jsou vylozene vinou os a ne vyrobce ci neznalosti uzivatelu?

Ano presne ten, jmenuje se Windows. Mezi verzema typicky prestavaji chodit zarizeni jako karty pro video, skenery. V soucasne dobe to dotahuje vyrobce do excelentiho stavu, kdy vam prestane chodit touchscreen, touchpad, grafika - jen tak z niceho nic, protoze novy build.

Dekuji, nechci :) Jedu linux, ktery podporuje veskery - i novy - HW ktery mam mnohem efektivne, a hlavne beze zmeny instalace poslednich 15 let!

Lol. Myslis destiky, ktere dokazou ze slabsiho notebooku udelat nepouzitelne zarizeni a ktere libovolna nahodna distribuce strci do kapsy? Tak to potom jo..

Myslím, že výkon počítačů roste rychleji, než nároky operačních systémů. Dnes už hodně lidí nemá nejmenší problém s Hyper-V / WSL ani na laptopu a v budoucnu to bude úplná marginálie. Podobné obavy panovaly i v minulosti, můžu vzpomenout na přechod 16=>32 bit, poté 32 bit subsystem v 64 bitových Windows. Nyní je tato obava jako přes kopírák, jen je předmětem WSL2.

Vždy zůstanou existovat uživatelé, kteří budou preferovat Linux. Buďto právě kvůli výkonu, který si nemohou dovolit, nebo prostě Windows potřebují velmi okrajově, nebo třeba i z filozofických důvodů. Tyto kroky ale skutečně rozšiřují počet těch, kteří nezávislou instalaci Linuxu potřebovat nebudou.

Kdysi jsem měl dva OS. Windows a Linux jako multiboot. Pak mi ta potřeba ochabla, vystačil jsem si s Windows a Linuxem na serveru (některé operace jsem dělal přes SSH). Díky WSL mi ochabuje i tato potřeba.

Na nástrojích produktivity jsem poměrně dost závislý na Microsoftu. Už jen "obyčejné" Active Directory, Echange server + Outlook nelze moc pohodlně nahradit v Linuxu. Takže mně (a asi i dalším) přijde jednodušší (efektivnější) používat WSL2, než do Linuxu lámat to, co mi tam chybí.

Otázka distribucí - tady to taky vychází příznivěji pro WSL2. Mám možnost si nainstalovat paralelně několik různých distribucí (nevím proč bych to dělal, ale prostě můžu) a jen přepnutím ve WSL, aniž bych musel něco restartovat, okamžitě pracuji s distribucí, kterou zrovna chci. Nemusím řešit nekompatibilitu hardware, postará se mi o to abstrakce Hyper-V. Na mém hardware (i9, RTX 2060) se mi dobře nainstaluje Ubuntu. Fedora 32 už nenastartuje ani instalátor a nemám čas, ani chuť hledat, v čem je příčina. Opět, zvítězí raději WSL.

Když započtu čas, který bych tomu musel věnovat, tak rychleji vydělám na silnější počítač, než vyladím novou distribuci k použití.

Přijde mi trochu smutné, že se Linux v očích některých stal systémem, který patří na hardwarový odpad a představuje pro ně výhodu hlavně v tomto směru.

S tím se nedá úplně souhlasit. Příliš zužujete svůj pohled jen na uživatele, kterým nevadí kupovat železo za 30 kKč a ještě dát 3 litry za licenci OS. Takoví lidi žijí v Praze, Brně, Ostravě, Olomouci, možná Plzni, ale ve zbytku republiky jsou to výrazně menší čísla, často rozvedení rodiče, kteří předraženým počítačem uplácí své děti.

Běžný uživatel a to dnes nejen v produktivním věku, ale i průměrný ne-IT student, potřebuje většinou jen terminál k internetu. Webový prohlížeč na facebook, nějaký messenger a online office. V téhle konfiguraci je W10 počítač dost nenažraný, obzvlášť s Firefoxem.

Cena zařízení, které toto zvládá s Windows včetně licence za office (navíc dnes měsíčnímu poplatku a ne jednorázové ceně) je poměrně vyšší, než cena za Linuxovou stanici a LibreOffice.

Zásadní problémy tohoto řešení ovšem jsou:
1) Neexistence out-of-box řešení. Nikdo se nesnaží protlačit přímo do prodeje ultrabook s předinstalovaným Ubuntu s komplet prostředím včetně LibreOffice, aby to uživatel vzal, spustil a začal používat jako u Win10. (Na druhou stranu to má tu výhodu, že díky tomu není tolik negramotných uživatelů a tím i virů a úspěšných útoků jako u Win)

2) I běžní uživatelé o této možnosti neví, nenapadne je, potřebují mít ve svém okolí někoho, kdo jim to doporučí a přednastaví. Pak bez problémů fungují na Ultrabooku za 9 litrů s Lubuntu a chválí si, jak je to svižné.

3) Stále existují určité problémy s kompatibilitou. Např. průměrný zprasený DOC dokument z úřadu se na LibreOffice občas rozhodí o něco hůř, než v Office365.

4) Roztříštěnost/chaos distribucí a opensource řešení. Když už potkáte linuxáka, tak je fanatik pro nějakou obskurní distribuci, se kterou si každý den hraje, aby to jelo, a nechápe, že BFU potřebuje jednoduché a snadno ovladatelné řešení a ne milion různých názvů a "vyber si" z něčeho, čemu nerozumí. Už i ta nesmyslná schizofrenie u Ubuntu, kde podle výchozí instalace okenního správce se to jmenuje pokaždé jinak. Přitom je to pořád stejný systém, jen s jedním jiným metabalíkem. A vysvětlete to Windowsákovi, který je zvyklý na jediné grafické prostředí nanejvýš s nějakými skiny.

Nemyslim, ze predrecnik chtel rict, ze tou nejhlavnejsi vlastnosti Linuxu je, ze jej rozjedete i na starsich strojich. Spis jde jen o to upozornit na fakt, ze existuji opravnene duvody pouzivat Linux jako hlavni system, o nichz vznesl pochybnost kolega 'oss'. Dal proste konkretni argument na konkretni zpochybneni.

Ovsem chapejte - my jsme ti fanatici, pan 'oss' je cisty jak lilie, naprosto chapavy a dava vzdy platne a spravne argumenty. Ted premyslim, neni to nahoudou ten manik co tak vehementne prizvukoval blahe pameti Laelu Ophirovy? Mam dojem (ale treba se pletu), ze ano - to by lecos vysvetlovalo.

"A tym normalny clovek straca potrebu instalovat nejaky linux ako primarny OS." hej? A ja som myslel že Linux ako primárny systém sa inštaluje z dôvodov ako napr. reliabilita. Asi jak to bude bežať vo WSL, když to beží na polorozpadnutom Windowse, kde Microsoft není schopný zlepiť jedno menu s nastaveniami do kopy.

Dúfam skončí krutovláda Microsoftu,... tý čo neutiekli do Linuxu či ohryzku jablka musia robiť jak Microsoft píska. Osobne mi ten DirectX až tak moc nechýba a Lutris dokáže na Linuxu docela dosť dobre spojazniť hry. Inak nedá sa povedať že vydal DirectX, pretože ho nevydal, vydal len niečo ako "proxynu" pre DirectX vo Windows, aby k nemu vedela pristúpiť i Linux aplikace vo WSL, ale pri tom stále je implementácia originálneho DirectX skrytá.

22. 5. 2020, 08:45 editováno autorem komentáře

Ale notak. Krutovláda dávno skončila. A i to slavné DirectX není k ničemu potřeba, když je Vulkan.

Podle mě je Apple daleko větší krutovládce než Microsoft - uzavřená sekta s cool image. Microsoft je podstatně otevřenější - komunikačně i technologicky.

Zajimavy. DirectX funguje. Ale kvuli rozdilne implementaci mmap nefunguje Berkeley DB(libdb4), a bez te nefuguje ani RPM.

Jinak WSL skvely, mnohem rychlejsi nez Cygwin.

cize ak som to spravne pochopil, nato aby to cele fungovalo, musi bezat linux pod windowsom. Ja vam neviem, ale toto tu uz kedysi bolo a bol dost problem sa z toho dostat https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish

Fajn.

A tem mi jeste vysvetlete k cemu to bude dobre. Aplikace vyuzivajici DirectX jedou nativne pod Widlama. Kdyz uz ty Widle bude mit uzivatel nainstalovany, proc by si ten program (pouzivajici Directy) poustel pod WSL?

Me to nedava jaksi smysl....

No mne to dáva jediný zmysel - presne to čo už v diskusii niekto spomína a ja som též toho názoru posledné 2 roky. Microsoft sa chystá pomaly prejsť na linux uplne a potrebuje si urobiť na to "nadstavby" a osahať si ho...

22. 5. 2020, 12:51 editováno autorem komentáře

Jakoze si predpripravuje vlastni "Win" distro a ceka ze mu jej uzivatele otestuji? Je to jen ma spekulace - ale mi nejak nepasuje, ze by se M$ rozhodl zahodit NT kernel, do ktereho narval tolik investic a udrzelo mu postaveni na trhu.

Pravdepodobnejsi mi prijde ze jde primarne o vykon HW - jak pise o neco nize Zdeno Sekerak. Coz ovsem vypada, ze bobasticke provolavani o revoluci bylo krapet predcasne...

Presne tak. Zda sa, ze uz aj microsoft pochopil, ze cez komplet vlastny system cesta nevedie, najme v dobe, ked takmer vsetky ostatne systemy maju jadro nejako prepojene s linuxom. Nasvedcuju tomu informacie, ze windows 10 bude posledny system microsoftu, ale taktiez aktualizacie, ktore su jedna katastrofa v poslednej dobe. Je ale velka skupina ludi, ktory stale zostavaju primarne na windowse. Su to hraci, a management microsoftu by bol velmi zly, ak by si nechal tuto skupinu vziat. Takze to podla mna nakoniec skonci tak, ze microsoft pobezi na linuxe, ale so svojimy vlastnymi kniznicami, ktore nebudu free. A jednou z nich bude aj funkcny direct X s funkcnymi ovladacmi od nvidie a amd. V reklame bude stat 'obrovsky pokrok v stabilite, funkcnosti a vykone', a v podstate budu mat pravdu. Bolo by to najlepsie riesenie pre vsetkych. Podla mna by tymto krokom microsoftu znova stupli predaje. Taktiez by to bol vydareny release windosu a skutocna revolucia. A my ostatny by sme mali paradny operacny system, omnoho lepsie fungujuce aktualizacie (microsoft by si mohol len po vzore androidu spravit svoju vizualnu vrstvu + tie direct X atd atd. ). Taktiez by vyrobcovia prestali kaslat s driverami na linux. No nie je to sen? Ale asi by sme si potom uz museli nainstalovat antivirus..

Takhle nějak se stává MS tím často uváděným největším přispěvatelem do opensourcu, potažmo do kernelu. Jako minule, kdy šlo o podporu jejich proprietárního Hyper-V, aby jim v něm linux běžel.

"Podpora GPU akcelerace pro AI (hlavní motivace?)

Podle mailu od vývojářů je vůbec i portace (respektive, zprostředkování) DirectX 12 v Linuxu celé motivované hlavně tím, že je to nejsnazší cesta, jak sdílet GPU současně mezi virtualizovaným WSL a nativními Windows. Normální virtualizace by totiž grafiku odňala hlavnímu OS, ale pokud je sdílená, mohou ji využívat obě vrstvy. Na to ale zřejmě Microsoft potřebuje, aby v obou vrstvách bylo použité totéž API, čili DirectX."

https://www.cnews.cz/microsoft-windows-subsystem-for-linux-podpora-direct3d-12-cuda-gui-aplikace/

22. 5. 2020, 11:58 editováno autorem komentáře

Microsoft mrsi network stack kazdym releasom.

Pouzivam Intel ANS, ktory podporuje LACP teaming. Microsoft vo Windows 10 teaming nepodporuje, je to prilis serverova/wor­kstation ficura, a kam by sme dosli, keby to podporoval niekto iny a takto Microsoft obchadzal. Tak to Intelu rozbijaju. 1909 bol historicky prvy release Windows 10, ktory to nerozbil.

V článku se uvádí, že aplikace v Linuxu "může dostat 100 % zdrojů/výkonu GPU.". Předpokládám, že těch 100% není myšleno doslova, protože tam bude nějaká režie ovladačů, které se starají o to kolik výkonu dostane která aplikace. Předpokládám, že toho výkonu bude max. 95%, ale spíš výrazně míň (70-80%).

No a pak je druhá věc latence, tzn. prodleva mezi "výpočtem" na fyzické GPU, přes přenos obrazu přes mezivrstvy hlavně přes ovladač dxgkrnl až po samotné vykreslení grafiky v subsystému Linuxu. Odhaduji to na desítky ms čímž to nebude vhodné pro realtimové aplikace.

To co píšu jsem zatím nikde nezjišťoval a neověřoval (v této rané fázi stejně benchtesty nebudou), ale píšu to ze zkušenosti s vga-passthrough na Linuxu. Pokud k výkonu a latencím někdo má nějaké bližší info nebo má nějaký důvod si myslet, že bude výkon a latence jiný než co píšu, rád se nechám poučit.

Toho by som sa nebal.

Aj pri nativnom stacku je driver zlozeny z dvoch casti - userspace dll, ktora pripravuje buffery na spracovanie a uklada ich do fronty a kernel space driver, ktory ma na starosti alokaciu zdrojov a pripravene buffery vo fronte posle na hardware.

Hyperv vie sockety medzi virtualnymi strojmi, ktore su vykonovo na tom rovnako ako nativne sokety v operacnom systeme. Takze ked budu mat userspace cast ovladaca nativnu linuxovu, ktora posle svoje data cez tenky shim v jadre a ten to posle rovno kernelovemu driveru v druhej wm cez hyperv socket, tak vykon bude velmi blizko nativnemu.

Když v Hyper-V nainstaluješ Windows 10 jako guesta, tak není žádná možnost jak by mohl guest i hostitel využívat stejnou GPU a přitom se přiblížit nativnímu výkonu. RemoteFX má velké výkonostní propady a o jiné technologie sdílení jedné GPU mezi guestem a hostitelem nevím. Profesionální Nvidia karty Quadro, které to umí vynechme.

Opravdu si myslíš, že když se neumí nativnímu výkonu přiblížit guest vyvíjený přímo Microsoftem (Windows) na hypervizoru vyjíjený přímo Microsoftem (Hyper-V), tak že to bude umět lépe za použítí kernelu Linuxu?

Pochybuji.

Nie je tam taka moznost, pretoze neexistuje driver, ktory by robil to, co v linuxe robi shim pre /dev/dxg. Teoreticky by Microsoft mohol pripravit takyto driver aj pre Windows, je tu zopar ale:

- ten driver funguje iba v ramci hosta. Ak ho virtualka pouziva, neexistuje moznost premigrovat ju na ineho hosta,

- tym padom Microsoft nema motivaciu spristupnovat to pre genericke virtualky, ale iba pre specificke, ktore vzdy budu lokalne - ako je prave WSL2 alebo Windows Sandbox.

RemoteFX je nieco uplne ine.

Virtuálky používají spoustu funkcionalit, které znemožňují migraci, přesto to není důvod, aby daná funkcionalita nebyla implementovaná. Např. virtuálka na Hyper-V umí VGA-pass, která taky znesnadňuje migraci. Nevím jestli to umí Hyper-V, ale na linuxu v Qemu můžeš virtuálce nastavit "Host passthrough" CPU, která také není doporučována pro migraci. Takových věcí znemožnujích migraci bychom určitě našli více, takže to není příliš pádný argument, proč by to nemohlo fungovat ve virtuálce Windowsu pod Hyper-V.

Ano RemoteFX funguje jinak než implementace popisovaná v článku, ale cíl je stejný - poskytnout virtuálce 3D akceleraci a MS nic lepšího než RemoteFX nemá. Kdyby to bylo jen o těch "rychlých" soketech, tak už by to měl. Poptávka podle mě je.

Existuje sdílení iGPU Intelu přímo na úrovni grafického ovladače, a uvádí se, že dosahuje cca 80% nativního výkonu. Proto jsem skeptický k tomu, že by se Microsoftu podařilo dostat se na úroveň téměř 100%. Na takovou hodnotu se nedostaneš ani s VGA-pass a to je ta nejvýkonější metoda na sdílení, přesněji předání GPU mezi guestem a hostitelem.

Vsadím svoje boty, že nad 90% nativního výkonu se nemají v MS šanci dostat.

Skvělá zpráva! Nemohu se dočkat až půjdou spouštět některé Linuxové programy, které ve Win nemají náhradu. Myslím že MS postupuje správným směrem ke kompatibilitě aplikací i s Linuxem a ne jako RH (Fedora) a Ubuntu(Canonical) házením klacků pod nohy týmu Wine.

A jak MS pomáhá wine? IMO zrovna taková pomoc by byla pro wine daleko nejužitečnější.

Už se těším, až si ve Windows pod WSL nainstaluju deb balíček VirtualBoxu, abych v něm pak pustil virtualizované W10 se Cinema4D a užíval si renderování scény přes DirectX...

Rád bych znal názor na nějaké smysluplné využití, než je zneužití linuxu pro běh vlastních cloudových řešení, kdy MS bude už prodávat jen licenci pro přístup do svého cloudu a uživatelé budou mít nějaký tenký klient s osekaným linuxem, který se do toho bude připojovat...

[jinejmuf]
"Už se těším, až si ve Windows pod WSL nainstaluju deb balíček VirtualBoxu, abych v něm pak pustil virtualizované W10 se Cinema4D a užíval si renderování scény přes DirectX..."

Vy se smejete, ale ja uz jsem na podone reseni (v trochu mensim meritku) narazil. Spusteni hry Dungeon Keeper z GOG.com vypadalo tak, ze se ve Wine spustil launcher, ten spoustel prilozeny widloidni build dosboxu a ten pak samotnou dosovou hru. Tedy poslopnoust Linux -> Wine -> Dosbox -> Hra. Masakr.... Nakonec jsem si teda zbastlil vlastni launcher, ktery vyuziva normalne nativni Dosbox v Linuxu :-D

"Tedy poslopnoust Linux -> Wine -> Dosbox -> Hra. Masakr.... Nakonec jsem si teda zbastlil vlastni launcher, ktery vyuziva normalne nativni Dosbox v Linuxu "

Taky jsem měl nějakou hru z gogu, kterou jsem takto spouštěl, asi to není nic neobvyklého. Taktéž mi připadal Wine zbytečný, takže jsem hru spouštěl přímo v dosboxu. Velký rozdíl, je ale v tom, že dosbox hry nevyužívají 3d akceleraci na kterou narážel předřečník.

[LarryLin]

Obavam se, ze ten rozdil neni az tak velky. Ano nejde sice o 3D akceleraci, ale jde o princip, ktery me prijde podobny jako popisoval predrecnik. Dokonce nejde ani o prebytecnost samotneho Wine.

Jde o to, ze se provadi emulace na dvou systemovych vrtvach (LInux -> Wine). Samotna vrstva Wine je jednak relativne nespolehliva a jednak vam uzere pomerne dost vykonu, v nekterych pripadech predstavuje i zuzeni pro data. A na tom potom spoustite build Dosboxu z Windows, ktery provadi emulaci dosoveho prostredi, coz neni taky uplne trivialni zalezitost. Takze minimalne dojde k razantnimu zpomaleni cele hry oproti nativnimu Wine.

Co se tyce "neobvyklosti" toho reseni, abych se priznal krome GOG.com jsem na podobnou prasarnu jeste nenarazil.

23. 5. 2020, 14:51 editováno autorem komentáře

's/...nativnimu Wine/...nativnimu Dosboxu'

Wine (originally an acronym for "Wine Is Not an Emulator").
Takže jediný emulátor je DosBox a i pro ten je ve Wine přidána compatibilita.

"Co se tyce "neobvyklosti" toho reseni, abych se priznal krome GOG.com jsem na podobnou prasarnu jeste nenarazil."
Hry z Gogu jsou především pro Windows. Nevím o tom, že by Gog podporoval Linuxové hry jako Steam. Takže je pro ně i pro uživatele jednodušší hodit Dosbox do Win aplikace s potřebným configurákem, než aby dávali uživateli složitý návod jak si mají nainstalovat konkrétní verzi Dosboxu a spustit na něm danou hru.

To co popisoval jinejmuf je zanořená virtualizace, jak už někdo napsal a představa, že by ve stejnou chvíli mohla používat společnou GPU:
1)zanořená VM (Win 10),
2)nezanořená VM (deb balíček Virtualboxu) a ještě
3)hostitel (další Win 10).
Fůůůha oproti tomu je Wine s Dosboxem slabý jarní větřík :-)

Což možná ani neuděláte, ne každá virtualizační technologie vždy umožňuje vnořenou virtualizaci, pokud chceme použít VT-x/AMD-V.

Jestli ta akcelerace DX jede v linuxu jen kdyz jsou pod tim windows, tak mne to pripadne jako docela zbastleny. Vetsi smysl by me davalo kdyby to slo cely prelozit pod linuxem, bez te windows mezivrstvy. Moc nechapu k cemu to komu bude...

Je vůbec něco, co do kernelu přidal MS, co nevyžaduje k provozu něco komerčního od MS? IMO to je přesně důvod, proč to tam dávají.

Mozna pribude nejaky ovladac pro Xorg/Mesa anebo nejaka knihovna pro pocitani na GPU.

Súčasťou Mesa je už nejakú doby implementácia Direct3d9 a je možné to používať s Wine (-staging?).

To uz jsem taky nekde zachytil. Mas o tom nejake podrobnejsi info, prosim?

DX9 v Mese ("Gallium Nine") je postaveny nad Gallium state trackerom, takze fungujel len s tymi ovladacmi, ktore su tiez postavene nad Gallium.

Co v praxi znamena, ze len ovladace pre AMD. Relativne nedavno Intel uviedol nove ovladace Iris pre Skylake a novsie, ktore tiez pouzivaju Gallium, takze to funguje aj s nimi. Tieto ovladace budu default v Mesa 20.1.

Pretoze dlhu dobu bola hw podpora relativne obmedzena, a nefunguje to na nvidiach, Projekt Wine tento driver ignoroval, patche neakceptoval a dodnes pouziva emulaciu nad OpenGL.

Projekt ktory zastresoval integraciu do Wine sa zda byt uz mrtvy: https://github.com/iXit/wine

User Mode v linuxu bude podle mě bez Windowsu na pozadí k ničemu. Jediné co mě napadá, že by se mohl Windows spustit na pozadí jako virtuálka (s VGA-pass) a někdo by upravil dxgkrnl (nejlépe kdyby to udělal přímo MS), aby User Mode v Linuxu mohl komunikovat s GPU ve virtuálce Windowsu. Tím pádem by v každém Linuxu mohl fungovat nativně DirectX. Kdyby navíc MS nabízel přímo osekanou verzi VM s Windowsem, která by sloužila pouze jako engine pro DirectX, tak by na tom mohli vydělat všichni - Linuxáci by měli DirectX v každé distribuci Linuxu a MS by vydělávál na licencích za takto osekané VM.

Hezky jsem se zasnil :-) ...ale myslím, že by to bylo funkční řešení s vysokým výkonem a minimální latencí.

jsou veci, ktere i jako linuxak uznavam, ze by microsoft mohl vtelit do vlastni distribuce. jako je mac os uz dnes unixovym systemem, tak by i windows mohly mit unixove streva, vzdyt i android je linux.

mame gcc, clang, proc by nemohl byt v linux/unixu dalsi kompiler msvc s visual studio (ktere opravdu chvalim). co by bylo vhodne opustit je win32 api. zase jsem zastance, aby pokracovalo C#. stejne v cem je microsoft dobry tak to jsou spise aplikacni veci, jako office.

a proc by nemohli do linuxoveho kernelu zamontovat svoje bejkoviny, ani nevim v cem se NT kernel lisi od linuxu, scheduler by mohli mit svuj, IO ovladani taky, takze propojeni by mohlo fungovat.

ja jsem zastance myslenky, ze by microsoft nad linuxem postavil vyssi urovne ekosystemu.

> mame gcc, clang, proc by nemohl byt v linux/unixu dalsi
> kompiler msvc s visual studio (ktere opravdu chvalim). co by

Myslím si, že na tom pracují. Je to logický krok, který jim dovolí pokrýt další segment.

> bylo vhodne opustit je win32 api.

Ano, některá API jsou dost ošklivá (z mojí zkušenosti hlavně ta týkající se GUI/grafiky), ale zejména ta týkající se základů (práce se soubory, procesy, synchronizační primitiva, asyhcnronní operace...) mi často přijdou mnohem lepší než třeba POSIX.

> a proc by nemohli do linuxoveho kernelu zamontovat svoje
> bejkoviny, ani nevim v cem se NT kernel lisi od linuxu,
> scheduler by mohli mit svuj, IO ovladani taky, takze propojeni
> by mohlo fungovat.

Je to jen můj dojem (neznám linux kernel, WIndowsí ale ano), ale přijde mi, že by z toho pak byl jeden velký bordel. Jsou tam rozdílné principy/myšlenky. Microsoft se třeba snaží svůj kernel hodně modularizovat; přístup linuxu mi přijde v porovnání s tím dost monolitický (samozřejmě, jsou tu moduly a velké možnosti nastavení). Dále má Windowsí kernel velmi stabilní API (cca 20 let), takže pokud výrobce nezmrší své ovladače, nebo se zrovna nejedná o oblast, která začala být deprecated a po pár verzích zmizela, vše funguje nezávisle na verzi jádra (několikrát jsem narazil i na případ, že ovladače "nefungovaly" pouze kvůli kontrole na verzi systému v instalátoru). Toto API je poměrně mocné -- dokážete i volat (a je to dokumentované) funkce exportované jako systémová volání.

Samozřejmě tu je trošku problém v tom, že Windows NT byly navrhovány cca 30 let zpátky, takže do kernelu od té doby přibylo spousta zlepšováků, optimalizací a různých podpůrných rozhraní, která z původního dost čistého návrhu dělají poměrně solidní guláš :-). ALe to se po čase stává každému většímu kusu software.

M$ scheduler stoji za dve veci, viz Ryzen9 a Threadripper, nedokaze si spravne poradit s jejich cipletovou architekturou

A pokud je to neschopnost si poradit spravne se nekteryma modernima architekturama, tak to muze bejt duvod k tomu postupne opustit NT kernel, prece jenom udrzba toho musi stat desnej majlant

Otazka je, kdo by mel o MSVC na Linuxu vubec zajem? V dnesni dobe je to ten nejhorsi kompiler co produkuje ten nejhorsi kod. Tam kde to je jen mozne uz se i ve Windows kompile pres clang-cl, dokonce i MS tento kompiler nabizi primo ve VS, takze pro koho by MSVC pod Linuxem byl?

IMO je to spis opacne, je otazka casu kdy MS ten jejich kompiler odpiska uplne a predje na clang, ktery si stejne muze diky licenci rozsirit tak jak potrebuje.

MSVC se poslední dobou hodně zlepšil, ale na Linuxu by byl fakt k ničemu, bohatě stačí Clang a ICC.

Muzes na godbolt.org udelat nejaky priklad, kde by byl ICC lepsi nez GCC nebo Clang? Mi prijde ICC srovnatelny s MSVC, teda aspon podle toho co jsem sam zkousel, v podstate uplne nepodstatny kompiler pro vetsinu projektu. Je to asi rok co jsem delal nejake experimenty, tak treba uz ICC presel na clang a je to srovnatelne :)