Vlákno názorů k článku Pozor na Microsoft, nakonec nás o svobodný Linux připraví od xyz - Autor vubec nevi o cem mluvi. Kdyby si...
-
Autor vubec nevi o cem mluvi. Kdyby si udelal aspon nejakou resersi, tak by zjistil, ze nahradit NT kernel za Linux Kernel ve Windows proste neni mozne. Skoncilo by to nejakou emulaci, to co dneska dela Wine atd.
Cili jsou dve moznosti, bud zahodit Windows a nahradit je necim jinym (zrejme Linuxova distribuce) a nebo dal udrzovat Windows.
Zahodit windows znamena ale prestat podporovat aplikace, pro ktere neni alternativa. (napr. 3d Studio Max??)
-
Michal SmržStříbrný podporovatelSouhlasím, ale protiargument... Proč by MS nemohl udělat MS-Wine? Narozdíl od jiných, oni ty API opravdu znají. Myslíte že 3D Studio Max potřebuje nějaké hluboké fičury z kernelu?
Dle mě je to právě naopak. Windows stojí na driverech k HW, které nelze nahradit. -
Pretoze jedna vec je ze ich oficialne API obchadazju mnohe ich vlastne nastroje (od Office ktore pouziva rozne nedokumentovane API) az po 3th party aplikacie ktore tiez mozu pouzivat rozne nestandardne cesty ktore tak nejak funguju. To ze by sa niekomu nieco rozbilo na desktope, to by sa este nejak prezilo. Ale nikto nebude riskovat ze sa rozdrbe serverova infrastruktura. Zakladne pravidlo - co funguje sa neprepisuje. Wine je fandom projekt ktory vznikol hlavne z potreby hrat hry pod Linuxom. Neviem ci by som chcel prevadzkovat pod Wine nejaky MS Sql server alebo nejaky cluster... A vzhladom na to ako MS si taha spatnu kompatibilitu a kolko api maju, ani oni nie su schopny od podlahy to prerobit na nejaku emulaciu.
-
MS SQL od 2k17 oficielne bezi v tucnakovi nativne.
https://learn.microsoft.com/en-us/sql/linux/sql-server-linux-setup?view=sql-server-ver17
-
Už teď běží Windows desktop by default ve VM, vedle toho VM s WSL2, a nad tím hypervizor. Takže se akorát prohodí: "nabootuješ" do Linuxu (WSL2) a poklikání na .exe automaticky spustí app ve VM s původním Windows jádrem a userspace a bude přenášet obraz a zvuk (stejně jako dnes umí u WSL2). 100% kompatibilita aplikací. Dále 100% kompatibilita HW ovladačů, protože ty jsou napojeny na hypervisor a oba OS jako guesti uvnitř používají obecné virtuální drivery. Ten Linux v popředí může mít grafiku Windows, dokonce tam může běžet naportovaný explorer.exe (plocha, Start menu, Start panel, Alt-Tab, ...). Stejně tak se naportují GUI toolkity (resp. obecná API, která jsou pod nima).
Např. A/UX (Apple Unix, 1988-1995) měl MacOS GUI toolkit naportován do Unixu, takže jste dostali stejně vypadající plochu, ať už jste v login dialogu vybrali otevřít MacOS nebo Unix prostředí.
-
To je hodne divoka teorie. Nechapu, jakou by to cele melo vyhodu? Podle toho popisu by windowsi kernel a vsechny userspace knihovny nad nim a asi i gui stejne museli furt vyvijet. Takze by si neusetrili zadnou praci. Krome toho ted to je tak, ze zarizeni (hlavne gpu) jsou pass through do te hlavni instance. Bez toho by vykon sel do kopru. A pasdthrough do dvou vm nepujde a i kdyby nejak jo, tak by musely byt dvoje ovladace. No proste to cele nedava smysl, sorry ;-)
-
Jenže userspace ve Windows se nevyvíjí, jen udržuje. Kvůli zachování plné zpětné kompatibility, kterou Linux nezná. Mimochodem zkoušel jsem např Windows GDI (původní GUI toolkit) naportovaný do MacOS Classic. Jel nad tím Microsoft Office 95 pro Mac.
A k té virtualizaci? Vždyť on tak Windows by default jede už teď! A jaky by byl důvod mého řešení? Kernel, který vyvíjet hlavně pro moderní servery a už i workstationy zvládá Microsoft stále hůře (např podpora více jader, škálování výkonu, výkon I/O, ...).
-
> A k té virtualizaci? Vždyť on tak Windows by default jede už teď!
Opravdu? Pamatuju si, že Windows ten hypervizor zapínaly například při instalaci WSL.
> Kernel, který vyvíjet hlavně pro moderní servery a už i workstationy zvládá Microsoft stále hůře (např podpora více jader, škálování výkonu, výkon I/O, ...).
A jak by si tím pomohli? Tyto věci musí nějak typicky řešit i hypervizor.
-
Ono to asi ani nedává smysl dávat GPU do hypervizoru. Co by s tím pak hypervizoru dělal? Měl vlastní GUI?
A praktická věc: Jak zajistíme implementaci něčeho tak komplexního jako jsou ovladače GPU? Teoreticky je možné je přepsat, ale to by mohlo být moc velké sousto j pro MŠ něco takového prosadit – i kdyby měli velkou motivaci.
-
Ovladače GPU se právě pro Windows dělají nejsnadněji ze všech OS. Je to jen tenká kernelová vrstva pod DirectX 12. Userspace DirectX 12 a wrappery na starší DirectX, OpenGL, OpenCL a Vulkan dodává Microsoft. Podobně v Linuxu stačí Vulkan a OpenGL je přes Zink. Nebo ve Windows 9x stačilo pro OpenGL driver implementovat jen rasterizaci a vše nad ní dodával Microsoft (vertexy, osvětlení, ... - Mini-Client Driver; v Linuxu zas bylo běžné zkopírovat softwarovou Mesu a přepsat kód rasterizace). Proto taky mohl Intel vydat dedikované grafiky s úplně novým ovladačem, podobně máme grafiku v procesoru Qualcomm. A obráceně, DirectX 12 je teď implementován přímo v Linuxu (binární ovladač ve WSL2).
16. 5. 2026, 18:15 editováno autorem komentáře
-
To nie je celkom tak pravda; preto mal Intel problem s kompatibilitou ked prisiel s diskretnymi ARC grafikami (najprv sa spolahol na MS implementaciu, co im bolo dane vyzrat, takze to museli riesit klasicky), AMD sustavne nieco fixuje a Nvidia si ziarlivo strazila svoj naskok v DX/OGL.
Na Linuxovej strane sa ziadne kopirovanie swrast nekonalo. Ovladace mali na vyber, bud si implementovat cely svoj stack, alebo pouzit Gallium. Stary i965 Intel driver pouzival pristup a), novsi iris pouziva pristup b). AMD islo cez Gallium vzdy.
No a samozrejme zostavaju shader compilery, co je pomerne velka cast ovladaca. Kazdy vendor si ho musi urobit sam, kedze si tiez definuje ISA sam. Niektori viac, niektori menej kompatibilne medzi generaciami.
16. 5. 2026, 19:09 editováno autorem komentáře
-
Passthrough jedneho zariadenia do dvoch (alebo viacerych) virtualok samozrejme ide, v pripade sietovych kariet sa to bezne pouziva.
V pripade GPU sa to pouziva menej, ale existuje. AMD aj Nvidia samozrejme za tuto moznost pytaju extra, takze to vyuzivaju len ti, co su ochotni za to priplacat, Intel to na niektorych produktoch dovoluje zdarma, ale ovladace ma len pre klientske windows a linux. Nazyva sa to SR-IOV a iste, samotna karta to musi podporovat.
A ano, kazda vm potrebuje svoj ovladac. Ved predsa vidi PCIe zariadenie, musi s nim nejako komunikovat.
-
Intel měl problém s kompatibilitou s DirectX 9, nakonec ho implementoval místo použití wrapperu od Microsoftu (mimochodem na GitHubu). U dedikované GPU chtějí uživatelé kompatibilitu dekády zpět, u integrované ne. Dale měl problém s výkonem (např ReBAR).
Kopírování MesaGL mluvím o dobách grafik jako SiS 6326. To ještě Linux neměl framework pro psaní GPU ovladačů.
Práce s GPU funguje ve WSL2 s různými GPU. Tam nejsou omezeni jako v bare metal Linuxu. Nemluvím o zabugovaném PCIe Passthrough, tam byste ani neměl možnost zobrazit si obraz dohromady s GPU, co kreslí desktop.
-
Pointa bola, ze wrappery su nedostatocne... ReBAR s nimi nic nema; a s vykonom pomaha, pretoze netreba na hostovi strankovat pamat PCIe zariadenia, je vidno cela naraz a DMA engine sa da vyuzit efektivnejsie. Problemom pre Intel bolo, ze vela dosiek vo volnej prirode ReBAR nezvladalo.
V casoch grafik ako SiS 6326 nemal framework na 3d ovladace ani Windows. Vtedy svetu vladlo Glide. Nie, minidriver v NT nepomahal, on bol dovod, preco ho IHV obchadzali (uz ked bolo treba akcelerovat T&L, co vedeli prve Nvidie Riva, tak to bola prekazka, nie pomoc).
GPU vo WSL2 funguju len preto, ze linuxove ovladace mesa (alebo compute runtime) nevolaju linuxove jadro, ako to robia v normalnej virtualke/fyzickom stroji, ale tuneluju tieto volania cez hyperv socket na hosta, kde to obsluzi windows ovladac. Je to svojim sposobom proprietarna obdoba virGL a preto aj nefungovala hned, ale az postupne, ako bola zapracovane do ovladacov na oboch stranach. AMD-ckovy librocdxg (passthough pre rocm) je v podstate verejne oznameny len par tyzdnov. No a inak PCIe passthrough, ci uz pre cele zariadenie, alebo pre VF na kartach co vedia SR-IOV, funguje velmi dobre. Mozno nie na zeleze, co ma problem aj sam so sebou alebo s ReBAR, ale na normalnom ano.
Btw, ste si vedomi, ze WSLg tuneluje vystup svojho wayland kompozitora cez RAIL? (Remote Application Integrated Locally, v podstate RDP jednotlivych okien, v tomto pripade cez lokalny socket) Nejde o priamy scanout. 3D akceleracia cez RDP ma, nazvime to, svoje uskalia (a tie sa tykaju rovnako aj virtualok s passthough a pristupom cez rdp).
-
Wrappery jsou nutnost, stará API jsou podporována stále hůře. Problém Intelu s chybějícím ReBARem je, že neumí pracovat skrz okno, protože na integrovaných grafikách to řešit nemusel.
OpenGL Mini-Client Driver byl ve Windows 9x, ne ve Windows NT. A měl jsem vícero grafik, které ho používaly. V té době Linux neměl hardwarové OpenGL vůbec.
Ano, řešení přenosu GPU z Guest do Host je více. Některá nejsou závislá na výrobci GPU. Řešení ve WSL2 funguje s minimální režií: Linux kreslí svůj Wayland přes DirectX, ten se posílá ven do Hosta, kde se nijak nezpracovává, rovnou se vykoná.
-
A prave preto bolo WSL1 opustene, niektore veci sa tam nikdy nepodarilo rozbehat, alebo neboli spolahlive -- napriklad postgresql vedel zhucat na fsync() -- pretoze aj ked syscally teoreticky odemulovane boli, semantika bola mierne ina.
Rovnako preto v linuxovom jadre pribudaju syscally s nt semantikou. Napriklad v prednedavnom vydanej Fedore 44 pribudla podpora NTSYNC.
-
WSL1 je v podstate subsystem, ako bol svojho casu OS/2 subsystem pre NT. Ano, niektore veci tam funguju, zvycajne tie jednoduchsie; ak v historickom WINE, ked zacinal, jednoduche veci nemali problem.
A to ze PostgreSQL existuje aj pre Windows som nijako neporozporoval; pointa bola, ze WSL1 nie je dost dobry, aby tam bezne linuxove aplikacie - napriklad take, co pouzivaju shared memory - behali.
No a vidi ho lokalne, pretoze maju spolocne sietove rozhranie. WSL2 je virtualka, tak ma samostane sietove rozhrania. To je cele.