Windows Subsystem for Linux krijgt ondersteuning voor DX12 en apps met gui

Tijdens zijn Build-evenement voor ontwikkelaars heeft Microsoft aangekondigd dat het gpu-acceleratie naar het Linux-subsysteem van Windows 10 brengt. Daarvoor krijgt WSL2 ondersteuning voor DirectX 12 en kan het ook Linux-programma's met gui draaien.

In een blogartikel geeft Microsoft de details over de komst van de hardwarematige grafische acceleratie naar het Windows Subsystem for Linux 2. WSL2 is vanaf de May 2020 Update onderdeel van Windows 10 en bevat bijvoorbeeld een Linux-kernel, maar het subsysteem draait standaard alleen command-line tools. Voor applicaties met een grafische userinterface moet een gebruiker externe toepassingen zoals X11 gebruiken.

Microsoft werkt eraan om dat te veranderen. De stap is het gevolg van Microsofts werk aan gpu-virtualisatie. Het bedrijf ontwikkelt hiervoor een Linux-kerneldriver die een gpu via het wddm gpu-paravirtualization-protocol beschikbaar maakt voor de usermode van Linux.

Volgens Microsoft krijgen applicaties in de Linux-omgeving daardoor dezelfde toegang tot de gpu als Windows-applicaties. Microsoft benadrukt verder dat het om de volledige D3D 12-api gaat die dezelfde functionaliteit en prestaties biedt als op Windows, minus de overhead die het gevolg is van virtualisatie.

Microsoft meldt verder dat het de OpenCL- en OpenGL-lagen voor DX12 waar het aan werkt, ook gaat gebruiken om hardwareacceleratie op basis van die standaarden naar het Linux-subsysteem te brengen. Dat zal gebeuren via de opensource Mesa-bibliotheek. Microsoft maakt de gpu-kerneldriver voor Linux opensource beschikbaar, maar de DirectX-core en D3D 12-bibliotheken blijven gesloten.

Microsoft werkt verder samen met Nvidia aan cuda-ondersteuning voor het Windows Subsysteem voor Linux. Die ondersteuning verschijnt met de komst van Nvidia's komende wddm v2.9-driver. De uitbreiding van WSL 2 is bedoeld om ontwikkelaars die Linux-tools gebruiken binnenboord te houden bij Windows 10.

Tegelijkertijd toont het de veranderde houding van Microsoft richting opensource aan. Recent zei Microsoft-president Brad Smith dat zijn bedrijf 'aan de verkeerde kant van de geschiedenis stond toen opensource explodeerde aan het begin van de eeuw'.

Reacties (152)

[Eonfge]

Linux kernel maintainers hebben al aangeven dat dit niet zomaar de kernel in gaat:
https://www.phoronix.com/...oft-DXGKRNL-Uphill-Battle

Lang verhaal kort:
- Standaard worden er geen koppelingen in de Kernel opgenomen die koppelen met gesloten componenten
- Dit kan lijden tot een divide-and-conquer, triple-E, situatie waarbij Linux afhankelijk wordt van componenten buiten hun invloedsfeer
- Er is zorg om patenten, aangezien Micorsoft hier een stukje van zijn NT kernel naarbinnen probeert te fietsen.

Je kunt er ook vanuit gaan dat de FSF en de SFC al vast meelezen en overleggen met ontwikkelaars over mogelijke schending van de GPL.

Edit.

Ik vermoed dat Microsoft zich hier nog wel eens in heeft vergist. Balmer's "Linux is Cancer" was een hele heldere vervloeking van het open model dat Linux vertegenwoordigd, en hoe meer Windows daar mee wilt koppelen, des te meer het gaat schuren.

Super edit.

Super interessante ontwikkeling in de zaak;
https://www.phoronix.com/...soft-Writing-Wayland-Comp

We have consider the possibility of bringing DX to Linux with no Windows cord attached. I'm not ready to discuss this at this time... but in the hypothetical that we were do this, DX would be running on top of DRI/DRM on native Linux.

Het lijkt er dus op dat ze intern gesproken hebben over het uitgeven van DirectX als onderdeel van de Linux kernel. Wat dus GPL 2.0 zou betekenen.

[Reactie gewijzigd door Eonfge op 22 juli 2024 14:33]

[Titan_Fox]

Die uitspraak van Balmer was in een tijd de verkoop van Windows nog het primaire verdienmodel was. Sinds een hele tijd focust Microsoft zich vooral op cloud services. Welk lokaal OS daar onder ligt maakt dan niet meer zo veel uit. Daarom komen ze ook met verschillende initiatieven om het voor o.a. Linux gebruikers makkelijk te maken om deze online diensten te gebruiken.

Daarnaast is Microsoft sowieso druk bezig om hun diensten op Android (Linux-kernel) aan de man te brengen. De stap om je applicaties ook op een desktop of server versie van Linux werkend te krijgen lijkt mij dan ook niet zo heel erg moeilijk.

[Reactie gewijzigd door Titan_Fox op 22 juli 2024 14:33]

[Ayporos]

Native DX op Linux zou natuurlijk súuuuper tof zijn.

[Titan_Fox]

In principe wel, mits hardwarefabrikanten dan voor fatsoenlijke drivers zorgen die daar mee overweg kunnen. Het lijkt voor hun al moeilijk genoeg (spreek : amper rendabel) om OpenGL en Vulkan fatsoenlijk te ondersteunen.

[Robin4]

Zit er niet erop te wachten, heb eerder liever vulkan voor in de plaats.

[Marctraider]

DX is proprietary Cancer voor open source.

Lekker Vulkan als standaard aanhouden.

[ro_vd_me]

Mactraider zegt niet dat alles opensource moet zijn. Hij bedoeld, denk ik, dat DX en opensource niet samen gaan. tenminste niet in elkaar op kunnen gaan omdat DX niet onder een vrije software licentie valt, De linux kernel is opensource, en het zou fijn zijn als dat zo blijft. Dat doet niets af aan dat anderen code mogen schrijven en die onder een andere licentie mogen uitbrengen.
Bovendien valt met opensource ook wel een boterham te verdienen hoor! Alleen niet direct met de verkoop van die code.

[YuYa]

Oftewel Embrace, extend, and extinguish.

[gepebril]

And fork! Open source kun je niet killen, dan wordt het vooraf geforked

Veel gezien in open source projecten. De meest heftige was bij Bitcoin, met Bitcoin cash. Uiteindelijk wint de community altijd, en verliest het grote geld.

[Reactie gewijzigd door gepebril op 22 juli 2024 14:33]

[Terr-E]

Even advocaat van de duivel spelen;
Dit is niet hoe Embrace, Extend and Extinguish werkt.
De Extend fase zou ervoor moeten zorgen dat gebruikers afhankelijk worden van de (propriëtaire/gesloten) toevoegingen die je als duivel doet, zodat mensen niet meer terug kunnen / willen.
Bijvoorbeeld Android. AOSP is een prima werkende Android versie en alles daaraan is te forken / vrij, libre en open te houden, maar hoe groot is het marktaandeel van AOSP telefoons ? Als Google vandaag besluit om Android alleen nog maar achter gesloten deuren door te ontwikkelen (Extinguish fase), dan zijn bijna alle Android gebruikers opeens vendor-locked. Een fork van AOSP die dan door de community verder doorontwikkeld wordt zal steeds verder afwijken van Google Android, en alle apps die rusten op Google Play Services zullen op een gegeven moment niet meer werken op AOSP. (Ik ga er hierbij vanuit dat Google op dat moment ook Google Play Services verder dicht gaat spijkeren zodat dingen als microG niet meer haalbaar zijn)
Vanaf dat moment wordt AOSP net zo'n buitenbeentje als Sailfish; het werkt prima, maar je mist een hoop (native) features die Google Android (en Apple IOS) wel hebben.

Voor Microsoft Linux zou dit betekenen dat ze zoveel mogelijk willen bijdragen aan essentiële dingen zoals de Linux kernel, Git etc. om afhankelijkheid te creëren. Vervolgens interessante nieuwe features toevoegen (zoals binairy blob DirectX ofzo) om zo te zorgen dat 3e partijen afhankelijkheden gaan creëren op jouw (propriëtaire) toevoegingen. Zodra de meerderheid van de gebruikers in sterke mate afhankelijk is van jouw bijdragen / diensten / platform ( Kernel code / DirectX, Visual Studio Code / Github om maar wat te noemen ) trek je de stekker eruit, en kunnen mensen niet meer terug zonder eerst jaren terug in de tijd te gaan qua features / gebruiksgemak.

Ik zeg niet dát het gaat gebeuren, maar tot nu gaat alles zoals ik het zou doen al ik Microsoft was en een tripple-E strategie zou hebben aangaande Linux / Open Source…

Zo, nu kan het alu hoedje weer af.

[84hannes]

Ik kwam deze ontwikkeling vandaag pas op het spoor

Ik zeg niet dát het gaat gebeuren

Ik zeg dat dit wel gaat gebeuren: ontwikkelaars gaan Linux-software schrijven die DirectX gebruikt. Die testen ze op hun WSL pc of Linux virtueel op Azure en alles is mooi. Dan willen ze het uitrollen op een puur Linux-systeem en het blijkt niet te werken omdat je de DirectX binaries nodig hebt op een onderliggend systeem: opeens is het gebruik van Linux geen optie meer en moet de ontwikkelaar maar ook de gebruiker voortaan beschikken over Windows. Linux wordt zo wel degelijk extinguished.

[Eonfge]

Een van de kernel-maintainers zegt dat ook gewoon ja. Als Microsoft wilt koppelen, moeten ze eerst maar eens over de brug komen met DirectX en de bijbehorende patenten.

[robertpNL]

Misschien is het Microsoft helemaal niet de bedoeling om Linux te "ontarmen" en "uit te roeien" maar alleen de ontwikkelaar op een Windows machine een Linux met GUI te faciliteren om geschreven software ook te testen op een Linux desktop (met .NET Core).

[xFeverr]

Ho ho ho... Niet alle developers hebben Cuda support nodig. Misschien is WSL in jouw praktijk nutteloos, maar voor mij en vele anderen is dat dus niet zo.

Zo, terug naar de orde van de dag.

[latka]

De release van nu doet geen GUI. Dus is het zowiezo nog niet erg bruikbaar behalve voor machine learning/AI/Cuda spul

[xFeverr]

GUI? Wie heeft er nu perse een Linux GUI nodig? Er zijn meer commandline tools dan ML/AI/Cuda spul hoor.

Windows heeft mijn GUI applicaties, zoals mijn IDE en webbrowser, dingen die Windows voor mijn gevoel beter afgaan terwijl WSL taken op zich neemt zoals builden en hosten, iets waar Linux in mijn geval sterk in is.

Dus... Niet nutteloos als je het mij vraagt.

[latka]

Ah, WSL is nuttig (gebruik zelf vaker cygwin). De discussie was voornamelijk gericht op het beschikbaar komen van GPU functies in WSL.

[psychicist]

WSL wordt toch maar gebruikt door een schamele 150.000 mensen op dese aardbol en kost Microsoft alleen maar geld. Voor AI/ML/CUDA heb ik een laptop met RHEL/CentOS en een desktop met OpenSUSE, die geïnstalleerd staan naast Debian, wat ik tegenwoordig voornamelijk gebruik. Ik vraag me alleen af of de Vulkan driver goed functioneert samen met CUDA.

Windows is voor mij voornamelijk handig om Visual Studio (niet Code) te draaien en helaas een noodzaak om firmware updates te kunnen installeren. Die wordt eens in de zoveel tijd opnieuw geïnstalleerd met de nieuwste versie. Ik vraag me af of de update goed gaat, wanneer de nieuwe versie later deze maand komt of dat ik die dan alsnog opnieuw moet installeren, omdat de boel verziekt is zoals bij zoveel mensen vaak het geval is.

[dj__jg]

Ach, toen ik laatst een GUI moest draaien viel de rompslomp best tegen, was goed te doen.

https://github.com/stronnag/mwptools/wiki/mwp-in-WSL

Niet heel soepel allemaal, maar het werkte zeker goed genoeg

[matty___]

komt Linux toch nog een keer op de desktop

[YuYa]

Jaren geleden realiseerde ik mij opeens dat het zeer waarschijnlijk was dat Microsoft op gegeven moment over zou stappen op een waarschijnlijk zelfgemaakte Linux en daarmee de Linux Desktop tot feit zou maken en zij meteen ook (tijdelijk) de grootste Distro zou worden.
Ik zie dat steeds dichterbij komen en wel zeer snel. Het zal natuurlijk voor- en nadelen hebben en het gezegde vertel mij wie je vrienden zijn en ik vertel jou wie jij bent zou wel eens schrijnend bewaarheid kunnen worden.
Aan de andere kant komt Satya Nadella en de bijdragen van MS de laatste jaren wel geloofwaardig over. Oftwel: vertrouwen geven maar waakzaam blijven

[WolfpackN64]

Ik zie het ook meer als een Extend, Embrace, Profit.
Microsoft is al zeer afhankelijk van Linux voor een groot stuk van hun winst, ze hebben geen redenen om Linux tegen te werken.
Langzaam hun Windows libraries en tools naar Linux overzetten kan hen alleen maar voordelen opleveren.
Vanaf dat Microsoft ooit begint met commits voor Wine of een fork ervan weten we hoe laat het is.

[chrisism]

Beetje outdated opvatting hoor en MS bashing. Iedereen die weer opmerkingen maakt over hoe MS stiekem linux aan het uitroeien is, is ook maar sfeermakerij. Microsoft is al jaren bezig met een totale andere route, waarbij ze zelf met heel veel dingen juist open-source zijn gegaan Lid zijn geworden van de linux foundation en nog wel meer dingen hebben toegevoegd aan de linux wereld.
MS richt zich ook niet meer op simpele windows licenties en zijn al tijden bezig zich volledige te richten op Azure en cloud. Daar verdienen zij hun geld en daar zit ook een heleboel linux bij. Ze willen juist zo veel mogelijk integreren met linux om een grotere afzetmarkt te creëren. Het idee van dat het niet uit maakt op welk platform of systeem je werkt, zolang je maar gebruik maakt van Microsoft services/diensten, net zoals Google dat doet.

[Eonfge]

Micorsoft :hartje: Open Source

Betekent precies dat. Microsoft heeft graag open technieken, welke ze kunnen opnemen in hun eigen gesloten producten en SaaS platform. Je zult Microsoft niet betrappen op het enthousiast bijdragen aan Libre Software. Sterker nog, als je wilt bijdragen aan een 'open source' Microsoft product, dan moet je eerst al je rechten weggeven aan Microsoft, en dan geven ze jou een licentie op je eigen werk, onder de MIT licentie. Microsoft's open source beleid is behoorlijk roofzuchtig en daarom liggen ze vaak zo slecht bij ontwikkelaars voor wie eerlijke rechten belangrijk zijn.

Meer info hier:
https://www.makeuseof.com/tag/open-source-vs-free-software/
https://medium.com/@moqod...re-licensing-c0fa600106c9

[svenk91]

Ik kan trouwens in de originele blogpost nergens vinden dat ze het in de standaard linux kernel willen hebben. Enkel dat het een kernel mode driver is, maar dat kan ook prima als module toch?

[ELD]

klinkt inderdaad als EEE "embrace, extend, and exterminate"

[Reactie gewijzigd door ELD op 22 juli 2024 14:33]

[Verwijderd]

We have consider the possibility of bringing DX to Linux with no Windows cord attached. I'm not ready to discuss this at this time... but in the hypothetical that we were do this, DX would be running on top of DRI/DRM on native Linux.

Oh wow dacht niet dat ik het ooit nog zou meemaken. Dit is echt groot nieuws.

[t link]

Dit zou fantastisch zijn, echt gigantisch. het zou bijvoorbeeld proton van steam enorm veel makkelijker maken kan ik me voorstellen.

[beerse]

Op zich helemaal gelijk, inclusief de (super) edit.

Bedenk wel dat het hier bij wsl gaat om een distributie die microsoft zelf uit brengt. Daar kan ze dus aan bijdragen wat ze zelf nodig acht. Volgens opensoure kan (en zal) ze dat ook terug geven aan de community die het op haar beurt kan en mag weggooien.

Daarnaast zie ik dat het hier om de grafische interface gaat. Voor de grafische kaarten zijn er 3 grote spelers waarvan er 1 ook niet met eigen drivers voor linux komt: nvidia. En nu juist die komt microsoft te hulp in deze ontwikkeling. Volgens mij gaat daar een virtuele nvidia kaart onstaan die met nuveau ( de opensource drivers voor nivida) wel gaat werken maar met een nvidia driver pas echt gaat vlammen.

Nee, ik ben het daar ook niet mee eens, ik had liever gezien dat ze 'gewoon' de virtuele driver uit de virtualisatie omgeving gepakt zouden hebben. Liefst de 'hardware accelerated' variant.
Nee, nvidia is nu net vanuit de opensource omgeving niet de juiste partner voor microsoft, gezien haar eigen reputatie met drivers.
Nee, misschien gaan ze met nvidia nu weer 'naar de verkeerde kant van de nieuwe geschiedenis qua opensource'.

[Eonfge]

Goed punt. Upstream hoeft het niet te accepteren, zolang de code maar open is.

In de praktijk betekend dat doorgaans de doodsteek voor een techniek. Als het niet in de kernel zit, is het ook geen onderdeel van welke intergratie test dan ook, dus dan ben je vaak afhankelijke van losse partijen die na elke nieuwe kernel-release de software opnieuw moeten compileren. Dit geeft ook zo veel gezeik bij Android en het uitbrengen van beveiligingsupdates.

[Flake]

Ik denk dat MS doorheeft dat Vulkan een serieuze bedreiging vormt in hun gaming ecosysteem. De Xbox biedt enige vorm van houvast omdat dat het enige andere platform is waar DX12 op draait en ik denk dat ze beginnen in te zien dat ze het daarmee niet gaan redden. Maar DX naar Linux is wel een opvallende zet.

[TheVivaldi]

Maar Microsoft heeft onlangs min of meer excuses aangeboden voor Ballmer's uitspraak, dus dat kan niet meer schuren.

[Eonfge]

Het is niet de uitspraak die schuurt, maar de fundamentele verschillen tussen hoe code moet worden gedeeld. GNU GPL 2 vs Microsoft Propriatary.

[TheVivaldi]

Microsoft is de grooste bijdrager van OSS-code, dus ze zijn er zeker wel voor. Dat erken zelfs ik als jarenlange Linux-gebruiker.

[jimshatt]

Maar als dit als losse module geleverd wordt, netzoals de nvidia drivers, dan is er weinig aan te doen, toch? Daarnaast distribueert Microsoft zelf de kernel voor WSL. Wellicht is er licentietechnisch iets tegen het samen leveren van een GPL kernel met een gesloten module te doen, maar de module zelf is open source dus daar verwacht ik weinig mogelijkheden.

Deze module doet natuurlijk alleen iets als de Linux kernel binnen WSL draait, en niet als je native Linux draait. Misschien dat het voor Wine developers nog nuttig is om de kijken welke calls wat doen, en misschien zelfs (via een of andere LVVM truc) de calls naar OpenGL of Vulkan kunnen routeren. Maar daar heb ik helemaal geen verstand van dus het kan zijn dat ik nu uit m'n nek zwets.

[Eonfge]

Dat kan ja. Er zijn systemen zoals DKMS waarmee je tijdens boot je eigen modules kunt toevoegen aan de Linux Kernel. Als je dit doet dan met je dit niet meer distribueren i.v.m. de GPL licentie op de Kernel, maar je mag het wel draaien inderdaad. Dit verklaart ook waarom de NVidia drivers doorgaans niet op de CD staan van Linux distributies.

Dit zal dus ook een spanningsveld worden, want als Microsoft dit als 1-klik oplossing gaat aanbieden in hun software center, dan kun al snel spreken over een afgeleid werk, en dan moet DirectX ook GPL gelicenceerd zijn.

Voor Wine is dit niet echt belangrijk. Naast dat het nog onduidelijk is of dit allemaal patent-vrij is. Wine doet eigenlijk het tegenovergestelde, Windows API calls omkappen naar Linux en Unix.

Voor de helderheid, je mag alleen aan Wine werken als je nooit broncode van Windows hebt gezien. Voor nu weigeren enkele prominente Linux developers ook om naar de code van dxgkrnl te kijken totdat er juridische duidelijkheid is. Veel onduidelijkheid dus, en advocaten zullen er nu vast een druk mee aan de slag gaan.

[Reactie gewijzigd door Eonfge op 22 juli 2024 14:33]

[afterburn]

Ik zie niet helemaal wat dit te maken heeft met de kernel development in de reacties hierboven. Microsoft gebruikt een custom kernel voor WSL/WSL2 en kan daar instoppen wat ze willen. Er is helemaal geen noodzaak om 1) DX12 open source te maken 2) Linux kernel dev deze aanpassing over te nemen. Sterker nog, dit zijn aanpassingen voor een hele specifieke use-case (nl WSL) die daarbuiten weinig toegevoegde waarde heeft, zeker niet voor Linux-core. Er zijn wel toepassingen te verzinnen voor andere virtualisatie oplossingen, maar dat is niet per definitie een zorg voor de linux kernel development (of Microsoft).

Dat gezegd hebbende, ALS Microsoft het voorelkaar krijgt om op deze manier near-native performance te geven met virtualisatie, dan zijn er wel redenen voor MS om mogelijkheden en oplossingen te verzinnen dit wel in de kernel te krijgen omdat dit dan in een klap Windows bovenaan zet als Linux virtualisatie platform. (je hoeft maar met Linux GUI gewerkt te hebben onder VMware ESX om te weten hoe ruk het kan zijn)

[rbr320]

Microsoft gebruikt een custom kernel voor WSL/WSL2 en kan daar instoppen wat ze willen.

Dat is niet correct. Ten eerst wordt voor WSL versie 1 helemaal geen Linux kernel gebruikt maar een door Microsoft zelf geschreven interface laag die Linux kernel API/ABI calls omzet naar hun NT kernel equivalenten. Feitelijk exact hetzelfde als dat Wine doet op Linux, maar dan precies de andere kant op.

WSL2 maakt inderdaad wel gebruik van een Linux kernel die voor zover ik weet draait in een afgeslankte versie van Hyper-V. Het is zeer waarschijnlijk dat deze kernel door Microsoft aangepast is, maar dat betekend niet dat ze er zomaar in mogen stoppen wat ze willen want ze moeten gewoon aan de GPL voldoen. De GPL zegt dat je aanpassingen aan de code weer moet delen met de rest van de wereld, je mag niet zomaar de code aanpassen en daarna doen wat je wilt zoals dat bijvoorbeeld wel mag met een BSD licentie.

Er zijn hier wel wegen omheen door bijvoorbeeld DKMS te gebruiken en daar wordt door anderen in hun reacties ook over gesproken. Ik snap dus ook niet dat je een +2 krijgt.

[Reactie gewijzigd door rbr320 op 22 juli 2024 14:33]

[afterburn]

Ook @dec0de ze mogen prima een driver als binary blob in hun kernel hangen zonder daar de source code van vrijgegeven hoeft te worden en dit distributeren. Er is gewoonweg genoeg ruimte voor MS om bepaalde dingen te doen zonder de GPL licentie te schenden. Als ze die driver opensource maken, zoveel te beter maar ook dat betekend nog geen DX12 ondersteuning in Linux zoals sommigen lijken te denken.

[latka]

Nee, dat mag dus niet: "The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. ". Buiten de kernel mag wel. Je mag geen blobs in de kernel stoppen tenzij je kan aantonen dat je ontwikkelaars de hele dag in een hex-editor changes doorvoeren op die blob.

[Alfa1970]

Dat mag niet, maar het gaat niet om een binary blob maar een open source driver.
Dat die open source driver uiteindelijk via een virtualisatie laag met closed source praat maakt het volgens mij niet helemaal zo zwart wit als men het hier in vele posts stelt.

[Alfa1970]

Het is een aanpassing voor WSL2 dus waarom je WSL1 erbij haalt snap ik niet.

Daarnaast snap ik ook niet hoe je een driver kan construeren als een aanpassing aan de kernel code??
Er wordt niets aan de kernel zelf aangepast, er wordt alleen een extra driver toegevoegd voor een heel kleine niche, namelijk de WSL2 omgeving.
Dat die driver op kernel level draait wil toch niet meteen betekenen dat het een aanpassing van de kernel zelf is? Die kan perfect 100% identiek zijn zonder enige wijziging.

Voorts gaat het om een koppeling met een virtualisatie laag en niet om een rechtstreekse koppeling met de D3D technologie. Ik zie het meer als een VMWare Tools of Virtual Box Tools toevoeging (bevatten beide ook een of meer kernel drivers) die praat met de VMWare danwel VB danwel HV virtualisatie laag. Dat die laag aan de andere kant praat met D3D of OGL maakt in dat geval dan toch niet uit ?
En als datzelfde voor VMWare geen probleem is, waarom zou dat dan voor Microsoft wel een probleem moeten zijn?

De WSL 2 Linux kernel is wel een aangepaste kernel, en is voor zover ik kan zien volledig open source onder GPLv2. Ik ga er daarom vanuit dat er geen probleem is om een extra driver toe te voegen die daarnaast ook nog open source is.

[rbr320]

Het is een aanpassing voor WSL2 dus waarom je WSL1 erbij haalt snap ik niet.

@afterburn had het over WSL/WSL2. Ik wees hem er even op dat dit 2 totaal verschillende dingen zijn.

Daarnaast snap ik ook niet hoe je een driver kan construeren als een aanpassing aan de kernel code??

Dat is nu juist precies het punt. Drivers zitten in Linux in de kernel tree en vallen dus per definitie onder de GPL. Dat je bij het compileren van de kernel er voor kan kiezen bepaalde drivers niet mee te nemen veranderd daar niets aan. De driver die MS gaat maken moet dus hoe dan ook open source zijn onder de GPL versie 2 of 3. Zoals ik aan geef kan je hier via DKMS wel onder uit komen maar dat is een nachtmerrie om te beheren want je moet dan bij iedere kernel update je module opnieuw compileren. Dit is wat bijvoorbeeld NVidia doet met hun grafische driver voor Linux. Het kan dus wel, maar het is niet wenselijk.

Er wordt niets aan de kernel zelf aangepast, er wordt alleen een extra driver toegevoegd voor een heel kleine niche, namelijk de WSL2 omgeving.

Dat is precies het probleem. Zelfs als MS met een volledige open source kernel driver komt onder de GPL, dan nog is de enige functie van deze driver om 2 stukken gesloten code aan elkaar te knopen, namelijk een Linux userspace D3D12 driver aan de ene kant en Hyper-V aan de andere kant. De geschiedenis leert ons dat de Linux kernel maintainers dit soort code niet accepteren omdat het technisch gezien wel voldoet aan de eisen, maar de intentie is om onder de GPL uit te komen.

Voorts gaat het om een koppeling met een virtualisatie laag en niet om een rechtstreekse koppeling met de D3D technologie. Ik zie het meer als een VMWare Tools of Virtual Box Tools toevoeging (bevatten beide ook een of meer kernel drivers) die praat met de VMWare danwel VB danwel HV virtualisatie laag. Dat die laag aan de andere kant praat met D3D of OGL maakt in dat geval dan toch niet uit ?
En als datzelfde voor VMWare geen probleem is, waarom zou dat dan voor Microsoft wel een probleem moeten zijn?

Zoals hierboven beschreven is het eigenlijke probleem de gesloten code van MS waar deze open source driver aan beide kanten mee gaat praten. In de voorbeelden die jij noemt is de Linux userspace code open source, evenals delen van de virtualisatie software.

[Reactie gewijzigd door rbr320 op 22 juli 2024 14:33]

[Alfa1970]

[/delete]

[Reactie gewijzigd door Alfa1970 op 22 juli 2024 14:33]

[mbb]

. Drivers zitten in Linux in de kernel tree en vallen dus per definitie onder de GPL.
Nou weet ik vrij weinig van linux, maar zelfs bij mijn enkele experimenten met Mint werd al de optie aangeboden om 'proprietaire drivers' te downloaden voor de videokaart (en netwerk?).
Dus ik neem aan dat je best drivers gesloten kan houden, als je ze maar niet mee compileert maar als 'aparte installatie' aanbied. (Vinkje tijdens installatie van WSL?)

[rbr320]

Dat klopt, deze drivers (waarschijnlijk de GPU drivers van Nvidia en netwerk drivers van Broadcom) worden geïnstalleerd via DKMS. Ik zeg dat al elders in deze discussie, het kan wel maar het is een nachtmerrie om te onderhouden.

[dec0de]

Uhm, heb je de GPL licentie gelezen, gpl v2 om precies te zijn? Daar staat in dat de source code beschikbaar moet zijn als je het distributeerd
Dat dus

[HollowGamer]

Helaas houden veel bedrijven zich daar niet aan. Ik tijd geleden heb ik bijvoorbeeld Realtek gevraagd voor de GPL sources van een wireless driver, nooit antwoord op gekregen, terwijl ze dit wel verplicht zijn onder die voorwaarden.

Uiteindelijk komen ze er wel weer onderuit, zoals het vrijgeven van sources pas naar X tijd of juridische kosten.

[Reactie gewijzigd door HollowGamer op 22 juli 2024 14:33]

[dec0de]

Klopt! Tesla is hier ook een voorbeeld van. Of ZTE. Of eigenlijk veel te veel bedrijven. Er is hier een site voor die je financiële steun kunt geven om deze bedrijven te bevechten, vaak krijg je dan wel een soort van resultaat, maar dan veel te oud. Bijvoorbeeld een 9 maand oude source versie bij tesla. Als iemand die site weet, zeg het!

[Heidistein]

Hmmm. Nou, dit lijkt heel mooi, maar het schuurt toch wel. Dit wordt een kernel implementatie om vervolgens tegen closed-source binary blob userspace drivers aan te babbelen. Lijkt mij wat gek...

https://lore.kernel.org/[e-mail]/T/#t

[Sebazzz]

Dat is niet anders als met de NVIDIA drivers echter.

[Eonfge]

Klopt. Daarom ook dat NVidia bijvoorbeeld nog geen Wayland ondersteund. Dit nieuwe display protocol hangt op een stukje Kernel functionaliteit genaamd Direct Rendering Manager, en NVidia weigert daarmee te koppelen.

NVidia is zo zuur op Linux, dat de laatst render servers die ik heb opgetuigd allemaal zijn uitgerust met AMD kaarten. 10% performance verlies is het echt wel waard als je daarvoor veel minder koppijn hebt.

[GertMenkel]

Niet alleen dat, Nvidia heeft meer vage constructies. Zo kun je maximaal vier schermen aansturen per X sessie vanwege beperkingen in hun driver (ook al heb je zes grafische kaarten). Ook is combineren van oude en nieuwe kaarten lastig aangezien support moet overlappen qua softwareversie.

Ik neem de kutheid van het bedrijf mee in welke grafische kaart ik mensen aanraad. AMD heeft bij iedere nieuwe release driverissues maar ze zijn in ieder geval geen Nvidia.

[Eonfge]

Ik heb nu nog een NVidia kaart, maar wanneer deze aan vervanging toe is wordt het zeker een AMD. NVidia werkt bij mij prima, zelfs op mijn zakelijke laptop, maar het is toch niet zo goed geintergreerd als AMD. Als ik toch 400.- ophoest voor een kaart, dan ook liever 1 die het gewoon doet vanaf een USB-stick.

[Amanoo]

Ik kan me dit wel voorstellen. Nvidia is erg prima als het werkt, en meestal werkt het ook wel met de proprietary drivers. Maar er blijven altijd toch een paar dingen die niet lekker werken. Wayland, soms doen de drivers moeilijk met custom kernels, en zo nog wel een aantal dingen. En AMD is daar toch wat makkelijker in.

[latka]

En daarom kreeg NVidia ook de vinger van Torvalds. Dat het kan betekent niet dat het een goed idee is voor het bedrijf of de klanten. In het geval van Nvidia is het echter geen goed idee voor de klanten van Nvidia HW want de support is gewoon minder.

[beerse]

[way off topic]
Je moet bij mij niet in de schuur kijken hoe een zootje het daar is,
Aan de andere kant, ik ben wel weer toe aan een goed schuurfeest

[MazeWing]

Wat een zure reacties vanuit de Linux (FSF) community. Het is toch zeer mooi en fijn dat Microsoft dit mogelijk maakt. Dat het closed source blijft is harstikke logisch. Het grote voordeel hiervan is dat het dadelijk een stuk minder noodzakelijk wordt om voor bepaalde applicaties om te moeten schakelen naar windows.
Ook op het gebied van gamen biedt dit zeer veel mogelijkheden.

Maar de reactie vanuit de community vind ik typisch een gevalletje van: "een dropje aanbieden en zeuren dat het geen zuurtje is..."

[terabyte]

Dat je het concept van vrije software en de filosofie van FSF niet begrijpt is één ding, maar om ze dan maar neer te zetten als ondankbare zuurpruimen omdat Microsoft aan filantropie doet en je tevreden moet zijn met alles wat je 'krijgt', zegt helemaal niets over FSF...

[Reactie gewijzigd door terabyte op 22 juli 2024 14:33]

[3dmaster]

Nee, het is meer misbruik maken van open source. Ze trekken dingen naar windows toe maar ze geven niks terug, tenminste zo lees ik het. Als het tot gevolg zou hebben dat directX 12 onder linux beschikbaar komt is het nog tot daar aan toe, maar volgens mij gebeurt dat niet met wat ze willen. Enkel een mogelijkheid om vanuit de linux kernel directX te kunnen gebruiken van de host.

Als native linux draaiend persoon heb ik er dus ook niks aan.

[Estel]

Geven niets terug, dat is een grap toch? Microsoft is een van de grootste contributors aan verschillende open source projecten, waaronder Linux. Hoezo geven niets terug...

[RJG-223]

Geven niets terug, dat is een grap toch? Microsoft is een van de grootste contributors aan verschillende open source projecten, waaronder Linux. Hoezo geven niets terug...

Dit is geen gift. Dit is een verplichting die ze geven: als dit opgenomen zou worden, moet de gemeenschap dit in de toekomst blijven onderhouden, terwijl ze er geen voordeel van hebben: de code is alleen bruikbaar als interface tussen twee closed-source binaire APIs.

Als iemand jou bijv. een olifant kado doet, waar je zelf niets aan hebt, die je niet kunt verhuren of verkopen, maar die je wel moet verzorgen: voer, stal/buitenruimte, dienarts, etc. etc., dan is dat geen gift. En als die iemand aan jouw broer eerder een nieuwe auto kado gedaan heeft, of misschien wel aan jou een Rolex, dan betekent dat nog niet dat jij verplicht bent deze zogenaamde 'gift' te accepteren.

[Estel]

Ik heb het niet specifiek hierover natuurlijk, maar over de opmerking dat Microsoft niets bijdraagt aan de Open Source communities. Dan doen ze juist zeer veel en hebben ook al veel eigen zaken Open Source gemaakt. Tuurlijk, met veel zullen ze de bedoeling hebben dat je hun producten gaat gebruiken, maar dat is niet anders dan andere bedrijven natuurlijk.

[RJG-223]

Naar mijn indruk had 3dmaster het over dit specifieke geval: ze doen iets waar alleen zijzelf profijt van hebben, en ze verwachten/hopen dat de linux-gemeenschap daarin meewerkt. En wat dat betreft is het dus nemen en niet geven. En dus wordt het bijna zeker nee.

[3dmaster]

Dat klopt, ik was misschien iets te kort door de bocht. Maar al hun bijdrages zijn niet uit liefde, maar uit noodzaak. En daar had de linux community ook zeker baat bij. Alleen gaat deze aanpassing wel erg ver imho en ik hoop dat de baarden dit niet toe gaan laten. Tegen een dkms oplossing kun je niks doen en dat is dan prima maar dit kan/mag gewoon niet in de kernel komen.

[Gimmeabrake]

Geven niets terug, dat is een grap toch? Microsoft is een van de grootste contributors aan verschillende open source projecten, waaronder Linux.

Ik vraag me af in hoeverre je betere compatibiliteit met Azure en Hyper-V een geschenk aan de Linux community kunt noemen. Natuurlijk zullen ze ook bijdrages leveren aan andere delen van de kernel, maar er zijn veel bedrijven die dat doen. Het door sommigen geschetste beeld dat Microsoft superveel bijdraagt aan open source projecten, is volgens mij een beetje overdreven. Ze dragen bij, en dat doen ze net als bijna alle bedrijven voornamelijk uit eigenbelang. Daar is mijns inziens ook niets mis mee, overigens.

[Estel]

Het is wel veel meer dan dat. Ga maar eens de commits nalopen.

[D0phoofd]

Het is vrij simpel;

The GNU GPLv3 also lets people do almost anything they want with your project, except distributing closed source versions.

Dat is ook direct het vraagstuk wat hier ligt.

[field33P]

Microsoft zal echt niet dom genoeg zijn om niet de broncode vrij te geven van werk onder de GPLv2 (want dat is de Linux-licentie), want dat betekent gelijk dat ze als zijnde grote vis aangeklaagd worden. Naar mijn weten staat de GPLv2 gewoon toe dat er gelinkt wordt naar een closed source binary blob, anders zou NVIDIA ergens in de afgelopen twee decennia allang aangeklaagd zijn.

[dec0de]

Nvidia zit ook niet in de kernel, maar is een externe kernel module, heel belangerijk verschil!

[GekkePrutser]

Een kernel module is ook gewoon onderdeel van de kernel. Hij wordt alleen on-demand geladen. Elke keer dat je je kernel verandert, moet je die 'externe' module ook weer hercompileren omdat hij zo nauw met de kernel verbonden is. Het is eigenlijk gewoon een vast deel van de kernel dat om performance reden los te koppelen is.

Dit is heel anders dan bijvoorbeeld een DLL of een Linux shared library die een stabiele interface met de rest van het programma heeft waardoor je die vanuit meerdere programma's kan aanroepen en niet steeds hoef te hercompileren.

[bdraw]

Linux is wel GNU GPLv2, niet GPLv3: https://en.wikipedia.org/wiki/GNU_General_Public_License. Niet zeker of verschil tussen deze 2 hier zo relevant is.
Volgens http://techrights.org/wiki/index.php/Linux_Foundation heef MS veel macht over The Linux Foundation. Als dit min of meer correct is: ik ben benieuwd hoeveel druk er van deze hoek kan komen.

[Reactie gewijzigd door bdraw op 22 juli 2024 14:33]

[RJG-223]

Als dit min of meer correct is: ik ben benieuwd hoeveel druk er van deze hoek kan komen

Ik denk nul druk. De kernel-ontwikkelaars zijn onafhankelijk genoeg, en hebben volgens mij de linux foundation niet echt nodig. Sommigen worden er wel door betaald, maar die vinden ongetwijfeld snel een andere werkgever als ze (een het extreme geval) de banden met de linux foundation zouden verbreken vanwege ongewenste druk. En er zou een publicitaire rel ontstaan, die de linux-foundation leden, zoals micorsoft, eerder zou schaden.

[bdraw]

Ik hoop het. Die van Techrights zijn wss ook niet te objectief wanneer het Microsoft betreft. Ik vertrouw Microsoft niet teveel (het blijft een bedrijf dat geld moet verdienen, met iets teveel macht), maar de developers die er werken zullen ook wel met de tijd mee zijn zeker. Voor hen zal open source etc ook wel aangenamer zijn om mee te werken. Oa hun interesse in gebruik van Rust programmeertaal vind ik goed.

[Pizzalucht]

Heel fijn. Maar dat zegt nog niet dat de Linux kernel maintainers het moeten opnemen in de mainline kernel tree (en daardoor dus mede de verantwoordelijkheid voor onderhoud overdragen aan de Linux kernel maintainers).

Ze kunnen ook prima een driver aanleveren die via DKMS/package managers werkt.

[oef!]

Ook op het gebied van gamen biedt dit zeer veel mogelijkheden.

Hoe zou dat gaan? Dit is voor Linux systemen die al op een Windows host draaien waarbij /dev/dxg uiteindelijk beschikbaar wordt gemaakt aan een driver op de host zelf (met andere, benodigde functionaliteit) . In een standaard Linux omgeving zul je dit niet hebben.

Verder is het goed dat MS dit doet, het maakt de wereld weer een stukje compatibler.

[wiseger]

Tja er is een verleden met Microsoft. Via een proxy (SCO) hebben ze er alles aangedaan om Linux via rechtzaken kapot te krijgen. Is ze niet gelukt omdat IBM achter Linux ging staan en zij een dikke patenten portefuille hadden inclusief Novell die de rechten op Unix bleek te hebben. Daarna is Linux uitgegroeid tot het server platform waarop grote bedrijven hun software draaien. Microsoft wil de boot niet missen in de opkomst van de grote cloud data centers en meedoen met Google, Amazon, IBM, HP etcetera. Daarom hebben ze hun Azure platform geschikt gemaakt voor Linux.

Dat Microsoft nu zegt Linux te omarmen en graag bij te willen dragen, het zal wel. Velen hebben hun twijfels door het verleden en zijn bang dat Microsfot probeert via de achterdeur gepatenteerde technologie in Linux te krijgen. En dan krijg je rechtzaken zoals destijds met FAT32.

[Reactie gewijzigd door wiseger op 22 juli 2024 14:33]

[Relief2009]

Klinkt in mijn oren als aluhoedjes denken. Op deze manier kun je de duitsers ook nog blijven wantrouwen vanwege het Nazi verleden. Want je weet het maar nooit.

En als we toch met aluhoedjes opdoen bezig zijn, wie zegt mij dat de bepaalde personen in de Linux community niet door AWS worden betaald om Microsoft constant in een slecht daglicht te stellen?

Weet je wat een feit is: MS heeft Linux nodig om veel geld te verdienen aan Azure. Dat is de reden waarom ze zo zwaar inzetten op Linux.

[Reactie gewijzigd door Relief2009 op 22 juli 2024 14:33]

[wiseger]

Ik zou 13 jaar na de oorlog idd nog niet de tegenstander vertrouwen. Track record zegt wel degelijk iets over een bedrijf. Gezien het vrij recente verleden van MS is voorzichtigheid geboden.

[N8w8]

Het klopt wat je zegt over het verleden.
Toen vond Ballmer dat MS het allemaal anders moest doen, en is daarom ook zelf gestopt.
Veel mensen zijn daar idd wantrouwend over, maar veel mensen hebben daar ook vertrouwen in.
In plaats van gevoelens, kan je je ook laten leiden door technische/legale implicaties en regels.
Maak je je zorgen over submarine patenten, kan je bijvoorbeeld dit lezen en je afvragen of dat nog een probleem zal zijn.

[PommeFritz]

edit: de 1e reactie van Eonfge hierboven legt het completer en beter uit.

[Reactie gewijzigd door PommeFritz op 22 juli 2024 14:33]

[RJG-223]

Maar de reactie vanuit de community vind ik typisch een gevalletje van: "een dropje aanbieden en zeuren dat het geen zuurtje is..."

Het is meer als het aanbieden van een shotje heroine. Logisch dat mensen daarover klagen. Óók als het 'gratis' is. Als ze dit goedvinden, dan is het hek van de dam, en dan gaan héél véél bedrijven onder dezelfde voorwaarden ook kernel-code uitbrengen. Waardoor de kernel voor de gemeenschap niet meer te onderhouden is (want: niet te testen). En het hele principe van een open-source kernel wordt dan op termijn van binnenuit uitgehold. Om nog niet te spreken van de mogelijkheid dan de kernel-licentie als gevolg daarvan in een rechtszaak deels onderuit gehaald wordt.

De Linux-community heeft een licentie gekozen, en heeft daar goede redenen voor. Microsoft dient zich aan die licentie te houden. Ze kunnen niet op hun eigen voorwaarden gaan profiteren van het werk van anderen. Als anderen van het werk van Microsoft willen profiteren, zonder dat daar iets tegenover staat, dan vindt Microsoft dat ook niet goed.

[KoosKieper]

Dus na "embrace" zitten we nu in de "extend" fase?

[walteij]

Als je Triple-E er inderdaad bij wil halen, zitten we al een hele tijd bij Extend.
Microsoft is al sinds 2015 een grote sponsor van Linux. Linux VM's zijn de grootste afnemers in Azure (ik meen vorige week gelezen te hebben dat 51% van de VMcores voor een Linux VM is).

Er lopen al jaren geen (proxy) rechtszaken tussen Microsoft en Linux (distributeurs). Binnen de Microsoft community zijn er mensen die zich afvragen of er wellicht een grote distributeur opgekocht gaat/zou moeten worden door Microsoft.
De houding van Microsoft t.o.v. open source is gigantisch veranderd. Sterker nog, de gehele houding van Microsoft naar computing is enorm veranderd.
Microsoft zelf vol in op hun cloud platform. Of dit nu Azure, Office365 of Dynamics365 is, daar zit voor Microsoft het goed te verdienen geld.

Microsoft is groot geworden met de desktop voor eindgebruikers. Desktops zijn al zo goed als EOL, steeds meer bedrijven stappen over op laptops en alleen serieuze gamers zullen een desktop PC hebben. Normale mensen hebben een laptop of een tablet om op te werken.
Op laptops is MS nog wel groot, op tablets niet.
Microsoft kan bijna geen geld meer verdienen met het verkopen van Windows op de desk/laptop, terwijl de clouddiensten ieder jaar met 10-tallen procenten groeit, mede dankzij Linux.

Daarom denk ik (maar hoop ik ook) dat de derde E (Extinguish) verleden tijd is. Microsoft ziet dat het Linux in Azure nodig heeft, als ze Linux dus gaan Extinguishen, schieten ze zichzelf (meerdere keren) in de voet.

[Reactie gewijzigd door walteij op 22 juli 2024 14:33]

[latka]

Het hangt heel erg van de MS top af. Nu is het Balmer niet meer en kunnen dit soort dingen. Als er volgend jaar een ander zit dat kan het zo maar weer dat men de 2e en 3e E weer vollop gaat toepassen. Garantie in dit soort zaken zijn tot aan de deur.

[walteij]

Money rules the world.
Op dit moment is ruim 50% van de CPU's in azure toegekend aan een linux machine.
Meer info over Linux op Azure in dit artikel:

More than 50% of VM cores runs Linux on Azure
Linux-based images comprise 60% of Azure Marketplace images
Top 100 Microsoft customers deploy Linux workloads on Azure
Azure Tuned Kernels provide 25% faster network throughput
Microsoft supports all major Linux distros, like: Red Hat, SUSE, Ubuntu, Oracle Linux, Debian, CentOS, CoreOS, and OpenSUSE (Related: Azure also supports FreeBSD)
Azure offers two natively supported managed Kubernetes orchestration services: Azure Kubernetes Service, and Azure Red Hat OpenShift

Je moet dus als CEO heel sterk in je schoenen staan, wil je van je grootst groeiende bedrijfsonderdeel ineens >50% van de inkomsten gaan schrappen.

Daarnaast is deze verandering in cultuur (diensten en platform ipv OS en software leveren) ingezet onder Ballmer. Onder zijn leiding is BPOS (voorloper van Office365) en Azure opgestart. Onder zijn leiding werd Linux op Azure ondersteund.
Nadella had toen al wel heel veel in te brengen over de te volgen richting, maar het is Ballmer geweest die dit allemaal heeft geinitieerd.

[GekkePrutser]

Dat is waar... Van Ballmer naar Nadella was een enorme verandering maar dat kan ook weer andersom gebeuren.

Nou is Ballmer daar ook niet echt neergezet vanuit zijn leiderschapskwaliteiten maar meer omdat hij altijd al de rechterhand van Bill Gates was. Ik denk dat na de problemen rondom hem ("Linux is a cancer", stoelengooien, vele mislukte produkten zoals WinPhone, Zune enz) de directie van Microsoft wel voorzichtiger is ). Nadella vond ik een heel goede keuze van ze.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 14:33]

[HollowGamer]

Het is waar dat de houding t.o.v. opensource en Linux daartegen veranderd is sinds er eindelijk 'betere' mensen aan het roer staan bij MS, maar als je puur naar de Linux-kernel bijdragen kijkt dan zitten deze vooral aan de HyperV kant.

Er worden nu wel mondjesmaat andere bijdrages gedaan door MS zoals hun FAT-driver, maar deze zat volgens de kernel-devers nou niet echt lekker in elkaar en zijn ze dus naar een alternatief overgestapt van Samsung. Op gebied van Samba (SMB) doen ze naar mijn weten vrij weinig en is het allemaal reverse engineering.

Ik wil niet zeggen dat MS niets doet voor Linux, volgens mij doen ze ook financieel een bijdrage leveren aan de LF en hebben ze genoeg open-source spul (VSCode is echt top op Linux), maar er zijn bedrijven die toch wel meer bijdragen aan de Linux-kernel.

[beerse]

Welke 'embrace' bedoel je? Die van de jaren '90, die van het begin van deze eeuw?
Volgens mij zijn ze nu bezig met de 'embrace' van windows 10 c.q. wsl.

[diondokter]

"List of Top 10 Linux environments in 2022: Number 1 might surprise you!"

Alle grappen daargelaten, MS is goed bezig!
Ze zijn ook bezig om alternatieven aan te bieden voor hun C++ API's. (WinRT/Rust bijvoorbeeld)
Package manager wordt toegevoegd.

Het zou zomaar kunnen zijn dat over een aantal jaar Linux niet meer 'het' platform voor devs is.

[thomasmoors]

"List of Top 10 Linux environments in 2022: Number 1 might surprise you!"

Alle grappen daargelaten, MS is goed bezig!
Ze zijn ook bezig om alternatieven aan te bieden voor hun C++ API's. (WinRT/Rust bijvoorbeeld)
Package manager wordt toegevoegd.

Het zou zomaar kunnen zijn dat over een aantal jaar Linux niet meer 'het' platform voor devs is.

In mijn ervaring zit ook minder dan 5% van de developers op Linux om te ontwikkelen op dit moment.

[cracking cloud]

Ik weet niet hoe statistisch verantwoord dit is, maar in 2019 was het 25% linux en 47% windows (https://insights.stackoverflow.com/survey/2019)

[dec0de]

Nadeel is, is dat de meesten op SO web devs zijn, en dan ook nog eens 90% nieuwelingen. Interessant zou zijn wat de gebruikers na 3 jaar gebruiken (spoiler alert, meer linux).

Ik heb ook geen SO account, ik lees en anders word het IRC of zoiets. Veel “geavanceerde” programmeurs gebruiken practisch alleen de (api) docs. Als beginneling is dat vaak best spannend / overwhelming.

[diondokter]

Het ligt er heel erg aan in welke kringen je kijkt.

Volgens de Rust survey is 51% op Linux.
Bij de Go survey zit 31% exclusief op Linux en 66% gebuikt Linux en misschien nog iets anders.
En Jetbrains zegt dat 48% op Linux zit.

Maar ja, windows enterprise software zal vooral op windows geschreven worden ja.

[Verwijderd]

Het ligt er natuurlijk ook maar aan voor wie de applicatie bedoeld is. Een server applicatie wordt steeds minder gebouwd op Windows en eerder in een container gestopt.

Ik denk dat iedere organisatie tegenwoordig wel snapt dat enkel een Win32 applicatie gewoon niet meer OK is en zich meer richten op web apps (server applicaties).

[jimshatt]

Ontwikkel je op Linux als je .Net Core microservices in een Linux Docker container draaien?

[wiseger]

Het ligt er natuurlijk wel aan of je bedoelt ontwikkelen op een computer met Linux als OS of software ontwikkelen dat op een Linux server gaat draaien. Dat laatste is namelijk de standaard geworden bij alle grote bedrijven. Vandaar Azure ook zo inzet op Linux ondersteuning, het is de grote markt.

[brabbelaar]

Het zou zomaar kunnen zijn dat over een aantal jaar Linux niet meer 'het' platform voor devs is.

Linux is niet het platform voor devs.

[diondokter]

Ik heb 'het' ook in quotes gezet. Persoonlijk gebruik ik voornamelijk Windows.
Maar het neemt niet weg dat heel veel mensen er wel zo over denken.

[brabbelaar]

Het is op zich geen rocket science, hoeveel surveys hierboven ook aangehaald worden. Waar wordt de meeste software voor ontwikkeld? Niet Linux. Windows, Mac, Android, iOS. Linux is groot in de wereld van servers. Maar je maakt mij niet wijs dat iedereen lekker crossplatformsoftware aan het schrijven is op Linux of zelfs maar dat de meerderheid van webdevelopment op Linux plaats vindt. Onder programmeurs die ik ken is Mac oververtegenwoordigd, maar vaak is het gewoon Windows.

[Verwijderd]

Dat je op Linux voor Windows ontwikkeld hoeft nog niet te betekenen dat het crossplatform is, kan ook gewoon crosscompiled zijn. Het testen van software is het sowieso handiger op een kale installatie in een VM.
Daarnaast bestaat er meer software dan alleen voor desktops, smartphones of websites. Microcontrollers, IoT-devices of aansturing van industriële machines is een zeer grote markt waar je alleen in laatste Windows zult aantreffen. Met de sector waar je zelf in bevind komt dan ook het verschil in wat de meeste programmeurs die je kent, gebruiken. In mijn omgeving is Windows vooral nuttig voor ontwikkelaars omdat Outlook en Word erop draaien.

[rbr320]

Je doet je nickname in ieder geval eer aan. Serversoftware ontstaat niet zomaar spontaan, dat moet ook ontwikkeld worden dus beweren dat er voor Linux veel minder software wordt ontwikkeld als voor andere platformen is onzin. De waarheid is dat dit niet op een goede manier te meten is. En dat webdevelopment dat op een Mac of op Windows plaats vindt zal uiteindelijk zeer waarschijnlijk gaan draaien op een Linux server.

Uiteindelijk hangt het dus sterk af van je definitie of je kunt beweren of Linux het platform is voor ontwikkelaars of niet. Het is misschien niet het platform waar ze op werken, maar vaak wel het platform waar de code op draait. Bovendien zijn er genoeg runtimes, middlewares en platform agnostische talen waardoor het niet eens uit maakt waar jij je code (voor) schrijft.

[Chris_147]

Waar wordt de meeste software voor ontwikkeld?
Ik zou denken web.
Waarop draaien de meeste webservers?
Linux

2e vraag is vrij gemakkelijk te beantwoorden, 1e vraag lijkt me pakken moeilijker.
web-based software lijkt mij het populairst, maar heb ik geen bewijzen voor.
Android is trouwens ook Linux.
Maar zie ook: https://www.explore-group...ment-platforms-2019/bp45/

Trouwens hoe bepaal je meeste software?
Mandagen development, regels code (wat met verschillende programmeertalen?), omzet, installaties, ...?

"Onder programmeurs die ik ken is Mac oververtegenwoordigd, maar vaak is het gewoon Windows."
Ontwikkelen OP is iets anders dan ontwikkelen VOOR.

[Reactie gewijzigd door Chris_147 op 22 juli 2024 14:33]

[latka]

Ik zou Linux gebruiken als de VPN infra en remote desktop technologie van de meeste bedrijven niet opgeknoopt is aan Windows. Dus nu maar Windows met Cygwin en een VM met Linux. Dit ook omdat de Windows tooling grotendeels opgeknoopt is aan de GUI en dat werkt voor geen meter als je ontwikkelt en grote datasets hebt (nee, het past echt niet in Excel). Commandline Windows is beter geworden (resizable console na 30 jaar) maar het blijft zwak.

[wiseger]

Linux is het platform waarvoor de devs ontwikkelen. Dat ze dat op een Windows computer doen maakt niets uit, de software wordt straks gehost op een Linux bak in de cloud. De hosting partij verdient zijn geld met het aanbieden van virtuele Linux servers en niet virtuele Windows servers.

[timvisee]

Dit staat dus DirectX gebruik toe onder Linux. Het addertje onder het gras: dit werkt alleen op een Windows host. Dit is specifiek voor WSL dat op Hyper-V draait op een Windows host. Zoals in het artikel staat worden de DirectX calls in feite geforward (door middel van paravirtualisatie technieken). DirectX op een native Linux host gaan we voorlopig dus niet zien.

[Eonfge]

Nee, daar is dus nu een grote discussie over los gebarst:
Eonfge in 'nieuws: Windows Subsystem for Linux krijgt ondersteuning voor DX12...

Tenzij Microsoft nu ook DirectX openbaart, en de patenten vrij geeft, dan gaat dit niets doen voor Linux gebruikers.

[- peter -]

Er is veel kritiek hierop en het zal zoals t nu eruit ziet niet zo 1,2,3 worden opgenomen in de kernel. T is jammer dat Microsoft niet voor echt opensource gaat, maar goed, je kan niet verwachten dat DirectX open gegooid word.
Hoe dan ook, dit is vooral om machine learning developers in Windows te houden.

[_Thanatos_]

Er is geen verplichting om Linux-onderdelen opensource te maken. Je kunt gewoon closed-source modules tegen de kernel aan plakken. Ik zie het probleem niet. Het is ook al deccennia zo, dus het kan niet zo zijn dat closed source nu opeens niet meer kan.

[borft]

Nja, niet helemaal. Code die direct met de kernel interfaced moet wel degelijk opensource zijn. Zie bv de kernel interface van de Nvidia driver voor Linux.

[Maulwurfje]

Wat is het idee van Microsoft hierachter. Op dit moment wordt X11 meegeleverd, straks levert Microsoft voor Linux op Windows dus via virtualisatie DirectX12 api. Wil Microsoft de Linuxs gebruikers op Windows (vaak ontwikkelaars/coders) meer bekend maken met DirectX12, of stroomlijnt het gewoon haar product en zorgt ervoor dat overal in Windows DirectX12 wordt gebruikt.

[Exirion]

Hiermee wordt WSL echt volwassen. Ik gebruik het inmiddels een jaar of 4 en in het begin was de file system performance nog vrij matig. Daar kwam later verbetering in. Met een X-server kon je in ieder applicaties met een UI draaien, al was dat ook vrij traag. Maar het was al heel wat je een redelijk complete Linux-installatie kon draaien. Inmiddels kun je een kernel draaien en is de grafische acceleratie ook een feit. Nog even en ze kunnen Windows wel uitfaseren