What I learned from trying Linux Desktop as a WSL user.

text

I switched from Mac to Windows a few years ago, right when they announced WSL integration. As an early adopter I instantly fell in love with it, even with WSL1. Things got even better when WSL2 was introduced.

My love for WSL got me to the point where I migrated my entire development workflow to WSL, and Windows became nothing more than a shell for everything else not related to development, like gaming, etc. And VS Code, which I mostly use in Remote-WSL mode.

As someone who is not strictly tied to specific apps, I started thinking about switching entirely to Linux Desktop. Luckily I have a spare SSD lying around, and I decided to give it a got without messing up my current setup.

And here’s how things went!

My current workflow

So the first thing to do was to look at my current workflow, within WSL and Windows, and write down all my (nearly) everyday use-cases and specifying what type of apps/services are crucial for me. I’m not talking about the apps themselves, since obviously not everything that is available in Windows is available in Linux, and vice versa. I’m rather talking about the functionality they have to provide.

WSL (running Arch)

As I already mentioned, I use WSL2 for my entire workflow. Even things that are not supported out of the box (like Flutter and PlatformIO), there are some easy workarounds to get them to work.

  • Docker
  • Web (NodeJS, PHP, Frontend…)
  • Go
  • Flutter *
  • PlatformIO (for my ESP8266 projects) *

Windows

  • VS Code in Remote-WSL mode
  • Windows Terminal
  • Communication: Mails, Messengers (WhatsApp, Slack, Discord)
  • Google Drvie
  • Screenshots (ShareX for images, gifs, videos)
  • Gaming (Steam, mostly Apex and CSGO)
  • Design with the Affinity Suite
  • Password Management (KeePassXC, with Google Drive sync)
  • Logitech G Hub for mapping G1-G5 keys

Hardware

  • Legion 5, AMD 4800H with NVidia RTX 2060
  • 3 external monitors
  • Logitech G815 heavily using the G1-G5 keys

Choosing the right distro

Since I already hopped from Ubuntu to Arch in WSL, I wanted to go with an Arch-based distro. My first choice here was Manjaro GNOME. So, I pulled out a USB stick, etched the ISO and booted into the installer.

And here’s already where I encountered my first problems.

When the installer boots up, my screens (internal and external) would flash a few times until they finally “settle”. My first thought was, it was due to some driver issues, so I went ahead and installed Manjaro anyway. After a successful installation, Manjaro booted from the SSD and after entering my password, the screens would flash again and finally take me to the desktop. Patiently enough, I installed the newest NVidia drivers, rebooted but the problem still persisted.

Unfortunately, I could not find any solution on the web, so I randomly decided to try out another distro, which is EndeavourOS.

Unlike Manjaro, EndeavourOS comes with only one installer, where one can chose the DE (Desktop Environment) during setup. The first thing I noticed is, that there was no screen-flashing when booting up the installer. Therefore, my first assumption was, that it’s somehow related to Gnome itself.

I went through the installtion of EndeavourOS and chose KDE. Finally, the OS booted up to the login screen, I entered my credentials and non of my monitors were flashing like they did on GNOME.

Boom, done! Right?

Getting things ready on Linux

Display arrangement in Windows

So now that Linux is booted up, I went ahead, installed the newest Nvidia drivers and arranged my monitors accordingly. Everything seemed to work fine, until I rebooted or logged out. While all monitors are arranged and oriented as I needed, number 2 just wouldn’t play along. It’s always upside down. I tried modifying Display Settings and Nvidia Settings, but none of them seem to work. So I just ignored this issue for now with the intention to come back to it sometime later.

Setting up the development workflow

As one would expect, setting up my WSL workflow in Linux was a no-brainer. Things like Docker, NodeJS, Flutter, PlatformIO worked out of the box. Unlike on Windows, no workarounds were needed.

Getting software from the right place

First thing to note, when using an Arch-based distro, is that there are multiple ways to install software. There’s the official repository using pacman, then there’s the AUR repository using something like yay and finally one can use containerized versions with flatpak or snap. And then there’s a nice GUI tool called pamac-all which allows you to install software through a GUI from each of the repositories.

My first hurdle teaching me a valuable lesson was getting VS Code to work properly. When I searched for “code” in pamac, the first thing that came up was “Code – OSS” which I thought was just another name for VS Code on Linux. Turned out, it’s an open source alternative, which does not include the sync option I needed to get my extensions and configs of VS Code running on Windows.

My second attempt was to install VS Code from flatpak. Since that version of VS Code runs inside a container, it does not have access to all the command line tools and env vars of my Linux setup, out of the box. Additional setup was necessary.

I eventually found out that I had to install VS Code from the AUR repository to have it work out of the box.

Getting available software

Communication: Since I run all my communication tools (mails, slack, etc.) in the browser, this again was a no-brainer. Although there are native versions of discord, slack, etc. which work flawlessly.

Gaming: Steam is available on Linux with games running natively or running in compatibility-mode with Proton. I was able to start up Apex, but due to the lack of Anti-Cheat within Proton, I was not able to play it. According to latest news, there’s a solution in the future.

KeePassXC: Since it’s cross-platform, it’s available on Linux, but…

Getting alternative software for Linux

Windows Terminal: Konsole on KDE is just as great as the Windows Terminal

Google Drive: kaccounts-provider and kio-gdrive are a combination of software to get Google Drive in the Dolphin file browser

Screenshots: Fireshot for capturing images and Peek for capturing videos

Design: GIMP and InkScape

Logitech G Hub: Piper

So, everything works, right?

Well, not quite! Here are some things that still keep me from switching entirely to Linux

KeepassXC and Google Drive: Unfortunately, KeePassXC cannot access the Google Drive folder the way it is mapped by kio-gdrive

Steam: Until Anti-Cheat is available, Apex Legends, which I play quite a lot, is not working.

Logitech G Hub: I heavily rely on the key-bindings of the G1-G5 keys, and G Hub is not available on Linux. And the alternative Piper isnt’t working for me.

Screenshots: Although Fireshot and Peek work quite well, the lack of having them accessible with my G1-G5 keys is just slowing me down in my workflow.

Conclusion

Linux Desktop is just not there yet! At least not for me, and not in this setup. I hope my findings provide you some insight, if you’re planning on switching to Linux.

Tags:
  • lmao says:

    tfw your workflow is taking screenshots and playing apex legends

  • >