The Hot Take: Nore more docker on Windows? Interesting.
Windows 11 can now build, run, and manage Linux containers on its own, without Docker Desktop in the background. Microsoft calls this WSL Containers, and after installing the preview and running a few real workloads through it, here is what works, what still needs Docker, and how to get it running on your own PC.
WSL Container should not be confused with the next version of WSL 2, as we already covered how Microsoft shut down the WSL 3 rumors. It has now shipped as a public preview, so we installed it, built a custom container image from scratch, and pushed it through a few workflows to see where it holds up.
What is WSL Container in Windows 11
WSL Container is a built-in feature of the Windows Subsystem for Linux that lets you create, run, and manage Linux containers directly from Windows, without installing Docker Desktop, Podman Desktop, or any other third-party runtime. It ships in two parts:
The first is wslc.exe, a command-line tool that is added to your PATH as soon as you update WSL. Microsoft also ships an alias called container.exe, so both commands point to the same binary. Anyone who has used Docker before will recognize the syntax, since commands like wslc run, wslc build, and wslc container list look like Dockerâs own structure almost one-for-one.
The second part is a WSL Container API, distributed as a NuGet package with support for C, C++, and C#. Windows application developers can use it to embed Linux containers directly into their own apps.
Instead of asking users to install a separate runtime, a Windows app can quietly spin up a Linux container in the background to run a piece of Linux-only code, then tear it down when the task finishes. Microsoft demoed this with Moonray, an open-source Linux rendering engine used on films like The Wild Robot, running inside a Windows executable with no visible sign that Linux was involved at all.
Moonray is a Linux-based rendering engine that can run inside Windows through WSL Container
Every Windows application that uses the API gets its own Hyper-V-backed virtual machine, separate from every other appâs container. The CLI flow gets its own VM too. Docker Desktop, however, runs every container inside one shared VM, which as youâd expect is more efficient.
WSL Containers trade some resource efficiency for a hard isolation boundary between apps, which explains why Microsoft is pitching this as enterprise-ready.
That said, both entry points talk to the same WSL service that already manages your regular distros, and inside the Linux VM, the container runtime doing the real work is Moby, the open-source engine that also powers Docker. Note that WSL Containers is not reinventing containers. It is, instead, giving Windows a first-party front door to them.
How to install WSL Container on Windows 11
WSL Container only ships in the pre-release channel of WSL for now, so you will need to opt into that before wslc shows up on your PC.
Open Windows Terminal or PowerShell as an administrator.
Run wsl âupdate âpre-release and let it finish downloading.
Restart WSL with wsl âshutdown command, then close and reopen your terminal.
Confirm the install with wslc âversion. You should see the version number 2.9.3.0, which confirms WSL Container is installed.
Run wslc âhelp to see the full command reference and confirm the binary is working.
In our test machine, the update took under two minutes over a decent connection. If wslc is not recognized right after the update, restart your terminal, and if that does not help, restart the PC. Since itâs in the pre-release channel, there might be some rough edges, as a few developers on Microsoftâs own devblog reported a Catastrophic failure, Error code: E_UNEXPECTED when running their first container. Fortunately, we didnât face the issue.
In case you are wondering, you do not need a Copilot+ PC to try this since WSL Container ships as a plain WSL component, but the Hyper-V-backed isolation model needs the support of modern virtualization, so a recent CPU with virtualization enabled in BIOS or UEFI counts for more here than it does for a regular WSL distro.
Building and running a container with wslc
Once wslc was working, we skipped the basic hello-world example everyone else is running and went straight to something closer to real use, building a custom image from a Containerfile and exposing a working service from it.
Creating a project folder for WSL container test
First, a quick sanity check. We pulled and ran a Debian container interactively:
wslc run -it debian:latest
Inside the container, running uname -a returned a Linux kernel string tied to WSL2, confirming we were sitting inside a real Linux environment instead of some translation layer.
Running uname -a inside a WSL container confirms it is a real Linux kernel, not a translation layer
Detaching with Ctrl+P, Ctrl+Q and running wslc ps -a listed the container by its autogenerated name (mossy_sawtooth), alongside how long ago it started and its current status.
wslc ps -a lists every container, whether it is running or has already stopped
Reattaching with wslc attach mossy_sawtooth dropped us straight back into the same shell.
reattaching to the container name mossy_sawtooth
Next, we wrote a Containerfile, which works the same way a Dockerfile does, to package a small Linux inspection utility that runs file, exiftool, and binutils against whatever gets dropped into it.
The Containerfile packages a small Linux inspection tool, working the same way a Dockerfile does
Here is roughly what that file looked like:
FROM python:3.12-slim
RUN apt-get update && \
   apt-get install -y âno-install-recommends \
       file exiftool binutils bsdmainutils coreutils && \
   rm -rf /var/lib/apt/lists/*
WORKDIR /app
COPY requirements.txt .
RUN pip install âno-cache-dir -r requirements.txt
COPY app.py .
EXPOSE 5000
CMD [âpythonâ, âapp.pyâ]
Building it was one command:
wslc build -t my-linux-inspector .
Building the custom image with wslc build
The build cached its base layers, so a rebuild finished in seconds instead of minutes. Running wslc image ls confirmed the image existed locally with a fresh timestamp.
wslc image ls confirms the custom image built successfully
From there, we started the container with a port mapping so the Flask server running inside Linux could be reached from Windows:
wslc run -d -p 5000:5000 âname inspector my-linux-inspector
Loading 127.0.0.1:5000 in a browser on the Windows side brought up the toolâs web interface without any extra networking setup.
The Flask server inside the Linux container, reached through localhost on Windows with no extra networking setup
A service running on a Linux kernel, reachable through localhost on Windows, with zero third-party software installed, sums up WSL Container in one sentence.
Testing GPU access inside a WSL container
GPU passthrough is the feature most developers doing AI or machine learning work will care about most, since it decides whether a Linux container can reach the graphics card instead of running on the CPU alone. WSL Container supports this through a --gpus all flag, the same syntax Docker users already know:
wslc run --rm --gpus all pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime \
python -c "import torch; print(torch.cuda.is_available())"
The clip below shows this in action, a container reaching the GPU directly, then racing a compiled PyTorch model against the same model running in plain eager mode. The gap between the two is not subtle.
https://www.windowslatest.com/wp-content/uploads/2026/07/testing-GPU-access-inside-a-WSL-container.mp4
WSL Container for enterprise environments
Microsoft is pitching WSL Container as enterprise-ready from the preview stage.
Microsoft Defender for Endpointâs existing WSL plugin now understands container events, so security teams monitoring WSL distros get the same visibility into containers without deploying separate tooling, though the feature is currently limited to a private preview with its own signup form.
IT admins can already control WSL Container today through Group Policy and an ADMX policy, with two capabilities that count most in a managed fleet:
First, admins can decide whether people in their organization are allowed to use WSL distros, containers, or both.
Second, and this is the one Microsoft says came up constantly in customer requests, admins can set an allowlist of which container registries are permitted, so a company can restrict pulls to an internal or approved registry instead of leaving Docker Hub wide open.
We expect full Intune dashboard support for these settings within a few weeks of the preview shipping.
VS Codeâs Dev Containers extension also picked up wslc support starting in version 0.462.0-pre-release. Switching to it just means opening Dev Container settings, finding the Docker Path field, and changing it to wslc, no need to reinstall extensions or reconfigure projects.
What is still missing from WSL Container
WSL Container does not ship with anything resembling Docker Compose at this stage, so multi-service projects that use a compose.yaml file to bring up a database, a backend, and a cache together are not a good fit yet. Every container we tested had to be started individually.
And of course, the biggest omission is that there is also no GUI dashboard, or anything like Docker Scout for scanning images. Also, the extensive plugin ecosystem that Docker Desktop has built up over the years does not exist here. WSL Container is not meant to replace Docker Desktop, Podman Desktop, or Rancher Desktop, and all three of those tools stand to benefit from the same low-level platform work, including the new virtiofs file system that Microsoft says makes Windows file access twice as fast inside containers.
Networking has also been reworked with an experimental mode called Consomme, which relays Linux traffic through the Windows networking stack instead of the older NAT setup, aimed at fixing the VPN and proxy compatibility issues that have annoyed WSL users for years. Both virtiofs and Consomme are currently exclusive to WSL Container, though Microsoft has said it wants to bring them to regular WSL distros eventually.
Should you switch from Docker Desktop yet
For a single container running a database or a small service during local development, WSL Container already does the job without asking for a separate license. For anything that needs Compose files, multiple linked services, or Dockerâs extension ecosystem, Docker Desktop is still the more complete tool for now.
Microsoft is targeting WSL Containerâs general availability for fall 2026, and given how closely the CLIâs syntax already tracks Dockerâs, most of what is missing looks like a matter of when rather than if.
If you already run Linux container workloads on Windows, running the pre-release build alongside Docker Desktop costs nothing and gives WSL Container a head start before it becomes the default choice.
The post I built a Linux container on Windows 11 without Docker Desktop, and Docker users should pay attention appeared first on Windows Latest
By ckasprzak | TkOut | June 8, 2026 | Linux, Software
The Hot Take: d0h!
Back in March Steam on Linux skyrocketed to 5.33% with more than double the Steam gaming marketshare of macOS. Then for April Steam on Linux pulled back to a still-great 4.52%, well above the times when Steam on Linux was at 2% or less for many years. Now the May 2026 figures have been published overnight by Valve...
The Hot Take: Linux becoming a target with people migrating over to it for sure.
Qualys's Threat Research Unit (TRU) has discovered and published a logic flaw in Linux kernel "that permits an unprivileged local user to disclose sensitive files and execute arbitrary commands as root on default installations of several major distributions." Friday their blog pointed out "The bug has resided in mainline Linux since November 2016 (v4.10-rc1)."
"Upstream patches and distribution updates are already available."
Working exploits are circulating publicly, and administrators should apply vendor kernel updates without delay. During ongoing research into Linux kernel privilege boundaries, TRU identified a narrow window in which a privileged process that is dropping its credentials remains reachable through ptrace-family operations even though its dumpable flag should have closed that path. By pairing this window with the pidfd_getfd() syscall (added in v5.6-rc1, January 2020), an attacker can capture open file descriptors and authenticated inter-process channels from a dying privileged process and re-use them under their own uid. The primitive is reliable and turns any local shell into a path to root or to sensitive credential material [including host private keys under /etc/ssh ]
CVE-2026-46333 is local-only, but the impact is severe... Any unprivileged shell on a vulnerable host is enough to read /etc/shadow, exfiltrate SSH host private keys, or execute arbitrary commands as root through hijacked dbus connections to systemd. In practice, the distinction between an unprivileged foothold and full host compromise collapses: a phished developer account, a constrained CI runner, a low-privilege service account, or a shared multi-tenant host all become direct paths to root. With the vulnerable code shipping in mainline kernels since v4.10-rc1 (November 2016), the historical exposure spans nine years of enterprise fleets, cloud images, and container hosts.
Qualys followed responsible disclosure throughout. Qualys reported the vulnerability privately to the upstream Linux kernel security contact on 2026-05-11. Over the following three days the kernel security team developed and reviewed the fix, CVE-2026-46333 was assigned, and the patch was committed publicly on 2026-05-14. We then engaged the linux-distros mailing list, the standard pre-disclosure channel for downstream coordination. A short time later, an independent exploit derived from the public kernel commit appeared.... Qualys is releasing the complete advisory today because the underlying technique is novel, the public picture is now incomplete and uneven, and independent researchers have already achieved local root and published exploit material. Doing so gives defenders, detection engineers, and downstream maintainers a single authoritative reference for the flaw, the race against do_exit(), the role of pidfd_getfd(), and the four exploitation case studies.
Read more of this story at Slashdot.
The Hot Take: Been saying it for years, Microsoft is pulling Linux into windows on bite at a time. This probably I would assume only accelerates.
Microsoft is turning Azure Linux into a general-purpose, Fedora-based cloud distribution available to all Azure customers, while also productizing Flatcar as Azure Container Linux for immutable container hosts. "When Microsoft joined the Linux Foundation, there was this big conspiracy theory that somehow the Linux Foundation was undermining open source in partnership with Microsoft, and now you announce that you're shipping a Linux distribution," Jim Zemlin, the Linux Foundation's CEO, said in response to Microsoft's surprise announcement. "That's amazing." ZDNet reports: Until now, [Lachlan Everson, Microsoft's Principal Program Manager on Azure's open-source team] noted, "we had Azure Linux only available to third-party customers through AKS specifically, and that was Azure Linux 3.0." Going forward, this will be ACL. Everson emphasized that Azure Linux 4.0 is the culmination of years of internal usage and the evolution of the earlier Mariner distribution. "So we've been running Azure Linux for many years internally, and we got through to 3.0, and we only allowed it on as a container host on AKS. What we've done is make it a general-purpose, so this is all the learnings that we've had in the heritage of Mariner."
Under the hood, Azure Linux 4.0 is based on Fedora Linux and is delivered as an open distribution on GitHub. This code is available now. Yes, Red Hat knows that Microsoft has done this. Everson continued, "So, we made a decision to use Fedora as an upstream, so it's using RPMs in the Fedora ecosystem. Microsoft curates the packages and the supply chain to fit Azure's cloud platform." Microsoft also created "it to be purpose-built for Azure, which integrates vertically into all of our infrastructure to give you the best Azure Linux experience on Azure." While Azure Linux will ship as a VM image, Microsoft is already preparing a developer-friendly path onto Windows desktops: "And as of today, we have it as a VM image for your VM host on Azure. We're going to announce WSL images as well."
While developers will be able to run Azure Linux locally through WSL, Microsoft is not positioning it as a traditional desktop Linux. Asked whether he could run it on his laptop, Everson said: "I will be able to run it on my laptop, or what have you. Yes, on Windows 11." However, when pressed about a desktop experience, Everson was clear that there are "no plans" for a graphical environment. "It's optimized for server-side in the cloud," he said, adding that even on a developer machine, users should expect a lean environment. "Minimal packages, yeah. The idea is that we offer you a consistent experience to do your development on your machine, and that you can take your workloads as you develop them on your machine and run them with VS Code. You can run your applications on that, and know that the platform is the same that you're running on the cloud, so that you have that kind of consistency between environments."
Flatcar itself remains the upstream project, but Microsoft is packaging it for Azure customers. Everson described Flatcar as "purpose-built, immutable, secure by default, production-ready operating system, and Azure Container Linux is the productization of that, but we're still investing in the upstream Flatcar ecosystem and pulling that downstream into a productized exterior experience just for container workloads, so it's a container hosting in AKS." To underscore the immutable model, he added that "Everything's baked in, so there is no package manager. We bake the bits into the immutable, and they're in the immutable version. So Azure Container Linux is the immutable version. So you shouldn't be changing any system packages or any application packages. Anything that you need to change is customer workloads run in containers."
Read more of this story at Slashdot.
The Hot Take: Closed source finally making it onto OSS OS, nice!
AMD has taken a major step toward enabling native open-source HDMI 2.1 support on Linux by submitting new patches for its AMDGPU driver. AMD Moves Closer to Open-Source HDMI 2.1 Support on Linux With New AMDGPU FRL Patches It appears that the HDMI 2.1 support is finally arriving to Linux as AMD has submitted the new Fixed Rate Link (FRL) patches for its AMDGPU driver. This has been one of the longest-standing limitations that affected Radeon GPUs on the platform. There have been years of restrictions tied to the HDMI Forum (Org behind the HDMI standard) policies that prevented upstream [âŚ]Read full article at https://wccftech.com/amd-finally-cracks-hdmi-2-1-on-linux-after-years-of-forum-lockout/
By ckasprzak | TkOut | May 3, 2026 | Linux, Software
The Hot Take: This has me very intrigued, I just wish Logitech and others with their software control on mice would jump onboard.
Steam on Linux use in March "had skyrocketed to 5.33%..." reports Phoronix, "easily the highest level we've seen Steam on Linux at since its inception more than a decade ago."
So what happened in April?
[April's results] point to Linux having a 4.52% marketshare on Steam, a drop of 0.81% compared to March. Year-over-year it's roughly double with Steam on Linux in April 2025 being at 2.27%. Or two years ago for April 2024, Steam on Linux was at 1.9%.
Read more of this story at Slashdot.
The Hot Take: As Linux gains market share just put a target on its back for compromise.
A new report from Sonatype identifies 21,764 malicious open source packages in the first quarter of the year, up 21 percent from the same period last year and bringing the total logged since 2017 to 1,346,867. The npm registry continues to be the target of most new malicious attacks, at 75 percent, seeing the equivalent of 46 malicious packages per day, with the quarter defined by credential theft, host reconnaissance, and staged payload delivery aimed at developer and CI/CD environments. Python package index PyPI saw 18 percent of total malware in Q1, with other registries significantly lower, suggesting that attackers⌠[Continue Reading]
By ckasprzak | TkOut | April 4, 2026 | Linux, Software
The Hot Take: This is good, as Windows 11 is just a pile of poop these days. I'm waiting on native support from game publishing houses, as I hate abstract/emulation layers. We still need the peripheral companies to publish apps to control all those RGB's on our systems and keyboards too.
Valve's March 2026 Steam Survey shows Linux gaming usage jumping to a record 5.33% share -- more than double macOS's 2.35%. Phoronix reports: Steam on Linux was never above 5% and easily an all-time high for the Linux gaming marketshare, especially in absolute numbers. It was a massive 3.1% spike in March while macOS also jumped surprisingly by 1.19% to 2.35%. The Steam Survey numbers show Windows losing 4.28%, down to 92.33%.
Part of the jump at least appears to be explained by Valve correcting again the Steam China numbers. Month over month they report a 31.85% drop to the Simplified Chinese language use and English use increasing by 16.82% to 39.09%. Other languages also showed gains amid the massive decline in Simplified Chinese use.
The latest numbers for March show around a quarter of the Linux gamers are running Steam OS. Due in part to the Steam Deck APU being a custom AMD product and the popularity of AMD hardware on Linux for its open-source nature, AMD CPU use by Steam on Linux gamers remains just under 70%.
Read more of this story at Slashdot.
The Hot Take: Linux is coming for Windows Gamers for sure!
Linux gamers are seeing massive performance gains with Wine's new NTSYNC support, "which is a feature that has been years in the making and rewrites how Wine handles one of the most performance-sensitive operations in modern gaming," reports XDA Developers. Not every game will see a night-and-day difference, but for the games that do benefit from these changes, "the improvements range from noticeable to absurd." Combined with improvements to Wayland, graphics, and compatibility, as well as a major WoW64 architecture overhaul, the release looks less like an incremental update and more like one of Wine's most important upgrades in years. From the report: The numbers are wild. In developer benchmarks, Dirt 3 went from 110.6 FPS to 860.7 FPS, which is an impressive 678% improvement. Resident Evil 2 jumped from 26 FPS to 77 FPS. Call of Juarez went from 99.8 FPS to 224.1 FPS. Tiny Tina's Wonderlands saw gains from 130 FPS to 360 FPS. As well, Call of Duty: Black Ops I is now actually playable on Linux, too. Those benchmarks compare Wine NTSYNC against upstream vanilla Wine, which means there's no fsync or esync either. Gamers who use fsync are not going to see such a leap in performance in most games.
The games that benefit most from NTSYNC are the ones that were struggling before, such as titles with heavy multi-threaded workloads where the synchronization overhead was a genuine bottleneck. For those games, the difference is night and day. And unlike fsync, NTSYNC is in the mainline kernel, meaning you don't need any custom patches or out-of-tree modules for it work. Any distro shipping kernel 6.14 or later, which at this point includes Fedora 42, Ubuntu 25.04, and more recent releases, will support it. Valve has already added the NTSYNC kernel driver to SteamOS 3.7.20 beta, loading the module by default, and an unofficial Proton fork, Proton GE, already has it enabled. When Valve's official Proton rebases on Wine 11, every Steam Deck owner gets this for free.
All of this is what makes NTSYNC such a big deal, as it's not simply a run-of-the-mill performance patch. Instead, it's something much bigger: this is the first time Wine's synchronization has been correct at the kernel level, implemented in the mainline Linux kernel, and available to everyone without jumping through hoops.
Read more of this story at Slashdot.
The Hot Take: Linux appears to be getting more Rust by the day.
BrianFagioli writes: Canonical has joined the Rust Foundation as a Gold Member, signaling a deeper investment in the Rust programming language and its role in modern infrastructure. The company already maintains an up-to-date Rust toolchain for Ubuntu and has begun integrating Rust into parts of its stack, citing memory safety and reliability as key drivers. By joining at a higher tier, Canonical is not just adopting Rust but also stepping closer to its governance and long-term direction. The move also highlights ongoing tensions in Rust's ecosystem. While Rust can reduce entire classes of bugs, it often depends heavily on external crates, which can introduce complexity and auditing challenges, especially in enterprise environments. Canonical appears aware of that tradeoff and is positioning itself to influence how the ecosystem evolves, as Rust continues to gain traction across Linux and beyond. "As the publisher of Ubuntu, we understand the critical role systems software plays in modern infrastructure, and we see Rust as one of the most important tools for building it securely and reliably. Joining the Rust Foundation at the Gold level allows us to engage more directly in language and ecosystem governance, while continuing to improve the developer experience for Rust on Ubuntu," said Jon Seager, VP Engineering at Canonical. "Of particular interest to Canonical is the security story behind the Rust package registry, crates.io, and minimizing the number of potentially unknown dependencies required to implement core concerns such as async support, HTTP handling, and cryptography -- especially in regulated environments."
Read more of this story at Slashdot.