The alternative is using a pre-built package repo which will prevent the kernel from updating to an incompatible version using the package dependencies. I lived that way for years and it is an awful experience.
No, because the CDDL was intentionally written to be incompatible with the GPL.
Good or bad, it's the result of another era. Still impressive stuff. It's only recently that things like btrfs and eBPF became usable enough, and not in all situations.
what on earth is that supposed to mean? ZFS is not in the Linux kernel because Sun and then Oracle deliberately decided to do that and continue to want that to be the case. The Linux kernel can't be re-licensed, (the Oracle and Sun code in) ZFS could be relicenced in ten minutes if they cared.
> The aspect of the CDDL that makes it incompatible with GPL is present in the GPL too. Neither license is more or less "dogshit" than the other, they are the same. The difference is the CDDL only applies to code written under the CDDL, whereas the GPL spreads to everything it touches.
lol
It means that the original authors could have originally intended to write a recipe for chocolate chip cookies and somehow accidentally wrote the CDDL. That wouldn't change a thing and it wouldn't make the CDDL any better or worse since it would have exactly the same words. The intent is irrelevant, all that matters is the end result.
> ZFS could be relicenced in ten minutes if they cared.
Indeed, I hope that they do. A copyfree license like the BSD licenses would make ZFS significantly more popular and I think would have saved all the effort sunk into btrfs had it been done earlier.
It is a shame Oracle hasn't released a CDDLv2 that provides GPL compatibility, they could solve the incompatibility quite easily, since CDDLv1 has an auto-update clause by default. I think some of OpenZFS has CDDLv1-only code, but that could probably be removed or replaced.
And in mobile, I'd say the amount goes to zero
So yes - you do want to be on an LTS kernel. But you only need to stay there for about a year until the next one is released and you can test it for a bit before deploying.
That question applies to LTS kernels too. Do you really want to risk that a backport of an important fix won't introduce a problem that mainline didn't have? Do you really want to risk that there are no security vulnerabilities in old kernels that won't get noticed by maintainers since they were incidentally fixed by some non-security-related change in mainline?
go ahead
If you are running user space applications only on upstream supported hardware, there is no reason to stay with long time supported kernels, just follow the regular stable which is much easier for everyone.
i absolutely despise breakage and random changes in my desktop environment