KDE in wsl2
Cheers 🍻 to those who owns a surface pro x and tries to do some development work on it.
By now, most is probably regretting why they didn’t buy a normal non-ARM surface pro or just an M1. Although wsl2 is very nice, it is not really mature enough. It has some nasty bugs such as slow network and slow filesystem, which leads to a big pain when development code is running on WSL while being accessed from a browser or IDE in windows. This pain explodes further by the fact that almost no IDE except VS Code runs on the windows ARM platform.
A current workaround is to have Windows X Server VcXsrv and then just sort of like boot into the GUI of the linux platform of choice in WSL and do development completely there, including the IDE and its browser during frontend work. At this point, most is likely considering to just run linux natively. Unfortunately again, linux kernel does not run on surface pro x processor and gpus. Now we are back to the workaround, but unfortunately again VcXsrv does not run on surface pro x due to it being an ARM aarch64 platform. Thanksfully, xrdp comes to the rescue.
Setting up KDE and xrdp
This guide assumes you have already the wsl set up. The commands here are for Debian and KDE (my favorite ones), if you need something else, I guess you can just tweak it accordingly.
# update packages list
sudo apt-get update
# install kde and its required component
sudo apt-get install kde-plasma-desktop dbus-x11
# install xrdp
sudo apt-get install xrdp
Now, since there is no systemd in wsl and its workaround systemd-genie does not work in aarch64, we will have to start xrdp every single time before we want to remote desktop there. Not to mention we can’t use localhost since it will be very slow due to the wsl localhost limitation. Let’s just script our way through.
tee ~/rdp.sh << END
#!/usr/bin/env bash
# start xrdp
sudo /etc/init.d/xrdp start
# figure out wsl ip
WSL_IP=\`ip addr show eth0 | grep -oP '(?<=inet\s)\d+(\.\d+){3}'\`
# run the windows rdp app
mstsc.exe /v:\$WSL_IP:3389
END
chmod 775 ~/rdp.sh
Now we can just run the script rdp.sh
once a wsl console is opened. To start the xrdp, we will need to enter our sudo password. To skip this, we can add a line to the sudoers
.
echo "$(whoami) ALL=(root) NOPASSWD: /etc/init.d/xrdp start" | sudo tee -a /etc/sudoers
Just run ./rdp.sh
once you have a wsl console opened. It should remote desktop into Xorg, where we can login with our wsl credentials. Upon login, it should open the KDE desktop. The first thing I would suggest you to do, is to go to display settings (can Alt + Space
, then Display
), scale settings, and set it to 2. Afterwards, if we restart wsl in CMD wsl.exe --terminate
and logs back in, things will look similar size to windows. The second thing to do is to disable screen locking as for some reason, it will trash your CPU (can Alt + Space
, then Screen Locking
).
Testing an IDE
Now we can install our IDE of choice. Personally, I use intelliJ ultimate for java and nodejs stuffs, so we will use that here.
# install arm64 jdk for intelliJ and wget for fetching the package
sudo apt-get install openjdk-11-jdk wget
# move to the directory you want and download intelliJ ultimate
cd ~ && wget https://download.jetbrains.com/idea/ideaIU-2021.1.2.tar.gz
# unpack to the folder and delete zipfile
tar -xvf ideaIU-2021.1.2.tar.gz && rm ideaIU-2021.1.2.tar.gz
# delete the jbr folder so that it does not use non arm java to run intelliJ
cd idea* && rm -rf jbr
# run intelliJ
bin/idea.sh
Closing
Well, so many hoops, but at least performance is now more bearable than trying to run intelliJ under the emulation in windows or making it accessing cross environment files. Well, in the end the surface pro x is not a development machine when they made it. Currently, everything is suboptimal. Do consider switching instead of wasting a lot of your time, as I did.
Surface pro x is such as a nice machine, but just not for development as of now due to many development things not working well in ARM. However, if ARM really kicks off in the windows world as well, having all these WSL issues does not help, especially when many tool vendors still does not work, e.g. localstack. I guess it might just mean Microsoft rising trend amidst developer will go back down massively if there is no catch up here.