3 ms·

> 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

by cyphar 10y 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 10y 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 10y 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 10y 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 10y ago
      Watch container based "solutions" to both sprout like wildflower...
- cyphar 10y 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 10y 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.
    - majewsky 10y ago
      glibc-static works fine for my Golang programs that are being compiled on RHEL hosts in the CI and then shipped as Alpine-derived containers (which is why I need to link libc statically; ain't no glibc on Alpine).
    - cyphar 10y ago
      > Have you ever tried to statically link a program on Linux? I'm guessing not. This is where autotools helps: ./configure --static. There are also equivalents for CMake. Aside from that I also statically compile Golang programs all the time (specifically runc which is a container runtime that uses cgo and a bunch of other magic). If static compilation didn't work, neither would our releases. Just because Rust only lets you statically link binaries if you use musl doesn't mean that nobody else knows how to link things statically. > because glibc cannot be statically linked This is patently false. It is true that glibc will make static linking _hard_ but it's definitely not impossible. You need to set some magic settings (that autotools does for you) which disables all of the dynamic loading stuff glibc does. > It's not as simple as "windows programs include their dependencies". But it is. If you ignore the core system libraries, and included all of the other library dependencies with programs, most of these problems would be fixed. > Windows has far better forward and backward compatibility than Linux glibc has symbol versioning so in principle (I have had to use this once or twice) you can use an older program (linked against an old glibc) on a newer glibc.
kuschku 10y 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 10y 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 10y 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.

by cyphar 10y ago

barrkel 10y 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 10y 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 10y 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 10y ago
    Watch container based "solutions" to both sprout like wildflower...
cyphar 10y 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 10y 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.
  - majewsky 10y ago
    glibc-static works fine for my Golang programs that are being compiled on RHEL hosts in the CI and then shipped as Alpine-derived containers (which is why I need to link libc statically; ain't no glibc on Alpine).
  - cyphar 10y ago
    > Have you ever tried to statically link a program on Linux? I'm guessing not. This is where autotools helps: ./configure --static. There are also equivalents for CMake. Aside from that I also statically compile Golang programs all the time (specifically runc which is a container runtime that uses cgo and a bunch of other magic). If static compilation didn't work, neither would our releases. Just because Rust only lets you statically link binaries if you use musl doesn't mean that nobody else knows how to link things statically. > because glibc cannot be statically linked This is patently false. It is true that glibc will make static linking _hard_ but it's definitely not impossible. You need to set some magic settings (that autotools does for you) which disables all of the dynamic loading stuff glibc does. > It's not as simple as "windows programs include their dependencies". But it is. If you ignore the core system libraries, and included all of the other library dependencies with programs, most of these problems would be fixed. > Windows has far better forward and backward compatibility than Linux glibc has symbol versioning so in principle (I have had to use this once or twice) you can use an older program (linked against an old glibc) on a newer glibc.

kuschku 10y 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 10y 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 10y 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.