Hacker News Reader

Hacker News

Comment by highwaylights | Hacker News Reader

Full thread

highwaylights

https://github.com/macOScontainers/homebrew-formula

"macOS native containers"

Cool, this sounds interesting.

"Disable System Identity Protection."

Eesh.

View on HN

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

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.

> Technical limitations aren’t excuses for a bad design.

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.

Design operates within the contexts of a system. A perfectly viable design can be made bad by a change in the system for which it was designed.

Does this current design require disabling SIP? Then I don’t think it is worth my effort to use (for my use case). If Apple changes the system in the future, my opinion might change.

But a design cannot be judged as good or bad outside of the context for which it was designed.

If you feel this is a better way to tackle the problem, then talk to Apple about it.

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)

And what is the benefit of that? Who would use that and for what? Containers solved deployment, and software distribution problems related to diversity of runtime environments on linux. It also has some security benefits, but their adoption was successful because it solved real world everyday problems. It eventually allowed better utilization of servers.

They did not have such success on windows, despite Windows also having a container subsystem, as windows servers already did this with IIS web app containerization.

On MacOS desktop software distribution is largely a solved problem since ages. On MacOS/Darwin servers... are there such in industrial use apart from some research installations?

> Who would use that and for what?

I believe this project can be useful for CI and testing scenarios.

> On MacOS desktop software distribution is largely a solved problem since ages

Are you talking about App Store? Or Homebrew? Or MacPorts? Or... Wait, isn't this too many tools for a problem that was solved?

So why don’t they run a Darwin VM that doesn’t need SIP and control it in the same manner?

Docker For Max marshals filesystem events over a VM host/guest boundary which can grind the most powerful computers to a halt if you’re sharing directories between the host and guest. For example, at my last company we developed Python apps and ran them in Docker for Mac containers by mounting the source code directory into the containers (so we wouldn’t need a build step) but as our project grew the filesystem event marshaling became exponentially slower until we eschewed Docker from our dev iteration loop entirely (the fidelity benefits weren’t worth the performance hit). Note: there are lots of projects and hacks that claim to solve this problem but none made an ounce of difference.

The alternative is to use a performant file sharing system through the VM isolation. Some people use NFS, I personally use VMware Fusion + vmhgfs.

Sure it does not attempt to map fsevents<->inotify 1:1 but honestly I can live with that limitation given that it's a 10x performance increase compared to the DfM kitchensink.

I do go native darwin when I can / it makes sense.

Is that something you can configure in DfM or are you saying you sort of roll your own DfM alternative? Also, what does "VM isolation" mean here? How is NFS or VMware Fusion more "isolated" than DfM?

> Is that something you can configure in DfM

> or are you saying you sort of roll your own DfM alternative?

Yes, I set up a NixOS VM and use DOCKER_HOST=ssh://docker@<ip>

If you want to have it easy you can roll with lima/colima (but I found the fs sharing slower than vmhgfs)

> Also, what does "VM isolation" mean here?

The host/guest boundary. The guest is just like any another, remote machine. DsM adds smoke and mirrors to make it look like guest and host are one.

> How is NFS or VMware Fusion more "isolated" than DfM?

It's not, both are VMs and need a way to expose the host fs to the guest, NFS or vmhgfs are a means to that.

Understood. Thanks for the explanation/clarification!

> until we eschewed Docker from our dev iteration loop entirely

Can you say anything more about what you did instead, and how it ended up working out?

We used native MacOS processes and it worked out fine. In practice I don't recall any bugs due to different behavior between our dev environment (MacOS) and our production environment (Linux) and we saved a ton of time during development. Docker just wasn't worth it. This worked for us because our app didn't depend on any platform specific behavior.

Of course, if you are using Go or some other language with a fast, static cross-compilation step, you don't need to mount a source code volume into your container, you can just rebuild the whole container image or rebuild on the host and `docker cp` the new binary onto the target container.

Docker Desktop for macOS does full-blown hardware virtualization, which is just silly.

Docker Desktop runs an entire second kernel in a VM.

This should have faster file access than Docker Desktop. For large projects, disabling SIP may be worth the increase in performance.

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 ?

Nope, that PR was an attempt to upstream my changes: https://github.com/macOScontainers/containerd/commits/macos

Vanilla containerd cannot mount anything on macos.

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

I can't stress enough how I also would like it to work with SIP enabled!

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.

In corporate managed laptops it may not be an option to disable SIP.

Understatement of the year. I am sure there are some places where being caught doing something like that (without authorization) could result in one of those “my hands are tied, I have to fire you” situations.

Think places where security is a big deal, like finance, military, aerospace, critical infrastructure etc.

> I don't think OS becomes any less vulnerable than usual Linux/Windows installation.

is not a good enough argument.

For the story, SIP is Apple's "rootless". Effectively the OS runs with less privileges than root. Disabling SIP significantly increases the attack surface.

That being said, I'm grateful that someone decided to do something more native for containers in macOS.

I think it's an OK argument given that most people run (and have been running with no alternative until very recently) docker in such a way that there's a trivial privesc to root. In general it seems like docker users are, overall, willing to take that tradeoff.

How so? I use docker pretty frequently, but I’m sure that my user is part of the docker group before I do, so I don’t sudo anything.

Is there anything else I should be doing security wise?

I’ve been hearing podman is more secure, but I think it’s still containerd under the hood, so idk how true that is.

In general if you can `docker run` without sudo then that means you have a trivial privesc path since you can do `docker run` with the various flags that run it without any sandboxing, get a shell, and just ask to be let out of the namespace.

The way that podman and newer versions of docker get around this is using unprivileged user namespaces. Unprivileged user namespaces are not a free lunch - in fact, they're a bit of a security disaster in their own right.

In a typical installation, being in a docker group gives you access to a socket that controls docker daemon and that daemon runs as root. `sudo` is not important in this context.

Thankfully there is rootless mode for some time now: https://docs.docker.com/engine/security/rootless/.

Podman, too, can run in rootful and rootless mode. Rootless in podman still feels to me to be more like first class citizen, as opposed to docker case.

In both cases it's important to keep in mind in which mode you operate. Both from the perspective of security and day to day operations, as some aspects of behavior will differ between those modes.

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.

macOS had granular directory permissions way back when it was NeXTSTEP, long before SIP was introduced. Where are you suggesting they disappeared to?

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 some installers, allowing them to run roughshod over their filesystem permissions, leaving them vulnerable to a subsequent varsectomy. If one did the same thing to their Linux system, the same thing could happen.

https://arstechnica.com/information-technology/2019/09/no-it...

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

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.

Here's a better one: https://gist.github.com/ChiChou/e3a50f00853b2fbfb1debad46e50...

What exactly attack vectors you think are possible against macOS without SIP but not possible against Linux?

I think the argument is that file permissions may not be applied as rigorously, with the assumption that SIP is in effect.

SIP won't save you from wrong file permissions.

And SIP doesn't defend you from editing files in /bin. They are guarded by the fact that root filesystem is mounted read-only.

Entitlement stealing, for example.

With SIP enabled it’s not possible to load arbitrary kernel extensions, for one - they must be signed.

I'd like to digress to your "Encouraged more forcefully" phrasing which is quite interesting if you think about it. In my view, it would mean something like pervasive dialog box ala EULA, some UI hoops you need to resolve, alike going with local account on installation.

In reality they done basically everything to force users to use secure boot. If they disabled normal boot altogether, OS adoption would suffer heavily. They could've obscured that option, but it would be found out, and enterprise users would be pissed at them because they didn't gave them a provisionable way while the way exists. So it came down to normal variables in installer registry.

However modifying, e.g making users "hack" the ISO is really as forceful as it gets without market loss.

Note: There may be more normal way today than modifying the registry of ISO, I installed 11 once when it came out.

> 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

Well Linux powers just about all the most important systems in the world and SELinux was originally developed by the NSA, but I'd love to get your insights.

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

If you're talking about desktop use, not really. All the software in a default Fedora desktop install, runs as unconfined by SELinux policies.

Where SELinux really shines is in server installs.

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?

Apple relied on it being turned on and started introducing permission checks where you'd have things like "do thing as root" and check for some flag being set that is protected by SIP. If you have it turned on, there are no issues, because the check blocks both root and non-root users! But if you turn it off, now the "do thing as root" is available to any account because the flag is editable.

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

Depends on your threat modeling. Are you running untrusted code on the worker (maybe you have an org with thousands of engineers, maybe you're running builds from a public fork)? Sure, that's an issue. Are you a small startup? Take the convenience and focus on the bigger fish to fry.

That's what it takes to implement container-ish technology on macOS. Hopefully one day Darwin will get real namespaces as Linux does.

In the context of an internal CI or something, it's probably fine.

Given that the vast majority of CI runs on linux without any equivalent of SIP, I'd have thought it were a complete non-issue

You might want to run CI/CD on your Mac builds

"v0.0.1"

There's probably a hundred things that are not right just yet and they know it, let's not be overly negative

(although the discussion on what it is and what it does definitely is interesting)

OrbStack doesn’t require breaking security: https://orbstack.dev/

Does OrbStack allow you to create MacOS Containers? It doesn't seem like it from their website. It seems like it just runs on MacOS to let you create Linux containers.

OrbStack is about Linux containers. What we're talking about in this topic is the only software in the world for macOS containers.

Then I wonder why the parent comment mentioned OrbStack as if it were somehow comparable or an alternative to this.

> "Disable System Identity Protection."

This is the first thing I do on any Mac OS system before I start using it.

Could you elaborate why? I’m new to macOS, I’d love to learn more about it.

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 "~/"?

Reads like support, and I'm 99% sure they mean "/"

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

I guess you don't use Homebrew or MacPorts?

SIP is a feature that protects you from malicious actors with root (admin) access on your device. After they've encrypted your photos and drives and changed your passwords, it prevents them from making your machine unbootable by deleting or altering system binaries. As a side effect of this protection, you give up certain freedoms to customize your system.

https://github.com/koekeishiya/yabai

For instance requires SIP to be disabled.

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.

I would think most people choose macOS over Linux for the familiarity with the UI/UX and software availability (Adobe and MS stuff).

I would expect a very small number people making this choice over security concerns.

Windows is constantly forces people with popups to makes scary security decisions and if they press no, the world stops working

I'm not your parent post but surely the easy answer to why use a mac at all is simply how great the hardware is. The 2020 M1 Air is nearly 3 years old and still a brilliant machine.

>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 still see a lot of friction with containers so I might be looking at framework for my next device. Or just go all in on client/server development model.

> Maybe they want a unixy desktop with working sound ?

In my experience, this has not been an issue for the past 10-15 years atleast. Before that there were some problems with few (external) soundcards or random cpu spikes with the mixers.

However, the UX can still improve. Switching audio outputs with multiple outputs like external displays etc is not very smooth or intuitive.

Some bluetooth headsets have issues but I've had those with a mac as well.

There's only a 1% chance these days on Linux that your sound won't work or your computer won't sleep when you close the lid or your wifi won't work, or your ethernet, or your cooling, or a peripheral, or CPU/memory spikes.

And a 90% chance it'll be at least one such thing.

All of those things work fine on every computer in my household that runs Linux. This spans thinkpad, dell and ASUS laptops, Dell desktops, home-built gamer type desktops, a few raspberry pi's, and a SFF PC we use to run Kodi on the main TV.

I do find it amusing in a thread about how you have to turn off a core security feature to be able to use containers properly on a Mac that the discussion immediately turns to how bad Linux sound drivers supposedly are. Honestly, I went in the other direction (Mac to Linux) and I've found the waters to be just fine. I don't know if I just have the magic touch or something, but ¯\_(ツ)_/¯.

Haha now that you mention it touch (trackpad) absolutely sucks on Linux when I last tried it - I couldn't even get palm rejection to work.

But this isn't bashing on linux desktop (I would use it if Mac wasn't an option) as much as giving a reason why people would use MacOS despite being annoyed by SIP.

Tell us what distro you recommend?

> In my experience, this has not been an issue for the past 10-15 years atleast. Before that there were some problems with few (external) soundcards or random cpu spikes with the mixers.

May be some confusion. To run linux on a newer Mac with "Apple Silicon" (ARM based), you need to go through a lot of hoops and much work needs to be done still for a stable environment. Check out https://asahilinux.org/about/

Or maybe you thought they meant running linux in general on a PC (Intel x86 32/64 bit)? In that case I agree - driver issues like that have been mostly ironed out by now.

I'm getting early PulseAudio vibes with PipeWire though. BT audio devices stuttering and sometimes losing audio completely regardless of output devices unless I restart the daemon. I guess it stabilizes again during next few years.

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 of that, setting my $DAYJOB VPN took three minutes and it just works, where on Linux I had constant problems with DNS breaking, and setting it up was always an hour of work, praying I got the config files right this time.

It really seems to be "unixy desktop with working sound", the best of both worlds.

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.

You can just install a recent bash with homebrew and use that as your terminal.

Karabiner and applescripts can get you pretty far

Homebrew has GNU utils to smooth over the differences in package options.

  [0] https://formulae.brew.sh/formula/coreutils
  [1] https://apple.stackexchange.com/questions/69223/how-to-replace-mac-os-x-utilities-with-gnu-core-utilities

The sound is an internal meme where the linux devops would regularly have to drop off calls to talk (restart to unmute :)).

On my desktop I couldn't even boot installer without running with safe mode, otherwise I'd just get stuck on a blank screen (ancient 1050 TI GPU and standard desktop components otherwise, so not exotic/new stuff).

I've used linux desktop for >decade and Gnome shell feels like home but these days I feel like I don't have the time for linux adventures. Maybe I'll mix it up with my next device, but I'm not reading great things about AMD power modes and Linux.

> The sound is an internal meme where the linux devops would regularly have to drop off calls to talk (restart to unmute :)).

Hmmm once every full moon MS Teams running on ungoogled chrome do not seem to realize my Bose BT Headset is paired and available (and in that case I just use the internal soundcard) but I have seen people having sound issues on MS teams and needing to reboot regardless of the OS they were using. Windows, Linux, even some MacOS users so I wouldn't use that as a generalization.

I'm running Linux everyday and I really wouldn't recommend it for any serious audio stuff.

There is great audio software coming to Linux (Bitwig, Reaper, etc) which is great but the underlying infrastructure is a mess.

There are like 3-4 audio subsystems running, I never know which one is it, setting latency is wizardry and sometimes it doesn't run at all. It's usually fine when I run stuff like Spotify, VLC, or Youtube in Firefox, so for user-level audio, Linux is fine IMO. But when I run something where I care about latency and multichannel output, it's hit or miss. It runs fine one day and then I get no sound on another or distorted sound or sound playing at wrong speed and wrong pitch (yay, 44,1 vs 48).

Maybe it's the distros I'm using, maybe there are some that work better, but the UX isn't as great as with macOS. On Manjaro, update sometimes get audio notification removed from tray and I can't change volume using mouse or dedicated keys. Then I have to look for few hours for a solution only to have the same thing happen again three months later (same with brightness keys on laptop). On Ubuntu Studio with an external soundcard, I get randomly distorted sound or no sound at all. So it's easier to use some shitty onboard sound, great.

I like Linux, I use Linux daily, but sound on Linux is terrible. It's much better than it was, yes, but still terrible. For anything more than "play a song here", macOS is much better.

It sounds like your specifically fighting your distros problem, or something that its not your understanding.

I would not consider Linux sound Terrible, but to be fair, I only use it every day for regular development tasks for the last 10 years. Maybe I've become accustomed to whatever problem you see that I don't.

Fedora Silverblue with Pipewire will just use a single subsystem and that's it. Inmutable OS and the rest of software it's Flatpak. The issues are gone. Oh, you need a proper devel environment with dnf/rpm? Just use "toolbox enter" and install all the complex envs under that container.

> homebrew is pretty great

I hear this said a lot in passing, and I'm really curious what people mean when they say this.

Perhaps they are talking about Homebrew the package manager [1].

[1] https://brew.sh

I wonder what people mean when they say "Homebrew is pretty great", I do not wonder what they mean when they say "Homebrew".

They mean that they have an overall positive opinion of Homebrew, more than “not bad” but less than “amazing”.

As someone who would readily say that Homebrew is pretty great, this is exactly how I feel about Homebrew.

It does what it says on the tin and installs the plethora of software available on homebrew with a simple command, which is pretty great

For example people do not use homebrew to install python3 on a fresh install of mac os and get a python that spews a bunch of messages to stderr about the version of libc6.so and cannot speak TLS.

It only upgrades PostgreSQL 3 major versions up alongside without asking.

Think this issue was fixed a few years ago

Not sure I agree, when I use brew it still regularly updates random unconnected crap through multiple major releases. And of course it takes ages doing so

I was referring to your postgresql example, those became rudimentary @versioned packages

It's plenty solid, and there's a good library of packages on there. It's a package manager, doesn't take more than that.

I mean, it installs stuff more or less reliably for me so I’d say that’s pretty great. I’m sure it has issues (I’ve had problems trying to install old versions of packages for example) but I don’t think I’ve ever had “brew install <whatever>” fail to install what I wanted

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 doing something relatively popular there will be a lot of noise when stuff breaks. Linux is spread out across various distros/repos/package managers, overlap of users with your problem is a lot smaller.

Beats all the package management experiences I've had on Windows, admittedly I have not tried to use Windows for work for >1 year.

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

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

Neither have I. My main complaint is that it's slow.

The comment was in response to parent's stated complaint, namely having to wait for someone else to resolve issues with popular packages being broken after an update, which has been the experience of more than one user.

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

If you need to build something from source (my use-case: Vim, so I can change which language bindings exist in the resulting build) it can sometimes be a lot easier than cloning and using the "raw" C/Make build system.

Also, assuming a downstream distro like Debian or Ubuntu, what's in Homebrew is likely a more up to date package. You could fiddle with adding/using Debian testing or some PPA, or... you could just use Homebrew.

(FWIW: I use Arch and the AUR on my desktop Linux installs these days, and it's essentially the same process. But still using Homebrew on the Mac, and occasionally in Linux when I'm not on a desktop)

The experience is really seamless, mostly it just works… which IMO is nothing special as they mostly support installing the latest and maybe a couple of other versions, and software that requires weird stuff will likely be packaged in a self contained way.

They mean they haven’t tried another package manager for Mac, like pkgsrc or macports.

I switched to it after using both Fink and macports and it was the first time I felt like I had a package manager as reliable to apt on Linux. Both Macports and Fink would routinely break my whole system by putting extra versions of system libraries where other applications could find them. Since, I’ve switched to nix.

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 anyway. the performance improvement was totally worth it, i won't even talk about the heating issue with intel.

> 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?

Building a single-page LaTeX document as a PDF can be done in less than 0.3s when the environment is set up correctly. I don't know anything about this particular container.

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

This is a fair point. For folks who want a “just works” Unix system, disabling SIP probably makes sense. But most it’s still very niche.

Is there a way to make a separate partition of MacOS and have one copy with SIP and one without?

> But most it’s still very niche.

I'd say that the whole containerization topic is niche

> Is there a way to make a separate partition of MacOS and have one copy with SIP and one without?

I think you can install macOS VM on your macOS host and disable SIP _inside VM_.

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.

No, I’ll give it a look, thanks for the tip.

Work gives me a laptop, I use it. I'd prefer Linux, but that's not what I get.

No, the hardware drivers are very polished and never give any problems. And the hardware itself is beautiful but I suspect wouldn't integrate as well with the OS if it were running Linux.

SIP on consumer laptops/desktops is security theater. It only really makes sense on web-servers. For people for whom this is a deal breaker, can you describe a concrete scenario where SIP would actually protect you?

SIP protects you from an app accidentally rendering your system unbootable, for example.

> Wouldn't a Linux device, or Linux running on a Mac suit you better?

No? Maybe you're preferring Mac OS for getting stuff done, exchange work with the outside world and/or use non-historic software (like any commercial desktop app such as idk Photoshop, Sketch, Audio, 3D, CAD s/w, etc., etc.) and still are a developer?

Or even doing something esoteric such as using office software without wanting to throw your notebook out of the window?

Only way to properly develop iOS apps, I'm afraid.

Connecting to a Mac Agent with Visual Studio on Windows gave me nothing but headaches.

The hardware is what's good in Macs, with Apple Silicon, not the software, which I use begrudgingly.

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

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.

I ran desktop Linux (Manjaro) for years in an enterprise job with certified hardware, as a Linux sysadmin. I regularly had issues and spent 5-10% of my time troubleshooting the OS or a janky application.

Conversely, macOS is broadly 'production grade'. It mostly 'just works' (with a number of tweaks - including SIP -, hacks etc on initial config, most power users automate with dotfiles). It has a drastically better UI, first class terminals and unixy support, and most code built for it has a higher level of shine.

I am confident enough to deploy alternate security implementations for the convenience of full FS control, as I know many power users are. Disabling SIP is a bad idea for those who don't understand it, the same as disabling Windows Defender or forwarding NAT on your router.

Bizarre

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

Apple Pay rocks, it has saved me a few times when I forgot my wallet. And it’s faster to use than pulling out my wallet.

I use it whenever I can, whether on laptop or mobile.

I don't know whether it is popular everywhere, but it is certainly popular everywhere I go (anywhere in the US, and western Europe). I absolutely love it.

You can forward Apple Pay requests to your other devices.

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.

Then you don't know how to use it.

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

Oh wow… please do not do that folks!

I disable SIP because I don't want to use an OS where I cannot debug programs which did not consent to be debugged. macOS makes it impossible to inspect failure states I encounter in normal usage (like I can on Linux with debuginfod enabled, or Windows with .pdb files) without first rebuilding the program in debug mode.

Surely you can do this with xattr?

I’ve never had problems debugging anything with SIP on.

My experience is that I was unable to debug Maestral (a Python program) crashing in native Cocoa bindings in LLDB, because the interpreter did not allow itself to be debugged. Mozilla says Firefox acts the same way at https://firefox-source-docs.mozilla.org/contributing/debuggi.... It's possible there's some workaround I'm not aware of, but I ended up disabling SIP just like every non-macOS computer I own.

Were you debugging a local install of python, or the default python installed as a part of the OS?

If the latter, it's definitely a footgun but you shouldn't be using it for applications. It's a legacy binary for scripts.

You can't debug system processes or anything with the hardened runtime enabled.

Sincerely, why is this your recommendation? What does this protect against and why do you consider it a concern?

Help doc: https://support.apple.com/en-us/102149#:~:text=System%20Inte....

TLDR: it restricts even the root user from modifying system files. Like the ones that would otherwise be the target of malware.

I understand that of course, I'm much more curious why you think this is a concern for people, and/or why you consider this an effective protection against said unknown actors.

I want that feature on cause I dont want stuff I dont know about looking and changing stuff I dont know about, whether it's running with escalated privileges or not

I doubt you (or any human) is capable of enumerating what you don't want looked at. Frankly, I doubt most of this unknown area is covered by SIP at all, and it would be extremely odd if it did. Perhaps you might consider arguing for actual permissions rather than arbitrarily walling off the OS in a way that tangentially benefits the monopoly Apple holds over their own computers.

Wouldn't it be far easier to enumerate what you want an app to access?

SIP means not messing with the system files, enumerated thusly: /System.

Enumerating what I do want an app to access is handled by Gatekeeper.

It's actually a larger list available in /System/Library/Sandbox/rootless.conf

> SIP means not messing with the system files, enumerated thusly: /System.

...and all its children, which is effectively the entire operating system

> Enumerating what I do want an app to access is handled by Gatekeeper.

Gatekeeper is not capable of this.

It's among the things Gatekeeper does, isn't it? As configured with PPPC?

Why would it be running with escalated privileges if you don't know what it is ?

I feel like you're assuming that applications have to be honest about what they are when they request a user-prompted permission. SIP makes that irrelevant.

No, I'm assuming that you know what you install and that apps run with the same rights your user has. Your user can't touch /System, so shouldn't the app

https://eclecticlight.co/2019/06/19/what-is-sip-and-when-is-...

It’s a core part of how macOS is prevents unauthorised modifications to the operating system and file system by malicious software.

I always disable SIP on every Mac I own. It's not very useful and I can run whatever I want on my hardware.

I hope that's sarcasm.

https://support.apple.com/en-us/102149 https://support.apple.com/guide/security/system-integrity-pr...

Why would it be sarcasm? If I am root and want to write to /bin or /System, I should be able to, even if it might be dangerous. I get why Apple does it for normal consumers but for people who know what they're doing, it should be available, which it is by disabling it.

I'm sure they'll overcome this! Rootless containers are a thing after all!

> Disable System Identity [sic] Protection.

Aaand, it's stillborn. Not happening.

Denial is not a river in Egypt.

Hopefully if Darwin containers take off and produce an ecosystem of containers this could pressure Apple to implement process namespacing in Darwin in a SIP compatible way.

Wouldn't recommend this to people prone to identity crises

Reply on news.ycombinator.com