4 ms·

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 containe

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...

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...