The people complaining that Apple copied a good thing are missing the point. If Apple includes containerization on macOS by default (even if you have to enable it manually), more developers can just target Linux instead of Linux and macOS for certain types of applications (real bash scripts with GNU coreutils instead of the trash that Apple ships, servers, etc.).
I love how all the major operating systems are adding ways to run Linux. Even Android which arguably IS Linux.
I do find it funny how android is Linux yet their Linux feature is a VM
Because google doesn’t want you doing anything
that they can’t controlfun on the host Android system. They did the same thing with crostini on ChromeOS for “security”.People say this but I’m not sure I believe that. Keep in mind Google is the only android OEM that allows you to do a bootloader unlock and root without an exploit, it’s officially supported as a developer configuration.
macOS 26? I thought the last version was 15…
They’re basically copying Samsung (and the auto industry) and switching to using the year of the release instead of iterative naming schemes.
Looks like they’re jumping from 15 to 26, in fact they’re doing the same thing for iOS, jumping from 18 to 26 for the next release. Looks like they’re synchronizing all their OS version numbers using the year they’ll be primarily used(i.e. 2026) from what I can find.
This is my preferred versioning format for user-facing software, by far.
I feel like Semver should also adopt the date inclusion, like 7.4.2-202606 or even 7.4.202606 — you can even extended it to multiple daily releases like 7.4.20260610.1233
There’s too much software to mentally track when each version was released. You should be able to tell at a glance.
I’m not an apple person, so even I saw news about iOS I thought “how the fuck are they on 26 already?”
I didn’t really care, but I appreciate the explanation.
Tbh I’m not an apple person either. The comment about macOS being on 26 caught my eye and I went and did some research.
We need to develop darling too
Wine is successful because of the decades of work put into it. For Darling to reach that level of support it would need a herculean amount of effort as well.
Darling is a cool project but I think the reason it hasn’t taken off is because there isn’t a lot of software people both want to use on Linux and software that isn’t already covered by wine. You need an overlap between those 2 and that’s a small market
Yeah, I just think that maybe, just maybe, if MacOS is also inspired by UNIX, making a compat layer is not that big of a difference. Because MacOS supports a lot of productivity programs that may attract professionals to Linux too. Mostly adobe suite.
The problem with that thought is the lower level bits are very *nix but all the higher level bits like the GUI and other surrounding APIs are all heavily Objective-C/NextStep based and aren’t really all that unixy. We do have GNUStep as a base to use for that to an extent but I really don’t think the unix parts of Mac, are that helpful to porting complex user facing GUI programs.
pretty scant on details. what is this doing for me that Podman or Containerd aren’t? “oPtIMizeD fOR aPPlE SiLICon” is fluff
Well it helps that its open source & apple is actually encouraging contributions: https://github.com/apple/container
Using the open source Containerization package, it runs a lightweight VM for each container that you create.
A big improvement over the stupid shit Docker Desktop did (running a bigass ugly VM for all containers). I’ll still stick with my Linux laptop ;)
I believe Podman uses a Fedora CoreOS VM. How does that compare?
I’m not sure. To me, the most interesting thing is that each container gets its own VM. I don’t know if podman does that or not. I’d guess not, since CoreOS isn’t the lightest OS around (I’ve used CoreOS and Flatcar extensively at my job and it’s a lil chunky as far as immutable container host OSes go).
What would be the use case for each container getting its own VM?
Each VM can be sized appropriately for the demands of the container. With docker desktop, you can’t have a container use all of your system cores without making the VM have access to all of your cores all the time always. One of the biggest benefits (imo) of running containers on a Linux workstation is that if you don’t define a CPI limit, a container can use all the compute/memory on your system. You just can’t do that with Docker desktop. This also affects multi threaded container builds when you’re using buildkit.
Being able to spin up a vm to build a container with all cores accessible to it, and then run the actual container with a smaller number of cores would make container builds so much faster.
EDIT: I’ve looked, and it appears that podman desktop also does 1 big VM, rather than having 1 VM per container.
I was wondering the same
@TheTwelveYearOld wow such amazing technology
who would have thought it was possible
🙄
