It’s still Linux, not GNU/Linux.

<edit>I’m in the process of rewriting this with some information and rebuttals to some of the comments. Stay tuned for that later tonight. Sorry to anyone on identi.ca in !ubuntu !linux or !gnu that may be writting a comment now. I’m locking comments so the newer one will get the traffic (since it’s going to be much better written than this one which I spent all of 10 minutes on.) </end edit>
I don’t understand why there’s so much push to have the Linux OS, called GNU/Linux. I see arguments like, “Linux is useless without GNU, so it’s part of the OS”, “Linux is just a kernel and not an OS”, “Look at other OS’s like FreeBSD, it includes more than just the kernel.” etc. In a very strict sense of the definition of an OS it’s:

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.

— From  The design of the unix operating system, Maurice J. Bach, Prentice/Hall, 1986, page 4

By that definition of an OS, Linux itself stands on its own. Whether or not you consider it useful at that definition is irrelevant. That’s why a POSIX environment is used, to actually do something useful after the hardware has been abstracted. GNU, just so happens to fill end up being the common POSIX environment. That doesn’t mean that it’s now GNU/Linux does it? Or better yet, should BusyBox based distros be called BusyBox/Linux? Do you know why you rarely, if ever, see that phrase? Because it’d by-and-large be incorrect to say it. The fact that you use GNU, BusyBox, or any other POSIX or non-POSIX userland is irrelevant to what the OS actually is. Here’s another example of the above error in logic from http://www.topology.org/linux/lingl.html :

A linux operating system cannot work without a CPU.
Therefore the CPU is part of the linux operating system.
Therefore the operating systems which I use are AMD/linux and Intel/linux.

I’ll highlight a few more snippets from the above web page:

There are three plausible definitions of operating system:
1. The OS kernel. This is the technically correct definition.
2. The OS kernel plus some basic utilities (compiler, linker, editor, CLI shells, etc.).
This is the obsolete 1980s colloquial and marketing definition which is used by RMS.
3. The OS distribution. This is the modern colloquial and marketing definition.
If you read a technical book about how to write an operating system, you will always see definition (1): the kernel, a RAM-resident program which loads and unloads applications and manages access to resources.
If you buy a linux operating system, then you are using definition (3). The linux OS distribution is usually several thousand packages on one or more disks. Of these thousands of packages, a few contain the kernel, a few contain some basic utilities (such as gnu for example), and about 97% of the packages are 3rd party software.

If you use the most correct definitions (1) and (3) of an operating system, then linux is not gnu/linux. Only if you use the obsolete 1970s and 1980s definition (2), then linux would be gnu/linux. But history has moved on. RMS is in a time-warp. We don’t get our operating systems on a 1/2″ mag tape any more. Definition (2) comes from the old Unix distribution tapes in the 1980s. That’s why RMS claims that kernel + compiler + basic utils = operating system. That is a Unix tape, not an operating system. The old Unix tapes had operating systems on them, and also lost of other stuff. It was just colloquial usage in the 1980s to call the Unix mag tape the Unix operating system, but that was just colloquial usage, not technically correct usage.
If you say linux, you are being factual and informative. If you say SuSE linux or redhat linux, you are being factual and informative. If you say gnu/linux, you are being political. I don’t like political propaganda. If I want to make political propaganda, I make my own political propaganda. I don’t want to parrot the factually incorrect propaganda of others.

Think of it this way:

Question: Are any gnu tools loaded into RAM when a linux OS is booted?
Answer: No.
Question: Do the gnu tools need to run continuously in RAM while a linux OS is running?
Answer: No.
Question: Would a linux operating system stop working if your removed the gnu tools?
Answer: No, except for the “ld” tool and a couple of other minor tools.

So it is clear that the gnu tools are not part of the operating system.

I’ll be more than happy to continue if you’d like 🙂


6 thoughts on “It’s still Linux, not GNU/Linux.

  • Michael B. Trausch

    First off, if you remove everything but the kernel, you will have nothing but a kernel panic. Secondly, yes, do look at other operating systems. Look at operating system definitions. By your argument, POSIX (Portable Operating System Interface for Unix) defines more than an operating system. However, it does not. It defines the interface that a POSIX-compliant operating system has, and a good part of the standard is quite impractical to implement at the kernel level. (This is why it’s pushed to userland; furthermore, pushing components to userland that can be in userland betters fits the Unix philosophy than not doing so.)

    In primitive operating systems, all of the things that we have as external utilities today were builtin commands. In primitive operating systems, all you have is the kernel and the shell; the API is part of the kernel, is limited, and is contained in memory. This was a bad thing, which is why every operating system that I know of today does not do everything in one or two core components. Why have code for “cp” in memory all the time if you do not absolutely have to?

    Now, consider a monolithic kernel with a multiserver kernel (a µkernel). In a µkernel, you gain even more flexibility: Parts that are useful to the operating system kernel are now also usable in userland. For example, if you have a µkernel that has several filesystem translators in use that provide filesystem services to mount filesystems, and they’re also user programs, a user can invoke “fst.ext4 directory owned-mount-point” and if the user has the privileges to read (and maybe write) the file, and can do r/w/x on the target directory, the filesystem translator can act on behalf of the user to make that filesystem available. If it crashes, it’s just an application crash and the kernel can restart it and heal itself, recovering gracefully. And the translator doesn’t link to the kernel at all (but it’s clearly required to access filesystems of various types while running under that kernel). I have every confidence in the world that people will make this argument then: “Of course a filesystem translator isn’t part of the filesystem. It’s just another application!” they will say. No matter what is said; filesystem access is always going to be something that operating systems provide: it does not matter what hardware privilege ring the filesystem driver is running in, whether or not the filesystem driver is always running, whether or not it is a user process or an unlinked object file that will be linked to the kernel with symbols resolved at runtime: that’s an operating system service.

    As an example, FUSE: Filesystem in Userspace. What is it? It is a kernel driver (for multiple operating systems) that exposes an API to userspace to do that, though on a monolithic kernel. This means that there is a wall between a FUSE driver implementation and the kernel module itself that some form of IPC has to be used to bridge. That doesn’t make FUSE filesystem drivers not part of the operating system; if you use a FUSE filesystem with a kernel module to mount filesystems, you’ve just extended the operating system to include running usermode, userspace application code to provide the OS service!

    Here we get to the real point: An operating system is a set of jobs, a series of primitive services, that application software running on that operating system expects to use. Just because you can swap components of the operating system as you like (you could, for example, port the OpenSolaris libraries and userland to the Linux kernel if you wanted) doesn’t mean that the operating system is limited to the parts that are (at present) irreplaceable. If you port OpenSolaris’ user stack to Linux, you’ll have an operating system alright, but nobody who “knows Linux” will be able to use it without learning about the vastly different suite of tools provided by OpenSolaris. Even the basic utilities all work different.

    By the way, on a lesser scale, Busybox? Yes, it’s a major component in an operating system targeted for low-memory, low-consumption, possibly embedded environments. It also does not provide services that are as featureful as the GNU versions; combined with a small C library like µClibc, and you have indeed changed the operating system completely. You will still have to port software to work on that stack.

    And I still say that you need to do some looking around and become very well acquainted with as many operating systems as is possible. Of course, if you’d really like to learn what is “operating system” and what is not, become a cross-platform programmer for a non-trivial project and notice everything you have to special case for every different type of operating system (and then realize that all those changes are special casing around things you would in your argument consider not to be operating system).

    Furthermore, to claim that the hardware that Linux runs on top of is part of the OS is absolutely absurd, and anyone that knows *anything* about technology should be able to tell you that. The operating system starts with a kernel. It certainly does not end there; not in today’s operating systems which are quite a bit more complex than I think you realize.

    • losinggeneration Post author

      First off, if you remove everything but the kernel, you will have nothing but a kernel panic.

      And if you have a program that consists of [cc lang=”c”]#include

      int main(int argc, char *argv[])
      {
      while(1)
      printf(“I am an OS!\n”);

      return 0;
      }
      [/cc]And compile that to /my_os then add init=/my_os to your kernel command line, it’ll print “I am an OS!” forever. Does that mean I just wrote a new OS? Because that’s the same place that the GNU userspace carries on. And by your previous logic, I did!

      Secondly, yes, do look at other operating systems. Look at operating system definitions.

      I’ve looked at other OS’s, that doesn’t really change the fact that the kernel is technically the OS, and everything else is typically “optional” or “replacable.” Which is exactly why you can pull the FreeBSD kernel out and throw a GNU userland on top of it. The userland isn’t the OS in monolithic kernels. In microkernels, you have more of an argument that the userspace drivers, filesystems, etc, are part of the OS since they’re still the parts that talk directly to the hardware. The GNU userland, on the other hand, doesn’t talk directly to the hardware, the kernel/OS does.

      My point about POSIX (why would you bother defining it when I already know what it is, and if people reading it don’t know what it is, they can’t have an opinion on it because they don’t know enough about the subject) was that POSIX defines an API abstraction so applications can be easily ported. GNU happens to do something like 90% of the POSIX standard. But, just because POSIX defines a certain API and userland, doesn’t make it an OS, or projects implementing POSIX an OS. Because, THE definition of an OS has nothing to do with POSIX or what other OS’s do/include. It too stands on its own, but in a very different sense that it’s the basis for UNIX like systems. Let me repeat in case I wasn’t clear, POSIX defines what a UNIX like system should be, not what the OS should be.

      Why have code for “cp” in memory all the time if you do not absolutely have to?

      Because cp isn’t part of the OS. It’s an application that makes calls to a C library, and the C libray makes the corresponding calls to the OS. So, cp->c library->OS (file system)->hard drive. In Linux, and most monolithic OS’s, that’s the typical path for application programs like cp. Even in a microkernel, it’d be a stretch to have programs like cp be part of the OS proper. Why? Because that means that cp now has to have an understanding of the underlying file system, and hardware. That’s why the OS abstracts that, even for microkernels. It just happens that the microkernel runs that portion of the kernel outside in the application ring (or it may still run in ring 1 or 2, I don’t really remember off the top of my head.) Regardless, the portion that actually talks to the hardware is the OS, and nothing more. Whether that application is in application space or kernel space. Let me repeat again in case you’re now confused by that (which I’ll asume you are) “cp” is not talking directly to the hardware in application space in Linux. It’s making API calls to the C library, which makes OS API calls, etc. Thus, “cp” is not part of the OS. (I’m repeating myself so in case you don’t understand the first time, maybe you’ll get it the second time. I’ll probably end up doing that often.)

      It also does not provide services that are as featureful as the GNU versions; combined with a small C library like µClibc, and you have indeed changed the operating system completely. You will still have to port software to work on that stack.

      Well, BusyBox compiles just fine on glibc. It just doesn’t provide a complete POSIX spec. It does however provide a good deal of the tools you’re used to in a POSIX environment. And, really, the porting to uClibc, is typically just recompiling. Unless you’re using some no-standard, or glibc specific functions, most things will compile without any (or much) change to the code to compile for uClibc vs glibc. There also may be parts of the C library that aren’t available, but the point being that a large portion is, and “porting” to uClibc, isn’t typically too much of a hassle.

      Furthermore, to claim that the hardware that Linux runs on top of is part of the OS is absolutely absurd

      Then why make claims that are essentially that? You use the exact same logic that GNU is part of the OS, so by your logic, AMD should also be part of the OS. Your logic is just being applied to show exactly how absurd it is. So no need to argue that, because that was exactly the point! And I do realize that OS’s are often blurring the line between what should be considered OS, and what shouldn’t. But most of that is just marketing. When it comes right down to it, the OS itself, only deals with the hardware (and usually scheduling.) By using that understood, technical definition of an OS, it’s typically not too hard to figure out what portions are OS, and what everything else is.

      • Michael B. Trausch

        You are missing some fine-grained, subtle points here. It seems to me that either you have never worked on an operating system or that you have decided to largely ignore history, I’m not sure which. You should study operating systems for a while. You will learn in the process that your claims do not make any sense.

        Your claim at logic application fails, because you’re explicitly ignoring an axiom that is the basis for the conclusion. An operating system requires a processor to run, but that does not mean that the processor is part of the operating system. It is configured in an kernel-specific fashion; NTOSKRNL.EXE configures the processor differently for typical operation than the Linux kernel does, for example.

        If the kernel is the operating system, then why aren’t programs written to run on the kernel? Why would programs be written to an operating system interface definition instead of the kernel itself? Your rationale is logically flawed.

        Let’s take the following statements as the assumed truths (axioms) here:

        * Hardware cannot be part of the operating system.

        * The operating system can define operational parameters of the hardware (and in fact, it must).

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

        Your example of a C program that goes into an infinite loop cannot be considered an operating system because it does not meet this definition. If you use that as the init process, the kernel will start up and it will spawn that single process, which will print to the console endlessly. What is being managed? What work is being done? None. It cannot manage anything, and it cannot operate anything besides whatever is statically linked into the kernel and the code being called as init. So, it cannot be an operating system.

        If you want to see a full operating system that uses Linux but not GNU, check out Android. Android uses a custom init process and system management tools, and provides an execution environment that is very different from what any application written for GNU/Linux or a real Unix-like system expects. Therefore it is a distinct operating system—it must be, because we would have to port to it to run applications on it. As I mentioned, the only thing it has in common with a desktop or server Linux-based system is the kernel.

        There is more than sufficient proof that a kernel by itself is useless; there is also more than sufficient proof that the userland component to an operating system is also useless. You would have people believe that the operating system is nothing but the kernel, but if that statement were indeed true, then programs do not have to be ported to new implementations based on different stacks. But that is a false statement, because an application would in fact have to be ported to Android to be useful and runnable there.

        I think that if you stop and look at the logic (and stop trying to extend it beyond its very necessarily constrained set of borders) you will get it.

        The statement “A kernel is an operating system” is only true sometimes; it is true in the case of simple operating systems like CP/M or MS-DOS or Apple’s ProDOS. I have a sneaking suspicion that you have used none of these systems, or that if you did, you never looked at their architecture. GNU/Linux (or Busybox and Newlib on Linux, or Android) do all the tasks that these primitive operating systems did, but on more complex hardware configurations and thus they require more management.

        My statement WRT “why keep cp in memory” doesn’t get the answer “Because it’s not part of the operating system.” It is of course part of the operating system to provide an interface for the user to be able to manipulate files! In the world of DOS, the shell did all of these things, making system calls on behalf of the user. Embedding commands into the shell in such a manner is a bad thing, as we have learned, and so we do not do it anymore. (Well, Microsoft still does, but they haven’t caught on to modular software development philosophy yet, not truly.)

        However, just because we don’t embed things like that in our shell does not mean that they are less a component of the operating system than they used to be.

        As to your “operating system”, and I use the term very loosely, what would make you believe that it could be? How is it at all useful? What does it do? What does it manage? How does it load and unload kernel modules? How does it manage the kernel? How does it manage subordinate processes (a key feature of any init system or any system which init delegates that feature to)? How does it do the things that an operating system does? It does not.

        The definitive answer on what is an operating system and what isn’t? I’m afraid that there just isn’t one. It has to be determined on a case-by-case basis, by looking at the system and coming to an informed conclusion. Alas, as long as you believe that a kernel is an operating system, you cannot yield to such a conclusion, because you do not know what an operating system is or does.

        Yes, that means that an operating system is something of an abstract concept. Welcome to computing: we abstract lots of things like that. I can assure you, though, it’s entirely possible to take a Linux kernel and build a new, incompatible operating system around it (and the same can be done with any kernel that isn’t a self-contained operating system, like DOS is). You can take NTOSKRNL.EXE and, with sufficient time taken to study that kernel and understand what it does, you can build a new operating system around it that is incompatible with Windows. It isn’t terribly difficult to do: just implement the rest of the operating system differently. Nothing in the existing Windows world will run unless your aim is to reimplement Windows on top of the NTOSKRNL.EXE kernel.

        • losinggeneration Post author

          You are missing some fine-grained, subtle points here. It seems to me that either you have never worked on an operating system or that you have decided to largely ignore history, I’m not sure which. You should study operating systems for a while. You will learn in the process that your claims do not make any sense.

          That’s actually how I formed my opinion. Reading books about OS’s (well, just one and part of another), and practical work with OS’s, and (mostly reading) the OS specific source code. The history of OS’s have said exactly what I’ve said and quoted about what the definition of an OS is. It’s a definition not up for debate. Deal with it, and use a different word. Although, I suppose if people are continuously misusing the term OS, the definition may change. Although, most every definition you’ve given has only differed slightly from what I’ve presented. Assuming that the definition is now this wishy-washy, basically anything is userland that’s required for day-to-day use (which BTW, changes depending on who you ask), this is a bad thing since it allows GNU to barge in and demand credit (sure, they should get credit, but demanding it be GNU/Linux really is a bit of stretch considering it’s a relatively replicable portion of the system.) Again though, that’s a completely different argument point. And I don’t even want to try debating that one since it’s strictly based upon what you vs others vs I want to consider an OS. (Are you starting to see why your definition of an OS leads to confusion, where the older, more established definition there was not a whole lot of room for confusion. Well, besides the fact that they decided to let the terms kernel and OS be interchangeable, which is how this whole mess got started to begin with!)

          Your claim at logic application fails, because you’re explicitly ignoring an axiom that is the basis for the conclusion. An operating system requires a processor to run, but that does not mean that the processor is part of the operating system. It is configured in an kernel-specific fashion; NTOSKRNL.EXE configures the processor differently for typical operation than the Linux kernel does, for example.

          Well, because you didn’t quote which part of my argument fails, and I’m too lazy to figure out exactly where you’re talking about, this statement goes to /dev/null unless you’re more clear as to which statements you’re referring to.

          If the kernel is the operating system, then why aren’t programs written to run on the kernel? Why would programs be written to an operating system interface definition instead of the kernel itself?

          Do you even code yourself? Because you should know the answer if you did. It’s for (source) portability and nothing else. You can do system calls directly (AKA, writing a program to run on the kernel), but instead, you abstract that to a C library (which has to be ported to use your OS’s system calls.) So, instead of doing all your system calls directly to the kernel, and being completely non-portable, the ported standard C library takes care of the OS specifics for you. That is why you don’t write your code to interface directly with the OS (but you could.)

          Need more proof? Let’s look at the graphics stack for Linux. At the lowest level you have the hardware, after that you have a kernel DRI driver, on top of that you have the DRM, then you have the Gallium3D API which has different state trackers for OGL, OVG, etc. (I hope I didn’t screw that up, or too over simplify it.) Anyways, the DRI and DRM are part of the OS because they deal with handling the hardware and managing the memory. The OGL API is in userspace and not part of the OS. It takes the OGL API, and sends that on its way to the DRM, which decides where in memory to place things, then tells the DRI what it should be doing. This is very consistent with everything I’ve said to this point. The portions that control the hardware are in the Linux kernel/OS, and the portions that don’t, aren’t.

          Let’s take the following statements as the assumed truths (axioms) here:
          * Hardware cannot be part of the operating system.
          * The operating system can define operational parameters of the hardware (and in fact, it must).
          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).

          Yes, with the exception of the very last little bit about utilities, that’s also consistent to what I’ve said. It deals directly with the hardware (the only thing added is that it deals with processes, which is what Linux itself does, and the incorrect portion about the utilities.)

          Your example of a C program that goes into an infinite loop cannot be considered an operating system because it does not meet this definition.

          Yes, and GNU doesn’t either. It spawns processes, but the actual process management and spawning ends up being done by Linux and not GNU.

          If you use that as the init process, the kernel will start up and it will spawn that single process, which will print to the console endlessly. What is being managed? What work is being done? None. It cannot manage anything, and it cannot operate anything besides whatever is statically linked into the kernel and the code being called as init. So, it cannot be an operating system.

          Again, init (and GNU) do not manage anything either. They spawn processes and let Linux handle how it’s managed. Why do you think you have Linux has things like “Preemption Model” and “Multi-core scheduler support”? It’s because Linux handles the system processes. With things like “top,” “kill,” and others you can tell Linux to stop processes, and shells can tell Linux to spawn processes, but that’s much different then handling and running the processes itself. Again, that’s why it’s Linux and not GNU/Linux because GNU isn’t the OS when run in conjunction with Linux.

          If you want to see a full operating system that uses Linux but not GNU, check out Android.

          Shortened because I have no desire to repeat myself yet again.

          There is more than sufficient proof that a kernel by itself is useless; there is also more than sufficient proof that the userland component to an operating system is also useless. You would have people believe that the operating system is nothing but the kernel, but if that statement were indeed true, then programs do not have to be ported to new implementations based on different stacks. But that is a false statement, because an application would in fact have to be ported to Android to be useful and runnable there.

          Again, you’re talking about a standard API and not a standard OS. The more common POSIX isn’t an OS, but an API and UNIX userland standard.

          I think that if you stop and look at the logic (and stop trying to extend it beyond its very necessarily constrained set of borders) you will get it.
          The statement “A kernel is an operating system” is only true sometimes; it is true in the case of simple operating systems like CP/M or MS-DOS or Apple’s ProDOS. I have a sneaking suspicion that you have used none of these systems, or that if you did, you never looked at their architecture. GNU/Linux (or Busybox and Newlib on Linux, or Android) do all the tasks that these primitive operating systems did, but on more complex hardware configurations and thus they require more management.

          Well, using your logic, the borders actually aren’t very constrained at all. Using my logic, the borders are very very constrained. I don’t really know what else to say. DOS’s architecture was basically (originally) only able to spawn one process at a time IIRC. So yes, I actually do know about at least DOS’s basic architecture. Most things to get to the actual hardware are dealt with via interrupts directly. It actually was an extremely bare bones OS.

          My statement WRT “why keep cp in memory” doesn’t get the answer “Because it’s not part of the operating system.” It is of course part of the operating system to provide an interface for the user to be able to manipulate files! In the world of DOS, the shell did all of these things, making system calls on behalf of the user. Embedding commands into the shell in such a manner is a bad thing, as we have learned, and so we do not do it anymore. (Well, Microsoft still does, but they haven’t caught on to modular software development philosophy yet, not truly.)

          However, just because we don’t embed things like that in our shell does not mean that they are less a component of the operating system than they used to be.

          Well, again, the shell isn’t part of the OS, it’s part of the POSIX specification.

          As to your “operating system”, and I use the term very loosely, what would make you believe that it could be? How is it at all useful? What does it do? What does it manage? How does it load and unload kernel modules? How does it manage the kernel? How does it manage subordinate processes (a key feature of any init system or any system which init delegates that feature to)? How does it do the things that an operating system does? It does not.

          So would it be better if I did a forks that spawn a child process, that then exec’s another command /iamos ? Then it’d have process control, so that would be more or less exactly what your definition is above. Or, if instead of writing output, it copied files around? I say that because you’ve previously disliked the fact that it doesn’t do anything useful.

          The definitive answer on what is an operating system and what isn’t? I’m afraid that there just isn’t one. It has to be determined on a case-by-case basis, by looking at the system and coming to an informed conclusion.

          Scholars have already defined what an OS & kernel are, why are you trying to redefine them in vague terms? The definition has been around for no less than 20 years.

          Alas, as long as you believe that a kernel is an operating system, you cannot yield to such a conclusion, because you do not know what an operating system is or does.
          Yes, that means that an operating system is something of an abstract concept. Welcome to computing: we abstract lots of things like that.

          I’ve already given you the established definition for an OS, so it’s not I, but you who do not understand what an OS is.

          I can assure you, though, it’s entirely possible to take a Linux kernel and build a new, incompatible operating system around it (and the same can be done with any kernel that isn’t a self-contained operating system, like DOS is). You can take NTOSKRNL.EXE and, with sufficient time taken to study that kernel and understand what it does, you can build a new operating system around it that is incompatible with Windows. It isn’t terribly difficult to do: just implement the rest of the operating system differently. Nothing in the existing Windows world will run unless your aim is to reimplement Windows on top of the NTOSKRNL.EXE kernel.

          Well, considering you seem to think you’re an expert, you should know that NTOSKRNL.EXE isn’t the only portion of the kernel in Windows. Because it’s not a monolithic OS like Linux, it has other portions which are still considered part of the kernel (similar to Minix or Mach, but to a lesser extent than those microkernels.) But from your comment there, it makes me wonder if you knew that…

          • Michael B. Trausch

            Uhm, alright, so your last paragraph alone is enough reason not to read the whole thing.

            You are acting like there is something arbitrary about what there is to an operating system in the abstract. It simply isn’t that way. Sure, I suppose if that’s what you want to believe it makes conversations easier. But any way you slice it, a kernel is utterly useless without the rest of the operating system. Show me a kernel that runs by itself; surely I can use it directly if it is a whole operating system.

            Even DOS requires a shell.

            In most embedded operating systems, the “shell” is a kiosk sort of thing.

            As to whether or not I code, you can look me up on the Internet for the answer, if you’d like. And that’s just the free software things I’ve worked on. I don’t expect you care about the rest, but I do a lot of work in programming and administration as a freelancer.

            As far as you’re too lazy to figure out what I was talking about, well, that sounds like a personal problem. But I was talking about your absolutely absurd claim that a CPU can be part of an operating system. A CPU can be tailored for an operating system (or even an operating environment!) but it is hardware, and operating systems are software. Period.

            You say that using the proper definition of what an operating system is leaves it to every individual as to what is part of the OS or not. You are again absolutely incorrect here—and I honestly do not see how you can say that. If you remove something, and your operating system no longer works, then it was obviously required for the operating system to function. If you take away X11, the operating system still works.

            Your argument makes the implication that there is nothing special about any of the programs that are installed in userspace. It ignores the historical fact that much of the operating system facilities that used to be built-in to the kernel are now part of the userland and are generally more useful that way (but are no less a part of the operating system than they were when they were built in).

            In biology, there is a particular thing that is considered to be a “model lifeform” for study—the fruit fly. I submit that DOS is a model operating system, much the same way that a fruit fly is a model biological system. You’d do well to study it; it was from a time when operating systems were simpler. If you do that, you’ll start to realize the fallacy that you’re committing by stating that the operating system is just the kernel.

            Proof that the operating system is the kernel: Format a DOS floppy with system on it, and then remove the shell. Boot it. It will fail.

            Further proof of the same: Build yourself a monolithic Linux kernel and then boot it without any init or any supporting userland. It will panic.

            As to your claim that NTOSKRNL is not monolithic in nature, I’d absolutely love to see where you got that notion. While some of its design is borrowed from the general concepts and notions of microkernel design, the kernel is not itself a microkernel. All system things such as drivers all are executed in the context of the kernel, not as independent user mode processes as would be done in a true microkernel.

            Further, creating a program that forks and execs to do nothing still accomplishes nothing. Just what do you think it is the job of an operating system to do anyway? Sit there and look pretty? Sure sounds that way.

            Maybe you should see what the Linux kernel’s boot up process looks like? The boot loader loads the operating system’s kernel and initial ramdisk and then jumps into the kernel, which initializes itself, hardware, and then spawns process ID 1: the init process. The init process then reads system configuration somehow (this is dependent on what sort of init implementation is used). The init process then brings up the rest of the operating system, indirectly, running shell scripts which in turn run operating system utilities that configure networking and so forth. If you remove all of that, you have a system that can boot and then panic. It can do nothing; the operating system is incomplete! This makes perfect sense: an incomplete operating system cannot operate. It’d be useless.

            While the process of determining what is included in an operating system does differ for each operating system, and does differ drastically between even Linux-based systems, it’s not arbitrary. Either the system works, boots, and manages hardware and software resources such as application software and its associated requests, or it doesn’t. It’s really that simple. If you take the wrong pieces out of the equation, then you’ve nothing left but a heap of blocks that do not fit together and cannot be used.

            Note that I am not talking about what an end-user thinks an operating system is. Nor am I talking about what some hobbyiest thinks an operating system is. I’m talking about simply what is. But no user can use an incomplete operating system, because it is impossible to do. There *has* to be userland software that supports the kernel, or the kernel cannot do its job. That’s why it’s called a kernel and not, say, a nut. Feel free to look up what a kernel is. Hell, look that up on Wikipedia, with all the context of operating systems. It even says:

            In computing, the ‘kernel’ is the central component of most computer operating systems.

            If a kernel IS the operating system, then how can it be only the central component, hrm? Oh, read on to figure out what makes a kernel monolithic vs. µkernel. It’s not about the design, it’s about the address space.

            At this point it is clear that you no longer care about the argument (assuming that you ever did) and that you wish to come away having learned nothing. You make claims that are more and more absurd in nature and now you’re trying to twist things to fit your own warped view and say that I’m saying things that I’m not. It’s patently absurd, and we’ll just leave it at that.

          • losinggeneration Post author

            Uhm, alright, so your last paragraph alone is enough reason not to read the whole thing.

            That makes it sound like you didn’t even bother to take the time to read my last rebuttal. (I assume you did, or at least cherry picked out what you wanted.) If you don’t want to discuss this, fine. But at least be courteous about it. I tried to put a lot of thought into 90% of that last comment. The last 10% was rushed because I was wanting to leave work. Perhaps I should have sent what I had up to that point to myself and finished at home. I didn’t and perhaps it was a mistake. Sorry if I came off as a jerk in that last paragraph, it really wasn’t my intention.

            You are acting like there is something arbitrary about what there is to an operating system in the abstract.

            I never said it was, I thought I stated a very clear definition of what an OS is from The Design of the UNIX Operating System by Maurice J. Bach

            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.

            I have never once said it was arbitrary what is the OS. I’ve always maintained the argument based around that definition (if I was coherent and expressed that with clarity is another topic entirely.)

            As to whether or not I code, you can look me up on the Internet for the answer, if you’d like. And that’s just the free software things I’ve worked on. I don’t expect you care about the rest, but I do a lot of work in programming and administration as a freelancer.

            I’m guessing this was triggered by the last paragraph, sorry again for that one, I should have been more careful about what and how I said it (if I could take it back, I’d at the very least remove that first sentence from the last paragraph.) And I did go ahead and do a bit of Googling for you. You hate censorship, enjoy wikipedia, and have a project called AllTray which in a nutshell, sends any program to the systray.

            As far as you’re too lazy to figure out what I was talking about, well, that sounds like a personal problem. But I was talking about your absolutely absurd claim that a CPU can be part of an operating system. A CPU can be tailored for an operating system (or even an operating environment!) but it is hardware, and operating systems are software. Period.

            Again, this was at the end of the day, and it was/is a personal problem. After a long day of work, I really didn’t feel like trying to figure out where you were talking about (and if I were to have to guess, it looks like I would have guessed wrong.)

            Anyways, you sort of missed the point of using that as an argument. It’s like using the exact same logic people do for GNU/Linux, just in a different way. As in: You’re saying Linux cannot work without GNU, therefore GNU is part of Linux (which is implied whenever you type something like GNU/Linux.) It’s the exact same argument I made. While the GNU argument is more subtle, it still wrong. My argument was (quite purposefully) obviously absurdly wrong. But they’re using the same logical argument, just in very different ways.

            You say that using the proper definition of what an operating system is leaves it to every individual as to what is part of the OS or not

            No, the definition I provided leaves little to no interpretation to what the OS is. I’ll say it again, if it doesn’t interact directly with the hardware, it’s not part of the OS. “cp”, “ls”, etc do not interact directly with the hardware, so they’re not part of the OS. (They interact with the OS, not the hardware, which is the distinction I’ve been trying to get across.)

            You are again absolutely incorrect here—and I honestly do not see how you can say that. If you remove something, and your operating system no longer works, then it was obviously required for the operating system to function.

            It hlts because the developers assume you want your OS to do something useful. It’s not a requirement of an OS. I discuss this a bit more later on. So stay tuned 🙂

            As to your claim that NTOSKRNL is not monolithic in nature, I’d absolutely love to see where you got that notion.

            http://en.wikipedia.org/wiki/Microsoft_Windows_7

            NT takes a middle ground to being monolithic and micro. Thus, it’s not quite micro kernel, and it’s not quite monolithic.

            Further, creating a program that forks and execs to do nothing still accomplishes nothing. Just what do you think it is the job of an operating system to do anyway? Sit there and look pretty? Sure sounds that way.

            Again, an OS doesn’t necessitate usefulness. Perhaps you should reread:

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

            Yep, nothing about being required to be useful. In every definition of an OS we’ve put out there so far, not a single one says anything about being useful to a(n end) user. Anyways, what I was talking about seems to fit pretty well into that definition you’ve put forth. So please tell me a real reason why it’s all of a sudden disqualified and GNU isn’t. The definition I’ve put forth, OTOH, says neither my nonsense program, nor GNU are OS’s, and that Linux would be the OS, and those two are just programs that can be executed in the user land.

            Maybe you should see what the Linux kernel’s boot up process looks like? The boot loader loads the operating system’s kernel and initial ramdisk and then jumps into the kernel, which initializes itself, hardware, and then spawns process ID 1: the init process. The init process then reads system configuration somehow (this is dependent on what sort of init implementation is used). The init process then brings up the rest of the operating system, indirectly, running shell scripts which in turn run operating system utilities that configure networking and so forth. If you remove all of that, you have a system that can boot and then panic. It can do nothing; the operating system is incomplete! This makes perfect sense: an incomplete operating system cannot operate. It’d be useless.

            Init is just customary, not required. You can call any program you want. Be it /bin/sh, /my_super_cool_code, or whatever. If you do choose to use /bin/sh, you’re dropped to a shell. Any other program will execute normally. After Linux is done initializing, and sees it has something to load (because you’re right, it wants something) Linux is more than happy to run anything as PID 1. Usefulness (to a user) doesn’t matter, at that point, the OS is completely booted, and you can make any system calls you want to communicate with the hardware (via Linux.) If you’re really that concerned with usefulness, take my stupid example program with a grain of salt. The fact of the matter is, when that program gets executed, the Linux OS is at a usable state. It’s just that what I do with it isn’t usable (to a user), but the Linux OS itself is usable (otherwise I wouldn’t be able to even write output to a console.)

            If a kernel IS the operating system, then how can it be only the central component, hrm? Oh, read on to figure out what makes a kernel monolithic vs. µkernel. It’s not about the design, it’s about the address space.

            Because, the kernel (or OS) only cares about the hardware and nothing else. The means by which your kernel abstracts it, doesn’t matter. Which is why the drivers that deal directly with the hardware, is part of the kernel/OS regardless of where in address space they’re included from. With this definition, it takes care of both micro and monolithic kernel/OS’s. As I’ve tried to show, with a Linux OS/kernel, the only thing that is required is Linux itself (with the one exception which we’ve already discussed.)

            At this point it is clear that you no longer care about the argument (assuming that you ever did) and that you wish to come away having learned nothing. You make claims that are more and more absurd in nature and now you’re trying to twist things to fit your own warped view and say that I’m saying things that I’m not. It’s patently absurd, and we’ll just leave it at that.

            I’ll apologize one last time, and if I make a jerky comment, call me on it, and move on with the discussion. I slip up sometimes (as have you) in keeping the conversation tactful. I don’t know about you, but I’m not perfect and more than willing to admit when I make a misjudgment or mistake (damn you last paragraph haunting me still.) So please, carry on with the discussion if you’d like, if not, at the very least, I’d like to ask that make one last comment saying you (still) have no interest in continuing this conversation.

            P.S. I tried to put quite a bit of time and thought into this and tried to be as non confrontational with this comment as possible. It was required to censor myself in some places, and rework how I said others statements to try to achieve that goal. I hope it comes off that way this time.

Comments are closed.