Windows-subsysteem voor Linux verlaat bèta in Fall Creators Update

Microsoft heeft bekendgemaakt dat het Windows-subsysteem voor Linux, waarmee gebruikers bijvoorbeeld Linux-tools kunnen draaien, in de herfst zijn bètastatus verliest. Vanaf de Fall Creators Update is het daarmee een volledig onderdeel van Windows.

Microsofts Rich Turner meldt dat het subsysteem voor Insiders al langer niet meer in bèta is sinds build 16251. Insiders hebben al geruime tijd toegang tot de functie, die werd geïntroduceerd als onderdeel van de Anniversary Update. Begin deze maand kwam Ubuntu beschikbaar als app in de Windows Store. Volgens Turner verandert er weinig aan het subsysteem zelf, al zullen gebruikers nu gebruik kunnen maken van het reguliere ondersteuningsproces bij problemen.

In de blogpost worden een aantal scenario's genoemd waarvoor het subsysteem expliciet niet is bedoeld, waaronder het draaien van een Linux-distributie bovenop het subsysteem in productieomgevingen. Met het verlies van de bètastatus zal het nog steeds niet mogelijk zijn om Linux-bestanden vanuit Windows te benaderen, al moet hier in de loop van de tijd verandering in komen. Er zijn momenteel bovendien geen plannen om ondersteuning te bieden aan x-servers-apps.

Waar het systeem wel voor bedoeld is, is bijvoorbeeld het uitvoeren van Linux-processen vanuit de Windows-opdrachtprompt en andersom, naast het draaien van Linux-commandlinetools voor ontwikkeling en beheer. Microsoft kondigde de Fall Creators Update in mei aan.

Reacties (113)

[Xieoxer]

Het is nog steeds niet mogelijk om vanuit Linux een Windows mount aan te spreken. Zelfs niet als je die mount omzet naar een disk in Windows. Als dit soort simpele dingen niet mogelijk zijn, dan stap ik liever meteen over naar Linux of MacOS. Het probleem van Microsoft is dat het een laag boven Windows op is, ipv van samengevoegd in het OS. Het zal nooit zo vlekkenloos werken.

Fixed typo's.

[Reactie gewijzigd door Xieoxer op 26 juli 2024 22:55]

[cracking cloud]

Linux in Windows werkt rechtstreeks op de kernel van windows.

Zie o.a. https://blogs.msdn.micros...6/06/08/wsl-system-calls/, https://blogs.msdn.microsoft.com/wsl/2016/11/08/225/ en https://blogs.msdn.micros...ystem-for-linux-overview/

[Verwijderd]

Dit vind ik wel grappig. Linux is technisch gezien een kernel. Die kan je helemaal niet draaien op een andere kernel(virtualizatie telt even niet). Deze subsystem bestaat dan ook niet echt uit Linux maar uit de gnu userspace tools.

[cracking cloud]

Voor mij als leek heet alles wat op de Linux kernel draait Linux Ik heb er te weinig verstand om te snappen of ik in de kernel loop te prutsen of in glibc of gnu of wat dan ook. Maar in ieder geval bedankt, ik heb kennelijk nog wat huiswerk te doen zie ik ...

[mOrPhie]

De Linux kernel is een onderdeel van Linux. Je kunt de kernel eraf halen en een virtual api van de kernel mappen op de NT-kernel en de rest van Linux intact laten. Dat is wat MS gedaan heeft. De enige die het GNU/Linux noemen is de FSF zelf, tot ongenoegen van Linus Torvalds.

[Reactie gewijzigd door mOrPhie op 26 juli 2024 22:55]

[BeosBeing]

De Linux kernel is een onderdeel van Linux.

Strikt genomen natuurlijk niet. De kernel komt van Linus (+ team) en heet Linux, de rest van het systeem komt van de FSF en anderen onder de naam GNU.

De enige die het GNU/Linux noemen is de FSF zelf, tot ongenoegen van Linus Torvalds.

Het is misschien nerdisch muggeziften maar strikt genomen klopt die nam GNU/Linux wel.
Bij de FSF zijn ze ook nog steeds bezig met het ontwikkelen van een ander kernel, de Hurd genaamd, waarmee de GNU tools en userland te bundelen zou moeten zijn.

Debian kFreeBSD, Gentoo FreeBSD, Arch BSD, ManjaroBSD zijn een paar voorbeelden van distributies die het GNU userland gebruikten met de kernel van FreeBSD. Ook met de kernels van OpenBSD en NetBSD zijn er projecten hiervoor geweest (o.a. bij Debian). Afgezien van Debian kFreeBSD zijn deze inmiddels allemaal gestopt omdat de steeds verdergaande integratie van systemd en udev het steeds moeilijker maakt om een andere kernel te gebruiken.

Toekomstige versies zullen dus steeds minder GNU-distributies zijn en steeds meer systemd-distributies en het neemt zelfs bepaalde functies over van de kernel.

[mOrPhie]

De ene noemt het --volledige operating system-- GNU/Linux en de ander noemt het Linux. De kernel daarentegen heeft toch echt maar _één_ naam en dat is de "Linux Kernel".

[BeosBeing]

De ene noemt het --volledige operating system-- GNU/Linux en de ander noemt het Linux.

Klopt. In de praktijk noemt vrijwel iedereen het volledige operating system bij de naam Linux maar strict genomen is GNU/Linux natuurlijk beter. In die zin is je oorspronkelijke opmerking

De Linux kernel is een onderdeel van Linux.

in die zin niet correct. De kernel is niet onderdeel van Linux, de kernel is Linux en onderdeel van GNU/Linux en de rest van het systeem* komt van het GNU-project. (* het console gedeelte in ieder geval, de grafische schil komt daar dan nog weer bovenop, bestaat ook weer uit twee delen, x-windows (XFree86 of Wayland) en een windowmanager (fluxbox, IceWM, Openbox, Fvwm, Blackbox, TWM, Metacity, Compiz Fusion) of een desktop environment (XFCE, GNOME, KDE, LXDE, LXQt).)

De kernel daarentegen heeft toch echt maar _één_ naam en dat is de "Linux Kernel".

"Linux Kernel" is eigenlijk al dubbelop, een pleonasme zoals ze dat in de taalkunde noemen (andere voorbeelden: witte sneew, ronde cirkel). Bij andere systemen zoals UNIX, FreeBSD e.d. is dat niet zo. Bij MacOS heeft de kernel trouwens ook zijn eigen naam: Darwin. Niemand haalt het in zijn hoofd om MacOS te benoemen als Darwin OS.

De enige die het GNU/Linux noemen is de FSF zelf, tot ongenoegen van Linus Torvalds.

Dat Linus graag het hele systeem als Linux bestempeld wilt zien kan ik wel begrijpen, Linux is behoorlijk essentieel er in, en het streelt mogelijk zijn ego maar het is mijn inziens niet correct. Daarmee bagatelliseer je het werk dat alle deelnemers aan het GNU-project gedaan hebben (en dat zijn er meer als alleen de FSF). Van de andere kant is het ook logisch dat we het niet GNU/Linux/XFree86/GNOME gaan noemen of zoiets. Strikt genomen is dat misschien juister maar in de praktijk is het niet werkbaar. GNU/Linux gaat nog wel. De grafische schil is zowiezo inwisselbaar voor een andere en daarboven niet noodzakelijk.

Tot slot: Android is ook Linux, maar geen GNU/Linux. Meamo daarintegen wel en Meego en Jolla's Sailfish volgens mij ook.

[mOrPhie]

in die zin niet correct. De kernel is niet onderdeel van Linux, de kernel is Linux en onderdeel van GNU/Linux en de rest van het systeem* komt van het GNU-project.

"Linux Kernel" is eigenlijk al dubbelop,

Ok, prima joh.
https://en.wikipedia.org/wiki/Linux_kernel

[Reactie gewijzigd door mOrPhie op 26 juli 2024 22:55]

[BeosBeing]

Tja ik weet dat het een beetje muggenziften is en het wikipedia-artikel is zo genoemd omdat er nu eenmaal verwarring is. Dit is ook een mooie: https://en.wikipedia.org/wiki/Linux_(disambiguation)
Linux is ook een astroïde:
Helaas geen eigen Engelse pagina maar wel: https://de.wikipedia.org/wiki/(9885)_Linux
en https://ssd.jpl.nasa.gov/sbdb.cgi?orb=1;sstr=9885

[mashell]

Maar in ieder geval bedankt, ik heb kennelijk nog wat huiswerk te doen zie ik ..

Nee hoor, je kunt dat huiswerk gewoon laten zitten. Het is namelijk totaal onbelangrijk, eigenlijk gewoon puristisch geneuzel. En dat is een compliment aan Linux. Qua architectuur is het misschien niet al te mooi maar het is inmiddels wel goed uitgerijpt en samenhangend.

[DCK]

Dit is niet juist.

Het Windows Subsystem for Linux is een implementatie van Linux systemcalls. De userspace tools voor Linux, inclusief de GNU tools, roepen (meestal via glibc) functies op de kernel aan - de syscalls. WSL is een laag die die Linux syscalls vertaalt naar de bijbehorende Windows syscalls. Daarom kun je random Linux binaries in WSL droppen en die werken dan gewoon (voor zover Microsoft de features compleet heeft geïmplementeerd).

Dit is hetzelfde principe als WoW64 - het subsysteem dat je op een 64-bit Windows 32-bit applicaties laat draaien. Het is ook hetzelfde principe als de historische subsystemen op Windows die je OS/2 en POSIX-programma's liet draaien (dat was met name een ding in de Windows NT-periode).

Het is óók hetzelfde principe als Wine al vele jaren implementeert om Windows-programma's op Linux te draaien. Dit hoewel Wine veel meer doet dan alleen het vertalen van syscalls, omdat zij heel veel andere Windows-componenten niet vrij mogen verspreiden zoals Microsoft dat met open source Linux-distro's wel kan.

[Dreamvoid]

Dat is het inderdaad - je kan allerlei userspace OSssen bovenop een kernel draaien, en van origine (toen MS en IBM nog samen werkten aan het OS wat later Windows NT werd) was de kernel ook ontworpen om zowel OS/2, Win32 en UNIX (POSIX) subsystems te draaien. Er is ook jarenlang een UNIX subsystem voor Windows geweest (en zelfs een text-only OS/2 subsystem), waarmee Microsoft aan de POSIX-compatibility eisen van oa het Amerikaanse defensie ministerie kon voldoen.

[Reactie gewijzigd door Dreamvoid op 26 juli 2024 22:55]

[mOrPhie]

Je verwart "linux" met de "linux kernel".

[Reactie gewijzigd door mOrPhie op 26 juli 2024 22:55]

[JackBol]

What else is there? Vanaf glibc upwards is alles GNU.

[mOrPhie]

Zeker. GNU/Linux == Linux. De kernel heet Linux kernel: https://www.kernel.org/

[JackBol]

No mij 1 linux binary die niet in kernelspace draait, en ik geef je gelijk.

[mOrPhie]

Joh, geloof wat je wil geloven, maar hier staat het hele verhaal: https://en.wikipedia.org/wiki/GNU/Linux_naming_controversy.

[JackBol]

Die link geeft mij net zoveel gelijk als jou.

[mOrPhie]

Manmanman. Is het nu echt zo ingewikkeld?

a combination of GNU software and the Linux kernel as "GNU/Linux" or "Linux".

Ofwel: GNU/Linux is Linux en de Linux kernel is de kernel.

[Gimmeabrake]

Door de stijgende populariteit van Alpine Linux(https://alpinelinux.org) in de containervirtualisatiewereld van docker & co, is het gebruik van de term GNU/Linux zo gek nog niet. Alpine Linux is namelijk een Linuxdistributie die standaard zonder GNU-tools draait, waardoor het onderscheid relevant wordt.

[JackBol]

Dat vind de helft van de wereld. De andere helft vindt wel degelijk dat Linux en GNU/Linux twee verschillende dingen zijn. Dit staat notabene in jouw link.

[MrFax]

Linux en Linux kernel zijn beide exact hetzelfde iets.

Ik denk dat je GNU/Linux bedoelt. Linux als OS zou amper kunnen bestaan zonder GNU.

[Reactie gewijzigd door MrFax op 26 juli 2024 22:55]

[Verwijderd]

Linux IS letterlijk de naam van de kernel. Dat Linux door mensen wordt gebruikt voor het hele ecosysteem doet hier niet van af(doe ik zelf ook).

[Archcry]

Linux is de kernel.

[mashell]

Hmm. Eigenlijk vind ik dat de linux "kernel" veel meer bevat dan eigenlijk in een kernel zou horen. Het is gewoon al een half OS. GNU voegt er de andere helft aan toen.

[JackBol]

Alles wat linux heet is onderdeel van 1 compile. Okee, er zijn nogal wat kernel modules die een microlernel purist misschien liever in userspace ziet, maar in de monolitische kernel die linux is, is alles dus onderdeel van kernel space.

[2green]

Behalve de onderdelen die naar userspace gepushed zijn

[JackBol]

Een verzamelnaam voor de kernel plus wat precies?

[Archcry]

Strict gesproken is Linux enkel en alleen de kernel, het operating system is de kernel met de tools.
De naam van het operating system is daarom in veel gevallen GNU/Linux of GNU+Linux (tenzij je een andere toolset gebruikt).
De kernel zonder een toolset is niet bruikbaar en is daarom ook geen OS.

[Reactie gewijzigd door Archcry op 26 juli 2024 22:55]

[Archcry]

Dit artikel suggereert dat we beide een punt hebben, het ligt er maar net aan wiens standpunt je het meest aanspreekt.

[Alfa1970]

Je ziet het verkeerd denk ik.
Het lijkt erop dat je dit ziet als een vervanger voor Linux, en zo is het niet bedoeld.
Het probleem dat hiervoor bestond was dat het ontwikkelen van software voor Linux en het beheren van Linux systemen vanuit Windows nogal omslachtig was.
Met behulp van dit systeem is dat een stuk eenvoudiger gemaakt.

Het is ook geen laag die bovenop Windows draait. Het is een sub systeem dat ernaast draait op kernel level. Het userland deel is gewoon Linux.

[2green]

Dit systeem gaat voor heel wat meer gebruikt worden vrees ik, is ook bedoeld een aantal userbases op windows te houden die langzaam naar linux gingen.

[nlooije1]

Bedoel je binnen dit subsysteem is het niet mogelijk om een Windows share te mounten?
Ik heb vorige week er mee zitten spelen en met:
sudo mount drvfs /share_path /mnt_path
Lukte dat mij wel. Zie ook: https://blogs.msdn.micros.../wsl-file-system-support/

[Blokker_1999]

Neen, stel je hebt een netwerkschijf gekoppeld in windows op N:\ dan vind je deze niet zomaar terug onder je gemounte bestandssystemen in de shell. Je moet deze telkens handmatig opnieuw mounten.

[nlooije1]

Dat gebeurt idd niet automatisch maar je kan altijd in je .bashrc de schijf laten mounten elke keer als bash start

[JackBol]

Is er een losse root partitie wanneer je wsl-bash start?

Zoals ik het nu zie, is wsl eigenlijk een soort container bovenop de windows kernel, met eigen userspace. Alleen de hardware resouces worden gedeeld, alles boven kernel level zijn eigenlijk twee losse OS'en.

[Dreamvoid]

Precies, dat is inderdaad hoe het werkt. Dit is niet nieuw overigens, eind jaren 80 is Windows NT specifiek ontworpen om diverse OSsen (subsystems) op 1 kernel te draaien, en er is jaren een OS/2 (text-only) en POSIX (UNIX) subsystem op de Windows kernel geweest, wat na Windows 2000 Server min of meer gedropt is toen hun grote klanten stopten met UNIX-compatibility als harde eis.

[Reactie gewijzigd door Dreamvoid op 26 juli 2024 22:55]

[leuk_he]

Dat was voor mij ook de reden het te laten voor wat het is, en maar weer met een cygwin shell mijn linux scriptjes te draaien. Want de linux kernel (of hoe je het ook noemt) ziet niet de rechten en de netwerkshares van de windows OS.

Cygwin heeft een veel grotere performance impact, maar kan wel scherm en files delen die je met windows gebruikers rechten kan benaderen.

[ZaPPZion]

Wat een rare naamgeving is het eigenlijk, alsof een subsysteem van windows voor linux is gemaakt. Ik had het denk ik linux subsystem for windows genoemd

[Brent]

Er zit geen byte Linux in dit stuk software. Hoe Microsoft Ubuntu (niet Ubuntu Linux!) op Windows werkende heeft gekregen is door een API laag over de Windows kernel te gieten die de Linux kernel emuleert, althans, zodanig dat Ubuntu minus Linux werkt. In die zin dus een Windows subsystem in plaats van Linux.

[ApexAlpha]

Inderdaad, waar een Linux distributie zoals Ubuntu vaak wordt aangeduid met GNU/Linux waarbij Linux de kernel is en GNU de rest van de software (veel, in ieder geval).

In dit geval zou het dus GNU/NT moeten zijn. Er zitten veel Unix tools in die nu op NT werken, met een direct inplementatie. Maar het is juist niet Linux, want die kernel is dus vervangen door de NT kernel van Microsoft!

[Roel911]

GNU de rest van de software (veel, in ieder geval).

Correctie: veel van de software wordt onder de GNU licentie uitgegeven.

[N8w8]

Het meeste in de meeste Linux distro's is gebouwd op/met een GNU build environment (libc/compiler/make/autotools/binutils), en de "unix laag" is grotendeels ook GNU (bijv. coreutils).
Minder diep gelegen lagen zijn mss niet van GNU (al hebben ze wat je zegt wel vaak een licentie ontworpen door GNU) maar er is wel degelijk een echte GNU basis.
Of je zulke distro's daarom ook "GNU/Linux" moet noemen valt over te twisten, maar er is iig meer aan de hand dan alleen de licenties.

[rbr320]

Ik denk dat de meeste mensen op Tweaker.net technisch genoeg zijn om je reactie te begrijpen, maar voor diegenen die toch nog verward zijn over de terminologie: wat @Brent bedoelt is dat er geen regel Linux kernel code in WSL aanwezig is, de Linux kernel API's worden inderdaad via een driver laag ge-emuleerd en calls worden uiteindelijk door de NT kernel afgehandeld. Dat betekent ook dat WSL niet 100% API compleet is ten opzichte van de echte Linux kernel.

De software die vervolgens binnen WSL draait wordt vaak in 1 adem genoemd met Linux, maar valt eigenlijk grotendeels onder GNU, een verzameling gebruikerssoftware die ooit is ontwikkeld om onder de licentierestricties van Unix uit te komen. Daarom heet een volledig werkende Linux distributie eigenlijk GNU/Linux of GNU+Linux. WSL zou je dus eigenlijk ook GNU+NT kunnen noemen.

[MSalters]

Het is ironisch dat GNU al jarenlang aan een eigen kernel bezig is (GNU/Hurd), als alternatief voor GNU/Linux, maar dat ze door nota bene Microsoft worden ingehaald

[rbr320]

Ze zijn helemaal niet ingehaald door Microsoft. Een volledige kernel schrijven inclusief drivers voor hardware en weet ik wat er allemaal nog meer bij komt kijken is wel even iets anders dan het maken van een vertaallaag tussen een reeds functionerende kernel waarvan je zelf de broncode hebt en goed gedocumenteerde open source software. Ik wil niet zeggen dat het geen knap werk is van Microsoft, maar het is van een heel andere orde van grote.

De ontwikkeling van de Hurd kernel werd flink vertraagd toen de Linux kernel uit kwam, dit was namelijk een prima alternatief en dus was de noodzaak om de Hurd kernel verder te ontwikkelen niet zo groot meer. Er is echter nog steeds ontwikkeling op dit gebied en er zijn ook wel degelijk distributies te vinden die deze kernel aanbieden. Zo wordt er onder andere een Debian GNU/Herd distributie ontwikkeld.

[Reactie gewijzigd door rbr320 op 26 juli 2024 18:21]

[GateKeaper]

Emuleren is niet het juiste woord hier. Het subsystem vertaald de functieaanroepen naar het windows systeem.

Dit heeft nogal een positieve impact op performance. Verschil is 1 woord, maar enorm in de impact.

[koelpasta]

Emuleren is niet het juiste woord hier. Het subsystem vertaald de functieaanroepen naar het windows systeem.

Huh? Wat is het verschil dan tussen 'emuleren' en 'vertalen' ?

[Bruin Poeper]

[...]

Huh? Wat is het verschil dan tussen 'emuleren' en 'vertalen' ?

De betekenis van Emuleren is nabootsen.

Het verschil tussen Chinees nabootsen en Chinees vertalen kan je wel inzien, denk ik.

[koelpasta]

Het verschil tussen Chinees nabootsen en Chinees vertalen kan je wel inzien, denk ik.

Als ik via 'chinees emuleren' een zinnig gesprek kan houden dan zie ik het verschil inderdaad niet in.

[Laurens-R]

Het is heel simpel. Emuleren is de exacte functionaliteit nabootsen (inclusief de innerlijke werking van de kernel functies). In dit geval hebben we het over een wrapper; de functies worden vertaald naar windows system calls. Intern werken de windows functies anders dan hun linux counterpart, maar in dit geval is het enige wat telt de in- en output van de functie; niet de exacte implementatie van die functie. Als die implementatie ook nog eens hetzelfde zou moeten zijn; dan heb je het over emulatie (= nadoen), waarbij een wrapper een tweerichtings vertaler is. Dat merk je ook in performance; vertalen is sneller dan nadoen.

Ken je Wine op linux? Dit is precies hetzelfde qua opzet maar dan omgekeerd (van linux naar windows system calls). WSL is eigenlijk gewoon een API wrapper, net zoals Wine dat is.

[Reactie gewijzigd door Laurens-R op 26 juli 2024 22:55]

[koelpasta]

Emuleren is de exacte functionaliteit nabootsen (inclusief de innerlijke werking van de kernel functies).

Dan vallen dus de meeste gamehardware emulatoren af? Want die emuleren de functionaliteit niet helemaal en vaak werken bepaalde dingen niet of slecht en een 'echte' emulatie (zoals jij die hier definieert) zou zelfs om een moderne PC teveel cpu tijd vergen.

Intern werken de windows functies anders dan hun linux counterpart, maar in dit geval is het enige wat telt de in- en output van de functie;

Maar dit geldt ook voor de instructie voor bijvoorbeeld een geemuleerde cpu. Dat wordt ook met functies 'gewrapt' om het uit te kunnen voeren op het platform waar je de emulator op draait.

niet de exacte implementatie van die functie.

Meeste emulatoren hebben ergens functies die niet exact op dezelfde manier worden geimplementeerd als op het oorspronkelijke platform.

Ken je Wine op linux?

Ja, ik ken wine.
Desalnietemin zullen er ook in wine bepaalde stukken geemuleerd moeten worden omdat linux bepaalde functionaliteit gewoon niet biedt.
Ik vind wine dan ook geen goed voorbeeld van een expliciete non-emulator, al doet de naam natuurlijk anders vermoeden.
In de Wine faq wordt een beetje vaag gedaan. Ze noemen het een 'compatibility layer' en prijzen het aan vanwege zn snelheid, maar geven vervolgens ook weer een beetje toe dat je het als emulator kan zien.

Volgens mij is het enige verschil dat een 'standaard' emulator met name hardware emuleert terwijl dit soort dingen een softwareomgeving emuleren. Beide zijn wat mij betreft vormen van emulatie.

[batjes]

Emuleren is niet native. Als je Linux zou emuleren zou dit bv op de Win32api draaien zoals cygwin of andere Linux op Windows oplossingen.

Vior het linux subsysteem is er een nieuwe API direct op de kernel geschreven waar enkel en alleen dit linux subsysteem mee praat.

Dit is net zo native als Win32 applicaties.

[koelpasta]

Volgens mij zijn er zat zaken die 'native' zijn onder windows die alsnog emulatie worden genoemd door microsoft.

[rbr320]

Dit heeft nogal een positieve impact op performance.

Euhm... blijkbaar niet echt
https://plus.google.com/u...9475093/posts/1UqjejQbQA6

[MSalters]

Onzin verhaal daar. " Alles moet als root draaien" - het is nota bene een Ubuntu distributie, root login is disabled! Waar het verhaal dan vandaan komt dat alles als root moet draaien?

I/O performance is inderdaad wel een issue. Je hebt twee filesystems in WSL: Het pure Linux deel (wat dus niet vanuit Windows te benaderen is) en de gedeelde Windows drives (te benaderen als /mnt/c/ ). Die laatste zijn niet al te snel vanuit WSL, want Linux benadert ze alsof het remote disks zijn.

[rbr320]

Dat je op Ubuntu standaard niet direct kan inloggen als gebruiker root klopt, maar je kan nog steeds sudo -s of sudo su - doen om een root shell te krijgen.

Maar daar ging het me niet eens om. Het feit dat deze gebruiker misschien iets raars heeft gedaan met inloggen maakt niet meteen zijn meetresultaten incorrect, en daaruit blijkt dat er nog nog wel een performance issue is met WSL. Misschien komen er binnenkort nog andere benchmarks uit die anders laten zien, maar voorlopig is dit de informatie die ik heb. En als het inderdaad klopt dan hoop ik dat Microsoft er iets aan doet.

[David Mulder]

Ik denk niet dat je er aan ontkomt dat Windows kernel + Windows rest (NT) + Linux rest (GNU) te draaien trager is dan enkel Linux kernel (Linux) + Linux rest (GNU).

Sowieso, ik denk dat het voornamelijk handig is voor developers, en voor developers is het een BIG DEAL. En ja, tijdens development maakt performance sowieso niet zo veel uit. Het is gewoon extreem handig dat je je software zowel op Linux als op Windows kunt testen en draaien en dat je Linux-only software kunt gebruiken. Bijvoorbeeld op m'n vorige werk maakten we een linux server applicatie en de andere twee team leden waren Linux en Mac gebruikers respectievelijk. Gezien dat beide Unix systemen zijn is dat redelijk makkelijk voor hun, maar met Windows betekende dat dat ik een VM moest gebruiken (ik zou ook naar Linux zijn geswitched, maar m'n laptop miste goed werkende drivers).

[rbr320]

Ik beweer ook nergens dat er geen overhead zou mogen zijn, maar de meting waar ik naar link laat zien dat WSL een factor 2.5 trager is dan native linux, en een factor 1,5 trager dan Linux in een VM. Dat is wel een erg groot verschil.

[MSalters]

Het blijft een vreemd idee, dat mensen denken dat een kernel draaien tijd kost. Een kernel handelt verzoeken af van programma's, en dat kost tijd ja. Maar als de NT kernel verzoeken afhandelt van een Linux process, dan komt daar geen tijd bij voor "Windows rest(NT)". Het verzoek gaat van Linux process naar syscall laag naar NT kernel., en komt nergens in de Win32 laag. WSL is een alternatief voor de Win32 laag.

[David Mulder]

Maar er is beperkte processor kracht beschikbaar. En ja, zowel Windows als Ubuntu heeft tal van achtergrond processen. En die draaien beide als je ubuntu bovenop Windows start.

[MSalters]

WSL draait geen systemd, in tegenstelling tot Ubuntu op een Linux kernel.

[batjes]

Het linux deel is wel vanuit Windows te bereiken, de linux disk is een map ergens in je user folder.

[cdwave]

Lijkt op colinux (http://www.colinux.org/) die deed hetzelfde. Alle kernel calls worden naar Windows calls omgezet. Werkte prima, en veel efficienter dan VM, maar is intussen verlaten.

[MSalters]

Eerlijk gezegd lijkt het er niet op. Een WSL process is een native NT proces, en er zijn geen trucs met de MMU nodig. In theorie zou je zelfs Shared Memory kunnen hebben tussen een Win32 proces en een WSL proces (de huidige API's hebben geen namespace mapping, dus de twee processen kunnen elkaar niet vinden.)

Omdat het een NT proces is, kunnen ze dus ook de file cache delen. Dat si natuurlijk efficienter dan de coLinux oplossing waar elk OS zijn eigen cache heeft.

[Mraedis]

Ik ben dit topic binnengewandeld met dezelfde veronderstelling. Een soort Wine van MS zelf uit had nog eens handig kunnen zijn.

[hcQd]

Is een beetje raar. Vroeger noemde ze het ook andersom: OS/2 Subsystem for NT.

[Chuk]

Zoals ik al eens eerder zei, er zijn in de loop der jaren al zoveel alternatieven om bash commands op windows te draaien dat dit er niet echt meer toe doet. Gebruik zelf al jaren git bash met een custom console en dit voldoet prima aan mijn script-noden. Maar goed, beter laat dan nooit, MS.

[mjz2cool]

behalve dan dat je hier niks extra's voor hoeft te installeren. je zet het subsystem aan, en download uit de store een distro, en klaar.
je kunt hier ook via de normale repo's software downloaden, wat voor zover ik niet kan met bijvoorbeeld git bash.

[Reactie gewijzigd door mjz2cool op 26 juli 2024 22:55]

[xDiglett]

Exact. Ik zou rsync wel eens willen gebruiken.

[GateKeaper]

Dan is de vraag of een service ook mogelijk is. Zou je iets in je cron gooien, wordt het dan ook netjes uitgevoerd op 't gewenste tijdstip? Zonder de terminal open te hebben wel te verstaan.

[xDiglett]

WSL is niet bedoeld om background processen te starten. Wellicht kijken naar task scheduler van windows?

[GateKeaper]

Ja, die kende ik uiteraard al. Het ging me in deze juist om de nog diepere integratie.

[MSalters]

Dit is meer dan alleen bash commando's Dit is de echte bash, bit voor bit identiek aan de Ubuntu bash. En het is dus ook de echte GCC, niet MinGW.

[Reactie gewijzigd door MSalters op 26 juli 2024 22:55]

[GateKeaper]

Vooral voor compilers wel handig ja. Op windows is er altijd weer gezeik met `node-gyp`.

[DigitalExorcist]

Precies. En 'vi' werkt nou eenmaal handiger dan Notepad, da's ook wel weer een voordeeltje.

[batjes]

Geef mij naar liever nano.

[Michelli]

Nano vond ik in het begin handig, omdat het vrij toegankelijk is voor beginners. Echter met wat oefenen heb ik nu vim redelijk onder de knie en ik vind deze toch wel fijner werken, onder andere vanwege de syntax highlighting

[RoestVrijStaal]

Als dat je grootste minpunt van nano is, je kunt gewoon syntax highlighting ervoor instellen.

Ikzelf zit er tussenin, omdat ik vi/vim op het werk moet gebruiken.
Het nadeel van commando's van vi/vim is dat je ze uit je hoofd moet weten / moet opzoeken terwijl bij nano die zichtbaar zijn en je makkelijker aan de slag kan ondanks dat je dan misschien meer handelingen en toetsaanslagen moet maken dan bij vi/vim.

Overigens, syntax highlighting voor config bestanden of data/text zoals markdown en json snap ik nog wel, maar het begint te ruiken dat je beter een volwaardig IDE kunt gebruiken ipv met texteditors stoeien.

offtopic:
Ik heb sommigen ontmoet die heel stoer stonden te doen dat ze alles met vi/vim/emacs deden maar als er iets van een klasse moest worden gerefactored of een interface moest worden extract begonnen ze zuur te kijken

[Reactie gewijzigd door RoestVrijStaal op 26 juli 2024 22:55]

[DigitalExorcist]

Ja, maar stel dat je in een lap tekst alle eerst letters van een zin met een hoofdletter wil beginnen, dan is vi/vim je beste kameraad... (als je dat epos van een commandoregel uit je hoofd kent dan )

[RoestVrijStaal]

Mijn antwoord suggereert alsof optie A en optie B vergeleken wordt en dat optie C de winnaar is van de vergelijking, maar in jouw voorbeeld ben je met de opmaak van je text bezig en dan lijkt me LibreOffice een betere optie

Maar voor nano is er ook een Search en Replace met regex out-of-the-box beschikbaar.

[Reactie gewijzigd door RoestVrijStaal op 26 juli 2024 22:55]

[DigitalExorcist]

Nee dat was maar een voorbeeldje. Er zijn een aantal functies in vi te doen die Notepad, zelfs Word, nog steeds niet kunnen...

[batjes]

Ach het ging me om het oude Vi(m) vs nano (vs emacs). Ik vind het allemaal best, heeft allemaal zijn voordelen en nadelen. Persoonlijk prefereer ik nano, want het werkt wat simpeler. Ik gebruik soms vele maanden achter elkaar linux niet, dan slippen er nog wel eens wat commandos tussen uit.

[Verwijderd]

Real men use Emacs.

[hiddepolen]

Ook al zijn niet alle features van je Windows installatie te gebruiken vanuit het Linux subsystem, toch vind ik het goed hoe Microsoft dit aanpakt. Ze proberen een stap in de goede richting te zetten om Windows voor al hun klanten zo aantrekkelijk mogelijk te maken (van dev tot bejaarde). Volledige inter-operability zal er naar mijn mening nooit komen: de systemen werken op een te verschillende wijze.

Het Linux subsystem is gemakkelijk te gebruiken en perfect om een lokale Linux dev omgeving mee op te zetten. Zet maar eens nginx, PHP 7.1, Redis en een MariaDB instance in Windows op, en je bent gelijk een dag verder. Dit is een goede oplossing, in tegenstelling tot alleen Bash op Windows draaien, waar je de native Linux software niet hebt.

[batjes]

Het is wel mogelijk. Kost alleen werk. NT kan in theorie allerlei subsystemen of OS/kernel API calls aan.

Dat linux een filebased kernel is en NT object oriented doet hier weinig aan af. NT kan namelijk ook als filebased kernel werken.

Php, redis en mariadb zijn met 2 vingers in de neus aan te klikken om te installeren. Gewoon via IIS.

[Shebang]

Geef mij maar Git-bash (onderdeel van Git for Windows: https://git-for-windows.github.io/) In deze terminal zitten de meeste gangbare tools (cat/sed/less/curl/ssh/rsync/etc.) die native werken op het Windows filesystem, zonder gekloot met Cygwin oid. Ik heb aan het begin gespeeld met dit Ubuntu subsystem, maar ik vond het niet werken. Uiteraard kan je met Git-bash geen Linux tools draaien die er geen onderdeel van zijn (geen apt-get install), dus daarvoor zou dit subsystem wel een uitkomst bieden...

[MSalters]

Probeer maar eens iets ingewikkelders, zoals de Yocto cross-compile omgeving. Die wil toch een echte Ubuntu hebben, en niet "git bash".

[Shebang]

Inderdaad, dat geef ik ook aan in mijn reactie. In zo'n geval wil ik liever native Linux ipv. een subsystem onder windows (of een VM, of een docker image).

[Mitsuko]

Hier laatst gebruik van gemaakt, werkte zonder probleem. Kreeg zelfs UI applicaties aan de praat met Xming, alleen CUDA versnelling gaat nog niet (gelukkig kon ik dat deel native werkende krijgen).

[nlooije1]

Hebben andere mensen ook significant verschil gemerkt in compilatie-tijden tussen dit subsysteem en een pure Linux build? Ik snap dat er altijd wat IO overhead zal zijn maar ik zie echt verschillen van factor 5-10. Niet echt heel werkbaar dus.

[MSalters]

Hangt nogal af van je file system locatie, is dat VolFS of DrvFS (/home of /mnt/c) ?

[amx]

Ik vraag me af of de Tweakers redactie al overlegd heeft waar GoT topics hierover moeten worden geplaatst. Non-Windows Operating systems kun je het nu niet echt meer noemen

[stuiterveer]

Microsofts Rich Turner meldt dat het subsysteem voor Insiders al langer niet meer in bèta is sinds build 16251.

Best vreemd eigenlijk, dat een product betastatus verlaat binnen een beta release.

EDIT: mensen lijken het punt te missen. Zou het niet logischer zijn om deze uit beta te halen op het moment dat die Windows-build zelf ook de beta verlaat? Dit staat los van software die je zelf installeert en functies die al lang en breed aanwezig waren en niet in betastaat verkeerden.

[Reactie gewijzigd door stuiterveer op 26 juli 2024 22:55]

[KoningsGap]

Is dat echt heel vreemd? Deze beta release zit tjokvol met software die allang geen betastatus meer heeft maar gewoon vaste prik is op iedere windows installatie.

[stuiterveer]

Wat ik meer bedoel is dat een functie die hiervoor in beta zat, dus niet al bijvoorbeeld vanaf de release van Windows 10 standaard aanwezig was en niet in beta zat, uit de beta wordt gehaald binnen een Windows release die nog altijd een beta is. Zou het niet logischer zijn om deze uit beta te halen op het moment dat die Windows-build zelf ook de beta verlaat?

[KoningsGap]

Klaar is klaar! Past prima bij de hedentendaagse technieken als scrum enzo.

[mjz2cool]

waarom zou een bepaald stukje software niet uit de beta kunnen binnen een os wat nog beta is? dus als je insider gebruikt, en installeert andere software, is dat ook gelijk beta?

[Reactie gewijzigd door mjz2cool op 26 juli 2024 22:55]

[stuiterveer]

Dat is een kromme vraag, wanneer je zelf andere software installeert binnen een beta maakt dat niet automatisch ook beta-software daarvan. Die twee staan totaal niet met elkaar in verband.

[mjz2cool]

op die manier staan dit linux subsystem en windows zelf ook niet met elkaar in verband. is gewoon een los stuk software wat wel ingebouwd is.
standaard zit ook outlook mail bijvoorbeeld in windows 10, dat is ook geen beta meer, ookal gebruik je een insider preview

[Reactie gewijzigd door mjz2cool op 26 juli 2024 22:55]

[stuiterveer]

Mijn hele vraag staat los van functies die al lang en breed aanwezig waren en niet in betastaat verkeerden. Mail staat hier dus los van, het hele subsystem niet.

[mjz2cool]

maar het subsystem staat hier toch ook los van? als microsoft dit klaar heeft voor een niet beta, dan kan dit toch al uit de beta zijn terwijl het os dat nog niet is?

[Reactie gewijzigd door mjz2cool op 26 juli 2024 22:55]

[mutley69]

Ikzelf vindt het niet verstandig om aan het al zo stevig te patchen windows-systeem nog veel extra OS en emulatielagen die op hun beurt onderhoud vergen te moeten laten draaien. Ik ga die optie dus slopen. Als ik een linux wil - zal dat wel op de cloud draaien of in een VM of native - niet onder windows (misschien wel onder een vm op windows).
Gewoon gezond verstand - deze dienst is enkel bruikbaar voor heel specifieke toepassingen - maar als't veilig moet - denk ik dat er toch best is goed over nagedacht wordt.

[stuiterveer]

Standaard staat dit subsystem niet aan, je hoeft er dus niks uit te slopen.