5 ms·

I think that the people who work on it have goal to run linux in it and that causes the project to be more complex than it should. For example if you use Linux

by takeda 6y ago

I think that the people who work on it have goal to run linux in it and that causes the project to be more complex than it should. For example if you use Linux on ARM you still need to build new containers, because the x86_64 won't work there, so why it should be different with FreeBSD? Yes, it would be great to run the same docker images on FreeBSD, but that should be a later step, and stuff like described in this wiki, could be used to accomplish that.

danieldk 6y ago
For example if you use Linux on ARM you still need to build new containers, because the x86_64 won't work there, Actually, it would with qemu user-mode emulation. This can be done transparently with binfmt_misc, which is a one or two-liner on many distributions. BuildKit now can now also automatically without any additional setup: https://github.com/moby/buildkit/pull/1516 https://github.com/moby/buildkit/pull/1516 But I do understand your point, Linux emulation on FreeBSD may be incomplete/incorrect in places, so you have to address to problems at the same time. Unfortunately, I think this is also what people would expect from Docker support - the ability to pull arbitrary images.
- whizzter 6y ago
  > But I do understand your point, Linux emulation on FreeBSD may be incomplete/incorrect in places, so you have to address to problems at the same time. Unfortunately, I think this is also what people would expect from Docker support - the ability to pull arbitrary images. This is really an important point, MS failed to get WSL1 good enough so WSL2 was just a plain Linux kernel being virtualized. Maybe running a some partially virtualized linux kernel(Linux already has modes for this?) via bhyve relying on a host FreeBSD filesystem (using the already developed layering) might be an feasible approach that requires less Linux API chasing while retaining the "native" FS advantage at the expense of some extra memory (bhyve) ?
  - deleted 6y ago
    [deleted]
- trasz 6y ago
  From what I understand, with qemu-usermode you're still risking incompatibilities, as QEmu needs to be able to handle the syscalls to translate (or 'transmarshal', if that's a word) each of the syscalls.

by takeda 6y ago

danieldk 6y ago

For example if you use Linux on ARM you still need to build new containers, because the x86_64 won't work there, Actually, it would with qemu user-mode emulation. This can be done transparently with binfmt_misc, which is a one or two-liner on many distributions. BuildKit now can now also automatically without any additional setup: https://github.com/moby/buildkit/pull/1516 https://github.com/moby/buildkit/pull/1516 But I do understand your point, Linux emulation on FreeBSD may be incomplete/incorrect in places, so you have to address to problems at the same time. Unfortunately, I think this is also what people would expect from Docker support - the ability to pull arbitrary images.

whizzter 6y ago
> But I do understand your point, Linux emulation on FreeBSD may be incomplete/incorrect in places, so you have to address to problems at the same time. Unfortunately, I think this is also what people would expect from Docker support - the ability to pull arbitrary images. This is really an important point, MS failed to get WSL1 good enough so WSL2 was just a plain Linux kernel being virtualized. Maybe running a some partially virtualized linux kernel(Linux already has modes for this?) via bhyve relying on a host FreeBSD filesystem (using the already developed layering) might be an feasible approach that requires less Linux API chasing while retaining the "native" FS advantage at the expense of some extra memory (bhyve) ?
- deleted 6y ago
  [deleted]
trasz 6y ago
From what I understand, with qemu-usermode you're still risking incompatibilities, as QEmu needs to be able to handle the syscalls to translate (or 'transmarshal', if that's a word) each of the syscalls.