09.04.09

Eight reasons you should be using Linux. (and not GNU/Linux)

Posted in geek, en_US, Fedora at 12:23 pm by glommer

Over the years, many arguments were provided by FSF and its supporters for what the system many of us use should be called GNU/Linux, instead of just Linux. Most of them does not make much sense anyway, and can be easily discarded. I choosed the two more common ones to discuss here, by arguments #1 and #2. About them, I never thought they make sense anyway.

In all this time, just one particular argument actually made some sense to me. The glibc argument, which basically says that what defines the behaviour of the system is the combination of GNU libc and the kernel Linux. Linux provides hardware management, but if you replace it with some other totally different kernel and kept the GNU libc, wrote a schim between this new kernel and glibc, every userspace program would be kept working.

In arguments #3 on, I’ll try to show why in my current view, this argument, like all the others, just makes no sense at all.

1. The collection argument

A typical “Linux” distribution, as it is usually called, it comprised by many software packages, including the Linux Kernel. There are two ways of seeing the naming issue, which basically depends on what definition of an Operating System (O.S.) you use.

If you think of an O.S. as just the kernel, we’re done. It is totally valid to say you use “The Linux Operating System”. However, many people note that the kernel itself does not do much for itself (although I arguee that it does not have to do much: it just have to what an O.S. does, which is not that much!).

With just the kernel, your device won’t work as intented, therefore not being fully functional. The actual Operating System is then, larger than that. This is the definition the FSF uses, calling the remainder of the system, GNU.

It might be true for RMS, that does every single thing, including browsing and e-mailing from within emacs. However, if we pick, for example, an average desktop user, his system is comprised by, in the sense of “not being fully functional without”:

• Linux, which is not a GNU Software
• GNU libc, which is, as the name says, a GNU Software
• X.org, which is not a GNU software
• A Python interpreter (try removing it to see what happens). Non GNU.
• A Java virtual machine, which is not always a GNU Software
• A Window Manager, among which just GNOME is more or less a GNU Software

The official subset that makes the system “recognizable” for your final applications may vary from use case to use case. But although it might not have been true some years ago, GNU is far away from being a majority. The only way to make justice (but as I intend to show in argument #2, it also
makes no sense), would be to call it GNU/Java/Python/X.org/KDE/Linux

Instead, the only sane two options are:

1. Pick the component that defines it behaviour, which implements things that no other part can. The kernel can ultimately implement everything userspace
   can, although it is a stupid thing to do. There are things that just the kernel can do. From this, it is totally fine to say “I run Linux”, implicitly saying “plus a lot of other stuff ontop”.
2. Acknowledge that every single collection is different from its parts, and call it by the name the ones who actually did the final work of integrating that whole collection intented. Be it Fedora, Ubuntu, or etc.

Note that IMHO, there is nothing wrong with creating a distro (IOW, the whole OS), and calling “Whatever GNU/Linux”. As much as there is nothing wrong in creating a “Whocares KDE/Linux”. Just that, requiring other people to do that, specially saying this is a moral issue, is totally unfunded.

2. The derived work argument

There was in Brazil, some time ago, a distribution called Conectiva Linux. It was heavily based on Red Hat Linux. And it was not called Conectiva Red Hat
Linux. Red Hat Linux is no more, and the Fedora project inherited most of its code base. Note it is called Fedora, not Fedora Red Hat Linux.

If you look at the other big branch of the Free Software ecosystem, there is Ubuntu. It’s name is not Ubuntu Debian. The list goes as long as one wants it
to, with thousands of examples outside the Free Software community too.

When you do derived work, it is polite (and if you really care, you can even say you have the moral obligation) to give credit for the major pieces you
started building at. So to make it clear:

• Any distribution owes a lot to the GNU Project.
• It would be hard to run Linux if GNU wasn’t there in the first place
• A lot of the userspace Linux uses today still comes from GNU.

Thousands of statements like this can be made. But there is absolutely nothing, nor legal, nor moral, nor out of politeness, that says that you should quote all the work you built upon in the name of the project you built.

Distributions are a derived work of both GNU and Linux (and a lot others), but the naming issue has absolutely nothing to do with it. As much as it might be true that the result of this collaboration is not Linux alone, unless the FSF releases a distribution actually called GNU, GNU/Linux, or whatever, there is no reason anyone should name theirs like that.

3. The udev argument

I’m running a semi-freshly Fedora system. If I try “yum remove udev”, what I get is the following:


[...]
Remove 533 Package(s)
[...]

In this very same system:

[root@t60 ~]# rpm -qa | wc -l
1471


This is roughly 36 % of all Fedora. If you just remove Linux and keep the GNU libc with another kernel, you lose udev support.
udev is a communication channel that, among other things, notifies user space programs about hardware-related events, such as a usb device
being plugged in. Not something that can be implemented in glibc, and part of the defining behaviour of any Linux distribution.

4. The mount argument

mount is a widely available command. Pretty much any unix system has it. However, Linux mount has some features that you can’t take for granted in other systems. Nested mounts and bind mounts are examples of that. If those features exists in the first place, I can imagine there are utilities relying on it. This is something that relies on the behaviour defined by the Linux kernel. The GNU libc has nothing to do with it.

5. The O_DIRECT argument

Although Linus does not like it, the open system call in Linux can accept a flag called O_DIRECT. Basically, what it does is it bypasses all the operating system caches on writes to that files. There is no way you can emulate it in userspace.

O_DIRECT is not a performance optimization. It is a correctness issue. If a program (most likely a database) opens a file with O_DIRECT and the kernel doe not guarantee that, you’ll probably face severe data corruption. Thus, it is part of the behaviour defined by the Linux kernel.

6. The storage argument

More and more things in the storage stack is linux-specific (well, as much as there are solaris specific, and etc). To give an example, the brand new BTRFS
file system implements a lot of really cool features like snapshoting, copy-on-write, checksumming, and etc. This is not something doable in
userspace. Well, it actually is, with a performance penalty, if you do that in FUSE. But you can only do it because the linux kernel allows you to. There’s
no way glibc could circumvent that if it didn’t.

7. The syscall argument

Syscalls are the very interface between the kernel and the rest of the system. As I discussed in the other arguments, they provide the defining behaviour of your
system.

Although most system calls linux implements are posix-compliant - sometimes with a broad definition of ‘compliance’, a lot of it are linux specific. If I decide to bypass the GNU libc, I can just call _syscall() by hand. If I want to write my very own malloc, or my very own version of anything the GNU libc implements, that can be done. I could even write a super program called “userspace”, that re-implements all the functionality we have in userspace, from X to firefox in a single giant program.

But if I need to use something that has to be provided by the operating system, and it does not - like the features described above - that’s the end of the line. It is thus, the kernel that ultimately defines what a system is, can and cannot do, and is ultimately descriptive of the characteristics of it.

This is not to say userspace programs are not important. On the contrary. Just that they are not as descriptive of what the system is, as is the kernel.

8. who f***** cares? argument

Ultimately, names just stabilish conventions. I live in a state called Sao Paulo, whose capital is called… Sao Paulo. The blue algae is not blue,
and not even algae.

This is confusing, but ultimately, this is the way it is, because names are just names, and we all comunicate using non context-free languages. If you look
around you, you’ll see a lot of names that are totally unappropriate to describe what they mean to. Yet, no one f*** cares. Most people call
linux kernel derived system just “Linux”, and ultimately, this is what matters. If a critical mass just started to call it Pink Overdosed Elephant,
and most people understand it, POE it is. That said, the FSF is obviously free to call it GNU, as much as I’m free to call airplanes pigs, and pigs
something else entirely. Just it just brings more confusion to the discussion.

From all possible subjects of dicussions towards a Free Society, this is the least important, by far.

Popularity: 45% [?]

Permalink