macOS Container Machines
Posted by timsneath 7 days ago
Comments
Comment by timsneath 7 days ago
Comment by jt2190 7 days ago
> - 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-...
Comment by mikepurvis 7 days ago
Comment by sqquima 6 days ago
Comment by parl_match 6 days ago
Comment by jjtheblunt 7 days ago
Which kernel is running, and is it hosted in hypervisor.framework, as is done with UTM (when not using the qemu mode)?
Comment by Scarbutt 7 days ago
Comment by Onavo 7 days ago
Comment by CGamesPlay 7 days ago
Comment by AlexB138 7 days ago
Comment by gsnedders 7 days ago
Comment by selcuka 7 days ago
Comment by rvz 7 days ago
Comment by LoganDark 7 days ago
Comment by mjg59 7 days ago
Comment by alerighi 7 days ago
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.
Comment by 0x1d7 7 days ago
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.
Comment by sterlind 7 days ago
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.
Comment by smallnamespace 7 days ago
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.
Comment by someguyiguess 7 days ago
Comment by khana 6 days ago
Comment by LoganDark 7 days ago
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?
Comment by barrkel 7 days ago
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.
Comment by TylerE 7 days ago
Comment by qalmakka 7 days ago
Comment by naishoya 7 days ago
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.
Comment by pjmlp 7 days ago
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.
Comment by hnlmorg 7 days ago
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.
Comment by nyrikki 7 days ago
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.
Comment by qalmakka 6 days ago
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
Comment by hnlmorg 6 days ago
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.
Comment by hnlmorg 6 days ago
Linux encouraged people to fork and experiment with it. Whereas the FreeBSD was a carefully maintained ecosystem.
Comment by pjmlp 7 days ago
Minix was a toy OS for university teachings.
Coherent was commercial.
Nothing else was there on the PC market.
Comment by hnlmorg 7 days ago
FreeBSD was also used heavily in the late 90s in ISPs and similar domains.
Comment by nyrikki 7 days ago
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.
Comment by hnlmorg 6 days ago
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.
Comment by manithree 7 days ago
Comment by hnlmorg 6 days ago
Which simply wasn’t enough drama to persuade businesses on smaller budgets away from using FreeBSD.
Comment by pjmlp 7 days ago
Also SCO lawsuit was more due to IBM's money than Linux.
Both a different situation than Windows NT being available a decade earlier.
Comment by hnlmorg 6 days ago
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.
Comment by pjmlp 6 days ago
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.
Comment by hnlmorg 6 days ago
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…
Comment by qalmakka 6 days ago
Comment by noduerme 7 days ago
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.
Comment by TylerE 7 days ago
Comment by bschwindHN 7 days ago
https://old.reddit.com/r/ProgrammerHumor/comments/96ufiz/pro...
Comment by rpeden 7 days ago
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.
Comment by TylerE 7 days ago
Comment by noduerme 7 days ago
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)
Comment by coldtea 7 days ago
Comment by kergonath 7 days ago
You still can, and it still works exactly the same way.
Comment by procflora 7 days ago
Comment by iririririr 7 days ago
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.
Comment by metaltyphoon 7 days ago
Many enterprises allow windows only so your way into Linux is via WSL2
Comment by oso2k 6 days ago
Comment by TylerE 7 days ago
Comment by _blk 7 days ago
Comment by michaelsbradley 7 days ago
Comment by kevinminehart 7 days ago
Comment by dented42 7 days ago
Comment by pjmlp 7 days ago
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...
Comment by embedding-shape 7 days ago
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.
Comment by pjmlp 7 days ago
Comment by embedding-shape 6 days ago
I'm not sure if you see the quoted part. My comment is about the part that starts with "> " that you wrote earlier.
Comment by alerighi 7 days ago
Comment by mrpippy 7 days ago
Comment by jayd16 7 days ago
Comment by musicale 1 day ago
But (some) people still criticize it because it's not Linux or FreeBSD (though it is closer to the latter than the former).
Comment by BodyCulture 7 days ago
Comment by burnte 7 days ago
Comment by hedora 7 days ago
Comment by pseudosavant 7 days ago
Comment by bogantech 7 days ago
How is this different to bind mounts
Comment by jdub 7 days ago
Comment by miohtama 7 days ago
Comment by jdub 7 days ago
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.
Comment by AtlasBarfed 6 days ago
Comment by jdub 6 days ago
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)
Comment by lxgr 7 days ago
Comment by jdub 7 days ago
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...
Comment by lxgr 7 days ago
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.
Comment by jdub 7 days ago
Comment by fc417fc802 6 days ago
Comment by jdub 6 days ago
Comment by oulipo2 7 days ago
Comment by CaptainCyber99 7 days ago
Comment by golem14 7 days ago
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
Comment by binsquare 7 days ago
Comment by apitman 6 days ago
Comment by binsquare 6 days ago
Comment by chrisweekly 6 days ago
Comment by djsavvy 7 days ago
Comment by klohto 7 days ago
Comment by startakovsky1 7 days ago
Comment by happyopossum 7 days ago
Comment by cowsandmilk 7 days ago
Comment by golem14 6 days ago
Comment by qalmakka 7 days ago
Comment by cedws 7 days ago
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.
Comment by RationPhantoms 7 days ago
Comment by whimblepop 7 days ago
Comment by gyoridavid 7 days ago
Comment by jorisw 7 days ago
Comment by qalmakka 7 days ago
Comment by tonymet 6 days ago
Comment by adastra22 7 days ago
Comment by qalmakka 7 days ago
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
Comment by coldtea 7 days ago
Comment by inejge 7 days ago
Comment by larodi 7 days ago
Comment by qalmakka 7 days ago
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
Comment by blahgeek 7 days ago
Comment by kdrag0n 7 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.
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.
Comment by egernst 7 days ago
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-...
Comment by rubnogueira 7 days ago
Comment by kdrag0n 7 days ago
Comment by mescalito 7 days ago
> 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?
Comment by kdrag0n 7 days ago
Comment by kxxx 7 days ago
"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."
Comment by kdrag0n 7 days ago
Comment by kxxx 7 days ago
Comment by d3v1an7 7 days ago
Comment by CGamesPlay 7 days ago
Wow, missed this when reviewing OrbStack. I assumed that you just used Containerization and therefore would have the same limitation.
Comment by saltamimi 7 days ago
Comment by kdrag0n 7 days ago
Comment by rswail 7 days ago
This post reminded me to buy a license, just done it, worth it for the time saved.
Comment by trueno 7 days ago
Comment by TheTaytay 7 days ago
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
Comment by kdrag0n 7 days ago
Comment by jhancock 7 days ago
Comment by thatxliner 7 days ago
Comment by torarnv 7 days ago
Comment by rahen 7 days ago
Comment by kdrag0n 7 days ago
Comment by vsgherzi 7 days ago
Comment by blackqueeriroh 7 days ago
Comment by keybits 7 days ago
Nothing specific for Docker yet, but I find the Linux machines are lightweight enough that I just run Docker inside them.
Comment by bjt12345 7 days ago
Comment by bekantan 7 days ago
Comment by emmelaich 7 days ago
AFAICT it's pretty similar.
Comment by eatonphil 7 days ago
Comment by mpeg 7 days ago
Comment by Ghoelian 7 days ago
Comment by baq 7 days ago
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.
Comment by kxxx 7 days ago
Comment by pojzon 6 days ago
Comment by cpuguy83 7 days ago
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.
Comment by gempir 7 days ago
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.
Comment by kdrag0n 7 days ago
Comment by gempir 7 days ago
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
Comment by jnewton_dev 7 days ago
Comment by gempir 7 days ago
Comment by kiproping 7 days ago
Comment by garganzol 6 days ago
Comment by jbverschoor 7 days ago
Comment by WatchDog 7 days ago
Edit: It's a VM per container. https://github.com/apple/container/blob/main/docs/technical-...
Comment by kenanfyi 7 days ago
Comment by sigmoid10 7 days ago
[1] https://cheatsheetseries.owasp.org/cheatsheets/Docker_Securi...
Comment by lxgr 7 days ago
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.
Comment by sigmoid10 7 days ago
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.
Comment by lxgr 7 days ago
Comment by fc417fc802 6 days ago
AFAICT all the security problems are fairly obvious own goals inflicted after that point.
Comment by kenanfyi 7 days ago
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.
Comment by pojzon 6 days ago
Comment by LoganDark 7 days ago
Comment by kenanfyi 7 days ago
I guess my use case is not that important for the main user of these tools.
Comment by LoganDark 7 days ago
Comment by kenanfyi 7 days ago
Comment by saljam 7 days ago
i'd still use less permissive containers for things i don't feel comfortable installing on the host, e.g. npm.
Comment by stefan_ 7 days ago
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..
Comment by coldtea 7 days ago
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.
Comment by jlhawn 7 days ago
Comment by jaimehrubiks 7 days ago
Comment by usernametaken29 7 days ago
Comment by deathanatos 7 days ago
That said, colima still has the expensive VM that upthread is mentioning.
Comment by TimTheTinker 7 days ago
Comment by noname120 6 days ago
Comment by CarlitosHighway 7 days ago
Comment by TimTheTinker 7 days ago
Comment by thejazzman 7 days ago
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
Comment by deathanatos 7 days ago
> 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.
Comment by MBCook 7 days ago
Comment by nozzlegear 7 days ago
Comment by lxgr 7 days ago
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.
Comment by binsquare 7 days ago
Comment by lostlogin 7 days ago
The pain of working around Docker Desktop is bad.
Comment by trollbridge 7 days ago
Comment by prmoustache 7 days ago
Comment by Igor_Wiwi 7 days ago
I wrote about that angle here: https://igorstechnoclub.com/sandbox-exec/
Feels like the spiritual successor to sandbox-exec, but with VM-level isolation.
Comment by avel 7 days ago
Comment by ChrisArchitect 7 days ago
Discover container machines
Comment by cromka 7 days ago
There's some clever advertising in it for Linux, if Linux was advertising.
Comment by rahkiin 7 days ago
Comment by artistonn 7 days ago
Comment by krzyk 7 days ago
Comment by cromka 7 days ago
Comment by krzyk 7 days ago
As long as there are just few "normies" using Linux, it is safe from corporations adding their "security", "safety" etc.
Comment by cromka 7 days ago
Comment by hedora 7 days ago
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.
Comment by fc417fc802 6 days ago
Comment by regexorcist 7 days ago
Comment by QuiEgo 7 days ago
Comment by regexorcist 7 days ago
Comment by cromka 7 days ago
Comment by ActorNightly 6 days ago
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
Comment by plutokras 7 days ago
Comment by pjmlp 7 days ago
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.
Comment by neop1x 7 days ago
Comment by cromka 7 days ago
Comment by nozzlegear 6 days ago
Comment by 0xbadcafebee 7 days ago
Comment by CarlitosHighway 7 days ago
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.
Comment by lxgr 7 days ago
Comment by einsteinx2 7 days ago
Comment by mkagenius 7 days ago
I have made it a MCP so that it's easily discoverable by all the coding agents
Comment by bicepjai 7 days ago
Comment by rakel_rakel 7 days ago
UX wise it looks kinda neat though!
Comment by borborigmus 7 days ago
Comment by llimllib 7 days ago
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
Comment by kdrag0n 7 days ago
Comment by ahknight 7 days ago
Comment by dchest 7 days ago
Comment by noobcoder 7 days ago
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
Comment by masklinn 7 days ago
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.
Comment by cogman10 7 days ago
BSD actually has this already.
Comment by qalmakka 7 days ago
Comment by cogman10 7 days ago
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.
Comment by qalmakka 6 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.
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.
Comment by cogman10 6 days ago
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.
Comment by qalmakka 6 days ago
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
Comment by twoodfin 7 days ago
Comment by cogman10 7 days ago
There's also simply the possibility of using linux software directly in macos without doing OS dependent changes to the software.
Comment by MBCook 7 days ago
Running VMs is really really easy and low maintenance demand on Apple. And it’s guaranteed compatibility.
Wasn’t compatibility what really sunk WSL1?
Comment by skissane 7 days ago
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
Comment by qalmakka 7 days ago
Comment by cogman10 7 days ago
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.
Comment by coldtea 7 days ago
The target for this isn't GUI stuff.
Comment by MBCook 7 days ago
Maybe that’s not what they intended.
Comment by tannhaeuser 7 days ago
Comment by masklinn 7 days ago
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.
Comment by niek_pas 7 days ago
Comment by coldtea 7 days ago
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.
Comment by jrochkind1 7 days ago
Comment by nozzlegear 6 days ago
Comment by egorfine 7 days ago
It looks like Golden Gate fixes this design a lot.
Comment by jorisw 7 days ago
Comment by osigurdson 7 days ago
Comment by marssaxman 7 days ago
Comment by emulio 7 days ago
Comment by notpushkin 7 days ago
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-...
Comment by musicale 1 day ago
Comment by pmontra 7 days ago
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.
Comment by iririririr 7 days ago
"bind mounts? I'm better without it"
Comment by coldtea 7 days ago
Comment by pmontra 7 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.
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".
Comment by coldtea 6 days ago
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.
Comment by yeswecatan 7 days ago
Comment by katspaugh 7 days ago
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.
Comment by binsquare 7 days ago
It's a full vm
Comment by Joyfield 7 days ago
Comment by jzer0cool 7 days ago
Comment by numbsafari 7 days ago
Comment by RossBencina 7 days ago
Comment by CGamesPlay 7 days ago
Comment by jayd16 7 days ago
Comment by LaFolle 7 days ago
Comment by KeplerBoy 7 days ago
Comment by coldtea 7 days ago
(Plus, you could always even have amd64 linux containers on macOS AS, with good performance, via Rosetta2).
Comment by k_bx 7 days ago
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.
Comment by vachanmn123 7 days ago
Comment by xd1936 7 days ago
Comment by aurareturn 7 days ago
Comment by mohamedkoubaa 7 days ago
Comment by kergonath 7 days ago
Comment by Gigachad 7 days ago
Comment by pjmlp 7 days ago
Comment by asimovDev 7 days ago
Comment by Gigachad 7 days ago
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.
Comment by pjmlp 7 days ago
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?
Comment by Gigachad 7 days ago
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.
Comment by pjmlp 7 days ago
Comment by bel8 7 days ago
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.
Comment by pjmlp 7 days ago
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.
Comment by aspeckt_112 7 days ago
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.
Comment by rickstanley 7 days ago
Comment by opengears 7 days ago
Comment by m132 7 days ago
Comment by Danox 6 days ago
https://en.wikipedia.org/wiki/Darwin_(operating_system)
https://github.com/PureDarwin/PureDarwin
https://www.reddit.com/r/MacOS/comments/1b75xlv/why_is_darwi...
Comment by groundzeros2015 7 days ago
Comment by al_borland 7 days ago
Comment by tw04 7 days ago
If they were to support darwin containers, what would be the point? Literally nobody would build to it, Linux won.
Comment by riffic 7 days ago
because nobody does ci/cd against macOS or iOS apps right?
Comment by tw04 7 days ago
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.
Comment by m132 7 days ago
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.
Comment by tw04 7 days ago
Comment by MBCook 7 days ago
Which is a ton of ‘em.
Comment by pjmlp 7 days ago
Comment by ahknight 7 days ago
Comment by TheDong 7 days ago
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.
Comment by bschwindHN 7 days ago
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!
Comment by m132 7 days ago
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.
Comment by alwillis 7 days ago
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].
Comment by m132 7 days ago
> 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.
Comment by alwillis 7 days ago
"Exploring Darwin and PureDarwin: The Open-Source Foundation of Apple's Operating Systems" - https://machaddr.substack.com/p/exploring-darwin-and-puredar...
Comment by pjmlp 7 days ago
Comment by vehemenz 7 days ago
Comment by bel8 7 days ago
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.
Comment by pjmlp 7 days ago
Which is why so many projects get burned with their license choices.
Comment by gf000 7 days ago
Comment by pjmlp 7 days ago
Comment by a1o 7 days ago
Comment by jdub 7 days ago
Comment by cpach 7 days ago
Comment by frizlab 7 days ago
Comment by whycombinetor 7 days ago
Comment by commandersaki 7 days ago
Comment by whycombinetor 7 days ago
Comment by kstenerud 7 days ago
Comment by phplovesong 7 days ago
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.
Comment by masklinn 7 days ago
Comment by happyopossum 7 days ago
Comment by brianmartin039 5 days ago
Comment by harrouet 7 days ago
Comment by nottorp 7 days ago
Comment by solenoid0937 7 days ago
Comment by thedougd 7 days ago
Comment by yurimo 7 days ago
Comment by almaight 7 days ago
Comment by Havoc 7 days ago
Comment by namegulf 7 days ago
Comment by MBCook 7 days ago
Basically: they’ve moved on.
Comment by danhon 7 days ago
Comment by joshuat 7 days ago
Comment by JumpCrisscross 7 days ago
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.
Comment by crote 7 days ago
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?
Comment by macintux 7 days ago
I'm very, very skeptical of this analysis. Certainly "entirely" is hyperbole.
Comment by solarkraft 7 days ago
Comment by ForOldHack 7 days ago
Comment by weikju 7 days ago
Comment by ForOldHack 5 days ago
Comment by jdub 7 days ago
Comment by zackmorris 6 days ago
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.
Comment by teaearlgraycold 7 days ago
Comment by imglorp 7 days ago
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.
Comment by MBCook 7 days ago
Comment by teaearlgraycold 7 days ago
Comment by ncr100 7 days ago
Comment by Brian_K_White 7 days ago
Comment by krzyk 7 days ago
Comment by gigatexal 7 days ago
Comment by commandersaki 7 days ago
Comment by kdrag0n 7 days ago
Blog post soon
Comment by blackqueeriroh 7 days ago
Comment by calebm 7 days ago
Comment by commandersaki 7 days ago
* need a usb sdcard reader for macbook pro cause the builtin is not usb)
Comment by kdrag0n 7 days ago
Comment by egernst 7 days ago
Comment by commandersaki 7 days ago
Comment by nikisweeting 6 days ago
Comment by rgovostes 7 days ago
Comment by shelled 7 days ago
Comment by konaraddi 7 days ago
Comment by avsm 7 days ago
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.
Comment by throw1234567891 7 days ago
Comment by lanycrost 5 days ago
Comment by rcarmo 7 days ago
Comment by happyopossum 7 days ago
Comment by sachinjoseph 7 days ago
Comment by exabrial 7 days ago
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.
Comment by Melatonic 6 days ago
Comment by sdevonoes 7 days ago
Comment by zekrioca 7 days ago
Comment by CSDude 7 days ago
Comment by Cadwhisker 7 days ago
Comment by alwinaugustin 7 days ago
Comment by zer0zzz 7 days ago
Comment by asxndu 7 days ago
Comment by riffic 7 days ago
Comment by riffic 6 days ago
https://github.com/darwin-containers
However it requires disabling SIP, so that's unfortunately a non-starter for anything serious today.
Comment by tonymet 7 days ago
Comment by beemboy 7 days ago
Comment by michaelsbradley 7 days ago
Comment by blackqueeriroh 7 days ago
Comment by MBCook 7 days ago
It’s the only legal way to do so, due to the software license on MacOS.
Comment by running101 7 days ago
Comment by naikrovek 7 days ago
(you remote into a system and part of your environment comes with you; that's very Plan9-like.)
Comment by ShinyLeftPad 7 days ago
Comment by kosikond 7 days ago
Comment by jbverschoor 7 days ago
Comment by t1234s 7 days ago
Comment by ExoticPearTree 7 days ago
LE: nevermind, it is already on MacOS. Did not read everything.
Comment by asxndu 7 days ago
Comment by cdnsteve 7 days ago
Comment by m463 7 days ago
you can now run linux containers on your mac
... but it could be better.
what about (totally contrived):
FROM apple/macos:10.11.6
RUN xcodebuild -project myapp.xcodeproj -scheme MyScheme -configuration ReleaseComment by webXL 7 days ago
Comment by m463 7 days ago
ENV XCODE_FRONTEND=unattended
ENV XCODE_LICENSES=accept,firstborn,applepay,appleid=sjobs@me.comComment by trollbridge 7 days ago
services:
macos:
image: dockurr/macos
container_name: macos
environment:
VERSION: "15"
(And indecently slow.)Comment by egorfine 7 days ago
Yeah I was working on that, created a prototype. I don't see a business in it, so abandoned.
Comment by windowliker 7 days ago
Comment by m463 7 days ago
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)Comment by MBCook 7 days ago
So it seems like in theory that should be doable if someone just made the container images right?
Comment by windowliker 7 days ago
Comment by jadar 7 days ago
Comment by lzwjava 7 days ago
Comment by zoetaylor00 5 days ago
Comment by GHanku 7 days ago
Comment by Lapsa 7 days ago
Comment by sourcegrift 7 days ago
Comment by al_borland 7 days ago
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?
Comment by hollerith 7 days ago
Comment by pixelatedindex 7 days ago
Comment by armadyl 7 days ago
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.
Comment by hollerith 7 days ago
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.
Comment by JumpCrisscross 7 days ago
Comment by armadyl 7 days ago
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.
Comment by TimTheTinker 7 days ago
Comment by armadyl 7 days ago
Comment by JumpCrisscross 7 days ago
Comment by armadyl 7 days ago
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.
Comment by dvhh 7 days ago
Comment by xiaodai 7 days ago
Comment by jwlake 7 days ago
Comment by itsneulook4 7 days ago
Comment by itsneulook4 7 days ago
Comment by khazhoux 7 days ago
Comment by Barbing 7 days ago
This is a step in the right direction but requires any given developer’s buy-in first, right?