Once upon a time these were usually posts on one own blog (self-hosted or not), started with a HOWTO keyword and helped the people just in the same way. Nowadays everything developer must be on GitHub or it won't ever be noticed.
I personally like these detailed step by step readmes. It’s helpful for someone clueless dropping in to get quickly started and develop a working prototype. Too many times you’re left to your own devices when setting up dependencies. I totally understand if you’re expected to do some homework. On another hand, it certainly helps to gently guide the reader versus give them a high level request to install this or that.
The problem with each of these tools (Lima etc.) is that it’s still fundamentally a virtual machine under the covers.
The great thing for me about WSL (and why IMHO it was worth all the effort they put into it), is that because the kernel process tree is running as a native Windows process tree, I don’t have to pre-allocate memory ahead of time.
This is murder on Apple’s RAM-restricted laptops, and kind of rubbish on machines with massive RAM too. Most of the time, most of your memory goes unused. The base model Airs/Pros for example need to have 25-50% of your RAM locked away just to run a Linux container at all - when you already have a fairly anaemic 8GB to begin with that’s pretty dire.
It's a shame they essentially deprecated WSL1 and is doing everything in WSL2 now, where exactly this kind of memory allocation and the performance issues that entails is an issue.
Not that I think it's a bad decision, but I wish they somehow managed to break Conway's Law and enhance Windows itself by fixing the file system speed issues as well as somehow making NT/Windows processes fork instantaneously just like on Linux :)
We work very closely across the file system, kernel, and virtualization teams, so I don’t think we can blame Conway’s Law for WSL2. And actually our WSL1 fork performance wasn’t too bad IIRC—we have real fork at the Windows kernel level, it’s just not something that can realistically work with the Win32 programming model. I also think we will eventually resolve the file system performance issues.
No, the most important reason to choose a VM instead of a reimplementation of the Linux ABI is long tail compatibility. You can’t realistically replicate and then keep up with every corner of the Linux kernel’s interface. And so with WSL1, software will randomly not work, or it will randomly break after an apt upgrade, and users will get frustrated and switch to a VM anyway. Might as well get perfect compatibility and still have nice integration with Windows via the WSL2 approach.
Their explanation was that Windows could not be enhanced but rather should be slimmed down - the APIs that the NT kernel provides can't be efficiently worked around without breaking all kinds of already existing Windows software.
The other commenter alluded to this but didn’t say it outright: WSL2 is essentially just a special VM with API based limited hardware access. It’s neat though, the file systems are connected over 9p.
It is - but its speciality is exactly what matters most - it doesn't preallocate RAM and in fact can dynamically release it back to the host without any user intervention. It's super convenient.
The great thing for me about WSL (and why IMHO it was worth all the effort they put into it), is that because the kernel process tree is running as a native Windows process tree, I don’t have to pre-allocate memory ahead of time.
You are right and it can definitely be improved, however at all my jobs I’ve had 32-64gb MacBooks, is that not true for most developers? When I didn’t i was able to buy an actual Linux laptop
> A: It's a proof of concept name only. If I were to distribute this as a finished piece of software, which I probably won't (see why below) I would choose a different name.
> Q: Isn't this literally just a QEMU virtual machine? How simple is that!
> A: Yes, it is. And yes, it's simple. Why did I choose to put this on my Twitter, you ask? Because I couldn't find something exactly like what I did, and because before I posted it, I had 50 Twitter followers, total. I did not expect to get the over 700 likes that it did when I posted it; as a matter of fact, I would have been perfectly satisfied if it had gotten 7 likes.
> Q: What, you won't be distributing this as a finished piece of software!? Why?
> A: From what I can tell (and admittedly, I haven't tested this piece of software), it already exists. Lima seems to have a lot more features (such as file sharing, something that I have not implemented) and seems to be geared towards a different application (containers).
For at least the last year I’ve ran my entire dev environment out of a Linux VM I ssh into (locally).
The primary factors are:
1. I, overall, like macOS and the Apple ecosystem. I heavily use Notes, my calendar, several apps I like to sync from my iPad and phone, etc. I'm pretty bought-in, and macOS helps me manage the non-developer stuff a lot easier, in my opinion.
2. Enough things have broken, over time, from macOS updates that my developer experience is subpar compared to a Linux OS.
3. A Linux VM gives me 100% reproducibility, so little delay that I would argue to say there is no delay, and I can reliably use the rest of my MacBook for all the other apps I care about.
It’s worked great, and I’ve never felt like it’s complicated.
Edit: Some people might mention Docker. I've run into just-enough networking issues with Docker that the full VM was worth running.
I sometimes code in assembly for fun (my professional work is mobile app developer, though). One of my favorite assemblers is FASM: https://flatassembler.net/
It's still written in 32-bit assembly, which means it won't run on any macOS since Catalina. On the other side, Linux still provide 32-bit compatibility mode.
In an ideal world, we wouldn't need to be bothered with Linux-only software. It's incredibly frustrating not only on Mac, but e.g. on OpenBSD as well.
Docker (and Kubernetes) are a prime example, but it's increasingly bothersome to work around dependencies on systemd, logind, etc. Linux software is starting to feel like Windows software: it's this special other thing that requires extra steps and care to run on your machine, and the user experience is far from smooth, if things work at all.
I know about Darling [1] but don't know about how practical it can be because I'm assuming all proprietary frameworks like the core web framework aren't implemented there.
Multipass is somewhat limited, but what it does it does really well.
It is supported in Linux, Windows and osx. This means that you can have identical development environment across all your devices using a shared VM script
I’ve been using Multipass for a couple years now as my “WSL for Mac”. It’s great to be able to spin up a Linux guest on demand. I also use it for Docker shenanigans so I don’t need Docker Desktop or deal with its licensing issues.
Yes. It's using the same naming as WSL which always confused me:
Q: Why the same naming scheme as WSL?
A: It's a proof of concept name only.
If I were to distribute this as a finished piece of
software, which I probably won't (see why below) I would
choose a different name.
It's not confusing once you know where it came from. The NT kernel has a concept called “environment subsystems”. Win32 was, until WSL1, the only one used (a long time ago there was SFU, the grandfather of WSL). So WSL is a Windows subsystem made for Linux. Hence the name.
Note that WSL2 isn't an NT subsystem, they're just using an actual kernel now. The name stuck though.
Yeah well, I'm not familiar with their naming scheme, I've managed to mostly ignore Windows in the past 10+ years. Except that legacy vb.net project... sigh, the things I'll do for money.
I've wanted to do it. Mostly to test out stuff that my colleagues would need to run but haven't been able because I run Linux. So I usually have to ask colleagues to double check my work.
I am aware that running macOS on non-Apple hardwade would be against their ToS.
Readit News
That README shows a great deal of appreciation for other people’s time, which should be commended.
/Old man yells at clouds
In addition to the fact that folks can submit a PR (or fork) to update the instructions if something goes out of date.
Provided, of course, they don't use the github wiki stuff or use separate repos for documentation.
The great thing for me about WSL (and why IMHO it was worth all the effort they put into it), is that because the kernel process tree is running as a native Windows process tree, I don’t have to pre-allocate memory ahead of time.
This is murder on Apple’s RAM-restricted laptops, and kind of rubbish on machines with massive RAM too. Most of the time, most of your memory goes unused. The base model Airs/Pros for example need to have 25-50% of your RAM locked away just to run a Linux container at all - when you already have a fairly anaemic 8GB to begin with that’s pretty dire.
Not that I think it's a bad decision, but I wish they somehow managed to break Conway's Law and enhance Windows itself by fixing the file system speed issues as well as somehow making NT/Windows processes fork instantaneously just like on Linux :)
No, the most important reason to choose a VM instead of a reimplementation of the Linux ABI is long tail compatibility. You can’t realistically replicate and then keep up with every corner of the Linux kernel’s interface. And so with WSL1, software will randomly not work, or it will randomly break after an apt upgrade, and users will get frustrated and switch to a VM anyway. Might as well get perfect compatibility and still have nice integration with Windows via the WSL2 approach.
CoLinux did that years before WSL1 did. Sadly, the project is dead and AFAIK it never really worked on Windows 64-bit, only on 32-bit: https://en.wikipedia.org/wiki/Cooperative_Linux
Web dev here, ran with 16 up until recently… now at a whopping 24…
No memory pressure.
Assuming that they just don't get a cloud VM accessed via Citrix/RDP.
What do Mac users get out of this? I thought most Linux things work reasonably well already
========================
> Q: Why the same naming scheme as WSL?
> A: It's a proof of concept name only. If I were to distribute this as a finished piece of software, which I probably won't (see why below) I would choose a different name.
> Q: Isn't this literally just a QEMU virtual machine? How simple is that!
> A: Yes, it is. And yes, it's simple. Why did I choose to put this on my Twitter, you ask? Because I couldn't find something exactly like what I did, and because before I posted it, I had 50 Twitter followers, total. I did not expect to get the over 700 likes that it did when I posted it; as a matter of fact, I would have been perfectly satisfied if it had gotten 7 likes.
> Q: What, you won't be distributing this as a finished piece of software!? Why?
> A: From what I can tell (and admittedly, I haven't tested this piece of software), it already exists. Lima seems to have a lot more features (such as file sharing, something that I have not implemented) and seems to be geared towards a different application (containers).
The primary factors are:
1. I, overall, like macOS and the Apple ecosystem. I heavily use Notes, my calendar, several apps I like to sync from my iPad and phone, etc. I'm pretty bought-in, and macOS helps me manage the non-developer stuff a lot easier, in my opinion.
2. Enough things have broken, over time, from macOS updates that my developer experience is subpar compared to a Linux OS.
3. A Linux VM gives me 100% reproducibility, so little delay that I would argue to say there is no delay, and I can reliably use the rest of my MacBook for all the other apps I care about.
It’s worked great, and I’ve never felt like it’s complicated.
Edit: Some people might mention Docker. I've run into just-enough networking issues with Docker that the full VM was worth running.
I sometimes code in assembly for fun (my professional work is mobile app developer, though). One of my favorite assemblers is FASM: https://flatassembler.net/
It's still written in 32-bit assembly, which means it won't run on any macOS since Catalina. On the other side, Linux still provide 32-bit compatibility mode.
Docker (and Kubernetes) are a prime example, but it's increasingly bothersome to work around dependencies on systemd, logind, etc. Linux software is starting to feel like Windows software: it's this special other thing that requires extra steps and care to run on your machine, and the user experience is far from smooth, if things work at all.
Also: https://news.ycombinator.com/item?id=31842318
I know about Darling [1] but don't know about how practical it can be because I'm assuming all proprietary frameworks like the core web framework aren't implemented there.
[1] https://github.com/darlinghq/darling
1) https://github.com/lima-vm/lima 2) https://github.com/beringresearch/macpine
With a nice CLI included.
Deleted Comment
https://multipass.run/
It is supported in Linux, Windows and osx. This means that you can have identical development environment across all your devices using a shared VM script
Multipass is a solid tool.
https://itdeepdive.com/2020/10/kubernetes-multi-node-cluster...
Either way is absurd, tbh, but here we are.
I thought it's something for running (some parts of) MacOS on Linux. Not the other way round.
Note that WSL2 isn't an NT subsystem, they're just using an actual kernel now. The name stuck though.
I am aware that running macOS on non-Apple hardwade would be against their ToS.
[1] https://www.darlinghq.org/