4 ms·

>Distributions built on GNU libc/coreutils, including Fedora and Ubuntu, are below the noise floor. This is not true if you consider the server market. Almost

>Distributions built on GNU libc/coreutils, including Fedora and Ubuntu, are below the noise floor. This is not true if you consider the server market. Almost all the Linux machines and virtual machines are running the glibc and gnu toolchain. I know that there's alternatives like musl-based distributions, but that's kind of fringe. In any case, I'm not a "GNU/Linux" promoter. Though I can sympathize with Stallman feeling a little cheated on the naming stuff, especially in the early days when GNU tools were the bulk of the userland. But nowadays, the only strong part of their claim is glibc and the compiler toolchain. The real reason why GNU has floundered as an organization is that they (and Stallman in particular) are rigidly ideological and difficult to work with.

jmillikin 5y ago
You might be surprised. What you say was definitely true ten years ago, or maybe even five, but the adoption of containers has changed things a lot. A container-oriented VM host can boot with a handful of binaries designed to receive scheduled workloads and nothing else. The root filesystem is read-only. Go is a popular implementation language for this stack (look at containerd or kubelet), so no libc. SSH is OpenSSH, shell and init and such are Busybox or similar. The scheduled containers might contain GNU code if they're using a Debian chroot as a base filesystem, but even that's becoming less popular because it introduces questions of package updates and reproducibility. The container might itself contain just a statically linked binary (Go, Rust, or C/C++ with MUSL) plus its data files. Right now this approach hasn't filtered down to the hobbyist area yet (except among current or former FAANG employees), but I think in 5 or 10 years it'll be the standard (unless a wildcard like Fuchsia or Oxide's Hubris takes over).
- legalcorrection 5y ago
  All very interesting. I just want to say that I strongly doubt that non-libc or musl based environments will take over on linux servers anytime soon. Perhaps for narrow use cases, like as you mention, a vm host that only needs to run one binary.
  - Tostino 5y ago
    > All very interesting. I just want to say that I strongly doubt that non-libc or musl based environments will take over on linux servers anytime soon. Perhaps for narrow use cases, like as you mention, a vm host that only needs to run one binary. I think you underestimate the number of services that could be run in this fashion with a much reduced attack surface. It's not at all niche.
  - hnfong 5y ago
    You can doubt but it seems that Go is becoming the de facto language on the server side. Which doesn't use libc. A lot of systems still run on Java -- I suppose the Linux JVM does depend on glibc, but seriously, in these situations you might as well call it Java/Linux. As I commented elsewhere, arguing that a system ought to put the developer of its C library in its name seems silly when it's just one small component. The GNU ecosystem used to be much more influential in the 90s and early 2000s...

jmillikin 5y ago

You might be surprised. What you say was definitely true ten years ago, or maybe even five, but the adoption of containers has changed things a lot. A container-oriented VM host can boot with a handful of binaries designed to receive scheduled workloads and nothing else. The root filesystem is read-only. Go is a popular implementation language for this stack (look at containerd or kubelet), so no libc. SSH is OpenSSH, shell and init and such are Busybox or similar. The scheduled containers might contain GNU code if they're using a Debian chroot as a base filesystem, but even that's becoming less popular because it introduces questions of package updates and reproducibility. The container might itself contain just a statically linked binary (Go, Rust, or C/C++ with MUSL) plus its data files. Right now this approach hasn't filtered down to the hobbyist area yet (except among current or former FAANG employees), but I think in 5 or 10 years it'll be the standard (unless a wildcard like Fuchsia or Oxide's Hubris takes over).

legalcorrection 5y ago
All very interesting. I just want to say that I strongly doubt that non-libc or musl based environments will take over on linux servers anytime soon. Perhaps for narrow use cases, like as you mention, a vm host that only needs to run one binary.
- Tostino 5y ago
  > All very interesting. I just want to say that I strongly doubt that non-libc or musl based environments will take over on linux servers anytime soon. Perhaps for narrow use cases, like as you mention, a vm host that only needs to run one binary. I think you underestimate the number of services that could be run in this fashion with a much reduced attack surface. It's not at all niche.
- hnfong 5y ago
  You can doubt but it seems that Go is becoming the de facto language on the server side. Which doesn't use libc. A lot of systems still run on Java -- I suppose the Linux JVM does depend on glibc, but seriously, in these situations you might as well call it Java/Linux. As I commented elsewhere, arguing that a system ought to put the developer of its C library in its name seems silly when it's just one small component. The GNU ecosystem used to be much more influential in the 90s and early 2000s...