Live data from Hacker News

macOS Containers v0.0.1

macoscontainers.org

301–310 of 374 posts

Re: macOS Containers v0.0.1

#301
post #274

Earlier quoted context omitted.

> reasonably fast. But still not "as fast as it gets". And I want it to be as fast as it gets.

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.

Re: macOS Containers v0.0.1

#302
post #267

Earlier quoted context omitted.

I've only used it with Linux kernels, but that has not been my experience with the new Virtualization.framework. The perf of virtio shares is reasonably fast. I can see how you'd need a crap ton of disk for MacOS virtualization, but again, why do you need it? If it's isolation for builds, fix your build. If it's isolation for tests, live with it. If it's for running your app, write your app to properly run in the app…

> If it's isolation for builds, fix your build Isolation fixes the problem for free and is more similar to how I build for Linux. Why would I want another solution?

MacOS apps are designed to be self contained and not require isolation, unlike most Linux distros, which are designed to use FHS and share their state/dependencies with everything else on the system.

Further you can sandbox processes just fine on MacOS without needing to mock the whole userspace, like you do on Linux. This will give you the same degree of isolation that a container does.

Re: macOS Containers v0.0.1

#303

Earlier quoted context omitted.

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

This kind of makes me wonder why you'd have a Mac at all (I'm sure there are use cases). Wouldn't a Linux device, or Linux running on a Mac suit you better? For me, the security picture is one of the main features of the eco-system even if it's very restrictive - disabling SIP undermines it more or less completely.

> why you'd have a Mac at all

My work provides it. Everyone else uses it and I don't want to be the one with a different setup.

Re: macOS Containers v0.0.1

#304

Earlier quoted context omitted.

Don't disable security features because of random comments from randos. Also, don't install shit anywhere but your home directory as you unless you want to break your system in an irreparably, unmaintainable, or unsupported manner. If you're using sudo, you're already doing it wrong. https://support.apple.com/en-us/102149

Civilized people don’t install things in “/“.

I'm not sure if you were arguing against the parent comment or supporting it but did you actually mean "/" and not "~/"?

Re: macOS Containers v0.0.1

#305
post #42

Earlier quoted context omitted.

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

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

No, I don't use apple pay. I don't have any apple device for personal use at all, and I wouldn't use my work MacBook for personal payments.

Re: macOS Containers v0.0.1

#306

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

> With the source code available and the primary contributor clear, what more could anyone want?

Reproducible builds. :)

Re: macOS Containers v0.0.1

#307

Earlier quoted context omitted.

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

This kind of makes me wonder why you'd have a Mac at all (I'm sure there are use cases). Wouldn't a Linux device, or Linux running on a Mac suit you better? For me, the security picture is one of the main features of the eco-system even if it's very restrictive - disabling SIP undermines it more or less completely.

In my opinion, MacOS is just a nicer experience on the whole than (Ubuntu or Red Hat) Linux (I have limited experience with other distros, but they are all pretty comparable to the big distros at best.

I only ever really had one goofy driver/deep OS bug in Mac - something with the location daemon would cause the wireless internet connection to cut out repeatedly. That bug was left behind with that machine when I left that company, and didn't appear in my next macbook pro.

Linux is just always a struggle with drivers, subtle bugs, and other misc friction. It's not a dealbreaker - ubuntu 22.04 is still my daily driver, but it's very much enough that I would prefer a mac for most development.

For example, if I run a software update, it quietly breaks the fn keys to change screen brightness, and when the machine wakes from sleep, the screen stays black. I figured out after much trial that running ubuntu-drivers fixes it, but it's a pain. I'd rather just turn off auto-updates.

Also the Command key for keyboard shortcuts is brilliant and just works across the whole system. On linux I have to use ctrl-shift to copy/paste and I haven't found a good workaround yet.

Re: macOS Containers v0.0.1

#308

Earlier quoted context omitted.

Original author here. I wanted to clearly indicate early-prealpha-unstable-not-for-production-yet state of this software. Using "1.0.0" and even "1.0.0-alpha" would give false expectations about maturity of this project.

This was more of a stab at "semantic" part of the semantic versioning (which similar to in semantic Web... found its own semantics that don't follow from its definitions). You are definitely not the only one using it like this. I believe this is the problem with the format of semantic version which seem to assume that releases only happen to software ready to be... released :) My preferred course of action in such si…

> My preferred course of action in such situations is not specify a version at all.

This doesn't work because, well, I do make releases and they need some numbers)

Re: macOS Containers v0.0.1

#309
post #251
post #243

Earlier quoted context omitted.

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 da…

One can have vague, general concerns about any operating system if one lets their imagination run wild, though, and one doesn't care about the presence or absence of specific examples supporting the suggestion that the "permissions system...makes assumption[s]" about SIP existing.

I think we have a rather specific example of a Chrome bug hosing OS installs. Had SIP not existed, there's virtually zero chance that bug wouldn't have been caught before shipping.

Re: macOS Containers v0.0.1

#310
post #266

Earlier quoted context omitted.

> I don't think OS becomes any less vulnerable than usual Linux/Windows installation. A modern Linux with SELinux enabled (the default in e.g. Fedora) running apps inside rootless containers (Podman doesn’t even need a daemon) is likely much more secure than your default MacOS or Windows.

I think you're probably @totallywrong

TBH, Fedora Silverblue with the parent commenter's approach it's far more secure.
Post reply on HN