This guest column by Kevin Dankwardt originated as a talkback to the LinuxDevices.com article entitled “What is Linux?”

What an apt question! I remember this question being asked, of one of the speakers, at the ELEC (Embedded Linux Expo & Conference) by the gentleman sitting next to me. It wasn't answered then too well, either. I'd like to add my 2 bits worth. I think asking the question “what is Linux” is important because of the issue of “forking” that concerns many of us. To get a little scholastic here, we want to know the definition of Linux to avoid ambiguity.

It's like the story by William James about an argument over whether a man “goes round” a squirrel. A man is on one side of a tree with a squirrel opposite of him. Whenever the man moves around the tree a bit, the squirrel moves an equal amount always staying opposite of the man. The man eventually moves all of the way around the tree. The question then is “did the man go round the squirrel?” The answer depends on one's definition of “go round”. If one defines it to be to the north of, to the south of, to the east of and to the west of, then the man went round the squirrel. On the other hand, if the definition is that to go round the squirrel the man must be at some point on the squirrel's left, on it's right, in front of it, and behind it, then the man did not go round the squirrel.

Now, it may be quite valuable to promote one's product as one that “goes round the squirrel.” Does HardHat Linux “go round the squirrel” when they change a small piece of the kernel like including their own scheduler? Does RTLinux “go round the squirrel” when it manipulates how interrupts are handled yet pretty much allows the kernel to perform as usual? Does one's version of Linux “go round the squirrel” when you port it to a new processor?

Consumers of Linux distributions want to know what they are getting. Are they going to be dependent on the distribution they choose? Are these dependencies in the kernel or just on software outside of it? I think that most consumers will want to be able to keep up with new versions of Linux. Will the differences in the distribution they choose be kept up-to-date?

I think what we want is a standard. With a standard vendors can then be asked to clearly explain how they differ. The problem is, I think most people would agree, is that it's too early to adopt a standard for a “Linux Distribution”. For the kernel, though, we do have a clearly defined standard. The standard is what Linus releases. Interestingly, that means there are literally hundreds of standards since there have been hundreds (I did a little counting on www.kernel.org) of versions, or minor versions, of the Linux kernel.

The mechanism that the GPL mandates for making changes is quite useful. The vendor is to supply you with a patch. Humans can actually read Patches. But, it can be hard work, just like reading code. It's like working without out man or info pages.

If a vendor has code in its kernel that is not in a release from www.kernel.org then its valuable to be told what that code is. Tell us in a way that helps us understand our commitment. Such distributions are not Linux anymore, but they are a Linux distribution if they have any Linux kernel code at all.

From the perspective of a developer, any change to the kernel presents the possibilities of incompatibilities. Even a simple patch can change the behavior of an application. In, fact, that's the point. Would NASA apply a patch without thoroughly investigating and testing? (no snickers, please!) A patch makes the kernel different. If its different from what Linus releases, then in my simple, yet unambiguous, definition it's no longer Linux.

If a vendor patched a kernel and didn't tell you would you have an issue with that? So we have the situation of vendors then having to come up with a name for an unpatched kernel to distinguish it from a patched one. Some say “pure Linux” — perhaps we should start with Linux, and make distinctions away from that.

Finally, I'd like to point out, like Tim Bird noted, we can view this as speciation. In computing, I think, just like in nature speciation occurs most rapidly when a species encounters a new environment. Embedding of Linux is a new environment and should be expected to cause rapid evolution. Whichever species survive will be decided by the life and death decisions of customers. Like in the natural world, new creatures may quickly die off because they do not receive the support they need to sustain life.

I think part of the important role that, sources of information like linuxdevices.com and outside consultants such as myself, play is to help to establish taxonomies* that customers can use to better understand the strengths and weaknesses of any particular distribution for use in a given ecological niche. We should expect vendors to continue to define Linux, and other valuable adjectives such as “open source”, in ways that fit their message.

* Incidentally, the man called the “Father of Modern Zoology” and famous in part for his binomial nomenclature of plants and animals was Carl von Linne' (sometimes spelled Linneaus). So we may want to develop a Linneaus Linus Linux naming system for variants of Linus' Linux system. ;-)

---

Author's bio: Kevin Dankwardt is founder and President of K Computing, a Silicon Valley training and consulting firm. He has spent most of the last 9 years
designing, developing, and delivering technical training for such subjects as Unix system programming, Linux device drivers, real-time programming, and parallel-programming for various organizations world-wide. He received his Ph.D. in Computer Science, in 1988. He may be contacted at [email protected].

---

Related story:
“What is Linux?”

Do you have a question or comment on this article? talkback here

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.