Live data from Hacker News

Ubuntu Linux Jail on FreeBSD 12.2-Release

wiki.freebsd.org

61–70 of 86 posts

Re: Ubuntu Linux Jail on FreeBSD 12.2-Release

#61
post #25

Earlier quoted context omitted.

Every couple of years people express interest but no one has ever done the work. It is very much doable as the original port showed, and the zfs driver already exists for image layering as that works on Linux.

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 w…

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

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.

Re: Ubuntu Linux Jail on FreeBSD 12.2-Release

#62

Earlier quoted context omitted.

systemd-as-SysV-init replacement was fine. It's all the other stuff that many people think is overkill: udevd being pulled in, journald, time sync, file system mounting, network management, etc. And all are in one repo with tight coupling. For an "init system".

People keep saying it's tightly coupled, but never supply any proof for that. You can still run udev without systemd, the NTP stuff is completely optional and in separate binaries and the same is true for the network management stuff. The journal is indeed required, but any traditional syslog daemon still works, and you can trivially disable the persistent journal (I even believe that's the default on Debian).

> you can trivially disable the persistent journal (I even believe that's the default on Debian)

The persistent journal is enabled by default in Debian testing.

Re: Ubuntu Linux Jail on FreeBSD 12.2-Release

#63
post #52

Earlier quoted context omitted.

People keep saying it's tightly coupled, but never supply any proof for that. You can still run udev without systemd, the NTP stuff is completely optional and in separate binaries and the same is true for the network management stuff. The journal is indeed required, but any traditional syslog daemon still works, and you can trivially disable the persistent journal (I even believe that's the default on Debian).

Suppose I want to write my own competitor to systemd-resolvd. I want it to work with systemd-networkd, in the same way as systemd-resolvd does. Or just patch dnsmasq or unbound to be able to do that. Is there a stable interface for that? An RFC I can read? Any guarantee they won't change the interface and break my version, while they update both of theirs together?

> Any guarantee they won't change the interface and break my version, while they update both of theirs together?

No, I think you can guarantee that the interface will change at some point.

Re: Ubuntu Linux Jail on FreeBSD 12.2-Release

#64
post #25

Earlier quoted context omitted.

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 w…

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 But I do understand your point, Linux emulat…

> 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) ?

Re: Ubuntu Linux Jail on FreeBSD 12.2-Release

#65

Earlier quoted context omitted.

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 But I do understand your point, Linux emulat…

> 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…

[deleted]

Re: Ubuntu Linux Jail on FreeBSD 12.2-Release

#66
post #25

Earlier quoted context omitted.

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 w…

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 But I do understand your point, Linux emulat…

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.

Re: Ubuntu Linux Jail on FreeBSD 12.2-Release

#67
post #6

I wish there was a usable Docker Engine API implementation that could run containers in jails using zfs for image layering. There is a Docker for FreeBSD port, but last time I checked, it was super old. Having Docker as a first class citizen on FreeBSD would make it really incredibly as a server OS.

Every couple of years people express interest but no one has ever done the work. It is very much doable as the original port showed, and the zfs driver already exists for image layering as that works on Linux.

There has been some work done: https://reviews.freebsd.org/D21570. It appears stalled, though.

Re: Ubuntu Linux Jail on FreeBSD 12.2-Release

#68
post #49

Earlier quoted context omitted.

> facing many of the same difficulties that prompted the Windows team to just run Linux in a hypervisor How's that? WSL had serious performance issues due to design differences between linux and NT. Linux and freebsd both being unices, there is no such impedance. Some features (like cgroups) remain unimplemented, true, but there haven't been any big difficulties afaik.

Sure, "BSL" doesn't have all the same difficulties as Windows WSL1 had. There are still design mismatches between FreeBSD and Linux that make implementing Linux features difficult (just for example, compare Linux clone() to FreeBSD fork()), and there are many, many features that remain unimplemented (inotify, cgroups, namespaces, ...). I agree it's largely "just" a matter of implementing the missing functionality, wh…

I'd say it doesn't have ~90% of the difficulties WSL1 had. From what I remember WSL1 had problems with even most basic functionality, like the filesystem semantics, and never got to support eg DRI for X11.

Regarding clone() - it's rfork(2) you want to compare to, not fork(2). Not the same, sure, but much closer.

(Disclaimer: I'm one of the people working on it, so I'm obviously biased.)

Re: Ubuntu Linux Jail on FreeBSD 12.2-Release

#69

Earlier quoted context omitted.

FreeBSD's point of distinction is that it's carefully designed and fitted together, compared to Linux's comparatively heavy use of glue. I also haven't heard credible reports of it being slow, except for things it's not really used for (like drivers for consumer wifi cards).

That’s what systemd is giving the Linux world, though. A carefully designed system for a lot of very essential things, so that distros will need to apply less glue.

>carefully designed system

Ehm...really? Are you making fun of us?

Re: Ubuntu Linux Jail on FreeBSD 12.2-Release

#70

Earlier quoted context omitted.

systemd-as-SysV-init replacement was fine. It's all the other stuff that many people think is overkill: udevd being pulled in, journald, time sync, file system mounting, network management, etc. And all are in one repo with tight coupling. For an "init system".

But systemd was never just an init system. AFAIK, systemd has always been advertised as a system and service manager for Linux. With that in mind it makes perfect sense that systemd manages what it does. Whether or not such an architecture is desirable is debatable, but the portrayal of systemd as just an init system is a fundamental misunderstanding of what systemd is.

> With that in mind it makes perfect sense that systemd manages what it does.

It made perfect sense to pull in udevd, which had existed externally for a long time, and tightly couple it so that it can no longer be used independently? (The Gentoo folks forked eudevd.)

Post reply on HN