I really don't know about the implementation of containers at all. But any time I heard containers being explained especially when compared to VMs, the kernel sharing was the biggest part of what a container was. I didn't even know there was a formal definition 😂
Two quick things about “Mac OS X”: 1. It's pronounced Mac OS *ten*. 2. The last version of Mac OS X was Lion, which came out over 12 years ago. After that, it was OS X, and since Sierra (over four years ago), it's macOS. So, you don't even need to remember how to pronounce the ‘X’ any more, since there isn't any ;) P.S. (OK, it's three quick things I guess): IMO it's totally fine to spell it ”MacOS”. However, definitely don't ever call it ”Mac OS” - that's an entirely different system! And ”MacOs” is just silly.
Good question. I'm not familiar with UTM to be honest. But yes, a downside of this approach is that you don't have the features and restrictions control groups and namespaces bring.
Maybe... But if you mean namespaces in the syscall sense, that that excludes windows containers though. And if you mean conceptual namespaces, where you just can't see what's running in another namespace then doesn't that make a VM a container, because the workloads are namespaced? Or is the shared kernel an important part of it? Which needs to be supported using the capabilities of the kernel in question?
@@EarthlyTech I agree with you that people are getting far too hung up on the details of the definition, it doesn't matter if there is a VM involved or not. I think it would be fair though to say that "container" means isolation of filesystem, IPC and networking. If an implementation can run two environments at the same time that can listen on the same TCP ports and talk to processes using pipes, without having to know to avoid other instances or the host, than that is a "container". So for now at least, a chroot is only ever going to be a "filesystem container" since chroots will all share the same networking and PID space. FWIW, I have myself used your exact same chroot technique to produced a "docker-like" tool for Solaris, HPUX and AIX for my work. Being able to "docker pull" AIX images is great , but I don't get full isolation and can still destroy the host OS
I really don't know about the implementation of containers at all. But any time I heard containers being explained especially when compared to VMs, the kernel sharing was the biggest part of what a container was. I didn't even know there was a formal definition 😂
Thanks for coming to my rant :)
Two quick things about “Mac OS X”: 1. It's pronounced Mac OS *ten*.
2. The last version of Mac OS X was Lion, which came out over 12 years ago. After that, it was OS X, and since Sierra (over four years ago), it's macOS. So, you don't even need to remember how to pronounce the ‘X’ any more, since there isn't any ;)
P.S. (OK, it's three quick things I guess): IMO it's totally fine to spell it ”MacOS”. However, definitely don't ever call it ”Mac OS” - that's an entirely different system! And ”MacOs” is just silly.
I knew me saying X was going to come up! That was a mistake and you are totally right! I'll stick to macOS from now on.
Super cool! Just what I need for a thing I'm tinkering with.
Pretty cool project. Would it make sense to run these containers inside a VM (like UTM) so we can mimic control groups/namespaces?
Good question. I'm not familiar with UTM to be honest. But yes, a downside of this approach is that you don't have the features and restrictions control groups and namespaces bring.
Great news, hopefully I can use Podman natively on macOS soon
Best of luck!
chroot isn't a container, it's just changing the perceived root of a filesystem, the #1 main thing with containerisation is namespaced workloads.
Maybe...
But if you mean namespaces in the syscall sense, that that excludes windows containers though. And if you mean conceptual namespaces, where you just can't see what's running in another namespace then doesn't that make a VM a container, because the workloads are namespaced?
Or is the shared kernel an important part of it? Which needs to be supported using the capabilities of the kernel in question?
@@EarthlyTech I agree with you that people are getting far too hung up on the details of the definition, it doesn't matter if there is a VM involved or not. I think it would be fair though to say that "container" means isolation of filesystem, IPC and networking. If an implementation can run two environments at the same time that can listen on the same TCP ports and talk to processes using pipes, without having to know to avoid other instances or the host, than that is a "container". So for now at least, a chroot is only ever going to be a "filesystem container" since chroots will all share the same networking and PID space.
FWIW, I have myself used your exact same chroot technique to produced a "docker-like" tool for Solaris, HPUX and AIX for my work. Being able to "docker pull" AIX images is great , but I don't get full isolation and can still destroy the host OS