Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

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'.

Door Olaf van Miltenburg

Nieuwscoördinator

20-05-2020 • 10:51

151 Linkedin

Submitter: Sp3ci3s8472

Reacties (151)

Wijzig sortering
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 20 mei 2020 14:13]

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 20 mei 2020 11:56]

Native DX op Linux zou natuurlijk súuuuper tof zijn. 8-)
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.
Zit er niet erop te wachten, heb eerder liever vulkan voor in de plaats.
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 20 mei 2020 12:37]

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.
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.
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).
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 :Y)
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.
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.
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
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?
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.
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)
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 20 mei 2020 12:05]

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.
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.
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.
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
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 foxgamer2019 op 20 mei 2020 13:24]

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!
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/l...JvP6A@mail.gmail.com/T/#t
Dat is niet anders als met de NVIDIA drivers echter.
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.
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.
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 20 mei 2020 11:48]

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.
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...
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.
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.
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.
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.
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.
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.
Nvidia zit ook niet in de kernel, maar is een externe kernel module, heel belangerijk verschil!
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.
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.
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.
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 20 mei 2020 13:00]

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 20 mei 2020 13:17]

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.
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.
"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.
"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.
Ik weet niet hoe statistisch verantwoord dit is, maar in 2019 was het 25% linux en 47% windows (https://insights.stackoverflow.com/survey/2019)
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.
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.
Ontwikkel je op Linux als je .Net Core microservices in een Linux Docker container draaien?
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.
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.
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.
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 20 mei 2020 13:07]

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.
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.
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.
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.
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.
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 :+


Om te kunnen reageren moet je ingelogd zijn


Apple iPhone SE (2020) Microsoft Xbox Series X LG CX Google Pixel 4a CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True