Ask HN: Has anybody built search on top of Anna's Archive?
289 points by neonate 6d ago 146 comments
Ask HN: Is there any demand for Personal CV/Resume website?
6 points by usercvapp 1d ago 16 comments
Containerization is a Swift package for running Linux containers on macOS
457 gok 200 6/9/2025, 8:53:29 PM github.com ↗
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)
Not a container "as such" then.
How hard is it to emulate linux system calls?
It’s doable but a lot more effort. Microsoft did it with WSL1 and abandoned it with WSL2.
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)
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?
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.
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.
Needing two of the most famous non-Linux operating systems for the layman to sanely develop programs for Linux systems is not particularly a victory if you look at it from that perspective. Just highlights the piss-poor state of Linux desktop even after all these years. For the average person, it's still terrible on every front and something I still have a hard time recommending when things so often go belly up.
Before you jump on me, every year, I install the latest Fedora/Ubuntu (supposedly the noob-friendly recommendations) on a relatively modern PC/Laptop and not once have I stopped and thought "huh, this is actually pretty usable and stable".
If Gnome implemented that as well as macOS does I’d happily switch permanently.
Everybody has been making fun of Blender forever but they consistently made things better step by step and suddenly few UX enhancements the wind started shift. It completely flipped and now everybody is using it.
I wouldn’t be surprised if desktop Linux days are still ahead. It’s not only Valve and gaming. Many things seems start to work in tandem. Wayland, Pipewire, Flatpack, atomic distros… hey even Gnome is starting to look pretty.
I think we need to have a specific audience in mind when saying whether or not it's stable. My Arch desktop (user: me) is actually really stable, despite the reputation. I have something that goes sideways maybe once a year or so, and it's a fairly easy fix for me when that does happen. But despite that, I would never give my non-techy parents an Arch desktop. Different users can have different ideas of stable.
The desktop marketshare stats back me up on the earlier point and last I checked, no distro got anywhere close?
Sure, Android is the exception (if we agree to consider) but until we get serious dev going there and until Android morphs into a full-fledged desktop OS, my point stands.
And yes, that's bought by the 'average person'.
For Windows and MacOS you can throw a few quick bucks over the wall and tick a whole bunch of ISO checkboxes. For Linux, you need more bespoke software customized to your specific needs, and that requires more work. Sure, the mindless checkboxes add nothing to whatever compliance you're actually trying to achieve, but in the end the auditor is coming over with a list of checkboxes that determine whether you pass or not.
I haven't had a Linux system collapse on me for years now thanks to Flatpak and all the other tools that remove the need for scarcely maintained external repositories in my package manager. I find Windows to be an incredible drag to install compared to any other operating system, though. Setup takes forever, updates take even longer, there's a pretty much mandatory cloud login now, and the desktop looks like a KDE distro tweaked to hell (in a bad way).
Gnome's "who needs a start button when there's one on the keyboard" approach may take some getting used to, but Valve's SteamOS shows that if you prevent users from mucking about with the system internals because gary0x136 on Arch Forums said you need to remove all editors but vi, you end up with a pretty stable system.
Yes, a lot of MDM feature are just there to check ISOwhatever boxes. Some are legitimately great, though. And yes, even though I’m personally totally comfortable running a Linux laptop, come SOC2 audit time it’s way harder to prove that a bunch of Linux boxes meet required controls when you can’t just screenshot the Jamf admin page and call it good.
That’s not to say it can’t or doesn’t work for some people in the middle, but for this group it’s much more likely that there’s some kind of fly in the soup that’s preventing them from switching.
It’s where I’m at. I keep secondary/tertiary Linux boxes around and stay roughly apprised of the state of the Linux desktop but I don’t think I could ever use it as my “daily driver” unless I wrote my own desktop environment because nothing out there checks all of the right boxes.
However on embedded, and desktop, the market belongs to others, like Zehyr, NutXX, Arduino, VxWorks, INTEGRITY,... and naturally Apple, Google and Microsoft offerings.
Also Linux is an implementation detail on serverless/lambda deployments, only relevant to infrastructure teams.
I think what slows down market share of Linux on desktop is Linux on desktop itself.
I use Linux, and I understand that it's a very hard job to take it to the level of Windows or macOS, but it is what it is.
More software gets developed for that base Linux platform API, which makes releasing Linux-native software easier/practically free, which in turn makes desktop Linux an even more viable daily driver platform because you can run the same apps you use on macOS or Windows.
Eventually I got practical and fed up with ways of Linux Desktop.
Hell, Samsung is delivering Linux to the masses in the form of Wayland + PulseAudio under the brand name "Tizen". Unlike desktop land, Tizen has been all-in on Wayland since 2013 and it's been doing fine.
Likewise with ChromeOS.
They are Pyrrhic victories.
As for Tizen, interesting that Samsung hasn't yet completely lost interest on it.
I do pro audio on Linux, my commercial DAWs, VSTs, etc are all Linux-native these days. I don't have to think about anything sound-wise because Pipewire handles it all automatically. IMO, Linux has arrived when it comes to this niche recently, five years ago I'd have to fuck around with JACK, install/compile a realtime kernel and wouldn't have as many DAWs & VSTs available.
Similarly, I have a friend in video production and VFX whose studio uses Linux everywhere. Blender, DaVinci Resolve, etc make that easy.
There is a lack of options when it comes to pro illustration and raster graphics. The Adobe suite reigns supreme there.
Brag about this to an average Windows or Mac user and they will go "huh?" and "what is Linux?"
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.
> 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.
Chromiom is a hostile fork of WebKit. Webkit was a rather polite fork of KHTML, just that they had a team of full time programmers so KHTML couldn't keep up with the upstream requests and gave up since WebKit did a better job anyway.
I personally would LOVE if a corporation did this to any of my open source projects.
Even KDE eventually dropped KHTML in favor of KHTML’s own successor, WebKit-based engines (like QtWebKit and later Qt WebEngine based on Chromium).
A web engine isn’t just software — it needs to keep evolving.
Recognising the value of someone’s work is better than ignoring it and trying to build everything from scratch on your own, Microsoft's Internet Explorer did not last.
You are rewriting history here. The main KHTML developers were hired by Apple and Konqueror got on with the new engine. There was no fuss and no drama.
The reason why it’s fair play is that the license allows it. Google is no white knight out to avenge the poor KHTML users from 2003.
WebKit has been a fully proper open source project - with open bug tracker, patch review, commit history, etc - since 2005.
Swift has been a similarly open project since 2015.
Timeline-wise, a new high profile open source effort in 2025 checks out.
I do have a personal MacBook pro that I maxed out (https://gigatexal.blog/pages/new-laptop/new-laptop.html) but I do miss tinkering with my i3 setup and trying out new distos etc. I might get a used thinkpad just for this.
But yeah my Mac personal or work laptop just works and as I get older that’s what I care about more.
Going to try out this container binary from them. Looks interesting.
If my biases are already outdated, I'm happy to learn that. Either way, my hopes are the same. :)
They took over LLVM by hiring Chris Lattner. It was still a significant investment and they keep pouring resources into it for a long while before it got really widespread adoption. And yes, that project is still going.
I suspect this move was designed to stop losing people like you to WSL.
I can happily use my Mac as my primary machine without much hassle, just like I would often do with WSL.
I am also thinking the same, Docker desktop experience was not that great at least on Intel Macs
They don't have to do literally any of this.
Besides, I think OP wasn't talking about licenses; Apple has a lot of software under FOSS licenses. But usually, with their open-source projects, they reject most incoming contributions and don't really foster a community for them.
Or distributing builds of something that statically links to it. (Which some would argue creates a derivative work.)
https://developer.apple.com/documentation/virtualization
Do people learn docker not via the CLI?
And like I'm not all anti-GUI, it's just that docker is one of those things I've never even imagined using a GUI for
It’s just that Docker Desktop makes it easy and also provides other integrations like file system sharing etc.
For Kubernetes, something like K9s [1] or Headlamp [2] works fine. I remember seeing something similar for Docker but I can't remember the name.
[1] https://k9scli.io/ [2] https://headlamp.dev/
I think docker desktop and apple's containerization are both targeted firmly at developers only.
It's like programming, sure it's possible to write code in microsoft office or xcode or vscode, but all programmers I've met opt for ed or vi.
The nice part is that they (a) set up the Linux VM that runs the Docker daemon for you and (b) handle the socket forwarding magic that lets you communicate with it "directly" by running the Docker client on the host OS. This is likewise true for Podman Desktop, Rancher Desktop, etc.
The GUI is icing on the cake, imo.
Docker for Desktop sits on-top of container/virtualization software (Hypervisor.framework and QEMU on Mac, WSL on Windows, containerd on Linux). So there's a good chance that future versions of Docker for Desktop will use this library, but they don't really compete with each other.
If it doesn't, then it's still a toss-up whether or not user chooses docker/podman/this...etc.
If it ends up shipping by default and is largely compatible with the same command line flags and socket API... Then docker has a problem.
For what it's worth, I prefer podman but even on Linux where the differentiators should be close to zero, I still find certain things that only docker does.
My org's management wasn't taking the issue seriously, but once the subscription cost reached one FTE's salary, they started listening to people who had already switched to Podman, Rancher or (Co)Lima.
I'll not deny that it's a bit niche, but not so much so that it's completely unknown.
I'm sure Apple will try to push their own version of Docker but I'm not sure if they'll be able to win over any Docker Desktop businesses unless their tool also works on other operating systems.
"Apple developer circles" to me means the few mostly indies who build non-electron Mac apps and non-ReactNative ios apps, but those developers mostly are writing client code and don't even touch servers.
All this said, my above "gut feelings" don't explain why Apple would have bothered spending their time making this when Orbstack, Docker, etc. already meet the needs of the developers on Mac who actually need and use containers.
[0]: besides the "Command line tools" that allow compilation to work, of course.
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.
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.)
> But after that, Rosetta will be pared back and will only be available to a limited subset of apps—specifically, older games that rely on Intel-specific libraries but are no longer being actively maintained by their developers. Devs who want their apps to continue running on macOS after that will need to transition to either Apple Silicon-native apps or universal apps that run on either architecture.
https://arstechnica.com/gadgets/2025/06/apple-details-the-en...
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.
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.
Container: Apple's Linux-Container Runtime - 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 - June 2025 (345 comments)
(Normally we'd merge them but it seems there are significant if subtle differences)
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
But is it also finally time to fix dtrace on MacOS[0]?
[0]: https://developer.apple.com/forums/thread/735939?answerId=76...
People still want the nice UI/UX, and this is just a Swift package.
As opposed to that, there's OrbStack, a venture-backed closed source application thriving off of user licenses, developed by a small team. As empathetic as I am with them, I know where I bet my money on in this race.
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.
Presumably it's not as good right now but where it ends up depends entirely on Apple's motivation. When they are determined they can build very good things.
If you're a dev team that creates Mac/iOS/iPad/etc apps, you might want Mac hardware in your CI/CD stack. Cloud providers do offer virtual Macs for this purpose.
If you're a really big company (eg. a top-10 app, eg. Google) you might have many teams that push lots of apps or app updates. You might have a CI/CD workflow that needs to scale to a cluster of Macs.
Also, I'm pretty sure apple at least partially uses Apple hardware in the serving flow (eg. "Private Cloud Compute") and would have an interest in making this work.
Oh, and it'd be nice to be able to better sand-box untrusted software running on my personal dev machine.
Private Cloud Compute is different hardware: https://security.apple.com/blog/private-cloud-compute/
I would cal this "Apple Hardware" even if its not the same thing you can buy at an Apple Store.
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.
It’s some nice tooling wrapped around lightweight VMs, so basically WSL2
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
> 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...
This guide seems to have no specific license agreement.
https://www.freecodecamp.org/news/install-xcode-command-line...
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.
> 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
I like the hardware, hate the absurd greedy storage and RAM prices.
Source? Is this self-imposed, or what does “allowed” mean?
Even if true, technical people can work around this by either spoofing a non-external drive or using `ln`, no?
IIRC Google Drive for Desktop won't sync the target of a symbolic link. It will sync the target of a hard link, but hard links can only target the same filesystem that the link is on, so you can't target an external drive on macOS AFAIK.
I can't speak for the other software you mentioned.
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.
https://t2linux.org/
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
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.
No comments yet
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?
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]
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.