Hacker News new | ask | show | jobs
by CGamesPlay 12 days ago
Not quite, it’s still a VM. And while it supports virtio balloon for growing RAM, it doesn’t yet support releasing that RAM back to the host. And there isn’t a convenient way to shrink the sparse disk images as they grow yet, either.
7 comments

Isn't the Windows subsystem for Linux (the reference there) also a VM?
Only WSL2; WSL1 was an actual subsystem.
So this is Darwin/BSD Subsystem for Linux 2.
Yes.
WSL1 was so cool, WSL2 made it boring and isolated.
WSL1 was very conceptually appealing, and ended up working very poorly because of the poor matching between Linux syscalls and the Windows kernel. Git suffered terribly as a result. The inverse is also somewhat true - there have been cases where Wine is much slower than native Windows because Linux simply doesn't provide a simple way to achieve the same outcome, and interestingly the Wine developers have had reasonable (if tediously slow) success in making it possible to express the same semantics to Linux and have it handle things fast. It would be fascinating to know whether WSL1 developers didn't have enough traction to get Windows internals altered to match, or whether it's just way harder to do the same under Windows.
It did work quite well. The problem with the filesystem could have been solved by optimizing the Windows kernel, that would have benefit also programs run outside the WSL by the way (NTFS have performance problems and Microsoft knows, and even provided a kind of solution as far as I know with the developer FS or what they call it).

The thing that I don't like of the WSL2 is that is just a VM, but a VM that is very limited. For example working in the embedded development field I often need to use serial ports or USB devices, a thing that the WSL2 is not capable of doing (unless passing trough USB/IP that has its compatibility issues especially for stuff like debuggers needing precise timing), and that the WSL1 was at least for the serial ports able to do. This is a limitation that doesn't allow me to use the WSL. Same thing with all kind of other software that wants to access peripherals of the machine natively (e.g. a GPU for example, or another PCI card, something that to be fair is not even doable as far as I know with hypervisors on Windows but completely doable with hypervisors running on a Linux OS where trough the IO MMU you can share any PCI device of the host to the VM).

WSL1 was a great idea, bad thing that Microsoft abandoned it for something that is just good for web application development.

> (NTFS have performance problems and Microsoft knows, and even provided a kind of solution as far as I know with the developer FS or what they call it)

NTFS does not have performance problems. The difference between DevDrive, which uses ReFS (arguably a more 'resilient' file system than NTFS due to journaling) and a standard NTFS volume is the file system filters are either removed or in the case of Defender, put in async mode.

The file system filter architecture is the performance problem, not the file systems. It's a trade off to have a more extensible I/O stack.

> The problem with the filesystem could have been solved by optimizing the Windows kernel

Over time this would tie the Windows kernel’s requirements so that they matched the Linux kernel’s due to expectations from WSL1 users. This of course is a bad idea for any engineering organization - you will have requirements imposed on you that don’t mesh well with your other non-WSL users and you also have no real sway over Linux governance. This would lead to the Windows kernel either becoming a clone of Linux or serving at least one set of users poorly.

Why would you work on embedded development through a VM? Out of curiosity.
Wine achieves better performance these days due to things like... adding a module to the Linux kernel that implements NT-like synchronization primitives. So, Linux subsystem for NT synchronization basically. (a.k.a. NTSync)

Maybe this works out better because Linux is more flexible, while Windows/NT is more "set in its ways" and therefore more difficult to implement Linux on top of... Maybe?

It's my understanding that a big part of WSL1 performance loss comes from the relatively thick layered filesystem architecture on Windows.

Since git and nodejs are both common in modern development and are expected to work efficiently with huge numbers of files, this was a real bottleneck and it couldn't easily be tackled without threatening backward compatibility.

Back in my day you to to download a couple GB worth of cygwin, and that wasn't an actual environment, basically just a GNU toolchain compiled for windows. But it got you like....grep and bash and stuff that ran natively on windows which was kinda cool.
Does any older folk here remembers when NT was the Cool New Thing (TM) and it had by design support to multiple subsystems plopped over the NT API, and Win32 was just one of them alongside POSIX (Interix) and OS/2? There was even a _very short_ time span when Interix was actually usable (it was extremely short though)
I guess that makes me square within the 'older folk' subset - I continued to use the NT core with LiteSTEP alongside the SGI/IRIX Octane2 well after Y2K.

Those days I was working on a rework of the TRO PLATO learning system which was a real beast but essential for the individual learning project of a charter school i was supporting.

PLATO had been taken from it's dedicated mainframe world and made 'runnable' on W95 workstations with an NT server - but it really didn't run well, and the kids could really get behind the interface into regular Windows environment too readily. In combination the workstations were crazy hard to keep running cleanly.

So in the end; we had to take the software out of Windows, wash it clean in the waters of Silicon Graphics System-V with BSD extensions (X11) Unix and BSD - NeXTSTEP, just so we could bring it back to Windows properly using LiteStep.

Life happened and I lost touch with the outcome of it all, moving on to my next project; but, I kept a LiteSTEP desktop until moving entirely over to Linux in 2004.

Haven't used Windows for anything but a gaming load since '05 and stopped doing even that in about 2010, nothing later than XP.

Yes, the only reason I cared for Linux in first place was that the POSIX support wasn't that good.

I am convinced that if POSIX subsystem was UNIX serious, GNU/Linux would never taken off on PC, and the whole would be divided between SGI, HP-UX, Solaris, Aix and Windows NT.

Cygwin was fun. I'd done zero development on Windows, but about 10 years ago I had to figure out how to deploy some nightly shell scripts across a bunch of local computers in a few dozen offices, where about 80% were MacOS and the rest were Windows. I don't remember exactly how I rigged it, but basically cygwin allowed me to keep the scripts as they were and trigger them in place, with a few small modifications.

I never want to deal with that again ;)

[edit] fwiw, Termux on Android is similarly a fun pseudo-environment. It's a nice and helpful toy.

The biggest issue I remember is directory seperators... windows of course using \ which bash would then interpret as an escape. Cygwin mostly papered over that from what I can recall, but it could lead to some weirdness, like sometimes you'd get C:\\path\\es\\like\\this
> Back in my day you to to download a couple GB worth of cygwin

You still can, and it still works exactly the same way.

It's true, but to be honest the MinGW-built stuff that ships with git for Windows has been enough since WSL took off.
what do you mean? that's still the only way to work as a human in windows. wsl1 almost replaced it, but obviously they scrapped it.

if you must use windows, it's because you will compile for windows. so you install MSYS, which is a linux distro-ish compiled native for windows. and do your work.

wsl2 (and this apple thing) is just a meme. if you're working in it, you're better of just installing Linux or ssh'ing to a server.

> wsl2 (and this apple thing) is just a meme. if you're working in it, you're better of just installing Linux or ssh'ing to a server.

Many enterprises allow windows only so your way into Linux is via WSL2

shrug. I haven't owned a Windows machine in years at this point. It's one of those things like PHP that I just decided my life was better off without.
... Now it's just called git bash
Just install and use MSYS2, git bash is derived from it anyway, and a regular MSYS2 installation offers a lot more.
It was soooo slow though. Practically unusable for anything i/o heavy.
Those issues could have been fixed…
WSL 1 is long gone for all practical purposes, yet it still dominates conversations.

Also everyone on FOSS gets it wrong, WSL wasn't a subsystem like classical Windows NT ones.

It was based on Drawbridge research using picoprocesses, a new approach for library OSes.

https://learn.microsoft.com/en-us/archive/blogs/wsl/pico-pro...

> Also everyone on FOSS gets it wrong, WSL wasn't a subsystem like classical Windows NT ones.

Everyone in FOSS? How about Microsoft got it wrong, since they actually named it The Windows Subsystem for Linux (WSL)? It wasn't the FOSS community who chose the name for them.

What has that to do with a version number and not keeping up with the times?
What version number? WSL1 vs WSL2?

I'm not sure if you see the quoted part. My comment is about the part that starts with "> " that you wrote earlier.

And a limited VM, for example I look at the documentation and it's not possible to share USB devices with the VM, making it perfectly useless for doing embedded development where you have to connect to the boards with USB. I will continue to use UTM for that reason...
Virtualization.framework just gained USB passthrough support in macOS 27. It might be a niche feature for containers to add, but other VM software will likely add support soon.
Mac Subsystem for Linux 2
macOS is basically already a POSIX subsystem for macOS, which is already a UNIX™.

But (some) people still criticize it because it's not Linux or FreeBSD (though it is closer to the latter than the former).

This is not a problem at all as most Apple computers come with plenty of RAM and lots of disk space! We are so lucky that Apple engineers always think so differently into the future!
WSL is a VM too, but that's still what this is. WSL for MacOS. It's great!
So, heavier than running docker in qemu?