16 ms·

Containerization is a Swift package for running Linux containers on macOS

• rvz 1y ago
  Requires an Apple Silicon Mac to run. > You need an Apple silicon Mac to build and run Containerization. > To build the Containerization package, your system needs either: > macOS 15 or newer and Xcode 26 Beta > macOS 26 Beta 1 or newer Those on Intel Macs, this is your last chance to switch to Apple Silicon, (Sequoia was the second last)[0] as macOS Tahoe is the last version to support Intel Macs. [0] https://news.ycombinator.com/item?id=41560423 https://news.ycombinator.com/item?id=41560423
  • keysdev 1y ago
    Any linux or bsd that has goodhardwawe support for intel mac?
    • bjackman 1y ago
      For the older ones with Broadcom WiFi I was able to get stock Ubuntu working great by following this: https://askubuntu.com/questions/55868/installing-broadcom-wireless-drivers https://askubuntu.com/questions/55868/installing-broadcom-wi... Not sure about the newer ones. Gathering this information and putting together a distro to rescue old Macbooks from the e-waste bin would be a worthwhile project. As far as I can tell they're great hardware. I imagine things get harder once you get into the USB-C era.
      • monkey_monkey 1y ago
        This site is very useful for getting Linux on more recent Intel Macs - I was able to get Ubuntu running on a 2018 MBA https://t2linux.org/ https://t2linux.org/
  • haiku2077 1y ago
    Also, there are some really amazing deals on used/refurb M2 Macs out there. ~$700 for a Macbook Air is a pretty great value, if you can live with 16GB of RAM and a okay but not amazing screen.
    • socalgal2 1y ago
      a 30% discount for a 3 yr old machine is good? A new one is $999.
      • DrBenCarson 1y ago
        When the 3yo machine does 100% of what you need without missing a beat and has 8h screen-on battery life, yes, yes, it is
    • nicoburns 1y ago
      Even better deals on M1s which aren't much slower than M2s
    • paxys 1y ago
      $450 for a M4 Mac mini (at Microcenter, but Best Buy will price match) is possibly the best computer hardware deal out there. It is an incredible machine.
      • xp84 1y ago
        Having run a Mac Mini with a 256GB internal drive for 2-3 years I will dispute that anyone should buy base models for that reason. MacOS makes it as painful as possible for you to use external drives. For instance, no software for "cloud" drives (google drive, onedrive, icloud drive) is allowed to locate its local copy on an "External" drive, so you can't keep your files locally and in the cloud, have to pick one. Photos can have its library moved at least. I like the hardware, hate the absurd greedy storage and RAM prices.
        • paxys 1y ago
          AI FOMO at least made them bump the base RAM to 16GB. 256GB is pitiful but manageable if you don't need to handle large files. And jumping up to $800 just for another 256GB is absolutely not worth it.
          • 1y ago
  • pjmlp 1y ago
    That was officially communicated at the state of the union session.
• newman314 1y ago
  I wonder how this will affect apps like Orbstack
  • SparkyMcUnicorn 1y ago
    My guess is that Orbstack might switch to using this, and it'll just be a more competitive space with better open source options popping up. People still want the nice UI/UX, and this is just a Swift package.
    • jbverschoor 1y ago
      Orbstack also does kubernetes etc
  • 9dev 1y ago
    Huh. I suppose it’s a good thing I never came around to migrating our team from docker desktop to Orbstack, even though it seems like they pioneered a lot of the Apple implementation perks…
    • xp84 1y ago
      I still haven't heard why anyone would prefer the new Apple-proprietary thing vs Orbstack. I would not hold my breath on it being better.
      • zshrc 1y ago
        Wild because "Apple proprietary" is on GitHub and Orbstack is closed source but go off I guess.
        • xp84 1y ago
          You got me. It was super inaccurate to use "proprietary" here (though if i understand correctly, podman is another option that is FOSS). License aside, though, I would still bet that relying on the Apple-specific version of something like this will cause headaches for teams unless you're operating in an environment that's all-in on Apple. Like, your CI tooling in the cloud runs on a Mac, that degree of vendor loyalty. I've never seen any shop like that. Plus when this tooling does have interoperability bugs, I do not trust Apple to prioritize or even notice the needs of people like me, and they're the ones in charge of the releases.
• rfoo 1y ago
  This does not support memory ballooning yet. But they have documented custom kernel support, so, goodbye OrbStack.
  • worldsavior 1y ago
    Orbstack is docker. People might still prefer docker.
  • deleted 1y ago
    [deleted]
• outcoldman 1y ago
  Not sure what exactly is happening, but feels very slow. Builds are taking way longer. Tried to run builder with -c and -m to add more CPU and memory.
  • tibbar 1y ago
    What setup are you comparing this to? In the past silicon Macs plus, say, Rancher Desktop have been happy to pretend to build an x86 image for me, but those images have generally not actually worked for me on actual x86 hardware.
    • outcoldman 1y ago
      Comparing to Docker for Mac. Running on MBA M2. Building a 5GB image (packaging enterprise software). Docker for Mac builds it in 4 minutes. container tool... 17 minutes. Maybe even more. And I did set the cpu and memory for the builder as well to higher number than defaults (similar what Docker for Mac is set for). And in reality it is not the build stage, but "=> exporting to oci image format" that takes forever. Running containers - have not seen any issues yet.
• candiddevmike 1y ago
  Wonder how Docker feels about this. I'd assume a decent amount of Docker for Desktop is on Mac...
  • paxys 1y ago
    Well it makes developing Docker Desktop infinitely easier for them, since they no longer need to start their own Linux VM under the hood. I think the software is "sticky" enough that people will still prefer to use Docker Desktop for the familiar CLI and UX, Docker Compose, and all the Docker-specific quirks that make migrating to a different container runtime basically impossible.
    • prmoustache 1y ago
      I never used docker desktop and am struggling to understand what you are supposed to be doing with a gui in a docker/container context.
      • arjonagelhout 1y ago
        For me, Docker Desktop is simply an easy way to launch the Docker daemon and inspect some created images and their corresponding logs. Other than that, the cli suffices.
        • hiccuphippo 1y ago
          We had to remove Docker Desktop at my job (I think they started asking for money?) and moved to Lima/Colima. If this project means one less program to configure to get my docker containers running then I'm all for it.
          • queenkjuul 1y ago
            Docker desktop for commercial use requires a license and they don't release binaries for Mac other than desktop. Seems like their one route to monetization. I use docker for literally only one build that doesn't work on native macOS so i love the idea of switching to a simple standalone CLI
• IshKebab 1y ago
  Getting worried about WSL I see!
  • SkepticalWhale 1y ago
    Whenever I have to develop on Windows, I clone my repos and run neovim / docker inside of WSL, for the improved performance (versus copying / mounting files from windows host) and linux. The dev experience is actually pretty good once you get there. I'm not sure this is the same, though. This feels more like docker for desktop running on a lightweight vm like Colima. Am I wrong?
    • metaltyphoon 1y ago
      This is my same workflow even for C#
• justinzollars 1y ago
  I'm excited to run Systemd on mac!
  • TacticalCoder 1y ago
    > I'm excited to run Systemd on mac! OCI containers are supposed to be "one container, one PID": at the very least the container's server is PID1 (at times other processes may be spawned but typically the container's main process is going to be PID1). Containerization is literally the antithesis of systemd. So I don't understand your comment.
    • deleted 1y ago
      [deleted]
  • watersb 1y ago
    :-) It isn't systemd: > Containers achieve sub-second start times using an optimized Linux kernel config, minroot filesystem, and a lightweight init system, vminitd https://github.com/apple/containerization/blob/main/vminitd https://github.com/apple/containerization/blob/main/vminitd
    • trallnag 1y ago
      Wouldn't be surprised if this goes through the same process Windows users did with WSL. Starting out with no systemd, to community-developed systemd-in-a-bottle setups, to proper systemd integration
• jamie0 1y ago
  disappointing theres still no namespacing in darwin for macos containers. would be great to run xcodebuild in a container
• sneak 1y ago
  Surprising to me that this uses swift CLI tools (free software) and make, not Xcode.
  • detourdog 1y ago
    Xcode also has command line tools that can do the same.
    • sneak 1y ago
      Obtaining and using Xcode requires submitting to an additional license contract from Apple. Swift and Make do not.
      • detourdog 1y ago
        Are you sure about that? I mean accepting license aggreements is pretty standard and doesn't bother me. This guide seems to have no specific license agreement. https://www.freecodecamp.org/news/install-xcode-command-line-tools/ https://www.freecodecamp.org/news/install-xcode-command-line...
        • sneak 1y ago
          Accepting license agreements isn’t standard because EULAs aren’t standard. Each one is a contract and each one is unique. Just because you click through them all without reading doesn’t mean they are all equivalent. Xcode has an EULA. Swift and Make do not, being free software. They are not the same.
          • detourdog 1y ago
            I think any using Swift CLI tools would be bound to the same EULA as the Xcode CLI tools. I worked with a german developer that did all his Xcode work in emacs with GCC in Objective-C days. Somebody like to stand on ideals and complain and others like to get work done.
• solomatov 1y ago
  Does anyone know whether they have optimized memory management, i.e. virt machine not consuming more RAM than required?
  • dontdoxxme 1y ago
    Not yet: https://github.com/apple/container/blob/main/docs/technical-overview.md#releasing-container-memory-to-macos https://github.com/apple/container/blob/main/docs/technical-...
    • nasretdinov 1y ago
      From that document I read that it in fact does, but it doesn't release memory if app started consuming less. It does memory balooning though, so the VM only consumes as much RAM as the maximum amount requested by the app
• filleokus 1y ago
  Looks cool! In the short demo [0] they mention "within a few hundred milliseconds" as VM boot time (I assume?). I wonder how much tweaking they had to do, because this is using the Virtualization.framework, which has been around a while and used by Docker dekstop / Colima / UTM (as an option). I wonder what the memory overhead is, especially if running multiple containers - as that would spin up multiple VM's. [0]: https://developer.apple.com/videos/play/wwdc2025/346 https://developer.apple.com/videos/play/wwdc2025/346 10:10 and forwards
  • open592 1y ago
    They include the kernel config here[0] > Containers achieve sub-second start times using an optimized Linux kernel configuration[0] and a minimal root filesystem with a lightweight init system. [0]: https://github.com/apple/containerization/blob/main/kernel/config-arm64 https://github.com/apple/containerization/blob/main/kernel/c...
• jbverschoor 1y ago
  In my opinion this is a step towards the Apple cloud hosting. They have Xcode cloud. The $4B contract with Amazon ends, and it’s highly profitable. Build a container, deploy on Apple, perhaps with access to their CPU’s
  • paxys 1y ago
    It's quite a stretch to go from Apple launching container support for macOS to "they are going to compete with AWS". Especially considering Apple's own server workloads and data storage are mostly on GCP.
  • n2d4 1y ago
    It's still virtualization, so it'll necessarily be (slightly) slower than just running Linux natively. I don't think Apple's hardware makes up for that, certainly not at the price point at which they sell it.
    • jbverschoor 1y ago
      Compared to EC2? You've got to be kidding me.
  • slroger 1y ago
    Yeah that would be great. I dont understand why they dont explore this option
• sangeeth96 1y ago
  The CLI from the press release/WWDC session is at https://github.com/apple/container https://github.com/apple/container which I think is what many like myself would be interested in. I was hoping this'd be shipped with the newest Xcode Beta but that doesn't seem to be the case. Prebuilt packages are missing at the moment but they are working on it: https://github.com/apple/container/issues/54 https://github.com/apple/container/issues/54
  • n2d4 1y ago
    Seems prebuilt packages were released exactly one minute after your comment: https://github.com/apple/container/releases/tag/0.1.0 https://github.com/apple/container/releases/tag/0.1.0
    • sangeeth96 1y ago
      Beat me to it, thanks!
  • OJFord 1y ago
    Discussed at https://news.ycombinator.com/item?id=44229239 https://news.ycombinator.com/item?id=44229239
• sampton 1y ago
  Apple please expose GPU cores to the VMs.
  • emmelaich 1y ago
    I've used pytorch successfully in a MacOS VM on MacOS using https://tart.run/ https://tart.run/ so I'd expect it to work here too.
    • emmelaich 1y ago
      update: torch for Linux on ARM isn't built with Apple's MPS support so it didn't work with the pip install version. Perhaps it's possible to compile from scratch to have it.
  • lisperforlife 1y ago
    You can use libkrun to pretty much do the same thing.
• commandersaki 1y ago
  Video about it here: https://developer.apple.com/videos/play/wwdc2025/346/ https://developer.apple.com/videos/play/wwdc2025/346/ Looks like each container gets its own lightweight Linux VM. Can take it for a spin by downloading the container tool from here: https://github.com/apple/container/releases https://github.com/apple/container/releases (needs macOS 26)
  • paxys 1y ago
    Also works on macOS 15, but they mentioned that some networking features will be limited.
  • OJFord 1y ago
    The submission is about https://github.com/apple/containerization https://github.com/apple/containerization, not https://github.com/apple/container https://github.com/apple/container. The former is for apps to ship with container sidecars (and cooler news IMO); the latter is 'I am a developer and I want to `docker run ...`'. (Oh, and container has a submission here: https://news.ycombinator.com/item?id=44229239 https://news.ycombinator.com/item?id=44229239)
    • badc0ffee 1y ago
      The former is the framework enabling Linux containers on lightweight VMs and the latter is a tool using that framework.
  • zmmmmm 1y ago
    interesting choice - doesn't that then mean that container to container integration is going to be harder and a lot of overhead per-container? I would have thought a shared VM made more sense. I wonder what attracted them to this.
    • pxc 1y ago
      It seems great from a security perspective, and a little bit nice from a networking perspective.
• 9d 1y ago
  [flagged]
  • alexjplant 1y ago
    > Let's run linux inside a container inside docker inside macos inside an ec2 macos instance inside a aws internal linux host inside a windows pc inside the dreaming mind of a child. Not even the first non-hyperbolic part of what you wrote is correct. "Container" most often refers to OS-level virtualization on Linux hosts using a combination of cgroups, resource groups, SDN, and some mount magic (among other things). MacOS is BSD-based and therefore doesn't support the first two things in that list. Apple can either write a compatibility shim that emulates this functionality or virtualize the Linux kernel to support it. They chose the latter. There is no Docker involved. This is a completely sane and smart thing for them to do. Given the choice I'd still much rather run Linux but this brings macOS a step closer to parity with such.
    • 9d 1y ago
      To be honest, I don't know what Docker or any of these things are. I just wanted to sound smart so I could fit in and people would like me.
• deleted 1y ago
  [deleted]
• joshdavham 1y ago
  Will this likely have any implications for tools like ‘act’ for running local GitHub actions? I’ve had some trouble running act on apple silicon in the past.
  • OJFord 1y ago
    In theory could make it more seamless, so installation instructions didn't include 'you must have a functioning docker engine' etc. - but in practice I assume it's a platform-agnostic non-Swift tool that isn't interested in a macOS-specific framework to make it smoother on just one platform.
• roberttod 1y ago
  I need to look into this a little more, but can anyone tell me if this could be used to bundle a Linux container into a MacOS app? I can think of a couple of places that might be useful, for example giving a GPT access to a Linux environment without it having access to run root CLI commands.
  • paxys 1y ago
    Yes, as long as you are okay with your app only working on macOS 26. Otherwise you can already achieve what you want using Virtualization.framework directly, though it'll be a little more work.
  • OJFord 1y ago
    Yes, that's exactly what it's for.
• bdcravens 1y ago
  Cool, but until someone (Apple or otherwise) implements Docker Compose on top of this, it's unlikely to see much use.
  • conradludgate 1y ago
    You only need to expose a docker daemon, which docker compose will use. The daemon is just a unix socket to a process that manages the containers, which is very likely a trivial change on top of the existing container codebase. For instance, Orbstack implements the docker daemon socket protocol, so despite not being docker, it still allows using docker compose where containers are created inside of Orbstack.
• sho_hn 1y ago
  So both of the other big two desktop OSs now have official mechanisms to run Linux VMs to host Linux-native applications. You can make some kind of argument from this that Linux has won; certainly the Linux syscall API is now perhaps the most ubiquitous application API.
  • OJFord 1y ago
    'Linux with macOS.'
  • bakztfutur3 1y ago
    [flagged]
    • deleted 1y ago
      [deleted]
  • paxys 1y ago
    Is it winning if you are the only one playing the game? Brag about this to an average Windows or Mac user and they will go "huh?" and "what is Linux?"
    • sho_hn 1y ago
      > Is it winning if you are the only one playing the game? Depending on what you mean with "the game", I'd say even more so. MS/Apple used to villify or ridicule Linux, now they need to distribute it to make their own product whole, because it turns out having an Open Source general purpose OS is so convenient and useful it's been utilized in lots of interesting ways - containers, for example - that the proprietary OS implementations simply weren't available for. I'd say it's a remarkable development.
    • yjftsjthsd-h 1y ago
      By that logic, this feature and WSL shouldn't exist.
      • 1y ago
• paxys 1y ago
  Thinking more about this a bit, one immediate issue I see with adoption is that the idea of launching each container in its own VM to fully isolate it and give it its own IP, while neat, doesn't really translate to Linux or Windows. This means if you have a team of developers and a single one of them doesn't have a mac, your local dev model is already broken. So I can't see a way to easily replace Docker/Compose with this.
  • dontdoxxme 1y ago
    It translates exactly to Kubernetes though, except without the concept of pods, I don't see anything in this that would stop them adding pods on top later, which would allow Kubernetes or compose like setups (multiple containers in the same pod).
• m463 1y ago
  I think this is purely a checkbox feature to compare against wsl. Otherwise apple just wouldn't get involved (not engineers, who would do lots of good things, but management that let this out)
• pxc 1y ago
  This is the most surprising and interesting part, imo: > Contributions to `container` are welcomed and encouraged. Please see our main contributing guide for more information. This is quite unusual for Apple, isn't it? WebKit was basically a hostile fork of KHTML, Darwin has been basically been something they throw parts of over the wall every now and then, etc. I hope this and other projects Apple has recently put up on GitHub see fruitful collaboration from user-developers. I'm a F/OSS guy at heart who has reluctantly become a daily Mac user due to corporate constraints that preclude Linux. Over the past couple of years, Apple Silicon has convinced me to use an Apple computer as my main laptop at home (nowadays more comparable, Linux-friendly alternatives seem closer now than when I got my personal MacBook, and I'm still excited for them). This kind of thing seems like a positive change that lets me feel less conflicted. Anyway, success here could perhaps be part of a virtuous cycle of increasing community collaboration in the way Apple engages with open-source. I imagine a lot of developers, like me, would both personally benefit from this and respect Apple for it.
  • zapzupnz 1y ago
    It's not that surprising. Much of Swift and its frameworks are contributed by the open source community.
    • pxc 1y ago
      That's true, but I always thought of Swift as exceptional in this because Swift is a programming language, and this has become the norm for programming languages in my lifetime. If my biases are already outdated, I'm happy to learn that. Either way, my hopes are the same. :)
      • samtheprogram 1y ago
        Jai has been one exception I can think of here. It hasn’t been publicly released yet, either (you can email/request pre-release access, though)
        • klausa 1y ago
• m3kw9 1y ago
  I’m already running docker on macOS what’s the difference?
• sitole 1y ago
  Has anyone tried turning on nested virt yet? Since the new container CLI spins each container in its own lightweight Linux VM via Virtualization.framework, I’m wondering whether the framework will pass the virtualization extensions through so we can modprobe kvm inside the guest. Apple’s docs say nested virtualization is only available on M3-class Macs and newer (VZGenericPlatformConfiguration.isNestedVirtualizationSupported) developer.apple.com, but I don’t see an obvious flag in the container tooling to enable it. Would love to hear if anyone’s managed to get KVM (or even qemu-kvm) running inside one of these VMs.
• SamuelAdams 1y ago
  I wonder if this will dramatically improve gaming on a Mac? Valve has been making games more reliable due to Steam Deck, and gaming on Linux is getting better every year. Could games be run inside a virtual Linux environment, rather than Apple’s Metal or similar tool? This would also help game developers - now they only need to build for Windows, Linux, and consoles.
  • october8140 1y ago
    I imagine running in a VM would hurt performance a lot.
    • lxgr 1y ago
      Not necessarily. For example, the Xbox 360 runs every game in a hypervisor, so technically, everything is running in a VM. It's all a question of using the right/performant hardware interfaces, e.g. IOMMU-based direct hardware access rather than going through software emulation for performance-critical devices.
  • pxc 1y ago
    Apple's Virtualization Framework doesn't support 3D acceleration for non-macOS guests.
  • throwaway127482 1y ago
    Isn't the Linux gaming stuff really an emulator for Windows games? So it'd be like, windows emulation inside Linux virtualization inside macos?
    • lxgr 1y ago
      As far as I understand, it's a modified/extended version of Wine, which, as the name suggests, is not an emulator (but rather a userspace reimplementation of the Windows API, including a layer that translates DirectX to OpenGL/Vulkan). The reverse, i.e. running Linux binaries on Windows or macOS, is not easily possible without virtualization, since Linux uses direct syscalls instead of always going through a dynamically linked static library that can take care of compatibility in the way that Wine does. (At the very least, it requires kernel support, like WSL1; Wine is all userspace.)
• ANGXL123 1y ago
  [dead]
• miovoid 1y ago
  I hope it will support nested virtualization.
• spockz 1y ago
  At first I thought this sounded like a blend of the virtualisation framework with a firecracker style lightweight kernel. This project had its own kernel, but it also seems to be able to use the firecracker one. I wonder what the advantages are. Even smaller? Making use of some apple silicon properties? Has anyone tried it already and is it fast? Compared to podman on Linux or Docker Desktop for Mac?
  • rfoo 1y ago
    The advantage is, now there's an Apple team working on it. They will be bothered by their own bugs and hopefully get them fixed. Virtualization.framework and co was buggy af when introduced and even after a few major macOS versions there are still lots of annoyances, for example the one documented in "Limitations on macOS 15" of this project, or half-assed memory ballooning support. Hypervisor.framework on the other hand, is mostly okay, but then you need to write a lot more codes. Hypervisor.framework is equivalent to KVM and Virtualization.framework is equivalent to qemu.
    • egorfine 1y ago
      > They will be bothered by their own bugs Laughs in Xcode
    • Aaron2222 1y ago
      And QEMU on macOS uses Virtualization.framework for hardware virtualisation.
• cedws 1y ago
  Forget Linux containers on Mac, as far as I’m concerned that’s already a solved problem. What about Mac containers? We still don’t have a way to run a macOS app with its own process namespace/filesystem in 2025. And with all this AI stuff, there’s a need to minimise blast radius of a rogue app more than ever.
  • hadlock 1y ago
    Is there any demand for mac binaries in production? I can't think of a single major cloud provider that offers Mac hardware based k8s nor why you'd want to pay the premium over commodity hardware. Linux seems to be the lingua franca of containerized software distribution. Even windows support for containers is sketchy at best
    • jurip 1y ago
      I don't think the parent was asking for server side macOS containerization, but desktop. It'd be nice to put something like Cursor in a sandbox where it really couldn't rm -rf your home directory. I'd love to do the same thing with every app that comes with an installer.
      • hadlock 1y ago
        I've had really poor experience doing anything with container deployed consumer apps in Linux. As soon as you even look at going out of the happy path, things immediately start going sideways.
        • duped 1y ago
          flatpak and snap are both containerization-adjacent technologies for consumer apps, docker containers are not really intended for that use case.
      • duped 1y ago
        You already can with `sandbox_exec`. And the entire entitlements design is there to force apps to have granular permissions.
• mattclarkdotnet 1y ago
  Spoiler alert: it’s not containers. It’s some nice tooling wrapped around lightweight VMs, so basically WSL2
  • amazingman 1y ago
    Are the lightweight VMs running containers?
  • cromka 1y ago
    WSL1, rather.
• tgma 1y ago
  I'm glad this will kill the Docker Desktop clone business on Mac. Friend company got hit by using one of the free ones and got rug pulled by them.
• deleted 1y ago
  [deleted]
• dang 1y ago
  Related ongoing threads: Container: Apple's Linux-Container Runtime - https://news.ycombinator.com/item?id=44229239 https://news.ycombinator.com/item?id=44229239 - June 2025 (11 comments) Apple announces Foundation Models and Containerization frameworks, etc - https://news.ycombinator.com/item?id=44226978 https://news.ycombinator.com/item?id=44226978 - June 2025 (345 comments) (Normally we'd merge them but it seems there are significant if subtle differences)
• mustache_kimono 1y ago
  This is great. Also about time, etc. But is it also finally time to fix dtrace on MacOS[0]? [0]: https://developer.apple.com/forums/thread/735939?answerId=762622022#762622022 https://developer.apple.com/forums/thread/735939?answerId=76...
• peterpost2 1y ago
  Terrible name. Look like a neat product though!
  • bravesoul2 1y ago
    Tailored Swift would be better
    • badc0ffee 1y ago
      TAYNE (short for conTAYNEr): https://www.youtube.com/watch?v=a8K6QUPmv8Q https://www.youtube.com/watch?v=a8K6QUPmv8Q
• omeid2 1y ago
  This is really bad news for Linux on Desktop. Many developers I know don't use MacOS mainly because they depend on containers and virtualisation is slow, but if Apple can pull off efficient virtualisation and good system integration (port mapping, volumes), then it will eat away at a large share of linux systems.
• qalmakka 1y ago
  that's nice and all - but where are the native Darwin containers? Why is it ok for Apple to continue squeezing people with macOS CI jobs to keep buying stupid Mac Minis to put in racks only to avoid a mess? Just pull FreeBSD jails!
  • egorfine 1y ago
    This is my pain point. I would really want to have a macOS (not just Darwin) container, but it seems that it is not possible with macOS. I don't remember the specifics, but there was a discussion here at HN a couple of month ago and someone with intrinsic Darwin knowledge explained why.
    • qalmakka 1y ago
      > it's not possible Heck even Microsoft managed to run Windows containers on Windows, even with the technical debt and bloat they had. Apple could, they just don't want to because it goes straight against their financial interests
  • conradludgate 1y ago
    You can run macos VMs at the very least https://developer.apple.com/documentation/virtualization/running-macos-in-a-virtual-machine-on-apple-silicon https://developer.apple.com/documentation/virtualization/run...
    • qalmakka 1y ago
      Sure but they don't really scale due Apple's refusal to provide a headless version with WindowServer off Also the EULA limits you to just two VMs per computer and only for very specific purposes. Clearly because they want you to buy their damn computers
• deleted 1y ago
  [deleted]
• fralix 1y ago
  And when native OCI macos container engine native ?!
• julik 1y ago
  Really curious how this improves the filesystem bridging situation (which with Docker Desktop was basically bouncing from "bad" to "worse" and back over the years). Or whether it changes it at all.
  • dwaite 1y ago
    I would imagine it is low lift - using https://developer.apple.com/documentation/virtualization/shared-directories https://developer.apple.com/documentation/virtualization/sha... which is already built into the OS
  • torginus 1y ago
    I'm just taking a wild guess here, but I'd guess it's not a problem - WSL2 works afaik by having a native ext4 partition, and the Windows kernel accesses it. Intra-OS file perf is great, but using Windows to access Linux files is slow. MacOS just understands ext4 directly, and should be able to read/write it with no performance penalty.
  • benwaffle 1y ago
    I wonder how it compares to orbstack
  • merb 1y ago
    If they wanted to improve the situation they would’ve needed to ship an apfs driver and a Linux kernel. Sadly they didn’t.
    • wmf 1y ago
      AFPS isn't the solution since you can't have two kernels accessing the same FS. The solution is probably something like virtio-fs with DAX.
• pmarreck 1y ago
  So the x64 containers will run fine on Apple Silicon?
  • dwaite 1y ago
    On a ARM linux target, they do support Rosetta 2 translation of intel binaries under virtualization using Rosetta 2. I do not know if their containerization supports it. https://developer.apple.com/documentation/virtualization/running-intel-binaries-in-linux-vms-with-rosetta https://developer.apple.com/documentation/virtualization/run... Given that they announced a timeline for sunsetting Rosetta 2, it may be low priority.
    • pmarreck 1y ago
      x64 is not going away anytime soon, so that’s unfortunate
• pmarreck 1y ago
  Prefer the Nix approach unless a container approach is absolutely necessary.
• throwaway1482 1y ago
  If they're going this way, why not just replace the macOS kernel (XNU) with Linux? They'll get so much more.
  • badc0ffee 1y ago
    Because the rest of the system uses a bunch of things that have no drop-in Linux equivalent - SIP, Mach ports, firmlinks, etc.
    • throwaway1482 1y ago
      Those can be emulated with the likes of SELinux, sockets, and bind mounts. It will take a lot of effort and some adaptation, but it could be done.
• xmorse 1y ago
  Is this basically the same thing as Orbstack?
• sirjaz 1y ago
  This is just wsl2 from Microsoft, albeit with an Apple spin
• arianvanp 1y ago
  Them synthesizing an EXT4 file system from tarball layers instead of something like EROFS is so extremely odd. Really really strange design.