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

macOS Containers v0.0.1

macoscontainers.org

Post reply on HN
Print view View original

361–370 of 374 posts

Re: macOS Containers v0.0.1

#361

Post by cdaringe »

thtmnisamnstr wrote: post #273
therealmarv wrote: post #240

Reminds me: Still waiting for native ARM support on GitHub Actions https://github.com/actions/runner-images/issues/5631

This one is ridiculous. This should already exist. Until GitHub builds it, you can use GitHub Actions to kick your builds off but run them remotely on Earthly Cloud ( https://earthly.dev/ ). Even the free tier includes arm64 remote runners. Note: I work at Earthly, but I'm not wrong about this being a good, free, arm64-native workflow for GitHub Actions.

Isn’t that service shutting down in <1 week?

Re: macOS Containers v0.0.1

#362

Post by cdaringe »

daft_pink wrote: post #319

I feel cheated by Apple a little bit. I bought an Apple Silicon machine after their presentation claiming that they would have first class docker support, but the reality has been that while the first docker worked well as it was translated, now it wants to default to arm containers and it has become very difficult to use because it doesn't want to use Rosetta 2 containers. The whole point of using docker is to use t…

export DOCKER_DEFAULT_PLATFORM=linux/amd64

Re: macOS Containers v0.0.1

#363

Post by mbreese »

slonopotamus wrote: post #347
mbreese wrote: post #328

Earlier quoted context omitted.

Technical limitations aren’t excuses for a bad design. If it’s not a good design due to a technical limit, the answer isn’t to sacrifice security for functionality. If it really isn’t technically possible (which I think you might be able to do in a Darwin VM), then maybe this approach isn’t a good idea.

> Technical limitations aren’t excuses for a bad design. Tomorrow Apple might decide it is safe to chroot with SIP enabled (I actually do not understand why they restrict it, chroot is a tool to increase security). Does that suddenly convert bad design into a good design? But this is exactly the same design.

Design operates within the contexts of a system. A perfectly viable design can be made bad by a change in the system for which it was designed.

Does this current design require disabling SIP? Then I don’t think it is worth my effort to use (for my use case). If Apple changes the system in the future, my opinion might change.

But a design cannot be judged as good or bad outside of the context for which it was designed.

If you feel this is a better way to tackle the problem, then talk to Apple about it.

Re: macOS Containers v0.0.1

#364

Post by eviks »

sofixa wrote: post #276
eviks wrote: post #211

Earlier quoted context omitted.

Think this issue was fixed a few years ago

Not sure I agree, when I use brew it still regularly updates random unconnected crap through multiple major releases. And of course it takes ages doing so

I was referring to your postgresql example, those became rudimentary @versioned packages

Re: macOS Containers v0.0.1

#365

Post by fkgmeqnb »

totallywrong wrote: post #264
slonopotamus wrote: post #81

Earlier quoted context omitted.

Original author here. Thanks for spotting the typo, fixed. WRT security implications of disabling SIP - I don't think OS becomes any less vulnerable than usual Linux/Windows installation.

> I don't think OS becomes any less vulnerable than usual Linux/Windows installation. A modern Linux with SELinux enabled (the default in e.g. Fedora) running apps inside rootless containers (Podman doesn’t even need a daemon) is likely much more secure than your default MacOS or Windows.

If you're talking about desktop use, not really. All the software in a default Fedora desktop install, runs as unconfined by SELinux policies.

Where SELinux really shines is in server installs.

Re: macOS Containers v0.0.1

#366

Post by throwaway894345 »

lloeki wrote: post #353
throwaway894345 wrote: post #352

Earlier quoted context omitted.

Is that something you can configure in DfM or are you saying you sort of roll your own DfM alternative? Also, what does "VM isolation" mean here? How is NFS or VMware Fusion more "isolated" than DfM?

> Is that something you can configure in DfM No > or are you saying you sort of roll your own DfM alternative? Yes, I set up a NixOS VM and use DOCKER_HOST=ssh://docker@ If you want to have it easy you can roll with lima/colima (but I found the fs sharing slower than vmhgfs) > Also, what does "VM isolation" mean here? The host/guest boundary. The guest is just like any another, remote machine. DsM adds smoke and mirr…

Understood. Thanks for the explanation/clarification!

Re: macOS Containers v0.0.1

#367

Post by dkonofalski »

slonopotamus wrote: post #316
dkonofalski wrote: post #299

Earlier quoted context omitted.

Does OrbStack allow you to create MacOS Containers? It doesn't seem like it from their website. It seems like it just runs on MacOS to let you create Linux containers.

OrbStack is about Linux containers. What we're talking about in this topic is the only software in the world for macOS containers.

Then I wonder why the parent comment mentioned OrbStack as if it were somehow comparable or an alternative to this.

Re: macOS Containers v0.0.1

#368

Post by avidphantasm »

zshrc wrote: post #322
avidphantasm wrote: post #221

Earlier quoted context omitted.

I use AMD64 containers on my M1 Pro under Docker Desktop with zero problems. It’s about 10-20% slower than my AMD64 Linux machine on average, which is usually fast enough.

You ever give OrbStack a go? I used Docker Desktop before it but find OrbStack to be a lot faster and native feeling.

No, I’ll give it a look, thanks for the tip.

Re: macOS Containers v0.0.1

#369

Post by slonopotamus »

MuffinFlavored wrote: post #246

https://github.com/macOScontainers/macos-jail - new code https://github.com/macOScontainers/rund - new code https://github.com/macOScontainers/moby - fork, 6 commits https://github.com/macOScontainers/buildkit - fork, 4 commits https://github.com/macOScontainers/containerd - fork, 5 commits Would be interesting to see if they can get moby/buildkit/containerd changes upstreamed

If you want to follow my upstream attempts, subscribe to

https://github.com/moby/buildkit/pull/4059

https://github.com/moby/moby/pull/46558

Re: macOS Containers v0.0.1

#370

Post by Bnjoroge »

dmeijboom wrote: post #334
daft_pink wrote: post #319

I feel cheated by Apple a little bit. I bought an Apple Silicon machine after their presentation claiming that they would have first class docker support, but the reality has been that while the first docker worked well as it was translated, now it wants to default to arm containers and it has become very difficult to use because it doesn't want to use Rosetta 2 containers. The whole point of using docker is to use t…

Try OrbStack ;) It’s the only docker daemon alternative for Mac that makes working with docker acceptable.

+1 on Orbstack! def been a huge difference from the desktop client, and supports K8s too
Post reply on HN