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

271–280 of 457 posts

Re: macOS Container Machines

#271

Post by coldtea »

TylerE wrote: post #121
noduerme wrote: post #118

Earlier quoted context omitted.

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

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

Always used / and it worked for both cygwin/windows lands.

Re: macOS Container Machines

#272

Post by coldtea »

stefan_ wrote: post #268
kenanfyi wrote: post #255

I don‘t understand why these tools always advertise about mounting the $HOME inside the container. Isn‘t it better to have a complete isolation? Isn‘t that the point of using such a thing?

No, the whole point of machines is their external interfaces? A Linux VM with no interfaces is just a closed box wasting power doing math. And I think I would caution Apple to consider the lessons of WSL; having shared access to the filesystem is just the bare minimum. Next is networking (and god is this a rabbit hole with WSL), people will want to access their USB devices, X forwarding, GPU passthrough..

The whole point of container machines is their isolation.

If we wanted access to all interfaces, we'd just run it locally.

We want the container as a closed box, "wasting power doing math", i.e. processing what we actually passed to it.

Re: macOS Container Machines

#273

Post by coldtea »

qalmakka wrote: post #245
adastra22 wrote: post #242

Earlier quoted context omitted.

sandbox profiles?

macOS sandboxing is deliberately limited just enough to prevent anyone from truly implement Darwin-on-Darwin containers. People have been discussing about this for a while, see https://github.com/apple/container/discussions/611 In general I understand the rationale behind Apple's decision. They sell hardware, and there's real demand for macOS on servers to run build jobs and other Mac-only tools. Giving you the abili…

I doubt this insignificant statistically speaking market (compared to the overall units they move) is what prevents them.

Re: macOS Container Machines

#274

Post by rubnogueira »

kdrag0n wrote: post #26
blahgeek wrote: post #10

OrbStack works really well for me. I wonder how it’s compared to this performance wise

(OrbStack dev here.) Instead of Virtualization.framework, we have a custom Rust virtualization stack with custom devices and protocols for things like filesystem sharing. It's a highly optimized vertically integrated stack specifically for running our Linux machines and containers. Our biggest perf/resource gain is dynamic memory, which reduces memory usage a lot by releasing unused memory back to macOS. Nothing else…

Just to give a thumbs up to you and OrbStack. I've been using it every day since the first releases, and it is one of the most stable and performant drop-in replacements that I've seen.

Re: macOS Container Machines

#275

Post by lxgr »

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.

This applies to both containers and container machines though, right?

Re: macOS Container Machines

#276

Post by coldtea »

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.

>those of us holding out on Sequoia who can't stand the broken glass UI or what's called

Maybe hold 1 release back, but other than that, I don't think "holding out" on macOS releases has ever been a winning strategy.

In the end, macOS model presupposes users moving to the latest release sooner rather than later.

Re: macOS Container Machines

#277

Post by keybits »

blackqueeriroh wrote: post #127
kdrag0n wrote: post #26

Earlier quoted context omitted.

(OrbStack dev here.) Instead of Virtualization.framework, we have a custom Rust virtualization stack with custom devices and protocols for things like filesystem sharing. It's a highly optimized vertically integrated stack specifically for running our Linux machines and containers. Our biggest perf/resource gain is dynamic memory, which reduces memory usage a lot by releasing unused memory back to macOS. Nothing else…

When are y’all gonna support sandboxing? Preferably Docker Sandboxes?

Isolated machines was release recently: https://docs.orbstack.dev/machines/isolated - various recent improvements in the release notes: https://docs.orbstack.dev/release-notes

Nothing specific for Docker yet, but I find the Linux machines are lightweight enough that I just run Docker inside them.

Re: macOS Container Machines

#278

Post by coldtea »

KeplerBoy wrote: post #248
LaFolle wrote: post #227

Python binary wheels now have to be built for aarch64 for them to work inside the container, unless they are built using the corresponding build system while installing. It is not common for python binary libs to publish arm64 binary wheels, as most often they target amd64.

Isn't that just expected for modern macOS devices? They have been on arm64 for 6 years now.

This however is for Linux containers on macOS, and for those the deployment target are not usually/necessarily arm.

(Plus, you could always even have amd64 linux containers on macOS AS, with good performance, via Rosetta2).

Re: macOS Container Machines

#279

Post by lxgr »

sigmoid10 wrote: post #262
kenanfyi wrote: post #255

I don‘t understand why these tools always advertise about mounting the $HOME inside the container. Isn‘t it better to have a complete isolation? Isn‘t that the point of using such a thing?

Containers only got so popular as a tool for developers to make developing/deploying easier. If you want to use them as a security layer that is a completely different goal and has many highly dangerous pitfalls [1]. Just last week there was a post where people were shocked how an AI agent used docker to bypass sudo on a system. I'd imagine this could happen to most people who installed docker. So if you want to use…

> Just last week there was a post where people were shocked how an AI agent used docker to bypass sudo on a system.

This was due to implicitly granting the LLM access to the host docker daemon, which has superuser privileges, not due to a "container breakout". That's arguably a very different scenario, but of course both are worth considering.

> So if you want to use containers for anything but easier development, you need to be much more proficient than the average user already.

I'd disagree. Containers, at least without granting them additional privileges such as CAP_NET_ADMIN and without write-bind-mounting sensitive host directories into the container, offer a reasonable security boundary compared to the counterfactual, despite their bad reputation.

Re: macOS Container Machines

#280

Post by saljam »

kenanfyi wrote: post #255

I don‘t understand why these tools always advertise about mounting the $HOME inside the container. Isn‘t it better to have a complete isolation? Isn‘t that the point of using such a thing?

the reason i use this (and just a container with -v $HOME:$HOME before) is to get an environment with all the command line tools i'm familiar with from debian, instead of using something like homebrew. in general, i mostly trust these with access to my home directory. a bonus is that i can throw it away and rebuild it easily if i need to.

i'd still use less permissive containers for things i don't feel comfortable installing on the host, e.g. npm.

Post reply on HN