Rendered at 19:49:59 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
timsneath 5 days ago [-]
To clarify a few comments here: this is not only OCI containers: container machines add support for persistence and filesystem mounting, making container machines a great lightweight Linux environment for developers using macOS. More details here: https://developer.apple.com/videos/play/wwdc2026/389
jt2190 4 days ago [-]
> container runs containers differently. Using the open source Containerization package, it runs a lightweight VM for each container that you create. This approach has the following properties:
> - Security: Each container has the isolation properties of a full VM, using a minimal set of core utilities and dynamic libraries to reduce resource utilization and attack surface.
> - Privacy: When sharing host data using container, you mount only necessary data into each VM. With a shared VM, you need to mount all data that you may ever want to use into the VM, so that it can be mounted selectively into containers.
> -Performance: Containers created using container require less memory than full VMs, with boot times that are comparable to containers running in a shared VM.
Sounds like a lot of the same choices/compromises that are in wsl2.
sqquima 4 days ago [-]
Yes, this looks similar to wslc announced at Microsoft Build. They should have joined forces, Apple and Microsoft. Can you imagine?
parl_match 4 days ago [-]
You mean like for the first 20 years or so of Apple and Microsoft's history?
jjtheblunt 5 days ago [-]
> ... highly integrated Linux environment that works seamlessly on your Mac. ...
Which kernel is running, and is it hosted in hypervisor.framework, as is done with UTM (when not using the qemu mode)?
Scarbutt 5 days ago [-]
The katas container kernel by default.
Onavo 5 days ago [-]
Ah, the Darwin/BSD Subsystem for Linux.
CGamesPlay 5 days ago [-]
Not quite, it’s still a VM. And while it supports virtio balloon for growing RAM, it doesn’t yet support releasing that RAM back to the host. And there isn’t a convenient way to shrink the sparse disk images as they grow yet, either.
AlexB138 5 days ago [-]
Isn't the Windows subsystem for Linux (the reference there) also a VM?
gsnedders 5 days ago [-]
Only WSL2; WSL1 was an actual subsystem.
selcuka 5 days ago [-]
So this is Darwin/BSD Subsystem for Linux 2.
rvz 5 days ago [-]
Yes.
LoganDark 5 days ago [-]
WSL1 was so cool, WSL2 made it boring and isolated.
mjg59 4 days ago [-]
WSL1 was very conceptually appealing, and ended up working very poorly because of the poor matching between Linux syscalls and the Windows kernel. Git suffered terribly as a result. The inverse is also somewhat true - there have been cases where Wine is much slower than native Windows because Linux simply doesn't provide a simple way to achieve the same outcome, and interestingly the Wine developers have had reasonable (if tediously slow) success in making it possible to express the same semantics to Linux and have it handle things fast. It would be fascinating to know whether WSL1 developers didn't have enough traction to get Windows internals altered to match, or whether it's just way harder to do the same under Windows.
alerighi 4 days ago [-]
It did work quite well. The problem with the filesystem could have been solved by optimizing the Windows kernel, that would have benefit also programs run outside the WSL by the way (NTFS have performance problems and Microsoft knows, and even provided a kind of solution as far as I know with the developer FS or what they call it).
The thing that I don't like of the WSL2 is that is just a VM, but a VM that is very limited. For example working in the embedded development field I often need to use serial ports or USB devices, a thing that the WSL2 is not capable of doing (unless passing trough USB/IP that has its compatibility issues especially for stuff like debuggers needing precise timing), and that the WSL1 was at least for the serial ports able to do. This is a limitation that doesn't allow me to use the WSL. Same thing with all kind of other software that wants to access peripherals of the machine natively (e.g. a GPU for example, or another PCI card, something that to be fair is not even doable as far as I know with hypervisors on Windows but completely doable with hypervisors running on a Linux OS where trough the IO MMU you can share any PCI device of the host to the VM).
WSL1 was a great idea, bad thing that Microsoft abandoned it for something that is just good for web application development.
0x1d7 4 days ago [-]
> (NTFS have performance problems and Microsoft knows, and even provided a kind of solution as far as I know with the developer FS or what they call it)
NTFS does not have performance problems. The difference between DevDrive, which uses ReFS (arguably a more 'resilient' file system than NTFS due to journaling) and a standard NTFS volume is the file system filters are either removed or in the case of Defender, put in async mode.
The file system filter architecture is the performance problem, not the file systems. It's a trade off to have a more extensible I/O stack.
sterlind 4 days ago [-]
I recall there was also an issue with how paths are treated in NT. I don't fully recall, but I think NT paths are parsed by the kernel early on, and the whole kernel operates on "cooked" paths. there was some major performance implications this had for WSL1 in addition to the filter driver architecture.
I also don't remember why they couldn't just bypass the filter stack for paths in a certain volume - WSL2-like I/O on WSL1 - but there must have been a reason.
smallnamespace 4 days ago [-]
> The problem with the filesystem could have been solved by optimizing the Windows kernel
Over time this would tie the Windows kernel’s requirements so that they matched the Linux kernel’s due to expectations from WSL1 users. This of course is a bad idea for any engineering organization - you will have requirements imposed on you that don’t mesh well with your other non-WSL users and you also have no real sway over Linux governance. This would lead to the Windows kernel either becoming a clone of Linux or serving at least one set of users poorly.
someguyiguess 4 days ago [-]
Why would you work on embedded development through a VM? Out of curiosity.
khana 4 days ago [-]
[dead]
LoganDark 4 days ago [-]
Wine achieves better performance these days due to things like... adding a module to the Linux kernel that implements NT-like synchronization primitives. So, Linux subsystem for NT synchronization basically. (a.k.a. NTSync)
Maybe this works out better because Linux is more flexible, while Windows/NT is more "set in its ways" and therefore more difficult to implement Linux on top of... Maybe?
barrkel 4 days ago [-]
It's my understanding that a big part of WSL1 performance loss comes from the relatively thick layered filesystem architecture on Windows.
Since git and nodejs are both common in modern development and are expected to work efficiently with huge numbers of files, this was a real bottleneck and it couldn't easily be tackled without threatening backward compatibility.
TylerE 5 days ago [-]
Back in my day you to to download a couple GB worth of cygwin, and that wasn't an actual environment, basically just a GNU toolchain compiled for windows. But it got you like....grep and bash and stuff that ran natively on windows which was kinda cool.
qalmakka 5 days ago [-]
Does any older folk here remembers when NT was the Cool New Thing (TM) and it had by design support to multiple subsystems plopped over the NT API, and Win32 was just one of them alongside POSIX (Interix) and OS/2? There was even a _very short_ time span when Interix was actually usable (it was extremely short though)
naishoya 4 days ago [-]
I guess that makes me square within the 'older folk' subset - I continued to use the NT core with LiteSTEP alongside the SGI/IRIX Octane2 well after Y2K.
Those days I was working on a rework of the TRO PLATO learning system which was a real beast but essential for the individual learning project of a charter school i was supporting.
PLATO had been taken from it's dedicated mainframe world and made 'runnable' on W95 workstations with an NT server - but it really didn't run well, and the kids could really get behind the interface into regular Windows environment too readily. In combination the workstations were crazy hard to keep running cleanly.
So in the end; we had to take the software out of Windows, wash it clean in the waters of Silicon Graphics System-V with BSD extensions (X11) Unix and BSD - NeXTSTEP, just so we could bring it back to Windows properly using LiteStep.
Life happened and I lost touch with the outcome of it all, moving on to my next project; but, I kept a LiteSTEP desktop until moving entirely over to Linux in 2004.
Haven't used Windows for anything but a gaming load since '05 and stopped doing even that in about 2010, nothing later than XP.
pjmlp 5 days ago [-]
Yes, the only reason I cared for Linux in first place was that the POSIX support wasn't that good.
I am convinced that if POSIX subsystem was UNIX serious, GNU/Linux would never taken off on PC, and the whole would be divided between SGI, HP-UX, Solaris, Aix and Windows NT.
hnlmorg 5 days ago [-]
There were already better free options than Linux when Linux first started gaining traction.
The reason Linux grew in the 90s was because it was part of the hacker culture. Not because better options didn’t exist.
Kids liked the fact that Linux was a free-for-all, anything-goes, platform. It wasn’t stuffy like Unix and it wasn’t proprietary like Windows.
Then those kids grew up and became decision makers themselves. And we started to see Linux replace FreeBSD and commercial Unixes.
nyrikki 4 days ago [-]
Actually Linux was very SysV like back in the day, so it was more like the stuffy OS's that people liked.
GCC was the real catalyst, With even SUN which had used bundled dev tools as a early selling point was unbundling them and charging more, many x86 UNIXes like SCO didn't even come with a tcp/ip stack without an extra fee...and you couldn't take C code from HP to another system and actually have it compile.
As Solaris is really just a sysV-ification of the bsdish sunOs...the introduction of posix as a least common denominator, and Linux being closer to the commercial-ish unixes it was just an easier sell for a lot of users.
In hindsight it may seem silly, but in may projects I was involved with, linux using sysV /etc/init.d/, vs BSD's /etc/rc.conf was the driving factor, because /etc/rc.conf was a shared dependency and harder for us to modularize projects.
IMHO the real Linux advantage is that it was using the gnu user land, and thus gcc worked well with it and companies started to sell commercial support early.
But there were still flavor wars from all sides all the time, and being an ex-op on #unix and #unixhelp from the 1990s, I dealt with them all.
But BSD and heck even ITS etc... was the free-for-all, anything-goes, platform of record.
qalmakka 4 days ago [-]
> IMHO the real Linux advantage is that it was using the gnu user land, and thus gcc worked well with it and companies started to sell commercial support early.
IMHO what really differentiated Linux were
a. the bazaar development approach, which lowered barriers to contribution, felt more transparent and "safer" with regards to what was going on in kernel land
b. the GPL, which while annoying to certain companies due to its viral nature, it at least guaranteed that no competitor could just develop a major innovation, grab the kernel and all of your contributions and run with them, undercutting you in the process
and also a noteworthy mention was the fact the BSDs were basically sabotaged by AT&T via their nefarious set of lawsuits, which nipped in the bud any semblance of advantage they had
hnlmorg 4 days ago [-]
> and also a noteworthy mention was the fact the BSDs were basically sabotaged by AT&T via their nefarious set of lawsuits, which nipped in the bud any semblance of advantage they had
People keep saying that but I saw zero evidence of those lawsuits factoring into any purchasing decisions that customers made.
I saw Solaris SPARK servers purchased for running Informix RDBMS
I saw Solaris deployed for payroll systems running Oracle middleware.
I saw FreeBSD servers built for web hosting
I saw FreeBSD servers built for ISP backend services
But at no point in the 90s did I see anyone running Linux commercially. In fact the only reason I ran Linux (Slackware) in the 90s was to see what all the fuss was about from my nerdy younger peers on IRC. And even then, I just threw it on a desktop PC.
In the 90s you had NextStep workstations used to build games intended for PCs (like Id Software did with Doom and Quake). And used at CERN for the development of the WWW.
UNIX was the 90s platform of choice for computer animation. It was the platform of choice for multi-tenant web hosting. And so on and so forth.
Much as Linux had the cool hacker community, 90s UNIX systems had superior ACLs, containerisation, faster TCP/IP stacks, significantly more stable file system drivers and so on and so forth. So people naturally chose UNIX for their important systems. And that’s exactly the trend I personally experienced in the 90s.
This isn’t to say that I think the unix wars had “zero effect” on the decline of unix, but I do personally think the amount of impact it had is massively overestimated. I think Linux would have taken over regardless because the Linux culture embraced everyone’s weird ideas vs UNIX systems that did extensive gatekeeping. And the kids that played with Linux because it was fun and hacking was encouraged, grew up and became influential in decision making.
I think the culture of Linux had more to do with Linux’s growth than anything else.
Personally, I don’t think the license made any difference here. I do get the arguments people make about GPL, but GPL was around since before Linux and it didn’t gain significant traction then. But like most of the opinions I’ve shared above, it’s an impossible point to prove either way.
hnlmorg 4 days ago [-]
You’re talking about architecture but I was talking about development culture.
Linux encouraged people to fork and experiment with it. Whereas the FreeBSD was a carefully maintained ecosystem.
pjmlp 5 days ago [-]
Which ones? BSD was tied in a lawsuit that left doubts on its future.
Minix was a toy OS for university teachings.
Coherent was commercial.
Nothing else was there on the PC market.
hnlmorg 4 days ago [-]
386BSD and its derivatives (eg FreeBSD) weren’t really attacked by SCO like other UNIXes were. In fact SCO filed more lawsuits against Linux than they did (for example) FreeBSD.
FreeBSD was also used heavily in the late 90s in ISPs and similar domains.
nyrikki 4 days ago [-]
I think you are a possibly a decade off on the timing here.
USL v. BSDi is what impacted the BSD side, and it was during that lawsuit before Novell bought USL etc.... that the problems were that allowed Linux to make gains while the net/2 distros were in a waiting game IMHO.
The timing absolutely helped Linux and GNU being packaged as a complete system by the various distros etc..., and common OSS distribution points like Walnut Creek and PHT were very much concerned about USL v. BSDi and in an era when you had to make long distance phone calls to download with a modem, a lack of CDroms etc... absolutely caused a dip in adoption of the BSDs.
By the time the IBM v. SCO lawsuits happened (2003) the UNIX wars were long gone and Linux was already established.
SCO/Interactive/Coherent/etc... and other x86ish UNIXes were quite common in my work in the early 1990s, but the whole unix wars is way to complicated to cover in a single post.
The post .com bubble SCO lawsuits really just didn't matter much, the consolidation that happened in the early 90's that ended the UNIX wars, plus Intel killing most of the commercial unix independent CPUs with Itanium untruths and impossible promises and an inability for the major vendors to adapt to a lower margin model etc... killed those off.
The SCO lawsuits were really just the flailing of a dyeing company which was the end result of WordPerfect buying Novell with Novells money and local Utah politics.
hnlmorg 4 days ago [-]
Sorry, I don’t think my point was very clear. I wasn’t saying that SCO sued Linux in the 90s nor that the UNIX wars had zero impact.
Just that FreeBSD was still used a lot in the 90s and managed (at least from what I experienced) to dodge most of the concerns that companies had deploying other UNIXes.
I mean, it’s not like UNIX use dropped to zero overnight.
So you did see a lot of Internet companies using FreeBSD as their platform of choice. For a while, it really did look like FreeBSD was becoming the dominant server platform in that domain. Not everyone too Linux serious at that time. It wasn’t until at least 99 when Linux became a viable competitor to FreeBSD.
But once Linux did gain favour its popularity sky rocketed. Which is exactly why SCO took various Linux shops to court.
Even in that case, it was one suit and it was settled before FreeBSD was ever released.
Which simply wasn’t enough drama to persuade businesses on smaller budgets away from using FreeBSD.
pjmlp 4 days ago [-]
Those only came to be after AT&T lawsuit was cleared, and by then Linux already had enough wind behind it.
Also SCO lawsuit was more due to IBM's money than Linux.
Both a different situation than Windows NT being available a decade earlier.
hnlmorg 4 days ago [-]
You’re sidestepping my point that FreeBSD was in widespread use in the 90s.
My point about SCO wasn’t clear though. I was just saying FreeBSD wasn’t as embroiled in the UNIX wars as the others, ie referencing SCO vs Linux to demonstrate how even Linux suffered more time in the courts than FreeBSD did.
pjmlp 4 days ago [-]
Not at all, except for Hotmail and Yahoo, I never saw it being used personally.
In fact, had I not bought a set of Walnut Creek CD-ROMs, I would never had used it in first place, and never again since those days, excluding derivatives like macOS and Orbis OS.
Which is why I asserted with good POSIX support, the world today probably would be Windows NT linage on the PCs, plus the commercial UNIXes everywhere else.
hnlmorg 4 days ago [-]
You work for mainly Windows shops though don’t you?
My experience was very different in the 90s.
Solaris, FreeBSD and Next were very widely used. The only times I saw NT was in edu, government, and a random publishing house (which ran pirated copies of NT 4 on the servers and Mac OS 8 everywhere else).
That publisher is an interesting chapter in my career on its own actually…
qalmakka 4 days ago [-]
The BSDs would be much bigger today if it wasn't for AT&T going after them hard in the early '90s, exactly when both them and Linux were starting to take up speed. I think that things could have gone way different if the BSDs were bigger and more popular, in quite unpredictable ways (it's not like they haven't been popular anyway though - see Darwin, or the Playstation OS for instance)
noduerme 5 days ago [-]
Cygwin was fun. I'd done zero development on Windows, but about 10 years ago I had to figure out how to deploy some nightly shell scripts across a bunch of local computers in a few dozen offices, where about 80% were MacOS and the rest were Windows. I don't remember exactly how I rigged it, but basically cygwin allowed me to keep the scripts as they were and trigger them in place, with a few small modifications.
I never want to deal with that again ;)
[edit] fwiw, Termux on Android is similarly a fun pseudo-environment. It's a nice and helpful toy.
TylerE 5 days ago [-]
The biggest issue I remember is directory seperators... windows of course using \ which bash would then interpret as an escape. Cygwin mostly papered over that from what I can recall, but it could lead to some weirdness, like sometimes you'd get C:\\path\\es\\like\\this
bschwindHN 5 days ago [-]
We should be using the baguette emoji for path separators for cross-platform compatibility.
You could also use forward slashes, like C:/path/subpath, which has worked since Windows 1.0/DOS 2.0.
That's handy when you're entering paths in a Cygwin/MSYS Bash shell, but might not help much if you're trying to parse or otherwise work with existing patgh variables composed with backslashes.
TylerE 5 days ago [-]
Yes, you could if you were entering them manually, but some apps that generated file names would screw it up. I think they were using some sort of stdlib function to get the path seperator. Forward slash paths working in native windows apps also wasn't quite a given, either. Keep in mind this was a loooong time ago... like windows xp era maybe, even.
noduerme 5 days ago [-]
Yeah, I recall directory paths being the biggest PITA with running scripts in cygwin. But I mean, that was a very minor set of things to fix compared to what would've had to be written in anything else available at the time.
Doing retail office deployments of custom code on employee computers is a weird niche, and you find whatever works and hope you can maintain it somehow. Cygwin was awesome though, saved me a ton of time and the client a lot of money for the moment. (The client later stipulated to all future franchisees that they had to buy only Macs, lol)
coldtea 4 days ago [-]
Always used / and it worked for both cygwin/windows lands.
kergonath 5 days ago [-]
> Back in my day you to to download a couple GB worth of cygwin
You still can, and it still works exactly the same way.
procflora 4 days ago [-]
It's true, but to be honest the MinGW-built stuff that ships with git for Windows has been enough since WSL took off.
iririririr 5 days ago [-]
what do you mean? that's still the only way to work as a human in windows. wsl1 almost replaced it, but obviously they scrapped it.
if you must use windows, it's because you will compile for windows. so you install MSYS, which is a linux distro-ish compiled native for windows. and do your work.
wsl2 (and this apple thing) is just a meme. if you're working in it, you're better of just installing Linux or ssh'ing to a server.
metaltyphoon 4 days ago [-]
> wsl2 (and this apple thing) is just a meme. if you're working in it, you're better of just installing Linux or ssh'ing to a server.
Many enterprises allow windows only so your way into Linux is via WSL2
oso2k 4 days ago [-]
There is also git-bash which usually doesn’t need to have administrator to be installed.
> Also everyone on FOSS gets it wrong, WSL wasn't a subsystem like classical Windows NT ones.
Everyone in FOSS? How about Microsoft got it wrong, since they actually named it The Windows Subsystem for Linux (WSL)? It wasn't the FOSS community who chose the name for them.
pjmlp 4 days ago [-]
What has that to do with a version number and not keeping up with the times?
embedding-shape 4 days ago [-]
What version number? WSL1 vs WSL2?
I'm not sure if you see the quoted part. My comment is about the part that starts with "> " that you wrote earlier.
alerighi 4 days ago [-]
And a limited VM, for example I look at the documentation and it's not possible to share USB devices with the VM, making it perfectly useless for doing embedded development where you have to connect to the boards with USB. I will continue to use UTM for that reason...
mrpippy 4 days ago [-]
Virtualization.framework just gained USB passthrough support in macOS 27. It might be a niche feature for containers to add, but other VM software will likely add support soon.
jayd16 5 days ago [-]
Mac Subsystem for Linux 2
BodyCulture 4 days ago [-]
This is not a problem at all as most Apple computers come with plenty of RAM and lots of disk space! We are so lucky that Apple engineers always think so differently into the future!
burnte 4 days ago [-]
WSL is a VM too, but that's still what this is. WSL for MacOS. It's great!
hedora 4 days ago [-]
So, heavier than running docker in qemu?
pseudosavant 5 days ago [-]
Exactly what I thought. The Mac equivalent to WSL. Which is a great thing for Mac devs. Lots of stuff expects Linux these days, not POSIX. Mach isn’t Linux.
bogantech 5 days ago [-]
> filesystem mounting
How is this different to bind mounts
jdub 4 days ago [-]
Very different: Linux running in a virtual machine can't bind mount into a macOS host's filesystem. So they use virtiofs.
miohtama 4 days ago [-]
MacOS container filesystem/IO has been bog slow preventing even some basic dev container use cases. Hopefully this will fix the issue.
jdub 4 days ago [-]
It's not substantially different from previous approaches (9pfs vs. virtiofs).
My suggestion: Don't use the host filesystem from the guest at all. It'll be faster, and better isolated. It's a false convenience.
AtlasBarfed 4 days ago [-]
sshfs?
jdub 4 days ago [-]
That's a less efficient protocol than 9pfs and virtiofs, even if you subtract the encryption.
An example of improving efficiency: virtiofs has a relatively recent feature to map pages from host memory directly into guest memory, but that's a lot of risky acrobatics if your priorities are reliability and isolation...
... but it's not supported by Virtualization Framework's built-in virtiofs "folder sharing". (sad face)
... but someone could build it on top of the new macos 27+ custom virtio device support. (intrigued face)
lxgr 4 days ago [-]
This applies to both containers and container machines though, right?
jdub 4 days ago [-]
Containers (those popularised on Linux by Docker) are built on Linux primitives like cgroups and namespaces, so they're running directly on the same kernel, same VFS, often the same FS, etc. Their isolation properties rely on (a) all those Linux features working as expected, and (b) the container runtime setting them up properly.
Depending on your threat model, that's fine, but a lot of people (including me) will say that containers are not a security mechanism.
But macOS requires[1] virtualisation for containers anyway; the security is just a bonus.
[1] at least for a real Linux kernel...
lxgr 4 days ago [-]
The surface of an OS is definitely larger than that of many hypervisors, which is e.g. why browsers often provide their own much narrower sandbox.
On the other hand, in other scenarios, people trust the security boundaries of their working as expected all the time, no? This is the basis of e.g. Android app isolation (every app runs under its own Linux UID/GID), and true multi-user Unix systems trusting the OS's security boundaries to hold have decades of history.
jdub 4 days ago [-]
Different threat models. Your typical Android device (and Linux server for that matter, at home or at scale) is not usually running security-sensitive general workloads for multiple tenants in the same OS instance. :-)
fc417fc802 4 days ago [-]
I don't think that's right. The threat model for Android for example could well be a malicious third party leveraging a vulnerable app to gain access to your banking app on the same device. There's definitely (meant to be) a security boundary between apps.
jdub 4 days ago [-]
These are all security boundaries of a kind, some more effective than others, balancing priorities according to threat model. Running every app on your phone in a hardware virtual machine would be... an expensive choice.
oulipo2 4 days ago [-]
how does that compare to something like, eg, Orbstack?
5 days ago [-]
CaptainCyber99 4 days ago [-]
Still feels like a apple-ified microvm
TingPing 4 days ago [-]
Well yeah it’s a simple vm…
Melatonic 4 days ago [-]
Basically is it sounds like
golem14 5 days ago [-]
I belong to a rare breed of very opportunistic hobby-developers that like to use MacOS but also like to use linux machines or BSDs (rpi etc) sometimes.
I can create docker-images with docker compose, or use something like colima, which this seems to be close to (that should have some advantages over docker, although my hope of circumventing W^X page protection did not pan out).
I was perplexed that the repository does not put these container machines in context. The seem to be close to colima? When should I use which option (docker, collima, container machines ?)
Maybe others wonder too but are ashamed to ask. I have no shame ;)
Like, this doesn’t answer when to use this vs Docker. Any reference there?
happyopossum 4 days ago [-]
This is not the apple container framework / that’s the docker alternative. This is a project to easily run full Linux machines in macOS containers.
cowsandmilk 4 days ago [-]
Use this because docker has very problematic licensing on MacOS.
golem14 4 days ago [-]
[flagged]
qalmakka 5 days ago [-]
This is all fine and dandy, but where are the native Darwin Jails Apple? Still scared that people will filling whole rooms of Mac Minis if you allow them to have multiple macOS containers and not only up to two fat VMs per machine?
cedws 4 days ago [-]
Darwin namespaces would be much more interesting and we are in dire need of them in the current security landscape.
I don’t really understand the hype for Apple’s Containerization, it’s just another container runtime alongside many others. It’s not really any better than OrbStack - in fact it’s worse.
RationPhantoms 4 days ago [-]
Thank you for answering that question because I adore OrbStack and didn't find much difference.
whimblepop 4 days ago [-]
When Apple Sherlocks something, aren't their implementations usually worse? Typically the thing being Sherlock'd is very mature and featureful, and Apple's implementation is much less capable and has undergone much less user testing, at least at the outset.
gyoridavid 4 days ago [-]
+1 I'd love to have network namespaces
4 days ago [-]
jorisw 5 days ago [-]
[Replied to wrong comment]
qalmakka 5 days ago [-]
That's totally unrelated to what I wrote
tonymet 4 days ago [-]
You would want a layer above darwin, e.g. Foundation, Appkit -- all the stuff that runs the full MacOS. but good idea overall
adastra22 5 days ago [-]
sandbox profiles?
qalmakka 5 days ago [-]
macOS sandboxing is deliberately limited just enough to prevent anyone from truly implement Darwin-on-Darwin containers. People have been discussing about this for a while, see https://github.com/apple/container/discussions/611
In general I understand the rationale behind Apple's decision. They sell hardware, and there's real demand for macOS on servers to run build jobs and other Mac-only tools. Giving you the ability to run multiple containers on a single Mac would end up turning a 10 Mac Mini order into a 2 Mac Minis order for most people. Rest assured, even if it would be technically possible they'd find a way to cap it somehow via the EULA or whatever
coldtea 4 days ago [-]
I doubt this insignificant statistically speaking market (compared to the overall units they move) is what prevents them.
inejge 4 days ago [-]
Domino theory as applied to business, plus one should never underestimate the lengths to which a company will go to wring the last ounce of profit from a market.
larodi 4 days ago [-]
and how is this, having containers run hardware one owns, a bad or even shameful idea, given people do it and want to do it with their hardware all the time?
qalmakka 4 days ago [-]
> aving containers run hardware one owns, a bad or even shameful idea
what? it isn't, it's absolutely a right you surely have. The problem is that
a. Apple forces people to buy Macs to build, notarise and deploy iOS and macOS apps
b. Apple refuses to implement jails which is something that every OS, including Windows, has nowadays
c. Apple only allows you to have 2 VMs - full, fat, with GUI - on each Mac computer, running at once
c. Jails/Containers would allow you to easily deploy multiple jobs, which would allow you to have N jobs in parallel, which would mean you'd need way less Mac Studios/Mini in your local CI
blahgeek 5 days ago [-]
OrbStack works really well for me. I wonder how it’s compared to this performance wise
kdrag0n 5 days ago [-]
(OrbStack dev here.) Instead of Virtualization.framework, we have a custom Rust virtualization stack with custom devices and protocols for things like filesystem sharing. It's a highly optimized vertically integrated stack specifically for running our Linux machines and containers.
Our biggest perf/resource gain is dynamic memory, which reduces memory usage a lot by releasing unused memory back to macOS. Nothing else supports this, including Containerization.
I gave Container Machines a try and it seems to be much closer to OCI containers with a default bind mount than OrbStack machines. It has fewer integrations and doesn't run systemd or any other normal init system, so it's hard to run services.
egernst 5 days ago [-]
Thanks for the info kdrag0n! Big fan of OrbStack; good call out on dynamic memory.
Just to give a thumbs up to you and OrbStack. I've been using it every day since the first releases, and it is one of the most stable and performant drop-in replacements that I've seen.
kdrag0n 4 days ago [-]
love to hear it!
mescalito 5 days ago [-]
Super happy orbstack customer. Just curious on your statement:
> I gave Container Machines a try and it seems to be much closer to OCI containers with a default bind mount than OrbStack machines. It has fewer integrations and doesn't run systemd or any other normal init system, so it's hard to run services.
The linked md document says:
> Real Linux services for testing. Run a database or whatever your stack needs as a system service — systemctl start postgresql works on images with systemd installed.
Was that not the case when you used container machines?
kdrag0n 5 days ago [-]
That's my bad, I used the example alpine commands and the official alpine doesn't have init. It's supported if you build an image with systemd installed
kxxx 5 days ago [-]
Apple says that `systemctl` is supported... hmm am I missing something?
"Real Linux services for testing. Run a database or whatever your stack needs as a system service — systemctl start postgresql works on images with systemd installed."
kdrag0n 5 days ago [-]
Good catch, I tried the example alpine commands and there was no init system. Makes sense if it's based on OCI images
kxxx 5 days ago [-]
Just tested it on on an OCI image with systemd and it works well. I can see the appeal of OrbStack regarding memory reallocation and will stick with it in the time being :)
d3v1an7 5 days ago [-]
just adding a 'hell yeah: orbstack is so good' to the thread. i mainly avoid containers where i can, but when containers need to happen, orbstack is 'just enough' for me. lovely and well considered ui, stable, performant. don't need much else. thank you for your work and care!
CGamesPlay 5 days ago [-]
> Our biggest perf/resource gain is dynamic memory, which reduces memory usage a lot by releasing unused memory back to macOS. Nothing else supports this, including Containerization.
Wow, missed this when reviewing OrbStack. I assumed that you just used Containerization and therefore would have the same limitation.
saltamimi 5 days ago [-]
I know this is off topic, but I do thank you for your Android work, the idea and elegance of fastboot.js and that SafetyNet workaround trick was truly really cool.
kdrag0n 5 days ago [-]
Ahh those were good times, glad you came across it :)
rswail 5 days ago [-]
I changed over to Orbstack just for local builds and it is one of those apps that makes owning a Mac that much better.
This post reminded me to buy a license, just done it, worth it for the time saved.
trueno 5 days ago [-]
just dropping in to say orbstack super owns and i use it every day. huge respect to rethinking this experience, for a minute there i thought docker was just going to be the only path. i dont think ive looked back for docker since. orbstack just feels right, and damn its so fast and good with resources, and the UI is just insanely straight forward. props!
TheTaytay 5 days ago [-]
We love OrbStack too! Thank you for it,
I wanted to make its VM/machine our default secure agent sandbox, but I couldn’t figure out how to isolate this VM from the host properly. This thread prompted me to find the issue though, and I saw this was recently implemented!
https://github.com/orbstack/orbstack/issues/169
kdrag0n 5 days ago [-]
Yep! Still refining it but isolated machines now have fine-grained settings for filesystem mounts, network isolation, SSH agent forwarding, and CPU/memory/disk limits
jhancock 5 days ago [-]
I’ve been using podman on Mac. It’s been a nice fit as the container build files are identical to what I use on my fedora server. I have noticed my 2 virtual core 4 gb Linode vps runs apps faster in the same container as when run on my MacBook Air M2 16 gb. I expected some performance overhead but didn’t think it would be noticeable as it is. Overall happy with podman. How might OrbStack differ?
thatxliner 5 days ago [-]
Having used both, it feels like OrbStack "just works" more than Podman. The main example of this is Supabase.
torarnv 4 days ago [-]
Those are awesome features! The one missing for me is bridge networking. Any idea why orbstack doesn’t have that?
What kind of virtualization do you use internally? I assume some kind of LXD fork? OrbStack really feels like a single-node Incus host.
kdrag0n 4 days ago [-]
The Linux VM host and guest components are all custom, as well as the daemon that manages machines. It currently uses LXC as the runtime but that's being replaced as well. For containers we run a standard Docker engine inside a special machine.
vsgherzi 5 days ago [-]
I love orbstack, is there any code I could read on the rust side? Seems very interesting
blackqueeriroh 5 days ago [-]
When are y’all gonna support sandboxing? Preferably Docker Sandboxes?
Tart was just bought by OpenAI so its future is suspect.
mpeg 5 days ago [-]
I like orbstack in theory, but I find it hard to justify a $96/yr license fee for something that has so many open source, free alternatives. As it is, I’d rather use podman or colima
Ghoelian 5 days ago [-]
It's free for personal use, and for a company 96/year is absolutely nothing, I'd hope.
baq 5 days ago [-]
The alternatives are all broken in some ways is the answer, including the official paid docker enterprise.
Personally I’d rather the company provisioned me MacBook hardware with Linux. Unless Fable or some other ai ports asahi properly to modern hardware I expect to retire before this is possible, orbstack is the next best thing, available today.
kxxx 5 days ago [-]
I really like OrbStack and am also not sure why I'd use Container Machines over it, at the moment...
pojzon 3 days ago [-]
OrbStack still uses a single big VM, Container Mashines each spawn its own MicroVM. Isolation level on Container Machines is better from that point of view.
cpuguy83 5 days ago [-]
Not a full docker env, I aimed this as doing builds though you can run dockerd as an option, https://github.com/cpuguy83/crucible uses the containerization framework to run either build kitd or dockerd and wire it up to docker/buildx cli (or whatever client tooling you want to use).
The Containerization framework is a library that sits as a layer on top of the virtualization framework.
So each container is its own VM.
Machine is tooling above the containerization framework to run multiple things in a container in a vm.
gempir 5 days ago [-]
I just wish bind mounts would be more performant/native. I get that this is probably impossible, and probably also sucks on Linux, haven't tried.
But like having containers that need file watchers like vite dev server, or frankenphp in watch mode will overload OrbStack real quick since It seems to fallback to polling instead of listening to fs events.
So I'm stuck running vite dev servers and the like on the host.
kdrag0n 4 days ago [-]
Can you share more details? OrbStack has always supported inotify/fanotify (Linux fs watching APIs) on bind mounts and most people use watchers with no issues. Happy to look into whatever you're running into: danny@orbstack.dev
gempir 4 days ago [-]
I'll remember it and email you when I try it again.
Last time I tried all of orbstack froze and I had to restart my whole mac to fix it. But you also did some recent releases that fix issues related to freezing up, so maybe it was unrelated.
Thanks for the great software! Happy enterprise customer
jnewton_dev 4 days ago [-]
We dealt with this exact issue at my company. The root cause turned out to be something completely unrelated to what we initially suspected.
gempir 4 days ago [-]
Hmm, that sounds very vague. how DID you solve it? Do you now run Vite dev servers in containers?
kiproping 5 days ago [-]
Thank you for mentioning this, I have been suffering under the yoke of docker.
garganzol 4 days ago [-]
Orbstack is essentially a happy-path-only contraption that quickly breaks once you happen to take a less visited corner of the street. For example, if you happen to have multiple users who needs to work with it... good luck trying to clean up your system afterwards. So, it's a yoke as well. Maybe a better one for some people, but still a yoke.
jbverschoor 5 days ago [-]
Note that orbstack supports audio and usb pass through, which is super nice
WatchDog 5 days ago [-]
Do these containers share a common kernel? Or are they each ran in a separate VM?
Isnt this a micro VM and not a container? Confused
pjmlp 4 days ago [-]
A micro VM than encapsulates a single container inside, two levels of protection.
kenanfyi 4 days ago [-]
I don‘t understand why these tools always advertise about mounting the $HOME inside the container. Isn‘t it better to have a complete isolation? Isn‘t that the point of using such a thing?
sigmoid10 4 days ago [-]
Containers only got so popular as a tool for developers to make developing/deploying easier. If you want to use them as a security layer that is a completely different goal and has many highly dangerous pitfalls [1]. Just last week there was a post where people were shocked how an AI agent used docker to bypass sudo on a system. I'd imagine this could happen to most people who installed docker. So if you want to use containers for anything but easier development, you need to be much more proficient than the average user already. In that case not exposing $HOME is just a small thing on your config to-do list.
> Just last week there was a post where people were shocked how an AI agent used docker to bypass sudo on a system.
This was due to implicitly granting the LLM access to the host docker daemon, which has superuser privileges, not due to a "container breakout". That's arguably a very different scenario, but of course both are worth considering.
> So if you want to use containers for anything but easier development, you need to be much more proficient than the average user already.
I'd disagree. Containers, at least without granting them additional privileges such as CAP_NET_ADMIN and without write-bind-mounting sensitive host directories into the container, offer a reasonable security boundary compared to the counterfactual, despite their bad reputation.
sigmoid10 4 days ago [-]
>without granting them additional privileges such as CAP_NET_ADMIN and without write-bind-mounting sensitive host directories into the container, offer a reasonable security boundary compared to the counterfactua
There's much more to it than that if you check out the link above. Misconfiguring a container is the 2026 version of misconfiguring FTP and MYSQL in the 90s. I.e. most users don't even know how they are asking to get rooted.
lxgr 4 days ago [-]
If you let your container write setuid binaries to your path, give it admin access to your network, let it access the Docker daemon socket etc., sure, you're going to have a bad time. But how is that different from e.g. giving software running in a VM SSH access to your host or a writable bind mount to the host's root directory?
fc417fc802 4 days ago [-]
Yeah all of that stuff seems reasonably obvious. If you fire up a default unprivileged container with a network adapter but no other affordances it shouldn't have any holes. (If it does those are either runtime or distro bugs.)
AFAICT all the security problems are fairly obvious own goals inflicted after that point.
kenanfyi 4 days ago [-]
I see. Why this interests me is the similar stuff I have been reading lately. All these supply chain attacks regarding npm, Tanstack etc. Therefore I wanted to create a totally isolated sandbox and while considering options I have seen they all by default mount the $HOME. I needed to explicitly tell colima to not do that.
But yeah, I guess my use case is not the main use of such tools or their purpose in general. Thanks for the link, I‘ll take a look at it.
pojzon 3 days ago [-]
Im currently working on an article about this very topic. And its amazing how hard and multi-dimensional agent sandboxing. LLMs architecture is by design insecure. Working with something like this and making it secure to run in production is extremely interesting topic.
LoganDark 4 days ago [-]
No, the point of using such a thing is to be able to run Linux workloads. For example, I recently used Containerization to generate trace logs from the tup test suite so that I could bring it up to relative parity on macOS. If it had complete isolation, I would have difficulty getting the modified source code into the container and difficulty getting the trace logs back out of the container. Sure, you can paper over this with bind mounts or whatever the fuck but that's annoying
kenanfyi 4 days ago [-]
Understand. And yeah that‘s annoying. I use containers only for development and to keep my main system secure from supply chain attacks. I have almost no build tooling in my Mac anymore. No npm, no cargo, no uv. Nothing. They all live inside the container which is completely isolated.
I guess my use case is not that important for the main user of these tools.
LoganDark 4 days ago [-]
I wouldn't say your use case is not important. That is a completely reasonable way to work. I just wouldn't say mounting home directories is an anti-feature. There just should be a way to turn it off.
kenanfyi 4 days ago [-]
Well, maybe I should have used relativity unimportant. And yes there should be a way to turn them off. In OrbStack it was not possible to do that until lately.
saljam 4 days ago [-]
the reason i use this (and just a container with -v $HOME:$HOME before) is to get an environment with all the command line tools i'm familiar with from debian, instead of using something like homebrew. in general, i mostly trust these with access to my home directory. a bonus is that i can throw it away and rebuild it easily if i need to.
i'd still use less permissive containers for things i don't feel comfortable installing on the host, e.g. npm.
stefan_ 4 days ago [-]
No, the whole point of machines is their external interfaces? A Linux VM with no interfaces is just a closed box wasting power doing math.
And I think I would caution Apple to consider the lessons of WSL; having shared access to the filesystem is just the bare minimum. Next is networking (and god is this a rabbit hole with WSL), people will want to access their USB devices, X forwarding, GPU passthrough..
coldtea 4 days ago [-]
The whole point of container machines is their isolation.
If we wanted access to all interfaces, we'd just run it locally.
We want the container as a closed box, "wasting power doing math", i.e. processing what we actually passed to it.
jlhawn 4 days ago [-]
Michael Crosby wrote this! He's a long-time maintainer of Docker, Containerd, and more! He was Docker's first to receive the 'Distinguished Engineer' Title. This means a lot coming from him.
jaimehrubiks 5 days ago [-]
Will this be able to replace docker desktop an equivalents, removing the expensive Linux VM that runs alongside them?
usernametaken29 5 days ago [-]
My first thought as well, docker desktop overhead is pretty bad, would be awesome to see this land natively in DD. By my estimate this could happen, seeing as Docker has historically tried to improve performance but quickly had to accept platform limitations… would only be natural to settle DD over to containers
deathanatos 5 days ago [-]
Well, you can avoid the Docker Desktop tax by not running Docker Desktop. colima is a perfectly usable implementation of Docker for macOS, without the bloat of Docker Desktop.
That said, colima still has the expensive VM that upthread is mentioning.
TimTheTinker 5 days ago [-]
OrbStack is great also
noname120 3 days ago [-]
I agree, it’s so much better than Docker Desktop, Podman, and Colima. And not just by a small margin, it feels several orders of magnitude faster and more lightweight thanks to its WSL2-like architecture.
CarlitosHighway 4 days ago [-]
until they remove the free tier and raise prices, once their user base is sufficiently reliant on it.
TimTheTinker 4 days ago [-]
I had no idea they have a free tier. I've been paying for a couple of years and it's been so worth it.
phinnaeus 5 days ago [-]
Postman Desktop too
rawland 5 days ago [-]
You mean Podman Desktop?
phinnaeus 5 days ago [-]
Yes, thank you iOS autocorrect.
lxgr 4 days ago [-]
This explicitly provides a Linux VM, which seems hard to do without providing a Linux VM.
The use case is actually the opposite of what you seem to want (i.e. running Linux containers on macOS without a Linux VM); this uses a Linux-based container implementation of macOS to provide a long-lived Linux VM that looks more like a VM itself than a container.
thejazzman 5 days ago [-]
It mostly removes the big shared background VM and replaces it with smaller, more isolated Apple-native VMs.
TL;DR reduces ram/storage usage; minimizes it's existence
deathanatos 5 days ago [-]
How does that work, realistically?
> Memory defaults to half of host memory
That's the most expensive part of the whole transaction, b/c AFAIK, RAM is then dedicated to the VM. It can be swapped out, I suppose, but that's not great.
MBCook 5 days ago [-]
CGamesPlay said above its balloon memory so it won’t use all that memory by default, but it can’t release balloon memory yet.
nozzlegear 5 days ago [-]
Nice, thanks for this. My plan is to swap over to Apple's containers for local dev, and keep using podman quadlets in production.
binsquare 5 days ago [-]
Linux VMs on doesn't have to be expensive!
lostlogin 5 days ago [-]
Others here mention it and I’m a new convert to Colima.
The pain of working around Docker Desktop is bad.
trollbridge 5 days ago [-]
That sure would be nice. I seem to rm -rf ~/.colima every few days.
prmoustache 4 days ago [-]
this is more like toolbox/distrobox equivalent for MacOs, but running in individual VMs.
5 days ago [-]
Igor_Wiwi 4 days ago [-]
Interesting from a Docker perspective, but I’m more interested in it as a sandbox for AI agents and untrusted code execution.
Feels like the spiritual successor to sandbox-exec, but with VM-level isolation.
avel 4 days ago [-]
Yes, that article states that as well under limitations: "Deprecation status: While functional, Apple discourages its direct use in favor of App Sandbox for developers."
So essentially both macOS and Windows now heavily support developing using Linux on them. They can't more openly admit that they are no match for Linux in that area.
There's some clever advertising in it for Linux, if Linux was advertising.
rahkiin 5 days ago [-]
I’d argue they both admin that Linux servers are the target for a lot of applications to run on.
Not to develop on.
artistonn 4 days ago [-]
Linux also can't openly admit that it's no match for macOS/Windows on the desktop, which is why we have this hybrid situation - macOS/Windows desktops running Linux VMs
krzyk 4 days ago [-]
Unfortunately there are more and more users on Linux and as a result windowsization/macosization of Linux is in progress (systemd, wayland, some scary stuff Poettering is doing with boot, snap/flatpack).
cromka 4 days ago [-]
How is that a problem? Both systemd and Wayland helped tremendously in unifying Linux for desktop use, which together with Flatpak enable more 3rd party software to get official support. Yes it adds complexity but it's all still developed in an open fashion and you get very good insight into how things work. With Windows and macOS you have no clue what's happening in the background, or very little.
krzyk 4 days ago [-]
It is done in the open, but it adds complexity and it removes that made Unix/Linux great - composability, variety and replaces it with corporate introduced "stuff". And any distro is forced to support those additions because corps owning Fedora, Redhat, Ubuntu just rule the Linux world, and event Debian gives up.
As long as there are just few "normies" using Linux, it is safe from corporations adding their "security", "safety" etc.
cromka 4 days ago [-]
The point is you NEED those things if you want wide adoption of Linux, which, in turn, is a necessary condition for commercial software to get ported over to Linux. You just can't have both. We need a middle ground I believe 2026 desktop Linux is exactly that: a good compromise.
hedora 4 days ago [-]
You can still run devuan. I highly recommend it, though FreeBSD got really good over the last few years, and is even more insulated than devuan is.
I currently have one systemd infected machine, two devuan machines and two freebsd. Next step is paving the systemd one (it randomly craps out) and probably putting FreeBSD on it, but I’m on the fence. It’s a family member’s machine, and devuan is less change.
fc417fc802 4 days ago [-]
Guix is also an option.
regexorcist 4 days ago [-]
This is a tired cliché. Today, a modern Linux desktop like KDE Plasma just works and more importantly, gets out of your way unlike obnoxious MacOS and Windows. Aside of that you get the most advanced OS in the world where the thing being discussed here is a decade old.
QuiEgo 4 days ago [-]
The issue with Linux isn’t the software, it’s the hardware. Apple Silicon Macs are still the nicest laptop hardware by a huge margin. All the Linux-native options are, at best, “okay”.
regexorcist 4 days ago [-]
Agreed, the Linux laptop story is pretty dire compared to Apple hardware. My travel laptop is an M1 with Asahi.
cromka 4 days ago [-]
Same here but after 4 months with Asahi on M1 I wouldn't trust it fully. Had 3 freezes/reboots so far and WiFi often hangs on resume to the point I need to rmmod/modprobe.
ActorNightly 4 days ago [-]
Mac OS is adding support because they realize that they are gonna miss a good portion of consumer base to windows laptops running on Nvidia Spark since people can get the perfect machine for gaming and dev.
The big thing with Windows laptops is historically, they were slightly more sluggish than Macs because the os/hardware wasn't optimized. On desktops with enough performance, Windows has been king ever since WSL2, considering you can do everything with that system (WSL2 can even run I3WM if you care enough since they have an X server).
Now with Spark and ARM, you can pretty much get a perfect laptop that supports gaming as a first party, can run any windows only software (like CAD for example), and also has WSL2 which is very natively integrated with windows to where it supports CUDA with native like performance.
A
plutokras 5 days ago [-]
Enterprises would do anything to develop on Linux except using an actual Linux distro.
pjmlp 4 days ago [-]
Not really, this means the complete defeat of The Year of Linux Desktop.
Linux games depend on Windows ecosystem as their content source.
By having Linux nicely packaged in containers, they get to keep the 90% combined market share, almost no one bothers to support the market of Linux OEMs selling pre-installed Linux desktops and laptops.
The other "distros" used by consumers are Android, WebOs and going forward Googlebooks as Chromebooks evolution.
Meaning in the end a Pyrrhic victory, when Apple Linux, Microsoft Linux, Google Linux, Asus Linux, LG Linux, is all that the general public cares about, and hence no incentive for IT departments to support Linux laptops.
neop1x 4 days ago [-]
A lot of devs needs to use linux but they still use it just as a VM (Mac) or in some kind emulation (WSL). How pathetic.
cromka 4 days ago [-]
If they need to, it's because it's their work computers. Otherwise it's a choice.
nozzlegear 4 days ago [-]
What's pathetic?
0xbadcafebee 5 days ago [-]
Anyone know why you would use this instead of QEMU+Lima+Colima+Docker/containerd? The latter works on multiple OSes, has a very large ecosystem of tools, images, documentation, and lets you replace pieces as needed
CarlitosHighway 4 days ago [-]
From a layman's POV ("I just want to run my containers I need for dev work"), there's no point in switching to this for now. It's just cool that Apple cares enough about containers and might come up with an Apple-like built-in solution some day, this is the groundwork.
I'd stick to Colima, or Orbstack if you trust them enough to not do a rug-pull once their users are reliant on them enough to pay any amount.
lxgr 4 days ago [-]
QEMU has worse performance than Apple's native virtualization framework on macOS, for one thing. That said, Lima supports the latter as well.
einsteinx2 4 days ago [-]
Yeah I was gonna say I use Colima with Apple’s virtualization framework (it’s not the default for some reason but it’s a single command line flag), and found it works better than QEMU (better performance and resolved some bugs I was running into with the Supabase docker stack)
mkagenius 5 days ago [-]
Apple containers are great for providing a sandbox to your AI coding agents
I have made it a MCP so that it's easily discoverable by all the coding agents
So are there any benchmarks that compare all containers / docker / Lima / Colima / virtual box / VMware / orbstack and others ?
rakel_rakel 5 days ago [-]
It's funny that the system config page (https://github.com/apple/container/blob/main/docs/container-...) lists pebibytes for RAM configurations... in this day and age where buying a 16GB stick for workstation would cause me to eat instant ramen for a couple of months because my dentist needs an LLM chatbot on their page to stay competitive!
UX wise it looks kinda neat though!
borborigmus 4 days ago [-]
Signed in just to say LoL at the dentist comment.
llimllib 5 days ago [-]
Is this new? I thought we had this already
In my testing (iirc) filesystem performance was not good enough to be usable with node/rust dev where lots of small files get stat-ed
Curious if you've tried OrbStack? There's always more work to do (test workloads appreciated!) but we've put a lot of effort into optimizing for small files and other common developer workloads in OrbStack's customized filesystem sharing protocol (not standard virtiofs).
ahknight 5 days ago [-]
Podman is on macOS, FWIW. Uses the existing container framework to run the machine already. Root-full or not.
dchest 5 days ago [-]
Did you use their volumes for node_modules or a shared dir? I mounted the whole project directory (with node_modules) inside the container and it seems to work fine (MBA M1 8 GB RAM).
noobcoder 5 days ago [-]
The costs are startup time and image compatibility: dockerhub images don't work as machine images because container machine expects systemd
I am trying it on but its brekaing on homebrew 1.0.0. The formula puts plugins at opt/container/libexec/container-plugins/ and the apiserver looks in libexec/container/plugins/
This can be solved through a symlink or smth
masklinn 5 days ago [-]
> dockerhub images don't work as machine images because container machine expects systemd
Are you sure about that? A few comments above a commenter states that they don’t run inits at all (because they ran alpine), multiple people replied that it works fine if you give it an image with an init, and they acknowledged their error.
cogman10 5 days ago [-]
Is there any reason why macOS doesn't try a WSL1 style approach? I get why that didn't fully work out for windows, but it seems like macOS being another *nix would make a lot of what was hard for windows, easy for mac. It seems like it should be possible to run most linux applications natively on macOS with few additional new APIs.
BSD actually has this already.
qalmakka 5 days ago [-]
FreeBSD has Linuxlator because there is a lot of binary only software that was never and never will be ported to BSD, so it's necessary for them in order to avoid bleeding users away. Conversely, macOS has basically all software ported natively to it, so when you _need_ a Linux environment 95% of the time it isn't because you need $XYZ that only run Linux, but because you need a proper Linux environment with systemd, cgroups etc. Implementing that stuff on top of XNU would probably be extremely expensive and it would arguably defeat the point of having their own kernel in the first place.
cogman10 4 days ago [-]
> Implementing that stuff on top of XNU would probably be extremely expensive and it would arguably defeat the point of having their own kernel in the first place.
I'm not sure how it'd defeat the point of having their own kernel.
As for cost, possibly, but it would really be a huge boon to macOS for software devs. It's hard for me to believe that Rosetta isn't similarly costly, but it's been done because running x86 software is still very much a necessity for MacOS.
qalmakka 4 days ago [-]
> I'm not sure how it'd defeat the point of having their own kernel.
Because then you'd need to both maintain your kernel AND your own implementation of the Linux ABI, an ABI you don't have control over and that basically forces you to reimplement half on Linux in the first place.
People already get what they want by having a tiny Linux machine running at native speed. In 2026, virtualisation still isn't free, but it's pretty darn close.
cogman10 4 days ago [-]
> Because then you'd need to both maintain your kernel AND your own implementation of the Linux ABI, an ABI you don't have control over and that basically forces you to reimplement half on Linux in the first place.
A very large portion of that ABI is already implemented due to both systems being POSIX. But further, a lot of what programs actually interact with is already ported to macOS. For example, you can build and use glibc.
Also, I get the lack of control, but that really isn't a major issue. The linux kernel pretty rarely adds new userspace additions. By and large the majority of work that goes into the kernel is around new drivers and fixing drivers. Even when there's kernel level features, it's very often not a userspace thing but rather things like new schedulers.
There's a reason MS didn't see the same approach as being too terribly crazy with WSL1, and those are very different systems. Heck, there's a reason cygwin continues to exist and work.
qalmakka 4 days ago [-]
> A very large portion of that ABI is already implemented due to both systems being POSIX.
POSIX provides an API, not an ABI, and that API kind of ends at libc. Being compatible with Linux at an ABI level means being able to provide the same syscalls in the same way as Linux does. Not all Linux syscalls map cleanly to POSIX APIs, and in general xnu has lots of different concepts that make it somewhat cumbersome to adapt to what the Linux kernel does. The example of this is Microsoft with WSL1; they gave up not because Windows was too shoddy but rather because people want ALL of the kernel, which is a moving target anyway. it's a waste of time not to simply run it in the first place, virtualization is cheap and you get the real thing, with no quirks
twoodfin 5 days ago [-]
What would be the advantages over a VM infrastructure Apple needs anyway and that has a much simpler, more stable “ABI” compared to the Linux kernel?
cogman10 5 days ago [-]
Potentially faster application execution along much lower memory requirements. In the case of docker, even a possibility of shared library loading further reducing runtime costs (For example, containers based on the same base image could load glibc into memory only once).
There's also simply the possibility of using linux software directly in macos without doing OS dependent changes to the software.
MBCook 5 days ago [-]
Yeah. But in exchange it’s a lot of work to keep up with. For GUI stuff you’re now having to have some sort of Wayland layer/driver.
Running VMs is really really easy and low maintenance demand on Apple. And it’s guaranteed compatibility.
Wasn’t compatibility what really sunk WSL1?
skissane 5 days ago [-]
> Wasn’t compatibility what really sunk WSL1?
Yes, but a big part of the problem with WSL1 was the size of the conceptual gap between POSIX and Windows NT that WSL1 had to bridge. An “MSL1” would likely have fewer problems because the gap between macOS and Linux is smaller, given they are both POSIX
The other thing Apple could potentially do, is add Linux-compatible APIs to macOS. IBM wanted to support Kubernetes on their z/OS mainframe operating system, so they implemented on it a clone of Linux namespace APIs, e.g. unshare. Then we could have macOS nodes in a K8S cluster-which might actually be useful for some people, e.g. if you have a Jenkins CI farm, the Linux nodes can run on K8S, but currently macOS nodes (which you need if you are targeting iOS or macOS) can’t, they have to be bare metal or VMs.
More Linux-macOS source compatibility would also benefit macOS by making it less work to port software to it from Linux
qalmakka 5 days ago [-]
Linux and the BSDs take APIs one from the other all of the time. The issue with having a Linux ABI is that you don't need just the few APIs you're missing, you need to implement the WHOLE Linux API and it has to be _perfect_, otherwise stuff will randomly break. I loved the original WSL, I had to use it for a time period back in the day when I was stuck on a Windows PC, but it can't be denied it was full of random bugs
cogman10 4 days ago [-]
The original WSL proves that you actually don't need to be perfect or to have the entire ABI to be pretty useful.
It's true that missing ABIs will cause random crashes and problems. However, a lot of apps can run with a minimal set of ABIs.
coldtea 4 days ago [-]
>for GUI stuff you’re now having to have some sort of Wayland layer/driver.
The target for this isn't GUI stuff.
MBCook 4 days ago [-]
Generally I’d agree but the comment I replied to mentioned people running Linux applications and in my mind that means GUI.
Maybe that’s not what they intended.
tannhaeuser 5 days ago [-]
Just to clarify, this requires Mac OS 26 Tahoe for "container" doesn't it? So those of us holding out on Sequoia who can't stand the broken glass UI or what's called and the other undesired features need to stick to Docker desktop.
masklinn 4 days ago [-]
> Just to clarify, this requires Mac OS 26 Tahoe for "container" doesn't it?
> container relies on the new features and enhancements present in macOS 26. You can run container on macOS 15, but you will need to be aware of some user experience and functional limitations. There is no plan to address issues found with macOS 15 that cannot be reproduced on macOS 26.
The issues are around networking.
niek_pas 4 days ago [-]
It seems macOS Golden Gate (the upcoming version) fixes quite a few of the problems with Tahoe, so you might consider skipping Tahoe entirely.
coldtea 4 days ago [-]
>those of us holding out on Sequoia who can't stand the broken glass UI or what's called
Maybe hold 1 release back, but other than that, I don't think "holding out" on macOS releases has ever been a winning strategy.
In the end, macOS model presupposes users moving to the latest release sooner rather than later.
jrochkind1 4 days ago [-]
I turned off what "glass" UI I could with config, and it's not too different than Sequoia, got used to it pretty quick. Obviously the things not supported on an old OS will keep increasing, until eventually it is EOL'd.
nozzlegear 4 days ago [-]
I didn't make any adjustments and hardly ever notice Liquid Glass on macOS. To me, it's only ever noticed if I hang out in the control center/notification center all day.
egorfine 4 days ago [-]
Yeah I use Tahoe and I can't stand the liquid glass.
It looks like Golden Gate fixes this design a lot.
jorisw 5 days ago [-]
[dead]
emulio 4 days ago [-]
This appears to be an LXC-style alternative for macOS; however, unlike native LXC on Linux, this tool relies on VMs. While Docker and Podman also utilize a VM on macOS, they offer the advantage of the Docker Compose format. In my view, the ability to use YAML for declarative configuration is the most critical feature for any container tool. I have nothing against CLI tools in general, but I prefer avoiding repetitive manual commands that could be easily automated via Docker Compose or Kubernetes manifests.
I'm surprised they cared enough to do this. I'd still rather use Linux but MacBook value is incredible.
marssaxman 5 days ago [-]
I'd always rather use Linux, but sometimes your employer gives you a MacBook. I might use this tool.
pmontra 5 days ago [-]
How is this different from Virtualbox or similar products with a shared folder with the host machine? I expected that existing virtualization tech for Macs already did that. Maybe the improvement is having nothing to configure.
By the way, is it headless or can it run a full Linux desktop? Use case: buy a Mac, uninistall whatever can be uninstalled, run the Linux VM as primary desktop forgetting MacOS and without going through Asahi and the incomplete hardware support.
iririririr 5 days ago [-]
it differs by lacking all the cool options that makes vmware and virtualbox good products, but apple users will praise it as a benefit
"bind mounts? I'm better without it"
coldtea 4 days ago [-]
Funny how confidently people can mock while knowing nothing about the specific tech discussed and the different targets.
I'd google: VirtualBox vs containers.
> container runs containers differently. Using the open source Containerization package, it runs a lightweight VM for each container that you create. This approach has the following properties:
> * Security: Each container has the isolation properties of a full VM, using a minimal set of core utilities and dynamic libraries to reduce resource utilization and attack surface.
> * Privacy: When sharing host data using container, you mount only necessary data into each VM. With a shared VM, you need to mount all data that you may ever want to use into the VM, so that it can be mounted selectively into containers.
> * Performance: Containers created using container require less memory than full VMs, with boot times that are comparable to containers running in a shared VM.
So: you build it as a container image and MacOS starts a VM to run it.
Edit: quite unusually for a container it runs systemd. They give an example "systemctl start postgresql".
coldtea 4 days ago [-]
Obviously you still run a virtual machine to provide the Linux part.
But it's a tiny one, tightly integrated with macOS hypervisor, and the interface is standard OCI-compatible containers/images. It's not Virtualbox style VM.
yeswecatan 4 days ago [-]
How would I replace docker compose containing multiple services that communicate with each other with this? Seems cool for an individual service.
In the intro it mentions automatically mapping user and home dir. So host files accessible the container. Any settings to control this?
numbsafari 5 days ago [-]
Wouldn’t it be nice if services like Codespaces or Coder or Gitlab would allow you to target running on their hosted/integrated platform, or let you launch that same container completely locally? Sometimes I wanna take my “remote” dev environment off-line but still benefit from the integrated UX.
RossBencina 5 days ago [-]
This exists. It's called devcontainers and there is a cli for managing it locally.
If you can express that operation in Terraform, then Coder would let you do that. First problems I can think of are connectivity from the Coder provisioner to your local machine (Tailscale? Local?), and migrating disk images if you want to actually switch a workspace between environments (local provisioner could do this, but no matter what it’ll be slow and janky).
jayd16 5 days ago [-]
Maybe I don't understand but why doesn't Gitlabs self hosted setup work?
LaFolle 5 days ago [-]
Python binary wheels now have to be built for aarch64 for them to work inside the container, unless they are built using the corresponding build system while installing. It is not common for python binary libs to publish arm64 binary wheels, as most often they target amd64.
KeplerBoy 4 days ago [-]
Isn't that just expected for modern macOS devices? They have been on arm64 for 6 years now.
coldtea 4 days ago [-]
This however is for Linux containers on macOS, and for those the deployment target are not usually/necessarily arm.
(Plus, you could always even have amd64 linux containers on macOS AS, with good performance, via Rosetta2).
k_bx 5 days ago [-]
Most of my team's development happens on beefy desktop machine in incus containers per dev+project (so you run yourname-projname-dev). It has its own tailscale inside so you can open it like regular https website or give to another dev to check out – no need to deploy your branch somewhere, just run it. New dev onboard takes 10 minutes from zero to dev env with VSCode remote development.
I would really love if apple could give inexpensive way to run amd64 containers for situations when dev wants to use their own hardware. We've used LIMA for now, was too much of a hussle. But if there's a more native experience – would give it another try.
vachanmn123 5 days ago [-]
Could this allow us to use proton on mac maybe?
xd1936 5 days ago [-]
This is hilarious. Next year, the PC gamers will be saying "The best Windows gaming experience is win32 on Linux on macOS Containers".
aurareturn 5 days ago [-]
The fastest (Geekbench 6) Windows laptop in the world is actually an M5 Max Macbook running Parallels running Windows.
mohamedkoubaa 4 days ago [-]
I think there's one too many layers of graphics driver indirection for this to work
kergonath 5 days ago [-]
Wine works fine on macOS, there is no need for a Linux layer.
Gigachad 5 days ago [-]
I mean at this point literally anything works better than Windows.
pjmlp 5 days ago [-]
Except game development, hence Proton.
asimovDev 5 days ago [-]
it always gets a sad chuckle out of me to hear that some native linux ports run worse than the windows version under proton. i think valve games are like that (l4d2 for example) and recently I think Hollow Knight: Silksong was like that
Gigachad 5 days ago [-]
I think at this point native linux ports are somewhat a thing of the past. The problem was that the ports were usually contracted out to a 3rd party and rarely updated or cared for that much. There was also the issue that they often relied on dynamically linked libraries provided by the distro rather than static linked libraries bundled with the game. So stuff that did work would break on distro updates.
The proton model has the benefit that bugs on linux can be fixed by Valve and the Wine community. While bugs in an official linux port can only be fixed by the game publisher which rarely happened. There also seems to be virtually no downsides to running a Windows game in Proton. These days I don't even bother checking the Wine DB or proton rating because unless the game is deliberately blocking linux via anti cheat, it will just work.
pjmlp 5 days ago [-]
The irony that without Windows there are no Linux games, eventually Linux folks will learn about OS/2 history in regards to Windows compatibility features.
Linux will stay forever a headless operating system great for embedded, server rooms and containers.
We have all limited time on Earth, and eventually Valve won't be around as it used to be, might even be acquired, sold, whatever, then what in regards to Linux gaming?
Gigachad 5 days ago [-]
Wine existed before Proton, Valve made it better but the project doesn't rely on Valve. Currently Linux is the best gaming experience. Zero bloat or nagware, everything just works. It's just ironic Wine/Proton ended up being the best platform for gaming on Linux. I don't think anyone expected it to run so well with virtually no performance impact.
Now with the Fex project, it might end up that running Windows games on linux on a modern ARM processor could be the best way to game going forward, especially for mobile platforms like the SteamDeck.
pjmlp 5 days ago [-]
The best gaming experience are Switch, PlayStation, XBox, iOS, Android, the very definition of everything just works, and no kernel drivers to worry about.
gf000 5 days ago [-]
You just listed concrete hardware (with the exception of Android). That's a category error, of course a fixed hardware with specialized software will have less inconsistencies.
pjmlp 5 days ago [-]
You would be happier if I listed the respective OSes instead?
bel8 5 days ago [-]
I don't think so. This is a VM, closer to WSL2.
Proton is based on Wine which translates Windows instructions to Linux.
Besides there's already Wine for mac.
But I would love to be wrong here.
pjmlp 5 days ago [-]
With the BUILD and WWDC 2026 announcements, it is the Year of Linux Containers Desktop.
Which for many folks is good enough for what they are doing, thus the status quo of desktop platforms will hardly change for current form factors.
aspeckt_112 5 days ago [-]
This is pretty cool - being able to bring your own container machine image goes a long way to helping it's adoption.
I started using Colima a couple of years ago because I got bored of how bad Docker Desktop was and just started using the CLI / the "Services" tool window in whatever Jetbrains IDE I was using at the time anyway. I can't see myself moving away from it any time - having multiple profiles is an absolute winner of a feature for me there, but maybe the next time I set up a Mac from scratch I'll have a play with this.
rickstanley 5 days ago [-]
I was wondering if it's possible to have the container volume change to, say, an external drive. I currently use QMEU with qcow2 images to achieve this, works well enough.
opengears 5 days ago [-]
Also works with UTM.
m132 5 days ago [-]
Every time I see Apple flaunting Linux containers I can hardly consider it as anything but admitting defeat. It could easily be Darwin, if they still had the capacity.
Danox 4 days ago [-]
Darwin is open source still available (anyone who has the guts and talent) can pick up the gauntlet it’s been about 26 years. For example, those three engineers who left Apple to form Nuvia (to bad they didn’t want to do a OS to go along with hardware).
For what it's worth, the first web server was a NeXTcube, and NeXTSTEP was the foundation of macOS.
tw04 5 days ago [-]
What is the alternative? They gave up the server market a decade ago and before that they barely actually supported it.
If they were to support darwin containers, what would be the point? Literally nobody would build to it, Linux won.
riffic 5 days ago [-]
> Literally nobody would build to it
because nobody does ci/cd against macOS or iOS apps right?
tw04 5 days ago [-]
And what is the revenue stream tied to that ci/cd pipeline they aren’t capturing today? Apple would sell less hardware in order to…?
There aren’t any app developers avoiding the Apple ecosystem because there aren’t Darwin containers. They don’t sell server hardware and by all accounts have no intention of ever reentering that space. So they’d spend a bunch of developer cycles to reduce their own revenue stream with no apparent upside beyond “goodwill” which they’ve never been overly concerned about.
m132 5 days ago [-]
Correct me if I'm wrong, but by the same logic, you could also say this whole containerization framework is of no use either.
If they're investing resources into it regardless, they might at least try making something that Docker for macOS and co. haven't solved the same exact way already. Something that, due to their almost unhealthy obsession with "system integrity", only they can realistically make. Like native containers.
tw04 5 days ago [-]
Supporting the containerization framework lets them sell more laptops to Linux devs that may have otherwise bought a Dell or hp or insert brand to run Linux natively on or windows with WSL.
MBCook 5 days ago [-]
Containers are REALLY REALLY popular. This is a a great value add for developers on Mac who need to deal with Linux containers.
Which is a ton of ‘em.
pjmlp 5 days ago [-]
They already support this scenario with XCode Cloud, it is only a market for those that don't want to pay Apple for it.
ahknight 5 days ago [-]
[dead]
TheDong 5 days ago [-]
Apple set itself up for defeat in the server and developer marketplace as soon as they decided macOS was proprietary code.
Why would any serious developer use closed-source code they can't debug and modify? Especially for a production server?
It's the same reason no serious developers or hackers use macOS, like part of the point of being a developer is being able to dig into the code at any layer and debug and fix things.
bschwindHN 5 days ago [-]
> It's the same reason no serious developers or hackers use macOS
I know I'm basically taking the bait, but I guess I've not been "seriously" developing stuff for the past decade or two, which is news to me!
m132 5 days ago [-]
OpenDarwin was a thing at one point, with mailing lists and other infrastructure hosted by Apple.
That being said, my point isn't that Apple should absolutely focus on making a server OS again. It just saddens me how far behind macOS has fallen as they stopped caring about the fundamentals; back in the day, it would be Linux trailing behind macOS. Nowadays, you can't even have multiple routing tables on the latter, the firewall code was probably last updated in Snow Leopard, and what Apple happily shows off on WWDC is a wrapper around Linux. Something functionally equal can be cobbled up together by anyone sufficiently experienced in minutes, using just Bash, OpenSSH, and QEMU.
I really wish macOS would let me have a similar level of control over applications as Linux with namespaces, without me having to do all the heavy lifting.
alwillis 5 days ago [-]
> Nowadays, you can't even have multiple routing tables on the latter, the firewall code was probably last updated in Snow Leopard
Apple uses OpenBSD's Packet Filter [1]; I doubt multiple routing tables are a problem. Back in the Snow Leopard days, it was FreeBSD's IPFW, which is also no slouch.
Yes, I meant pf. Indeed, it was there in the source tree in 10.6 but they only flipped it on it in release builds in 10.7. My bad. Either way, it has hardly changed since then, while the OpenBSD upstream continued to progress.
> I doubt multiple routing tables are a problem.
The lack of them is a limitation for me (complex VM + VPN setup), which requires me to do pretty unholy static routing and address rewriting with pf.
I think even Apple has come across this; they added "scoped routing" (which IMO is a hacky workaround providing some of the functionality you'd get with multiple routing tables) just before iOS shipped with MMS support. Android, for comparison, uses Linux's routing policies and tables to send and receive MMS.
alwillis 5 days ago [-]
> OpenDarwin was a thing at one point, with mailing lists and other infrastructure hosted by Apple.
Apparently game, desktop and app devs aren't serious.
vehemenz 5 days ago [-]
No offense, but serious developers don’t think this way at all.
bel8 5 days ago [-]
For server side, which I believe is the context here, Linux and open source are king.
Even Microsoft gave up on Windows and just runs Linux most things except niche cases. Heck, even SQL Server which is expensive piece of machinery got ported to Linux and that's the default target now in their docs.
With that said, one can't deny Apple's success on the b2c side of things so it feels wrong to call their strategy a failure.
pjmlp 5 days ago [-]
Except the cloud isn't open source, the ones that matter to developers that is.
Which is why so many projects get burned with their license choices.
gf000 5 days ago [-]
I don't see how this comment is relevant to parent's point. Sure, cloud is proprietary. But it is Linux for the vast majority.
pjmlp 5 days ago [-]
Which is an Pyrrhic victory, when Linus and other founders are long gone, most of this generation actually, what will subsist are proprietary forks, just like what happened with UNIX System V.
brianmartin039 2 days ago [-]
I've been using Lima for this exact workflow. Apple's implementation looks cleaner though, especially the automatic user mapping. Curious how the performance compares.
a1o 5 days ago [-]
With colima I can run AMD64 (x86) Linux containers in my Arm64 too. I think this is strictly for Arm64 Linux VMs, or is there some way to run x86 with this too?
jdub 4 days ago [-]
You can run amd64 binaries inside an aarch64 Linux virtual machine. Although they're not supporting Rosetta for macOS apps from macOS 27, the Rosetta support in Virtualization Framework will remain.
andor 4 days ago [-]
Did Apple officially confirm this or is it based on the statement regarding games?
jdub 4 days ago [-]
[dead]
cpach 5 days ago [-]
What’s the performance when you do that?
frizlab 5 days ago [-]
Rosetta should be supported
whycombinetor 5 days ago [-]
Not for long!
commandersaki 5 days ago [-]
Very unlikely to lose support for Rosetta for Linux. Maybe just Rosetta 2 for mac apps.
whycombinetor 4 days ago [-]
Oh, didn't read that part of the news. That's great. Ability to run x64 docker images seminatively was one of the big reasons I jumped to the M1 platform when it came out and I was baffled that they would remove it.
kstenerud 4 days ago [-]
This is awesome! I just added this as a backend for yoloAI on Mac, and wow... super fast startup times now!
5 days ago [-]
phplovesong 5 days ago [-]
It was unclear to me, is this a native replacement for docker? I like docker (on mac) but its quite the resource hog.
I usually run like a db, redis, maybe something like rabbitmq/zeromq and have a app that uses these services (makefile/docker-compose).
I would love to switch if this in fact is a lightweight replacement.
masklinn 5 days ago [-]
On the one hand yes, on the other hand there are already multiple lighter alternatives to docker on mac.
happyopossum 4 days ago [-]
A native replacement for docker came last year with Apple Containers- this extends that.
harrouet 5 days ago [-]
Why did they have to invent their own solution instead of just shipping docker or an equivalent clone ?
nottorp 5 days ago [-]
Isn't docker on mac os still a large preallocated linux VM that runs the containers inside itself? With this maybe you can separate them.
solenoid0937 4 days ago [-]
They shouldn't bury the details about how the containerization actually works.
thedougd 4 days ago [-]
I still can’t use Containers because of a broken DNS implementation. I suppose I could manually set the DNS as I switch on and off VPN, but I don’t have to with Finch, Podman, or Docker Desktop.
yurimo 4 days ago [-]
I'm pretty sure this is not the use case at all but man do I miss bootcamp. Even for games if we could just run linux without a need for crossover, gaming on mac machines would be a dream.
almaight 4 days ago [-]
It's been over a year since it came out, based on kata-container
Havoc 5 days ago [-]
Always nice to have more options especially without third party tools
namegulf 5 days ago [-]
Would be nice if they also support Intel based macs, what prevents?
MBCook 5 days ago [-]
Apple won’t support them with MacOS 27, and it seems they announced this tool as part of this year’s WWDC.
Basically: they’ve moved on.
danhon 5 days ago [-]
Allocation of a finite amount of engineering resources.
joshuat 5 days ago [-]
And a legitimate business interest to further incentivize the adoption of Apple Silicon devices. Same with Rosetta deprecation after macOS 27.
JumpCrisscross 5 days ago [-]
> a legitimate business interest to further incentivize the adoption of Apple Silicon devices
Apple has never been about supporting legacy platforms with new features. And with over a quarter of revenue and two fifths of Apple's gross profits coming from services, one could argue the incentives run either way.
crote 5 days ago [-]
Sure, but to what extent?
Enterprise ARM servers are still a niche product, and so are the ARM developer machines running Linux or Windows. Until this significantly changes, Apple will have to provide good x86 interop - or lose the developer market entirely.
Forcing people towards Apple silicon is of course an attractive approach when targeting the large portion of the market using their MacBooks as Facebook browsing machines, but (especially with the new MacBook Neo) what's going to happen when a large portion of the market for high-end MBPs disappears because it turned from the default no-brainer into a liability?
macintux 5 days ago [-]
> Until this significantly changes, Apple will have to provide good x86 interop - or lose the developer market entirely.
I'm very, very skeptical of this analysis. Certainly "entirely" is hyperbole.
solarkraft 5 days ago [-]
That’s a joke right? I’ve been developing software deployed on x86 servers on ARM Macs ever since they were released.
ForOldHack 5 days ago [-]
Rosetta 2. Rosetta was for Intel to emulate 68k, now if you could get Rosetta 2 to run under Rosetta, then you could run 68k, on an ARM, and if you could get the apple ][ emulator...
weikju 5 days ago [-]
Rosetta 1 was for emulating PPC not 68k
ForOldHack 3 days ago [-]
[dead]
jdub 4 days ago [-]
The underlying Virtualization Framework works on Intel Macs, but they'll miss out on new features landing in macOS 27 and beyond.
zackmorris 4 days ago [-]
I started with System 3 on a Mac Plus with floppy disks back in the late 1980s, and ported original C code from around System 7 all the way through modern versions of macOS X. Apple has a long track record of deprecating basically everything, as part of its business model IMHO. That's why I don't target native macOS/iOS anymore.
Nobody is coming to save us. But I think that with AI, we have an opportunity to create a zero-cost runtime layer that provides something like Wine or SDL on all platforms. It could/should be the intersection of all mainstream OS features (a bit like the web), with the option to drop down to native components like how Cordova works.
I've been out of the game too long to know if something like this already exists, but would love to contribute.
Note that the thing to get to the thing is runway. With our currently broken open source software (OSS) funding model, we don't have a way to pay developers a stipend of perhaps $24-48k per year (minimum) for their OSS efforts. So they have to work pro bono. That leads to design-by-committee thinking that stands in the way of getting real work done.
So unfortunately we have to pick ourselves up by our bootstraps. I hope to see the creation of a maker's guild someday, where membership provides the stipend, with proceeds coming from the 1 in 10 or 1 in 100 apps that generate a return on investment, to cover the commercial failures. Like Humble Bundle on steroids.
- digression -
Imagine a corporate model, but without gatekeeping, minimum hours or profit. A pure meritocracy working to manifest a gift economy for all.
I'm not aware of an automation-based (instead of artificial-scarcity-based) economic model like this. Solarpunk is more of a cultural revolution, but comes close. Some examples of how it might work:
- Abandoning patents, copyrights and other intellectual property rights in favor of a commons owned by everyone
- Funding drug research but giving away the resulting medication for the cost of production or free
- Universal Basic Income (UBI) or its cousin Universal Basic Capital (UBC) that provides the resources for labor to participate in the exponential gains of capitalism (the missing ladder that the wealthy currently pull up behind them)
China is well on its way to achieving these goals and more by 2049 under its Second Centenary Goal. Meaning that the US is/has been left behind. You can feel it in every way: widespread underemployment, the collapse of our social safety nets, the return of prejudice, our national debt higher than our GDP, CEOs getting compensated hundreds of times more than workers, the upcoming crowning of the first trillionaire. Times 1000 other injustices.
Solving the thing that gets to the thing is akin to solving all things.
Edit: I was wrong about intellectual property (IP) in China. It sounds like they will instead pursue high-value IP to fund their economy, a bit like the UBI funding model. I don't think that's an equitable path, so am suggesting something above and beyond what they're attempting.
teaearlgraycold 5 days ago [-]
[flagged]
imglorp 5 days ago [-]
I'll defend, not cringe for everyone.
Daily driver is a 6yo, 32Mb mbp and it might not scream like an M5 or have the miraculous power draw of an M5, it gets my job done.
One nice thing is x86 containers run natively: I run most of my $work landscape which is 40 or 50 k8s pods on top of Kind, which is itself a plain container. That mirrors my prod. That plus slack, zoom, ff with scores of tabs, etc. all while building rust and playing music.
MBCook 5 days ago [-]
That is a far more useful reply than the GP comment. If they had stated something similar I don’t think they would’ve been downvoted.
teaearlgraycold 5 days ago [-]
Poe's Law and all that, but I was trolling/shitposting.
ncr100 5 days ago [-]
More power to ya!
Brian_K_White 5 days ago [-]
cringe is cringe
krzyk 4 days ago [-]
Oh, I hoped it would be macos contained in those containers.
Container for Linux are in millions, while I don't know if there are any with macos inside.
gigatexal 5 days ago [-]
I saw the video on this this is distrobox basically for Mac. It’s very cool. Seamless with your local files and the container. I’m very keen to try it.
commandersaki 5 days ago [-]
Would be cool if you can redirect USB devices to the VM.
What happened to Orbstack for like 9 months until earlier this year? Suddenly everything went silent for a bit and I was pretty concerned. Glad y’all are back!!!!
calebm 5 days ago [-]
Thank you for sharing this - I looked into OrbStack a few months ago, and this was the reason I didn't use it (as my primary purpose was to have an external wifi adapter for wifi pwnage).
commandersaki 5 days ago [-]
Yeah I find this useful for redirecting storage/sdcard*, so you can format linux filesystems or use other tools.
* need a usb sdcard reader for macbook pro cause the builtin is not usb)
kdrag0n 5 days ago [-]
We're working on block device passthrough for the builtin SD reader.
I've successfully tinkered with USB/IP with Apple containers, but it does require loading a custom kernel (which they make pretty easy, thankfully). On the host side, macOS also doesn't make it easy to unload a driver that attaches automatically.
lanycrost 2 days ago [-]
I will wait when docker or podman will adopt this :D
shelled 5 days ago [-]
I hope this brought us one step closer to being able to run our distros of choice very freely and easily on a Mac.
They've now added a WSL-style virtual machine layer, but there's no x86 container story (Apple's killing Rosetta) so I imagine some qemu shimming will be required.
And, most obviously: NO SUPPORT FOR MACOS. This is the single feature that only Apple can do, and they're choosing not to implement it deliberately, and it's so stupid given the pains we all have to go through to implement CI for macOS. In the land of OCaml, we were forced to implement a custom ZFS snapshotter to get reasonably cost effective macOS CI for our package repository: https://tarides.com/blog/2023-08-02-obuilder-on-macos/. This was fun to build, but it sucks to have to maintain it.
Also, I'm really curious what the GPU passthrough story here is for LLMs, since the Apple Silicon -> Linux kernel support is gated on Asahi's support, but that's been lagging beyond M2 due to the efforts of reverse engineering.
Do better for your developers, Apple. This is a half-baked sweep across third-party software without addressing the core needs around your own operating system.
konaraddi 5 days ago [-]
Sounds like toolbox or distrobox for Mac!
throw1234567891 4 days ago [-]
And no GPU passthrough? So colima with libkit remains the only method on Apple Silicon?
rcarmo 4 days ago [-]
This blew up spectacularly when combined with Time Machine, I wonder if that’s fixed.
happyopossum 4 days ago [-]
Considering that this project was published less than 24 hours ago I’m guessing you assume it’s a different project.
Melatonic 4 days ago [-]
Sounds a lot more like micro VM's and not normal containerization
sachinjoseph 5 days ago [-]
WSL-like implementation on macOS?
exabrial 4 days ago [-]
Handy for sure!
In production though, I've moved completely to systemd isolation of apps, rather than Docker-like containers; essentially blackboxes and present a supply chain threat. There's also a DRY principle here. Verification of a host presents a much smaller surface area.
bityard 4 days ago [-]
> moved completely to systemd isolation
On MacOS?
exabrial 3 days ago [-]
Negative:
> In Production
sdevonoes 5 days ago [-]
Im running Multipass on M1 for full linux VMs. Are container machines better?
m1keil 5 days ago [-]
Isn't multiphase is Ubuntu only?
sdevonoes 4 days ago [-]
It used to be. Any image is allowed now.
zekrioca 5 days ago [-]
"LXC" for macOS?
alwinaugustin 4 days ago [-]
Why it is important ? We have Docker for containers, right ?
zer0zzz 4 days ago [-]
I just want thunderbolt pci passthrough for these things.
kdrag0n 4 days ago [-]
Interesting, what devices would you want to pass through?
CSDude 5 days ago [-]
I know its not going to be there but wish we had Windows as well.
Cadwhisker 5 days ago [-]
Install Windows 11 ARM under the macOS "UTM" App. This lets you run x86 Windows programs on Apple silicon.
riffic 5 days ago [-]
darwin containers when?
riffic 3 days ago [-]
had to come back because there actually seems to be a project to build this:
Yeah I was working on that, created a prototype. I don't see a business in it, so abandoned.
windowliker 5 days ago [-]
It would be wonderful if this ran on older versions of macOS, but according to the README they only support 26.
m463 5 days ago [-]
you do not understand... Not run on, run IN :)
I'm saying the older version of macos could build/run INSIDE the container
just like on a ubuntu 24.04 system you can do:
FROM ubuntu:16.04
or
docker run ubuntu:16.04
and though I haven't tried it, I believe docker can do arm in x86 using an emulator (like rosetta)
MBCook 5 days ago [-]
You can already run older versions of macOS inside a VM on macOS.
So it seems like in theory that should be doable if someone just made the container images right?
windowliker 4 days ago [-]
Oh right. I don't see Apple having any interest in supporting that given their current trajectory.
5 days ago [-]
jadar 5 days ago [-]
i wish!
lzwjava 5 days ago [-]
[flagged]
zoetaylor00 2 days ago [-]
[dead]
GHanku 4 days ago [-]
[dead]
asxndu 4 days ago [-]
[dead]
Lapsa 4 days ago [-]
[dead]
sourcegrift 5 days ago [-]
[flagged]
al_borland 5 days ago [-]
macOS only needs to support the hardware it ships on, so of course Linux would have wider hardware support, but that doesn’t really matter in context. The bigger question is what hardware to people actually want? I see most people drool over Apple hardware while not finding any suitable equivalent for the PC that they can install Linux on.
Framework is trying to close that gap with their new release, but we’ll have to see how it is once people get their hands on it. I think it also comes at a price premium. There is always the Thinkpad route, but Lenovo burned just about every bridge with me a decade ago with things like Superfish. Where is the premium Linux laptop OEM that people can trust? Last I heard System76 was just rebranding Clevo hardware. What are people using? Dell? HP?
hollerith 5 days ago [-]
Sadly, Linux is much much less secure.
pixelatedindex 5 days ago [-]
This claim is so absurd that I need some sources.
armadyl 5 days ago [-]
The person you replied to is right, the "security" of Linux might as well be nonexistent compared to macOS and especially iOS/Android. Even the developers of Secureblue (https://secureblue.dev/) state that despite their hardening and mitigations Linux still lags far behind macOS (and possibly Windows) security-wise. The only Linux derivative that has proper security is Android, and even better GrapheneOS.
Also on top of that Linux/Windows laptops also lack the hardware-backed security that Macs and to an extent some Chromebooks have.
hollerith 4 days ago [-]
OK. Here is a kernel developer explaining it recently on this site:
https://news.ycombinator.com/item?id=48448345
// When people escalate privileges on MacOS it's news, when they do it on Linux
it's Tuesday (you might think the recent spate of privesc vulns on Linux was
unusual but that is totally normal). I say this as someone who works on Linux
security every day (I am a kernel developer) and uses Linux on every computer I
have, both at work and at home, BTW. I am not a Linux hater or Apple fanboy by
any means.
I also have some cites of comments on Linux by the founder of GrapheneOS I could dig up.
JumpCrisscross 5 days ago [-]
Linux is easier to misconfigure. Macs resists being misconfigured insecurely. At their tightest, I'd say neither is fundamentally more insecure than the other. (The exception would be M5-based Macs, which come with MIE. Though that isn't a macOS vs Linux thing per se.)
armadyl 5 days ago [-]
This is incorrect macOS is fundamentally more secure than desktop Linux operating systems and it isn't particularly close.
No amount of Linux hardening will get a system even close to an M-chip Mac. Software insecurities aside, desktop Linux OS systems have almost none of the hardware-backed security benefits that Macs do.
TimTheTinker 5 days ago [-]
At some point, lack of security becomes a feature. A fully secure, locked-down, T2 attested macOS is able to be controlled not just by Apple, but by increasingly evil governments, with no recourse available to users.
armadyl 5 days ago [-]
Conversely, a Linux system with no verified boot can be easily tampered with without the user detecting it by people lower than the government such as casual hackers. So in a world where your government is going crazy, you're opting for an operating system that can be penetrated with relative ease (e.g. with persistent root malware) both by a non-government hacker on top of a state backed one.
JumpCrisscross 5 days ago [-]
I'd also guess it's much harder to securely source components for a Linux build in the way Apple is able to.
armadyl 5 days ago [-]
It's not really about supply chain security it's about the hardware itself. PC manufacturers in general just can't keep up since they don't have full control/integration over the hardware stack like Apple does. Also CPU, secure element etc security is limited but Qualcomm is catching up pretty quickly I believe if they aren't there already. We won't talk about Intel and AMD. But that's beyond my knowledge so I can't say anything too specific that's just what I have from general knowledge I'm sure someone will jump in with additional info if needed.
I don't think Apple is particularly any more secure against the US government than Intel is with supply chain vulnerabilities but I have nothing to back that up with aside from vibes.
dvhh 5 days ago [-]
Security by obscurity worked quite well
xiaodai 5 days ago [-]
so basically dockers
jwlake 5 days ago [-]
haven't we had hypervisor.framework for like years now?
itsneulook4 5 days ago [-]
Yeah but sitting in the tweak circles just to gather personal data about people to make them lose their minds is no bueno. Otipolfueriborsklineypoo
itsneulook4 5 days ago [-]
that thepolfus and the Otis and the bors and the alschweid and pretty much anyone in old the the gs gangstalk or just getting people info to sit in the same room as them to try and makr them go crazy deserve to brave hart quartered
khazhoux 5 days ago [-]
try unplugging your keyboard and then plugging it back in
Barbing 5 days ago [-]
I found it hard to believe I didn’t have a simple way of staying safe by installing an arbitrary application in a sandbox on macOS. (Restoring using Time Machine doesn’t count! :) )
This is a step in the right direction but requires any given developer’s buy-in first, right?
> - Security: Each container has the isolation properties of a full VM, using a minimal set of core utilities and dynamic libraries to reduce resource utilization and attack surface.
> - Privacy: When sharing host data using container, you mount only necessary data into each VM. With a shared VM, you need to mount all data that you may ever want to use into the VM, so that it can be mounted selectively into containers.
> -Performance: Containers created using container require less memory than full VMs, with boot times that are comparable to containers running in a shared VM.
More details, including technical limitations (they’re looking for bug reports and contributions): “Container: Technical Overview” https://github.com/apple/container/blob/main/docs/technical-...
Which kernel is running, and is it hosted in hypervisor.framework, as is done with UTM (when not using the qemu mode)?
The thing that I don't like of the WSL2 is that is just a VM, but a VM that is very limited. For example working in the embedded development field I often need to use serial ports or USB devices, a thing that the WSL2 is not capable of doing (unless passing trough USB/IP that has its compatibility issues especially for stuff like debuggers needing precise timing), and that the WSL1 was at least for the serial ports able to do. This is a limitation that doesn't allow me to use the WSL. Same thing with all kind of other software that wants to access peripherals of the machine natively (e.g. a GPU for example, or another PCI card, something that to be fair is not even doable as far as I know with hypervisors on Windows but completely doable with hypervisors running on a Linux OS where trough the IO MMU you can share any PCI device of the host to the VM).
WSL1 was a great idea, bad thing that Microsoft abandoned it for something that is just good for web application development.
NTFS does not have performance problems. The difference between DevDrive, which uses ReFS (arguably a more 'resilient' file system than NTFS due to journaling) and a standard NTFS volume is the file system filters are either removed or in the case of Defender, put in async mode.
The file system filter architecture is the performance problem, not the file systems. It's a trade off to have a more extensible I/O stack.
I also don't remember why they couldn't just bypass the filter stack for paths in a certain volume - WSL2-like I/O on WSL1 - but there must have been a reason.
Over time this would tie the Windows kernel’s requirements so that they matched the Linux kernel’s due to expectations from WSL1 users. This of course is a bad idea for any engineering organization - you will have requirements imposed on you that don’t mesh well with your other non-WSL users and you also have no real sway over Linux governance. This would lead to the Windows kernel either becoming a clone of Linux or serving at least one set of users poorly.
Maybe this works out better because Linux is more flexible, while Windows/NT is more "set in its ways" and therefore more difficult to implement Linux on top of... Maybe?
Since git and nodejs are both common in modern development and are expected to work efficiently with huge numbers of files, this was a real bottleneck and it couldn't easily be tackled without threatening backward compatibility.
Those days I was working on a rework of the TRO PLATO learning system which was a real beast but essential for the individual learning project of a charter school i was supporting.
PLATO had been taken from it's dedicated mainframe world and made 'runnable' on W95 workstations with an NT server - but it really didn't run well, and the kids could really get behind the interface into regular Windows environment too readily. In combination the workstations were crazy hard to keep running cleanly.
So in the end; we had to take the software out of Windows, wash it clean in the waters of Silicon Graphics System-V with BSD extensions (X11) Unix and BSD - NeXTSTEP, just so we could bring it back to Windows properly using LiteStep.
Life happened and I lost touch with the outcome of it all, moving on to my next project; but, I kept a LiteSTEP desktop until moving entirely over to Linux in 2004.
Haven't used Windows for anything but a gaming load since '05 and stopped doing even that in about 2010, nothing later than XP.
I am convinced that if POSIX subsystem was UNIX serious, GNU/Linux would never taken off on PC, and the whole would be divided between SGI, HP-UX, Solaris, Aix and Windows NT.
The reason Linux grew in the 90s was because it was part of the hacker culture. Not because better options didn’t exist.
Kids liked the fact that Linux was a free-for-all, anything-goes, platform. It wasn’t stuffy like Unix and it wasn’t proprietary like Windows.
Then those kids grew up and became decision makers themselves. And we started to see Linux replace FreeBSD and commercial Unixes.
GCC was the real catalyst, With even SUN which had used bundled dev tools as a early selling point was unbundling them and charging more, many x86 UNIXes like SCO didn't even come with a tcp/ip stack without an extra fee...and you couldn't take C code from HP to another system and actually have it compile.
As Solaris is really just a sysV-ification of the bsdish sunOs...the introduction of posix as a least common denominator, and Linux being closer to the commercial-ish unixes it was just an easier sell for a lot of users.
In hindsight it may seem silly, but in may projects I was involved with, linux using sysV /etc/init.d/, vs BSD's /etc/rc.conf was the driving factor, because /etc/rc.conf was a shared dependency and harder for us to modularize projects.
IMHO the real Linux advantage is that it was using the gnu user land, and thus gcc worked well with it and companies started to sell commercial support early.
But there were still flavor wars from all sides all the time, and being an ex-op on #unix and #unixhelp from the 1990s, I dealt with them all.
But BSD and heck even ITS etc... was the free-for-all, anything-goes, platform of record.
IMHO what really differentiated Linux were
a. the bazaar development approach, which lowered barriers to contribution, felt more transparent and "safer" with regards to what was going on in kernel land
b. the GPL, which while annoying to certain companies due to its viral nature, it at least guaranteed that no competitor could just develop a major innovation, grab the kernel and all of your contributions and run with them, undercutting you in the process
and also a noteworthy mention was the fact the BSDs were basically sabotaged by AT&T via their nefarious set of lawsuits, which nipped in the bud any semblance of advantage they had
People keep saying that but I saw zero evidence of those lawsuits factoring into any purchasing decisions that customers made.
I saw Solaris SPARK servers purchased for running Informix RDBMS
I saw Solaris deployed for payroll systems running Oracle middleware.
I saw FreeBSD servers built for web hosting
I saw FreeBSD servers built for ISP backend services
But at no point in the 90s did I see anyone running Linux commercially. In fact the only reason I ran Linux (Slackware) in the 90s was to see what all the fuss was about from my nerdy younger peers on IRC. And even then, I just threw it on a desktop PC.
In the 90s you had NextStep workstations used to build games intended for PCs (like Id Software did with Doom and Quake). And used at CERN for the development of the WWW.
UNIX was the 90s platform of choice for computer animation. It was the platform of choice for multi-tenant web hosting. And so on and so forth.
Much as Linux had the cool hacker community, 90s UNIX systems had superior ACLs, containerisation, faster TCP/IP stacks, significantly more stable file system drivers and so on and so forth. So people naturally chose UNIX for their important systems. And that’s exactly the trend I personally experienced in the 90s.
This isn’t to say that I think the unix wars had “zero effect” on the decline of unix, but I do personally think the amount of impact it had is massively overestimated. I think Linux would have taken over regardless because the Linux culture embraced everyone’s weird ideas vs UNIX systems that did extensive gatekeeping. And the kids that played with Linux because it was fun and hacking was encouraged, grew up and became influential in decision making.
I think the culture of Linux had more to do with Linux’s growth than anything else.
Personally, I don’t think the license made any difference here. I do get the arguments people make about GPL, but GPL was around since before Linux and it didn’t gain significant traction then. But like most of the opinions I’ve shared above, it’s an impossible point to prove either way.
Linux encouraged people to fork and experiment with it. Whereas the FreeBSD was a carefully maintained ecosystem.
Minix was a toy OS for university teachings.
Coherent was commercial.
Nothing else was there on the PC market.
FreeBSD was also used heavily in the late 90s in ISPs and similar domains.
USL v. BSDi is what impacted the BSD side, and it was during that lawsuit before Novell bought USL etc.... that the problems were that allowed Linux to make gains while the net/2 distros were in a waiting game IMHO.
The timing absolutely helped Linux and GNU being packaged as a complete system by the various distros etc..., and common OSS distribution points like Walnut Creek and PHT were very much concerned about USL v. BSDi and in an era when you had to make long distance phone calls to download with a modem, a lack of CDroms etc... absolutely caused a dip in adoption of the BSDs.
By the time the IBM v. SCO lawsuits happened (2003) the UNIX wars were long gone and Linux was already established.
SCO/Interactive/Coherent/etc... and other x86ish UNIXes were quite common in my work in the early 1990s, but the whole unix wars is way to complicated to cover in a single post.
The post .com bubble SCO lawsuits really just didn't matter much, the consolidation that happened in the early 90's that ended the UNIX wars, plus Intel killing most of the commercial unix independent CPUs with Itanium untruths and impossible promises and an inability for the major vendors to adapt to a lower margin model etc... killed those off.
The SCO lawsuits were really just the flailing of a dyeing company which was the end result of WordPerfect buying Novell with Novells money and local Utah politics.
Just that FreeBSD was still used a lot in the 90s and managed (at least from what I experienced) to dodge most of the concerns that companies had deploying other UNIXes.
I mean, it’s not like UNIX use dropped to zero overnight.
So you did see a lot of Internet companies using FreeBSD as their platform of choice. For a while, it really did look like FreeBSD was becoming the dominant server platform in that domain. Not everyone too Linux serious at that time. It wasn’t until at least 99 when Linux became a viable competitor to FreeBSD.
But once Linux did gain favour its popularity sky rocketed. Which is exactly why SCO took various Linux shops to court.
Which simply wasn’t enough drama to persuade businesses on smaller budgets away from using FreeBSD.
Also SCO lawsuit was more due to IBM's money than Linux.
Both a different situation than Windows NT being available a decade earlier.
My point about SCO wasn’t clear though. I was just saying FreeBSD wasn’t as embroiled in the UNIX wars as the others, ie referencing SCO vs Linux to demonstrate how even Linux suffered more time in the courts than FreeBSD did.
In fact, had I not bought a set of Walnut Creek CD-ROMs, I would never had used it in first place, and never again since those days, excluding derivatives like macOS and Orbis OS.
Which is why I asserted with good POSIX support, the world today probably would be Windows NT linage on the PCs, plus the commercial UNIXes everywhere else.
My experience was very different in the 90s.
Solaris, FreeBSD and Next were very widely used. The only times I saw NT was in edu, government, and a random publishing house (which ran pirated copies of NT 4 on the servers and Mac OS 8 everywhere else).
That publisher is an interesting chapter in my career on its own actually…
I never want to deal with that again ;)
[edit] fwiw, Termux on Android is similarly a fun pseudo-environment. It's a nice and helpful toy.
https://old.reddit.com/r/ProgrammerHumor/comments/96ufiz/pro...
That's handy when you're entering paths in a Cygwin/MSYS Bash shell, but might not help much if you're trying to parse or otherwise work with existing patgh variables composed with backslashes.
Doing retail office deployments of custom code on employee computers is a weird niche, and you find whatever works and hope you can maintain it somehow. Cygwin was awesome though, saved me a ton of time and the client a lot of money for the moment. (The client later stipulated to all future franchisees that they had to buy only Macs, lol)
You still can, and it still works exactly the same way.
if you must use windows, it's because you will compile for windows. so you install MSYS, which is a linux distro-ish compiled native for windows. and do your work.
wsl2 (and this apple thing) is just a meme. if you're working in it, you're better of just installing Linux or ssh'ing to a server.
Many enterprises allow windows only so your way into Linux is via WSL2
https://git-scm.com/install/windows
Also everyone on FOSS gets it wrong, WSL wasn't a subsystem like classical Windows NT ones.
It was based on Drawbridge research using picoprocesses, a new approach for library OSes.
https://learn.microsoft.com/en-us/archive/blogs/wsl/pico-pro...
Everyone in FOSS? How about Microsoft got it wrong, since they actually named it The Windows Subsystem for Linux (WSL)? It wasn't the FOSS community who chose the name for them.
I'm not sure if you see the quoted part. My comment is about the part that starts with "> " that you wrote earlier.
How is this different to bind mounts
My suggestion: Don't use the host filesystem from the guest at all. It'll be faster, and better isolated. It's a false convenience.
An example of improving efficiency: virtiofs has a relatively recent feature to map pages from host memory directly into guest memory, but that's a lot of risky acrobatics if your priorities are reliability and isolation...
... but it's not supported by Virtualization Framework's built-in virtiofs "folder sharing". (sad face)
... but someone could build it on top of the new macos 27+ custom virtio device support. (intrigued face)
Depending on your threat model, that's fine, but a lot of people (including me) will say that containers are not a security mechanism.
But macOS requires[1] virtualisation for containers anyway; the security is just a bonus.
[1] at least for a real Linux kernel...
On the other hand, in other scenarios, people trust the security boundaries of their working as expected all the time, no? This is the basis of e.g. Android app isolation (every app runs under its own Linux UID/GID), and true multi-user Unix systems trusting the OS's security boundaries to hold have decades of history.
I can create docker-images with docker compose, or use something like colima, which this seems to be close to (that should have some advantages over docker, although my hope of circumventing W^X page protection did not pan out).
I was perplexed that the repository does not put these container machines in context. The seem to be close to colima? When should I use which option (docker, collima, container machines ?)
Maybe others wonder too but are ashamed to ask. I have no shame ;)
Thanks for any pointers
I don’t really understand the hype for Apple’s Containerization, it’s just another container runtime alongside many others. It’s not really any better than OrbStack - in fact it’s worse.
In general I understand the rationale behind Apple's decision. They sell hardware, and there's real demand for macOS on servers to run build jobs and other Mac-only tools. Giving you the ability to run multiple containers on a single Mac would end up turning a 10 Mac Mini order into a 2 Mac Minis order for most people. Rest assured, even if it would be technically possible they'd find a way to cap it somehow via the EULA or whatever
what? it isn't, it's absolutely a right you surely have. The problem is that
a. Apple forces people to buy Macs to build, notarise and deploy iOS and macOS apps b. Apple refuses to implement jails which is something that every OS, including Windows, has nowadays c. Apple only allows you to have 2 VMs - full, fat, with GUI - on each Mac computer, running at once c. Jails/Containers would allow you to easily deploy multiple jobs, which would allow you to have N jobs in parallel, which would mean you'd need way less Mac Studios/Mini in your local CI
Our biggest perf/resource gain is dynamic memory, which reduces memory usage a lot by releasing unused memory back to macOS. Nothing else supports this, including Containerization.
I gave Container Machines a try and it seems to be much closer to OCI containers with a default bind mount than OrbStack machines. It has fewer integrations and doesn't run systemd or any other normal init system, so it's hard to run services.
If the guest image has /sbin/init, we use that.
We'd recommend using a base image for the guest that includes systemd. ie: https://github.com/apple/container/blob/main/docs/container-...
> I gave Container Machines a try and it seems to be much closer to OCI containers with a default bind mount than OrbStack machines. It has fewer integrations and doesn't run systemd or any other normal init system, so it's hard to run services.
The linked md document says:
> Real Linux services for testing. Run a database or whatever your stack needs as a system service — systemctl start postgresql works on images with systemd installed.
Was that not the case when you used container machines?
"Real Linux services for testing. Run a database or whatever your stack needs as a system service — systemctl start postgresql works on images with systemd installed."
Wow, missed this when reviewing OrbStack. I assumed that you just used Containerization and therefore would have the same limitation.
This post reminded me to buy a license, just done it, worth it for the time saved.
I wanted to make its VM/machine our default secure agent sandbox, but I couldn’t figure out how to isolate this VM from the host properly. This thread prompted me to find the issue though, and I saw this was recently implemented! https://github.com/orbstack/orbstack/issues/169
https://github.com/orbstack/orbstack/issues/342
Nothing specific for Docker yet, but I find the Linux machines are lightweight enough that I just run Docker inside them.
AFAICT it's pretty similar.
Personally I’d rather the company provisioned me MacBook hardware with Linux. Unless Fable or some other ai ports asahi properly to modern hardware I expect to retire before this is possible, orbstack is the next best thing, available today.
The Containerization framework is a library that sits as a layer on top of the virtualization framework. So each container is its own VM.
Machine is tooling above the containerization framework to run multiple things in a container in a vm.
But like having containers that need file watchers like vite dev server, or frankenphp in watch mode will overload OrbStack real quick since It seems to fallback to polling instead of listening to fs events.
So I'm stuck running vite dev servers and the like on the host.
Last time I tried all of orbstack froze and I had to restart my whole mac to fix it. But you also did some recent releases that fix issues related to freezing up, so maybe it was unrelated.
Thanks for the great software! Happy enterprise customer
Edit: It's a VM per container. https://github.com/apple/container/blob/main/docs/technical-...
https://katacontainers.io/
For ultimate security, containers alone aren't enough.
Windows is also having a similar feature on top of WSL, announced at BUILD.
https://github.com/microsoft/mxc
[1] https://cheatsheetseries.owasp.org/cheatsheets/Docker_Securi...
This was due to implicitly granting the LLM access to the host docker daemon, which has superuser privileges, not due to a "container breakout". That's arguably a very different scenario, but of course both are worth considering.
> So if you want to use containers for anything but easier development, you need to be much more proficient than the average user already.
I'd disagree. Containers, at least without granting them additional privileges such as CAP_NET_ADMIN and without write-bind-mounting sensitive host directories into the container, offer a reasonable security boundary compared to the counterfactual, despite their bad reputation.
There's much more to it than that if you check out the link above. Misconfiguring a container is the 2026 version of misconfiguring FTP and MYSQL in the 90s. I.e. most users don't even know how they are asking to get rooted.
AFAICT all the security problems are fairly obvious own goals inflicted after that point.
But yeah, I guess my use case is not the main use of such tools or their purpose in general. Thanks for the link, I‘ll take a look at it.
I guess my use case is not that important for the main user of these tools.
i'd still use less permissive containers for things i don't feel comfortable installing on the host, e.g. npm.
And I think I would caution Apple to consider the lessons of WSL; having shared access to the filesystem is just the bare minimum. Next is networking (and god is this a rabbit hole with WSL), people will want to access their USB devices, X forwarding, GPU passthrough..
If we wanted access to all interfaces, we'd just run it locally.
We want the container as a closed box, "wasting power doing math", i.e. processing what we actually passed to it.
That said, colima still has the expensive VM that upthread is mentioning.
The use case is actually the opposite of what you seem to want (i.e. running Linux containers on macOS without a Linux VM); this uses a Linux-based container implementation of macOS to provide a long-lived Linux VM that looks more like a VM itself than a container.
I did an experiment migrating my Podman workload to Apple's container @ https://gist.github.com/jmonster/39e14585e107dbf990a90966c0f...
TL;DR reduces ram/storage usage; minimizes it's existence
> Memory defaults to half of host memory
That's the most expensive part of the whole transaction, b/c AFAIK, RAM is then dedicated to the VM. It can be swapped out, I suppose, but that's not great.
The pain of working around Docker Desktop is bad.
I wrote about that angle here: https://igorstechnoclub.com/sandbox-exec/
Feels like the spiritual successor to sandbox-exec, but with VM-level isolation.
Discover container machines
https://developer.apple.com/videos/play/wwdc2026/389/
There's some clever advertising in it for Linux, if Linux was advertising.
As long as there are just few "normies" using Linux, it is safe from corporations adding their "security", "safety" etc.
I currently have one systemd infected machine, two devuan machines and two freebsd. Next step is paving the systemd one (it randomly craps out) and probably putting FreeBSD on it, but I’m on the fence. It’s a family member’s machine, and devuan is less change.
The big thing with Windows laptops is historically, they were slightly more sluggish than Macs because the os/hardware wasn't optimized. On desktops with enough performance, Windows has been king ever since WSL2, considering you can do everything with that system (WSL2 can even run I3WM if you care enough since they have an X server).
Now with Spark and ARM, you can pretty much get a perfect laptop that supports gaming as a first party, can run any windows only software (like CAD for example), and also has WSL2 which is very natively integrated with windows to where it supports CUDA with native like performance.
A
Linux games depend on Windows ecosystem as their content source.
By having Linux nicely packaged in containers, they get to keep the 90% combined market share, almost no one bothers to support the market of Linux OEMs selling pre-installed Linux desktops and laptops.
The other "distros" used by consumers are Android, WebOs and going forward Googlebooks as Chromebooks evolution.
Meaning in the end a Pyrrhic victory, when Apple Linux, Microsoft Linux, Google Linux, Asus Linux, LG Linux, is all that the general public cares about, and hence no incentive for IT departments to support Linux laptops.
I'd stick to Colima, or Orbstack if you trust them enough to not do a rug-pull once their users are reliant on them enough to pay any amount.
I have made it a MCP so that it's easily discoverable by all the coding agents
https://github.com/instavm/coderunner
UX wise it looks kinda neat though!
In my testing (iirc) filesystem performance was not good enough to be usable with node/rust dev where lots of small files get stat-ed
update: what's new is the `container machine` subcommand. I went to test it out, but container failed to run at all for me: https://github.com/apple/container/issues/1681
I am trying it on but its brekaing on homebrew 1.0.0. The formula puts plugins at opt/container/libexec/container-plugins/ and the apiserver looks in libexec/container/plugins/
This can be solved through a symlink or smth
Are you sure about that? A few comments above a commenter states that they don’t run inits at all (because they ran alpine), multiple people replied that it works fine if you give it an image with an init, and they acknowledged their error.
BSD actually has this already.
I'm not sure how it'd defeat the point of having their own kernel.
As for cost, possibly, but it would really be a huge boon to macOS for software devs. It's hard for me to believe that Rosetta isn't similarly costly, but it's been done because running x86 software is still very much a necessity for MacOS.
Because then you'd need to both maintain your kernel AND your own implementation of the Linux ABI, an ABI you don't have control over and that basically forces you to reimplement half on Linux in the first place.
People already get what they want by having a tiny Linux machine running at native speed. In 2026, virtualisation still isn't free, but it's pretty darn close.
A very large portion of that ABI is already implemented due to both systems being POSIX. But further, a lot of what programs actually interact with is already ported to macOS. For example, you can build and use glibc.
Also, I get the lack of control, but that really isn't a major issue. The linux kernel pretty rarely adds new userspace additions. By and large the majority of work that goes into the kernel is around new drivers and fixing drivers. Even when there's kernel level features, it's very often not a userspace thing but rather things like new schedulers.
There's a reason MS didn't see the same approach as being too terribly crazy with WSL1, and those are very different systems. Heck, there's a reason cygwin continues to exist and work.
POSIX provides an API, not an ABI, and that API kind of ends at libc. Being compatible with Linux at an ABI level means being able to provide the same syscalls in the same way as Linux does. Not all Linux syscalls map cleanly to POSIX APIs, and in general xnu has lots of different concepts that make it somewhat cumbersome to adapt to what the Linux kernel does. The example of this is Microsoft with WSL1; they gave up not because Windows was too shoddy but rather because people want ALL of the kernel, which is a moving target anyway. it's a waste of time not to simply run it in the first place, virtualization is cheap and you get the real thing, with no quirks
There's also simply the possibility of using linux software directly in macos without doing OS dependent changes to the software.
Running VMs is really really easy and low maintenance demand on Apple. And it’s guaranteed compatibility.
Wasn’t compatibility what really sunk WSL1?
Yes, but a big part of the problem with WSL1 was the size of the conceptual gap between POSIX and Windows NT that WSL1 had to bridge. An “MSL1” would likely have fewer problems because the gap between macOS and Linux is smaller, given they are both POSIX
The other thing Apple could potentially do, is add Linux-compatible APIs to macOS. IBM wanted to support Kubernetes on their z/OS mainframe operating system, so they implemented on it a clone of Linux namespace APIs, e.g. unshare. Then we could have macOS nodes in a K8S cluster-which might actually be useful for some people, e.g. if you have a Jenkins CI farm, the Linux nodes can run on K8S, but currently macOS nodes (which you need if you are targeting iOS or macOS) can’t, they have to be bare metal or VMs.
More Linux-macOS source compatibility would also benefit macOS by making it less work to port software to it from Linux
It's true that missing ABIs will cause random crashes and problems. However, a lot of apps can run with a minimal set of ABIs.
The target for this isn't GUI stuff.
Maybe that’s not what they intended.
Yes’n’t: https://github.com/apple/container/blob/main/docs/technical-...
> container relies on the new features and enhancements present in macOS 26. You can run container on macOS 15, but you will need to be aware of some user experience and functional limitations. There is no plan to address issues found with macOS 15 that cannot be reproduced on macOS 26.
The issues are around networking.
Maybe hold 1 release back, but other than that, I don't think "holding out" on macOS releases has ever been a winning strategy.
In the end, macOS model presupposes users moving to the latest release sooner rather than later.
It looks like Golden Gate fixes this design a lot.
Doesn’t seem to have Compose support though, but it’s probably not impossible to build upon.
And of course, it also uses VMs, though unlike Docker, it’s one (micro-?) VM per container: https://github.com/apple/container/blob/main/docs/technical-...
By the way, is it headless or can it run a full Linux desktop? Use case: buy a Mac, uninistall whatever can be uninstalled, run the Linux VM as primary desktop forgetting MacOS and without going through Asahi and the incomplete hardware support.
"bind mounts? I'm better without it"
> container runs containers differently. Using the open source Containerization package, it runs a lightweight VM for each container that you create. This approach has the following properties:
> * Security: Each container has the isolation properties of a full VM, using a minimal set of core utilities and dynamic libraries to reduce resource utilization and attack surface.
> * Privacy: When sharing host data using container, you mount only necessary data into each VM. With a shared VM, you need to mount all data that you may ever want to use into the VM, so that it can be mounted selectively into containers.
> * Performance: Containers created using container require less memory than full VMs, with boot times that are comparable to containers running in a shared VM.
So: you build it as a container image and MacOS starts a VM to run it.
Edit: quite unusually for a container it runs systemd. They give an example "systemctl start postgresql".
But it's a tiny one, tightly integrated with macOS hypervisor, and the interface is standard OCI-compatible containers/images. It's not Virtualbox style VM.
However, unlike Lima, an Apple Container is not a full VM, so you cannot SSH to it, or forward SSH-agent signatures into a machine.
So it's more of a devcontainer story, which is also a great use case. Nice to see Apple creating tooling around their VZ framework.
Edit: referential clarity.
It's a full vm
https://github.com/devcontainers/ https://containers.dev/
(Plus, you could always even have amd64 linux containers on macOS AS, with good performance, via Rosetta2).
I would really love if apple could give inexpensive way to run amd64 containers for situations when dev wants to use their own hardware. We've used LIMA for now, was too much of a hussle. But if there's a more native experience – would give it another try.
The proton model has the benefit that bugs on linux can be fixed by Valve and the Wine community. While bugs in an official linux port can only be fixed by the game publisher which rarely happened. There also seems to be virtually no downsides to running a Windows game in Proton. These days I don't even bother checking the Wine DB or proton rating because unless the game is deliberately blocking linux via anti cheat, it will just work.
Linux will stay forever a headless operating system great for embedded, server rooms and containers.
We have all limited time on Earth, and eventually Valve won't be around as it used to be, might even be acquired, sold, whatever, then what in regards to Linux gaming?
Now with the Fex project, it might end up that running Windows games on linux on a modern ARM processor could be the best way to game going forward, especially for mobile platforms like the SteamDeck.
Proton is based on Wine which translates Windows instructions to Linux.
Besides there's already Wine for mac.
But I would love to be wrong here.
Which for many folks is good enough for what they are doing, thus the status quo of desktop platforms will hardly change for current form factors.
I started using Colima a couple of years ago because I got bored of how bad Docker Desktop was and just started using the CLI / the "Services" tool window in whatever Jetbrains IDE I was using at the time anyway. I can't see myself moving away from it any time - having multiple profiles is an absolute winner of a feature for me there, but maybe the next time I set up a Mac from scratch I'll have a play with this.
https://en.wikipedia.org/wiki/Darwin_(operating_system)
https://github.com/PureDarwin/PureDarwin
https://www.reddit.com/r/MacOS/comments/1b75xlv/why_is_darwi...
https://x.com/LeakerApple/status/2018467873308786771 Nuvia
If they were to support darwin containers, what would be the point? Literally nobody would build to it, Linux won.
because nobody does ci/cd against macOS or iOS apps right?
There aren’t any app developers avoiding the Apple ecosystem because there aren’t Darwin containers. They don’t sell server hardware and by all accounts have no intention of ever reentering that space. So they’d spend a bunch of developer cycles to reduce their own revenue stream with no apparent upside beyond “goodwill” which they’ve never been overly concerned about.
If they're investing resources into it regardless, they might at least try making something that Docker for macOS and co. haven't solved the same exact way already. Something that, due to their almost unhealthy obsession with "system integrity", only they can realistically make. Like native containers.
Which is a ton of ‘em.
Why would any serious developer use closed-source code they can't debug and modify? Especially for a production server?
It's the same reason no serious developers or hackers use macOS, like part of the point of being a developer is being able to dig into the code at any layer and debug and fix things.
I know I'm basically taking the bait, but I guess I've not been "seriously" developing stuff for the past decade or two, which is news to me!
That being said, my point isn't that Apple should absolutely focus on making a server OS again. It just saddens me how far behind macOS has fallen as they stopped caring about the fundamentals; back in the day, it would be Linux trailing behind macOS. Nowadays, you can't even have multiple routing tables on the latter, the firewall code was probably last updated in Snow Leopard, and what Apple happily shows off on WWDC is a wrapper around Linux. Something functionally equal can be cobbled up together by anyone sufficiently experienced in minutes, using just Bash, OpenSSH, and QEMU.
I really wish macOS would let me have a similar level of control over applications as Linux with namespaces, without me having to do all the heavy lifting.
Apple uses OpenBSD's Packet Filter [1]; I doubt multiple routing tables are a problem. Back in the Snow Leopard days, it was FreeBSD's IPFW, which is also no slouch.
Whatever a firewall can do, PF can do it.
You can also get a nice GUI for PF [2].
[1]: https://www.openbsd.org/faq/pf/index.html
[2]: https://www.murusfirewall.com/murus/
> I doubt multiple routing tables are a problem.
The lack of them is a limitation for me (complex VM + VPN setup), which requires me to do pretty unholy static routing and address rewriting with pf.
I think even Apple has come across this; they added "scoped routing" (which IMO is a hacky workaround providing some of the functionality you'd get with multiple routing tables) just before iOS shipped with MMS support. Android, for comparison, uses Linux's routing policies and tables to send and receive MMS.
"Exploring Darwin and PureDarwin: The Open-Source Foundation of Apple's Operating Systems" - https://machaddr.substack.com/p/exploring-darwin-and-puredar...
Even Microsoft gave up on Windows and just runs Linux most things except niche cases. Heck, even SQL Server which is expensive piece of machinery got ported to Linux and that's the default target now in their docs.
With that said, one can't deny Apple's success on the b2c side of things so it feels wrong to call their strategy a failure.
Which is why so many projects get burned with their license choices.
I usually run like a db, redis, maybe something like rabbitmq/zeromq and have a app that uses these services (makefile/docker-compose).
I would love to switch if this in fact is a lightweight replacement.
Basically: they’ve moved on.
Apple has never been about supporting legacy platforms with new features. And with over a quarter of revenue and two fifths of Apple's gross profits coming from services, one could argue the incentives run either way.
Enterprise ARM servers are still a niche product, and so are the ARM developer machines running Linux or Windows. Until this significantly changes, Apple will have to provide good x86 interop - or lose the developer market entirely.
Forcing people towards Apple silicon is of course an attractive approach when targeting the large portion of the market using their MacBooks as Facebook browsing machines, but (especially with the new MacBook Neo) what's going to happen when a large portion of the market for high-end MBPs disappears because it turned from the default no-brainer into a liability?
I'm very, very skeptical of this analysis. Certainly "entirely" is hyperbole.
Nobody is coming to save us. But I think that with AI, we have an opportunity to create a zero-cost runtime layer that provides something like Wine or SDL on all platforms. It could/should be the intersection of all mainstream OS features (a bit like the web), with the option to drop down to native components like how Cordova works.
I've been out of the game too long to know if something like this already exists, but would love to contribute.
Note that the thing to get to the thing is runway. With our currently broken open source software (OSS) funding model, we don't have a way to pay developers a stipend of perhaps $24-48k per year (minimum) for their OSS efforts. So they have to work pro bono. That leads to design-by-committee thinking that stands in the way of getting real work done.
So unfortunately we have to pick ourselves up by our bootstraps. I hope to see the creation of a maker's guild someday, where membership provides the stipend, with proceeds coming from the 1 in 10 or 1 in 100 apps that generate a return on investment, to cover the commercial failures. Like Humble Bundle on steroids.
- digression -
Imagine a corporate model, but without gatekeeping, minimum hours or profit. A pure meritocracy working to manifest a gift economy for all.
I'm not aware of an automation-based (instead of artificial-scarcity-based) economic model like this. Solarpunk is more of a cultural revolution, but comes close. Some examples of how it might work:
- Abandoning patents, copyrights and other intellectual property rights in favor of a commons owned by everyone
- Funding drug research but giving away the resulting medication for the cost of production or free
- Universal Basic Income (UBI) or its cousin Universal Basic Capital (UBC) that provides the resources for labor to participate in the exponential gains of capitalism (the missing ladder that the wealthy currently pull up behind them)
China is well on its way to achieving these goals and more by 2049 under its Second Centenary Goal. Meaning that the US is/has been left behind. You can feel it in every way: widespread underemployment, the collapse of our social safety nets, the return of prejudice, our national debt higher than our GDP, CEOs getting compensated hundreds of times more than workers, the upcoming crowning of the first trillionaire. Times 1000 other injustices.
Solving the thing that gets to the thing is akin to solving all things.
Edit: I was wrong about intellectual property (IP) in China. It sounds like they will instead pursue high-value IP to fund their economy, a bit like the UBI funding model. I don't think that's an equitable path, so am suggesting something above and beyond what they're attempting.
Daily driver is a 6yo, 32Mb mbp and it might not scream like an M5 or have the miraculous power draw of an M5, it gets my job done.
One nice thing is x86 containers run natively: I run most of my $work landscape which is 40 or 50 k8s pods on top of Kind, which is itself a plain container. That mirrors my prod. That plus slack, zoom, ff with scores of tabs, etc. all while building rust and playing music.
Blog post soon
* need a usb sdcard reader for macbook pro cause the builtin is not usb)
They've now added a WSL-style virtual machine layer, but there's no x86 container story (Apple's killing Rosetta) so I imagine some qemu shimming will be required.
There's still no equivalent to VPNKit or GVisor for networking so you'll be bridging I think. See: https://cacm.acm.org/research/a-decade-of-docker-containers/ for how Docker for Mac does this
I can't spot any support for dynamic memory ballooning to prevent the hypervisor from gobbling up too much memory. We've had this in Xen since forever! https://xenproject.org/blog/ballooning-rebooting-and-the-fea...
And, most obviously: NO SUPPORT FOR MACOS. This is the single feature that only Apple can do, and they're choosing not to implement it deliberately, and it's so stupid given the pains we all have to go through to implement CI for macOS. In the land of OCaml, we were forced to implement a custom ZFS snapshotter to get reasonably cost effective macOS CI for our package repository: https://tarides.com/blog/2023-08-02-obuilder-on-macos/. This was fun to build, but it sucks to have to maintain it.
Also, I'm really curious what the GPU passthrough story here is for LLMs, since the Apple Silicon -> Linux kernel support is gated on Asahi's support, but that's been lagging beyond M2 due to the efforts of reverse engineering.
Do better for your developers, Apple. This is a half-baked sweep across third-party software without addressing the core needs around your own operating system.
In production though, I've moved completely to systemd isolation of apps, rather than Docker-like containers; essentially blackboxes and present a supply chain threat. There's also a DRY principle here. Verification of a host presents a much smaller surface area.
On MacOS?
> In Production
https://github.com/darwin-containers
However it requires disabling SIP, so that's unfortunately a non-starter for anything serious today.
It’s the only legal way to do so, due to the software license on MacOS.
(you remote into a system and part of your environment comes with you; that's very Plan9-like.)
LE: nevermind, it is already on MacOS. Did not read everything.
you can now run linux containers on your mac
... but it could be better.
what about (totally contrived):
Yeah I was working on that, created a prototype. I don't see a business in it, so abandoned.
I'm saying the older version of macos could build/run INSIDE the container
just like on a ubuntu 24.04 system you can do:
or and though I haven't tried it, I believe docker can do arm in x86 using an emulator (like rosetta)So it seems like in theory that should be doable if someone just made the container images right?
Framework is trying to close that gap with their new release, but we’ll have to see how it is once people get their hands on it. I think it also comes at a price premium. There is always the Thinkpad route, but Lenovo burned just about every bridge with me a decade ago with things like Superfish. Where is the premium Linux laptop OEM that people can trust? Last I heard System76 was just rebranding Clevo hardware. What are people using? Dell? HP?
https://privsec.dev/posts/linux/linux-insecurities/
https://madaidans-insecurities.github.io/linux.html
I also commented here on Linux phones, the same can apply to Linux as a desktop OS: https://news.ycombinator.com/item?id=46997397
Also on top of that Linux/Windows laptops also lack the hardware-backed security that Macs and to an extent some Chromebooks have.
https://news.ycombinator.com/item?id=48448345 // When people escalate privileges on MacOS it's news, when they do it on Linux it's Tuesday (you might think the recent spate of privesc vulns on Linux was unusual but that is totally normal). I say this as someone who works on Linux security every day (I am a kernel developer) and uses Linux on every computer I have, both at work and at home, BTW. I am not a Linux hater or Apple fanboy by any means.
https://news.ycombinator.com/item?id=48444187 // I am just talking about the pure tech fact that GNU/Linux desktops do not have any meaningful intra-host security boundaries.
https://news.ycombinator.com/item?id=48059250 // To convince me Linux is full of kernel LPE bugs, can you share some of the bugs? [answered by the kernel dev]
I also have some cites of comments on Linux by the founder of GrapheneOS I could dig up.
No amount of Linux hardening will get a system even close to an M-chip Mac. Software insecurities aside, desktop Linux OS systems have almost none of the hardware-backed security benefits that Macs do.
I don't think Apple is particularly any more secure against the US government than Intel is with supply chain vulnerabilities but I have nothing to back that up with aside from vibes.
This is a step in the right direction but requires any given developer’s buy-in first, right?