12 ms·

macOS Containers v0.0.1

518 points by CiTyBear 3y ago

xcdzvyn 3y ago
TIL SIP blocks chroot. I wonder why?
- Hnrobert42 3y ago
  I imagine because if an adversary can a chroot environment, then they can trick anything using that chroot to use different binaries.
  - highwaylights 3y ago
    I have these thoughts about Homebrew also. macOS apps have to be signed and notarised to run without a warning, which is a pretty big part of the defence picture for this software - the certificates can be revoked at any time to block the software if malicious behaviour is identified. However, if I install Homebrew, then install python, then install a pip package, there's really no kind of scanning/notarization/checking happening at all. I wonder if this is something Apple has ever looked into - it seems like the exact scenario where you'd want to sandbox it away from the rest of the system.
    - vetinari 3y ago
      > However, if I install Homebrew, then install python, then install a pip package, there's really no kind of scanning/notarization/checking happening at all. There is: you are running that pip package in a chain of processes: Terminal (or iTerm, or whatever) - your shell - python - pip package. In this chain, Terminal has "Developer Tools" privilege, which allows you to run software, that does not meet the system's security policy. You can disable this privilege in System settings, Privacy and Security panel.
      - slonopotamus 3y ago
        Yeah, but we need to analyze picture as a whole. And by default, chroot is banned while running as root arbitrary stuff downloaded from the internets is not.
        vetinari 3y ago
        Only in terminal and only if you have developer tools installed. Otherwise, it is not.
      - highwaylights 3y ago
        EDIT: Having looked at this again, I'm not sure the Developer Tools privilege is even required to run essentially arbitrary software in Terminal. Homebrew still works without Developer Tools installed, as do interpreted runtimes. If I can even run an arbitrary shell script then the privilege is pointless, which makes the case for a dedicated sandbox for Terminal even more important. This is my point, Terminal with Developer Tools privilege is essentially granting carte blanche privilege to every sub-process running there, which is not really necessary. If I could pop a Terminal with a restrictive scope, allowing read and write access only within that directory tree it would be a much better situation than we have now. macOS' permission system isn't really that far away anyway - I can already disable Terminal's permissions to access anything else same as other apps. Essentially a basic and very limited not-even-a-chroot would be a vast improvement and would still offer an adequate sandbox.
  - duped 3y ago
    That's indeed the point of chroot. It's a feature not a bug.
skibz 3y ago
System Integrity Protection sounds really important. What does it do normally, and why does this tool require it to be disabled?
- bzzzt 3y ago
  It's meant to protect the base OS from persistent malware infections. https://support.apple.com/en-us/102149 https://support.apple.com/en-us/102149
  - astrange 3y ago
    Also against accidentally deleting /usr.
- highwaylights 3y ago
  SIP is secure boot for macOS. It's intended to prevent malware from changing system files due to rogue permissions or escalation. With SIP enabled, even the root/sudo user doesn't have rights to change these files. It also refuses to boot a system with drivers that are not signed by Apple, so as to deter malware from using drivers as an attack vector. https://en.wikipedia.org/wiki/System_Integrity_Protection https://en.wikipedia.org/wiki/System_Integrity_Protection
  - abujazar 3y ago
    > SIP is secure boot for macOS. Not really. «Secure Boot» is intended to secure the boot process through signature verification. However the security model is completely broken, https://arstechnica.com/information-technology/2023/03/unkillable-uefi-malware-bypassing-secure-boot-enabled-by-unpatchable-windows-flaw/amp/ https://arstechnica.com/information-technology/2023/03/unkil... SIP is a protection layer which protects system files from modification also after the system is booted.
    - saagarjha 3y ago
      Apple ships a non-broken secure boot, unlike almost everyone else.
minipark 3y ago
Why should anyone trust this website and download the software? There's no indication who made it. Could be malware for all I know.
- Squarex 3y ago
  Looks like it's open source https://github.com/macOScontainers https://github.com/macOScontainers
  - ThePowerOfFuet 3y ago
    Unfortunately, that doesn't answer their question.
    - RockRobotRock 3y ago
      It answers both of their questions. Git lets you see the author and they can audit the code if they like.
      - dangus 3y ago
        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.
    - puquesnrn 3y ago
      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
AceJohnny2 3y ago
How does this work? Fundamentally, containers are about namespace/isolation of a bunch of OS interfaces, so file system functions, network functions, memory management, process functions, etc, can all pretend like they're the only game in town, but crucially without having to virtualize out the kernel. Does XNU have such namespacing functionality across all its interfaces? Furthermore, the existing container ecosystem assumes a Linux syscall interface. [1]. Does macOS provide that? I expect not. The way Docker Desktop (and podman.io) implement "containers on macOS" is a bit of a cop-out: they actually run a Linux virtual machine (using Hypervisor.framework/hvf), and have that just provide the container environment. Is that what this project is doing? But then, how could it run a macOS container? [1] based on the foundation that Linux, unlike BSDs, has a stable syscall interface!
- deleted 3y ago
  [deleted]
- robertlagrant 3y ago
  The transitively linked docs have some answers: rund is an experimental containerd shim for running macOS containers on macOS. rund doesn’t offer the usual level of container isolation that is achievable on other OSes due to limited macOS kernel API. What rund provides: - Filesystem isolation via chroot(2) - Cleanup of container processes using process group - OCI Runtime Specification compatibility (to the extent it is possible on macOS) - Host-network mode only - bind mounts
  - znpy 3y ago
    So essentially a chroot with a bit of make-up and a lot of marketing? Except for bind mounts (not even overlayfs...) there isn't much interesting. > - Host-network mode only Yeah expect a lot of things to break in subtle ways... most containers are developed kinda expecting you have your own network namespace (and that no one else is using ports)
    - lloeki 3y ago
      overlayfs and bind mounts are orthogonal: - bind mounting solves the exposition of filesystem within the root pivot. - overlayfs solves the persistence efficiency issue using a layered union fs. > most containers are developed Most Linux (and Windows) containers. Since these are macOS containers there are no containers developed yet so by definition there is nothing to break.
highwaylights 3y ago
https://github.com/macOScontainers/homebrew-formula https://github.com/macOScontainers/homebrew-formula "macOS native containers" Cool, this sounds interesting. "Disable System Identity Protection." Eesh.
- comandillos 3y ago
  That's what it takes to implement container-ish technology on macOS. Hopefully one day Darwin will get real namespaces as Linux does.
- dddnzzz334 3y ago
  [flagged]
  - cassianoleal 3y ago
    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.
    - lopkeny12ko 3y ago
      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.
      - doctor_eval 3y ago
        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.
_joel 3y ago
Sorry, not disabling SIP for something that I can already do without needing to nobble security policies (and have them reset/impossible due to MDM). If there was user/networking space in Darwin then maybe I'd be interested but...
- lloeki 3y ago
  > something that I can already do I would be very curious as to how you already run darwin containers. The only alternative is spinning a macOS VM (including relying on macOS CI machines as a remote job executor)
  - _joel 3y ago
    I mean in terms of functionality, this doesn't give me anything extra to what using docker would do on macos (granted it's via a linux based VM). From an end user perspective there's no real difference, but I don't have to entirely disable SIP just to use it. Something like namespaces or proper jails on darwin would be super cool, but not at the expense of other security measures and chroot-ish outcome imho. Maybe this works for some, but not me :)
    - slonopotamus 3y ago
      > this doesn't give me anything extra to what using docker would do on macos You're missing the point. This project DOES use docker.
      - _joel 3y ago
        I mean docker machine/desktop (kinda implicit of running docker on macos) not the cli or anything :)
    - lloeki 3y ago
      > I mean in terms of functionality, this doesn't give me anything extra to what using docker would do on macos (granted it's via a linux based VM) Ah, I understand your angel, in that your use case is to run namespaced processes that achieve some functional purpose irrespective of the underlying kernel/platform, which is totally fair. > not at the expense of other security measures Not for me either... that is, not in a host OS, maybe a dedicated VM; I consider this to be as it says on the tin, 0.0.1, a thing that would help bootstrap an ecosystem of containers, which would push towards Apple adding namespaces or jails (oh, hell yeah, JailKit!) to darwin.
xena 3y ago
This is amazingly cursed and I'd love to see this become viable
keepamovin 3y ago
Can anyone speak to how the macOS runners on GitHub actions work? It would seem from this post that containers of any kind for macOS are a brand new thing..
- mawalu 3y ago
  AFAIK GitHub action runners all use VMs and not containers
  - slonopotamus 3y ago
    Yes, they are VMs
    - keepamovin 3y ago
      I'm probably getting confused between containers and VMs but, sorry, I don't understand what the difference is in the case of MacOS?
      - slonopotamus 3y ago
        It is the same for any OS. Virtual machine boots a separate instance of the whole OS. This is slow, this is often too much isolated (you can't easily/effectively share files between host and guest), you need to set artificial limits on VM disk/memory/cpu. On the other side, containers work in the context of host OS, what means less overhead and easier interaction with host.
        keepamovin 3y ago
        I see! Thank you! :)
RockRobotRock 3y ago
Despite the SIP problem, this is really exciting.
prmoustache 3y ago
caveat: this is based on rund. Extract from the readme: rund is an experimental containerd shim for running macOS containers on macOS. rund doesn’t offer the usual level of container isolation that is achievable on other OSes due to limited macOS kernel API. What rund provides: Filesystem isolation via chroot(2) Cleanup of container processes using process group OCI Runtime Specification compatibility (to the extent it is possible on macOS) Host-network mode only bind mounts
- blablabla123 3y ago
  I wonder if something comparable can be achieved with ptrace. I've tried to experiment with that but the API seems a bit unclear to say the least
dingi 3y ago
Can anybody explain, what's the point of Mac containers? Almost nobody uses Mac for container based deployments.
- dvdplm 3y ago
  CI/CD workflows most likely. And devshops that have standadised on docker containers for their stacks (mac-based devs in such places suffer a fair amount of papercuts today). Then I guess there are people that are very security minded that might want to run all userland executables in containers (although this project here is not for them I'd say).
  - slonopotamus 3y ago
    > CI/CD workflows most likely Yep, this is primary goal of this project.
- shepherdjerred 3y ago
  At work, this would've been super helpful for compiling macOS libraries. We ended up using a macOS cross-compiler [0] instead. [0]: https://github.com/shepherdjerred/macos-cross-compiler https://github.com/shepherdjerred/macos-cross-compiler
da39a3ee 3y ago
I use MacOS and am very positive about it. I have lots of reasons to run Linux containers. What are some reasons I might want to run a MacOS container?
- nicexe 3y ago
  I would imagine it would enable you to run MacOS specific pipelines like building a project and have it work semi-portably across different machines/users.
  - da39a3ee 3y ago
    Yes, I can see it could be useful for a company making MacOS software. But for a company whose developers use MacOS but whose product has nothing specifically to do with MacOS, my instinct is that if local environment reproducibility concerns get to that point then linux containers are the answer since they'll be more closely related to CI/prod envs. Or are you thinking maybe that's wrong for large companies with lots of developers using MacOS?
- shepherdjerred 3y ago
  At work, this would've been super helpful for compiling macOS libraries. We ended up using a macOS cross-compiler [0] instead. [0]: https://github.com/shepherdjerred/macos-cross-compiler https://github.com/shepherdjerred/macos-cross-compiler
figmert 3y ago
It's sad to see so many negative comments for this. I get it's not an ideal place to start for macOS containers, but it's a start. Apple isn't doing it, so the community has to. Once you have a start, you can iterate on it. It might not be great now, but hopefully this makes it possible in a year or so. Who knows, maybe this is the kick Apple needs, and maybe they'll hire the devs of this project to fully work on this.
- deleted 3y ago
  [deleted]
baq 3y ago
cries in Asahi Linux macbook is the best laptop there is but macos... can't wait for a stable release of Asahi and permission from corporate to install it even in a VM somehow. probably won't happen, but one can dream.
- deleted 3y ago
  [deleted]
- _joel 3y ago
  You're missing the point of Asahi, by the looks of it. It's not intended to be run in a VM.
  - baq 3y ago
    I mean, I won't be allowed to install it side by side on my work laptop in a million years. GPU acceleration would be nice in a VM if macOS can pass it through, which I've no idea if it can.
    - _joel 3y ago
      It's not really intended to be run as a standalone distro (there's a fedora version though) and (afaiu) the point is to understand the bootloader process and stuff like GPU support from linux. I know company policy moves glacially with these things (been there, got the faded t-shirt!) so yea, you're probably right there. Technically you could probably still use linux MDM instead of MacOS for mgmt, but getting that past IT is nigh on impossible imho also.
  - ok123456 3y ago
    As long as the architecture satisfies Popeck and Goldberg, why shouldn't it?
    - xmodem 3y ago
      The point of Asahi is to provide linux drivers for Apple hardware. What would be the point? You can already run Linux in a VM on arm macOS today with good performances. You don't even need to disable SIP.
icar 3y ago
I hope their software quality is better than what the page looks like in a small form factor.
donatj 3y ago
What's the licensing situation on this? Would I be distributing parts of macOS in my containers? I don't think Apple is OK with that. Or is this just the fully open source Darwin core? That wouldn't likely be super compatible with a ton of production software? I need more explanation of what is actually going on here because it sounds like a good way to get sued.
- lloeki 3y ago
  > 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=macos-jail https://github.com/orgs/macOScontainers/packages?repo_name=m... Edit: There's a note here†, so at least there is some consideration for licensing. No idea if it holds ground. † https://github.com/macOScontainers/macos-jail/blob/9b1d5b141091c795887b35dd0289d3fe363dd631/README.md#macos-jail https://github.com/macOScontainers/macos-jail/blob/9b1d5b141...
  - donatj 3y ago
    Counting the hours until this gets DMCA'd out of existence
    - lloeki 3y ago
      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 https://app.vagrantup.com/jhcook/boxes/macos-sierra
    - notnmeyer 3y ago
      folks have been building macos vm images, sharing them, and virtualizing macos on macos for a decade or so now. is this that much different?
sourabhv 3y ago
This uses macfuse, a closed source software
- speedgoose 3y ago
  I think MacOs is also closed source.
tambourine_man 3y ago
It’s remarkable that Apple doesn’t have a first party solution to this yet. They used be, or aspire to be, at the forefront of OS research.“The most advanced Unix”. They’re not even trying, now.
- deleted 3y ago
  [deleted]
- pjmlp 3y ago
  A/UX wasn't that much advanced, and most technology interesting stuff in NeXTSTEP, and OS X, is completely unrelated to UNIX.
  - tambourine_man 3y ago
    Off the top of my head: launchd inspired systemd. Spotlight (real time indexing and notification) is something I miss in Linux today. 64bit Unix layer on consumer hardware (G5). All of that stuff was not a first ever implementation, of course, but it was well executed and led the way. All of that was more than a decade ago.
    - tambourine_man 3y ago
      You may argue that Quartz inspired Wayland, but I wouldn’t be so sure, maybe that was just obvious given the hardware of today.
      - pjmlp 3y ago
        Non UNIX display technology inspired Wayland. Amiga, Atari, BeOS, OS/2, Windows, classical Mac OS,...
    - pjmlp 3y ago
      All of that appeared first in HP-UX, Solaris and Aix. Xenix and Coherent were the first UNIX on consumer hardware.
amelius 3y ago
Can I run them on a normal PC with Linux?
- slonopotamus 3y ago
  No. For the same reason you cannot run Windows containers on Linux. You need a working macOS kernel.
bryanlarsen 3y ago
For a Docker-like OCI experience on MacOS without disabling SIP, check out TartVM. Happy user here.
crabbone 3y ago
Unrelated to containers themselves: how do you make a patch when no version was released? I mean, people call this "semantic" versioning, but then spit in the face of those semantics...
- joshgachnang 3y ago
  0.1.0 might make more sense, but still not completely (backwards compatible with what?). Then again, it doesn't really matter. It's not like someone's going to accidentally install 0.0.1 because of semantic versioning not being 100% correct.
- timcobb 3y ago
  Version 0?
  - crabbone 3y ago
    I believe at least some semantic version parsers would not accept version zero. I'd need to find the definition though. I could be wrong of course.
  - crabbone 3y ago
    Oh, it was easier than I thought: https://semver.org/#spec-item-2 https://semver.org/#spec-item-2 A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0. So, no leading zeros, ta-da! Oh, wait. The spec was written by some... big brain: Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable. So... my reading of this "definition" is that there's really no need for three digits, if major is zero... Then why on earth would you have two digits? Also, if no pubic API at this point, then why have versions at all? I mean, you clearly shouldn't be specifying anything with zero major version as a dependency because it should be illegal to depend on a library w/o public API... Then, again, why have versions in this situation? And if the argument is that its for internal use, then why standardize it for external use? Just two paragraphs below. How lovely.
therealmarv 3y ago
Reminds me: Still waiting for native ARM support on GitHub Actions https://github.com/actions/runner-images/issues/5631 https://github.com/actions/runner-images/issues/5631
- thtmnisamnstr 3y ago
  This one is ridiculous. This should already exist. Until GitHub builds it, you can use GitHub Actions to kick your builds off but run them remotely on Earthly Cloud (https://earthly.dev/ https://earthly.dev/). Even the free tier includes arm64 remote runners. Note: I work at Earthly, but I'm not wrong about this being a good, free, arm64-native workflow for GitHub Actions.
  - slonopotamus 3y ago
    You mean, Earthly has macOS arm64 runners? I am failing to find any info on its website.
  - cdaringe 3y ago
    Isn’t that service shutting down in <1 week?
    - adamgordonbell 3y ago
      We shut down CI. Earthly satellites are still going strong.
- fkorotkov 3y ago
  There are Cirrus Runners which is a service of managed GitHub Actions Runners powered by M2 chips. But there is no free option for OSS yet. https://tart.run/integrations/github-actions https://tart.run/integrations/github-actions
xyst 3y ago
7G images, wow
- slonopotamus 3y ago
  I believe that could be optimized in the future. At least, by splitting amd64/arm64 code.
MuffinFlavored 3y ago
https://github.com/macOScontainers/macos-jail https://github.com/macOScontainers/macos-jail - new code https://github.com/macOScontainers/rund https://github.com/macOScontainers/rund - new code https://github.com/macOScontainers/moby https://github.com/macOScontainers/moby - fork, 6 commits https://github.com/macOScontainers/buildkit https://github.com/macOScontainers/buildkit - fork, 4 commits https://github.com/macOScontainers/containerd https://github.com/macOScontainers/containerd - fork, 5 commits Would be interesting to see if they can get moby/buildkit/containerd changes upstreamed
- slonopotamus 3y ago
  This is a failed attempt to upstream part of containerd changes: https://github.com/containerd/containerd/pull/8789 https://github.com/containerd/containerd/pull/8789 Other part of containerd changes waits for gods-know-what: https://github.com/containerd/containerd/pull/9054 https://github.com/containerd/containerd/pull/9054 But I haven't gave up yet.
  - AkihiroSuda 3y ago
    Just merged #9054. Sorry for that we had to revert #8789, but we are looking forward to seeing that PR submitted again with an alternative abstraction interface.
    - slonopotamus 3y ago
      Yeah, I undestand the situation with #8789.
- slonopotamus 3y ago
  If you want to follow my upstream attempts, subscribe to https://github.com/moby/buildkit/pull/4059 https://github.com/moby/buildkit/pull/4059 https://github.com/moby/moby/pull/46558 https://github.com/moby/moby/pull/46558
mavili 3y ago
When macOS runs on Unix kernel and Linux systems are the best supported for containerisation and I assume are much more lightweight than macOS, I personally don't see any reason to run macOS in a container.
- jayd16 3y ago
  You would do it so you can run mac software in a container.
  - mavili 3y ago
    I think I get that part :) but realistically if anyone wants to run macOS software they are most likely macOS users already. Whereas containerisation is useful to aid with development and deployment. Have you come across anyone who runs production software on macOS? :)
    - slonopotamus 3y ago
      One might develop a game that by some kind of a miracle releases for macOS too. So they way to run CI tests on macOS. Or they might target iOS. And use macOS build machines to produce builds. The world is not only about web, you know?
duped 3y ago
I can't help but feel like this is an X/Y problem. Apps on MacOS shouldn't need containerization to function. I get the point of isolation for build/test situations. But Apple provides a neat virtualization framework, and you get security + isolation + reproducibility + decent performance. It seems like if you feel the need to containerize the userspace on MacOS you're using MacOS wrong. It's not the same thing as the Linux userspace, and doesn't have the same kernel features that would let you do so cleanly or performantly. Orbstack is moving mountains to provide Linux-native perf and support for containers and it still makes me beg the question: why are devs allergic to just using Linux natively? At least I understand why Orbstack is useful, I don't know why containerizing MacOS itself is.
- WesolyKubeczek 3y ago
  > But Apple provides a neat virtualization framework, and you get security + isolation + reproducibility + decent performance. You also get limits on how many VMs your machine can run, each VM needs gobs of storage and locked-out RAM blocks, and sharing directories between the host and guest, compared to bind mounts, is something that makes me remember for my root canal dental jobs wistfully.
  - duped 3y ago
    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 sandbox.
    - WesolyKubeczek 3y ago
      > reasonably fast. But still not "as fast as it gets". And I want it to be as fast as it gets.
      - 3y ago
WesolyKubeczek 3y ago
What my dream is that the User Mode Linux is made into a cross-platform userspace binary that translates syscalls transparently between itself and the host. So you might get "drivers" that talk to Windows, Linux, *BSDs, Darwin, it manages memory in an efficient (for the host) way, and enables you to run any kinds of wild experiments with, say, virtualized and passed-through serial devices, USB devices, networking, bind-mounting from the host and image mounts. And yes, containers. All of that without needing host root in most cases. Of course the drawback would be that the host would see just a fat Linux process and its child processes, much like you can see qemu, but it could be an interesting thing nonetheless, if even for shits and giggles of it.
daft_pink 3y ago
I feel cheated by Apple a little bit. I bought an Apple Silicon machine after their presentation claiming that they would have first class docker support, but the reality has been that while the first docker worked well as it was translated, now it wants to default to arm containers and it has become very difficult to use because it doesn't want to use Rosetta 2 containers. The whole point of using docker is to use the same containers in production as you use in development, so having docker default to these random arm containers means that my containers aren't exactly production, because they are arm based and the servers are not. I understand that docker is the developer of docker software, but I really wish I could just click a button and force intel based containers in docker as the default and have to opt-in to arm. If anyone has an easy solution to this let me know. I don't want to spend hours and hours figuring out docker on my mac.
- dmeijboom 3y ago
  Try OrbStack ;) It’s the only docker daemon alternative for Mac that makes working with docker acceptable.
  - daft_pink 3y ago
    Thanks! I'll check it out.
  - Bnjoroge 3y ago
    +1 on Orbstack! def been a huge difference from the desktop client, and supports K8s too
- cdaringe 3y ago
  export DOCKER_DEFAULT_PLATFORM=linux/amd64
beders 3y ago
MacOS is - by choice - an Apple controlled walled garden. Trying to break out of that is an exercise in futility. Can you come up with situations where I would run a container instead of just running an app or sys service?
ravenstine 3y ago
This is a cool idea and an impressive project. At the same time, I don't truly understand why anyone would need to use it. If your preference is to totally work with macOS, then I'm sure this would be perfect for that. Otherwise, what's the advantage? VMs have really come a long way. Every major OS today has a virtualization framework that makes running another OS extremely performant. Docker on macOS uses a virtual machine, but so what? Performance of individual containers, in my experience, isn't really a problem unless you're doing something with the GPU, and even then there are ways to deal with that. Even a fully-emulated VM using QEMU (without hypervisor or KVM) won't have any noticeable performance penalties in many cases. IMO, there's a much greater advantage to sticking with Linux. Even if the host isn't Linux, developing and deploying with Linux guests provides a tremendous level of consistency and portability. But maybe I'll be proven wrong by this project someday soon!
nathants 3y ago
the amount of engineering hours wasted making macos usable for backend dev work and then wasted again from inefficiency due to that failure is staggering. linux is great. macos is great. windows is great too. for their intended purposes. it’s horseless carriages all the way down.

518 points by CiTyBear 3y ago

xcdzvyn 3y ago

TIL SIP blocks chroot. I wonder why?

Hnrobert42 3y ago
I imagine because if an adversary can a chroot environment, then they can trick anything using that chroot to use different binaries.
- highwaylights 3y ago
  I have these thoughts about Homebrew also. macOS apps have to be signed and notarised to run without a warning, which is a pretty big part of the defence picture for this software - the certificates can be revoked at any time to block the software if malicious behaviour is identified. However, if I install Homebrew, then install python, then install a pip package, there's really no kind of scanning/notarization/checking happening at all. I wonder if this is something Apple has ever looked into - it seems like the exact scenario where you'd want to sandbox it away from the rest of the system.
  - vetinari 3y ago
    > However, if I install Homebrew, then install python, then install a pip package, there's really no kind of scanning/notarization/checking happening at all. There is: you are running that pip package in a chain of processes: Terminal (or iTerm, or whatever) - your shell - python - pip package. In this chain, Terminal has "Developer Tools" privilege, which allows you to run software, that does not meet the system's security policy. You can disable this privilege in System settings, Privacy and Security panel.
    - slonopotamus 3y ago
      Yeah, but we need to analyze picture as a whole. And by default, chroot is banned while running as root arbitrary stuff downloaded from the internets is not.
      - vetinari 3y ago
        Only in terminal and only if you have developer tools installed. Otherwise, it is not.
    - highwaylights 3y ago
      EDIT: Having looked at this again, I'm not sure the Developer Tools privilege is even required to run essentially arbitrary software in Terminal. Homebrew still works without Developer Tools installed, as do interpreted runtimes. If I can even run an arbitrary shell script then the privilege is pointless, which makes the case for a dedicated sandbox for Terminal even more important. This is my point, Terminal with Developer Tools privilege is essentially granting carte blanche privilege to every sub-process running there, which is not really necessary. If I could pop a Terminal with a restrictive scope, allowing read and write access only within that directory tree it would be a much better situation than we have now. macOS' permission system isn't really that far away anyway - I can already disable Terminal's permissions to access anything else same as other apps. Essentially a basic and very limited not-even-a-chroot would be a vast improvement and would still offer an adequate sandbox.
- duped 3y ago
  That's indeed the point of chroot. It's a feature not a bug.

skibz 3y ago

System Integrity Protection sounds really important. What does it do normally, and why does this tool require it to be disabled?

bzzzt 3y ago
It's meant to protect the base OS from persistent malware infections. https://support.apple.com/en-us/102149 https://support.apple.com/en-us/102149
- astrange 3y ago
  Also against accidentally deleting /usr.
highwaylights 3y ago
SIP is secure boot for macOS. It's intended to prevent malware from changing system files due to rogue permissions or escalation. With SIP enabled, even the root/sudo user doesn't have rights to change these files. It also refuses to boot a system with drivers that are not signed by Apple, so as to deter malware from using drivers as an attack vector. https://en.wikipedia.org/wiki/System_Integrity_Protection https://en.wikipedia.org/wiki/System_Integrity_Protection
- abujazar 3y ago
  > SIP is secure boot for macOS. Not really. «Secure Boot» is intended to secure the boot process through signature verification. However the security model is completely broken, https://arstechnica.com/information-technology/2023/03/unkillable-uefi-malware-bypassing-secure-boot-enabled-by-unpatchable-windows-flaw/amp/ https://arstechnica.com/information-technology/2023/03/unkil... SIP is a protection layer which protects system files from modification also after the system is booted.
  - saagarjha 3y ago
    Apple ships a non-broken secure boot, unlike almost everyone else.

minipark 3y ago

Why should anyone trust this website and download the software? There's no indication who made it. Could be malware for all I know.

Squarex 3y ago
Looks like it's open source https://github.com/macOScontainers https://github.com/macOScontainers
- ThePowerOfFuet 3y ago
  Unfortunately, that doesn't answer their question.
  - RockRobotRock 3y ago
    It answers both of their questions. Git lets you see the author and they can audit the code if they like.
    - dangus 3y ago
      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.
  - puquesnrn 3y ago
    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

AceJohnny2 3y ago

How does this work? Fundamentally, containers are about namespace/isolation of a bunch of OS interfaces, so file system functions, network functions, memory management, process functions, etc, can all pretend like they're the only game in town, but crucially without having to virtualize out the kernel. Does XNU have such namespacing functionality across all its interfaces? Furthermore, the existing container ecosystem assumes a Linux syscall interface. [1]. Does macOS provide that? I expect not. The way Docker Desktop (and podman.io) implement "containers on macOS" is a bit of a cop-out: they actually run a Linux virtual machine (using Hypervisor.framework/hvf), and have that just provide the container environment. Is that what this project is doing? But then, how could it run a macOS container? [1] based on the foundation that Linux, unlike BSDs, has a stable syscall interface!

deleted 3y ago
[deleted]
robertlagrant 3y ago
The transitively linked docs have some answers: rund is an experimental containerd shim for running macOS containers on macOS. rund doesn’t offer the usual level of container isolation that is achievable on other OSes due to limited macOS kernel API. What rund provides: - Filesystem isolation via chroot(2) - Cleanup of container processes using process group - OCI Runtime Specification compatibility (to the extent it is possible on macOS) - Host-network mode only - bind mounts
- znpy 3y ago
  So essentially a chroot with a bit of make-up and a lot of marketing? Except for bind mounts (not even overlayfs...) there isn't much interesting. > - Host-network mode only Yeah expect a lot of things to break in subtle ways... most containers are developed kinda expecting you have your own network namespace (and that no one else is using ports)
  - lloeki 3y ago
    overlayfs and bind mounts are orthogonal: - bind mounting solves the exposition of filesystem within the root pivot. - overlayfs solves the persistence efficiency issue using a layered union fs. > most containers are developed Most Linux (and Windows) containers. Since these are macOS containers there are no containers developed yet so by definition there is nothing to break.

highwaylights 3y ago

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

comandillos 3y ago
That's what it takes to implement container-ish technology on macOS. Hopefully one day Darwin will get real namespaces as Linux does.
dddnzzz334 3y ago
[flagged]
- cassianoleal 3y ago
  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.
  - lopkeny12ko 3y ago
    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.
    - doctor_eval 3y ago
      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.

_joel 3y ago

Sorry, not disabling SIP for something that I can already do without needing to nobble security policies (and have them reset/impossible due to MDM). If there was user/networking space in Darwin then maybe I'd be interested but...

lloeki 3y ago
> something that I can already do I would be very curious as to how you already run darwin containers. The only alternative is spinning a macOS VM (including relying on macOS CI machines as a remote job executor)
- _joel 3y ago
  I mean in terms of functionality, this doesn't give me anything extra to what using docker would do on macos (granted it's via a linux based VM). From an end user perspective there's no real difference, but I don't have to entirely disable SIP just to use it. Something like namespaces or proper jails on darwin would be super cool, but not at the expense of other security measures and chroot-ish outcome imho. Maybe this works for some, but not me :)
  - slonopotamus 3y ago
    > this doesn't give me anything extra to what using docker would do on macos You're missing the point. This project DOES use docker.
    - _joel 3y ago
      I mean docker machine/desktop (kinda implicit of running docker on macos) not the cli or anything :)
  - lloeki 3y ago
    > I mean in terms of functionality, this doesn't give me anything extra to what using docker would do on macos (granted it's via a linux based VM) Ah, I understand your angel, in that your use case is to run namespaced processes that achieve some functional purpose irrespective of the underlying kernel/platform, which is totally fair. > not at the expense of other security measures Not for me either... that is, not in a host OS, maybe a dedicated VM; I consider this to be as it says on the tin, 0.0.1, a thing that would help bootstrap an ecosystem of containers, which would push towards Apple adding namespaces or jails (oh, hell yeah, JailKit!) to darwin.

xena 3y ago

This is amazingly cursed and I'd love to see this become viable

keepamovin 3y ago

Can anyone speak to how the macOS runners on GitHub actions work? It would seem from this post that containers of any kind for macOS are a brand new thing..

mawalu 3y ago
AFAIK GitHub action runners all use VMs and not containers
- slonopotamus 3y ago
  Yes, they are VMs
  - keepamovin 3y ago
    I'm probably getting confused between containers and VMs but, sorry, I don't understand what the difference is in the case of MacOS?
    - slonopotamus 3y ago
      It is the same for any OS. Virtual machine boots a separate instance of the whole OS. This is slow, this is often too much isolated (you can't easily/effectively share files between host and guest), you need to set artificial limits on VM disk/memory/cpu. On the other side, containers work in the context of host OS, what means less overhead and easier interaction with host.
      - keepamovin 3y ago
        I see! Thank you! :)

RockRobotRock 3y ago

Despite the SIP problem, this is really exciting.

prmoustache 3y ago

caveat: this is based on rund. Extract from the readme: rund is an experimental containerd shim for running macOS containers on macOS. rund doesn’t offer the usual level of container isolation that is achievable on other OSes due to limited macOS kernel API. What rund provides: Filesystem isolation via chroot(2) Cleanup of container processes using process group OCI Runtime Specification compatibility (to the extent it is possible on macOS) Host-network mode only bind mounts

blablabla123 3y ago
I wonder if something comparable can be achieved with ptrace. I've tried to experiment with that but the API seems a bit unclear to say the least

dingi 3y ago

Can anybody explain, what's the point of Mac containers? Almost nobody uses Mac for container based deployments.

dvdplm 3y ago
CI/CD workflows most likely. And devshops that have standadised on docker containers for their stacks (mac-based devs in such places suffer a fair amount of papercuts today). Then I guess there are people that are very security minded that might want to run all userland executables in containers (although this project here is not for them I'd say).
- slonopotamus 3y ago
  > CI/CD workflows most likely Yep, this is primary goal of this project.
shepherdjerred 3y ago
At work, this would've been super helpful for compiling macOS libraries. We ended up using a macOS cross-compiler [0] instead. [0]: https://github.com/shepherdjerred/macos-cross-compiler https://github.com/shepherdjerred/macos-cross-compiler

da39a3ee 3y ago

I use MacOS and am very positive about it. I have lots of reasons to run Linux containers. What are some reasons I might want to run a MacOS container?

nicexe 3y ago
I would imagine it would enable you to run MacOS specific pipelines like building a project and have it work semi-portably across different machines/users.
- da39a3ee 3y ago
  Yes, I can see it could be useful for a company making MacOS software. But for a company whose developers use MacOS but whose product has nothing specifically to do with MacOS, my instinct is that if local environment reproducibility concerns get to that point then linux containers are the answer since they'll be more closely related to CI/prod envs. Or are you thinking maybe that's wrong for large companies with lots of developers using MacOS?
shepherdjerred 3y ago
At work, this would've been super helpful for compiling macOS libraries. We ended up using a macOS cross-compiler [0] instead. [0]: https://github.com/shepherdjerred/macos-cross-compiler https://github.com/shepherdjerred/macos-cross-compiler

figmert 3y ago

It's sad to see so many negative comments for this. I get it's not an ideal place to start for macOS containers, but it's a start. Apple isn't doing it, so the community has to. Once you have a start, you can iterate on it. It might not be great now, but hopefully this makes it possible in a year or so. Who knows, maybe this is the kick Apple needs, and maybe they'll hire the devs of this project to fully work on this.

deleted 3y ago
[deleted]

baq 3y ago

cries in Asahi Linux macbook is the best laptop there is but macos... can't wait for a stable release of Asahi and permission from corporate to install it even in a VM somehow. probably won't happen, but one can dream.

deleted 3y ago
[deleted]
_joel 3y ago
You're missing the point of Asahi, by the looks of it. It's not intended to be run in a VM.
- baq 3y ago
  I mean, I won't be allowed to install it side by side on my work laptop in a million years. GPU acceleration would be nice in a VM if macOS can pass it through, which I've no idea if it can.
  - _joel 3y ago
    It's not really intended to be run as a standalone distro (there's a fedora version though) and (afaiu) the point is to understand the bootloader process and stuff like GPU support from linux. I know company policy moves glacially with these things (been there, got the faded t-shirt!) so yea, you're probably right there. Technically you could probably still use linux MDM instead of MacOS for mgmt, but getting that past IT is nigh on impossible imho also.
- ok123456 3y ago
  As long as the architecture satisfies Popeck and Goldberg, why shouldn't it?
  - xmodem 3y ago
    The point of Asahi is to provide linux drivers for Apple hardware. What would be the point? You can already run Linux in a VM on arm macOS today with good performances. You don't even need to disable SIP.

icar 3y ago

I hope their software quality is better than what the page looks like in a small form factor.

donatj 3y ago

What's the licensing situation on this? Would I be distributing parts of macOS in my containers? I don't think Apple is OK with that. Or is this just the fully open source Darwin core? That wouldn't likely be super compatible with a ton of production software? I need more explanation of what is actually going on here because it sounds like a good way to get sued.

lloeki 3y ago
> 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=macos-jail https://github.com/orgs/macOScontainers/packages?repo_name=m... Edit: There's a note here†, so at least there is some consideration for licensing. No idea if it holds ground. † https://github.com/macOScontainers/macos-jail/blob/9b1d5b141091c795887b35dd0289d3fe363dd631/README.md#macos-jail https://github.com/macOScontainers/macos-jail/blob/9b1d5b141...
- donatj 3y ago
  Counting the hours until this gets DMCA'd out of existence
  - lloeki 3y ago
    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 https://app.vagrantup.com/jhcook/boxes/macos-sierra
  - notnmeyer 3y ago
    folks have been building macos vm images, sharing them, and virtualizing macos on macos for a decade or so now. is this that much different?

sourabhv 3y ago

This uses macfuse, a closed source software

speedgoose 3y ago
I think MacOs is also closed source.

tambourine_man 3y ago

It’s remarkable that Apple doesn’t have a first party solution to this yet. They used be, or aspire to be, at the forefront of OS research.“The most advanced Unix”. They’re not even trying, now.

deleted 3y ago
[deleted]
pjmlp 3y ago
A/UX wasn't that much advanced, and most technology interesting stuff in NeXTSTEP, and OS X, is completely unrelated to UNIX.
- tambourine_man 3y ago
  Off the top of my head: launchd inspired systemd. Spotlight (real time indexing and notification) is something I miss in Linux today. 64bit Unix layer on consumer hardware (G5). All of that stuff was not a first ever implementation, of course, but it was well executed and led the way. All of that was more than a decade ago.
  - tambourine_man 3y ago
    You may argue that Quartz inspired Wayland, but I wouldn’t be so sure, maybe that was just obvious given the hardware of today.
    - pjmlp 3y ago
      Non UNIX display technology inspired Wayland. Amiga, Atari, BeOS, OS/2, Windows, classical Mac OS,...
  - pjmlp 3y ago
    All of that appeared first in HP-UX, Solaris and Aix. Xenix and Coherent were the first UNIX on consumer hardware.

amelius 3y ago

Can I run them on a normal PC with Linux?

slonopotamus 3y ago
No. For the same reason you cannot run Windows containers on Linux. You need a working macOS kernel.

bryanlarsen 3y ago

For a Docker-like OCI experience on MacOS without disabling SIP, check out TartVM. Happy user here.

crabbone 3y ago

Unrelated to containers themselves: how do you make a patch when no version was released? I mean, people call this "semantic" versioning, but then spit in the face of those semantics...

joshgachnang 3y ago
0.1.0 might make more sense, but still not completely (backwards compatible with what?). Then again, it doesn't really matter. It's not like someone's going to accidentally install 0.0.1 because of semantic versioning not being 100% correct.
timcobb 3y ago
Version 0?
- crabbone 3y ago
  I believe at least some semantic version parsers would not accept version zero. I'd need to find the definition though. I could be wrong of course.
- crabbone 3y ago
  Oh, it was easier than I thought: https://semver.org/#spec-item-2 https://semver.org/#spec-item-2 A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0. So, no leading zeros, ta-da! Oh, wait. The spec was written by some... big brain: Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable. So... my reading of this "definition" is that there's really no need for three digits, if major is zero... Then why on earth would you have two digits? Also, if no pubic API at this point, then why have versions at all? I mean, you clearly shouldn't be specifying anything with zero major version as a dependency because it should be illegal to depend on a library w/o public API... Then, again, why have versions in this situation? And if the argument is that its for internal use, then why standardize it for external use? Just two paragraphs below. How lovely.

therealmarv 3y ago

Reminds me: Still waiting for native ARM support on GitHub Actions https://github.com/actions/runner-images/issues/5631 https://github.com/actions/runner-images/issues/5631

thtmnisamnstr 3y ago
This one is ridiculous. This should already exist. Until GitHub builds it, you can use GitHub Actions to kick your builds off but run them remotely on Earthly Cloud (https://earthly.dev/ https://earthly.dev/). Even the free tier includes arm64 remote runners. Note: I work at Earthly, but I'm not wrong about this being a good, free, arm64-native workflow for GitHub Actions.
- slonopotamus 3y ago
  You mean, Earthly has macOS arm64 runners? I am failing to find any info on its website.
- cdaringe 3y ago
  Isn’t that service shutting down in <1 week?
  - adamgordonbell 3y ago
    We shut down CI. Earthly satellites are still going strong.
fkorotkov 3y ago
There are Cirrus Runners which is a service of managed GitHub Actions Runners powered by M2 chips. But there is no free option for OSS yet. https://tart.run/integrations/github-actions https://tart.run/integrations/github-actions

xyst 3y ago

7G images, wow

slonopotamus 3y ago
I believe that could be optimized in the future. At least, by splitting amd64/arm64 code.

MuffinFlavored 3y ago

https://github.com/macOScontainers/macos-jail https://github.com/macOScontainers/macos-jail - new code https://github.com/macOScontainers/rund https://github.com/macOScontainers/rund - new code https://github.com/macOScontainers/moby https://github.com/macOScontainers/moby - fork, 6 commits https://github.com/macOScontainers/buildkit https://github.com/macOScontainers/buildkit - fork, 4 commits https://github.com/macOScontainers/containerd https://github.com/macOScontainers/containerd - fork, 5 commits Would be interesting to see if they can get moby/buildkit/containerd changes upstreamed

slonopotamus 3y ago
This is a failed attempt to upstream part of containerd changes: https://github.com/containerd/containerd/pull/8789 https://github.com/containerd/containerd/pull/8789 Other part of containerd changes waits for gods-know-what: https://github.com/containerd/containerd/pull/9054 https://github.com/containerd/containerd/pull/9054 But I haven't gave up yet.
- AkihiroSuda 3y ago
  Just merged #9054. Sorry for that we had to revert #8789, but we are looking forward to seeing that PR submitted again with an alternative abstraction interface.
  - slonopotamus 3y ago
    Yeah, I undestand the situation with #8789.
slonopotamus 3y ago
If you want to follow my upstream attempts, subscribe to https://github.com/moby/buildkit/pull/4059 https://github.com/moby/buildkit/pull/4059 https://github.com/moby/moby/pull/46558 https://github.com/moby/moby/pull/46558

mavili 3y ago

When macOS runs on Unix kernel and Linux systems are the best supported for containerisation and I assume are much more lightweight than macOS, I personally don't see any reason to run macOS in a container.

jayd16 3y ago
You would do it so you can run mac software in a container.
- mavili 3y ago
  I think I get that part :) but realistically if anyone wants to run macOS software they are most likely macOS users already. Whereas containerisation is useful to aid with development and deployment. Have you come across anyone who runs production software on macOS? :)
  - slonopotamus 3y ago
    One might develop a game that by some kind of a miracle releases for macOS too. So they way to run CI tests on macOS. Or they might target iOS. And use macOS build machines to produce builds. The world is not only about web, you know?

duped 3y ago

I can't help but feel like this is an X/Y problem. Apps on MacOS shouldn't need containerization to function. I get the point of isolation for build/test situations. But Apple provides a neat virtualization framework, and you get security + isolation + reproducibility + decent performance. It seems like if you feel the need to containerize the userspace on MacOS you're using MacOS wrong. It's not the same thing as the Linux userspace, and doesn't have the same kernel features that would let you do so cleanly or performantly. Orbstack is moving mountains to provide Linux-native perf and support for containers and it still makes me beg the question: why are devs allergic to just using Linux natively? At least I understand why Orbstack is useful, I don't know why containerizing MacOS itself is.

WesolyKubeczek 3y ago
> But Apple provides a neat virtualization framework, and you get security + isolation + reproducibility + decent performance. You also get limits on how many VMs your machine can run, each VM needs gobs of storage and locked-out RAM blocks, and sharing directories between the host and guest, compared to bind mounts, is something that makes me remember for my root canal dental jobs wistfully.
- duped 3y ago
  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 sandbox.
  - WesolyKubeczek 3y ago
    > reasonably fast. But still not "as fast as it gets". And I want it to be as fast as it gets.
    - 3y ago

WesolyKubeczek 3y ago

What my dream is that the User Mode Linux is made into a cross-platform userspace binary that translates syscalls transparently between itself and the host. So you might get "drivers" that talk to Windows, Linux, *BSDs, Darwin, it manages memory in an efficient (for the host) way, and enables you to run any kinds of wild experiments with, say, virtualized and passed-through serial devices, USB devices, networking, bind-mounting from the host and image mounts. And yes, containers. All of that without needing host root in most cases. Of course the drawback would be that the host would see just a fat Linux process and its child processes, much like you can see qemu, but it could be an interesting thing nonetheless, if even for shits and giggles of it.

daft_pink 3y ago

I feel cheated by Apple a little bit. I bought an Apple Silicon machine after their presentation claiming that they would have first class docker support, but the reality has been that while the first docker worked well as it was translated, now it wants to default to arm containers and it has become very difficult to use because it doesn't want to use Rosetta 2 containers. The whole point of using docker is to use the same containers in production as you use in development, so having docker default to these random arm containers means that my containers aren't exactly production, because they are arm based and the servers are not. I understand that docker is the developer of docker software, but I really wish I could just click a button and force intel based containers in docker as the default and have to opt-in to arm. If anyone has an easy solution to this let me know. I don't want to spend hours and hours figuring out docker on my mac.

dmeijboom 3y ago
Try OrbStack ;) It’s the only docker daemon alternative for Mac that makes working with docker acceptable.
- daft_pink 3y ago
  Thanks! I'll check it out.
- Bnjoroge 3y ago
  +1 on Orbstack! def been a huge difference from the desktop client, and supports K8s too
cdaringe 3y ago
export DOCKER_DEFAULT_PLATFORM=linux/amd64

beders 3y ago

MacOS is - by choice - an Apple controlled walled garden. Trying to break out of that is an exercise in futility. Can you come up with situations where I would run a container instead of just running an app or sys service?

ravenstine 3y ago

This is a cool idea and an impressive project. At the same time, I don't truly understand why anyone would need to use it. If your preference is to totally work with macOS, then I'm sure this would be perfect for that. Otherwise, what's the advantage? VMs have really come a long way. Every major OS today has a virtualization framework that makes running another OS extremely performant. Docker on macOS uses a virtual machine, but so what? Performance of individual containers, in my experience, isn't really a problem unless you're doing something with the GPU, and even then there are ways to deal with that. Even a fully-emulated VM using QEMU (without hypervisor or KVM) won't have any noticeable performance penalties in many cases. IMO, there's a much greater advantage to sticking with Linux. Even if the host isn't Linux, developing and deploying with Linux guests provides a tremendous level of consistency and portability. But maybe I'll be proven wrong by this project someday soon!

nathants 3y ago

the amount of engineering hours wasted making macos usable for backend dev work and then wasted again from inefficiency due to that failure is staggering. linux is great. macos is great. windows is great too. for their intended purposes. it’s horseless carriages all the way down.