Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

macOS Container Machines

github.com

Post reply on HN
Print view View original

321–330 of 457 posts

Re: macOS Container Machines

#321

Post by barrkel »

mjg59 wrote: post #251
LoganDark wrote: post #89

Earlier quoted context omitted.

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 reasonab…

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.

Re: macOS Container Machines

#322

Post by masklinn »

tannhaeuser wrote: post #224

Just to clarify, this requires Mac OS 26 Tahoe for "container" doesn't it? So those of us holding out on Sequoia who can't stand the broken glass UI or what's called and the other undesired features need to stick to Docker desktop.

> Just to clarify, this requires Mac OS 26 Tahoe for "container" doesn't it?

Yes’n’t: https://github.com/apple/container/blob/main/docs/technical-...

> container relies on the new features and enhancements present in macOS 26. You can run container on macOS 15, but you will need to be aware of some user experience and functional limitations. There is no plan to address issues found with macOS 15 that cannot be reproduced on macOS 26.

The issues are around networking.

Re: macOS Container Machines

#323

Post by pjmlp »

cromka wrote: post #181

So essentially both macOS and Windows now heavily support developing using Linux on them. They can't more openly admit that they are no match for Linux in that area. There's some clever advertising in it for Linux, if Linux was advertising.

Not really, this means the complete defeat of The Year of Linux Desktop.

Linux games depend on Windows ecosystem as their content source.

By having Linux nicely packaged in containers, they get to keep the 90% combined market share, almost no one bothers to support the market of Linux OEMs selling pre-installed Linux desktops and laptops.

The other "distros" used by consumers are Android, WebOs and going forward Googlebooks as Chromebooks evolution.

Meaning in the end a Pyrrhic victory, when Apple Linux, Microsoft Linux, Google Linux, Asus Linux, LG Linux, is all that the general public cares about, and hence no incentive for IT departments to support Linux laptops.

Re: macOS Container Machines

#324

Post by cedws »

qalmakka wrote: post #189

This is all fine and dandy, but where are the native Darwin Jails Apple? Still scared that people will filling whole rooms of Mac Minis if you allow them to have multiple macOS containers and not only up to two fat VMs per machine?

Darwin namespaces would be much more interesting and we are in dire need of them in the current security landscape.

I don’t really understand the hype for Apple’s Containerization, it’s just another container runtime alongside many others. It’s not really any better than OrbStack - in fact it’s worse.

Re: macOS Container Machines

#325

Post by embedding-shape »

pjmlp wrote: post #155
gsnedders wrote: post #65

Earlier quoted context omitted.

Only WSL2; WSL1 was an actual subsystem.

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.

Re: macOS Container Machines

#327

Post by miohtama »

jdub wrote: post #256
bogantech wrote: post #219

Earlier quoted context omitted.

> filesystem mounting How is this different to bind mounts

Very different: Linux running in a virtual machine can't bind mount into a macOS host's filesystem. So they use virtiofs.

MacOS container filesystem/IO has been bog slow preventing even some basic dev container use cases. Hopefully this will fix the issue.

Re: macOS Container Machines

#328

Post by alerighi »

mjg59 wrote: post #251
LoganDark wrote: post #89

Earlier quoted context omitted.

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 reasonab…

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.

Re: macOS Container Machines

#330

Post by alerighi »

CGamesPlay wrote: post #47
Onavo wrote: post #29

Earlier quoted context omitted.

Ah, the Darwin/BSD Subsystem for Linux.

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.

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...
Post reply on HN