How much GNU is there in GNU/Linux?

Remove the BIOS and see whether your system will boot at all.

Remove the CPU microcode and see whether your BIOS will run at all.

Do we get to call it Intel/BIOS/GNU/Linux now?

I think the GNU/ prefix, based on just 8% code contribution, has become largely moot by today. If people want to say "Linux/GNU" then they can do that, but trying to *insist* on the "GNU/Linux" naming based on the rather strained argument that's still all super-important GNU code and the rest is just details is somewhat pathetic.

If the GNU projects wants to gain larger relevance it should contribute more *code* and should be a friendly platform for contributors, instead of aggressively trying to language-lawyer themselves into the naming of other projects ...

wait clang actually compiles the linux kernel http://lwn.net/Articles/411654/

Quite a lot, apparently: http://www.debian.org/ports/kfreebsd-gnu/

Anyway, Stallman's point is not that the GNU project wrote most of the software, but that all of it was written (and selected) with the sole purpose of creating a free operating system:

"Many other people and projects have contributed code to the system, and some of this code is just as vital as anything the GNU Project wrote. But the GNU Project did one other crucial thing which no one else did: we made a complete free operating system our explicit goal."

http://lkml.org/lkml/1999/4/6/13

Not sure what I'm trying to say.

Most of the software is perfectly portable to alternative libcs.

And if it's not, it should be.

Dave.

The fact is that the Linux kernel would have been useless had there not been a GNU project, already in place, to drop it wholesale into. If Linux had not come along, a newly unencumbered BSD kernel would have been adapted a year or two later, and would since have forked, and would now be managed by mostly the same people as do Linux today -- maybe Linus included. It would, then, have been a GNU/BSD system. The same names would be complaining about that, instead, with arguments of exactly equal merit.

1. To avoid Linux' geeky image. Don't forget that many potential users previously had bad experiences or heard about them. Linux on the desktop has an image as a tinkerer's system.

2. To elevate themselves to the 'operating system' rather than 'distribution' category (i.e. one can pick between Windows, OS X, Ubuntu, and Linux). This gives the perception of Ubuntu being a real competitor to Windows and OS X, not just another flavor of a marginal (on the desktop) operating system.

I think that from a PR-perspective this is a good thing.

Zombies with shotgun wounds in their feet move more than this. This is a project with zero active developers. (I wonder what David Dawes is doing with his time, now he threw his co-developers out of the house because they wouldn't give him enough credit and discovered that when they've left the house is so very empty?)

But my question was about the final result, which is measurable quite easily, and that most people (read: not just developers) will use : the software in the default install.

I was building commercial products using these tools as late as the late 1980s.

The big break for GCC actually came with the advent of C++. Up until GNU C++, the only available C++ implementation was AT&T's fairly horrific CFRONT preprocessor. Not sure I'm thanking the GNU folks for making this language viable, and at any rate it was never really used for fundamental infrastructure.

What did you think BSD used for tools before RMS helped them out, anyhow?

I think the argument does not make any sense at all.

1. I should point out that the majority of code contributed today is by people working for corporations. To me this is important to point out because its fair, and because it helps remind my (relatively politically left-leaning) self that corporations as not inherently evil, but instead corporations are what they are, and are perfectly valid, great, and efficient in a particular role in society.

2. I should point out that the thing wasn't started by corporations. People motivated primarily by profit did not (and probably would not) initially create this thing I consider so beneficial. Idealists, and academics, did.

I may not agree with all of Stallman's positions. However, recognizing the importance of Stallman/FSF/GNU in creating "Linux" (as an OS, not just a kernel) helps remind us that idealists (and for that matter academics) are important and should be valued in society going forward. (End soap box...thank you)

Where the FSF goes haywire is that it considers that its distribution is a fundamental property of the programs that make it up, and therefore also of other distributions made out of the same pieces. You could as easily say that coreutils should be called RedHat/GNU coreutils because of the longtime employer of its maintainer: by extension, because RH maintains so much of the software that goes into Linux, Ubuntu should be called RedHat/Ubuntu. This is plainly mad, and RH would fight it because it's trademark dilution as well. (You could argue that coreutils's copyright is assigned to the FSF so it should be allowed to keep other entities out of its name, but X's copyright *isn't* assigned to the FSF yet the FSF feels happy to call it part of the GNU system. So copyright assignment cannot be relevant here.)

Here, as in many ways, RMS and the FSF are stuck in the past: in the era they come from, and in the proprietary world now, products really *did* get dubbed with the name of the vendor who was distributing them. The free software world stopped working like that fifteen years or more ago, but the FSF never changed its ways here. Product names are, more than ever, arbitrary monikers, not credit lists: but the FSF doesn't seem to have noticed.

As for logos, the GNU tools I counted don't contain any AFAIK. Unlike Linux.

Now, if you want to compare a standard install, it would be just fair to apply the same standard to both sides, namely, discarding unusual drivers and architectures from Linux too. Or, if you want to claim they're important, then so are the less-than-common languages, architectures and operating systems supported by GCC, GDB and glibc, the architectures and object file formats supported by binutils, and all the options (or lack thereof) of Gnome.

Anyway, even if Linux *had* doubled in size in that time-frame and GNU hadn't grown at all, my very limited study with just a few GNU components showed they were 3 times larger that Linux, so these GNU tools alone would still be at least 50% larger than Linux.

a) I said *I* will continue to name it GNU/Linux. You can do whatever you want, and I wont fire a shotgun at you. However, if asked, I will continue to motivate it in the same way.

b) nobody forces a name on Linux, except maybe Android people. The kernel still is named Linux. It's the whole system that's named differently. If one is to follow your "don't force names on things logic" you can't name your system Debian, Fedora, SuSE, Gentoo or Ubuntu, for that matters. By the way, I am free to call it Bonkers OS, if I like, since there is no trademarked name for the whole combination as an holistic system.

c) I am also interacting with Windows computers, indirectly. I do not go so far as to say I am using a Microsoft Windows system just because of that. I find *your* comment rather naive.

d) With my software engineer hat on: LoC *is* a poor metric, they not only discourage you to use that at school (at the university they fail you outright if you try to use that directly to estimate effort) and at work (Bill Gates is credited to criticize the IBM effort-estimation mode based on SLoC by saying: "Measuring programming progress by lines of code is like measuring aircraft building progress by weight."), but commons sense should help you too to understand it. Numbers will not help you when you use the wrong method to measure the wrong thing.

I do not have to show that the numbers themselves are wrong, as you suggest. Running the experiment again would be pointless, because its based on a wrong set of hypothesis.

I am claiming that this report shows nothing of interest to support your denigrating notion about the GNU project, to which you seem to have a personal grudge against.

LoC was introduced as a metric around 1960. Not only agreeing about what SLoC means is difficult, it also is hard to adjust that value for different languages and programming paradigms.

Look: two SLoC:

--------------------------

#include <iostream>
int main () { std::cout << "Hello world!" << std::endl; }

--------------------------

Look: more SLoC:

--------------------------

#include <iostream>

int
main ()
{
using namespace std;
cout << "Hello world!"
<< endl;
return 0;
}

--------------------------

A nice story is also here: http://www.folklore.org/StoryView.py?project=Macintosh&...

I advise reading the following book: N. E. Fenton, S. L. Pfleeger, "Software Metrics: a rigorous & practical approach", PWS Publishing 1998