Microsoft brengt WSL 2 2.0 uit met mirrored-netwerkmodus en IPv6-ondersteuning

Microsoft heeft een grote update uitgebracht van Windows Subsystem for Linux. WSL 2.0.0 krijgt onder andere een compleet vernieuwde netwerkoptie die de Windows-instellingen spiegelt en IPv6-ondersteuning heeft. Ook is het mogelijk om voortaan automatisch schijfruimte vrij te maken.

WSL 2.0.0 is een van de grootste updates voor het Windows Subsystem voor Linux tot nu toe, specifiek voor versie 2 en niet de eerste versie. Eigenlijk gaat het dus om WSL 2 versie 2.0.0. De septemberupdate is inmiddels beschikbaar voor alle gebruikers. Het gaat nog wel om een prerelease, schrijft Microsoft in de releasedocumentatie.

Een van de vernieuwingen in WSL 2.0.0 is een mirrored networking mode. Die moet de traditionele NAT-architectuur vervangen die in het oude WSL zat. Met de nieuwe mirrored modus maakt WSL direct verbinding met het lan of vanuit een localhostadres. IPv6 en multicast worden ondersteund en de stabiliteit van vpn's is verbeterd. WSL krijgt de mogelijkheid om firewallregels en proxyinformatie van Windows over te nemen, en gebruikers kunnen aangeven hoe WSL met dns-requests omgaat.

Een andere belangrijke toevoeging is die van schijf- en geheugenruimte. Gebruikers kunnen voortaan virtuele harde schijven automatisch laten krimpen als die niet meer nodig zijn. Hetzelfde kan worden ingesteld voor geheugencaches. WSL kijkt dan naar cpu-gebruik om te controleren of gebruikers niet meer actief zijn. In dat geval wordt het cachegeheugen automatisch geleegd.

Update: in het stuk is duidelijker gemaakt dat het gaat om versie 2.0.0 van WSL 2 en niet de originele WSL.

Reacties (68)

[Anonymoussaurus]

Wilde zelf updaten door

wsl --update

te doen, maar dat haalde niets uit, dus bronartikel gelezen en blijkt het om een pre-release te gaan (wat overigens niet in het Tweakers-artikel naar voren komt). https://devblogs.microsof...ss-feedback-and-questions

Kan geïnstalleerd worden door middel van het volgende commando in PowerShell:

wsl --update; wsl --update --pre-release

Het is ook mogelijk om direct vanuit de GitHub repository te downloaden: https://github.com/microsoft/WSL/releases/tag/2.0.0

Direct download: https://github.com/micros....0.0_x64_ARM64.msixbundle

[Reactie gewijzigd door Anonymoussaurus op 22 juli 2024 13:45]

[Jerie]

https://github.com/microsoft/WSL/releases?page=1

Tussen die releases staat constant pre-release bij versies x.y.z. Terwijl de daadwerkelijke releases ook gewoon x.y.z volgen. En ze worden vervolgens ook niet uitgebracht als stable. Er lijkt geen logica in te zitten. De laatste release is volgens hen 1.2.5 van 20 April 2023.

En net als @Exirion hier zegt Exirion in 'Microsoft brengt WSL 2.0 uit met mirrored-netwerkmodus en IPv6-ondersteuning' snap ik ook he-le-maal niets van hun versioning van WSL1 en WSL2 en nu WSL 2.0.0.

Om nog maar te zwijgen over de naam Windows Subsystem for Linux. Logischer is precies andersom: het is het Linux subsystem voor Windows! Maar goed, die traditie zijn ze met SFU begonnen...

Wat een rommeltje. Hopelijk werkt de software beter.

[Reactie gewijzigd door Jerie op 22 juli 2024 13:45]

[ledents]

Windows subsystem for Linux, lijkt op het eerste gezicht een rare naam inderdaad echter kan het wel verklaard worden:
- het is wel degelijk een subsysteem van Windows want het draait in Windows en het heeft als doel Linux functionaliteit aan te bieden !
Logische naamgeving dus!

[sfranken]

Dit. Het is vanuit het "guest" platform bekeken, vandaar de naam.

[TweakerCarlo]

Ik wil ook uitroepteken delen !

[Xellence]

Ooit in vervlogen tijden was er Windows subsystem for POSIX. Dit was ten tijde van Windows NT 4.0 uit 1996. Zie dit als de evolutie daarvan.

[bzuidgeest]

Vergeet wow windows on windows niet. Zijn verschillende versies van. Misschien niet exact hetzelfde, maar het idee is het zeker wel. In dat geval ondersteuning voor oudere Windows versies op nieuwe versies.

[Luminair]

Kijk, dit verdient wat mij betreft dus een +3, want het vult een gat in het artikel op met broodnodige info.

[DigitalExorcist]

Kijk, dát is nuttige info, van die update

[TijsZonderH]

wat overigens niet in het Tweakers-artikel naar voren komt

Behalve dan in de zin "Het gaat nog wel om een prerelease, schrijft Microsoft in de releasedocumentatie."

[Anonymoussaurus]

Stond dat er gisteren ook in? In dat geval: excuses, dan heb ik daar overheen gelezen.

[TijsZonderH]

Yup maar het staat deels achter zo'n linkje dus dat is altijd vaag dus no worries.

[TheNephilim]

Het is alleen zo ontzettend langzaam in vergelijking met Hyper-V...

In mijn situatie (IDE, Docker, verschillende projecten) kan ik de WSL-bestandspaden niet gebruiken en kom ik er gewoon via Windows zelf. Dan zijn I/O acties zo tergend langzaam dat het niet bruikbaar is.

[juiced01]

Huh? Heb je je projecten wel in Linux geplaats? Bijvoorbeeld in een map in je home folder in Linux? Klinkt alsof je de Windows mount gebruikt, die is inderdaad traag.

In Windows (en dus ook je IDE) kan je je Linux distributie(s) benaderen door \\wsl$\<Distributie>\home\username\project etc

[Reactie gewijzigd door juiced01 op 22 juli 2024 13:45]

[TheNephilim]

Ga ik eens op die manier proberen! Tot zover kreeg ik dat nooit goed voor elkaar.

[Exirion]

We hebben WSL1 gehad en inmiddels al een paar jaar WSL2. En nu WSL 2.0.0? Lekker duidelijk gekozen allemaal weer.

[84hannes]

Dit is inderdaad een nieuwe mijlpaal voor Microsoft.

Toen Microsoft rond 2010 de Roslyn C# compiler introduceerde begonnen ze de versienummers weer bij 1.0, net als toen C# rond 2000 geïntroduceerd werd. Daardoor kun je twee totaal verschillende C# 2.0 compilers vinden, en moet je Roslyn toevoegen om de nieuwe te krijgen. Bij .Net Core maakten ze die fout ook, door weer bij 1.0 te gaan nummeren, maar na versie 3 zagen ze hun fout in. Om verwarring met .Net Framework 4.x te voorkomen zijn ze direct naar .Net Core 5.0 gesprongen. Een mens zou hopen dat ze hierna niet meer tegen een vergelijkbare steen zouden botsen.

@TijsZonderH, is er een verklaring waarom Tweakers het in 2020 al over WSL 2 hadden en nu pas over WSL 2.0.0?

edit:
Het lijkt er op dan @DdeM een punt heeft: volgens Wikipedia is de meest recente stabiele versie van WSL 2 1.2.5 uit Augustus, ze zouden nu dus best met WSL 2 2.0.0 kunnen zitten.

[Reactie gewijzigd door 84hannes op 22 juli 2024 13:45]

[Christoxz]

ze zouden nu dus best met WSL 2 2.0.0 kunnen zitten.

Nou je kan gewoon WSL 1 distros draaien met de 2.0.0.
Als ik het goed begrijp zijn WSL1/2 type of distros, die met een andere architectuur draaien, en is '2.0.0' de versie van WSL zelf.

Er zitten in 2.0.0. ook fixes voor WSL1, zie bijvoorbeeld: https://github.com/microsoft/WSL/issues/9231
WSL 2.0.0. bevat dus ook gewoon WSL 1 & 2.

WSL 2.0.0 is dus juist, tegenover "WSL 2 2.0.0"

[Reactie gewijzigd door Christoxz op 22 juli 2024 13:45]

[Jerie]

Noem het dan WSL 3 dat backwards compatible is met 1 en 2.

[Noxious]

Om verwarring met .Net Framework 4.x te voorkomen zijn ze direct naar .Net Core 5.0 gesprongen.

Sterker nog, ze hebben het 'Core' deel laten vervallen; dus je hebt nu:

(meer .NET Framework historie hiervoor)
.NET Core 1.0 (2016)
.NET Framework 4.6.2 (2016)
.NET Core 1.1 (2016)
.NET Framework 4.7 (2017)
.NET Core 2.0 (2017)
.NET Framework 4.7.1 (2017)
.NET Core 2.1 LTS (2018)
.NET Framework 4.7.2 (2018)
.NET Core 2.2 (2018)
.NET Framework 4.8 (2019)
.NET Core 3.0 (2019)
.NET Core 3.1 (LTS) (2019)
.NET 5.0 (2020)
.NET 6.0 (LTS) (2021)
.NET Framework 4.8.1 (2022)
.NET 7 (2022)
.NET 8 (2023)

[Chris7]

Ja WSL2 is al een tijdje uit, was ook verbaasd over deze kop. In het gelinkte artikel komt “2.0” nergens voor dus vraag me af waar dat vandaan komt @TijsZonderH. Het zou me overigens niet heel erg verbazen als het klopt want zoals andere comments noemen doet MS wel vaker raar met versies, maar zou toch verwachten dat ze na WSL2 verder gaan nummeren.

[R4gnax]

Het is inderdaad WLS2 v2.0.0

https://github.com/microsoft/WSL/releases/tag/2.0.0

experimental.autoMemoryReclaim - Makes the WSL VM shrink in memory as you use it by reclaiming cached memory

Halleluja. Zou eens tijd worden.

[Reactie gewijzigd door R4gnax op 22 juli 2024 13:45]

[CodeCaster]

Naast RAM hebben ze ook wat gedaan aan de eeuwig groeiende VHDX hier met Ubuntu+Docker op WSL2...

https://superuser.com/que...space-from-ubuntu-on-wsl2

wsl.exe --manage <distro_name> --set-sparse

[Reactie gewijzigd door CodeCaster op 22 juli 2024 13:45]

[TijsZonderH]

Het moet inderdaad WSL 2 2.0.0 zijn maar mijn god Microsoft wat maak je het weer onnodig moeilijk. Ik verduidelijk het wat in het stuk!

[bzuidgeest]

De eerste regel van het artikel spreekt van een major update aan 2.0. Dus ik denk dat de titel gewoon heel rot gekozen is.

[DdeM]

Ik denk dat dit wsl2 2.0.0 is

[007901jfc]

Van een eerdere blogpost (https://devblogs.microsof...ble-on-windows-10-and-11/)

Now with the Store version of WSL, there are a lot of names to keep track of! Here’s the clear explanation on them. There are two types of WSL distros: “WSL 1”, and “WSL 2” type distros. These matter for how your distro runs and behaves, as they have different architectures. WSL 2 distros have faster file system performance and use a real Linux kernel, but require virtualization. You can learn more about WSL 1 and WSL 2 distros here. There is also the “in-Windows” version of WSL as a Windows Optional component, and WSL in the Microsoft Store as the “Store version of WSL”. These matter for how WSL is serviced on your machine, and what latest updates and features you’ll get. This is just a change on how WSL is serviced, the user experience and product is the same. Learn more here.

With this update our goal is to simplify our versioning story. Since WSL 2 is the default distro type, and the Store version of WSL is the default install location, you can just say: WSL is an app in the Microsoft Store that lets you run actual Linux that integrates directly into Windows.

In 2022 werd versie 1.0.0 van WSL 2 uitgebracht. Dit is versie 2.0.0 van WSL 2.

[machiel]

Een paar jaar dus WSL2 v1.x nu is dus WSL2 v2.0 (bijna) uit. De kop is dus fout.

[philippw]

Het is WSL2 2.0. WSL1 en WSL2 zijn compleet verschillende implementaties.

Niet dat ik dit wil goedpraten (want het is idd erg verwarrend), maar denk dat het zo wel duidelijk is. ;-)

[x280]

Straks krijgen we wsl 2.0.0.0

[Sando]

Of WSL 2 2x2

[DigitalExorcist]

WSL2²

[rko4u]

Ik denk dat het wsl2 2.0.0 v2 wordt.

[klakkie.57th]

Ik heb nooit begrepen wat het voordeel van wsl is, althans ik heb er geen use-case voor die niet beter kan met een locale linux vm of eentje in de cloud.

[Bartmanz]

Windows OS, lokaal ontwikkelen met behulp van bijv. docker containers maar met IDE in Windows.
Dat draait in mijn geval vele malen sneller in WSL dan met Linux in een VM. De intergratie vanuit de IDE is zoveel beter.

[klakkie.57th]

Maar das gewoon kwestie van resources.
Waarom nog lokaal ontwikkelen ? , dat is een keuze.
Ik gooi die vm’s / containers wel op dedicated servers die exact hetzelfde zijn ingericht als de productie omgeving.

[EraYaN]

Een debugger over een connectie met een hogere ping is ook gewoon wel echt verliezen, lokaal is gewoon zo veel sneller. Zelfs binnen het LAN is het eigenlijk al verliezen.

[Bartmanz]

Een dedicated server om te kunnen ontwikkelen vind ik nogal overkill als het (met voldoende resources) gewoon lokaal kan.
Bij een vorige werkgever ontwikkelden we op een dedicated server (met een mannetje of 30) maar dat was altijd gedoe met performances, rechten, tooling, etc.. Lokaal werken was echt een verademing.

Een server die hetzelfde is ingericht als op productie heb je al door het werken met docker containers.

[klakkie.57th]

Maar wel niet zo handig als je met een heel team aan dezelfde applicatie zit te ontwikkelen.

Mijn ervaring is toch wel echt dat wanneer er plots wat in productie moet worden gezet, de developers vergeten zijn dat alles in gescheiden subnets staat met dedicated firewalls ertussen, vandaar mijn opmerking dat een development omgeving zo dicht mogelijk bij de productie omgeving moet aansluiten.

[lenwar]

Onder aan de streep is het natuurlijk net wat goed werkt voor de organisatie. Als ontwikkelaars 'vergeten' dat communicatie afgeschermd is in een productieomgeving, dan heb ik daar een mening over die ik hier niet zal ventileren. Er komt natuurlijk ook een factor (geautomatiseerd) testen bij voordat je in productie een probleem hebt.

Het verschilt ongetwijfeld ook per ontwikkelproject. Is het een applicatie in de cloud, of iets op een klassiekere omgeving die een bepaald type infrastructuur vereist. Is de applicatie geclusterd of draait alles op één node. Ontvangt/verstuurd de applicatie van/naar 60 andere applicaties of is ie redelijk 'alleen' op het netwerk.
Ben je in C/java/python aan het programmeren of ben je voornamelijk bezig met yaml-templates die binnen een framework het gedrag van een applicatie/middleware aan het aanpassen zijn.

Zijn er juridische eisen over de snelheid waarmee aanpassingen gedaan moeten zijn. Mogelijk is er continu veranderende wetgeving die bepaalde ontwikkelingsmethoden afdwingen. (denk aan internationale financiele instellingen. Wereldwijd zijn er dagelijks wetsaanpassingen die al dan niet impact hebben op een of ander)

Er is domweg niet één beste manier van ontwikkelen.

[DigitalExorcist]

Minder overhead; WSL(2) is wat zuiniger dan een aparte installatie van bijv Virtualbox of VMware heb ik het idee.

Ik gebruik WSL2 regelmatig, vanuit m'n werk (cybersecurity) heb ik vaak te maken met tools en scripts die bedacht zijn voor Linux distributies en die kan ik dan naadloos gebruiken vanuit m'n Windows box. Een dedicated Linux OS had me na anderhalf jaar tóch nog wat teveel issues met dagelijks werk (Teams, Office 365 apps, dat soort dingen).

Geheel terzijde maar QubesOS was ook briljant maar dat is al helemáál een gedoe.

[Prince]

Nice. Als nu nog de snelheid omhoog kan van de C schijf onder /mnt/c/ dan is het helemaal goed.
Tot nog toe is de snelheid op de native schijf vele malen hoger dan die onder /mnt/c.
Dat merk je vooral in scripts en laat dit nu net de "kracht van Linux" zijn waarvoor ik WSL vaak gebruik.

[jesse!]

Zelf heb ik al mijn bestanden welke ik in Linux nodig heb (mijn software source code) in WSL staan, en niet op de C schijf. Dan heb je dit probleem niet.
Het is zelden dat ik de source files nodig heb binnen Windows.
Enige is mijn IDE, maar die kan automatisch een remote starten met WSL. (Visual Studio Code)
Daarmee draait mijn IDE in Windows, maar is dat alleen de voorkant. Hij communiceert verder met de VSCode server in Linux (WSL). Terminal in VSCode is dan ook Linux etc. Alle git commandos ook

[Prince]

In mijn geval gebruik ik QGIS op Windows en mutaties op de shapefiles en allerhande CSV's met metadata gebeurt in Linux.

[jesse!]

Heb je al geprobeerd om het om te draaien? De files in WSL plaatsen en dan in QGIS op Windows inladen vanuit WSL.
Zal niet sneller zijn, maar je verplaatst de bottleneck van de schijf naar je view point in Windows, ipv in Linux waar je het "zware" werk doet middels scripts.

Verder overigens eens dat ze het gewoon moeten fixen natuurlijk

[Prince]

Ja, maar daar wringt het schoentje. De scripts is eenmalig, telkens ik een update heb van mijn bestanden.
De QGIS is dagdagelijks bij het maken van rapportjes, kaartjes, etc...

Vroeger kopieerde ik eerst alle data naar binnen de schijf, deed ik de updates en kopieerde ik terug, maar dit gaat over ettelijke GB's.

[Sando]

Tot nog toe is de snelheid op de native schijf vele malen hoger dan die onder /mnt/c.

Het blijft een soort hack waarbij Linux Ext4 op NTFS of wat Windows tegenwoordig gebruikt gesimuleerd wordt. Je kan eventueel ook Linux native draaien en eventuele Windows programma's waar je van afhankelijk bent in WINE.

[EraYaN]

Het is gewoon een netwerk schijf op het Plan 9 protocol. Vandaar de traagheid.

[Prince]

Klopt, maar als je kijkt naar WSL 1, dan kan het wel sneller. Het is om een mij onbekende reden trager geworden.

@Redsandro: De Ext4 is een vhdx bestand zoals je vindt in de hyper-v virtual machines.
Het is vreemd dat je virtualisatie een hack noemt, maar zo zal het ooit wel begonnen zijn :-)
De NTFS schijf is een gemounte drive over een virtuele netwerkverbinding.

[EraYaN]

Omdat WSL1 geen VM is dus zit er geen netwerk tussen. WSL2 is een VM dus moet er door de netwerk barrière heen gegaan worden.

[Crim]

WSL1 heeft veel betere performance op /mnt/c. Als je veel met bestanden op je Windows schijf doet kan je beter die versie gebruiken.

[DaanHetEendje]

IPv6!! Eindelijk! IPv6!! En betere support voor VPNs.. Dit nieuws maakt mij echt heel erg blij.

Al mijn instances zaten nog op WSL 1 omdat WSL 2 geen support had voor IPv6. Dat is minder handig als je werkt met een IPv6 primary/only omgeving.

En de scriptjes om mijn resolv.conf aan te passen op basis van mijn IP adres (Wel of geen VPN aan.. dus wel of niet de VPN DNS server ). Ik hoop dat dit met deze experimental features verleden tijd is.

Ik ga gelijk aan de slag!

[GekkePrutser]

Ik vond WSL1 ook eigenlijk prettiger. Omdat je veel meer integratie had met Windows zelf, het was als een bash console op Windows. Het draaide immers samen in dezelfde kernel. Voor mijn doel, Windows gewoon beheren met een echte *nix commandline, was het ideaal.

WSL2 is 'gewoon' een opgeleukte VM. Leuk als je je dockertjes wil draaien maar daar ging het mij helemaal niet om.

[sfranken]

Dan heb je WSL 1.0 nooit echt gebruikt, want je kon helemaal niet "windows gewoon beheren met een echte nix commandline", want je draaide gewoon een Linux userspace + kernel bovenop de Windows kernel (met vertaallaag ertussen). Dat je Windows $PATH ook aan je Linux $PATH werd toegevoegd was leuk, en kan trouwens vanuit WSL 2 nog steeds (en sneller, want geen vertaalslag meer).

Misschien eerst onderzoek doen voordat je wat spuit?

[ThomasG]

De Windows-kernel is ontworpen als multi-subsystem besturingssysteem. Normaal gesproken hebben de meeste installaties daar alleen het Windows-subsystem draaien. Met WSL 1.0 kwam daar het Linux-subsystem bij. WSL 1.0 had dus eigenlijk helemaal geen Linux kernel, maar een subsystem dat de Windows kernel als Linux kernel deed gedragen. WSL 1.0 draaide dus geen Linux kernel bovenop de Windows kernel. Met WSL 2.0 zijn ze daar vanaf gestapt, en draait Linux stiekem als Hyper-V virtual-machine. Met WSL 2.0 kun je dan ook iedere willekeurige Linux kernel, zelfs je eigen gecompileerde, gebruiken.

[elamre]

Eindelijk. Was altijd zoveel gedoe met de virus scanner van werk die het netwerken zonder extra Tools kompleet onmogelijk maakte. Of altijd naar wsl1 wisselen om het e.e.a. te installeren en dan weer terug te wisselen. Gek dat het niet gewoon wsl3 is

[Kazu]

Vooral het automatisch trimmen van de VHD is echt een hele welkome toevoeging. Op mijn vorige workstation tikte de ruimte die WSL innam de 150 gig aan, en je kunt dan met een hoop workarounds die ruimte wel weer vrijmaken, maar omdat het workarounds zijn blijf je de kans hebben dat je distro corrupt raakt. Dus erg fijn dat ze nu eindelijk (nadat het ticket op Github al bijna 4 jaar open staat, en ruim 200 comments heeft) een officiele oplossing aandragen.

[DutchKevv]

Het super!

Heb nu zelf regelmatig situaties waarin veel Docker containers opspinnen dat het geheugengebriuk alleen maar groeit en amper krimpt. Zo krijg je 64GB RAM wel vol.

Dit maakt men machine weer een stukje blijer, goed bezig MS!

[ricjuh]

Helaas helpt deze update niet voor mijn vpn issue met Cisco AnyConnect vpn, moet nog steeds de 'interface metric' handmatig op 6000 zetten in de adapter eigenschappen voordat de verbinding werkt binnen WSL