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

51–60 of 457 posts

Re: macOS Container Machines

#51

Post by TimTheTinker »

deathanatos wrote: post #39
usernametaken29 wrote: post #17

Earlier quoted context omitted.

My first thought as well, docker desktop overhead is pretty bad, would be awesome to see this land natively in DD. By my estimate this could happen, seeing as Docker has historically tried to improve performance but quickly had to accept platform limitations… would only be natural to settle DD over to containers

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

Re: macOS Container Machines

#52

Post by kxxx »

kdrag0n wrote: post #44
kxxx wrote: post #40

Earlier quoted context omitted.

Apple says that `systemctl` is supported... hmm am I missing something? "Real Linux services for testing. Run a database or whatever your stack needs as a system service — systemctl start postgresql works on images with systemd installed."

Good catch, I tried the example alpine commands and there was no init system. Makes sense if it's based on OCI images

Just tested it on on an OCI image with systemd and it works well. I can see the appeal of OrbStack regarding memory reallocation and will stick with it in the time being :)

Re: macOS Container Machines

#53

Post by CGamesPlay »

numbsafari wrote: post #41

Wouldn’t it be nice if services like Codespaces or Coder or Gitlab would allow you to target running on their hosted/integrated platform, or let you launch that same container completely locally? Sometimes I wanna take my “remote” dev environment off-line but still benefit from the integrated UX.

If you can express that operation in Terraform, then Coder would let you do that. First problems I can think of are connectivity from the Coder provisioner to your local machine (Tailscale? Local?), and migrating disk images if you want to actually switch a workspace between environments (local provisioner could do this, but no matter what it’ll be slow and janky).

Re: macOS Container Machines

#54

Post by thatxliner »

jhancock wrote: post #45
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…

I’ve been using podman on Mac. It’s been a nice fit as the container build files are identical to what I use on my fedora server. I have noticed my 2 virtual core 4 gb Linode vps runs apps faster in the same container as when run on my MacBook Air M2 16 gb. I expected some performance overhead but didn’t think it would be noticeable as it is. Overall happy with podman. How might OrbStack differ?

Having used both, it feels like OrbStack "just works" more than Podman. The main example of this is Supabase.

Re: macOS Container Machines

#56

Post by vsgherzi »

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…

I love orbstack, is there any code I could read on the rust side? Seems very interesting

Re: macOS Container Machines

#58

Post by AlexB138 »

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.

Isn't the Windows subsystem for Linux (the reference there) also a VM?

Re: macOS Container Machines

#59

Post by TimTheTinker »

armadyl wrote: post #49
JumpCrisscross wrote: post #35

Earlier quoted context omitted.

Linux is easier to misconfigure. Macs resists being misconfigured insecurely. At their tightest, I'd say neither is fundamentally more insecure than the other. (The exception would be M5-based Macs, which come with MIE. Though that isn't a macOS vs Linux thing per se .)

This is incorrect macOS is fundamentally more secure than desktop Linux operating systems and it isn't particularly close. No amount of Linux hardening will get a system even close to an M-chip Mac. Software insecurities aside, desktop Linux OS systems have almost none of the hardware-backed security benefits that Macs do.

At some point, lack of security becomes a feature. A fully secure, locked-down, T2 attested macOS is able to be controlled not just by Apple, but by increasingly evil governments, with no recourse available to users.
Post reply on HN