7 ms·

As someone working in developer tools for a company with thousands of people developing software on MacBooks, MAN do I resent SIP. I've recently started calling

by burke 2y ago

As someone working in developer tools for a company with thousands of people developing software on MacBooks, MAN do I resent SIP. I've recently started calling it "Systems Implementation Prevention". It's incredible that it's 2024 and I can't cobble together anything vaguely container-like on macOS because: * bind mounts don't exist (?!) * clonefile() could maaaybe do the job but doesn't work cross-volume and a lot of the stuff outside of /Users is a different volume * there's no filesystem namespace. * chroot doesn't work either because /usr/lib/libsystem.B.dylib is required, but also pretend. * And it sounds like chroot runs afoul of some SIP rule nowadays even if you can get past the above. * A lot of this could be worked around with FUSE, but in order to turn that on, we'd have to turn off a lot of SIP. The closest we can get without virtualization is sandbox-exec, which just allows allowing/denying file reads by path, with no path translation. And also is deprecated. Nevermind that dtrace exists but you're not allowed to use it either. Truly, the worst UNIX.

m463 2y ago
> Truly, the worst UNIX. You're not the target market. :(
- Vilian 2y ago
  It's still the worse unix, if the target market don't care don't change that fact
- talldayo 2y ago
  If the Xserve's legacy is anything to go by, neither are UNIX customers.
ChocolateGod 2y ago
> * A lot of this could be worked around with FUSE, but in order to turn that on, we'd have to turn off a lot of SIP. Didn't the latest MacOS update add something similar with userspace filesystems
- burke 2y ago
  File Provider: https://developer.apple.com/documentation/fileprovider/ https://developer.apple.com/documentation/fileprovider/ Interesting, I hadn't heard of this. First impression skimming the docs is that they've gone to significant trouble to make it not generically useful as a FUSE replacement but I could be misreading.
- mbirth 2y ago
  Not macOS directly, but there’s fuse-t which works in userspace and just creates an NFS server which it automatically mounts via macOS-own capabilities. The library is a drop-in replacement for libfuse and works great for me. https://www.fuse-t.org https://www.fuse-t.org
jsolson 2y ago
Why do you want to avoid virtualization?
- burke 2y ago
  It's very heavyweight, and there's no good shared filesystem option. We did use virtualization for a bunch of stuff before the move to Apple Silicon, back when Hypervisor.framework and xhyve actually existed and were plausibly useful. Those also fell by the wayside in the architecture migration and now virtualization has a massive performance cost. Apparently the M4 chips are on ARMv9 which is apparently much better at virtualization, but it remains to be seen whether apple provides anything lightweight again.
  - darklion 2y ago
    Uh, Hypervisor still exists, and is still supported: https://developer.apple.com/documentation/hypervisor https://developer.apple.com/documentation/hypervisor
    - burke 2y ago
      Yep. However, before the Apple Silicon migration, VT-x gave us extremely low-overhead virtualization. We built a tiny linux kernel that booted in a second or two and were able to run whatever we wanted with minimal perf overhead. In the Apple Silicon migration, obviously emulating x86_64 got slow, but even when we built ARM64 VMs, performance was still miserable: there was (is?) no way -- at least no way we ever figured out -- to get reasonable perf out of virtualization on a macbook. It's possible that this changed post-M1 and it sounds likely it's set to change with M4. EDIT: ok, I'm probably hallucinating more problem than there actually turned out to be based on the pain in the first year of the M1 chips.
      - inkyoto 2y ago
        If you are referring to the nested virtualisation support in ARM v8, it was added in the ARM v8.3-A revision of the architecture, and M1 uses ARM v8.5-A as the baseline. But yes, virtualisaiton support for ARM (in general) was abysmal and Apple Silicon was the catalyst that pushed people over the edge towards improving it across aarch64 (also in general).
viraptor 2y ago
> Nevermind that dtrace exists but you're not allowed to use it either. You're not losing anything, dtrace even without SIP has been broken and unusable for at least 2 major versions now.
- pxc 2y ago
  What's broken in dtrace even with SIP disabled?

by burke 2y ago

m463 2y ago

> Truly, the worst UNIX. You're not the target market. :(

Vilian 2y ago
It's still the worse unix, if the target market don't care don't change that fact
talldayo 2y ago
If the Xserve's legacy is anything to go by, neither are UNIX customers.

ChocolateGod 2y ago

> * A lot of this could be worked around with FUSE, but in order to turn that on, we'd have to turn off a lot of SIP. Didn't the latest MacOS update add something similar with userspace filesystems

burke 2y ago
File Provider: https://developer.apple.com/documentation/fileprovider/ https://developer.apple.com/documentation/fileprovider/ Interesting, I hadn't heard of this. First impression skimming the docs is that they've gone to significant trouble to make it not generically useful as a FUSE replacement but I could be misreading.
mbirth 2y ago
Not macOS directly, but there’s fuse-t which works in userspace and just creates an NFS server which it automatically mounts via macOS-own capabilities. The library is a drop-in replacement for libfuse and works great for me. https://www.fuse-t.org https://www.fuse-t.org

jsolson 2y ago

Why do you want to avoid virtualization?

burke 2y ago
It's very heavyweight, and there's no good shared filesystem option. We did use virtualization for a bunch of stuff before the move to Apple Silicon, back when Hypervisor.framework and xhyve actually existed and were plausibly useful. Those also fell by the wayside in the architecture migration and now virtualization has a massive performance cost. Apparently the M4 chips are on ARMv9 which is apparently much better at virtualization, but it remains to be seen whether apple provides anything lightweight again.
- darklion 2y ago
  Uh, Hypervisor still exists, and is still supported: https://developer.apple.com/documentation/hypervisor https://developer.apple.com/documentation/hypervisor
  - burke 2y ago
    Yep. However, before the Apple Silicon migration, VT-x gave us extremely low-overhead virtualization. We built a tiny linux kernel that booted in a second or two and were able to run whatever we wanted with minimal perf overhead. In the Apple Silicon migration, obviously emulating x86_64 got slow, but even when we built ARM64 VMs, performance was still miserable: there was (is?) no way -- at least no way we ever figured out -- to get reasonable perf out of virtualization on a macbook. It's possible that this changed post-M1 and it sounds likely it's set to change with M4. EDIT: ok, I'm probably hallucinating more problem than there actually turned out to be based on the pain in the first year of the M1 chips.
    - inkyoto 2y ago
      If you are referring to the nested virtualisation support in ARM v8, it was added in the ARM v8.3-A revision of the architecture, and M1 uses ARM v8.5-A as the baseline. But yes, virtualisaiton support for ARM (in general) was abysmal and Apple Silicon was the catalyst that pushed people over the edge towards improving it across aarch64 (also in general).

viraptor 2y ago

> Nevermind that dtrace exists but you're not allowed to use it either. You're not losing anything, dtrace even without SIP has been broken and unusable for at least 2 major versions now.

pxc 2y ago
What's broken in dtrace even with SIP disabled?