Canonical Releases LXD 5.17 With OpenZFS 2.2 Delegation Support

[Developer12]

I'm in the middle of converting my 4 home server disks, containing almost 12 TB of data, from ext4 to zfs. The sole reason is because I'm tired of getting hit by bit rot. I'm only using single disk zfs as I have both local and cloud backups, but now I'll finally be able to tell when a file is corrupted. Of course I also formatted my 2 local backup disks with zfs to protect them as well.

My only concern is that Linus has this nonsensical prejudice against OpenZFS and simply will not allow it to be included in the kernel, apparently because Oracle has its own zfs with a restrictive license. But it goes beyond even that, as Linus uses a combination of complaints about licensing, and the insane assertion that OpenZFS is unsupported and could disappear any day. When the truth is that OpenZFS uses the CDDL license which allows distributing it as a binary module or source code, and OpenZFS is supported incredibly well and used in many enterprise and data center environments.

For example, my home server runs Manjaro which distributes OpenZFS binary modules in its official repositories and keeps kernels and zfs in sync. However Arch, which I use for my main desktop workstation, distributes it as source code, with a dkms option that usually assures kernel version compatibility. But compatibility with various Arch kernels cannot be assured, so the lts kernel must always be installed as a backup option. However I always keep the lts kernel installed on any distro I use anyway, so it's not a problem.

But things would be so much easier if Linus would simply stop with his irrational rejection of OpenZFS so it could be included in the kernel and become effortlessly compatible across all Linux distros just like ext4, btrfs, etc.

There is indeed a prejudice among linux developers, against ZFS and every other out-of-tree module alike.

It has absolutely nothing to do with Linus' refusal to merge ZFS into the kernel. It's impossible to do that. That's not a prejudice, it's a legal fact.

The two projects' licences are very widely agreed to be legally incompatible for a multitude of reasons. Nobody on earth disputes this. Not in the Linux camp, not in the ZFS camp, not even canonical. Canonical's shipping of ZFS hinges on there being nothing in either licence preventing shipping ZFS as an out of tree module, just like the closed source nvidia module or countless other proprietary modules.

The only sad part is that the kernel community don't distinguish beyond whether something is in-tree and GPL, or everything else.

ZFS is open source, yes.
ZFS is copyleft, yes.
ZFS would make a great addition to linux, yes.

But non of that matters. In the kernel devs' minds it's no different whether ZFS is copyleft or fully proprietary, whether open source or closed source, or whether anyone working on would or wouldn't like to upstream it. It isn't in-kernel and never will be in-kernel, and so they will continue to treat it as the enemy.

[CommunityMember]

The only one who can really fix that is Oracle changing the ZFS license to something GPL compatible.

Or the Linux kernel could change it's license. That is unlikely, but, as they say, it takes two to tango, and if either chooses not to partner up, there is no dance. There is no blame/wrong here, it is just different, and valid, points of view. To claim that Oracle is the only one able to fix this is simply wrong.

[kylew77]

I'm in the middle of converting my 4 home server disks, containing almost 12 TB of data, from ext4 to zfs. The sole reason is because I'm tired of getting hit by bit rot. I'm only using single disk zfs as I have both local and cloud backups, but now I'll finally be able to tell when a file is corrupted. Of course I also formatted my 2 local backup disks with zfs to protect them as well.

My only concern is that Linus has this nonsensical prejudice against OpenZFS and simply will not allow it to be included in the kernel, apparently because Oracle has its own zfs with a restrictive license. But it goes beyond even that, as Linus uses a combination of complaints about licensing, and the insane assertion that OpenZFS is unsupported and could disappear any day. When the truth is that OpenZFS uses the CDDL license which allows distributing it as a binary module or source code, and OpenZFS is supported incredibly well and used in many enterprise and data center environments.

For example, my home server runs Manjaro which distributes OpenZFS binary modules in its official repositories and keeps kernels and zfs in sync. However Arch, which I use for my main desktop workstation, distributes it as source code, with a dkms option that usually assures kernel version compatibility. But compatibility with various Arch kernels cannot be assured, so the lts kernel must always be installed as a backup option. However I always keep the lts kernel installed on any distro I use anyway, so it's not a problem.

But things would be so much easier if Linus would simply stop with his irrational rejection of OpenZFS so it could be included in the kernel and become effortlessly compatible across all Linux distros just like ext4, btrfs, etc.

Just run FreeBSD, or Illumos distros like OpenIndiana or Triblix, or heck even NetBSD has support for ZFS. Why run ZFS on something where it is not a first class citizen?

[fallingcats]

Or the Linux kernel could change it's license. That is unlikely, but, as they say, it takes two to tango, and if either chooses not to partner up, there is no dance. There is no blame/wrong here, it is just different, and valid, points of view. To claim that Oracle is the only one able to fix this is simply wrong.

My understanding is that Oracle could change the license single-handedly, but since the linux kernel does not have a CLA it would take every single contributer over the last 30 years to agree to re-license their code.

[chocolate]

Canonical considerations aside, does anybody have experience using LXD for the same usecases Distrobox currently gets recommended everywhere (e.g. clean, ad hoc programming environments)? Would you recommend LXD? Why?

[skeevy420]

Or the Linux kernel could change it's license. That is unlikely, but, as they say, it takes two to tango, and if either chooses not to partner up, there is no dance. There is no blame/wrong here, it is just different, and valid, points of view. To claim that Oracle is the only one able to fix this is simply wrong.

FWIW, I immediately said afterwards that both GNU and the Linux Foundation could also change the situation from their ends but that either of them doing it would be even less likely than Oracle.

[Jakobson]

Or the Linux kernel could change it's license. That is unlikely, but, as they say, it takes two to tango, and if either chooses not to partner up, there is no dance. There is no blame/wrong here, it is just different, and valid, points of view. To claim that Oracle is the only one able to fix this is simply wrong.

Sure. However, obtaining explicit permission from all past kernel developers is essential. This includes individuals who have passed away and any inheritances they might have. In practice, this is an entirely unfeasible task.

[paulocoghi]

Canonical considerations aside, does anybody have experience using LXD for the same usecases Distrobox currently gets recommended everywhere (e.g. clean, ad hoc programming environments)? Would you recommend LXD? Why?

Since distrobox is based on docker, I would recommend LXD instead because its based on LXC and the container environment it provides is, by design, a complete OS environment. It's natural choice.

Docker, on the other hand, provides containers made to run a single service on each of them and, IMHO, it seems like a workaround/kludge to make them running multiple services inside again.

[skierpage]

reined*

Correct, King Chuck 3 reiGns. But the original remains unidiomatic

[LXD]has been reigned into control by Canonical and maintainership being limited to Canonical engineers.

You take the reins of a horse to rein it in, so "into control" is redundant. Better "[LXD] has been reined in by Canonical, which limited maintainership to Canonical engineers."

[jaypatelani]

Why work on OpenZFS while there's aleady FreeBSD. Why waste more resources on OpenZFS? 😛