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;
}
Posted Jun 3, 2011 14:22 UTC (Fri) by pr1268 (subscriber, #24648)
[Link]
The LOC anecdote you linked reminded me of an orthogonal software engineering metric SNAFU that's equally silly: Fixing bugs for money! (A college professor told me that this actually happened at IBM sometime in the 1970s.)
Another metric besides LOC
Posted Jun 4, 2011 5:12 UTC (Sat) by dlang (✭ supporter ✭, #313)
[Link]
I get that you don't like LOC as a metric, but the only alternative that's been presented is the size of the compressed source .rpm files.
what metric would you propose to use instead?
Another metric besides LOC
Posted Jun 5, 2011 3:12 UTC (Sun) by pr1268 (subscriber, #24648)
[Link]
I'm not totally against using LOC as a metric, but it does seem to lend itself to abuse (see Tchernobog's comment above). The size of compressed source tarballs could be equally abused (consider if I threw in a 1 MB random bits file in my source tarball—that would certainly enlarge my contribution).
I'm unsure what else to use. I admit that this is a lame answer, but it's just that the stories of abusing LOC metrics permeate folklore far beyond the link in Tchernobog's comment.
I suppose a better way of measuring software code would be based on features added, tested, and verified to the code base (for new development), or defects fixed and verified (for maintenance). If an individual were to have an unusually low number of features added/defects fixed, then this could be investigated—perhaps it's not attributable to the individual being lazy or incompetent but rather the particular code is hairy. Conversely, if some "hot shot" adds a hundred features/fixes, then this too might be attributed to a bunch of simple additions/modifications, like cosmetic fixes or single-line updates (The Dilbert example I linked notwithstanding).
Please understand that I do not wish to preach management style/technique. Besides, I'm not currently in a managerial position, nor do I consider myself prepared for such a role. I'm just suggesting intuitively what might be better than LOC for software metrics.
P.S. To answer the question asked by the title of this article, I suppose that there really isn't a better way to determine how much GNU in GNU/Linux other than LOC. Sigh.
Another metric besides LOC
Posted Jun 5, 2011 3:39 UTC (Sun) by neilbrown (subscriber, #359)
[Link]
> P.S. To answer the question asked by the title of this article, I suppose that there really isn't a better way to determine how much GNU in GNU/Linux other than LOC. Sigh.
Which leaves just a small step to the logical conclusion... it doesn't matter.
This isn't a contest. This is a collaboration. Let's just say a heart-felt "thank you" to every contributor, and not try to measure that which cannot be measured.
(Isn't that the whole point of ditching the 4-clause BSD license)