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 2 verschijnt voor Windows 10-versies van vorig jaar

Microsoft brengt het Windows Subsystem voor Linux 2 ook naar de Windows 10-versies 1903 en 1909, oftewel de May 2019 Update en November 2019 Update. WSL2 verschijnt vooralsnog alleen voor x64-systemen.

Microsoft meldt WSL2 naar de eerdere Windows 10-versies te brengen omdat gebruikers hierom gevraagd zouden hebben. Gebruikers die de versies 1903 en 1909 van Windows 10 draaien, kunnen deze bijwerken naar OS-buildversies 18362 of 18363; als bij het versienummer het laatste getal 1049 of hoger is, is WSL2 aanwezig. De backport geldt alleen voor x64-systemen. Gebruikers van Windows 10 op ARM64 moeten Windows 10-versie 2004 gebruiken voor WSL2.

Microsoft introduceerde Windows Subsystem for Linux 2 bij de Windows 10 May 2020 Update van begin dit jaar. Met het subsysteem richt Microsoft zich op ontwikkelaars die bijvoorbeeld Linux-tools binnen Windows willen gebruiken. In plaats van op een relatief eenvoudige compatibiliteitslaag, zoals bij WSL1, is de tweede versie gebaseerd op een virtuele machine waarbinnen een door Microsoft zelf ontwikkelde opensource-Linux-kernel en de usermode van Linux draaien. Microsoft werkt eraan om Linux-bestanden binnen WSL vanuit de Verkenner te kunnen openen.

Door Olaf van Miltenburg

Nieuwscoördinator

21-08-2020 • 08:49

73 Linkedin

Submitter: Hoppie

Reacties (73)

Wijzig sortering
Ik gebruik al jaren naar volle tevredenheid Cygwin.
Wat voegt WSL toe ?
Ik zat heel erg op WSL2 te wachten, met name om de belofte dat Docker hierdoor ook sneller zou werken op Windows. Helaas blijkt tot nu toe het tegendeel het geval. Hopelijk gaan ze dit oplossen, dat zou development een stuk aangenamer maken.
Ik lees enkel dat je je bestanden moet verplaatsen naar de linux locatie die je gewoon kan bedaderen via //wsl$/. Dit is bekend, staat ook direct in de vergelijk tabel. https://docs.microsoft.co...dows/wsl/compare-versions

Dus dit is helaas een andere werkwijze, maar werkt erna gewoon netjes.

[Reactie gewijzigd door disjfa op 21 augustus 2020 10:47]

Precies, zorg dat je checkouts in Linux filesystem staan en dan gaat het prima.

Ik werk reeds een jaar met WSL2 icm Docker en werkt lekker snel. Heb een systeem ernaast staan op WSL1 om build scripts voor collega's op WSL1 compatible te maken en verschil is nogal groot. Het starten van de containers duurt echt 5x langer. Enige reden waarom zij nog niet over waren op WSL2 is omdat het tot voor kort alleen in beta windows versies beschikbaar was.
WSL2 als geheel viel mij een beetje tegen tov WSL1. Ja, je kunt dieper in Linux gaan (in WSL1 ontbraken bvb bepaalde syscalls), maar de prestaties zijn er niet op vooruit gegaan.

Ik vind het nog steeds bijzonder dat ze de hele WSL1 architectuur uit het raam hebben gegooid en vervangen hebben door deze VM oplossing. Het is begrijpelijk dat het even duurt voordat WSL2 zijn voorganger overstijgt, maar ik ga er vanuit dat deze beslissing niet licht genomen is en dat het uiteindelijk wel gaat lukken dus.

Voordeel: ik werk nu weer op mijn Macbook en Docker for Mac is bliksemsnel in vergelijking met de Docker op WSL2 Beta :+

[edit]
Foutje: apples met peren vergelijken want die MacBook is een high-end 2020 model en de Windows laptop was ouder en niet super high-end.

[Reactie gewijzigd door Bigs op 21 augustus 2020 12:17]

Prestaties zijn juist enorm vooruit gegaan! Ik ben heel erg benieuwd hoe je het voor elkaar krijgt dat Docker for Mac zoveel sneller voor je is dan Docker op WSL2, ik draai thuis ook beide en ik wil eigenlijk de Mac niet meer gebruiken omdat het zoveel fijner en sneller werkt op WSL2.

Ik vermoed dat je de docker containers gebruik laat maken van het Windows filesystem? Dat kan je beter niet doen: gewoon via Verkenner naar \\wsl$\<Distributie naam>\ (bijvoorbeeld: \\wsl$\Ubuntu-18.04) gaan en dan naar het pad gaan waar je de bestanden wil plaatsen. Zodra je de container vanaf deze locatie start zal het vele malen sneller werken!
Leuk allemaal, maar toch totaal onpraktisch? Je moet ineens een je project pad prefixen, ik vind dat wel afbreuk doen aan het geheel. Ik heb nu gewoon weer Docker met Hyper-V backend aangezet en dat is snel zat. Ik kan me nauwelijks voorstellen dat WSL2 nog weer veel sneller is.
Ik zie het zelf niet als iets onpraktisch... Het is even wennen aan de nieuwe workflow, maar in mijn optiek is het de extra moeite (als je dat het al mag noemen) waard. Tevens geeft het je de mogelijkheid om verschillende distributies naast elkaar te draaien die allemaal hun eigen 'filesystem' hebben, ideaal voor testen van zaken.

Je moet uiteraard doen wat je zelf wil, maar vasthouden aan een oude methode omdat de nieuwe een andere workflow vereist is als je het mij vraagt niet een goed idee.

En voor wat betreft performance verbeteringen in WSL2, ik heb geen absolute getallen maar het is echt vele malen sneller geworden. Vooral projecten die meerdere containers omvatten zijn significant sneller geworden.
Dan doe je echt iets verkeerd. WSL1 was ook een VM, en WSL2 is dat ook, alleen op een andere manier. WSL2 is zo veel sneller. Dit is gewoon bijna native snelheden als je je bestanden op het WSL filesystem zet zoals @afterburn zegt. Ik ben bijna de enige op werk met een Windows laptop, en mijn Docker omgevingen zijn vele malen sneller dan die van collega's op een (snellere) Macbook.
Als ik het mij goed herinner is/was WSL1 een soort translatie laag tussen een op linux gebasseerd systeem (bijv. ubuntu) en de NT kernel. Ofwel, WSL1 had eigenlijk niks met Linux te maken afgezien van het feit dat veel mensen de op linux gebasseerde operating systems onder de benaming "linux" scharen.
The first release of WSL provides a Linux-compatible kernel interface developed by Microsoft, containing no Linux kernel code.

...

The architecture was redesigned in WSL 2, with a Linux kernel running in a lightweight virtual machine environment.
(Windows_Subsystem_for_Linux)

M.a.w. WSL 1 maakte geen gebruik van een virtuele machine waar WSL 2 dit nu wel doet.

[Reactie gewijzigd door Archcry op 21 augustus 2020 10:01]

Wsl1 vm klopt toch niet? Het was gewoon native linux executables uitvoeren. Wat dingen leuk maakt zoals het daadwerkelijk hebben van 1 machine (gedeelde netwerk interface en zo). Maar wat file performance tricky maakte.
Klopt, WSL1 was een emulatie laag om Linux calls te vertalen naar Windows calls. Nadeel is dat niet alle calls vertaald worden/zijn, waardoor niet alles kan werken. WSL2 is geen emulatie maar een lightgewicht virtualisatie, waardoor je in principe alles wat je op bare metal Linux kunt draaien ook binnen WSL2 kunt draaien.
WSL2 is geen lightgewicht virtualisatie...

WSL2 is puur en simpel standaard Hyper-V virtualisatie waarbij het OS dat men installeerde lichter is omdat men de oa kernel gestript heeft van onnodige drivers support enz. Om de sneller boot up effect te bekomen.

Je kan hetzelfde effect ook hebben met VirtualBox of VMware hun VM's. Sommige Os images zijn gewoon van hun eigen nogal zwaar.

Draai bijvoorbeeld Ubuntu en Debian in VMware VM's en Debian ( net minimum install ) start letterlijk 10 keer sneller op dan de standaard Ubuntu server OS. Kan je verzekeren dat Debian op VMWare VM's bijna even snel opstart als WSL2 instances.

WSL1:

Er was nog een ander probleem met WSL1 dat je overkijkt. Het feit dat NTFS ( het file systeem ) dat Windows gebruikt niet echt compatibel was in WSL1, met hoe Linux omging met hun file systeem. Met het nadeel dat WSL1 traaaaaaag was voor bepaalde intensieve (aka veel files access ) taken dat terugviel op het file systeem ( zoals code compile jobs ).
Sorry, maar het is niet "puur en simpel standaard Hyper-V virtualisatie". Probeer maar eens de vhdx van een WSL2 distro te booten in Hyper-V, lukt niet. Ook hoef je Hyper-V niet geinstalleerd te hebben om WSL2 te kunnen gebruiken. Het wel gerelateerd aan Hyper-V, maar meer een lichte, uitgeklede en gespecialiseerde variant geschikt voor maar 1 taak, het runnen van een WSL2 Linux instance. Zo gebruikt WSL2 geen partities, enkel disken (een van de redenen dat je niet kan booten in Hyper-V). Hyper-V gebruikt net als bare metal /dev/sda voor disk en dan /dev/sda1 enz voor de partities. In WSL2 staat de / partitie gewoon op /dev/sda (of b of c, afhankelijk van volgorde van starten)

[Reactie gewijzigd door afterburn op 21 augustus 2020 11:38]

Dat hangt van je definitie van virtual machine af. Het vertalen van syscalls natuurlijk net zo goed een vorm van virtualisatie, alleen op applicatieniveau en niet op processorniveau.

[Reactie gewijzigd door .oisyn op 21 augustus 2020 11:38]

WSL2 is sneller als WSL1. Alleen IO van/naar WSL en Windows is wat traag. Zolang je files die horen bij watever je draait binnen WSL2 ook binnen WSL2 houdt, is er geen enkel probleem en is serieus sneller als onder WSL1.
> WSL2 is sneller als WSL1.

https://www.phoronix.com/...em=wsl-wsl2-tr3970x&num=1

Hangt af van wat je doet. Bepaalde taken zijn sneller tot veel sneller onder WSL1. Andere zijn dan weer sneller tot sneller onder WSL2.

Het is niet zo zwart en wit zoals je het voorspiegelt.
Voordeel: ik werk nu weer op mijn Macbook en Docker for Mac is bliksemsnel in vergelijking met de Docker op WSL2 Beta :+
Ik heb precies het tegenovergestelde, sinds WSL2 is mijn docker een stuk sneller dan met mijn Mac. Had je na de upgrade naar WSL2 wel je distributie een upgrade gegeven naar versie 2. Dit moet je namelijk handmatig doen als je je Linux versie hebt geïnstalleerd voordat je WSL upgrade.
Docker op Mac draait ook in een VM, en dat heeft significante overhead. Als je veel Docker gebruikt vind je het wellicht interessant om het eens op een native Linux bak te draaien, dan merk je hoe vlot Docker daadwerkelijk kan zijn.
De meeste ervaren het andersom.

Heeft even niks met docker te maken, maar een 'npm install' in mijn wsl2 wint het van dezelfde npm install _native_ op een 2018 MacBook.

Dat is dezelfde Intel u-cpu met zelfde ram.

Hij wint waarschijnlijk omdat in mijn Lenovo de cpu wat meer ongeremd zijn gang kan gaan (oftewel dit is meer Lenovo vs MacBook dan wsl2 vs macos), maar het is nog steeds leuk om te zien.
Ik vind het ook jammer omdat WSL1 gewoon veel minder overhead heeft. Als het je puur gaat om een bash shell op Windows en wat kleine processen dan heb ik dat veel liever dan de WSL2 methode.

Ik hoop dan ook dat WSL1 blijft...
Voor de gnu omgeving op windows zou ik gewoon bij cygwin blijven. Dat blijft.
Daarmee draai ik al jaren bash,bawk en rsync onder mswindows. Zelfs rsync vanuit een bat-script
Er zijn nog wel wat meer issues met WSL2 die er voor mij voor zorgen dat ik voorlopig op WSL1 blijf (https://github.com/microsoft/WSL/issues/4619). Als ze die nou eerst eens oplossen, in plaats van de de feature naar een OS-versie brengen die in december! (1903) al niet meer ondersteund wordt 8)7
Dat is geen bug. WSL2 is een VM met een eigen Linux kernel, geen emulatie zoals WSL1. WSL1 kan dus localhost:port bereiken van het Windows systeem, maar WSL2 kan dat niet. Daar is localhost:port iets binnen het Linux systeem van die WSL2 sessie. Om externe services te bereiken zal je dus hetzelfde moeten doen als dat je een VM onder Hyper-V/Vmware/Virtualbox of zoals het moet met een Linux installatie op bare metal naar een Windows systeem.
Ik ben bekend met de technische oorzaak, maar ik ben ook van mening dat WSL2 juist de tooling zou moeten hebben om dit met wat eenvoudige configuratie op te lossen. En dat momenteel niet het geval, want voor ieder netwerk dat net iets anders geconfigureerd is, moet je opnieuw je firewall gaan instellen omdat ips wijzigen. Wat configuratie om automatisch tunnels te maken voor de geconfigureerde poorten tussen de host en WSL zou het al verhelpen.

Het is in ieder geval een bruikbaarheidsissue, want zodra je een bestaande wsl1 installatie bijwerkt naar wsl2, gaat hetgeen dat je gebruikte stuk.
Ik snap wat je zegt, maar ben het niet met je eens. WSL1 naar WSL2 is een migratie en voor elke migratie hoor je te kijken wat voor mogelijke impact dit heeft voor je. Je gaat niet eerst "wsl --set-version <distro> 2" inkloppen om vervolgens te klagen dat bepaalde dingen niet werken of aandacht behoeven. Microsoft heeft hier een document staan waar de verschillen beschreven staan, en daar staat ook uitgelegd wat wel en wat niet kan qua netwerken. Vanaf Windows kun je dus wel degelijk WSL2 benaderen via localhost in bepaalde situaties, mits je build nieuwer is als 18945 (werkt dus niet met 1903 en 1909), maar punt is dat uitgelegd wordt wat wel en niet kan. Hier kun je dan vervolgens rekening mee houden en beslissen of het op dit moment handig is om naar versie 2 te converteren.
Zelfs als technisch gebruiker vind ik het wel verwarrend dat je al het onderscheid moet gaan maken tussen 1903/1909 en 2004, maar dan ook nog eens build nummers als 18945 moet gaan onthouden. Sorry hoor, handig is dat niet.
Microsoft heeft veel dingen in documenten staan, maar je moet ze ook altijd maar weten te vinden.

Ik wil geen WSL expert moeten zijn om het te kunnen gebruiken.
Dat wil ik ook niet Chris, m'n hoofd zit vol genoeg. Maar om die info te vinden was 1 query in DuckDuckGo met zoekterm "wsl1 vs wsl2" en het bovenste resultaat is de link uit mijn vorige reactie. Build nummers enzo komen daar ook vandaan. Hoef je verder ook niks mee; 20H1 zit er boven, de rest zit er onder dus als je 20H1 draait zit je goed.

WSL is echt heel goed gedocumenteerd door Microsoft en alle informatie is bizar makkelijk terug te vinden en ik vind het dan ook geen excuus om niet bepaalde dingen, al was het vluchtig, even na te lezen om te zien of er geen grote rode vlaggen voor jouw situatie zijn. WSL is geen rocketscience en het is ook niet dat je verplicht wordt om honderden pagina's documentatie na te zoeken voor je iets zinnigs weet.

Het feit dat een migratie van WSL1 naar WSL2 maar 1 kort commando is wil niet zeggen dat je dan maar alle normale voorzorgsmaatregelen bij het grof vuil moet zetten, toch?
Bedankt voor de reactie.
Vooral deze comment in gerelateerde issue geeft interessante info over de achtergrond van het 'probleem' met WSL2:

https://github.com/micros...97#issuecomment-604592340

Eigenlijk is dit het al oude probleem dat je hebt in Windows met shared files tussen VM en Host (of het nou vmware, virtualbox, hyper-v, of whatever is). Dat is er uiteraard niet beter op geworden met WSL2 wat eigenlijk gewoon een Hyper-V oplossing is.

Nog een ander 'vervelend' issue (die ik had): je kan blijkbaar niet goed WSL2 en VMWare tegelijk draaien. (Ja met nieuwste VMware in hyper-v mode maar dan ook traag).

[Reactie gewijzigd door JointFillah op 21 augustus 2020 09:36]

Nog een ander 'vervelend' issue is dat je blijkbaar niet meer WSL2 en VMWare tegelijk kan draaien. (Ja nieuwste VMware in hyper-v mode maar dan ook traag).
Dat is niet waar: https://blogs.vmware.com/...upports-hyper-v-mode.html
Ja klopt dat is wat ik bedoelde...dat is nieuwste VMWare (heb ik nog geen licentie voor). Heb de trial geprobeerd, maar die lijkt erg traag in 'Hyper-V mode'.

Heeft iemand wel goede ervaringen met de Hyper-V mode in VMWare (met WSL2 aan, anders gaat VMWare is normale mode draaien)?
Ik heb toevallig op mijn PC ook nog VMware draaien en die draait gewoon net zo soepel als hij deed voor ik WSL2 gebruikte. Heb geen benchmarks gedraaid verder ofzo, maar voor het werk wat ik er op doe (VS 2019 draaien geïsoleerd van host PC met zware applicaties) merk ik geen verschil.
Draaide WSL2 toen tegelijkertijd met VMWare (beide een VM actief)?
VMWare detecteert of Hyper-V/WSL2 draait en dan pas gaat hij in Hyper-V mode. Daar leek ik een trager-dan-normaal VM van te krijgen in VMware.
Met hyperv gebruik onder Windows 1909 (dus toen nog geen wsl2) kon je VMware gewoon niet draaien als hyperv geïnstalleerd was. Er draaide geen VMs, geen services die ik uit kon zetten... las ook dat het gewoon niet ging werken met hyperv actief. Je moest hem in 'Windows componenten bij Control Panel gewoon uitvinken (deïnstalleren dus eigenlijk).

Ik denk dat als wsl2 actief is en je draait VMware draai je _altijd_ in de hyperv-mode.
Hetzelfde geldt ook voor Virtualbox, met het verschil dat deze niet stabiel draait in Hyper-V mode van de host... Netwerk issues en kernel panics duiken op in de guest...

Ik hoop dat er snel een oplossing zal komen.
Heb je hier zelf last van? Het probleem is dat de IO performance slecht is van WSL naar mounted NTFS filesystemen van Windows. Maar wees eerlijk, als je Docker binnen WSL hebt draaien waarom zou je dan docker files buiten WSL willen houden? Er is ook geen reden voor gemak voor als je zelf moet editen, aangezien je zelf net zo makkelijk naar \\wsl$\<distro>\directory kunt navigeren als naar een willekeurige directory op je locale filesysteem.

Ik zou zeggen, draait je container onder WSL, hou je data dan in WSL. En draait je container onder Windows, hou dan je data in Windows. Je hebt dan geen performance issues en je hebt gelijk een logische scheiding tussen wat in je docker gebeurt en de rest van het systeem.
Ik loop toch regelmatig tegen rare problemen met Docker op Windows aan: na hibernate zijn de klokken niet meer juist in de containers, soms kan hij niet connecteren naar onze Nexus (heb ik Docker moeten herinstalleren) een nog heel wat andere rare dingetjes die zich 1x voor doen. Al best veel tijd mee verloren. Ook op Mac zijn er wel eens problemen hoor ik van collega's.

Vermits Docker eigenlijk toch een VM opstart op Windows, kan je denk ik het beste een Linux VM maken en daarin Docker installeren en werken.

Edit: dan lees ik wat verder en kom ik bvb dit probleem tegen met Docker in WSL2: http://nuts4.net/post/mov...e-to-a-different-location
Ik vraag me dan direct af of er nog andere problemen zijn...

[Reactie gewijzigd door Chris_147 op 21 augustus 2020 16:03]

Probeer het eens? Lees die ticket goed. Als je WSL2 gebruikt en je bestanden gewoon op het FS hebt van WSL2 dan is het razendsnel. Ik gebruik WSL2 nu zo'n driekwart jaar na en maand van WSL1, en het is echt een verschil van dag en nacht zo veel sneller. De snelheid tussen Windows en WSL2 is wel wat traag, maar ik heb in al die tijd daar nooit echt een probleem mee gehad.
Gary Explains doet het al. Hij converteert eerst naar WSL2, waarna hij docker installeert, en binnen docker weer Ubuntu.
https://www.youtube.com/watch?v=loC7VfgRT-I
Vraagje;
Als je hoofdtaak developen is icm docker. Waarom draai je dan niet een linux host?
Dat maakt je development veel makkelijker (en sneller).
Omdat er vanuit het bedrijf de wens is Windows te gebruiken om bijvoorbeeld in te loggen op het domein met 2fa. Op linux ontsluit je je dan van dat ecosysteem.
Hmm. je kan prima met een linux bak op een windows domein inloggen. Ook met 2FA zo ver ik weet. Maargoed. Erg omslachtig zo natuurlijk. Je bent in feite een linux-dev, maar je moet windows gebruiken.
Hierdoor moet je door behoorlijk wat hoepels heen.
Goed om te lezen dat het naar 1909 komt. We zien meer vraag naar WSL2 binnen de enterprise omgeving, maar slaan liever de 2004 versie van Windows over vanwege de korte support voor deze versie. De autumn editie heeft altijd een jaar langer support wat wenselijk is.

Dit is een goede toevoeging en fijn dat we niet naar de 2004 versie hoeven te springen. We kunnen wachten op de gepatchte 20H2 en 2004 overslaan.
WSL bij enterprises? Wat voor bedrijven zijn dat. Installeer dan gewoon een Linux distro.
Het is bij ons niet toegestaan om native linux te installeren. Dus dan is WSL of een VM die linux draait wel een uitkomst.
Waarom dan niet?
Ik draai native debian en zou echt geen windows 10 willen hebben.
Dit omdat windows 10 geen oudere hardware goed ondersteunt.
IT policy. Het is voor IT makkelijker om één OS te onderhouden. Werklaptops hebben ook toegang tot het interne netwerk dus dan heeft één OS waarvoor dezelfde security patches kunnen worden uitgerold wel de voorkeur. Wij hebben de nieuwste generatie workstations dus het ondersteunen van oudere hardware is geen eis.
Waarom dan de keuze van WSL2 voor een Linux VM? Of moet die keuze nog gemaakt worden?

Als ik andere commentaren hier lees, is WSL2 wel goed, maar moet je het eigenlijk ook niet teveel willen mixen met Windows (bestanden echt in WSL zetten, niet in Windows folders, want dat is trager). Dan lijkt een VM me misschien toch beter.
Serieuze vraag he.
Ik gebruik voor development activiteiten nu voornamelijk nog een Linux VM. Het voordeel van WSL2 is de hogere integratie met windows.
Welke hogere integratie en welke voordelen biedt die je echt dagdagelijks?
Ik bedoel maar: WSL is toch voornamelijk gericht op ontwikkelaars? Wat moet je nog meer hebben dan directories met broncode te kunnen uitwisselen?
Genoeg redenen te verzinnen waarom Windows op de clients voordelig is. Uiteraard draaien de meeste services op dedicated servers en is dit vooral een "nice to have" voor de engineers.
Ik denk dat @mocem ook servers bedoelt voor services en toepassingen zoals Kubernetes. Clients snap ik wel dat Windows gebruikt wordt (alhoewel ik zelf liever MacOS heb voor dev werk).
Maar we praten hier over een feature op een cliënt OS en geen server OS. Dus lijkt het mij vanzelfsprekend dat je het dan over clients hebt in de enterprise omgeving.
Daar heb je een punt :)
Ja ik snap dat ook niet hoor. Zelfde overigens met Oracle databases en Middleware stacks, bijna elk bedrijf draait die op UNIX of Linux, en er zijn er altijd een paar die het op Windows proberen. Mijn ervaring is dat die meer problemen, minder uptime en meer beheer vergen. Sommige applicaties moet je gewoon niet onder Windows draaien.
Is dit misschien een indicatie dat het nog even kan duren eer de May update breder beschikbaar komt?
Ik heb hier verscheidene laptops die aangeven dat 2004 nog niet beschikbaar is wegens 'problemen' (welke dat nu exact zijn, geen idee)
Hm, wat gek, want ik heb inmiddels twee systemen die aangeven dat de update wél beschikbaar is, maar iedere poging om ze te installeren, starten een normale "check for updates" zonder dat versie 2004 geinstalleerd gaat worden.

Misschien maar gewoon wachten op de volgende update.

[Reactie gewijzigd door _Thanatos_ op 21 augustus 2020 09:11]

komt er ook ondersteuning voor ext2/3/4 bestandssystemen?
Dat zou echt zo lang overdue zijn. Ik geef weinig om WSL (ik draai wel gewoon effectief Linux), maar het zou fijn zijn als EXT4 hierdoor straks gebruikt zou kunnen worden voor externe media, zonder gedoe als ik m'n externe schijf eens uitleen aan Windows-gebruikers.
Geen idee als dat er zal komen in de toekomst.
Mij zou het niks verbazen dat straks windows gaat draaien onder een Linux Kernel compleet met Ext bestands systeem ondersteuning.
Ik draai al een tijdje WSL2 in combinatie met Docker. Sinds WSL2 is het mogelijk om fatsoenlijk je container aan de host machines te koppelen. Wij draaien onder andere Linux containers met een PostgreSQL database en voorheen draaide dit een VM in Hyper-V, godsonmogelijk om je postgres dir te sharen met de host machine. Deed je wel, kreeg je rechten issues waardoor je container niet kon draaien. Alternatief is een volume share of een vrij bijzondere workaround om het zelfde resultaat te krijgen.

Tevens is de boel ook sneller geworden sinds je geen Hyper-V meer nodig hebt als je Docker combineert met WSL2. Dus erg blij dat ze WSL2 ook voor oudere versies gaan uitbrengen, want de werk PC krijgt voorlopig nog geen 2004 update.
Waarom draai je die containers op een Windows machine?
@thePiett Ik draai een spiegel van de productie omgeving.
Makkelijk bij het ontwikkelen van software (ontwikkelen en testen) en je kunt dan eenvoudig updates testen voordat je in productie achterkomt dat je een bepaalde packages niet had moeten bijwerken.

Maar software development dus.
Blijkbaar is er een periode aangebroken dat de goede ontwikkeltools alleen maar onder linux draaien.
Installeer alleen LInux dan ben je veel beter af en geen gezeik met updates of malware die je laptop versleutelt. Als ontwikkelaar heb je echt geen windows nodig.
Je kan onder wsl linux zelf een gui krijgen.
Bijvoorbeeld met Ubuntu Wsl .Zal ook werken met Debian Wsl .
Xfce4 en Lxde doen het zeker.
Ook zijn Kde en Gnome shell mogelijk,maar 100% werken is niet zeker.

https://www.reddit.com/r/...on_windows_10_ubuntu_wsl/
Net Ubuntu 20.04 geprobeerd op WSL, ik krijg er niet veel mee voor elkaar: als ik eender welk programma wil installeren via apt / apt-get, krijgt hij de packages niet gevonden. Zelfs een eenvoudige utility als mailx is een probleem.
Ik gebruik nu WSL2 een paar weken en ben er onwijs tevreden mee!

Misschien offtopic maar:

aangezien WSL2 een echte VM is, waarom is het niet mogelijk om bijvoorbeeld een usb webcam aan te sluiten in WSL.

Via Hyper-V VM zou dit wel mogelijk moeten zijn toch?.
Ik dacht dat WSL2 onder water ook een eigen Hyper-V vm was.

[Reactie gewijzigd door narimantos op 21 augustus 2020 18:19]

Op dit item kan niet meer gereageerd worden.


Apple iPhone 12 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