So, the comments got a bit long in the last post. I think I’ll clean it up, and get the interesting tidbits out of there and present them here in a clear fashion. Also, while I appreciate Michael B. Trausch’s discussion on the topic, and provided some interesting discussion points (which will be discussed further here.) Also, reading through my arguments that I put in the comments of the last post really didn’t flow together. They were mainly taking my base argument and extending it to rebut Michael B. Trausch’s claims. The comments became a bit unwieldy to actually get out what the useful information.

So without further ado, perhaps we can finally put this silly argument behind us (not likely but I can dream right :)) Because GNU still is not part of the Linux OS.

Point of discussion (POD) 1:⌗

“Linux is useless without GNU.” “It doesn’t even boot without init. If the OS panics without GNU, it must be because it’s part of the OS.” This is false. While it’s true, Linux does depend on having a single application to execute after it’s done with it’s initialization, that doesn’t mean that the program passed to Linux is part of the OS. Let’s take this as an example: [cc lang="c”]#include <stdio .h>

int main(int argc, char *argv[]) { while(1) printf(“Am I part of the OS now?\n”);

return 0; }[/cc]So this can be compiled with gcc -o /my_example my_example.c After it’s compiled, the OS can be rebooted with the following passed to Linux as an argument “init=/my_example” Now, upon boot you’re greeted with “Am I part of the OS now?” printing to the screen forever (or until you reboot.) By the very same logic used in the POD, I’ve just written a whole new OS. This is of course, incorrect. This should be plain to see, and also it’s easy to agree that what I just wrote isn’t an OS. Now, why is this not an OS? Let’s take a couple definitions of an OS shall we? Definition 1:

The operating system interacts directly with the hardware, providing common services to programs and insulating them from hardware idiosyncrasies. Viewing the system as a set of layers, the operating system is commonly called the system kernel, or just the kernel, emphasizing its isolation from user programs.

So by this definition, my program obviously fails “is it an OS or not” test. It doesn’t touch the hardware itself. Thus, it’s not an OS (or even part of an OS.) Linux on the other hand, precisely fits this definition. So, by this definition Linux is an OS. Nothing else is required by this definition. So, now let’s look at a typical GNU program that people using the POD often argue is part of the OS. I present to you “cp.” Now, let’s take a look at what actually happen when you actually invoke cp. First the command is executed with and argument or two (how or where it’s executed doesn’t matter, it could be directly from init="cp /my_example /my_example2” The means by which cp isn’t relevant.) So, after the program starts executing, it typically has logic to check for if files exist, lets ignore that for now, when it actually gets ready to copy the file (in C) the a call to open() then the file is read() into a new file. open and read is defined in the C library. While in the C library, a call to Linux’s to filesystem is made. From the file system, a call to the hard drive driver is made and the actual location file to be opened/read (in the case of open, this may be skipped if the FS already knows where on the HD the file is. In the case of a read, this step is mandatory otherwise, the file isn’t actually being copied by the OS.) So, in GNU systems, it’d be: cp->read->glibc->FS->Linux driver->hardware.

So, what actually talks to the hardware? If you said Linux, you’d be right. my_example is very similar: printf->glibc->Linux console->monitor.

Again, Linux is what’s dealing with the hardware here and nothing else. So, by the definition Linux is the OS, and cp/coreutils/other GNU userspace applications/my_example are not.

Let’s try this with another definition of an OS put forth by Michael B. Trausch, real source: unknown Definition 2:

Now, let’s take a look at a definition of operating system—the definition that software programmers use, more or less: An operating system runs processes, manages processes, and multiplexes their access to finite hardware and software resources. It provides an environment that is consistent amongst different processes. It provides for every process an address space which can be managed by the operating system (directly, by way of the kernel, or indirectly by way of kernel management utilities which are part of the operating system).

Now, everything up to the parentheses I’d agree with, it’s what’s inside that I have issue with. Here’s why. Using the above, here’s modprobe’s execution order (which falls into that last part.) modprobe->syscall()->glibc->then Linux’s syscall is done->Linux loads the module from the arguments passed to it.

Even though loading modules is an optional feature of the OS, by Michael B. Trausch’s definition, modprobe would have been part of the OS, but really Linux did most all the work.

If I were to change Michael B. Trausch’s definition and omit that last part, it would be consistent with the other definition I’ve provided. Definition 3:

An operating system runs processes, manages processes, and multiplexes their access to finite hardware and software resources. It provides an environment that is consistent amongst different processes. It provides for every process an address space which can be managed by the operating system

Here’s another definition of an OS by Moshe Bar <http ://www.linuxjournal.com/article/4048> Definition 4:

A kernel is the operating system software running in protected mode and having access to the hardware’s privileged registers. The kernel is not a separate process running on the system. It is the guts of the operating system, which controls the scheduling of processes to achieve multitasking, and provides a set of routines, constantly in memory, to which every user-space process has access.

(italics added by me for emphasis.) This definition, again, is exactly what Definition 1 & 3 of an OS states. By all three of these definitions, Linux is an OS. GNU offers the user space tools to provide a POSIX like environment.

Note: GNU (and glibc in particular) provide a POSIX interface to the OS. While glibc is required for my_example to run (unless it was statically linked), glibc itself is just provides the API by which the OS is accessed. The fact that I used glibc in my examples is irrelevant. Any API that provides access to the OS would have worked (uClibc, newlib, and diet libc just to name a few.) The main point here is that the API that sits between Linux and the applications doesn’t matter. For all intents and purposes, the my_example program could be rewritten to make the Linux syscalls directly, but that would have been overkill for our discussion.

Now lets move on.

Point of Discussion 2:⌗

“Without GNU Linux is useless.” “The my_example program isn’t part of the OS (or an OS) because it doesn’t do anything useful for a user.” This argument carries no weight what-so-ever. I’ve briefly explained why above with my_example. But I’ll go over it again to reiterate some of the points.

By the time Linux is fully booted, it is in a useful state. The proof is in that my_example was able to run just fine, and access the hardware just fine (and a process was spawned.) Just because my_example does nothing useful (to and end user) doesn’t mean it’s not using the OS. Linux itself however, by executing my_example, spawning a process, managing where my_example’s memory should be placed, and accessing the hardware to infinitely printing my message. So, yes, my example is useless (for everything except making a point) but Linux at that point isn’t. It’s a fully operational OS at that point.

What the end user considers useful has nothing to do with what an OS is. What one person considers useful doesn’t mean that someone else is going to find the same thing useful. Thus, trying to fit usefulness into the equation for what makes an OS is like throwing and unknown variable into an equation, asking someone to solve, telling them to make the variable whatever they want, then wondering why each equation comes out to a different answer. This is precisely why the definition to OS’s have been defined. All three of the definition I’ve provided leave almost no user interpretation.

Point of Discussion 3:⌗

POSIX There is often a misunderstanding of POSIX’s role in Linux systems. The first thing to understand is that POSIX is a specification for a UNIX system. Secondly, POSIX defines an API and some userland tools. This is to not only make things nicer for users of POSIX systems (familiar tools across POSIX compatible systems), but to also allows for programs that are (more or less) source compatible. That way less work has to be done when porting from one POSIX system to another.

This should not be confused with being the OS or even part of the OS. It’s part of the user’s environment, but not of the operating system. Any time a system wants to be POSIX compatible, the API and userland tools must be implemented for the target OS. This is almost always done in such a way that the API and userland communicate with the OS, and then the OS takes care of the actual hardware interaction. POSIX on Linux is a layer that sits on top of Linux.

I think these three points of discussion are enough to get the ball rolling. Please let me know what else needs explained or clarified to get the point across that GNU/Linux is incorrect.