Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

macOS Containers v0.0.1

macoscontainers.org

Post reply on HN
Print view View original

141–150 of 374 posts

Re: macOS Containers v0.0.1

#141

Post by tipsytoad »

stonewhite wrote: post #88
urxvtcd wrote: post #71

Earlier quoted context omitted.

Anecdotal evidence, but here it goes. I moved from Linux to M1 MacBook recently. I know my greps and vims, but I was tired of audio glitches during high CPU usage, system not waking up from sleep, total OS freezes, super loud fans, and so on. Now I get none of that. I don't think I've ever heard the fans. Audio just works, everything is super snappy. It always wakes up. I'm no longer afraid of bluetooth. And on top o…

Exactly my experience. After 15 years, I became an apple fanboy in 15 days. I still do hate losing my muscle memory on some bash shortcuts, but I'd say it was very much worth it.

Karabiner and applescripts can get you pretty far

Re: macOS Containers v0.0.1

#142

Post by lloeki »

donatj wrote: post #134
lloeki wrote: post #130

Earlier quoted context omitted.

> Would I be distributing parts of macOS in my containers? Unless you're producing fully static binaries (or static enough that they don't bind to non-redistributable things) it'd be a yes (it would not be much of a container if it needed non-packaged things) The screenshot points out a ghcr.io URL that lands on these packages: https://github.com/orgs/macOScontainers/packages?repo_name=m... Edit: There's a note here†…

Counting the hours until this gets DMCA'd out of existence

Anecdotally:

- there has been images like that circulating on well-known platforms† for a long time.

- I never heard of a single DMCA on any of these, even though they were on much clearer violation of the license.

Apple might be pulling a Hackintosh manoeuvre here.

† an example, there are many others: https://app.vagrantup.com/jhcook/boxes/macos-sierra

Re: macOS Containers v0.0.1

#143

Post by Angostura »

perryizgr8 wrote: post #15
highwaylights wrote: post #7

https://github.com/macOScontainers/homebrew-formula "macOS native containers" Cool, this sounds interesting. "Disable System Identity Protection." Eesh.

> "Disable System Identity Protection." This is the first thing I do on any Mac OS system before I start using it.

... the second thing being scanning for Malware, presumably

Re: macOS Containers v0.0.1

#144

Post by dangus »

RockRobotRock wrote: post #65
ThePowerOfFuet wrote: post #38

Earlier quoted context omitted.

Unfortunately, that doesn't answer their question.

It answers both of their questions. Git lets you see the author and they can audit the code if they like.

IMO that’s not good enough, especially when disabling SIP is involved.

We don’t even have certainty that the human running the account is who they say they are (anyone can make a GitHub account and make it look like a real person).

Not everyone who wants to use a container system understands the underlying code of that container system. If I’m a web developer using Docker Desktop or podman to build my PHP app, I’m not necessarily going to understand the code written in Go when my specialty is PHP.

Re: macOS Containers v0.0.1

#145

Post by dangus »

puquesnrn wrote: post #50
ThePowerOfFuet wrote: post #38

Earlier quoted context omitted.

Unfortunately, that doesn't answer their question.

yes it does. There’s only one contributor for most of it and you can click to see his profile. With the source code available and the primary contributor clear, what more could anyone want? Certainly it’s a bit much for one to ask for a security audit they themselves won’t do

How hard is it to make a GitHub profile?

If I am a developer using podman/Docker to build my PHP images, am I expected to understand code written in Go?

These are all acceptable risks until someone is asking me to disable SIP.

Re: macOS Containers v0.0.1

#146

Post by capableweb »

ayewo wrote: post #99
slonopotamus wrote: post #81

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

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 ?

Sounds like if Apple wants developers who wants to use containers natively, they need to address the problem of not being able to offer this feature without disabling SIP.

No matter what you or I think about what's needed for adoption, technical problems get in the way of the tool working with SIP, so seems it's in Apple's ball court really.

Re: macOS Containers v0.0.1

#147

Post by highwaylights »

slonopotamus wrote: post #81
maggit wrote: post #33

Earlier quoted context omitted.

"System Integrity Protection (SIP)" seems to be the correct name here, for anyone as confused as me :) (More details here: https://support.apple.com/en-us/102149 )

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.

This is not necessarily the case.

On Linux, more or less the entire permissions system makes no assumption about SIP existing (as it doesn't there), so other protections are relied upon to secure the system (such as SELinux, granular directory permissions, etc.).

On both Linux and Windows, TPM and secure boot provide similar protections to SIP on macOS, but are optional (it's encouraged more forcefully on Windows 11).

Removing SIP from a system that relies on it as a basis for platform security is different than using a system that wasn't relying on it in the first place.

Re: macOS Containers v0.0.1

#148

Post by matwood »

prmoustache wrote: post #103
Klonoar wrote: post #42

Earlier quoted context omitted.

So I take it you don't use Apple Pay or anything...? Edit: to be clear for the people who may not know, Apple Pay does not work with SIP disabled. ;P

Is Apple Pay that popular?

On mobile absolutely [1]. Not sure on the computer, but I use it all the time.

[1] https://capitaloneshopping.com/research/apple-pay-statistics...

Re: macOS Containers v0.0.1

#149

Post by iFreilicht »

lopkeny12ko wrote: post #36
cassianoleal wrote: post #20

Earlier quoted context omitted.

You're free to disable SIP, so your post makes no sense. It's more akin to locking your front door. Keep it locked if you want the extra protection but feel free to crank the door open if you want the breeze to come in, but knowing that more than the breeze might do so.

Have you ever tried modifying the filesystem a couple levels under /? Last I used a Mac I remember trying to create a new directory in / and writing to /bin (or something like that). I was appalled that Mac doesn't let you do anything other than read-only operations for select paths a few levels under root, and as I remember, there way no way to disable this asinine behavior.

That specific example doesn't seem to be an issue anymore. The Nix Installer creates /nix/store on macOS 13.5 just fine without disabling SIP. You do need admin rights of course.

Re: macOS Containers v0.0.1

#150

Post by pasc1878 »

doctor_eval wrote: post #44
lopkeny12ko wrote: post #36

Earlier quoted context omitted.

Have you ever tried modifying the filesystem a couple levels under /? Last I used a Mac I remember trying to create a new directory in / and writing to /bin (or something like that). I was appalled that Mac doesn't let you do anything other than read-only operations for select paths a few levels under root, and as I remember, there way no way to disable this asinine behavior.

I say this as someone who has used Unix, MacOS and Linux for most of his long life: not being able to write to /bin and other system directories is a feature and I really don’t understand how anybody in 2023 could see it otherwise. Freedom does not just imply the ability to do the things you want, but also the ability to avoid the things you don’t.

Why 2023 writing to /bin was always a bad idea in 1994 when I first used Unix and would have been so even earlier.
Post reply on HN