slonopotamus

If you want to follow my upstream attempts, subscribe to

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

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

You mean, Earthly has macOS arm64 runners? I am failing to find any info on its website.

Okay, call it "labeled code snapshots")

Haha, what a mess)

Yeah, I undestand the situation with #8789.

It's not me, it's containerd "native" snapshotter. It turns to be efficient on macOS thanks to `clonefile` syscall.

> 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.

One might develop a game that by some kind of a miracle releases for macOS too. So they way to run CI tests on macOS. Or they might target iOS. And use macOS build machines to produce builds. The world is not only about web, you know?

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

> My preferred course of action in such situations is not specify a version at all.

This doesn't work because, well, I do make releases and they need some numbers)

FUSE is only used for bind mounts. If you write to a directory that belongs to container, you get the raw speed of host OS.

I believe that could be optimized in the future. At least, by splitting amd64/arm64 code.

This is a failed attempt to upstream part of containerd changes: https://github.com/containerd/containerd/pull/8789

Other part of containerd changes waits for gods-know-what: https://github.com/containerd/containerd/pull/9054

But I haven't gave up yet.

> macOS doesn't provide a stable system call API

I'm really wondering, do you have any links about macOS syscall stability over versions?

SIP won't save you from wrong file permissions.

And SIP doesn't defend you from editing files in /bin. They are guarded by the fact that root filesystem is mounted read-only.

Original author here. I wanted to clearly indicate early-prealpha-unstable-not-for-production-yet state of this software. Using "1.0.0" would give false expectations.

No. For the same reason you cannot run Windows containers on Linux. You need a working macOS kernel.

> But most it’s still very niche.

I'd say that the whole containerization topic is niche

> Is there a way to make a separate partition of MacOS and have one copy with SIP and one without?

I think you can install macOS VM on your macOS host and disable SIP _inside VM_.

> Who would use that and for what?

I believe this project can be useful for CI and testing scenarios.

> On MacOS desktop software distribution is largely a solved problem since ages

Are you talking about App Store? Or Homebrew? Or MacPorts? Or... Wait, isn't this too many tools for a problem that was solved?

> Also not sure if it can be dynamically set by a parent process for a child?

Yes, it can. See sandbox-exec tool. And I actually plan to use it: https://github.com/macOScontainers/rund/issues/15

I didn't want to use "jail" term because it is mostly unheard of outside of FreeBSD.

Container definition is very stretched nowadays. Look at Windows HostProcesses in Kubernetes [1]. They don't have neither process, network nor device isolation from the host.

I also plan to try macOS sandbox-exec tool, which should offer additional isolation from the host.

[1]: https://kubernetes.io/blog/2022/12/13/windows-host-process-c...

What exactly attack vectors you think are possible against macOS without SIP but not possible against Linux?

> this doesn't give me anything extra to what using docker would do on macos

You're missing the point. This project DOES use docker.

You can just mount it readonly.

> And that’s a good thing?

That's a technical limitation.

> What's the licensing situation on this?

1. This project didn't take explicit permission from Apple to redistribute binaries

2. There are multiple jurisdictions where you don't need to explicitly have such permission, it is implied by law

3. Usage of this software implies you already have macOS system. I'm not a lawyer, but it looks to be covered by section 3 of macOS EULA.

4. There are existing precedents of redistribution of macOS binaries for multiple years aready:

- https://github.com/cirruslabs/macos-image-templates/pkgs/con...

- https://hub.docker.com/r/sickcodes/docker-osx

- https://app.vagrantup.com/jhcook/boxes/macos-sierra

And so on.

> CI/CD workflows most likely

Yep, this is primary goal of this project.

It is the same for any OS. Virtual machine boots a separate instance of the whole OS. This is slow, this is often too much isolated (you can't easily/effectively share files between host and guest), you need to set artificial limits on VM disk/memory/cpu. On the other side, containers work in the context of host OS, what means less overhead and easier interaction with host.

Nope, that PR was an attempt to upstream my changes: https://github.com/macOScontainers/containerd/commits/macos

Vanilla containerd cannot mount anything on macos.

> If you really want good adoption, you’ll have to figure out a way for devs to try it out without first having to disable SIP.

I can't stress enough how I also would like it to work with SIP enabled!

Original author here.

> So essentially a chroot with a bit of make-up

Well.

1. It is not trivial to properly set up a chroot on macOS. If you try to find a working guide/tool that works with modern macOS, I doubt you'll find anything (at least, I failed, even though tried very hard) 2. I believe that ability to package stuff into a Docker image distributable via already existing infrastructure and compatible with already existing tools maybe "a bit of make-up", but it is an important makeup. 3. Kubernetes recently got HostProcesses for Windows: https://kubernetes.io/blog/2022/12/13/windows-host-process-c.... They are even less isolated from host than chroot and still, people find them useful for certain scenarios.

> and a lot of marketing?

Thanks for "a lot of marketing", that made me chuckle. My own submission got buried yesterday with humble 8 points: https://news.ycombinator.com/item?id=37640688