Setting Up Arch Linux with KDE Plasma in Windows Subsystem for Linux 2 | Hacker News Reader

Setting Up Arch Linux with KDE Plasma in Windows Subsystem for Linux 2

rashil2000.me

84 pointsindigodaddy69 comments

A native method of running GUI applications in WSL2 is coming, I believe it'll be in GA in the Fall 2021 release: https://devblogs.microsoft.com/commandline/whats-new-in-the-...

XDC 2020 talk here: https://www.youtube.com/watch?v=b2mnbyRgXkY&t=7975s

For Windows Insiders running preview builds, I believe some of the pieces are present but not preconfigured. The XDC 2020 conference talk discusses the advantages of the built-in support, including fewer memory copies and lower latency.

"but the Arch community isn't onboard with the concept of WSL, or they aren't exactly comfortable with how easy WSL makes Linux installations for Windows users."

That's a bit disingenuous. WSL is generally irrelevant to a Linux user. I don't hear many discussions about pacman or yay amongst Windows users. OK, better analogy: I don't hear much about QEMU discussed by Windows users.

Good effort and nicely written up.

I happen to be a PHB that uses Arch and KDE (since I managed to get something like KDE 2.something to compile on my Slackware powered Pentium II back in the day.) I'm also a Windows sysadmin with 30 odd years under me belly errr belt.

>I don't hear much about QEMU discussed by Windows users.

Interesting that you chose QEMU and not, say, WINE, which definitely gets discussed even by Windows users. And, for that matter, is even more relevant since WSL also isn't an emulator.

As you said, a bit disingenuous.

WSL 2 is an emulator (Hyper-V).

It is not an emulator. It is a compatibility layer for ELF binaries that implements Linux system calls on Windows, among other things. It uses the same approach WINE ("WINE is not an emulator") uses.

You're thinking of WSL 1 (which behaves as you describe). WSL 2 actually uses virtualization and a linux kernel.

Source: https://docs.microsoft.com/en-us/windows/wsl/compare-version...

To be pedantic, Hyper-V is a hypervisor not an emulator.

"Interesting that you chose QEMU and not, say, WINE, which definitely gets discussed even by Windows users."

I've no idea what WSL is as such (virty, para-virty, emulator or whatever) but I do know what WINE and QEMU are and I run quite a lot of VMware and Hyper-V clusters.

I have a fair few employees who insist that Windows is lovely (mad fools.) They really don't spend much time discussing Linux virty technologies.

It is possible I've been a Windows sysadmin longer than you have been on the planet. I'm 50 and 30 years in the saddle.

It is not disingenuous.

WSL is a taboo term in the Arch Linux community, for one reason or the other. If you search for it in the Wiki, you get redirected to the Code of Conduct.

It is less about being irrelevant and more of a "we do not want to deal with that in any official capacity because of unspecified reasons."

Do you have an citation for it being taboo?

The whole structure of Arch, by contrast, makes having one-click installable images extraordinarily likely to be broken just for being out of date.

I do not know WHY it is taboo. I know it is because the only official resource given for the WSL term is a code of conduct document with no further explanation. Draw your own conclusion, I ain't got more than that.

Well, being redirected to the Code of Conduct when you search for WSL seems enough of a citation to me. Kind of surprised of such a behaviour of arch community, to be honest. Usually, it's one of the user-friendliest knowledge-bases on the Internet.

Caveat, I don't use Arch and am not in any way connected to the community. However, since several people have mentioned it but no-one has actually linked it, this is the redirect for WSL in the arch wiki:

https://gitlab.archlinux.org/archlinux/service-agreements/-/...

It specifically redirects to the subheader "Arch Linux distribution support ONLY". I'd draw specific attention to "Posting issues with, and requesting support for, derivative distributions or operating systems other than Arch Linux are prohibited."

It sounds like they're taking a very hard stance against allowing discussion on anything but "arch linux as installed described by our documentation and using our repositories". I know Arch has a lot of spin off distros with custom repositories or configurations, and they probably get annoyed answering support questions for them.

It seems like a loss to me, since these WSL images are using "native" Arch repos/userlands except for the WSL2 kernel, but I guess they'd rather play it safe than sorry.

> Arch Linux used to be an official app on the Windows Store some time ago, but the Arch community isn't onboard with the concept of WSL, or they aren't exactly comfortable with how easy WSL makes Linux installations for Windows users.

Is Microsoft comfortable with Wine, Proton, VKD3D, DXVK? Do they support or contribute to those projects?

Or even a better example, ReactOS. Should Microsoft support ReactOS?

Just mentioning this for posterity. Some solutions I've had are:

1. Using Cygwin, Cygwin's X12 server and ssh X forwarding to run Linux apps on Windows that were actually running in VirtualBox.

2. Same thing with Cygwin X server but running everything in WSL1.

3. Trying to natively compile things for Cygwin.

4. Using Docker for Windows to run specific apps, although this is fairly similar to #1.

5. Straight Hyper V Debian... Networking was such a pain I went back to VirtualBox.

I haven't messed with WSL2 yet but I imagine it'll be some cross of #1 and #2.

Compiling stuff in Cygwin was a pain somewhat, still took hours to compile seemingly every dependency if the thing you wanted wasn't in the Cygwin package managers. The X server is rock solid though.

The WSL1 sure is a neat idea but I can understand that being a dead end street so they hopped to virtualization.

Another commenter mentioned ChromeOS and I really dig how they made that work. Even better than OSX. Recently I got a Pinebook Pro and running arch it seems I have to run a Debian container and forward X for so much stuff I'm thinking about just going to Debian straight away, but I may lose some support for some things I'm not sure.

Edit: I forgot there is I think a closed source X server for Windows that is still free that supports some of OpenGL. I managed to get Kitty (terminal) running on that.

WSL2 is basically the same as WSL1 for the comparison you're making, though the upcoming GUI stuff will mean that you don't have to fiddle with the X server, it'll "just work".

The main difference I encounter between WSL1 and WSL2 is that accessing files across the OS divide happens through a networked filesystem instead of a natively shared filesystem, so it's not as seamless/performant, but the upside is much better filesystem performance when it's Linux doing Linux things. Which I'm happy about when it comes to containers. (I run both WSL1 and WSL2 on different computers.)

Docker for Windows also now has WSL integration so that you can launch Linux containers directly into WSL. I don't think it's configured by default just because you have to choose to install WSL, but once you've flipped the requisite switches it's seamless.

> The main difference I encounter between WSL1 and WSL2 is that accessing files across the OS divide happens through a networked filesystem instead of a natively shared filesystem

This has been my biggest gripe with WSL and linux virtualization on windows. WSL1 wouldn't work with some weirdly mapped network drives we had and with WSL2 (and linux in general) I don't find the drivers (or samba or some other component) stable enough when you're doing large writes to NTFS drives, I've had the same issues with vmware too.

This is one of the big reasons I'm still on cygwin, it's worked for years (maybe decades), it interoperates with windows better and all the little bugs have been worked out. Ultimately it's then GNU tools I'm after, the kernel isn't particularly interesting for my use cases.

> Ultimately it's then GNU tools I'm after, the kernel isn't particularly interesting for my use cases.

That’s an interesting take, and it makes sense that some people need properly hybrid setups. I personally used Cygwin mostly to have access to a Linux dev environment inside Windows, not so much to apply GNU tools to Windows development. As a result I’m pretty happy with WSL just for the sake of having a Linux dev environment within easy reach, and I typically don’t feel a need to do much with the shared file system.

My latest solution is to just install git sdk for Windows. It comes with pacman and mays, almost perfect for my research work.

It is my favorite too! I can quickly work in Bash/Zsh without starting any WSL sessions.

The site seems to switch automatically to night mode and is very hard to read generally. Not speaking for the disqus part, thats not readable at all. https://i.imgur.com/B7r2NMy.png

The font size is mostly way too small. I don't have the same issue with the Discus comments though

https://imgur.com/M8ejyUq.png

Looks like they're using the default LaTeX font which is OK in print and awful on computer screens.

Hey, thanks for the feedback! I'll get to work on the font right on. Regarding the `prefers-color-scheme` part, I haven't extensively tested on Firefox, but it works really well on Chromium-ish browsers.

here is your screenshot VS what I get when I visit the site: https://i.imgur.com/AHpKfUc.png

Not for me. Probably `prefers-color-scheme` CSS detecting your OS/browser settings ?

Would be interested to see some guide on supporting 3d acceleration. Wasn’t there some announcement last year they were sticking some d3d layer in wsl2?

They did, and it is pretty much useless for all currently existing Linux software because it all uses GL or Vulkan. You can write Linux applications using DX12 and they will run on the GPU in WSL2 but obviously they will not work on native Linux.

Maybe someone will write the inverse of dxvk to allow Vulkan or GL apps to run on top of the DX12 driver.

> Maybe someone will write the inverse of dxvk to allow Vulkan or GL apps to run on top of the DX12 driver.

Microsoft did. Mesa already has OpenGL to DX12 conversion, and they're working on Vulkan. https://docs.mesa3d.org/drivers/d3d12.html

This is amazing on a technical level and a kind of horrifying all at the same time.

Why? WSL1 was kind of interesting indeed, but WSL2 is just a VM, isn't it?

Yes, technically it is, but it's the integration that makes it interesting.

Plus theres the simple reality that Microsoft's got native APIs in Windows that enable running a linux vm with a KDE window alongside the standard windows environment. Microsoft has really come a long way and that's what's really amazing and kind of disorienting.

You've been able to run Linux in Hyper-V for a decade now though, it's not really anything new beyond the client-side integration.

WSL2 uses it's own init system - only one kernel (plus a tiny initrd) is virtualized by hyper-v; each subsequent linux instance (distribution) is containerized. There's additional facilities that handle resource allocation dynamically vs the user specifying a static amount during VM creation.

These (and more) result in the end-user interacting with WSL2 the same way they would any normal application. To think of it as simply a VM isn't quite correct.

Sure but I could just run Ubuntu and containerd in a VM and it's the same thing. Or just run k8s instead...

Not quite. WSL2 dynamically uses resources as needed (`vmmem`), whereas a traditional VM requires allocating a fixed amount of RAM and CPU from the host machine.

So I fired up Ubuntu first for my current WSL2... then I installed a Kali distribution.. are you saying that the Kali instance is really just a container inside the Ubuntu WSL2?

No. A minimal initrd + kernel is virtualized. Both Ubuntu and Kali are containers.

Ah gotcha. Neat stuff.

on hyper-v windows is kind of a vm aswell.

I'm kinda curious if in some wild future WSL3 ends up being Windows completely ditching the NT kernel for linux kernel and building up wine to be a first class Windows API emulator.

It's just increasingly silly in the Azure and server space to be running Windows--you lose all the benefits of the container ecosystem and have all the baggage of decades of windows cruft (yes I know windows containers exist--no one uses them). Desktop usage has been in decline forever and I have to imagine they could get the 90% of windows API apps left that matter to work great on wine. It would give Microsoft a huge boost to get back in ARM by building on the linux kernel and its great support vs. windows ARM very limited set of qualcomm and a handful of other chips.

AFAIK Windows is still one of Microsoft’s golden geese. If they transitioned to Linux, they’d lose out on all that sweet, sweet licensing revenue. Which makes this seem unlikely to me.

Last I heard internally there hasn't even been an official Windows OS team for the last couple years after Myerson left. It's been divvied up and split apart into parts of Azure, etc.

The OP's point is Microsoft is still making billions of dollars selling millions of Windows annual licences to both personnel and corporate users.

If they were to discontinue Windows they would just be throwing away those billions of dollars in annual income.

Since Windows continues to make Microsoft such large amounts of 'easy money' they would be stupid to not keep pushing it out to customers.

Not a new idea, see eg. https://news.ycombinator.com/item?id=24599397

I would recommend you to read this article by a former Canonical engineer - https://boxofcables.dev/no-microsoft-is-not-rebasing-windows...

ChromeOS's Linux support is even more streamlined than Windows's approach. You enable it, the container is automatically created (though, it is possible to install other distros -- but you void official ChromeOS support), and then graphical apps just work. All window management works across Linux, Android, and ChromeOS apps seamlessly, and even the open with dialog in the ChromeOS file manager shows apps across Linux, Android, and ChromeOS. The app launcher also includes Linux apps.

One unique "feature" I like about the setup is how easy it is to just delete the container and start-over if I'm so inclined. I have an elaborate set of scripts to bootstrap a newly created Linux container on ChromeOS -- if anything goes wrong, I can just delete the container and re-run the bootstrap scripts.

I'm a big fan of where ChromeOS has headed and I like the containerized approach to the problem a lot. It's extremely close to getting to the point where I'd consider ChromeOS over MacOS for a work laptop, especially since they added Desk/workspaces support. I use ChromeOS exclusively at home and for personal dev now.

Are we re-inventing, install linux GUI image oon hyper-V/any other VM. Wasnt wsl supposed to be a lightweight way of running cli tools? How is wsl2 any different from a regular vm when the image is fullblown.

I tried WSL2 once, but IPv6 doesn't work. Guess I'll check back in a few years.

Just install Linux.

I have a full blown Linux install on dual-boot, but for my purposes (gaming and some development on Windows, some development on Linux) it's honestly just easier to have WSL1/WSL2 around so that I can have both OSes around always, rather than having to reboot to switch.

For those purposes, I run Windows in a VM? In my case, the only reason I even need to run it at all, is that my employer has some software that requires it.

Qubes can do the opposite, I think.

What is the gaming experience like on Qubes for modern games? What about older games? Or VR?

This is an earnest question for the record.

Sorry, I don’t actually use Qubes, just know by reputation that they have worked on WSL2-style VMs for Linux.

I assume IOMMU passthrough works pretty well, when available. Also, I’ve been pleasantly surprised by how well Steam’s proton works even with applications that aren’t officially supported.

Why not use a Windows VM on GNU/Linux to have both OSes around usually, and one even when Windows is BSODing or Blue Screen of Forced Update-ing (yes I know you can procrastinate those for various amounts of time with various hidden settings or hacks, but seems easier to just use GNU, and personally even grow out of AAA gaming)?

Edit, responding to now-deleted reply:

> a good way to virtualize Windows that maintains decently high compatibility and performance with the games I want to play

Isn’t a normal VM with GPU passthrough that? I’m genuinely asking, because I’ve asked my original comment’s question several times before and never received answers except something about wanting to buy a computer with the OS installed from a brick-and-mortar retail store, which didn’t seem to apply to you given you’ve already installed GNU/Linux.

> I can lose out on a hobby I enjoy and pretend it's "growing up". Because as we all know games are for kids; adults who play them are manchildren.

I said personally because I personally have felt less addicted to games as I personally have grown older. Of course most people are different from me in many ways, but I don’t think everyone is in every one.

> a good way to virtualize Windows that maintains decently high compatibility and performance with the games I want to play

I'd legit rather kill myself than use Windows as my primary OS, so I dual-boot, but I'm frankly interested in that too. Not for games though, but for real-time audio. Does anyone have any experience with running a DAW on a Windows VM? Is it worth the effort?

The simple answer is that typically the software that keeps one tied to Windows is the type that wants/needs to be on metal.

Hardware passthrough does exist and I only expect it to improve, but we're still a ways from reaching "just works" level.

I just run them on different machines. My life is so much simpler without all those layers. Windows never messes with my Linux and vice versa.

Of course it helps that RDP and freeRDP both work very well. Whenever I need Windows I just fired up and I'm there instantly. If I want to play a game I go over to my gaming machine. Personally I never mix games and business.

I dual boot as well but I only switch to Windows to game which isn't too often.

From an enterprise it perspective, most of the time you cannot just install linux. corp computers need to be centrally managed, maintained, and compatible with all the crap the enterprise issues. for the most part that's windows or osx. in the past, my field at least has relied on either using a vm, or an unsupported second computer you need to expense and get exceptions for. WSL is pretty much a godsend as it's native windows supported, few exceptions needed from the enterprise, cheaper to expense, and less friction and better integration with windows than a vm.

imo, windows primary with WSL is the new standard to beat as far as working environment. I cannot even imagine going back to osx or using linux as my primary OS anymore.

I had running battles with a previous employer's IT department as we wanted to install linux (being developers in a large non-technical company) as we were deploying to linux targets. Unfortunately the powers that be were very slow/disinterested in helping so WSL was pretty much the only route to have something still serviceable. Shadow IT wouldn't have cut it.

I did. But I also have Windows machines, in which I use WSL2. Granted, I don't use GUI applications on them (or see much need to).

It's actually quite nice to have a "real" linux instance available on virtually any Windows machine. I believe Microsoft is targeting the "developer who uses a Mac" market share with WSL2 and I expect more and more to jump ship, as the experience is significantly better.

Apple wins in the hardware department by far. Even before M1. If this targets anyone it targets developers who play video games.

I think most developers would be happy with a Thinkpad, if it meant they could use Docker without pulling their hair out.

How would you feel if you were to ask someone "Hey how do I run Office on Linux (for whatever reason, probably work-enforced)?" and they replied "JuSt iNsTaLl WiNdOws!"

This wasn't the question, but depending on what the issue is, the chances are that I'd give the same advice - "just install Windows". And since you're the author, would you mind to explain what was your reasoning behind why you thought something like this was necessary?

It wasn't necessary. I just wanted to experiment; I had some free time over the holidays. The blog is just a PoC. GUI apps on Windows are more than enough; there should be no need (currently, at least) to have GUI apps running in WSL.

Reply on news.ycombinator.com