Hacker News Reader

Comment by unshavedyak | Hacker News Reader

What sort of code toolchains do you use? I've used a bit of windows before via WSL and Cygwin and it left a lot to be desired. It felt pretty similar to the problems i encountered on OSX when needing to run Linux specific tooling on docker containers. Ie not great.

Curious on what you use, and how your experience might overlap with mine these days?

View on HN

I can strongly recommend trying out NixOS in WSL; I love this setup so much with komorebi. I have a starter template[1] available if you'd like to try it out. It takes less than 10 minutes in most cases to set up a fully functional NixOS WSL VM.

[1]: https://github.com/LGUG2Z/nixos-wsl-starter

Hah, i use NixOS, Nix Darwin, and Home Manager. Generally love it (as much as i dislike Nix lang lol)

Any reason you specifically like NixOS on WSL?

My issues with WSL was more that it felt like an artificial barrier. The filesystem differences would cause slow churn if expensive operations crossed the barrier, so it just in general was things i had to think about. Wasn't a fan of that.

> Any reason you specifically like NixOS on WSL?

Pretty much the same reason I like NixOS on my Linux laptop and Nix-Darwin on my Macbook - single flake that I can use on all my machines so that they all behave in a predictable way.

I do most of my Rust development (with the exception of komorebi and whkd) on NixOS in WSL, using JetBrains IDEs running on Windows accessing projects in WSL and I haven't noticed anything causing churn, however I think this is probably language-dependent.

Generally I think it's a reasonable heuristic that any language which is a pain to develop with when source directories are mounted in Docker containers (JS/TS and the huge node_modules folders immediately jump out) will also have similar problems in WSL (though probably not _as_ bad).

Not the GP but I use a headless Linux server VM through Virtualbox. I mount the Linux filesystem as a drive in Windows to use whatever editors on the Windows side and run any server processes (or command line utilities) on the Linux side. I've used this setup for over a decade without any complaints and the maintenance is low.

Can you please elaborate? I used to ssh into a Linux VN with VSCode but your setup is more sophisticated.

Here's how I do it. Create an Ubuntu server VM in VirtualBox, I use the bridged adapter for networking, VM will be its own host/IP on the network.

Then install samba.

  sudo apt install samba

Also install openssh if not already chosen during setup.

Edit /etc/samba/smb.conf to uncomment/set these settings.

  [homes]
     browseable = no
     read only = no
     valid users = %S

Create a user for SMB, use the same username/password as your local Windows user for convenience.

  sudo smbpasswd -a username

Restart smbd, this command can vary depending on the VM OS/version.

  sudo service smbd restart

Mount the home directory (run this from the Windows command line.) You won't have to provide a password when authenticating, if you set the user/pw as I suggested above.

  net use z: \\vm-hostname\vm-username

I run git commands on the Linux side where all code projects live.

You can go in the opposite direction (mount the Windows filesystem from within Linux) but I don't suggest that for the primary use case of code projects, it can introduce problems with permissions. But for one-off use cases I do sometimes mount the Windows filesystem in Linux. That requires following the VirtualBox instructions for installing "Guest Additions" and using the Shared Folders feature.

Run servers on the VM, access web sites/services on the VM hostname through the browser on the Windows side.

Not specific to this setup, but if you want to run a service on port 80 of the VM, run this command on whatever the actualy binary is for the server process. (Not a symlink.)

  sudo setcap 'cap_net_bind_service=+ep' /usr/local/python-3.12/bin/python3.12

Thanks a lot. This is more than I can understand right now. I'll digest and see if I can apply the principle.

Isn't this quite similar to WSL? Is there a reason you prefer this to WSL?

I've been using this setup since before WSL existed. WSL had enough rough edges when it was newer to keep me from switching, but I'm sure it's improved since then.

This setup is simpler in the sense of not requiring a newish and ever-evolving layer from Microsoft. It's lame that Oracle owns VirtualBox now, but there's never been any pain with it so far.

Reply on news.ycombinator.com