Related: does anyone do development on a Mac in a Linux VM? If my dockers are already running in a VM, why not go to the next logical step?
replies(8):
They made an update that claims performance is comparable.
I tested realistic workloads last week and docker desktop was still meaningfully worse.
If your work computer has antivirus, the performance of docker desktop will be even worse if exceptions aren't or can't be added.
I need to try it again, bet it works out of box now.
I typically work on my work issued linux workstation (pretty old now and less powerful than my Macbook Pro), but often need to do development from my laptop too. I run a Fedora arm VM in UTM full screen. It generally works well, although I'd much prefer to have native linux on my laptop. It would be nice of mac os didn't interrupt full screen mode randomly and allowed UTM to capture all keys and touchpad gestures.
I personally am incredibly unproductive on a mac, and have no idea how anyone does anything with how terrible the window management and virtual desktops are. Plus, I find all my linux based tools that I am accustomed to just work so much better under linux. So for me, even a VM is still a huge leap in productivity.
Also, the bind mount of the external MacOS directory is extremely slow. I do out of tree builds so that the builds land in ext4.
I haven't gone the next logical step because (1) it is plenty fast for rust development, and battery life is fine, and (2) I'd like webcam and speaker support.
Also, I just checked, and I have a 2023 model, and the installer status is "WIP", so I guess I'll be waiting a bit longer.
It's really nice being able to four-finger swipe between Macos and Linux full-screen desktops when I want that.
But usually I SSH into the Linux VM so that I can use iTerm2 as my terminal, and use Mac native GUI Emacs (railwaycat & Mitsuharu Yamamoto's version) to have its graphical features working alongside my iTerm2 and Firefox.
Linux in a VM runs some things much faster than the host MacOS on the same laptop! In particular filesystem intensive builds. I found some Docker-based test system I had to use for work ran an order of magniitude faster in the Linux VM than with Docker on the Mac host.
I did test running Linux natively on this MBP (no MacOS host) but found to my surprise the battery drained faster than using it in a VM, and the VM is almost as fast. So I stick with the VM and I get to use both OSes side by side.
I don't use the VMware file sharing as it is extremely buggy and regularly corrupts files when operating on them with Git or some other activities due to buggy cache settings which cannot be set to non-buggy values.
Instead I use some crazy combination of Samba and NFS which works reasonably to get the right permissions and ownership as seen by each side of the other's files. The upshot is two-way file sharing works, but this was actually difficult to make reliable.
(I found the Mac SMB2 client is prone to occasionally deleting files that aren't even being accessed by it at all, but are in a directory where other files are being updated. A shocking bad SMB2 protocol bug in the Mac client where it sends the wrong filename for renames occasionally, using a name from a recent directory listing. It took me a year to diagnose that and I thought it must be a bug in my code in a critical Linux database application I was writing, which I didn't dare deploy upstream for all that time, because important random files like invoices and data files would occasionally disappear and be noticed days later causing me to doubt myself. That is until I did a very deep dive with every debugging tool you can imagine, to find the true cause was MacOS when I edited unrelated files, and my application had been fine all that time to deploy to prod. Solution was force MacOS to use CIFS instead of SMB2.)
I hope to replicate something like that when I get an ARM Mac at some point, though I hope the MacOS SMB bugs are fixed. Currently holding out for an M3.