In setting up SSH into an Linux install in WSL2, I’ve found guides on how to do this setup. While most contain the similar steps for setting up SSH, they have very different mechanisms for making it start on boot, of which almost none work.

Setting up SSH

First I’ll assume you are running WSL2 and have installed a debian based linux within it.

1. Launch the WSL instance and inside it execute:

   sudo apt install openssh-server
   

2. Run ip addr show to get the IP address of this VM to be used later
3. Launch your favorite shell on the windows side and run:

   netsh advfirewall firewall add rule name=”Open Port 2222 for WSL2” dir=in action=allow protocol=TCP localport=2222
   netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=2222 connectaddress=172.23.129.80 connectport=22
   

   and substitute the IP address you obtained earlier for the connectaddress in the second line.
4. Execute netsh interface portproxy show v4tov4 to confirm it is set correctly (and you can run netsh int portproxy reset all to remove the entries if you need).

(A step or two may be missing above but this is the gist and I’m not trying to make a comprehensive guide for this part)

If you’ve ever installed Xcode via the Mac App Store, you know it can take an hour to install. The reason is not due to its size but the large number of individual files. What if it didn’t have so many small files? Could optimizations made here apply to other apps as well?

Overview

The idea is simple: instead of storing apps as a constellation of individual files, instead store a disk image with its own filesystem. The idea isn’t new and has been used elsewhere and so much of what I’m going to outline here is what one familiar with the idea might expect. So instead of an app being a directory, its current representation, the contents of that directory exist in a read-only filesytem stored in a disk image. Then the app is really a single file, the image itself. Accessing contents within the app is simply traversing the filesystem within the image.

It’s no secret that Apple’s Time Machine backup solution is clunky at best. For those who are unaware, it backs up a Mac to an HFS+ filesystem using directory hard links. The biggest problem with this is that HFS+ was an old filesystem when Time Machine was first designed and it’s gotten even older since. These days Apple uses APFS as their filesystem on computers and iOS devices but the Time Machine backup still uses the fragile HFS+ filesystem for its backups. If you select a backup target that’s not HFS+, such as a network share, it creates a sparse disk image there and creates an HFS+ filesystem in that image. I question whether there was a better way. There is but I wouldn’t expect Apple to bother actually implementing it because, well, they don’t actually seem to care about quality anymore.