-- Leo's gemini proxy

-- Connecting to samsai.eu:1965...

-- Connected

-- Sending request

-- Meta line: 20 text/gemini

Making the best of a Windows laptop


Been two weeks on the job now and by now I have kind of managed to get the hang of the basics. But one thing that has taken me a while and a fair bit of effort has been setting up a development environment myself.

The company gave us laptops to do our work on. Pretty decent ones too, mine is a relatively new Thinkpad with 40GB of RAM and an okay i5 processor. But it also came with a massive anchor that has been slowing me down significantly, namely Windows 10. We were basically told that we'd be stuck with Windows for the first six months, after which we could at least try to set up a Linux environment for it. Apparently the corporate network and IT services are a bit tricky to navigate and set up, which is the reason why Linux isn't allowed for new trainees.

But this posed a problem, because I have to actually develop some software with the damn thing. We were promised some VMs to use as our main development and test deployment systems, but we only got access to those at the end of last week. So, I went a couple days trying to set up a local dev environment for the laptop.

All I can really say is that software development on Windows is a nightmare. My first goal was to set up Doom-Emacs so that I at least had a decent editor to work with. But Doom-Emacs itself requires a few packages and Windows is woefully inadequate by default when it comes to fetching and installing software. Coming from a more civilized land, I wanted to address this problem by installing a package manager and I managed to find two options. Chocolatey was my first choice, but it refused to install correctly and the Powershell lines it threw at me didn't fix anything. Scoop I eventually managed to get working correctly, so that's what I ended up using.

With Scoop it was easy enough to pull in Git, Emacs, ripgrep and fd. These allowed me to get Doom-Emacs working. I could also pull in nodejs (I know, not all of us get to choose our tools) so I could create a bare minimum of a development environment.

This turned out to not be a viable choice, however. Doom-Emacs worked, but it was slow to the point of being nearly unusable. And I could say the same about the other tools as well. It would take over a minute for NPM to initialize a simple React project template and Git wasn't particularly fast about fetching repositories either. I'm assuming this is because of Windows file indexing and anti-virus software. Indexing I could disable, but there's nothing to be done about the AV suite.

When I got access to my VM, I gave up on running Emacs locally. Instead I moved over to coding straight on the VM (don't worry, the VM is not production) on a Doom-Emacs installed on the VM itself. I started out just using Emacs in TTY mode via SSH, but that wasn't really the best system. It works okay, but lacks clipboard support, which would be handy for sharing quick code snippets and looking up things on Stackoverflow. I tried VNC but it's a bit clumsy to manage your regular apps and the apps running in the VNC window.

So, the solution I've settled on for now is the following: I launch an X server on my Windows machine and SSH into the VM using Putty. Putty supports X11 forwarding, so I can basically just log in and call a GUI application from the terminal and it will show up as if it was a native window. For some applications like Firefox this is quite slow, but Emacs works surprisingly well. The X11 forwarding also provides me with good two-way clipboard handling and I can multiplex the terminal inside Emacs using vterm and workspaces to run multiple tools at the same time.

It's not really perfect still. Sometimes the SSH connection will timeout and that close the window, but this seems to only happen when the laptop goes to sleep when I'm carrying it around or not looking at it for a while, so this isn't really a concern for me. Performance-wise, Emacs via X11 forwarding absolutely flies in comparison to the native Emacs. Once again, this is presumbaly because the VM isn't constantly burning up cycles to make sure my Emacs files don't contain viruses.

I'm currently the only one at the office using this sort of an environment, almost everybody else is just using native VS Code with SSH plugins. I'm sure that's maybe a more practical system and doesn't involve as much jank, but I really want my Doom-Emacs, so this seems like the best compromise I can make. If I had the time, I could maybe set up all of my email and Teams and stuff on the VM itself and only use the Windows laptop as a thin client that fires up VNC Viewer, but that itself would require some work. So, until I am released from the purgatory that is my Windows work laptop, I think I'll keep relying on old-world technology to run remote applications. In the future I might investigate if I can accomplish the same with a more modern display stack with something like Waypipe.

-- Response ended

-- Page fetched on Sun Aug 1 00:34:21 2021