7G images, wow
macOS Containers v0.0.1
241–250 of 374 posts
Re: macOS Containers v0.0.1
#242cries in Asahi Linux macbook is the best laptop there is but macos... can't wait for a stable release of Asahi and permission from corporate to install it even in a VM somehow. probably won't happen, but one can dream.
You're missing the point of Asahi, by the looks of it. It's not intended to be run in a VM.
As long as the architecture satisfies Popeck and Goldberg, why shouldn't it?
Re: macOS Containers v0.0.1
#243Earlier quoted context omitted.
It still has them, of course, but the concern is that after ~8 years of SIP basically ~everywhere, platform security decisions have been made assuming it is present. This concern is definitely not totally unfounded, back in 2019 Chrome shipped an update that rendered systems with SIP disabled unbootable: https://support.google.com/chrome/thread/15235262?hl=en
The "varsectomy" bug in Chrome isn't the example you think it is, because disabling SIP was not sufficient conditions for it. There were 3 other conditions that had to be met, the most notable of which is that "/" had to be writeable by tho logged-in user, which is not the default. This is an example of defense-in-depth being present, and defense-in-depth still failing for some users who gave escalated permissions to…
The two other conditions listed in the page you link basically amount to "the buggy code has to run". Related, I think SSV [1], introduced last year, would also have blocked this bug even with SIP disabled. But none of that invalidates concern that areas of the OS we don't know about might not have the level of defence in depth that we would like - it's not like Apple has never cut corners or shipped bugs to hit a date.
1: https://support.apple.com/en-gb/guide/security/secd698747c9/...
Re: macOS Containers v0.0.1
#244Earlier quoted context omitted.
> > Does XNU have such namespacing functionality across all its interfaces? > I don't think so, but some Docker features could be implemented using XNU sandboxing AFAIK Theoretically, probably, for coarse-grained yes/no things? I don't think it's able to go much further than "you can use the local network and/or internet" and "you can read/write to the filesystem location corresponding to you bundle identifier `com.f…
> 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
Oh my I totally forgot about sandbox-exec!
I played with it some time ago, can't recall the context but it was about build systems / packaging (maybe nix?), doing the configure/make/make install with reduced privileges.
Re: macOS Containers v0.0.1
#245Earlier quoted context omitted.
You're missing the point of Asahi, by the looks of it. It's not intended to be run in a VM.
As long as the architecture satisfies Popeck and Goldberg, why shouldn't it?
The point of Asahi is to provide linux drivers for Apple hardware. What would be the point? You can already run Linux in a VM on arm macOS today with good performances. You don't even need to disable SIP.
Re: macOS Containers v0.0.1
#246https://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
Re: macOS Containers v0.0.1
#247Earlier quoted context omitted.
I can use it to get stuff I need to do work and I don't remember the last time I couldn't. Upgrades sometimes leave me broken but it's usually ironed out fast because everyone is using it. If my dependencies are that locked down I'm using docker and special environments anyway. Linux can get tedious with upgrades breaking or dependency mismatches. Homebrew is probably the largest homogenous community - if you're doin…
Homebrew is available for Linux as well since approx 3yrs now. I've been using it without issues https://docs.brew.sh/Homebrew-on-Linux
I’m curious what’s the benefit? I use homebrew as a Linux package manager for MacOS. On Linux I just use the distros package manager
Re: macOS Containers v0.0.1
#248Earlier quoted context omitted.
OK but what I like about homebrew on mac is that when I'm having an issue with "popular stack X broke after updating" it's probably me and >10k other people out there, so by the time I hit the problem it's already under investigation on GH. I'm not sure the same would apply to homebrew on Linux - even if you ignore the differences between distros - how popular is homebrew on linux and linux desktop in comparison ?
I wish more of those 10k people would help get others off of a package manager that is so fragile and convoluted that updating so often leads to popular things breaking. Things like macports and pkgsrc do things in an arguably much simpler, more unixy way, without the contortions that so often seem to leave homebrew in a bind after routine operations like updating.
I’ve never experienced a broken homebrew and I’ve used Mac for years
Re: macOS Containers v0.0.1
#249Re: macOS Containers v0.0.1
#250When 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.