7 ms·

Over here in Linux world we're all super thankful that the kernel community is big on interface stability and compatibility (and not just backwards), because pr

by alxlaz 7y ago

Over here in Linux world we're all super thankful that the kernel community is big on interface stability and compatibility (and not just backwards), because pretty much nobody else is. Lots of folks don't realize how important that is. If the Linux kernel space were to break as often as the Linux desktop, Linux' market share on the server and in the embedded space would likely barely exceed that of TempleOS.

dooglius 7y ago
The difference really doesn't have to do with backward compatibility (which Windows does to arguably an even greater extent than Linux) but with where the stable interface boundary is. Windows puts the boundary in ntdll, Linux puts it at syscalls.
- gmueckl 7y ago
  Well, the stable kernel interface matters on Linux because the user space doesn't give a damn about backwards compatibility. You might be fine if you only rely on the system libc. But every other library that you don't ship with your binary is essentially out to break your stuff. These libraries may even differ between distributions even though they have the same version numbers just because they were built using different build configurations. This is why things like the Steam Runtime exist.
  - dooglius 7y ago
    That has nothing to do with kernel space vs user space and everything to do with different projects having different attitudes. The comparison is to the case where Linux instead ships a special "linuxso.so" that all processes and libraries need to (dynamically) link against in order to get a stable interface.
    - gmueckl 7y ago
      That attitude that is so prevalent in Linux user space is what this thread was getting at. This is why the syscall interface being maintained as a stable interface is so important on Linux compared to other operaring systems.
  - account42 7y ago
    > But every other library that you don't ship with your binary is essentially out to break your stuff. There are many more lower level libraries that provide binary backwards compatibility: libasound, libX11, libGL, ... Sure you're not going to be able to assume that /usr/lib/libpng.so.1 will provide the functionality that you want but that isn't any different from png1.dll some program installed in system32.
    - gmueckl 7y ago
      It's funny that you mention libpng. That is one of those libraries that is developed so conservatively that I'd actually trust it to provide the features a binary that I ship relies on. I rarely (if ever) needed the more obscure things like 16 bit per channels or ICC profiles.
fortran77 7y ago
But Windows has excellent back-compatibility!
quotemstr 7y ago
Backward compatibly is important. It's a weird Linuxism to assert that it's the kernel that has to provide the compatibility interface. There's no reason the ring zero transition has to be the stable part. The real reason Linux's ABI boundary is the kernel is just that the kernel and glibc are sperate and frequently-antagonistic projects. Linux ships the org chart.
- caf 7y ago
  Even if they were the same project it wouldn't matter, because the promise is that your completely statically-linked binary will continue to work without recompilation on tomorrow's kernel if it works on today's.
  - quotemstr 7y ago
    Huh? What you should care about is whether your program can run on future systems. Whether you call your program static or not is irrelevant.
    - caf 7y ago
      It's relevant because if your program is statically linked then it doesn't matter whether or not future changes at the kernel boundary are made backwards-compatible by compensating changes in libc (as is possible if you release them together), because your statically-linked binary can't pick up those libc changes.
      - masklinn 7y ago
        So it's relevant because it avoids breaking your stupidity? The entire objection is that it's a self-inflicted wound, if you don't statically link everything it's not an issue. And non-linux systems will just forbid statically linking libc (e.g. can't statically link libc / libSystem on OSX).
        caf 7y ago

by alxlaz 7y ago

dooglius 7y ago

The difference really doesn't have to do with backward compatibility (which Windows does to arguably an even greater extent than Linux) but with where the stable interface boundary is. Windows puts the boundary in ntdll, Linux puts it at syscalls.

gmueckl 7y ago
Well, the stable kernel interface matters on Linux because the user space doesn't give a damn about backwards compatibility. You might be fine if you only rely on the system libc. But every other library that you don't ship with your binary is essentially out to break your stuff. These libraries may even differ between distributions even though they have the same version numbers just because they were built using different build configurations. This is why things like the Steam Runtime exist.
- dooglius 7y ago
  That has nothing to do with kernel space vs user space and everything to do with different projects having different attitudes. The comparison is to the case where Linux instead ships a special "linuxso.so" that all processes and libraries need to (dynamically) link against in order to get a stable interface.
  - gmueckl 7y ago
    That attitude that is so prevalent in Linux user space is what this thread was getting at. This is why the syscall interface being maintained as a stable interface is so important on Linux compared to other operaring systems.
- account42 7y ago
  > But every other library that you don't ship with your binary is essentially out to break your stuff. There are many more lower level libraries that provide binary backwards compatibility: libasound, libX11, libGL, ... Sure you're not going to be able to assume that /usr/lib/libpng.so.1 will provide the functionality that you want but that isn't any different from png1.dll some program installed in system32.
  - gmueckl 7y ago
    It's funny that you mention libpng. That is one of those libraries that is developed so conservatively that I'd actually trust it to provide the features a binary that I ship relies on. I rarely (if ever) needed the more obscure things like 16 bit per channels or ICC profiles.

fortran77 7y ago

But Windows has excellent back-compatibility!

quotemstr 7y ago

Backward compatibly is important. It's a weird Linuxism to assert that it's the kernel that has to provide the compatibility interface. There's no reason the ring zero transition has to be the stable part. The real reason Linux's ABI boundary is the kernel is just that the kernel and glibc are sperate and frequently-antagonistic projects. Linux ships the org chart.

caf 7y ago
Even if they were the same project it wouldn't matter, because the promise is that your completely statically-linked binary will continue to work without recompilation on tomorrow's kernel if it works on today's.
- quotemstr 7y ago
  Huh? What you should care about is whether your program can run on future systems. Whether you call your program static or not is irrelevant.
  - caf 7y ago
    It's relevant because if your program is statically linked then it doesn't matter whether or not future changes at the kernel boundary are made backwards-compatible by compensating changes in libc (as is possible if you release them together), because your statically-linked binary can't pick up those libc changes.
    - masklinn 7y ago
      So it's relevant because it avoids breaking your stupidity? The entire objection is that it's a self-inflicted wound, if you don't statically link everything it's not an issue. And non-linux systems will just forbid statically linking libc (e.g. can't statically link libc / libSystem on OSX).
      - caf 7y ago