Earlier quoted context omitted.
https://github.com/apple/container/blob/main/docs/technical-... read documentation mr. rare breed
Like, this doesn’t answer when to use this vs Docker. Any reference there?
[flagged]
macOS Container Machines
411–420 of 457 posts
Re: macOS Container Machines
#412Re: macOS Container Machines
#413I 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 doe…
I built this tool to solve that exact problem: https://github.com/smol-machines/smolvm
smolvm's are awesome
Re: macOS Container Machines
#414Earlier quoted context omitted.
>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 aski…
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?
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.
Re: macOS Container Machines
#415Earlier quoted context omitted.
> 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 c…
Sounds like a lot of the same choices/compromises that are in wsl2.
Yes, this looks similar to wslc announced at Microsoft Build. They should have joined forces, Apple and Microsoft. Can you imagine?
Re: macOS Container Machines
#416Would be nice if they also support Intel based macs, what prevents?
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.
Re: macOS Container Machines
#417Earlier quoted context omitted.
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"…
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.
Guix is also an option.
Re: macOS Container Machines
#418Earlier quoted context omitted.
MacOS container filesystem/IO has been bog slow preventing even some basic dev container use cases. Hopefully this will fix the issue.
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.
sshfs?
Re: macOS Container Machines
#419Earlier quoted context omitted.
Sounds like a lot of the same choices/compromises that are in wsl2.
Yes, this looks similar to wslc announced at Microsoft Build. They should have joined forces, Apple and Microsoft. Can you imagine?
You mean like for the first 20 years or so of Apple and Microsoft's history?
Re: macOS Container Machines
#420Earlier quoted context omitted.
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.…
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 Sol…
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.