3 ms·

> why do you want this in MacOS? I have a small rackmounted rendering farm using mac minis, which outperform everything in the Intel world, even order of magni

> why do you want this in MacOS? I have a small rackmounted rendering farm using mac minis, which outperform everything in the Intel world, even order of magnitude more expensive. I run macOS on my personal and development computers for over a decade and I use Linux since inception on server side. My experience: running server-side macOS is such a PITA it's not even funny. It may even pretend it has ssh while in fact the ssh server is only available on good days and only after Remote Desktop logged in at least once. Launchd makes you wanna crave systemd. etc, etc. So, about docker. I would absolutely love to run my app in a containerized environment on a Mac in order to not touch the main OS.

mannyv 2y ago
Funny, I ran a bunch of Mac minis in colo for over a decade with no problems. Maybe you have a config problem? Of course, I had a LOM/KVM and redundant networking etc. They were substantially more reliable than the Dell equipment that I used in my day job for sure.
- egorfine 2y ago
  Hardware-wise I have exactly zero complaints. Software-wise it's much different to an expected behavior. For example, macOS won't let you in over SSH until you log in via Remote Desktop. You'll get "connection closed" immediately. Or sometimes it will. And that depends not on the count of connection attempts or anything you can do locally but rather on the boot process somehow. Sometimes it boots in a way that permits ssh, sometimes not. The same computer, the same OS. Then after you login on screen sharing and log out, macOS will let you in over ssh. For a few days. And then again will force you to login via GUI. Or maybe not. I have no idea what makes it. I have trouble reading macOS logs or understanding it. It spews a few log messages per second even idle. If you grep ssh these messages contain zero actionable data, like "unsuccessful attempt" or similar. Another complaint is that launchd reports the same "I/O error" on absolutely all error situations, from syntax error in plist to corrupt binary. Makes development and debugging of launchagents very fun.
  - rafram 2y ago
    https://support.apple.com/lt-lt/guide/mac-help/mchlp1066/mac https://support.apple.com/lt-lt/guide/mac-help/mchlp1066/mac
    - egorfine 2y ago
      Seriously?
duped 2y ago
What would a containerization environment on MacOS give you that you don't already have? Like concretely - what does containerization mean in the context of a MacOS user space? In Linux, it means something very specific: a user/mount/pid/network namespace, overlayfs to provide a rootfs, chroot to pivot to the new root to do your work, and port forwarding between the host/guest systems. On MacOS I don't know what containerization means short of virtualization. But you have virtualization on MacOS already, so why not use that?
- egorfine 2y ago
  On macOS probably I'd like chroot and pid/mount namespaces. I'd like to install OS and dependencies in a container and run my application from there so that it does not interfere with host OS. My app is GPU heavy and has lots of dependencies (OpenCV, LAPACK, armadillo, lots and lots) and I'd like to not pollute the host OS with it. Also I want to run the latest OS with all security patches on the host while having a stable and known macOS version in a container given how developer-hostile Apple is.
  - duped 2y ago
    What you want is virtualization, not containerization. And you have this already. Since MacOS doesn't have a stable syscall interface, decoupling the host/guest in a mount namespace and chroot would lead to horrible breakages when the system libraries of your container are out of date with your host OS. So you would have to share the host OS and a big portion of the userspace to begin with. Or you can package your app as a .app and not worry about it, there's no "pollution" when everything is bundled.
    - egorfine 2y ago
      Yeah, seems like on macOS that level of isolation is achievable solely with virtualization unlike in Linux. We were talking about missing things in macOS and containerization is one of them.

mannyv 2y ago

Funny, I ran a bunch of Mac minis in colo for over a decade with no problems. Maybe you have a config problem? Of course, I had a LOM/KVM and redundant networking etc. They were substantially more reliable than the Dell equipment that I used in my day job for sure.

egorfine 2y ago
Hardware-wise I have exactly zero complaints. Software-wise it's much different to an expected behavior. For example, macOS won't let you in over SSH until you log in via Remote Desktop. You'll get "connection closed" immediately. Or sometimes it will. And that depends not on the count of connection attempts or anything you can do locally but rather on the boot process somehow. Sometimes it boots in a way that permits ssh, sometimes not. The same computer, the same OS. Then after you login on screen sharing and log out, macOS will let you in over ssh. For a few days. And then again will force you to login via GUI. Or maybe not. I have no idea what makes it. I have trouble reading macOS logs or understanding it. It spews a few log messages per second even idle. If you grep ssh these messages contain zero actionable data, like "unsuccessful attempt" or similar. Another complaint is that launchd reports the same "I/O error" on absolutely all error situations, from syntax error in plist to corrupt binary. Makes development and debugging of launchagents very fun.
- rafram 2y ago
  https://support.apple.com/lt-lt/guide/mac-help/mchlp1066/mac https://support.apple.com/lt-lt/guide/mac-help/mchlp1066/mac
  - egorfine 2y ago
    Seriously?

duped 2y ago

What would a containerization environment on MacOS give you that you don't already have? Like concretely - what does containerization mean in the context of a MacOS user space? In Linux, it means something very specific: a user/mount/pid/network namespace, overlayfs to provide a rootfs, chroot to pivot to the new root to do your work, and port forwarding between the host/guest systems. On MacOS I don't know what containerization means short of virtualization. But you have virtualization on MacOS already, so why not use that?

egorfine 2y ago
On macOS probably I'd like chroot and pid/mount namespaces. I'd like to install OS and dependencies in a container and run my application from there so that it does not interfere with host OS. My app is GPU heavy and has lots of dependencies (OpenCV, LAPACK, armadillo, lots and lots) and I'd like to not pollute the host OS with it. Also I want to run the latest OS with all security patches on the host while having a stable and known macOS version in a container given how developer-hostile Apple is.
- duped 2y ago
  What you want is virtualization, not containerization. And you have this already. Since MacOS doesn't have a stable syscall interface, decoupling the host/guest in a mount namespace and chroot would lead to horrible breakages when the system libraries of your container are out of date with your host OS. So you would have to share the host OS and a big portion of the userspace to begin with. Or you can package your app as a .app and not worry about it, there's no "pollution" when everything is bundled.
  - egorfine 2y ago
    Yeah, seems like on macOS that level of isolation is achievable solely with virtualization unlike in Linux. We were talking about missing things in macOS and containerization is one of them.