3 ms·

Looking at one of my remote servers running Debian Buster, it has about the same amount of GNU stuff on it (~100 MB) and most of that is semi-obsolete tooling t

Looking at one of my remote servers running Debian Buster, it has about the same amount of GNU stuff on it (~100 MB) and most of that is semi-obsolete tooling that, again, just isn't necessary day-to-day. I could probably purge ~all of it without loss of functionality. I log in with OpenSSH, which listens on a Wireguard interface. The shell is whatever generic Bourne-alike Debian uses (Ash? Dash?). The administrative tools are all written in Go since they're a mix of contemporary projects (containerd) and my own administrative agents. Primary editor is vim. There's the basic tools (mv, cp) but those could just as easily be supplied by Busybox, which is installed. It's difficult for me to imagine what sort of server would run GNU software as a majority of its workload, or even just the UX control surfaces. The GNU project has always had a strong emphasis on re-creating the UNIX interfaces of yesteryear, and modern sysadmin practices don't include running m4 or gcc in the same machine that's going to serve traffic.

aragilar 5y ago
Does glibc count? If you use systemd, then you are dependant on GNU (as noted in the article). GNOME is becoming more systemd-dependant, so GNOME is also implicitly more dependent on GNU. Other things include mDNS (what, if anything, does blah.local resolve to on non-GNU systems), libquadmath (which tends to be required more often than people would expect) or GNU-specific flags/behaviours (e.g. GNU tar just does the right thing). I suspect if you did purge the GNU stuff (baring the things which either require you to specifically say you're fine with the result or remove required software) you'll find lots little things that don't work right, because the GNU code is functionally the only option (missing features, integrations from other software etc.). I don't think GNU is particularly special this way: try going from vim to busybox vi, or looking at how much stuff depends on imagemagick (a.k.a https://xkcd.com/2347/ https://xkcd.com/2347/).
- hnfong 5y ago
  You're naming a lot of projects that aren't under the GNU umbrella. Why shouldn't "Linux" systems be called "systemd/Linux" instead? Why not "imagemagick/Linux" even? It seems very silly to name a family of operating systems just for the C library alone. Sure, there are apps that depend on GNU extensions, but beside systemd I don't know whether the rest are really true. (Pretty sure Vim and Imagemagick work fine without glibc...) I don't think Richard Stallman would have gone so far to attach the GNU name just because of libc. Back then when he was advocating for GNU/Linux, it was because GNU basically had a unix clone implemented and ready (libc, compiler, shell and common utilities), but people eventually named the system by the kernel, the only component that they failed to get right. At that point it was probably apt to call the system GNU/Linux, but these days when many of the original GNU parts are replaceable or faded into obscurity, I don't know whether the argument holds any more.
  - aragilar 5y ago
    Ah, sorry, I probably wasn't clear enough: you can't just count direct dependencies (or install size) when considering something's importance, you also need to consider indirect dependencies (which I think jmillikin is underestimating). I'd also argue in many cases the GNU parts have only been partially replaced, if at all (mDNS name lookups for example). My example of mDNS is deliberate: doing a name lookup of blah.local can either go though glibc's NSS (musl explicitly does not have NSS), or explicit calls to resolved (glibc only because systemd) or avahi (non-glibc only). Unless everything calls out to avahi, you've can't rely on blah.local working on non-glibc systems. I used imagemagick as an example (which inspired that xkcd comic) of a project which is a common indirect dependency, and vim (compared with busybox vi) to show the effect depending on extensions (you could use neovim and vim instead, but busybox was suggested as a complete replacement of coreutils). I'm not suggesting either of these are systemd or glibc only. As to why not systemd/linux: the set of systems where systemd runs is a strict subset of where the GNU software is used, and so you have GNU/Linux systems which are not systemd/linux systems (also, systemd is linux only as far as I know, where as glibc does run on non-linux systems (Debian's GNU/kfreebsd) so it does make sense to have that distinction, where as a system running systemd could be called a systemd system with no loss of generality). EDIT: It's also worth considering another piece of data: the author is one of the Alpine linux maintainers, they presumably wrote the article for a reason (likely bugs reports either due to people being unable to install/run specific software, or behavioural differences from GNU tools).

aragilar 5y ago

Does glibc count? If you use systemd, then you are dependant on GNU (as noted in the article). GNOME is becoming more systemd-dependant, so GNOME is also implicitly more dependent on GNU. Other things include mDNS (what, if anything, does blah.local resolve to on non-GNU systems), libquadmath (which tends to be required more often than people would expect) or GNU-specific flags/behaviours (e.g. GNU tar just does the right thing). I suspect if you did purge the GNU stuff (baring the things which either require you to specifically say you're fine with the result or remove required software) you'll find lots little things that don't work right, because the GNU code is functionally the only option (missing features, integrations from other software etc.). I don't think GNU is particularly special this way: try going from vim to busybox vi, or looking at how much stuff depends on imagemagick (a.k.a https://xkcd.com/2347/ https://xkcd.com/2347/).

hnfong 5y ago
You're naming a lot of projects that aren't under the GNU umbrella. Why shouldn't "Linux" systems be called "systemd/Linux" instead? Why not "imagemagick/Linux" even? It seems very silly to name a family of operating systems just for the C library alone. Sure, there are apps that depend on GNU extensions, but beside systemd I don't know whether the rest are really true. (Pretty sure Vim and Imagemagick work fine without glibc...) I don't think Richard Stallman would have gone so far to attach the GNU name just because of libc. Back then when he was advocating for GNU/Linux, it was because GNU basically had a unix clone implemented and ready (libc, compiler, shell and common utilities), but people eventually named the system by the kernel, the only component that they failed to get right. At that point it was probably apt to call the system GNU/Linux, but these days when many of the original GNU parts are replaceable or faded into obscurity, I don't know whether the argument holds any more.
- aragilar 5y ago
  Ah, sorry, I probably wasn't clear enough: you can't just count direct dependencies (or install size) when considering something's importance, you also need to consider indirect dependencies (which I think jmillikin is underestimating). I'd also argue in many cases the GNU parts have only been partially replaced, if at all (mDNS name lookups for example). My example of mDNS is deliberate: doing a name lookup of blah.local can either go though glibc's NSS (musl explicitly does not have NSS), or explicit calls to resolved (glibc only because systemd) or avahi (non-glibc only). Unless everything calls out to avahi, you've can't rely on blah.local working on non-glibc systems. I used imagemagick as an example (which inspired that xkcd comic) of a project which is a common indirect dependency, and vim (compared with busybox vi) to show the effect depending on extensions (you could use neovim and vim instead, but busybox was suggested as a complete replacement of coreutils). I'm not suggesting either of these are systemd or glibc only. As to why not systemd/linux: the set of systems where systemd runs is a strict subset of where the GNU software is used, and so you have GNU/Linux systems which are not systemd/linux systems (also, systemd is linux only as far as I know, where as glibc does run on non-linux systems (Debian's GNU/kfreebsd) so it does make sense to have that distinction, where as a system running systemd could be called a systemd system with no loss of generality). EDIT: It's also worth considering another piece of data: the author is one of the Alpine linux maintainers, they presumably wrote the article for a reason (likely bugs reports either due to people being unable to install/run specific software, or behavioural differences from GNU tools).