Microsoft just shipped coreutils for Windows. Yes, you read that right.
ls. grep. cat. cp. find. The same commands that have powered Unix and Linux systems for over 50 years are now available natively on Windows, maintained by Microsoft itself.
In case you are not already familiar, GNU coreutils are the foundational utilities that every Linux and macOS system relies on for basic file operations, text processing, and shell scripting. They are the foundation of Unix computing. Tens of millions of scripts, pipelines, and workflows depend on them every day.
And now Microsoft is shipping and maintaining a build of them for Windows.
This is not WSL. You do not need a Linux subsystem running in the background. These "Linux commands" run natively on Windows, with the exact same flags and behavior as on Linux.
Microsoft's ultimate goal seems to make moving between Linux, macOS, WSL, containers, and Windows completely frictionless. Write a script once. Run it anywhere.
The Rust-based Windows coreutils is a work in progress
The package bundles uutils/coreutils (a modern Rust rewrite of GNU coreutils), findutils, and grep into a single multi-call binary. Every command supports standard flags. Same commands, same pipelines, no translation needed.
The project is still in preview and there are only a handful of commands. Since some commands have the same name in Linux and Windows, there is a possibility of conflict. Some don't fit in Windows environment.
Commands like dir, expand, more, paste, whoami conflict too directly with existing Windows built-ins. kill and timeout are unavailable due to Windows lacking POSIX signals. dd, dircolors, shred, sync, and uname were dropped as not useful on Windows. A longer list of POSIX-only commands like chmod, chown, chroot, mkfifo, id, who, and others are simply not applicable to the Windows environment. Who is surprised? Not me.
So, what commands are available as part of Windows coreutils then? The official GitHub repo does a better job at it:
Notice that there are separate columns for command prompt and PowerShell. Some commands would work in the default command prompt but not in the advanced PowerShell and vice versa.
Clearly, this is a work in progress and there should be more improvement on them in the near future.
Testing Linux commands on Windows
I booted into my Windows partition just to test it out. It's been months since I last logged in to the Windows and thus had to update the system with multiple reboots.
Sob story aside, I downloaded the .exe file for the Coreutils and installed it. Yes, these coreutils are offered in a single .exe file.
You can see a very brief demo of running some Linux commands in Windows command prompt. Some commands result in error as they are not supported yet.
A move for the agentic AI era?
See, the entire point of bringing Coreutils to Windows is to keep developers on the Microsoft platform. If they can use Linux commands and the tools their workflows depend on without leaving Windows, they have fewer reasons to switch to a Linux desktop. That is the same argument I made when WSL 2 was released years ago.
But this move goes beyond WSL, and in my opinion, it is not primarily aimed at developers, at least not in the direct sense.
Microsoft made several announcements at Build 2026 yesterday. One of them was bringing OpenClaw to Windows.
Now, OpenClaw is an open-source AI agent framework that lets autonomous agents run on your own machine. These agents rely on Linux commands, Python scripts, and similar tools to get things done. OpenClaw exploded in popularity earlier this year, so much so that people were buying Mac Minis just to run it locally.
These days, every operating system wants to be AI-ready. Development itself is increasingly happening through AI agents rather than purely by hand.
With OpenClaw coming to Windows, the ability to run Linux commands natively is no longer just a developer convenience, it becomes critical infrastructure for running AI agents.
That is what makes this announcement bigger than it looks. Microsoft is not just courting developers; it is positioning Windows as a serious platform for the agentic AI era.
A Vim fork has arrived, and it exists because of AI. Drew DeVault, the developer behind SourceHut, announced Vim Classic back in March 2026 after becoming unhappy with the direction both Vim and NeoVim were heading.
His gripe was that generative AI had started creeping into their development, and he wanted no part of it.
The NeoVim side of that concern is the project's labeling of AI-assisted pull requests as "AI assisted 🤖," which has now stacked up a fair number of requests, many of which have already been merged.
With Vim, the situation is a bit murky. Drew points to a GitHub issue where community members suspected one contributor of using LLMs, but a Vim maintainer had already pushed back on those accusations.
Drew warns that Vim Classic is meant for early adopters. Not for people looking to daily drive it.
A classic Vim experience
Screenshot of the website because building from source is ☠️.
Based on Vim 8.2.0148, Vim Classic predates the Vim9 script entirely. This was done deliberately to keep the maintenance burden manageable, stopping at the last patch before the script was introduced.
As a result, some Vim plugins that rely on Vim9 Script will not work with Vim Classic.
From that base, select patches have been backported from upstream, mostly addressing CVEs discovered after 8.2, alongside some bug fixes and original patches to keep things building on modern toolchains.
DeVault is also upfront that not every applicable security patch has been confirmed as backported, so some CVEs may have slipped through. The project is currently recommended only for early adopters comfortable with that uncertainty.
In addition, the charityware model carries over from Vim, with this project continuing to support the children of Uganda (albeit via a different charity) that Bram Moolenaar, the creator of Vim, endorsed.
📋
The original ICCF Holland charity was dissolved following his passing, with its mission carried forward by Kuwasha.
The packages
Vim Classic 8.3 is currently available as a source tarball from SourceHut (direct download). You will also find the release tarball and its PGP signature, signed with DeVault's public key, up on the project's refs page.
For the source code, head to the homepage of the SourceHut instance for Vim Classic.
I may hate AI slop but I am not a AI hater. I have found decent use of the AI tools and I try to include these tools in my workflow wherever it makes sense.
While mainstream LLMs like ChatGPT and Perplexity have decent free offering, they leach on the user data. "If you are not paying for the product, you are the product".
Recently, I discovered Jan AI. It is a polished, genuinely usable desktop app that runs entirely on my machine. In fact, I once tried replacing Ollama and llama cpp with Jan AI, but later changed my mind.
I'll explain why I switched back to Ollama in the later sections. First, let's learn about Jan AI.
What is Jan AI?
Jan is a free and open-source desktop application that lets you run various large language models directly on your own hardware. You can think of it as a self-hosted, offline-capable ChatGPT, except the model runs on your CPU or GPU, and no data ever leaves your machine.
The project is developed by the Jan.ai company, and the source code is available on GitHub under the AGPL-3.0 license. It's built on top of llama.cpp under the hood, which means it can run quantized GGUF models efficiently even without a dedicated GPU.
What I found impressive is that Jan's desktop application is built using the Tauri framework instead of Electron JS, which gives it a good performance boost and I think eats less RAM, too.
A quick catch, you still need plenty of RAM for running your local LLM.
The app supports Linux, macOS, and Windows. I used it on my Linux machine.
System requirements
Running a local LLM with Jan AI does require decent hardware. Here's what to realistically expect:
8 GB RAM minimum. It's enough for 7B parameter models at 4-bit quantization (Q4_K_M). You'll notice slowdowns with other applications open. 16 GB RAM is the sweet spot. It can comfortably run 7B models and lets you experiment with 13B models.
GPU acceleration is optional but makes a big difference. Jan supports NVIDIA (via CUDA), AMD (via ROCm), and Intel Arc. If you don't have a compatible GPU, CPU-only mode works, but it's significantly slower.
Disk space models range from around 4 GB (7B, Q4) to 8 GB+ (13B). Download only what you need.
📋
I've been running Jan on a machine with 16 GB RAM and no discrete GPU, and a 7B model gives me response times that feel somewhat usable.
Installing Jan AI on Linux
Jan offers multiple installation formats, including .deb and AppImage, but the AppImage is what I'd recommend for most Linux users. It's a single self-contained file that runs on virtually any distro without touching your system packages or requiring root privileges for the app itself. It requires no dependency hell. It's just made to work.
When you run Jan AI for the first time, you should see an interface like this:
Jan application interface for running local AI models
Downloading models and putting Jan to work
A freshly installed Jan is essentially an empty shell capable, but waiting. The first thing you need to do is grab a model. Think of it like the app is the frame and the model is the brain.
Finding your way to the model hub
Click the Hub in the left sidebar. This is Jan's built-in model library, a curated list of open-source models you can download with a single click.
There are dozens of models with names full of numbers and letters like Q4_K_M or IQ3_XS.
Jan AI application's model hub
Before I recommend which ones to pick, let me quickly demystify that alphabet soup because I spent an embarrassing amount of time confused by it when I first started.
What does Q4_K_M actually mean?
Every model name carries a quantization tag. Quantization is how a model's original full-precision weights get compressed to fit on consumer hardware. Here's a practical breakdown:
Q4: 4-bit quantization. The most common choice. Roughly 4 GB for a 7B model. Fast, memory-efficient, and quality holds up well for everyday tasks.
Q8: 8-bit quantization. Nearly full quality, but needs about twice the RAM. Worth trying if you have 32 GB or more.
K_M: The specific compression method (K-quants, medium variant). Generally, the best balance of speed and quality within the Q4 family.
XS (Extra Small): This is the most aggressive compression. It results in a file size that is slightly smaller than a standard Q4_K_S
💡
If you have 8–16 GB RAM, stick with Q4_K_M. If you have 32 GB+, try Q8_0 for noticeably sharper outputs.
The 3 LLM models I tested
I am using an AMD laptop with an integrated GPU. I settled for CPU interference for local LLM models because enabling RoCm (Radeon Open Compute) is a hectic task, based on my research. It requires 25-30 GB of disk space.
For those of you who aren't familiar with what AMD ROCm is, it's the answer to NVIDIA's CUDA. Basically, when you run a local LLM, the heavy math, such as matrix multiplications across billions of parameters, can be offloaded to a GPU instead of the CPU.
RoCm lets software like Jan AI, PyTorch, or Llama.cpp talks to AMD Radeon GPUs to do that same heavy lifting. Without it, Jan falls back to CPU-only mode, which works but is significantly slower.
For this article, I settled on three models that cover a solid range of use cases. I asked the same question to each model - "What can you do"? Here's what I found:
Gemma 4
I don't lie. The performance wasn't superb, only 5 tokens per second.
Gemma 3
The performance was bad than the Gemma 4 2B model. It was only 3 tokens per second. I think you can use the Gemma 3 2B model variant to achieve comparable performance.
Jan
Yeah! Jan offers its own AI model. I used the Jan-v3-4b model to test. It comes with 262K context length. It can follow up instructions and do some light coding tasks.
Features I liked in Jan AI
Let's see a few features that I liked in this open source AI tool.
Unified Interface for Local and Cloud LLMs
Jan can act as a unified interface for local and cloud LLMs, instead of jumping from Claude to ChatGPT and then Gemini. You get to talk to your favorite LLMs within a single interface.
Though directly interacting with Cloud LLMs takes away your privacy, you can still use Jan AI as a unified interface to interact with any models on HuggingFace, Groq, Gemini, Qwen, Mistral, and Claude with the respective platform's API.
Configuring cloud LLM provider like Groq, Gemini, OpenAI, Mistral and OpenRouter within a single unified interface of Jan
I'm especially in love with the Groq and Cerebras API. These platforms provide fast interference.
If your model provider is not in the list, you can still add OpenAI-compatible models to it.
To add, click on the plus icon next to "MODEL PROVIDERS". It'll ask for a name. Enter the name and then set the BASE_URL and API Key provided by your LLM platform.
Keeps your chats organized
Jan offers the functionality to organize chats per project.
Tailor Jan for Custom Experience
You can edit the system instruction. It's kind of making LLM behave like a specific expert.
Local API Server
It comes with a local API server. You can start the server by going to Settings -> Local API Server.
Use it as a tool to download AI models for Llama.cpp
Models downloaded with Jan AI application are completely compatible with Llama.cpp CLI. You can use Jan as a downloader tool and then run the downloaded AI model with llama-servera command.
Jan CLI
Jan offers a CLI interface to interact with as well.
My honest opinion on using Jan AI vs Ollama
Thanks to the developer involved in building the Jan AI app. It provides a nice GUI interface to interact with LLMs. On the contrary, I see some improvement scope for the application.
Ollama vs Jan AI application
The major one is with the local LLM inference time. I tested the same model, and what I found was that Jan AI provided slow inference time as compared to Ollama on the same hardware. Ollama produced a response at a rate of 6.62 tokens/sec while Jan AI produced a response at around 5 tokens/sec.
On the second test, Ollama reported 7.35 tokens per second while Jan AI responded at 3 tokens per second. Also, I tried Llama.cpp for the same Gemma 5 E2B model with 3.97 tokens/sec.
The secondary issue is Jan application often freezes your system. I agree, running LLM models takes significant RAM memory, but there are a couple of attempts I faced where giving a prompt with the Gemma 4 E2B model freezes my system. I haven't faced any similar issue with Ollama. That's why I kept Ollama and Llama.cpp for my local AI model inference.
Who is Jan AI actually for?
After spending time with it, I'd say Jan AI fits a few kinds of people particularly well. One thing I need to justify here, although in my tests, Jan struggled to give me more than 5 tokens per second in CPU mode, running it on a system with modern GPUs like Radeon GPU, Intel Arc, Nvidia 4050, you may get to see a huge boost in performance, especially with tokens per second. You could achieve around 13-15 tokens per second.
Privacy-conscious users who want AI assistance without feeding their conversations to a corporation. Lawyers, journalists, healthcare workers, and anyone handling sensitive information fall into this category.
Developers who want a local AI backend for their tools. The OpenAI-compatible API makes it drop-in compatible with a surprising number of existing integrations.
Linux enthusiasts who simply prefer FOSS software and want to own their stack. The fact that it's AGPL-licensed and actively developed is a big plus.
People on a budget. It comes with no API costs or subscription. You run it on hardware you already own.
It's not for everyone. If you need GPT-4 level capability for complex reasoning tasks, you'll still feel the quality gap compared to frontier cloud models. But for writing assistance, summarization, brainstorming, and everyday tasks? A well-tuned 7B or 13B model gets the job done.
The bigger picture
Local AI is no longer a hobbyist experiment. The AI models like Gemma 4, Gemma 3, Granite, Jan AI model, and SmolLM2 have gotten small enough that a standard laptop can run something genuinely useful. Tools like Jan have made the setup approachable enough that you don't need to be a machine learning researcher to get started.
Jan AI won't replace cloud services for everyone. But for a growing number of Linux users who care about privacy, cost, and control, it's become a daily-use tool. I'd encourage you to try it. Download it, grab a 7B model, and see how far it gets you.
If you have been following AlmaLinux OS, you know it is one of the more popular free enterprise Linux distributions out there.
Born out of the CentOS chaos, it has steadily grown into a community-governed project with a clear focus on stability and compatibility for production use.
Now, the AlmaLinux OS Foundation is taking things to Los Angeles, with an event squarely aimed at the studios and engineers who keep the entertainment industry running on Linux.
AlmaLinux Day: Los Angeles
Illustration by the AlmaLinux team.
This is a free, one-day gathering with a crowd that is set to be a mix of VFX engineers, sysadmins, cloud and DevOps folks, and open source contributors working in or adjacent to media and entertainment.
The AlmaLinux people have scheduled it a day before SIGGRAPH 2026, the premier annual conference for the computer graphics and VFX world, so that attendees get the technical conversations and networking in before the bigger crowd moves in on Sunday.
Sessions on Saturday will cover GPU driver integration for production use, the economics of running large-scale cloud rendering, and the AlmaLinux 2026/27 roadmap.
Of course the big reveal for the day is the launch of a dedicated AlmaLinux Media & Entertainment edition, which is a purpose-built variant tailored for the needs of studios and creative teams.
All of that is the result of the Media & Entertainment SIG's hard work, a group that has been at this since December 2025, working to get AlmaLinux certified and production-ready for VFX, animation, and post-production studios.
Event Details and Registration
The event takes place on Saturday, July 18, 2026, from 9:00 AM to 8:00 PM (local time) at the E-Central Downtown Los Angeles Hotel.
The venue can be found on OpenStreetMap (listed under the old name 'Luxe Hotel') and Google Maps. It is located at 1020 S Figueroa St., near the LA Convention Center.
Worth noting is that the event room has a hard cap, and the first 100 registrants get a special gift. So registering sooner rather than later is the wise move here.
The hotel is also ADA compliant, so people with nerfs (disabilities) should not face major barriers, though the actual experience on the day will depend on the venue's current setup and staff.
If you want to speak at the event, the call for speakers is open until June 5, 2026. They are particularly interested in topics like render farm architecture, migration stories, and security/CVE response in production.
You might remember that the KDE folks have been busy working on KDE Linux, their own Linux distribution that is still very much in active development. I tried its Alpha build last year and found the experience surprisingly smooth for something so early.
Fast forward to today, and Nate Graham, a well-known KDE name, has put out a progress report covering a pretty busy May for the project, with security fixes, build system changes, and a notable app swap all making the cut.
A lot of work
The most significant infrastructure work this month came from contributor Hadi Chokr, who reworked how KDE software gets built. The old process churned out Arch packages and handed them off to mkosi for installation.
That is now gone, replaced by KDE's own kde-builder tool compiling everything directly.
As a result, there are three major improvements. The build process now works the same way KDE developers build software on their own machines, the project is now more distro-agnostic, and builds are faster because the new setup uses caching more effectively.
Reacting to the many Linux vulnerabilities of last month (e.g., Dirty Frag and Copy Fail), the devs went through KDE Linux's package list looking for anything insecure or unnecessary.
The end result was a slew of cuts that included dropping the Zen kernel, axing several insecure kernel modules, removing a bunch of unused packages, and finally killing off the project's AUR dependency.
It's not all removals though. Nate also added a service that installs newly added pre-installed Flatpak apps on existing KDE Linux systems automatically, while leaving untouched anything the user has already removed on purpose.
There's a swap too; KWalletManager is being retired in favor of KeepSecret, a new, more modern KDE app for managing passwords and credentials.
Another thing to note is that Ark, the graphical file compression/decompression utility, now has .7z file support in its KDE Linux Flatpak packaging, bringing it in line with what the Flathub version already offers.
And, lastly, testing is being improved.
Right now, KDE Linux only checks that each build boots to the desktop, which is not saying much. Work is underway to change that though, with an OpenQA-based testing system in the works that should catch a lot more before a broken build goes out.
The Espressif-backed M5Stack has been keeping its Cardputer product line alive since 2023 by continuously updating it.
The original ran on an ESP32-S3, and the follow-up, the Cardputer-Adv, stuck with the same ESP32-S3 but brought in better audio, a larger battery, a 6-axis IMU, and more expansion options.
Both were decent microcontroller-powered devices, but neither ran a real Linux environment.
The CardputerZero is where that changes. It trades the ESP32 for a Raspberry Pi Compute Module Zero (CM0), and with that, the Cardputer platform goes from embedded tinkering territory into something you can do proper computing on.
📝 CardputerZero: Key Specifications
The horsepower is provided by a Broadcom BCM2837 inside the CM0, equipped with a quad-core Cortex-A53 at 1GHz with 512MB of LPDDR2 RAM and a VideoCore-IV GPU for graphics and hardware video codec.
The device itself measures 84 × 54 × 23.1 mm (W×H×D), small enough to fit in your pocket, with the display being a 1.9-inch ST7789v3 LCD with HDMI output up to 1080p at 30fps, which is paired with a 46-key matrix keyboard and a 1,500mAh LiPo battery.
Here are the rest of the specs:
RAM: 512MB LPDDR2
Storage: microSD card slot
Camera: Sony IMX219, 8MP (3280×2464), CSI 4-Lane (standard model only)
Wireless: 2.4GHz Wi-Fi 802.11 b/g/n, Bluetooth 4.2/BLE
USB: 2× USB Type-C, 1× USB-A (both USB 2.0)
Networking: 10/100M Ethernet
Audio: ES8389 codec, MEMS mic, 1W speaker, 3.5mm TRS out
Video: H.264/MPEG-4 decode at 1080p 30fps, H.264 encode at 1080p 30fps.
Expansion: Grove HY2.0-4P port (I2C/UART switchable), 2.54-14P bus (SPI, UART, I2C, USB, GPIO, 5V).
IR: Infrared TX/RX
Depictions of some of the above-mentioned specs.
There are a few other things to know before you get yours, though. The screen is not a touchscreen, and the magnetic attachment found on earlier Cardputer devices is gone.
You also get access to a built-in app store where you can load your projects or grab community firmware without needing to involve a computer. Carrying out lightweight edge AI via tools like OpenClaw is possible for local automation and testing.
Many Choices
M5Stack is offering the CardputerZero in two variants. The CardputerZero gets you a Sony IMX219 8MP camera, the full IMU sensor suite, and a 32GB microSD card. The CardputerZero Lite skips those three and costs less.
The CM0, keyboard, display, battery, Wi-Fi, Bluetooth, Ethernet, expansion ports, and infrared transceiver are all the same across both models.
For the standard CardputerZero, the MSRP is $149, but Kickstarter pricing looks like this:
Super Early Bird (reserved only): $89
Early Bird (72 hours): $104
KS Special: $119
Double Pack: $238
For the Lite, against an MSRP of $99:
Super Early Bird: $59
Early Bird (72 hours): $69
KS Special: $79
Keep in mind that we are now well beyond the window for any early bird offers and have now moved on to "KS Special", which is the limited-time pricing for buyers on Kickstarter that will be live until July 3.
There is also a Transparent Black version that was unlocked as a stretch goal after the campaign crossed the $1 million mark. It is a Kickstarter-exclusive colorway, and backers of either model can pick it at no extra cost through a PledgeBox survey once the campaign ends.
They will send out the survey when the crowdfunding campaign ends. 📝
Get Yours
The Cardputer platform has built up a decent community over the past couple of years, with firmware projects, retro emulators, security tools, and dashboards floating around GitHub.
Bringing Linux into the mix with the CardputerZero should give that community a fair bit more to work with.
As of writing, the campaign has raised over $1.4 million against a $10,016 goal, with over 10,900 backers and 32 days still left. Units are set to ship some time around November 2026.
Microsoft's WSL allows people to use Linux inside Windows. It integrates well in the system allowing people to use Linux command line Windows. Linux GUI apps can also be used, which helps for editing config file in GUI-based editors.
Now reverse the situation. How about using Windows applications on Linux? Sure, WINE and Bottles are there but I came across a new tool that combines container technology with Remote Desktop Protocol (RDP) to give you native-app feel for Windows software on Linux.
I am going to share my experience with Winpodx for running Windows software on Linux in this article. But first, lets briefly understand its mechanism.
How Winpodx Works
Under the hood, Winpodx relies on open-source tools like Podman, FreeRDP, and the dockur/windows project to spin up a lightweight, isolated Windows environment. This way, it runs a specialized Windows instance inside a background container. Then, instead of rendering a full virtual machine interface, it uses FreeRDP to seamlessly stream individual Windows applications directly to the Linux desktop, making them behave like native apps.
This setup allows Windows applications to launch and blend into the underlying Linux desktop with minimal overhead.
If needed, we can also access the full Windows desktop environment, which I will cover in a later section of this article.
Installing Winpodx
🚧
You'll need high-end system with at least 16 GB RAM. Fast and stable internet connection is a must for the installation as it downloads Windows ISO.
Before beginning the installation, there are a few important resource requirements to keep in mind. On its first launch, the installer will automatically download a full Windows ISO, which requires a fast and stable internet connection.
Second, because this setup runs a complete Windows operating system in the background, it is resource-intensive. To avoid performance issues, the host system should meet the following requirements:
Storage: A minimum of 50+ GB of free disk space. The installer explicitly recommends at least 64 GB of free storage space for a safe and stable setup.
RAM: At least 4 GB needed for the Windows container itself, alongside enough remaining host memory to keep the Linux system running smoothly. So, your system must have at least 16 GB of RAM for it to function smoothly.
If your system meets these requirements, install Winpodx using its universal installer script. Ensure curl is installed, open the terminal, and run:
The script will automatically configure the necessary packages and background containers.
To use the graphical configuration tool (winpodx gui), I needed to manually install the Python bindings for Qt. On an Arch Linux system, install this additional package via pacman:
sudo pacman -S pyside6
💡Tip: Managing the container after a reboot
Although Winpodx is designed to auto-start the background environment when you click an app icon, you might see a warning that the "pod is not started" after a fresh reboot.
If that happens, or if you just want to ensure everything is ready before you begin working, you can manually fire up the container using this command:
winpodx pod start --wait
Winpodx Start
Once the command finishes executing, the containerized Windows environment will be fully active and ready to launch apps or open the configuration GUI.
Exploring the features of Winpodx
Let me share some of the major features of this application that I tried.
Using Microsoft-specific pre-installed Windows apps in Linux
Microsoft Windows 11 comes with a number of default applications like notepad, paint, calculator etc.
This is the core feature of the tool. Applications installed inside the Windows container can be made available directly in the Linux system menus. Naturally, applications that aren't installed yet inside the container won't show up or be accessible to run.
To see what we have available, first, list the installed Windows applications using the command:
winpodx app list
This will output a list of the apps inside Windows that are ready to be integrated into Linux.
List Windows Apps
You can be selective:
winpodx app install app-name
Or, add them all to the host system, run:
winpodx app install-all
💡
Latest versions supports auto-discovery of apps.
This command automatically generates and registers .desktop files for all the compatible Windows apps so they populate the application launcher of the Linux system.
Regardless of whether they show up in the desktop environment's menu, you can always bypass the GUI and launch any Windows application directly from the Linux terminal using:
winpodx app run <app_name>
Where <app_name> is the exact name of the application as it appears in the winpodx app list output.
Get full Windows desktop
Winpodx gives you the option to run the full Windows guest desktop interface. While this isn't necessary for launching standalone apps, it becomes essential when you install new applications inside the guest Windows environment or tweak system configurations.
To launch the full Windows desktop, use the following command:
winpodx app run desktop
Windows Desktop
Alternatively, the same Windows desktop is accessible directly via a web browser. Connect to it by opening your favorite browser and navigating to port 8007:
http://127.0.0.1:8007
Windows Desktop in Browser
💡
Whenever you want a new application available through Winpodx, open this full desktop view, use the installer, and install it within the guest Windows instance.
I recommend downloading the installer file to the host system and then accessing the installer from the guest system.
Accessing Linux files in Windows
The guest Windows environment is integrated with the host system so that we can seamlessly access the Linux files from within the Windows container. This tight integration is precisely what sets this tool apart from a traditional, isolated Windows Virtual Machine.
The primary use case for this is opening and modifying Linux files directly with Windows applications. For example, you can use Windows Notepad or a specific Windows-only IDE to edit code or text stored on the Linux drive.
Opening Files
Secondly, this shared file system allows us to manage, organize, and work with the host files natively from within the guest Windows session, making cross-platform workflows incredibly smooth.
Managing everything from GUI
Winpodx includes a clean, graphical configuration tool built with Qt. This utility provides a central hub to manage the containerized setup without relying solely on the command line. We can use it to quickly launch a full desktop session, adjust system-level preferences, and monitor the container's status.
To open this Qt settings window from the host machine, simply run the following command:
winpodx gui
Winpodx GUI
Install Windows Apps
You can install Windows-only applications inside the containerized Windows session using standard .exe installers.
Run full desktop (or web interface) of Windows, download exe file and complete the program's installation wizard. You know the drill of installing an application on Windows, I hope.
After that. register the app with Winpodx so it can be launched from Linux. For that, open the Qt settings application:
winpodx gui
Inside the GUI, click on the Add App option and fill out the profile fields for the new program. If not sure of the exact executable path of the app, its always available in the properties of the application's shortcut file inside the Windows environment.
Create App Profile
After saving the app profile in the GUI, verify that Winpodx recognizes it by listing the available applications:
winpodx app list
Once it appears in the list, register and install the shortcut to the Linux desktop environment using the following command:
winpodx app install <appname>
For example, I installed the Notion desktop client, and integrated it into the system using:
winpodx app install notion
Notion and Evernote
Opening Windows files in Linux apps
Winpodx features a Reverse Open capability.
This is incredibly useful if you plan to work inside the full Windows Desktop environment frequently but still prefer your host Linux workflows for specific tasks.
For example, if you double-click a .txt or .md file inside the Windows guest, you can right-click it, head to the "Open with..." menu, and select a native Linux application like your host's text editor.
Open in Linux App
There is a dedicated "Linux Apps" folder, pinned to the sidebar of the Windows File Explorer, that contains a list of Linux apps available.
List of Linux Apps
💡
Winpodx also supports bidirectional copy-paste. There is scope for USB device passthrough as well.
Uninstalling Winpodx
If you decide that Winpodx isn't the right fit for your workflow, the project provides a dedicated uninstaller script to clean up its files, configurations, and containers. Depending on how thoroughly you want to wipe the data, there are two options:
To remove the Winpodx files but preserve the underlying Windows container data run:
The uninstaller script handles the Winpodx ecosystem and its containers, but it will not touch your system package manager.
Any core packages installed during the initial setup like Podman or optional dependencies like pyside6 will need to be uninstalled separately using your distribution's package manager.
Winpodx for the win(dows)?
Winpodx offers an innovative solution for accessing Windows applications on Linux system, provided you have a high-spec machine with plenty of resources to spare.
During testing, I occasionally encountered minor input lag and screen artifacts.
However, despite these occasional graphical hiccups, the majority of the applications remained functional and usable.
It is worth noting the contrast in cross-platform integration. Because of Linux's incredibly small resource footprint, running Linux GUI applications inside Windows (via WSL) is a much lighter process.
Conversely, running a full Windows environment on top of Linux via containers is naturally a heavy, resource-intensive operation. As development continues, the project will hopefully achieve better optimization and smoother performance in future updates.
Did you find this tool interesting? Will you give it a shot on your system, or do you prefer sticking to a traditional Windows dual-boot? Let us know your thoughts in the comments below!
