4 ms·
I think the point would be not to use linux containers or any abstraction around the parts that fuel LXC, but to use BSD Jails on the idea that they are "battle
by yebyen 12y ago
I think the point would be not to use linux containers or any abstraction around the parts that fuel LXC, but to use BSD Jails on the idea that they are "battle tested"
Just as you might not trust Docker's native driver more than LXC, if you most cynically regarded LXC as an "example of a failed marketing experiment" and then Docker as "the first notable consumer of cgroups and linux kernel namespacing, and certainly too new yet to trust with anything important" -- but there are plenty of high-profile consumers of the FreeBSD jails and it is trusted by many to keep processes separate.
I mentioned emulation and binary compatibility, maybe because it's the thing that's missing in many other cases that wind up being responsible for alternative platform support getting back-burnered and second-classed in Docker community.
Where there might be lots of people who want to use Docker on i386, it's not supported probably most of all because it would lead to a bad user experience and fragmentation. Binary images are all built for amd64 linux at this point.
I bypassed the warnings, I use it, I'm not bothered that I have to rebuild for my specific architecture. The docker users at large can still use my images, and maybe I'm a bad citizen for pushing images compiled this way, but it works.
Similarly there are probably a lot of people testing Docker on ARM, but they can't use any of the pre-built containers that are provided by the majority docker community, tested and supported. Their architecture is even farther out from being supported. They have the drawback that they can neither receive blood from "O" nor give to "AB" if you'll indulge the analogy of images to blood types, they have one of those weird blood types that doesn't even register in the statistics with a reasonably sized sample. Anemic, maybe.
If you had a jails execution driver, you certainly don't have to use Linux processes or binary emulation, you can build your containers with a BSD base and BSD toolchain. The point is that in theory, you probably could skip that step and get working with existing binary images built from Linux distributions.
It would quickly be a better "alternative platform" than any of the other existing contenders (different architectures) who you could already see in the docker ecosystem at this point; it could probably run many existing container images out of the box, on a FreeBSD host with amd64 architecture.
The contained software really shouldn't care what execution driver keeps it isolated, at least in theory. In practice someone with more knowledge than me can probably say what a bad idea this is, maybe because either "congrats, you just invented Virtualization" or "wrong, jails won't keep those processes separated."
- justincormack 12y agoIsn't the FreeBSD Linux emulation still 32 bit only? I can't find any reference saying that changed. In which case it there isn't any way compat would work. I think docker will give in and support multiple repositories at some point, as all these osx people are going to want native stuff, and the arm (and arm64) people will want something, and IBM will have a big docker on Power8 push and so on... Linux amd64 will do doubt be the biggest platform. (someone should look at porting the netbsd amd64 linux emulation to freebsd...)