a long rebuttal to the Linux-is-the-engine fallacy (was: Re: that old GNU/Linux argument)

[Alexandre Oliva]

On Jul 24, 2008, Marko Vojinovic <vvmarko at panet.co.yu> wrote:

> As far as I know, the purpose of a kernel is to abstract the hardware layer 
> from the userspace software (this is of course an oversimplification, but I 
> believe it is sufficient for making the parallel).

Yup.  In fact, there are several layers of abstraction at work here.
I don't see anything that makes this particular layer of abstraction
any more special or relevant than others.  So that remains to be
justified, especially in the light of:

> the kernel "does the essential work" (actually, it communicates
> further to the hardware that does the actual work, but that is
> abstracted out).

Nevermind that what you "essential work" here is hardly perceived as
such by users.  What do they care that there are multiple CPUs there
that need a task scheduler, or how files or even filesystems are laid
out on disk, or how interrupts and DMA are handled?  They just want to
browse the web, read their e-mail, play their movies and songs, write
their texts, prepare their presentations, perform their
High-Performance computations, run databases, serve out files, etc.
*That*'s the essential work for *them*.

The kernel, like so many good administrators, works behind the scenes,
imperceptibly, doing work that others perceive as irrelevant, but that
is indeed very important for the whole system to function, but that is
most definitely not the end goal of the system.

I'd concede to qualifying it as *an* essential part, but not as *the*
essential part.  In good teams, every member performs an essential
task, and if you take any member out, the team gets a severe hit and
may even become completely dysfunctional.  Every member of such a team
might claim to be the most important, because his/her removal would
have such a severe impact, but the conclusion would be that *all* of
them are *the* most important, and this doesn't make sense.  I don't
think that this is the kind of measuring stick we're looking for.

> The parallel is simple --- the car engine is also the one "doing the
> essential work" (converting fuel to mechanical --- ie. usable ---
> energy).

Converting fuel to mechanical energy is hardly what most people who
purchase a car are interested in.  In fact, I'd say that if someone
purchases a car and get just an engine, and customer support goes
"hey, the engine is the essential component of a car; Marko Vojinovic
says so" it wouldn't get very happy customers.

Very few people actually care that there is an engine in their car.
Or a motor.  Or both, for hybrids.  Or propellers, jet propulsion,
magnets and superconductors, magic powder, whatever.

Converting energy is not the purpose of a car, and it's hardly even a
relevant part of the user experience.  People buy cars to drive to
places, not to convert fuel to mechanical energy.  People expect cars
to have some steering and speed controls, seats, lights, and that's
about it.

Which is not to say that the engine is not relevant for today's cars.
It is indeed very important.  But, as you said yourself, many
components are so important for a car to work that, if you take them
out, it won't work any more, and the engine is not a part of the user
experience that the user cares about.  So how can we support the claim
that the engine is the most important part?

Or, avoiding any imperfections introduced by the analogy, how could we
support the claim that Linux is the most important part of a system of
which it is a kernel?


> Consider a simple situation --- take a Fedora distro, and remove all
> GNU utilities. The system will lose much of its functionality, but
> not all.

Do you have any evidence to support this claim?  I very much doubt it,
and I invite you to give that a try.  I get the impression that you
don't have the faintest idea of how extensive the GNU project is, and
how extensive the reliance of the whole system on GNU software is.
You wouldn't wave it away so easily if you did.  Please "show me the
code", as I'm sure you heard before, most often without the 'please',
given the, erhm, source :-)

> Some hypothetical userspace program could still be able to
> communicate to the kernel and do some useful work.

Indeed, you could boot up the kernel and have it run this hypothetical
program as init.  Nevermind the details of how you actually managed to
compile, assemble and link this program into something that can issue
system calls without GCC, GNU as, GNU ld and GNU libc.

For the sake of the argument, let's assume you coded it by hand, in
binary, directly into an ELF static executable, or that you used some
other toolchain, and some other library that is far more limited but
that serves your purpose.

Great, it can probably do some useful stuff, such as printing Hello
World, running a firewall or, to cite the example of the engine,
converting electrical energy into heat.  Or rather getting the
microprocessors to do that because, you know, it's not the kernel that
actually dissipates power, this actually happens several layers down
in the abstraction stack.  If you get a cluster of machines running
Linux and this hypothetical program of yours (combined with this
library it depends on, if any), you'll have a very good (and
expensive) furnace :-)


Now...  Would anyone still recognize that as this system we're talking
about, that people mistakenly call Linux?  Would a kid on Jurassic
Park, looking at such a system, shout "hey, that's Linux!"?  I doubt
it.

Oddly, this would be one of the rare circumstances in which this
assessment would have been correct and fair.  And, even more oddly,
this system would be missing nearly every major feature of what people
recognize as features of this system, just like an engine by itself
would be missing nearly every major feature of what people recognize
as features of a car.


== Defining features

So let's think for a moment (or many moments) about what the defining
features of this operating system are, what the common features shared
by most recognizable instances of it are.


One could start from the upper layer, since that's what's most visible
to typical users.  Applications such as OOo, Firefox, Thunderbird,
etc, and servers such as bind, Apache http server, MySQL, Samba and
Sendmail, are hardly defining features of GNU+Linux systems.  They run
on many other Unix-like systems, and some of them run even on
Unix-unlike (dislike? :-) systems.

Besides, although some of them are obvious leaders in their
categories, even for those there are readily-available alternatives,
so even those who need that major feature won't necessarily run these
specific programs.

Thus, while these are no doubt very important for the users that rely
on them, they're not defining features, that make these systems what
they are, that set them apart from other systems.


Going down one layer in the graphical applications, we could go for
say Gnome.  This one happens to be part of the GNU system, and an
important part of it.  However, as users and developers of KDE, XFCE,
WindowMaker and of various other low-footprint desktop and window
managers would promptly argue, Gnome is not an essential part of the
system, as in, you can refrain from installing Gnome components and
nobody would dispute it's not a distribution of this system we're
talking about.

And then, again, Gnome, KDE and others do run on other Posix systems
as well, so you can't just look at a screenshot of either one and have
any certainty whatsoever that it's "our" system.


One layer below that is the X Window System.  Ok, ok, you on the back,
there are gtk+ and qt and others in between; the same arguments as
those to Gnome and KDE apply, so I won't go into that for the
(futile?) sake of brevity :-)

X was originally designed for Unix systems, long before such a thing
as POSIX was even a theoretical plan, so claiming it to be a defining
feature of our system would be quite a twist.  Heck, it preceded the
start of the GNU project for several years, and thus Linux for an even
longer period.

When the GNU system was deciding how to go about graphical user
interfaces, it found that X11 was there, was available, and was under
suitable terms.  So the rest of the GNU system was designed to use it,
like a number of other smallish components that spared the GNU
developers from a bit of the total effort.

Evidently, X can't be a defining part of GNU, let alone GNU+Linux
(even if you call it Linux), since by looking at it you can't tell
what's the operating system underneath.  It runs on so many of them!

And then, for people who run the relatively common headless servers,
for their remote administrators, and for the relatively atypical user
who most often stick to textual-interface applications, X is mostly,
when not completely, replaceable by the CLI.


Going by the same reasoning of availability on other Unix-like
systems, we could take out most of the other programs, applications,
scripting languages, CLI interfaces, and even libraries.  Nearly all
of them will run perfectly well on top of other systems.  GNU libc
will run perfectly well on top of other kernels.


Some might be tempted, at this point, to claim victory for Linux, as
the last standing component, and conclude that it is the defining
feature of that system, even though we'd already established that it,
by itself, wasn't even recognizable as the system.


But wait!  Taking the same reasoning we used to discard applications
on the other end of the spectrum (that they could be easily replaced
by alternatives) and other components all the way down, and taking the
very argument we used to discard GNU libc as a defining feature (that
it could easily target other kernels), we'll realize that Linux is
also replaceable and retargetable.

Indeed, you can just put another kernel in its stead, and pretty much
nobody will even notice a difference.  Furthermore, you can use it
along with uClibc and newlib, or in the scenario of the library-less
init proposed several pages above.  (hey!, the subject said *long*,
you were warned :-)

The only reason we got the impression that Linux might be a defining
feature is that we went top-down, so we looked at it last.  Had we
gone the other way, we'd have discarded it first, and at the end,
should we cut the reasoning short (IOW, stop thinking when we reached
an answer we found satisfying), we'd conclude that OOo, Firefox and
Apache http server are defining features of our system.

Unsurprisingly, some people do present this argument, and even defend
it as if it made any sense.  But it makes just as much sense as
concluding, from this reasoning, that Linux is the defining feature of
our system: none whatsoever.


However, if we do not stop thinking just because we found an answer
we're happy with, we're left with *nothing* as a defining feature.
That's absurd, so something in the methodology we used must have been
wrong.  We must have been asking the wrong question, since the answer
we got was 0, rather than 42 :-)


== Impact of replacement

It should be clear at this point that there's no single program or
feature that defines the system.  Like many complex systems (or
teams), it is a set of components, some essential for most, some
redundant but still essential for very many, and some clearly less
relevant.

So I propose that, instead of going about trying to determine one
single component that makes the system what it is (we've already
failed at that), we look at the system as a whole (as fuzzy as "whole"
is defined), and then try to determine what impact, if any, the
replacement of any of the components would have on a statistically
significant sample of users of the system.

The assumption being that, the larger the impact of replacing that one
component, the further the system becomes notably different from what
it is.  IOW, a component that, if replaced, would make the system
"very different" for "many users" would be regarded as more defining
than a component that, if replaced, would hardly raise an eyebrow from
any user.  The more you (or rather many users) can tell there was a
difference, the more defining the component is.


So let's start again from the top.  Desktop applications, as important
as they are, are hardly irreplaceable.  In fact, the efforts of Gnome
and KDE have pretty much ensured that, for every major need of desktop
users, there are at least two major applications that can fulfill that
need.

Of course there are minor variations in the feature of set of each
application.  Of course in some cases that are multiple overlapping
applications that target the same desktop environment, and even some
that aren't part of either.  This means the impact of replacing say
OOo with Abiword+Gnumeric+etc or KOffice, Firefox with Epiphany or
Konqueror, Thunderbird with Evolution or KMail, etc, could affect a
large number of users, but that it is unlikely to remove an essential
feature for a large fraction of the total number of users.

Likewise Desktop environments.  They would definitely be missed by
users who prefer Gnome over KDE or vice-versa, or those who prefer
lighter-weight desktop/window managers, but an average user would
hardly feel the system to be fundamentally different, or even totally
unusable, when playing with say a Gnome-only or KDE-only LiveCD
release of our system.


Now, the X Window System is much trickier to replace.  In spite of its
being a relatively small portion of the entire system, the
unavailability of a GUI, that depends entirely on it, would have a
major impact on most users, and there's no viable replacement for X
that I'm aware of.

Sure, one could list various forks of X, but these all have the same
heritage, so I wouldn't count them as actual replacements, certainly
not complete replacements.  They're more like variations, in a way
like different major versions of Linux, or say Linux vs uClinux, or
perhaps one *BSD vs another (-ENOCLUE for this last one, but I'll take
the risk and assume they do have a large shared heritage; apologies if
it is not so and someone takes offense at the implications :-)

Even headless-system administrators (note the dash, angry headful but
attentionless sysadmins! :-) would miss the ability to use X
applications tunneled over SSH every now and then.

Hard-core 100% VT "why would I ever want all this fscking xorg-* junk
on my disk (or some even more, erhm, polite wording)" users are very
rare, so we can count X11 as a highly-defining feature of the system.


Database, smtp and http servers, there are several.  Sure enough
having to drop say PostgreSQL, Sendmail or the Apache http server and
use some other server in their stead would be a pain for people with
highly-customized scripts or configurations.  But users with high
customization levels *and* inability to obtain required features from
other similar servers are probably the exception, rather than the
rule.

SMB and NFS servers are a bit harder to replace, but then again,
although they're certainly essential for a significant number of
users, missing them would turn the system into "something else" or
into "unusable" for no more than a small fraction of the total number
of users in our sample.


Now, let's have a look at GNU software.  All of it!  I don't mean
GPLed software (many are not GNU software, e.g. Linux itself, and not
all GNU software is GPLed), I don't mean all software that is regarded
as Free Software (yeah, GPLed is not the same as Free Software is not
the same as GNU software), I mean the programs that are available from
ftp://ftp.gnu.org/pub/gnu/, or listed there as part of the GNU system
but offered for download elsewhere.  These are the components of the
GNU system.  It's a *lot* of software.

What if we set out to replace it all?  Well, we'd have a lot of work
ahead of us.  Sure enough, replacing one component or another
shouldn't be too hard.  You could use newlib or uclibc instead of GNU
libc, for example, although these are quite feature limited, for their
focus on embedded systems, and so much software will fail to run on
them, for depending on features that are missing or incomplete on
them.

You could use some other toolchain to rebuild everything with this
other library, but you'd probably find out a significant amount of
build machinery requires features from GNU make, GNU Compiler
Collection (GCC), GNU ld; sometimes their build scripts also depend on
GNU bash, GNU awk and GNU sed extensions or quirks.  And then, some
program's source code relies on extensions present in GNU CC, GNU
libc, GNU as and GNU ld.  Patch, patch, patch.  Would the result of
all that work be Apach[ey] operating system? :-)

Once you replace GNU bash, GNU coreutils, GNU awk, GNU sed, GNU grep,
GNU find, you'll certainly find out that a lot of software breaks.
The system might even fail to boot up, since so many of the rc scripts
used on this system we're talking about rely on extensions offered by
the GNU implementations of these programs.  You'd have to fix the
scripts, or add support for GNU extensions to your replacements.  More
patching, or actual development.

Now, it's obvious that it *can* be done.  It doesn't even have to be
done all at once.  Indeed, GNU software was built just like that, one
component at a time, each one replacing one of the components of the
non-Free operating system on which GNU is inspired in, but is not.
That was the most sensible approach, and, for the hypothetical efforts
discussed herein, it would work just fine, even if it would take a
while.

However, because all of these GNU components were also developed to
work together, and to work along with other preexisting Free Software
components that the GNU project decided it didn't make sense to
reimplement, they all work well together, and they rely on each
others' idiosyncrasies, quirks and inconsistencies and extensions.

Furthermore, as Linux developers decided to adopt all this software
and use it along with the kernel they had created, to spare themselves
from having to duplicate all that work to have a complete operating
system, they found that a number of small pieces were necessary to get
them all to work together.

These pieces were thus developed within this environment that combined
GNU software and Linux.  Just like Linux itself, these other pieces
were created dependent on GNU infrastructure, and only recently did it
become possible to use Linux with other low-level libraries instead of
GNU libc.  That said, even distributions that adopt such alternate
libraries still include a significant number of GNU components to make
for a complete functional system.

Therefore, if one set out today to replace all GNU software from our
system, one would be have a lot of development work ahead to get back
to a functional system.  Certainly not as long as the 7 years it took
GNU to get to the point where the kernel was the only major missing
piece, for nowadays there is much more BSD and OpenSolaris Free
Software that can be used as a starting point for several of the
smaller components, but it would be a lot of work nevertheless.

But until this effort was complete, users would notice the difference.
Replacing all GNU software would render the system unusable, even
unbootable, for nearly all users, until replacements were developed or
dependencies on GNU features and extensions were fixed, which would
take a lot of work and a long time.  To the best of my knowledge,
nobody has ever succeeded in, or even tried, anything like this.


Now, let's look at Linux-specific software.  Rather than going for the
simpler "Linux is a kernel" approach, I'll concede to regarding some
of the low-level programs and scripts developed specifically for the
combination of GNU with Linux, but turned mostly towards the kernel,
as Linux-specific.  Say, programs to create and manipulate filesystem
types that are implemented exclusively or at least originally in the
Linux kernel, Linux-specific basic utilities (linux-util-ng),
device-mapper and LVM, mdadm/raidtools, SELinux, boot-up scripts that
rely heavily on Linux-specific /proc and /sys contents, and even all
the effort that went into porting GNU and non-GNU software for it to
run on this system we're talking about.

Putting this all in shape and together was no doubt a lot of work.  It
is self-evident that there is merit in that, and that a Free kernel
and all this work that completed and provided us with the first
fully-functional Free operating system calls for our gratitude and
praise.  And, boy!  or girl!  Erhm.  And, young human! :-), do they
get enough of it!

But, getting back to determining the impact that replacing the
contributions of this project would have on the whole system, we'd
find out: not so much.  As mentioned before, some people have already
shown this to be true.

People took entire distributions of our system, replaced as little as
the kernel and a few low-level applications with their counterparts in
OpenSolaris or FreeBSD (or, surprise!, in the GNU operating system
itself), configured the replacement kernel to emulate Linux syscalls
or rebuilt GNU libc to target the replacement kernel while exporting
the same ABI as before, and got functional systems!

Not so much when using the Hurd, unfortunately; it's still suffering
the consequences of unfortunate mistaken decisions and lower priority.
But the other two are hardly distinguishable from their baseline,
full-featured distros based on our system.  Users can hardly tell the
difference.  Nearly-zero impact.

Others actually went through the trouble of rebuilding all the
software on top of this replacement kernel, which spared them from
some adaptation layers in GNU libc, presumably getting them slightly
better performance.  Little to no trouble to doing that, and little to
no perceptible changes for users.

== Conclusion

Summing it up, GNU is far more "irreplaceable" in the whole system
than any other component, including the kernel Linux.

Second to it is X, which happens to have been adopted early on to play
this role in the GNU operating system.

Linux developers deserve credit for having provided the last missing
pieces, but it is not reasonable to pretend they did all the work, or
even the largest part of the work, or even the most important part of
the work towards the fully-functional system.  They completed the last
piece first, indeed, but their last piece is hardly essential to the
system any more, i.e., it's easily replaceable.

Conversely, the pieces they created depend heavily on GNU, just like
the rest of the system.

So, please give the GNU project the credit it deserves, and help us
spread the philosophy that justified its development and provided us
with the largest and most irreplaceable portion of the GNU+Linux
operating system.  Please don't refer to it as just Linux, no matter
how many others make this mistake.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}
FSFLA Board Member       ¡Sé Libre! => http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}