[HN Gopher] Containerization is a Swift package for running Linu...
       ___________________________________________________________________
        
       Containerization is a Swift package for running Linux containers on
       macOS
        
       Author : gok
       Score  : 174 points
       Date   : 2025-06-09 20:53 UTC (2 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | rvz wrote:
       | 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
        
         | keysdev wrote:
         | Any linux or bsd that has goodhardwawe support for intel mac?
        
           | bjackman wrote:
           | 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-
           | 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 wrote:
             | 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/
        
         | haiku2077 wrote:
         | 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 wrote:
           | a 30% discount for a 3 yr old machine is good? A new one is
           | $999.
        
             | DrBenCarson wrote:
             | 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 wrote:
           | Even better deals on M1s which aren't much slower than M2s
        
           | paxys wrote:
           | $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.
        
         | pjmlp wrote:
         | That was officially communicated at the state of the union
         | session.
        
       | newman314 wrote:
       | I wonder how this will affect apps like Orbstack
        
         | SparkyMcUnicorn wrote:
         | 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 wrote:
           | Orbstack also does kubernetes etc
        
         | 9dev wrote:
         | 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...
        
       | rfoo wrote:
       | This does not support memory ballooning yet. But they have
       | documented custom kernel support, so, goodbye OrbStack.
        
         | worldsavior wrote:
         | Orbstack is docker. People might still prefer docker.
        
       | outcoldman wrote:
       | 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 wrote:
         | 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 wrote:
           | 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 wrote:
       | Wonder how Docker feels about this. I'd assume a decent amount of
       | Docker for Desktop is on Mac...
        
         | paxys wrote:
         | 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 wrote:
           | 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 wrote:
             | 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.
        
             | stackskipton wrote:
             | GUI lets you look at logs quickly, there is buttons to
             | click quickly open http://localhost:<port>, stop and start
             | containers, get shell in container and bunch of other stuff
             | that people developing or testing against containers need
             | locally.
        
               | prmoustache wrote:
               | I am surprised a developer would not have chosen to
               | redirect the port at run time already and would not be
               | running the containers in the foreground in the first
               | place.
        
               | phinnaeus wrote:
               | Dropbox copypasta goes here
        
         | cogman10 wrote:
         | Probably about the same way they feel about podman.
        
           | Kwpolska wrote:
           | Podman is fairly niche. This is an Apple product that Apple
           | developer circles will push hard.
        
             | cogman10 wrote:
             | I agree, Apple has a lot of weight. Podman, however, also
             | has a fair bit of heft behind it (IBM via Redhat).
             | 
             | I'll not deny that it's a bit niche, but not so much so
             | that it's completely unknown.
        
         | sneak wrote:
         | Docker Desktop is closed source proprietary software and this
         | is free software, so this is a win (for us, at least).
        
       | IshKebab wrote:
       | Getting worried about WSL I see!
        
         | SkepticalWhale wrote:
         | 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?
        
       | justinzollars wrote:
       | I'm excited to run Systemd on mac!
        
         | watersb wrote:
         | :-)
         | 
         | 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
        
       | jamie0 wrote:
       | disappointing theres still no namespacing in darwin for macos
       | containers. would be great to run xcodebuild in a container
        
       | sneak wrote:
       | Surprising to me that this uses swift CLI tools (free software)
       | and make, not Xcode.
        
         | detourdog wrote:
         | Xcode also has command line tools that can do the same.
        
           | sneak wrote:
           | Obtaining and using Xcode requires submitting to an
           | additional license contract from Apple. Swift and Make do
           | not.
        
         | w10-1 wrote:
         | Containers are mainly for CI+testing and for Linux workflows,
         | so xcodebuild is not really an option.
        
       | solomatov wrote:
       | Does anyone know whether they have optimized memory management,
       | i.e. virt machine not consuming more RAM than required?
        
       | filleokus wrote:
       | 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 10:10
       | and forwards
        
         | open592 wrote:
         | 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/c...
        
       | jbverschoor wrote:
       | 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 wrote:
         | 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.
        
       | sangeeth96 wrote:
       | The CLI from the press release/WWDC session is at
       | 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
        
         | n2d4 wrote:
         | Seems prebuilt packages were released exactly one minute after
         | your comment:
         | https://github.com/apple/container/releases/tag/0.1.0
        
       | sampton wrote:
       | Apple please expose GPU cores to the VMs.
        
       | commandersaki wrote:
       | Video about it here:
       | 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 (needs macOS
       | 26)
        
       | 9d wrote:
       | At what point will this Russian doll set of virtualization reach
       | an end?
       | 
       | 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.
       | 
       | And inside that linux maybe run qemu with munal os
       | [https://github.com/Askannz/munal-os]
        
         | alexjplant wrote:
         | > 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.
        
       | sho_hn wrote:
       | Linux has won.
        
       | joshdavham wrote:
       | 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.
        
       | roberttod wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2025-06-09 23:00 UTC)