> Why would anyone care unless they are writing a libc replacement?
- So that you can feel safe upgrading your kernel without upgrading your whole userspace. (Linus harps on this one a lot.)
- So that there can be multiple competing libc's. Linux is used in a lot of diverse environments, and the tradeoffs made by glibc (in terms of bloat, license, etc.) are not necessarily the best for everyone. Android does not use glibc, for example.
- So that you can isolate apps from each other using containers (hermetic chroot environments), where different containers may have entirely different libc. Docker (and my own Sandstorm.io) relies very heavily on Linux's syscall ABI compatibility promises.
- Because the syscall ABI is frankly a much clearer boundary than the libc ABI, and arguably easier to keep backwards-compatible. An app literally _can't_ break this boundary and access the private interfaces beneath (assuming a secure implementation, lol).
- So that you can feel safe upgrading your kernel without upgrading your whole userspace. (Linus harps on this one a lot.)
- So that there can be multiple competing libc's. Linux is used in a lot of diverse environments, and the tradeoffs made by glibc (in terms of bloat, license, etc.) are not necessarily the best for everyone. Android does not use glibc, for example.
- So that you can isolate apps from each other using containers (hermetic chroot environments), where different containers may have entirely different libc. Docker (and my own Sandstorm.io) relies very heavily on Linux's syscall ABI compatibility promises.
- Because the syscall ABI is frankly a much clearer boundary than the libc ABI, and arguably easier to keep backwards-compatible. An app literally _can't_ break this boundary and access the private interfaces beneath (assuming a secure implementation, lol).