Windows-pc's kunnen nu Linux-containers draaien via WSL

Microsoft brengt WSL Containers officieel uit. Gebruikers kunnen daarmee Linux-containers draaien binnen Windows 11. De functie werd al langer getest, maar is nu voor iedereen beschikbaar.

WSL Containers (WSLC) worden een nieuwe functie binnen WSL, oftewel Windows Subsystem for Linux. Gebruikers konden daarmee al langer Linux draaien binnen Windows, bijvoorbeeld om bepaalde software te gebruiken.

Voorheen was het niet standaard mogelijk om Linux-containers binnen WSL te gebruiken. Een container is een softwarepakket dat verpakt wordt met al zijn code, runtime en dependency's. Programma's draaien op die manier op ieder systeem identiek.

Met WSLC werken zulke containers voortaan native via WSL, zonder dat ze daarvoor eerst een app als Docker Desktop moeten installeren.

De terminal en een api

Gebruikers krijgen met WSLC toegang tot twee nieuwe functies. Allereerst WSLC CLI, waarmee ze containers kunnen opzetten via de terminal. Er komt ook een bijbehorende api, waarmee ontwikkelaars Linux-containers kunnen draaien binnen hun Windows-apps.

Deze manier van werken heeft verschillende voordelen, schrijft Microsoft. Gebruikers kunnen hierdoor bijvoorbeeld een stuk sneller containers aanmaken, aldus de techgigant. Containers kunnen op deze manier ook snellere toegang tot Windows-bestanden krijgen.

Containers draaien via Docker op de 'gewone' WSL-installatie kon ook netwerkproblemen met zich meebrengen. Met WSLC is dat opgelost, wat onder meer de compatibiliteit met vpn-diensten en firewalls moet verbeteren.

De functie is per direct beschikbaar. WSL-gebruikers krijgen toegang tot containers door 'wsl --update' te draaien in hun terminal. Microsoft blijft intussen WSLC verbeteren. In de toekomst moet de functie bijvoorbeeld native ondersteuning krijgen voor compose.

WSL kan voortaan native overweg met containers. Bron: Microsoft

Reacties (83)

[Klauwhamer]

Ah, nice. Ik vind WSL/2 echt heel prettig werken. Ben benieuwd naar de performance van containers ten opzichte van een native Linux-host.

[latka]

Er zit nog steeds een Windows kernel tussen je container en de hardware. Het zou me verbazen als dit sneller is.

[Llopigat]

Nee hij spreekt direct de hypervisor in Windows aan. Hij hangt niet onder de Windows kernel.

Windows zelf hangt daar ook onder, WSL hangt er dus eigenlijk naast. Dit werkt al heel lang zo, al voordat WSL bestond had je een andere oplossing van MS (ben de naam even kwijt) en je had ook dingen als colinux. Sinds Windows 2000 is dat ingevoerd als ik het me goed herinner. Sindsdien praat de NT kernel al via een soort hypervisor met de hardware en die heeft sinds het begin al meerdere OS'en tegelijk ondersteund.

Hier is een soort diagram over hoe dat grofweg werkt: https://www.thomasmaurer....Architecture-768x431.webp

Dus er zit wel een hypervisor tussen maar geen hele windows kernel. Diezelfde hypervisor zit ook tussen windows en de hardware zelf. Dus die is best lichtgewicht anders zou Windows zelf ook traag zijn.

Maar als je gewoon in een standaard bare metal windows installatie zit dan zit je dus eigenlijk altijd in een VM te werken. Best grappig.

[Reactie gewijzigd door Llopigat op 1 oktober 2026 21:07]

[kdekker]

Wat je zei over dat Windows zelf ook onder een hypervisor draait was nieuw voor me. Dit lijkt zo te zijn als je WSL installeert. Anders toch direct op bare metal. Grappige info.

Van lang geleden weet ik wel dat concurrent VMware niet tof multi-core VM's schedulde (sorry, geen NL). Want je VM kreeg pas ticks als minimaal het aantal virtuele cpu's vrij was in de hypervisor. Kortom: bij drukte met veel multi-core VM's, stortte voor iedereen de performance in. En in die tijd was de hyper-v hypervisor een stuk slechter dan VMWare. Hyper-v en Linux was toen vooral 'knijpen' van Linux. Geen idee of dat nu beter is. Al kun je WSL niet helemaal vergelijken met een VMWare hypervisor, waar je basis OS, de hypervisor, zo kaal mogelijk is. Dat is Windows, als gastheer, beslist niet, icm WSL op bijv. Windows 11.

[cibrhusk]

Dit is niet echt te vergelijken met een "gewone" vm waarin je een OS draait, daar moet de vm een heleboel doen dat hier niet nodig is.

Het is echter niet zo dat de Linux kernel via WSL2 direct met alle hardware via hypervisor mag praten, wsl2 draait zelf wel in de hypervisor en ook de Windows kernel draait in die hypervisor, maar de Windows kernel (degene die het boot proces start) neemt een speciale positie in (de root partition) en is degene die in weze de hardware aansturing doet, maar wel binnen de grenzen die de hypervisor daarvoor opwerpt.

De linux kernel moet dus via de windows kernel praten met de hardware, dit gebeurd over een VMBus, daar zit wel degelijk een overhead maar Microsoft is er alles aan gelegen om die overhead zo klein te maken dat deze verwaarloosbaar is.
De Linux-kernel verpakt bijvoorbeeld een native I/O-schrijfactie als een VSC-bericht welke de Windows kernel weer uitpakt en aan de fysieke driver doorgeeft. Als de schrijf actie echter naar een windows mount gaat dan wordt het 9P protocol gebruikt (wat logisch is want Windows heeft daar de regie al over op het niveau van bestandsysteem).
Voor GPU toegang is er dan weer een speciale module geschreven die de calls van de Linux omgeving omzet naar WDDM die direct door de Windows Kernel in de root partition kan worden afgehandeld als native. Het zijn overigens, voor zover ik weet, allemaal kernel modules die Microsoft ontwikkeld voor de Linux kernel die daarvoor gebruikt worden, dus niet nog een laagje die nog ergens translatie erboven op moet doen.

Wat ik jammer vind is dat ik er geen goed WSL2 georiënteerd plaatje van kan vinden, dit plaatje bij Microsoft komt er het dichtst bij, het doel daarvan is echter Hyper-V uitleggen vanuit het perspectief van meedere vm's. Je ziet hier wel de root partition en de VMBus maar niet direct duidelijk welke rol die VMBus pakt (staat wel in de tekst). WSL2 Linux draait wel als child partition, maar dan wel met een hoop extra's die het niet vergelijkbaar maken met een Linux als gewone vm.
https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/architecture

[Reactie gewijzigd door cibrhusk op 2 oktober 2026 00:34]

[jb044]

Van wat ik ervan weet is dit alles wel optioneel. Windows/Microsoft pusht het wel en als het uitstaat is dat een uitroepteken onder de security settings waar je op geattendeerd wordt met een uitleg dat Windows belangrijke processen in een hyporvisor kan draaien voor aanvullende veiligheid.

Zelf draai ik Windows 11 in een kvm VM met AMD nested virtualisation met minimale performance penalty en een nVidia kaart in passthrough mode. Daarmee is ook WSL mogelijk, al zal het default wel een melding geven dat nested virtualisation binnen WSL niet ondersteund wordt, het houdt natuurlijk een keer op Ook is het mogelijk om ook de hyporvisor optie van Windows 11 zelf te activeren maar dat is dan echt meer een functioneel iets dan iets dat werkbaar is, performance penalty is dan echt wel iets van 40%.

Benieuwd wat dit weer gaat brengen. Onlangs wou ik Drupal CMS eens uitproberen en ddev is een makkelijke manier om dit te doen, iets dat onder OSX easy peasy is. Ik had niet zo'n zin om mijn Linux bare metal te vervuilen met ddev dus kwam ik uit op Windows 11 met WSL. Was uiteindelijk inderdaad niet zo spannend en werkte prima, ik gok dat dit alles dat weer net even wat makkelijker gaat maken, maar zal waarschijnlijk wat geduld moeten hebben nu dit net uit is

[Henkieschmenkie]

Met de "Hypervisor-based security" van Windows Defender op Windows 11 draai je ook zonder WSL onder een hypervisor.

[Carrieretijger]

Al die features maakt van Windows 11 een zwaar besturingssysteem. Hier is het eerder andersom. Linux from scratch blijft beter in mijn ogen. Zo is de beveiliging in Linux beter onder Linux zelf dan onder Windows. Nee, ik ben geen Windows hater, maar Linux is een blijvertje hier

[nullbyte]

HyperV op Windows is een type 1 hypervisor en VMware workstation een type 2. Daar waar ESXi een type 1 hypervisor is. Het type is afhankelijk van of deze op bare metal of een OS draait.

VM's schedulde (sorry, geen NL).

ICT vakjargon is altijd Engels, daar zou ik geen sorry voor zeggen. Dat dwangmatig vertalen leidt volgens mij alleen maar tot verwarring.

[Reactie gewijzigd door nullbyte op 3 oktober 2026 09:12]

[kdekker]

We gebruikten toen een dure server versie van VMware. De scheduler was toen niet optimaal. Lees: sommige dingen werden onwerkbaar traag, waar met een oude doos bare metal geen enkel probleem was. Performance problemen agv hyper- visors/VMs uitzoeken was voor IT met hun mooie GUI tools niet mogelijk. Ik vermoed dat de oorzaak van vertraging een mix was van de scheduler (veel meer VM's uitgegeven met virtuele cpu's dan fysiek aanwezig) en netwerk stack. Het ging wel om a-typische software.

Vandaar mijn verrassing dat Windows zelf ook als vm draait. Nu weet ik niet of WSL samen met core Windows en het gebruikers deel aan overprovisioning doet. Waarschijnlijk niet en dan heb je minder last van de overhead (die er beslist ook moet zijn) van een hypervisor.

[Kalief]

Betekent dit dat het ook onder Windows 10 zou moeten kunnen werken?

[bzuidgeest]

In theorie misschien maar dat OS is out of support.

[Klauwhamer]

Ik bedoelde natuurlijk ook hoe groot de performance hit is, hè.

[Archcry]

Ben ik nou de enige die nog steeds struikelt over de naam "Windows Subsystem for Linux"? Dat suggereert toch dat Windows het subsystem is, terwijl Linux juist het subsystem ís? Of hebben ze het gewoon zo genoemd omdat "Windows" per se vooraan moest staan?

[jorikc]

Het is een Windows subsystem dat werkt als een linux kernel, zodat er linux applicaties/binaries kunnen worden uitgevoerd. Zo is er ook een Windows subsystem om 32-bit applicaties op 64-bit Windows te draaien: WoW64 genoemd.

[R4gnax]

Inderdaad. Voluit SysWow64 - SYStem for Windows (32-bit) On Windows 64-bit.

[HyperioN]

Het softwarecomponent dat dit mogelijk maakt noemen ze "subsystem". Dus zowel Windows als Linux zijn beide niet het "subsystem", dit specifieke stukje software is het subsystem

Lees het als (the) "Windows component to run Linux" -> (the) "Windows subsystem to run Linux" -> "Windows subsystem for Linux"

[John Doos]

Ik lees hem zo: Windows die op subsystem niveau, Linux bruikbaar maakt.

Maar ik denk dat je gelijk hebt, nooit bij nagedacht eigenlijk, ik zeg altijd WSL

[spoordressing]

Ben ik nou de enige die nog steeds struikelt over de naam "Windows Subsystem for Linux"?

Als er een komma achter 'Windows' zou staan, wellicht.

[__Leon___Leon__]

Ja niet nee

[stresstak]

Apostrof.
Windows' Subsystem

[Kallik]

Ze hebben het zo genoemd omdat Linux niet vooraan mag staan omdat "Linux Subsystem for Windows" zou impliceren dat het een product is van de makers van Linux. Een ontwikkelaar van WSL heeft dit ooit aangehaald, weet niet meer waar.

De uitleg die hier verder worden gegeven zijn incorrect, WSL2 is geen subsysteem en maakt geen gebruik van die infrastructuur. WSL is een virtualizatie platform.

[Reactie gewijzigd door Kallik op 1 oktober 2026 21:18]

[satya]

Bij een volgende versie zou het zomaar LSW kunnen zijn, want daar wordt wel aan gewerkt.

[TeunSegers]

Grappig de dag dat ik stop met WSL brengen ze het officieel uit.

Korte review: Het werkt gemiddeld gezien uitstekend en ik heb er erg weinig problemen mee gehad. Ik draaide er docker containers in, t.e.m. een k3d opstelling. Voor lokale deployments van zaken als VaultWarden, Zulip, zelf ontwikkelde services, Forgejo, etc. bleek het betrouwbaar en zeer handig.

Waarom ben ik er dan mee gestopt? Het schaalt niet lekker. WSL alloceert 3 à 4 zoveel geheugen als het nodig heeft. Dat kan wel weg configureren tot op een punt, maar de kern van het probleem is dat het dat geheugen nooit automatisch weer afgeeft. Dan wordt het snel onprettig als je ziet dat je containers 12GB gebruiken maar docker bijna 100GB aanslaat. Je kan dat manueel vrijmaken, maar dat is weinig interessant. Je moet er ook rekening mee houden dat het een soort Linux swap file bijhoudt in geheugen en die kan lijvig worden.

Het werkt, het is betrouwbaar, performance was prima, maar als je aan serieuzere dingen begint te doen dan draai je best Linux native.

[cricque]

Tenzij de workplace je verplicht om Windows te gebruiken en linux uit den boze is, maar je moet dan wel dingen doen op servers en dat wil je toch wel eerst eens lokaal testen ... dan is dit toch wel een geschenk hoor.

Ter info: heb op zo een bedrijf gewerkt ... En thuis gebruik ik al sinds 96-97 linux, maar sommige dingen doe ik gewoon sneller en gemakkelijker onder linux

[YGDRASSIL]

De vraag is of deze wslc containers ook teveel geheugen pakken of dat dat een docker ding was...

[Kerfuffle]

Dat gedoe met Docker Desktop in Windows en dan Linux via WSL daar gebruik van laten maken, dat vond ik nooit echt lekker werken. Toen ik bovendien merkte dat ik voor mijn werk (Java dev) eigenlijk alleen maar dingen in Linux of in mijn browser deed, ben ik maar gewoon op native Linux (Ubuntu) overgestapt. Nooit meer terugverlangd en eerlijk gezegd voelt Windows inmiddels (7 jaar later) heel vreemd om nog in te developen.

[Barsonax]

Helaas nog genoeg bedrijven waar je een dichtgetimmerde laptop of VM krijgt met Windows erop. Zie dan maar eens met native Linux te werken. Wsl is dan de enige uitweg.

[Kerfuffle]

Zeker, dan is wsl the next best thing. En dan is deze verbetering broodnodig, bedoelde ik ook te zeggen, want werken met Docker vond ik nou net waar het tekortschoot.

[MSalters]

Als je een VM met Windows krijgt dan gaat dit sowieso niets doen. En een dichtgetimmerde laptop laat ook geen installatie van WSL toe dus dan moet je hopen dat het er al op staat

[Barsonax]

Jawel hoor, wsl mogen we wel gebruiken. De enige manier om toch nog wat voor elkaar te krijgen als engineer. Echter linux installeren op je laptop gaat echt niet werken. Als je het al lukt kan ga je niet kunnen inloggen met je werk account en heb je er niks aan.

Laat duidelijk zijn dat dit geen ideale situatie is natuurlijk.

[Reactie gewijzigd door Barsonax op 2 oktober 2026 07:48]

[Orthodroom]

Jij misschien wel, ik niet

En zo zullen er nog wel meer bedrijven zijn waar het uit staat.

[Kerfuffle]

Ik wil hier toch wel oproepen tot een stukje developer activisme. Als ik in gesprek ben met organisaties waar je als developer gedwongen wordt om apparatuur en infrastructuur te gebruiken die duidelijk niet bedoeld is om op te developen, geef ik direct aan dat dat een obstakel is om goede software te leveren. Ik heb er opdrachten om geweigerd, maar ik heb er ook kleine overwinningen mee behaald waar de klant oprecht niet besefte hoe onbruikbaar hun IT-organisatie was voor software development en de regels zowaar werden verruimd. Misschien leidt het tot een ruimer BYOD-beleid, misschien leidt het tot het kunnen gebruiken van bruikbaardere communicatiemiddelen dan Teams, misschien leidt het tot het inzicht dat niet alles via Citrix hoeft te lopen, misschien leidt het tot het inzicht dat een IT-organisatie die uitsluitend Microsoft snapt een aanvulling behoeft wanneer je hele software-deliveryketen op non-Microsoft spullen draait.

[Tassadar32]

Het is natuurlijk ook een keuze om wel of niet met/voor dat soort bedrijven te werken. Als we als developers collectief niet accepteren dat we in een kreupele omgeving moeten werken hebben bedrijven die hun dev team hetzelfde behandelen als een kantoormedewerker zonder IT kennis al snel een groot probleem.

[Webgnome]

Ook is het ook nog een keuze van mensen zelf. In ons team werken we met een mac, windows en linux door elkaar. Interessant om dan te zien waar je tegenaan loopt als we docker willen gebruiken voor lokale dev.

[kazuka]

Mocht je een Mac gebruiker zijn; Apple heeft onlangs zelf Apple Container uitgegeven voor macOS, wat exact hetzelfde doet. https://github.com/apple/container

[Daantje20]

Eigenlijk is de belangrijkste functie alleen via een community project beschikbaar voor wslc, en dat is de compose functie.

Als die er ook netjes in is verwerkt, dan is het pas echt bruikbaar.

[William_H]

Zoals er onderaan het artikel staat, compose is iets wat nog toegevoegd moet worden, maar waar wel aan gewerkt wordt.

[hosternokkezld]

Gebruikt iemand dit in de praktijk?

[FPSUsername]

Elke keer dat ik denk "dit moet ik met linux testen" kom ik erachter dat het niet zoals linux is. Zo kun je volgens mij nog steeds niet direct met randapparatuur praten.

Voor mij dan toch linux direct draaien.

Maar het zou zeker wat hebben als het zo krachtig is als linux direct op de hardware. Handig om zo dingen voor elkaar te krijgen die alleen goed gaan onder linux, terwijl je een windows pc hebt.

Wat ik echt nog eens zou willen zien is volledige compatibiliteit van linux symlinks in windows. Dat je het 1 op 1 kunt kopiëren en dat het gewoon is zoals je het verwacht.

[Zoijar]

Ja, al mn development met docker op wsl en vscode devcontainers.

[Sp3ci3s8472]

Toen ik als developer nog op Windows werkte zat ik meer in WSL dan in "Windows". Dus als je vraag was of men WSL gebruikt, de meeste developers doen dit ja.

Toen er nog geen WSL was gebruikte ik MobaXTerm (cygwin).

[Ethirty]

Voor mijn simpele doel werkt Docker desktop ook prima. Integreert in WSL en doet wat ik nodig heb.

Benieuwd wat je hiermee dan extra kan? Kan je bijvoorbeeld makkelijk bestaande (Docker) containers laden?

[Zoijar]

Snap ik er ook niet uit. Ja, je hebt geen docker desktop nodig dan... ok, een 30 seconden download en install. Ik zie niet echt reden om nu docker desktop te uninstallen.

[HMS]

Docker Desktop is natuurlijk sinds een tijd niet meer ‘gratis’ voor bedrijven. Je kan natuurlijk wel Docker CE in WSL draaien maar dat is niet altijd supported waardoor je vaak terugvalt op iets als Podman, wat ook net niet helemaal als Docker werkt.

We zullen zien. Microsoft is altijd erg goed in een geïntegreerde developer experience maken. Ze zullen hiermee een beetje in het gat willen springen voor bedrijven die de Docker Desktop licentie niet kunnen verantwoorden qua gebruik maar ook niet helemaal tevreden zijn over Podman.

[HJR]

Podman desktop is gratis en best goed te gebruiken. Volgens mij zitten er ook docker compose plugins in en dergelijke.

Op maCOS spint podman desktop 1 Linux vm op om daar de OCI images op te draaien. Gelukkig niet voor iedere container een VM. Dat is overkill.

Ik ben van m’n docker compose workload op een intel NUC 8i5 via proxmox en twee grote docker VMs. Daar wilde ik vanaf en heb de vms vervangen voor podman vms met systemd.

Sind juli ben ik helemaal over op Kubernetes en heb mn workload van ongeveer 70 deployments draaien op een NUC 13 pro met distributie Talos!

Wat een verademing zeg. Geen proxmox meer. Ik heb nog 3 native vms die ik onder kubevirt draai. En de overhead van Talos is echt minimaal.

Blijf niet te lang hangen op het legacy docker platform. Als je Kubernetes hebt gebruikt wil je echt niet meer terug.

[jimshatt]

Je kunt ook prima Docker in WSL draaien zonder Docker Desktop als schil in Windows. Integratie met sommige programma's die in Windows draaien kan af en toe wat lastiger zijn (docker cli en DOCKER_HOST configuratie, etc.) maar eigenlijk gebruik ik dat nauwelijks. En als het eenmaal draait dan draait het.

Maar goed, WSLC klinkt toch wel interessant.

[Wailing_Banshee]

Het probleem is dat je linux containers niet automatisch kunt starten zonder ingelogd te zijn in een windows server omgeving. Ik heb thuis een Windows Server 2022 draaien (ik heb helemaal niets met linux, heb het nooit gebruikt behalve in containers, en heb er 0 verstand van) maar wil wel graag wat linux containers draaien. Nu kan ik zonder problemen Docker Desktop/CLI installeren, maar als ik die wil gebruiken, moet ik een ingelogde gebruiker hebben. Dat is natuurlijk niet handig. Mogelijk dat het op deze manier wel kan? (moet wel de compose optie hebben...)

[Myri]

Is het niet net gevaarlijker dan bv. Docker gebruiken? Dit lijkt me een deur openzetten/makkelijker maken van je windows te benaderen vanuit een docker container. Security -wise lijkt het me dat je minder moet nadenken over hoe je de zaak inregelt en dat het net standaard "teveel" gaat openzetten?

[readefries]

Hoe is dit anders dan Docker? Dit is toch precies hetzelfde? WSLC spint ook gewoon OCI images op. Docker is ook geen beveiligslaag.

Wat ik er nu over lees, krijgt iedere container z'n eigen VM en je kan ze niet privileged draaien. Lijkt me juist veiliger.

- knip -

[Reactie gewijzigd door Bor op 2 oktober 2026 13:58]

[Myri]

Gebruikers kunnen hierdoor bijvoorbeeld een stuk sneller containers aanmaken, aldus de techgigant. Containers kunnen op deze manier ook sneller toegang tot Windows-bestanden krijgen.

Containers draaien via Docker op de 'gewone' WSL-installatie kon ook netwerkproblemen met zich meebrengen. Met WSLC is dat opgelost, wat onder meer de compatibiliteit met vpn-diensten en firewalls moet verbeteren.

Sneller, minder netwerkproblemen, makkelijkere integratie lijkt me dat je ergens shortcuts hebt genomen (tov. hoe docker het doet en aanbiedt). Maar moet er me eens meer in verdiepen, dus bedankt voor de link!

[SPee]

Sneller, minder netwerkproblemen, makkelijkere integratie lijkt me dat je ergens shortcuts hebt genomen (tov. hoe docker het doet en aanbiedt).

Nee. Docker moet een langere route nemen. Deze draait op een VM en moet via de Windows VM laag naar het netwerk of filesystem en daar zitten dus allemaal vertaalslagen tussen om dat mogelijk te maken. Dat zorgt voor vertraging (vooral toegang tot het filesystem van windows is trager). Deze tool zit direct in Windows waardoor je die vertaalslagen niet meer hebt.

Technisch doet het hetzelfde; een proces - afgesloten van de rest van het systeem - draaien. Als je je meer verdiept in Docker, VM's en OCI containers, dan zal het opvallen dat Docker minder doet dan je dacht.

[Arunia]

Ik ben al best een tijd terug begonnen op mijn thuis server met Docker Desktop. Maar omdat sinds 1,5 jaar het geheugen vol loopt (zo veel draai ik nu ook weer niet), heb ik een half jaar geleden alles "native" in WSL2 gehangen. Wel tegen wat problemen aangelopen, maar lijkt nu opgelost te zijn. geheugen problemen nog niet opgelost, maar wel iets beter.

Twijfel nu heel erg of het nut heeft WSLC te gaan draaien en of het heel veel meer werk zal zijn. Uiteindelijk draait er nu natuurlijk Linux in.

[thedjdoorn]

Ben zelf op podman (met podman machine) overgestapt op Windows, dat scheelt echt een enorme hoeveelheid bloat, zeker als je toch geen behoefte hebt aan een GUI. En qua commands hoef ik weinig tot niks aan m'n workflow aan te passen

[Arunia]

Voor mij is het vooral dat ik Portainer draai voor het grafische gedeelte zeg maar. Maar zit daar niet perse aan vast. Podman zal ik eens bekijken qua mogelijkheden.