linux is great. macos is great. windows is great too. for their intended purposes.
it’s horseless carriages all the way down.
341–350 of 374 posts
linux is great. macos is great. windows is great too. for their intended purposes.
it’s horseless carriages all the way down.
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.
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.
Think places where security is a big deal, like finance, military, aerospace, critical infrastructure etc.
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
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.
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.
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.
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.
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?
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.
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…