[HN Gopher] Container: Apple's Linux-Container Runtime
___________________________________________________________________
Container: Apple's Linux-Container Runtime
Author : jzelinskie
Score : 283 points
Date : 2025-06-09 20:42 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jzelinskie wrote:
| Container runs OCI (docker) compatible by creating lightweight
| VMs.
|
| This repository houses the command-line interface which is
| powered by containerization[0], the Swift framework wrapping
| Virtualization.framework to implement an OCI runtime.
|
| [0]: https://github.com/apple/containerization
| ok_computer wrote:
| I am going to show my ineptitude by admitting this, for the
| life of me I couldn't get around to implement the Mac Os native
| way to run linux VMs and used vm-ware fusion instead. [0]
|
| I'm glad this more accessible package is available vs docker
| desktop on mac os or the aforementioned, likely to be abandoned
| vmware non enterprise license.
|
| [0] [apple virtualization docs](https://developer.apple.com/doc
| umentation/virtualization/cre...)
| mrpippy wrote:
| VMware Fusion is a perfectly good way of running VMs, and IMO
| has a better and more native UI than any other solution
| (Parallels, UTM, etc)
| stephenr wrote:
| This is a weird take to me.
|
| VMWare Fusion very much feels like a cheap one-time port of
| VMWare Workstation to macOS. On a modern macOS it stands
| out very clearly with numerous elements that are
| reminiscent of the Aqua days: icon styles, the tabs-within-
| tabs structure, etc.
|
| Fusion also has had some pretty horrific bugs related to
| guest networking causing indefinite hangs in the VM(s) at
| startup.
|
| Parallels isn't always perfect sailing but put it this way:
| I have had a paid license for both (and VBox installed),
| for many years to build vagrant images, but when it comes
| to actually running a VM for purposes other than building
| an image, I almost exclusively turn to Parallels.
| close04 wrote:
| > reminiscent of the Aqua days
|
| Maybe _early_ Aqua. We 're still in the Aqua days, if you
| don't count yesterday's Liquid Glass announcement. :)
| cpuguy83 wrote:
| Not on Apple Silicon it's not. In the Intel days, sure it
| was great.
| kefirlife wrote:
| Lima makes this really straightforward and supports vz
| virtualization. I particularly like that you can run x86
| containers through rosetta2 via those Linux VMs with nerdctl.
| If you want to implement it yourself of course you can, but I
| appreciate the work from this project so far and have used it
| for a couple of years.
|
| https://lima-vm.io/
| pdimitar wrote:
| And you also have `colima`[0] on top of it that makes
| working with Docker on the command-line a seamless
| experience.
|
| [0] https://github.com/abiosoft/colima
| wmf wrote:
| Should probably merge with
| https://news.ycombinator.com/item?id=44229348
| OJFord wrote:
| I disagree, they are different, and _that_ (containerization,
| not container here) is the more novel /interesting one imo.
| It'd be nice to focus the discussion more (though at present
| there are many confused comments there that think they're
| discussing the container tool).
| n42 wrote:
| Oh, like OP I didn't see the difference. I believe the
| difference is:
|
| Container is a CLI tool
|
| Containerization is a framework
| OJFord wrote:
| Yes, container is like `docker` CLI: 'I am a developer and
| I want to run a container'; containerization is for
| packaging OCI image container sidecars into Swift .apps -
| you could distribute your app with postgres 'built in' (but
| running as a container), user doesn't need to ensure it's
| installed and running separately or anything.
| dang wrote:
| Whoops, I merged them but you've persuaded me to unmerge
| them. This will take a bit of time.
|
| Edit: reverted!
| OJFord wrote:
| Oh no, sorry! :)
| 90s_dev wrote:
| How actually _is_ Swift as a Rust alternative? Is it feasible?
|
| The only gripe I remember with it is that all its APIs are weird.
|
| Like instead of normal names, you have Apple-legacy-names for
| methods/classes.
| EPWN3D wrote:
| Depends on what you're doing. If you want to write systems
| code, Swift is very allocation-happy and will probably not be
| the best fit. They're trying to make an embedded Swift, but
| progress is pretty slow, since that's not going to be something
| that gets anyone promoted.
|
| If you just want to write A Thing, then it's up to your
| individual taste, what's available in the ecosystem, etc.
| dwaite wrote:
| Apple has started using Swift for production embedded code
| run within the Secure Enclave. I've been looking out for any
| evidence whether they are using it in the C1 modem baseband.
|
| I don't think I'd push for it over Rust for those
| applications, but there is apparently wood behind the arrow
| internally.
| tcmart14 wrote:
| I can't speak to performance since I don't really race
| languages. But as far as feel and what not, it is very similar.
| But there is also a pretty good overlap in people who worked on
| Rust and people who worked in Swift. Graydon worked on both. So
| Swift has a lot of similarities with Rust. The way I usually
| word it is, Swift is like having C# with mostly everything you
| like about Rust.
|
| I believe a lot of the legacy names come from when your
| interfacing with platform APIs like UIKit and such if you have
| to and they haven't quiet gotten a bump from their Objective-C
| APIs to have more swifty-APIs.
| written-beyond wrote:
| Rust and Swift have done a fair bit of borrowing from each
| other "pun intended".
|
| I've never got the chance to work with swift since their cross
| platform compatibility and "server-side swift" have been recent
| introductions.
|
| In terms comparison, it really is the closest you can get to a
| rust that ARC BOX's everything (which has/ is planned to come
| down when lifetimes come in). You get a good runtime and good
| performance.
| waterTanuki wrote:
| much of the new swift libraries/apis don't have the legacy "NS"
| prefixes you're thinking of
| rafram wrote:
| Swift isn't quite as fast, because reference counting is
| inherently slower at runtime than the allocations/deallocations
| generated by the Rust borrow checker.
|
| On the other hand, Swift has (IMO) a much cleaner and less
| symbol-heavy syntax than Rust. Easier to read and write. Less
| of a culture of doing crazy metaprogramming/DSL definition with
| macros, and the builder DSL built into the language (which
| SwiftUI uses) is pretty nice and generates mostly
| understandable compile errors.
|
| I actually like Apple's APIs, even the legacy ones. There's
| some weirdness, like how some file APIs want paths and some
| want URIs, but it's not that bad.
| dwaite wrote:
| They are different language designs sharing quite a few of the
| same features/philosophies.
|
| Swift is good for business logic, like writing an app.
|
| Rust is better for infrastructure, like writing a HTTP/3 server
| or Javascript VM.
|
| Swift has an extremely good story about ABI stability, which
| makes sense when Apple ships a swift runtime and libraries as
| part of the OS, and needs the binaries to work across two dozen
| different major/minor releases.
|
| Rust has up-front memory control primitives and options to
| remove the core library to cater to things like embedded
| systems development.
|
| People have written apps in Rust, and Apple has written API
| backends and even device firmwares in Swift. I would argue both
| push against the ergonomics of the respective languages.
| sverhagen wrote:
| Is it smart to call the implementation after the category, or am
| I misunderstanding what is going on? Surely they won't be able to
| trademark this?
| wmf wrote:
| It's not a product; it's a command line tool that's (more or
| less) part of the OS. It doesn't need a fancy name.
| precompute wrote:
| You're right, it's an incredibly pyrrhic decisions that aims to
| wrestle the meaning of the word towards apple's implementation.
| I mean, the company is named "apple". This kind of raze-a-
| language marketing is in their DNA.
| dang wrote:
| Related ongoing threads:
|
| _Containerization is a Swift package for running Linux
| containers on macOS_ -
| https://news.ycombinator.com/item?id=44229348 - June 2025 (158
| comments)
|
| _Apple announces Foundation Models and Containerization
| frameworks, etc_ - https://news.ycombinator.com/item?id=44226978
| - June 2025 (346 comments)
|
| (Normally we'd merge them but it seems there are significant if
| subtle differences between these)
| spockz wrote:
| Cross posting in the right place instead of the other thread:
|
| 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?
| punnerud wrote:
| Does this enable running containers next apps to iOS and MacOS
| downloaded from AppStore?
| gardaani wrote:
| I have been using lima to run Linux VMs on macOS. This new Apple
| tool looks very similar and I might replace lima with it.
| rcarmo wrote:
| Not for iPadOS, alas.
| znpy wrote:
| well of course, the ipad is not a computer (despite what the
| marketing says)
| zarazas wrote:
| Will it be possible to integrate this with docker, so docker
| containers on Mac run more performance optimized?
| ouked wrote:
| According to jzelinskie, yes:
| https://news.ycombinator.com/item?id=44229248
| dwaite wrote:
| This is a layer on top of the operating system support for
| virtualization, which Docker Desktop (and tons of open source
| alternatives) already use.
___________________________________________________________________
(page generated 2025-06-10 23:02 UTC)