| |||||||||||||
How much GNU is there in GNU/Linux?How much GNU is there in GNU/Linux?Posted Jun 2, 2011 13:39 UTC (Thu) by tchernobog (guest, #73595)Parent article: How much GNU is there in GNU/Linux?
Isn't anyone bothering to question how those numbers were achieved? LoC is a very very poor metric. It does not capture usefulness of code, its complexity, or how many commits were needed to get there.
If I were to choose between two pieces of code doing the same thing, I would choose the one doing it in less lines of code. It could be an index of better maintainability, perhaps. I am just saying that you can't tell anything from these numbers. They just start flamewars.
For instance, I don't use all of the kernel; most drivers do not apply to my hardware. I use most of the glibc functionality, though.
And I will continue to call it GNU/Linux, not because it has a lot of GNU code in it, but because I think that it is important that people remember they are using a free-as-in-speech system. Or in a few years we will end up with a lot of Linux (android, google OS, whatever) systems that will have a small free portion, and will be uncannily similar to the old windows world again. No changes allowed. DRM everywhere. Patents to prevent you reverse engineer it. Etc. Calling it GNU/Linux normally has some people asking me "what is GNU?"; that is the most important part.
(Log in to post comments)
How much GNU is there in GNU/Linux? Posted Jun 2, 2011 16:12 UTC (Thu) by southey (subscriber, #9466) [Link] This is a rather naive to say that you don't use all of the kernel. You (or perhaps the distro) have used the full kernel source to obtain a binary because the compiler has to go through the complete kernel source based on your input. Also while your particular system may not have all drivers, you and your system may directly interacting with systems that do (GPS, internet servers etc.).
If LoC is a very very poor metric, how can you say that [Linux] has a lot of GNU code in it? The comments in this article show that this naming scheme is just pure fud. Sure GNU project host a number of projects that are very useful to use. But since Linux is important to you, does Linus and other developers have the same right to call you [something]/tchernobog? I agree with mingo that names should not be forced on others (especially given you other comments about openness).
How much GNU is there in GNU/Linux? Posted Jun 2, 2011 22:51 UTC (Thu) by tchernobog (guest, #73595) [Link]
I am sorry, but:
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>
--------------------------
Look: more SLoC:
--------------------------
#include <iostream>
int
--------------------------
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
Another metric besides LOC 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)
|
|||||||||||||