Live data from Hacker News

Apple announces Foundation Models and Containerization frameworks, etc

apple.com

361–370 of 514 posts

Re: Apple announces Foundation Models and Containerization frameworks, etc

#361

Earlier quoted context omitted.

> And it's local and on device. Does that explain why you don't have to worry about token usage? The models run locally?

> You don’t have to worry about the exact tokens that Foundation Models operates with, the API nicely abstracts that away for you [1] I have the same question. Their Deep dive into the Foundation Models framework video is nice for seeing code using the new `FoundationModels` library but for a "deep dive", I would like to learn more about tokenization. Hopefully these details are eventually disclosed unless someone el…

I guess I'd say "mu", from a dev perspective, you shouldn't care about tokens ever - if your inference framework isn't abstracting that for you, your first task would be to patch it to do so.

To parent, yes this is for local models, so insomuch worrying about token implies financial cost, yes

Re: Apple announces Foundation Models and Containerization frameworks, etc

#362
post #137

I hoped for a moment that "Containerization Framework" meant that macOS itself would be getting containers. Running Linux containers and VMs on macOS via virtualization is already pretty easy and has many good options. If you're willing to use proprietary applications to do this, OrbStack is the slickest, but Lima/Colima is fine, and Podman Desktop and Rancher Desktop work well, too. The thing macOS really painfully…

What would these be useful for?

I might misunderstand the project, but I wish there was a secure way for me to execute github projects. Recently, the OS has provided some controls to limit access to files, etc. but I'd really like a "safe boot" version that doesn't allow the program to access the disk or network.

the firewall tools are too clunky (and imho unreliable).

Re: Apple announces Foundation Models and Containerization frameworks, etc

#363

Earlier quoted context omitted.

Using a hypervisor means just running a Linux VM, like WSL2 does on Windows. There is nothing native about it. Native Linux (and Docker) support would be something like WSL1, where Windows kernel implemented Linux syscalls.

Surely if Windows kernel can be taught to respond to those syscalls, XNU can be taught it even easier. But, AIUI the Windows kernel already had a concept of "personalities" from back when they were trying to integrate OS/2 so that zero-to-one for XNU could be a huge lift, not the syscalls part specifically

XNU similarly has a concept of "flavors" and uses FreeBSD code to provide the BSD flavor. Theoretically, either Linux code or a compatibility layer could be implemented in the kernel in a similar way. The former won't happen due to licensing.

Re: Apple announces Foundation Models and Containerization frameworks, etc

#364

Earlier quoted context omitted.

On Android devices with AVB (so basically everything nowadays), once the bootloader is unlocked, so many things already either lock you out or degrade your service in various ways. For example, Netflix will downgrade you to 480p, Google Pay will stop working, many apps will just straight up disappear from the Play Store because SafetyNet will stop passing (especially on newer devices with hardware attestation), banki…

Out of interest, are you currently using android (or fork) or iOS?

I used Android until around last January year when I switched to iPhone, because it works better with Mac (which I'd switched back to about a month prior, after having enough of around four years of dealing with Windows's bullshit). Not that Android worked well with Windows... I just didn't even have the idea in my head that devices could work well together at all. AirDrop changed my mind! (And all the other niceties, like Do Not Disturb syncing, and so on...)

I used to tweak/mod Android and most recently preferred customizing the OEM install over forks. I stopped doing that when TWRP ran something as OpenRecoveryScript and immediately wiped the phone without giving me any opportunity to cancel. My most recent Android phone I never bothered to root. I may never mod Android again.

Re: Apple announces Foundation Models and Containerization frameworks, etc

#365
Related ongoing threads:

Containerization is a Swift package for running Linux containers on macOS - https://news.ycombinator.com/item?id=44229348 - June 2025 (158 comments)

Container: Apple's Linux-Container Runtime - https://news.ycombinator.com/item?id=44229239 - June 2025 (11 comments)

Re: Apple announces Foundation Models and Containerization frameworks, etc

#366

Earlier quoted context omitted.

> You're either fully locked in, or fully on your own. I'm not sure what you mean by that. You can trivially root a Pixel factory image. And if you're talking about how they will punish you for that by removing certain features: Apple does that too (but to a lesser extent). https://github.com/cormiertyshawn895/RecordingIndicatorUtili...

On Android devices with AVB (so basically everything nowadays), once the bootloader is unlocked, so many things already either lock you out or degrade your service in various ways. For example, Netflix will downgrade you to 480p, Google Pay will stop working, many apps will just straight up disappear from the Play Store because SafetyNet will stop passing (especially on newer devices with hardware attestation), banki…

That is a good point. I wish dual booting with different security settings was possible on Android as well. The incentives for Google to implement that aren't really there though.

Re: Apple announces Foundation Models and Containerization frameworks, etc

#367

Earlier quoted context omitted.

the only macbook I’ve tried to put linux on was a t2 machine, and it still doesn’t sleep/suspend right, so I’m a bit skeptical that apple is really leading the way here, but maybe I’ve just not touched any recent windows devices either

To be fair, sleep/suspend has been a rather infamously difficult problem for Linux when it comes to devices that weren't designed to run Linux. I think the Macs with T2 chips were a bit weird anyway and I wonder if they had already been working on Apple Silicon Macs that far back and that's why the T2 became a thing?

Apple is also rather notorious for tinkering with Intel's ACPI files, for better or worse. Suspend is finnecky enough on hardware that supports it, and probably outright impossible if your CPU power states disagree with what the software is expecting.

Re: Apple announces Foundation Models and Containerization frameworks, etc

#368

Earlier quoted context omitted.

To be fair, this is how homebrew for Apple devices has always worked. You've always had to effectively reverse engineer the platform in order to write privileged code. Although I get the argument that if Apple were explicitly trying to support alternative operating systems they probably could have done more to make it easy, really what they were doing with this was first and foremost enabling additional use cases for…

It's not how homebrew worked on Intel Macs, or even PowerMacs[0] either. It's a change made with the Apple Silicon lineup - I cannot speak on Apple's behalf to tell you why they did that. But I can blame UEFI as the reason why the M3 continues to have pitiful Linux support when brand-new AMD and Intel chips have video drivers and power management on Day One. [1] https://mac-classic.com/articles/open-firmware-basics/

The EFI environment does provide some basic drivers for the boot environment, but they all go away once the OS loads, except for a handful of functions such as EFI variable management. (Linux can also reuse a framebuffer originally obtained from EFI for a very limited form of video support - efifb - but that’s not proper video support.) So EFI doesn’t get credit for video drivers or power management.

For power management, you can however give some credit to ACPI, which is not directly related to UEFI (it predates it), but is likewise an open standard, and is generally found on the same devices as UEFI (i.e. PCs and ARM servers). ACPI also provides the initial gateway to PCIe, another open standard; so if you have a discrete video card then you can theoretically access it without chipset-specific drivers (but of course you still need a driver for the card itself).

But for onboard video, and I believe a good chunk of power management as well, the credit goes to drivers written for Linux by the hardware vendors.

Re: Apple announces Foundation Models and Containerization frameworks, etc

#369

Earlier quoted context omitted.

FWIW, here are the repos for the CLI tool [1] and backend [2]. Looks like it is indeed VM-based container support (as opposed to WSLv1-style syscall translation or whatever): Containerization provides APIs to: [...] - Create an optimized Linux kernel for fast boot times. - Spawn lightweight virtual machines. - Manage the runtime environment of virtual machines. [1] https://github.com/apple/container [2] https://githu…

WSLv1 never supported a native docker (AFAIK, perhaps I'm wrong?) That said, I'd think apple would actually be much better positioned to try the WSL1 approach. I'd assume apple OS is a lot closer to linux than windows is.

In the end they're probably run into the same issues that killed WSL1 for Microsoft— the Linux kernel has enormous surface area, and lots of pretty subtle behaviour, particularly around the stuff that is most critical for containers, like cgroups and user namespaces. There isn't an externally usable test suite that could be used to validate Microsoft's implementation of all these interfaces, because... well, why would there be?

Maintaining a working duplicate of the kernel-userspace interface is a monumental and thankless task, and especially hard to justify when the work has already been done many times over to implement the hardware-kernel interface, and there's literally Hyper-V already built into the OS.

Re: Apple announces Foundation Models and Containerization frameworks, etc

#370

Earlier quoted context omitted.

To be fair, this is how homebrew for Apple devices has always worked. You've always had to effectively reverse engineer the platform in order to write privileged code. Although I get the argument that if Apple were explicitly trying to support alternative operating systems they probably could have done more to make it easy, really what they were doing with this was first and foremost enabling additional use cases for…

It's not how homebrew worked on Intel Macs, or even PowerMacs[0] either. It's a change made with the Apple Silicon lineup - I cannot speak on Apple's behalf to tell you why they did that. But I can blame UEFI as the reason why the M3 continues to have pitiful Linux support when brand-new AMD and Intel chips have video drivers and power management on Day One. [1] https://mac-classic.com/articles/open-firmware-basics/

Sorry, I should have specified Apple Silicon rather than just "Apple devices". Obviously the devices that used widely supported CPUs running pretty much widely supported firmware were pretty easy to install non-Apple things on. My Mid-2015 A1398 ran a triple boot between macOS, Windows and Arch Linux thanks to rEFInd.
Post reply on HN