1. 12
  1. 12

    The distributions have already picked their (often trademarked) names:

    • “Red Hat Enterprise Linux”, not “Red Hat Enterprise GNU/Linux”.
    • “Suse Enterprise Linux”, not “Suse Enterprise GNU/Linux”.
    • “Slackware Linux”, not “Slackware GNU/Linux”.
    • “Gentoo Linux”, not “Gento GNU/Linux”.
    • “Arch Linux”, not “Arch GNU/Linux”.
    • “Ubuntu”, not “Ubuntu GNU/Linux”.
    • Even “Debian” with 6.0 “squeeze” stopped using “GNU/Linux” in its release names.
    • etc.

    Debian further used eglibc for a time, which forked from GNU libc and was not GNU software. eglibc eventually merged back in with GNU libc, but during that time Debian was not a GNU/Linux distribution by this criteria. Speaking in generic terms you run into problems as that article mentioned. Alpine, OpenWRT, and Android all do not use GNU libc, so by their definition, are not “GNU/Linux”.

    Even if it is technically correct to refer to distributions as “GNU/Linux”, it’s also divisive. Back in 2012, Linux Weekly News senior editor Jonathan Corbet mentions that they stopping asking the FSF for comments, specifically because of the naming controversy:

    “Just to be clear on this: we stopped asking the FSF for comments many years ago because the FSF refused to talk to us without prior promises from us on what we would say and which terms we would use. We are unwilling to make such promises. If the FSF’s policy on such things has changed, we would be pleased to know about it.”

    1. 6

      Even if it is technically correct to refer to distributions as “GNU/Linux”

      It’s also pointless. It’s like people who want to control what words and grammar rules are considered correct in a language. Languages evolve organically by it’s users. Words that weren’t considered native or syntactic constructions that weren’t considered valid, become acceptable when a significant portion of language users use them.

      Even though it is technically is valid to talk about GNU/Linux, GNU/kFreeBSD, or perhaps MUSL/Linux, there are other considerations in the evolution of naming. One important one is that “Linux” is just shorter and easier to pronounce than GNU/Linux. Furthermore, most people don’t really care if it is Linux using glibc + coreutils, MUSL, or whatever. To them it is just Linux, not Windows or macOS. Or if they want to be more specific, they’ll refer to the product name, like “Red Hat Enterprise Linux” or “Alpine Linux”.

      The world chose to call it Linux and not GNU/Linux. Live with it. Outside a very small group (who will look obnoxious to the outside world), nobody really cares.

      1. 1

        I think the idea is that the default taxonomy and common terms in this space lead to invalid expectations for many users, who change Linux distros and expect certain things to work the way they did on their prior GNU system.

        I take the point of this article to be 1) to remind people that the presence or lack of GNU tools is relevant, 2) to encourage separation between things are are GNU-things and things that are Linux-things in the way people talk about the world of Linux-based operating systems, in the hope that users have clearer expectations for what will remain the same when they change platforms.

      2. 3

        I don’t mind distros saying Linux instead of GNU/Linux, because a distro is a platform. The RHEL platform is not just GNU/Linux, it’s GNU + Linux + X.org + systemd + a load of other libraries and system services / configuration tools. The RHEL system includes a load of applications bundled on top of this platform. Saying RHEL or Debian Linux is strictly more specific than saying GNU/Linux (saying Debian might be now - I think Debian dropped the HURD and kFreeBSD versions).

        The problem is that a lot of people use Linux to mean GNU/Linux. You have conversations like (paraphrased from real conversations I’ve had):

        ‘Clang isn’t used much on Linux’

        ‘You mean, apart from the couple of billion Linux systems that use it as the default compiler?’

        ‘Oh, Android isn’t Linux, I mean Linux Linux’


        ‘MS Office runs on Linux, I use it every day’

        ‘But only on Android, that’s not Linux’

        When what the speaker means is a Linux distro that has glibc, Linux, and (typically) an X server. Not just something that has the Linux kernel. Android really exacerbates this by having a completely different libc, system service management system, and display server from any other kind of Linux system, yet still being Linux. Hopefully they’ll move to Fuchsia soon and eliminate that confusion.

        Alpine is another fun corner case. In my experience, it’s easier to port software between FreeBSD and a GNU/Linux distro than it is to port between Alpine and a GNU/Linux distro. Most code doesn’t care about the kernel at all and FreeBSD libc and glibc have both adopted a lot of each other’s extensions (and there are shim libraries such as libbsd, libkqueue, and libepoll for papering over the differences, just adding some of them to be build is often sufficient). Runs on Linux or runs on GNU/Linux doesn’t imply that it will work on Alpine without porting (unless it’s something that doesn’t depend on libc at all, such as Go binaries).

        That said, GNU/Linux is itself somewhat confusing. For example, Ubuntu replaced bash with dash as /bin/sh, so their default shell is no longer GNU, even though all of their core utilities are (Debian later adopted this). I’ve seen other systems where the core utilities come from busybox, but libc is still glibc to ease porting. If you have coreutils, glibc, but not bash, are you GNU/Linux? What if you have coreutils, bash, and musl? Or busybox and glibc, no coreutils or bash?

        The distro names are the only unambiguous platform identifiers, but no one wants to say ‘runs on Debian or RedHat, you might be able to make it work on your distro if you have adequate shims and your distro ships compatible versions of the libraries’, they want to say ‘runs on Linux’.

        1. 1

          The idea that distros “already picked” their name is undermined by the Debian example.

          Even if it is technically correct to refer to distributions as “GNU/Linux”, it’s also divisive.

          You give an example of a division caused by one party’s refusal to agree to say GNU/Linux (we can assume). So that would be the divisive thing, no?

        2. 6

          For an immense number of users, X is just as important to their “Linux experience” as the kernel or the libc or the base shell and utilities, but nobody demands that we call Linux GNU/MIT/Linux (or GNU/Athena/Linux or GNU/X11/Linux).

          The GNU Project was and is vitally important to the entire computing world, and they were critically important to bootstrapping Linux in its early days, but GNU needed Linux a lot more than Linux needed GNU, IMHO.

          1. 5

            I dunno, this seems like a somewhat intractable problem of trying to precisely and concisely describe motley assemblages of software components (“operating systems”) by whether or not they belong to some fairly broadly-defined category. You can certainly draw some semi-arbitrary boundaries and do that, but what does it ultimately achieve?

            For example, I run Void. It’s available in both glibc- and musl-based flavors. If I swap out one libc for the other, does it suddenly become a meaningfully different OS? I’d argue no, for most practical purposes. In a situation where the distinction is likely to be relevant, I can clarify by stating whether it’s “Void with musl” or “Void with glibc”, but it’s probably just as frequent (if not more so) that I’d need to clarify “Void with Xmonad” vs. “Void with KDE” or whatever else.

            1. 3

              On the final point of projects advertising compatibility: if a README avoids saying “we support Linux” followed by installation with apt-get they’re already better than the norm.