5 ms·

A stable binary device-driver API has always been resisted in Linux. I suppose that's what Treble is?

deleted 9y ago
[deleted]
kuschku 9y ago
Not exactly. Treble is a stable API between userland and kernel. Userland can be quickly updated even if the drivers are not, and if the drivers are updated, userland can stay the same. The long term plan smells of Magenta. Sadly, we have nothing like this, or a stable driver API on desktop linux at the moment, which is <insert expletives here>.
- cyphar 9y ago
  > Treble is a stable API between userland and kernel. Stock Linux definitely has a stable userland API, though I imagine that third party driver vendors don't know how to do stable userland APIs. > Sadly, we have nothing like this, or a stable driver API on desktop linux at the moment, which is <insert expletives here>. As for driver ABI compatibility, I know that almost all enterprise distributions maintain kABI compatibility for a particular release of their distribution (this is one of the selling points of such distributions). I believe there are also some community distributions with similar stability guarantees (for instance openSUSE Leap uses the same kernel as SUSE Linux Enterprise, so I would assume the same guarantee is provided).
  - barrkel 9y ago
    "stable userland API" Try copying some Linux binaries between a few distros, a few release years apart and tell me again about stability. Try the same with some Windows apps and compare and contrast. API == ABI for stability purposes, and the kernel isn't the problem, otherwise things like docker wouldn't meaningfully work at all. It's all the auxiliary libraries, much larger surface area.
    - ethelward 9y ago
      The problem you'll have will be with the dynamic libraries, not the kernel. If you stay with statically linked binaries or you package your binary with its .so, everything should work fine.
      - barrkel 9y ago
        If you link everything statically, you must (a) have the right to do so, and (b) you now subsume responsibility for security patches for all your dependencies. These are two very big asks.
        digi_owl 9y ago
        Watch container based "solutions" to both sprout like wildflower...
    - cyphar 9y ago
      > Try copying some Linux binaries between a few distros, a few release years apart and tell me again about stability. The issue is the dynamic libraries (which are handled by distributions in different ways). Try statically compiling a binary like that and you'll find that it will work between distributions and kernel versions. > Try the same with some Windows apps and compare and contrast. Because they include their dynamic libraries with their programs, which has its own tradeoffs (updating security issues in shared libraries is much harder, even if you had a package manager on windows -- which you don't). > It's all the auxiliary libraries, much larger surface area. Right, but GP's point was that Linux doesn't have userland-to-kernel stability and I was saying that's simply not true. It's true that there is no stable upstream driver API but there are also solutions to that problem as well.
      - IshKebab 9y ago
        Have you ever tried to statically link a program on Linux? I'm guessing not. Until recently it was more or less impossible because glibc cannot be statically linked. Nowadays you can do it with musl but it still takes significant extra effort. It's not as simple as "windows programs include their dependencies". Windows has far better forward and backward compatibility than Linux (by which I mean Linux plus the required userland stuff - libc, ld, etc.) That's kind of to be expected. Comparability is tons of extra effort that open source can't really prioritise, but don't just pretend that it is as good as Windows.
  - kuschku 9y ago
    Correct, the issue isn't in Linux itself. It's in drivers, third party kernel modules, libraries, etc. But that doesn't make it any easier. On desktoo GNU/Linux or GNU/NT we don't have easy stable environments, and the fight between dynamic and static linking is always won by static linking. In the GNU world, that ended with snap/flatpack/docker/rkt/containerd
    - digi_owl 9y ago
      Only for those to introduce their own problems, like having some insecure lib sitting in a container somewhere... I really wish userland devs would spend more time actually maintaining API/ABI stability, and less time reinventing wheels because they are not "perfect" (after whatever arbitrary marker for perfection they work with).
      - kuschku 9y ago
        To be honest, Alpine Linux based containers on Kubernetes are so amazingly stable, and "just works", it’s amazing. But yes. One issue anywhere, and I can upgrade everything again.

deleted 9y ago

[deleted]

Not exactly. Treble is a stable API between userland and kernel. Userland can be quickly updated even if the drivers are not, and if the drivers are updated, userland can stay the same. The long term plan smells of Magenta. Sadly, we have nothing like this, or a stable driver API on desktop linux at the moment, which is <insert expletives here>.

cyphar 9y ago
> Treble is a stable API between userland and kernel. Stock Linux definitely has a stable userland API, though I imagine that third party driver vendors don't know how to do stable userland APIs. > Sadly, we have nothing like this, or a stable driver API on desktop linux at the moment, which is <insert expletives here>. As for driver ABI compatibility, I know that almost all enterprise distributions maintain kABI compatibility for a particular release of their distribution (this is one of the selling points of such distributions). I believe there are also some community distributions with similar stability guarantees (for instance openSUSE Leap uses the same kernel as SUSE Linux Enterprise, so I would assume the same guarantee is provided).
- barrkel 9y ago
  "stable userland API" Try copying some Linux binaries between a few distros, a few release years apart and tell me again about stability. Try the same with some Windows apps and compare and contrast. API == ABI for stability purposes, and the kernel isn't the problem, otherwise things like docker wouldn't meaningfully work at all. It's all the auxiliary libraries, much larger surface area.
  - ethelward 9y ago
    The problem you'll have will be with the dynamic libraries, not the kernel. If you stay with statically linked binaries or you package your binary with its .so, everything should work fine.
    - barrkel 9y ago
      If you link everything statically, you must (a) have the right to do so, and (b) you now subsume responsibility for security patches for all your dependencies. These are two very big asks.
      - digi_owl 9y ago
        Watch container based "solutions" to both sprout like wildflower...
  - cyphar 9y ago
    > Try copying some Linux binaries between a few distros, a few release years apart and tell me again about stability. The issue is the dynamic libraries (which are handled by distributions in different ways). Try statically compiling a binary like that and you'll find that it will work between distributions and kernel versions. > Try the same with some Windows apps and compare and contrast. Because they include their dynamic libraries with their programs, which has its own tradeoffs (updating security issues in shared libraries is much harder, even if you had a package manager on windows -- which you don't). > It's all the auxiliary libraries, much larger surface area. Right, but GP's point was that Linux doesn't have userland-to-kernel stability and I was saying that's simply not true. It's true that there is no stable upstream driver API but there are also solutions to that problem as well.
    - IshKebab 9y ago
      Have you ever tried to statically link a program on Linux? I'm guessing not. Until recently it was more or less impossible because glibc cannot be statically linked. Nowadays you can do it with musl but it still takes significant extra effort. It's not as simple as "windows programs include their dependencies". Windows has far better forward and backward compatibility than Linux (by which I mean Linux plus the required userland stuff - libc, ld, etc.) That's kind of to be expected. Comparability is tons of extra effort that open source can't really prioritise, but don't just pretend that it is as good as Windows.
- kuschku 9y ago
  Correct, the issue isn't in Linux itself. It's in drivers, third party kernel modules, libraries, etc. But that doesn't make it any easier. On desktoo GNU/Linux or GNU/NT we don't have easy stable environments, and the fight between dynamic and static linking is always won by static linking. In the GNU world, that ended with snap/flatpack/docker/rkt/containerd
  - digi_owl 9y ago
    Only for those to introduce their own problems, like having some insecure lib sitting in a container somewhere... I really wish userland devs would spend more time actually maintaining API/ABI stability, and less time reinventing wheels because they are not "perfect" (after whatever arbitrary marker for perfection they work with).
    - kuschku 9y ago
      To be honest, Alpine Linux based containers on Kubernetes are so amazingly stable, and "just works", it’s amazing. But yes. One issue anywhere, and I can upgrade everything again.