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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



:-) I'll try to be just a little bit shorter. Though I may not succeed. ;-)

On Friday 25 July 2008 20:18, Alexandre Oliva wrote:
> On Jul 24, 2008, Marko Vojinovic <vvmarko@xxxxxxxxxxx> wrote:
> > 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*.

What the end-user sees as useful work is completely impossible without the 
work done by the kernel (although it is hidden from the user). That is why it 
is "essential".

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

I am afraid that the relevance of any piece of system code is quite hard to 
measure, as you indicated above. Take something out, the thing stops working. 
However, I tried my best to argue that severity of the damage to the system 
could be one possible measuring stick, although not perfect. By that 
criterion, one could argue that bios or the bootloader are even more 
essential than the kernel. However, the bios is not the part of an operating 
system or a distro, so it doesn't get its name in there. The bootloader, 
although completely crucial, is a fairly simple piece of code (compared to 
the kernel or any other serious part of the system). This means it is quite 
easy to code, needs no maintenence, and all in all, doesn't deserve its name 
mentioned either (no offence to the grub developers :-) ). If you push the 
car analogy, it would take part of ignition mechanism --- the key, the 
battery and the electric motor to give initial torque to the engine. It's a 
simple mechanism. However, once the engine is running, it is completely 
useless until the next ignition event.

All this said, the kernel is the only completely essential component left. Of 
course, the bare kernel with nothing else except the "hello world" 
application is purely theoretical notion, but nevertheless has *nonzero* 
usability (however academically small). But the system without a kernel 
has *precisely zero* usability. The kernel is distinguished to be the only 
component of an os with this "feature". And if one looks into the "why" of 
this, one will find that this is because the kernel has a qualitatively most 
important job to do in the os. That is why I consider the kernel to be the 
sole single component worth mentioning in the name of the os or distro.

And this measuring stick (although imperfect) works, and as a result gives 
some notion of "importance level" for the kernel vs the rest. Besides, that 
is the only measuring stick I can think of. Evaluation of imporance of 
something is always an ungrateful job. Of course, you could probably invent 
another method of evaluation, a different measuring stick, to back up your 
opinion on equal importance of GNU and the kernel. By the end of the day, it 
all boils down to which argument is more intuitively appealing to the 
majority of people. Please see below to the end of this post.

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

But that is what actually happens, whether people are interested to know or 
not. Give fuel, get transport. A car is a device to convert one into the 
other (but not vice-versa :-) ). But a car-savvy customer surely wants to 
know how much horse-power does his new car have, time to accelerate from 0 to
100 mph, fuel consumption over 100 miles, etc. These are all properties of the 
engine, and how efficiently it converts fuel to mechanical energy. I disagree 
that customers are not interested in that. At least they should be. The 
ignorant ones probably use Windows as well. :-)

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

Oh, you forgot the "squirrel in a barrel" type of drive. ;-) And the pedals, 
(like on a bycicle), or barefooted drive (as in Flinstones). :-)

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

But this conversion is the essential part of the process of "driving to 
places". Ignoring that is, well, ignorant. Whenever you decide to travel out 
of town, the first thing you need to do is to make sure you have enough fuel 
for the trip. Given the distance of the place you wish to visit, you need one 
of the engine parameters in order to calculate how much fuel to buy. If you 
do not take care of that, you risk having major trouble once you're on the 
road.

> 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?

See above. Without the engine, it is completely impossible to do something 
useful with the car. If some other part is missing, it is *not completely* 
impossible to do something useful. Not even remotely useful as driving it, 
but you can (for example) use the working engine to help somebody else start 
their car if their battery is dead. That is nonzero usefullness. The analogy 
to the "hello world"+kernel example works to emphasize that point, as 
academic as it is. 

> 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?

See above.

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

:-) Sorry, but other than not having enough free time, I have to admit that I 
am quite clumsy in doing any kind of experiment. That is one of the main 
reasons why I am involved in theoretical research. ;-)

// The experimentalist is the person that doesn't know how to sum up a column 
of numbers. The theoretician is the person that doesn't know how to tie his 
shoes. // ;-)

> > 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.
[snip]
> 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 :-)

You wouldn't believe, but I participated in an assembly of one precisely such 
cluster in my Institute. Today it has 160 quad-core nodes, couple of hunderds 
of terabytes storage space, a very very sophisticated and expensive master 
switch, etc. It is assembled in five racks, and dissipates around 20 KW of 
heat (that's an estimate, didn't measure it actually). :-) There is also a 
nontrivial cooling system to keep the machine from frying itself dead.

It mostly does some path-integral calculations, which are considered by 
general public to be utterly useless. So it is essentially one very big 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.

Recognition is irrelevant. It *would be* Linux, because of the kernel used.

> == 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.
[snip]
> 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 :-)

Basically I find all that was said in the snipped part quite correct. As I see 
it, this was one attempt to define a "measuring stick" for evaluating what is 
the most important component of the os or a distro. As Alexandre concluded, 
it doesn't work, so it's a failed attempt (but I do give credit to Alexandre, 
it is a very good try).

> == Impact of replacement
>
> 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.
[snip]
> 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.

This is a second try to define the "measuring stick", and one even more 
interesting. I basically agree with everything said (and snipped). After two 
readings, it seems ok to me, up to the fact that this kind of reasoning 
implies that GNU is the *only* one to take the credit (or maybe GNU+X 
combination), because the kernel itself is (more or less) easily replaceable 
part of the system. I wish to congratulate Alexandre for the successful (ie. 
consistent) construction of another "measuring stick".

So we basically have two approaches (so far). We agree (correct me if I am 
wrong here) to give the name to the distro by giving appropriate credit to 
the most important component of the system. There are two proposals on how to 
evaluate this importance:

1) based on the amount of "essentiality" of given components, ie. how much of 
a working system is left if a component is removed --- the winner here is the 
kernel (with grub as a side-effect), and the distro name is "Fedora Linux";

2) based on the amount of "complexity" of given components, ie. how hard would 
it be to replace a given component of the system without making serious 
damage/difference --- the winner here is GNU (with X as a side-effect), and 
the distro name is "Fedora GNU".

If nobody else suggests a third criterion, I suggest it's time to vote. Based 
on which of the two criteria is more intutively appealing, it seems, because 
both seem convincing (ie. it's a matter of taste). My vote is clear, I 
believe Alexandre's is also. So far, 1:1. ;-)

Best, :-)
Marko

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux