Live data from Hacker News

macOS Container Machines

github.com

121–130 of 457 posts

Re: macOS Container Machines

#121
post #90

Earlier quoted context omitted.

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.

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

Re: macOS Container Machines

#122
post #110
post #103

Earlier quoted context omitted.

> Literally nobody would build to it because nobody does ci/cd against macOS or iOS apps right?

And what is the revenue stream tied to that ci/cd pipeline they aren’t capturing today? Apple would sell less hardware in order to…? There aren’t any app developers avoiding the Apple ecosystem because there aren’t Darwin containers. They don’t sell server hardware and by all accounts have no intention of ever reentering that space. So they’d spend a bunch of developer cycles to reduce their own revenue stream with n…

Correct me if I'm wrong, but by the same logic, you could also say this whole containerization framework is of no use either.

If they're investing resources into it regardless, they might at least try making something that Docker for macOS and co. haven't solved the same exact way already. Something that, due to their almost unhealthy obsession with "system integrity", only they can realistically make. Like native containers.

Re: macOS Container Machines

#124

Earlier quoted context omitted.

Well, you can avoid the Docker Desktop tax by not running Docker Desktop. colima is a perfectly usable implementation of Docker for macOS, without the bloat of Docker Desktop. That said, colima still has the expensive VM that upthread is mentioning.

OrbStack is great also

Postman Desktop too

Re: macOS Container Machines

#125
post #113
post #15

Earlier quoted context omitted.

And a legitimate business interest to further incentivize the adoption of Apple Silicon devices. Same with Rosetta deprecation after macOS 27.

Sure, but to what extent? Enterprise ARM servers are still a niche product, and so are the ARM developer machines running Linux or Windows. Until this significantly changes, Apple will have to provide good x86 interop - or lose the developer market entirely. Forcing people towards Apple silicon is of course an attractive approach when targeting the large portion of the market using their MacBooks as Facebook browsing…

> Until this significantly changes, Apple will have to provide good x86 interop - or lose the developer market entirely.

I'm very, very skeptical of this analysis. Certainly "entirely" is hyperbole.

Re: macOS Container Machines

#126
post #122
post #110

Earlier quoted context omitted.

And what is the revenue stream tied to that ci/cd pipeline they aren’t capturing today? Apple would sell less hardware in order to…? There aren’t any app developers avoiding the Apple ecosystem because there aren’t Darwin containers. They don’t sell server hardware and by all accounts have no intention of ever reentering that space. So they’d spend a bunch of developer cycles to reduce their own revenue stream with n…

Correct me if I'm wrong, but by the same logic, you could also say this whole containerization framework is of no use either. If they're investing resources into it regardless, they might at least try making something that Docker for macOS and co. haven't solved the same exact way already. Something that, due to their almost unhealthy obsession with "system integrity", only they can realistically make. Like native co…

Supporting the containerization framework lets them sell more laptops to Linux devs that may have otherwise bought a Dell or hp or insert brand to run Linux natively on or windows with WSL.

Re: macOS Container Machines

#127
post #26

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…

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

Re: macOS Container Machines

#128
The costs are startup time and image compatibility: dockerhub images don't work as machine images because container machine expects systemd

I am trying it on but its brekaing on homebrew 1.0.0. The formula puts plugins at opt/container/libexec/container-plugins/ and the apiserver looks in libexec/container/plugins/

This can be solved through a symlink or smth

Re: macOS Container Machines

#129
post #121

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

You could also use forward slashes, like C:/path/subpath, which has worked since Windows 1.0/DOS 2.0.

That's handy when you're entering paths in a Cygwin/MSYS Bash shell, but might not help much if you're trying to parse or otherwise work with existing patgh variables composed with backslashes.

Re: macOS Container Machines

#130
post #37

Would be cool if you can redirect USB devices to the VM.

We just released this in OrbStack :) https://docs.orbstack.dev/features/usb Blog post soon

What happened to Orbstack for like 9 months until earlier this year? Suddenly everything went silent for a bit and I was pretty concerned. Glad y’all are back!!!!
Post reply on HN