https://github.com/macOScontainers/homebrew-formula "macOS native containers" Cool, this sounds interesting. "Disable System Identity Protection." Eesh.
I always disable SIP on every Mac I own. It's not very useful and I can run whatever I want on my hardware.
macOS Containers v0.0.1
321–330 of 374 posts
Re: macOS Containers v0.0.1
#322Earlier quoted context omitted.
>Wouldn't a Linux device, or Linux running on a Mac suit you better? Maybe they want a unixy desktop with working sound ? Half joking, but that's my use case - homebrew is pretty great, most developers use a Mac in my domains of interest so it's always supported. Linux is just too much work (and I'm using Fedora on my desktop). SIP is just false positives and annoyance. I'm on the fence about M/ARM switch since I sti…
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.
Re: macOS Containers v0.0.1
#323Earlier quoted context omitted.
depending of what you mean by friction with containers, there may be different solutins. for example, as a temporary solution on Docker when you don't want/have time to support both arm and x86, you can do something like this: FROM --platform=linux/x86_64 ubuntu:23.04 i haven't found any issues with it that i could not get over in the past 2+ years of m1. most of the containers are available on both architectures any…
> i haven't found any issues with it that i could not get over in the past 2+ years of m1. I'm currently running a Journal of Open Source Software x86 container on aarch64 and it's terribly slow. Takes 12GB of RAM and 3 minutes to build a LaTeX document, see https://github.com/openjournals/inara/issues/30 . Any tips?
> I'm currently running a Journal of Open Source Software x86 container on aarch64 and it's terribly slow
There's your issue. Use an aarch64 image.
Re: macOS Containers v0.0.1
#324https://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
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.
Re: macOS Containers v0.0.1
#325When macOS runs on Unix kernel and Linux systems are the best supported for containerisation and I assume are much more lightweight than macOS, I personally don't see any reason to run macOS in a container.
You would do it so you can run mac software in a container.
I think I get that part :) but realistically if anyone wants to run macOS software they are most likely macOS users already. Whereas containerisation is useful to aid with development and deployment. Have you come across anyone who runs production software on macOS? :)
Re: macOS Containers v0.0.1
#326MacOS is - by choice - an Apple controlled walled garden.
Trying to break out of that is an exercise in futility.
Can you come up with situations where I would run a container instead of just running an app or sys service?
Re: macOS Containers v0.0.1
#327Earlier quoted context omitted.
Docker Desktop doesn’t require me to disable SIP. Why would I use this if it requires that?
To containerize darwin binaries? This is not an alternative to remotely connecting to a VM to control Linux containers (which DfM is)
So why don’t they run a Darwin VM that doesn’t need SIP and control it in the same manner?
Re: macOS Containers v0.0.1
#328Earlier quoted context omitted.
And that’s a good thing? I’m not sure the benefits of containers would be worth disabling SIP. Maybe for an automated test CI/CD running system (which is probably the main use-case), but not on anything that users would interact with.
> 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.
Re: macOS Containers v0.0.1
#329Earlier quoted context omitted.
You would do it so you can run mac software in a container.
I think I get that part :) but realistically if anyone wants to run macOS software they are most likely macOS users already. Whereas containerisation is useful to aid with development and deployment. Have you come across anyone who runs production software on macOS? :)
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?
Re: macOS Containers v0.0.1
#330Earlier 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.
No, that's not true. Turning off SIP is usually about equivalent to allowing instant escalation to root privileges; sometimes even worse.
Can you please expand on this? It wasn't my understanding at all.
A decade ago SIP didn't exist at all. I thought disabling SIP just put us back to how things were in Yosemite. What changed?