4 ms·

With the "never break userspace" guarantee, is there ever a reason to want to be on an LTS kernel instead of the latest stable one, other than proprietary kerne

With the "never break userspace" guarantee, is there ever a reason to want to be on an LTS kernel instead of the latest stable one, other than proprietary kernel modules?

craftkiller 3y ago
Yes, ZFS. When new, incompatible kernels are released the dkms build for the ZFS kernel modules will fail. By switching to an LTS kernel, I no longer have to worry because my kernel lags so far behind. 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.
- XorNot 3y ago
  As a ZFS user, this really isn't a good enough reason IMO. Never break userspace really should be enough for most people.
- phone8675309 3y ago
  This wouldn't be a problem if OpenZFS didn't have a dogshit license.
  - craftkiller 3y ago
    The same could be said for Linux. This isn't a problem on FreeBSD.
    - josephcsible 3y ago
      > The same could be said for Linux. No, because the CDDL was intentionally written to be incompatible with the GPL.
      - craftkiller 3y ago
        The original intent of the license authors is irrelevant. 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.
        ghaff 3y ago
        And different people remember or choose to interpret the original intent differently.
        xorcist 3y ago
        If Linux had been under the CDDL, ZFS would have chosen another license. Sun management at the time saw Linux as their primary competitor, and ZFS and DTrace was the crown jewels of Solaris. Just open sourcing was reported to have been a long internal struggle by the people involved, and there's no chance they would have let the Linux distributors use them for free. 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.
        pabs3 3y ago
        That aspect of the GPL is what any software end-user should want, all the source code, for every part of what you are using. 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.
        bananapub 3y ago
        > The original intent of the license authors is irrelevant. 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
- kaylynb 3y ago
  Sometimes breaking changes for ZFS are backported to LTS anyway.
  - craftkiller 3y ago
    Oh :-\ Thanks for the warning, I guess I'll have to remain vigilant. Switching to LTS certainly significantly reduces the frequency of incompatibilities, so I'm definitely going to remain on it, but I guess its not the perfect fix I thought it was.
- raverbashing 3y ago
  As opposed to what ZFS users think, very few people care about it And in mobile, I'd say the amount goes to zero
Jhsto 3y ago
GPU applications are often less buggy on LTS (kernel, but also package sets)
- josephcsible 3y ago
  Isn't the reason for kernel-related bugginess in GPU applications usually the out-of-tree proprietary GPU driver kernel module?
  - baq 3y ago
    GPU drivers are routinely the biggest chunk of the kernel (both source and runtime) and have the most surface area to have bugs in them regardless of their openness.
- sambazi 3y ago
  came to say the same. i absolutely despise breakage and random changes in my desktop environment
o11c 3y ago
Some kind of breakage is pretty common in random recent kernels. It might not affect you this time, but do you really want to risk it? 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.
- josephcsible 3y ago
  > do you really want to risk it? 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?
  - sambazi 3y ago
    so you want to trade in tailored and curated fixes in lts for acccidental and experimental fixes in bleeding-edge. go ahead
    - josephcsible 3y ago
      My work uses "tailored and curated fixes in lts" and at home I use "acccidental and experimental fixes in bleeding-edge". I've had way more stuff break because of the former than because of the latter, and not just with the kernel.
xorcist 3y ago
Lots of third party software hooks the kernel for various things, such as drivers for enterprise RAID or proprietary networking, and whatever it is Nvidia does these days. Those go far beyond the user space interface and are dependent on binaries staying unchanged. This is for them. 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.

With the "never break userspace" guarantee, is there ever a reason to want to be on an LTS kernel instead of the latest stable one, other than proprietary kernel modules?

craftkiller 3y ago

Yes, ZFS. When new, incompatible kernels are released the dkms build for the ZFS kernel modules will fail. By switching to an LTS kernel, I no longer have to worry because my kernel lags so far behind. 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.

XorNot 3y ago
As a ZFS user, this really isn't a good enough reason IMO. Never break userspace really should be enough for most people.
phone8675309 3y ago
This wouldn't be a problem if OpenZFS didn't have a dogshit license.
- craftkiller 3y ago
  The same could be said for Linux. This isn't a problem on FreeBSD.
  - josephcsible 3y ago
    > The same could be said for Linux. No, because the CDDL was intentionally written to be incompatible with the GPL.
    - craftkiller 3y ago
      The original intent of the license authors is irrelevant. 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.
      - ghaff 3y ago
        And different people remember or choose to interpret the original intent differently.
      - xorcist 3y ago
        If Linux had been under the CDDL, ZFS would have chosen another license. Sun management at the time saw Linux as their primary competitor, and ZFS and DTrace was the crown jewels of Solaris. Just open sourcing was reported to have been a long internal struggle by the people involved, and there's no chance they would have let the Linux distributors use them for free. 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.
      - pabs3 3y ago
        That aspect of the GPL is what any software end-user should want, all the source code, for every part of what you are using. 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.
      - bananapub 3y ago
        > The original intent of the license authors is irrelevant. 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
kaylynb 3y ago
Sometimes breaking changes for ZFS are backported to LTS anyway.
- craftkiller 3y ago
  Oh :-\ Thanks for the warning, I guess I'll have to remain vigilant. Switching to LTS certainly significantly reduces the frequency of incompatibilities, so I'm definitely going to remain on it, but I guess its not the perfect fix I thought it was.
raverbashing 3y ago
As opposed to what ZFS users think, very few people care about it And in mobile, I'd say the amount goes to zero

Jhsto 3y ago

GPU applications are often less buggy on LTS (kernel, but also package sets)

josephcsible 3y ago
Isn't the reason for kernel-related bugginess in GPU applications usually the out-of-tree proprietary GPU driver kernel module?
- baq 3y ago
  GPU drivers are routinely the biggest chunk of the kernel (both source and runtime) and have the most surface area to have bugs in them regardless of their openness.
sambazi 3y ago
came to say the same. i absolutely despise breakage and random changes in my desktop environment

o11c 3y ago

Some kind of breakage is pretty common in random recent kernels. It might not affect you this time, but do you really want to risk it? 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.

josephcsible 3y ago
> do you really want to risk it? 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?
- sambazi 3y ago
  so you want to trade in tailored and curated fixes in lts for acccidental and experimental fixes in bleeding-edge. go ahead
  - josephcsible 3y ago
    My work uses "tailored and curated fixes in lts" and at home I use "acccidental and experimental fixes in bleeding-edge". I've had way more stuff break because of the former than because of the latter, and not just with the kernel.

xorcist 3y ago

Lots of third party software hooks the kernel for various things, such as drivers for enterprise RAID or proprietary networking, and whatever it is Nvidia does these days. Those go far beyond the user space interface and are dependent on binaries staying unchanged. This is for them. 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.