Live data from Hacker News

macOS Containers v0.0.1

macoscontainers.org

341–350 of 374 posts

Re: macOS Containers v0.0.1

#341
the amount of engineering hours wasted making macos usable for backend dev work and then wasted again from inefficiency due to that failure is staggering.

linux is great. macos is great. windows is great too. for their intended purposes.

it’s horseless carriages all the way down.

Re: macOS Containers v0.0.1

#342
post #274

Earlier quoted context omitted.

Neither is using macfuse as a stand in for overlayfs and bind mounts. My point is "as fast as it gets" is using MacOS how MacOS is designed: ie, through sandboxing and not containerization that pretends the MacOS userspace is Linux. It's not Linux. There is a fundamental trade off between isolation and performance. You cannot securely share resources without overhead.

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.

How do you support layers without overlayfs?

Re: macOS Containers v0.0.1

#343
post #99

Earlier quoted context omitted.

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. Is this related to the code you tried to have merged here: https://github.com/containerd/containerd/pull/8789 ?

In corporate managed laptops it may not be an option to disable SIP.

Understatement of the year. I am sure there are some places where being caught doing something like that (without authorization) could result in one of those “my hands are tied, I have to fire you” situations.

Think places where security is a big deal, like finance, military, aerospace, critical infrastructure etc.

Re: macOS Containers v0.0.1

#344
post #34

Earlier quoted context omitted.

I'm more interested in this as part of a CI/CD process for releasing macOS software. For an isolated build worker - yeah, sure, I'll go ahead and disable SIP. Not every workload is running on an endpoint connected to a human via keyboard and screen.

>For an isolated build worker - yeah, sure, I'll go ahead and disable SIP. Isn't this especially dangerous on a build worker? All your source code goes in and you (presumably) use the binaries that come out across the rest of your infrastructure. Compromising a build worker in a persistent fashion due to lack of SIP seems like it could do some serious[1] harm... 1: https://wiki.c2.com/?TheKenThompsonHack

Depends on your threat modeling. Are you running untrusted code on the worker (maybe you have an org with thousands of engineers, maybe you're running builds from a public fork)? Sure, that's an issue. Are you a small startup? Take the convenience and focus on the bigger fish to fry.

Re: macOS Containers v0.0.1

#346
post #254

Earlier quoted context omitted.

Which makes the point that there is hardly any UNIX inovation coming from them. Please cite a USENIX research paper from Apple.

Apple didn’t invent the GUI, touchscreen or the concept of unifying init, cron, etc. But it was after they released their implementations that those ideas caught on. I hope you can see the point I’m making.

UNIX was already winning the server room and workstation market before Apple, that is why they came up with A/UX in first place.

The Hollywood studios that now use Apple, would be using SGI previously.

On iDevices, UNIX APIs aren't even that relevant for app development, even basic stuff like networking has been superceeded by Objective-C specific APIs.

So no, I don't see anything UNIX related where Apple has helped to caught on.

Moving beyond UNIX, now that is a thing NeXT and Apple have done a lot.

Re: macOS Containers v0.0.1

#347

Earlier quoted context omitted.

> And that’s a good thing? That's a technical limitation.

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.

Re: macOS Containers v0.0.1

#348
post #342

Earlier quoted context omitted.

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.

How do you support layers without overlayfs?

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

Re: macOS Containers v0.0.1

#349

Earlier quoted context omitted.

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.

Just merged #9054. Sorry for that we had to revert #8789, but we are looking forward to seeing that PR submitted again with an alternative abstraction interface.

Yeah, I undestand the situation with #8789.

Re: macOS Containers v0.0.1

#350

Earlier quoted context omitted.

Version 0?

Oh, it was easier than I thought: https://semver.org/#spec-item-2 A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0. So, no leading zeros, ta-da! Oh, wait. The spec was written by som…

Haha, what a mess)
Post reply on HN