Quite possibly nonsense though you covered yourself well by using the qualifier 'often'. I recently misplaced a book from the library and thought I was going to have to replace it (found it later, so whew). I inquired into how I might do this - my plan was to find a nice clean copy at the local used book venue, or barring that, buy a new copy from a source that offered a nice discount over retail. My librarian told me that they would rather get the book from their sources and that it would probably cost me less because they buy books at a discount through some sort of consortium. I was surprised, since the "libraries pay more" meme has been thrown around quite a bit in the copyright discussions of the last decade or so.
Info source: My local librarian. And my father-in-law has a Ph.D. in Library Science.:-P
No, NoScript doesn't have an automatically updated whitelist - it's entirely the responsibility of the user. And that's a good thing in my view. Nothing is whitelisted by default, and the whitelist isn't automatically updated without the users explicit involvement.
The key advantage of NoScript if you can stand it is that the permissions can be granted temporarily. Do what you need to do and revoke permissions and exposure to the risks you mention are minimized at least.
Also, NoScripts user interface is easy enough to use that it isn't a big pain to selectively allow (temporarily) scripts until the site works. Once finished, rolling back permissions is pretty easy (Right click plus a mouse click).
No-script therefore has only false positives. Unfortunately, un-like ABP, a user curated list isn't practical; as soon as you do and whitelist a paticular script, someone will change it to do something malicious.
What he said. It took awhile to teach my family to change their default behavior to "temporarily allow" for NoScript, since it is a bit annoying, but they understand why and it gives me a bit more peace of mind. Only the sites we use regularly or have decided to trust get whitelisted permanently.
I actually have both installed, and haven't noticed any adverse effects or conflicts. NoScript handles the "selectively allow this", while Ghostery tells me about web bugs and such, and lets me identify the JS and urls, as you point out. Ghostery seems to stay out of the way quite nicely, while NoScript does the heavy lifting.
As with the Betamax/VHS formats, Circuit City's DivX and HD-DVD/Blu-Ray, the ace up the sleeve is that people always have the choice not to buy. If people don't want a format or technology, nothing the studios or content providers do will get them what they want (our money). They never seem to factor that in to their plans.
Lame? Not always - gift cards are quite useful in many circumstances, so don't write them off so glibly. Before gift cards (yes, there was such a time) giving people "throughly liquid cash" as a gift meant they were just as likely to use it to pay the rent, buy groceries or stick it in their wallet with the other liquid cash and spend it for ordinary things, not the intended gift. In the face of this, gift cards were a nice way to help the recipient "treat themselves" as intended rather than just spend the money on mundane necessities. The point of a gift, after all, is to give the recipient something special they might not have allowed themselves to purchase on their own (that's what we try to do in my family, anyhow).
Why not just buy the gift instead? Gift cards (or cash) are a copout for the lazy so they don't have to bother figuring out a "proper" gift, right? No, not always. There are plenty of people who have hobbies or interests that are specialized and complex, so trying guess what they really want can lead to the wrong gift. Yeah, one could ask enough questions to determine the correct gift, but that's just as likely to spoil the surprise - might as well just ask "tell me exactly what you want and I'll buy that". Rather than buy the wrong TV or game or computer or whatever, you can buy a gift card for the place where the desired gift is sold, and you can be reasonably sure that the recipient gets exactly what they want, and you don't blow the surprise either.
As far as the value of the purchase not matching the value of the card, that's not as simple as you cynically describe it either. Consider the situation where someone wants an expensive item that doesn't quite fit their budget. They won't buy what they really want because they can't afford it. Maybe you can't either (not entirely, anyway). Giving a gift card is a great way to help partially pay for the item when buying the item outright isn't feasible.
Nonsense. The terms of the calling plan are the same under contract as they were the 2 years prior when I was not under contract. I wish people would stop spouting this nonsense. All the contract ensures is that I stay a customer for the agreed period of time before I terminate service in exchange for recieving a new phone at a discount. Since I wasn't planning on switching providers anyhow, a new phone doesn't seem like such a burden.
I did (vote with my wallet). Maemo lost. Google managed to get a provider that actually has coverage where I live to sell an android device. Maemo? Not so much. When ideology collides with the real world, sometimes the real world wins. I hope this changes in the future, because I didn't have any preexisting bias for android, but I can use my android phone NOW, rather than wait for the nebulous future when the planets line up just right to make devices available that run software which fits my ideology perfectly. OTOH, I can't say I have much to complain about with android so far. I've been able to run only Free (as in speech) apps to get the functionality I desire, and I can write my own using the SDK that's available. Seems like a fine situation to me.
Fans of the walled garden may be happy with what they get, while those who are unhappy with that choice may be looking elsewhere for their OS environment, thus VLC for Mac may not be on their radar.
Ok, Sloppy on my part - I wasn't confusing patented, I was in a hurry and grabbing a quote from memory that doesn't apply. Replace the original "patented" with "copyrighted" and reread. If the codebase started out containing copyrighted code which was then removed and replaced during the course of development, or when someone realized the code violates copyright (or the original copyright holder noticed and complained), the question is does the new body of code which no longer includes the original code constitute a derivative work subject to the original copyright? If so, then there is potentially a lot of code out there that could be a target for copyright litigation, if it can be shown that it has been touched by someone else's copyrighted code at some earlier time. This makes correcting copyright violations by removing the copyrighted material rather difficult, given that the only option left seems to be a clean-room rewrite from scratch.
The violation in your analogy would be that the car in it's original form was destroyed, thus depriving the lender of his property. The new car isn't the original property. If, during the act of replacing all the old parts you assembled them to eventually create the original car you borrowed, then your new car is yours and the original goes back to the owner. The analogy to software would be that you provided the original source code in it's original form to anyone who asked, in compliance with the original license. And any intermediate forms that still contained old code. The interesting point comes when all the original code is gone and all that is left is the new code, solely created by the new author. Other than the nebulous "derivative", I don't see how the original author should have much claim over the new work, particularly if the old work is still available.
Can't tell whether you were replying to me or gr8_phk, but I meant to imply you did try communicate with these folks and it failed, so bringing the matter to the attention of the community was warranted. Apologies if in my haste I wasn't clear.
I'll have to agree with larry here. This touches an area that is nuanced, to say the least, but replacing the code needs to be an option in some cases. As an example, I worked on an OSS project several years back. For perfectly valid reasons, the current project maintainer wanted to change the license. He attempted to contact all the authors for their permission to relicense the code under the new license. If he got no response, or the original author said "no", then his only option was to replace the code with code he had written himself. This seems a perfectly valid approach to me, considering the old code is still available from the same source. I happened to miss noticing his request until it was too late (infrequently checked mail account), so was happy he could replace the code and move on.
I suppose if one wanted to adopt a strict interpretation of "derivative", then replacing code within an existing framework might be considered in violation of the license, but people really need to think before playing this card. It makes situations like "if you show us patented code in our application, we'll replace it" much more difficult to reconcile easily, especially if the code violating the patent was part of the original application code. Then the replacement code is 'derivative' and still subject to the original claims.
That's a mighty big can of worms you could be opening, Diesel Dave. Maybe even Pandora's box.
The following (from the original article) doesn't seem very nice either. While following the Golden Rule is good practice, "treat others with all the respect they have treated you" is sometimes warranted. Calling people out in public, particularly when "handling such matters" in private hasn't worked [speculation on my part], is a perfectly fine way to handle people that don't respect others in their community, in my opinion.
Mr. Andersen, his past employers and Mr. Landley appear to have removed some of the copyright statements of other Busybox developers, and appear to have altered license statements, in apparent violation of various laws. Mr. Landley once claimed that all of my contribution had been completely removed from the Busybox program, using a misinterpretation of Judge Walker's methods for identifying non-literal copying to justify his claim. As far as I'm aware, he was incorrect.
Americans aren't stupid, but you apparently are, since you just supported the argument made by the parent post while attempting to be contrary. After the obligatory contract period is complete (which is the exchange for getting the discounted phone), why doesn't the monthly bill "strictly cover the monthly usage of the service" instead of remaining at the same level it was while "paying for the free or discounted phone"?
My answer is that the contract period isn't really paying for the phone, it's providing a guaranteed revenue stream for the company for a specified period of time. A steady, guaranteed revenue stream is very important for a business, since it makes things a bit more predictable.
It's fascinating to me that so many people readily make excuses for companies/corporations as if they weren't made up of people who individually would not get the same benefit of the doubt. That's some pretty strong Kool aid the marketers have managed to foist upon the world.
I believe that the whole "locally compiled = better performance" is a load of hogwash since you chew up time compiling, and if you compile in the background, doesn't that affect what's going on in the foreground? This is why some people have a separate "compile machine" for Gentoo. I believe this "wasted" effort and time outweighs whatever potential benefits you get from a local compile.
Either you don't quite know what you are talking about and are just parroting what you've read elsewhere or you didn't quite think things through before posting and meant to say something better. I can't tell which.
What you 'believe' is irrelevant - facts are what matter. You give the impression that you've decided to choose a stance arbitrarily (based on your 'belief') in regard to local vs. 3rd party compilation, then manufactured (or adopted) arguments to support your position. And you're painting with a pretty broad brush, in any case. Sweeping generalizations mean little in a context where details matter. There is no easy answer to the question - it depends on the situation. Local compilation *can* lead to better performance by producing an optimized binary, and smart people who know what they want can determine whether the gain in performance (if there is one) is worth the effort.
In this particular case, you seem to have confused overall performance of a running machine with the performance of a particular binary. And you're using time in multiple senses as well (time spent compiling, time lost to reduced performance during compilation, and maybe another - I can't tell. And you're missed the most relevant one - execution time of the locally compiled binary).
In the specific case of the binary produced by a local compile, it may be more performant than the one produced for general distribution, and this is measurable. In the case where the binary is extensively used by a system dedicated to a specific purpose, the performance increase may be significant and worthwhile. In the case of a widely used library, the performance increase may impact many operations occurring on a system, so while not precisely measurable, can still provide enough of a benefit to be worth the trouble, or at least break even. This depends on what a person wants a system to do, and they have to make the decision.
Your other argument seems to be something about the act of compiling itself and it's impact on a running system. Again, the impact depends on the purpose of the machine(s) in question. In general, the time spent on the compile (both wall time and cpu time) is a small fraction of the total running time of the resulting binaries, so the overall impact is pretty low. Even on a Gentoo system experiencing frequent updates of a large fraction of packages, the time spent compiling is small relative to the uptime (in my experience). If any performance improvements are gained by local compilation, their effect will be manifest much longer than the time spent on compilation. On a dedicated server with few packages, the amount compiling due to updates is pretty small.
The problem with a source-based system like Gentoo, as others have mentioned, isn't the impact of compilation itself. It's the cognitive impact of frequent updates and the fact that they take much longer (in terms of wall time) than installing a binary package. For a busy human being, it's the time spent thinking about the update (while it's running, whether or not you watch the output scroll by) that has the most significant impact. This is what finally got me to step away from Gentoo. Your are thus correct about questioning the benefit of local compilation if that's what you meant. This is entirely separate from the question of whether local compilation can result in better performance, though. As I've said, it depends.
Learn to read, please. Both Richard Stallman and the many nameless contributors were mentioned in my post and I said it would be fitting they all take credit together. Thanks for completely missing the point and making it only about Linus again, when I was taking it in the other direction.
And Linus did much more than just 'release code into the wild' - that just results in thousands of unmaintained and abandoned projects as can be found on Sourceforge. He's done much more than just hacking away, otherwise you'd never have heard of Linux or him. But hey, why think things through when you can just take a cheap potshot at an easy target.
First off, Linus didn't do anything but release some code out to the wild. What happened happened because of others, most of whom you'll never know the name of. Linus didn't do anything except keep hacking away at his tool.
Secondly, the GNU Project would most likely like to have a word with you. Founded (not by Linus) in 1983. Created most of an OS using a distributed development model (sound familiar) and was at the point that all Linus had to do was put a kernel under it in 1991. The Free Software community you attribute to Linus already existed. Linus used the fruits of their labor. The BSD project also already existed and if it weren't for a lawsuit from AT&T, you probably never would have heard of Linus Torvalds or Linux.
FOSS is *much* larger then just Linux, and was around before it existed.
Maybe you haven't lived long enough to realize the significance of Linux as a world-wide collaborative project on a scale capable of producing something as complex as an operating system kernel. Less than 2 decades ago, a project like Linux was unheard of and essentially considered impossible. Anything non-trivial required the resources of a government or a corporation and that was that. What you now consider commonplace was a huge revelation when it began. Linux is one of the first projects that showed the world what the internet makes possible. Just about everything you now know as the FLOSS community happened because Linux set the example for what was possible. That *is* real change.
Now, Linus was just in the right place at the right time and had the right personality to pull it off. But releasing the kernel under the GPL to encourage participation was also a big factor, so I agree with the poster below that a co-nomination with Richard Stallman would be more appropriate. I'll go so far as to suggest that Eric Raymond, Bruce Perens, Tim O'Reilly, Brian Behlendorf, Paul Vixie and Mitch Kapor belong in that group too. Maybe even Eben Moglen. In fact, considering the collaborative nature of free software, anything other than a group of key contributors would be incorrect and missing the point.
I seriously think the people mentioned above (and a bunch of contributors who quietly gave of their time) changed the world in a significant way, for the better.
Slashdot Mirror
Mod parent up. Meet the new boss - same as the old boss.
Quite possibly nonsense though you covered yourself well by using the qualifier 'often'. I recently misplaced a book from the library and thought I was going to have to replace it (found it later, so whew). I inquired into how I might do this - my plan was to find a nice clean copy at the local used book venue, or barring that, buy a new copy from a source that offered a nice discount over retail. My librarian told me that they would rather get the book from their sources and that it would probably cost me less because they buy books at a discount through some sort of consortium. I was surprised, since the "libraries pay more" meme has been thrown around quite a bit in the copyright discussions of the last decade or so.
Info source: My local librarian. And my father-in-law has a Ph.D. in Library Science. :-P
No, NoScript doesn't have an automatically updated whitelist - it's entirely the responsibility of the user. And that's a good thing in my view. Nothing is whitelisted by default, and the whitelist isn't automatically updated without the users explicit involvement.
The key advantage of NoScript if you can stand it is that the permissions can be granted temporarily. Do what you need to do and revoke permissions and exposure to the risks you mention are minimized at least.
Also, NoScripts user interface is easy enough to use that it isn't a big pain to selectively allow (temporarily) scripts until the site works. Once finished, rolling back permissions is pretty easy (Right click plus a mouse click).
No-script therefore has only false positives. Unfortunately, un-like ABP, a user curated list isn't practical; as soon as you do and whitelist a paticular script, someone will change it to do something malicious.
What he said. It took awhile to teach my family to change their default behavior to "temporarily allow" for NoScript, since it is a bit annoying, but they understand why and it gives me a bit more peace of mind. Only the sites we use regularly or have decided to trust get whitelisted permanently.
I actually have both installed, and haven't noticed any adverse effects or conflicts. NoScript handles the "selectively allow this", while Ghostery tells me about web bugs and such, and lets me identify the JS and urls, as you point out. Ghostery seems to stay out of the way quite nicely, while NoScript does the heavy lifting.
As with the Betamax/VHS formats, Circuit City's DivX and HD-DVD/Blu-Ray, the ace up the sleeve is that people always have the choice not to buy. If people don't want a format or technology, nothing the studios or content providers do will get them what they want (our money). They never seem to factor that in to their plans.
Lame? Not always - gift cards are quite useful in many circumstances, so don't write them off so glibly. Before gift cards (yes, there was such a time) giving people "throughly liquid cash" as a gift meant they were just as likely to use it to pay the rent, buy groceries or stick it in their wallet with the other liquid cash and spend it for ordinary things, not the intended gift. In the face of this, gift cards were a nice way to help the recipient "treat themselves" as intended rather than just spend the money on mundane necessities. The point of a gift, after all, is to give the recipient something special they might not have allowed themselves to purchase on their own (that's what we try to do in my family, anyhow).
Why not just buy the gift instead? Gift cards (or cash) are a copout for the lazy so they don't have to bother figuring out a "proper" gift, right? No, not always. There are plenty of people who have hobbies or interests that are specialized and complex, so trying guess what they really want can lead to the wrong gift. Yeah, one could ask enough questions to determine the correct gift, but that's just as likely to spoil the surprise - might as well just ask "tell me exactly what you want and I'll buy that". Rather than buy the wrong TV or game or computer or whatever, you can buy a gift card for the place where the desired gift is sold, and you can be reasonably sure that the recipient gets exactly what they want, and you don't blow the surprise either.
As far as the value of the purchase not matching the value of the card, that's not as simple as you cynically describe it either. Consider the situation where someone wants an expensive item that doesn't quite fit their budget. They won't buy what they really want because they can't afford it. Maybe you can't either (not entirely, anyway). Giving a gift card is a great way to help partially pay for the item when buying the item outright isn't feasible.
Nonsense. The terms of the calling plan are the same under contract as they were the 2 years prior when I was not under contract. I wish people would stop spouting this nonsense. All the contract ensures is that I stay a customer for the agreed period of time before I terminate service in exchange for recieving a new phone at a discount. Since I wasn't planning on switching providers anyhow, a new phone doesn't seem like such a burden.
I did (vote with my wallet). Maemo lost. Google managed to get a provider that actually has coverage where I live to sell an android device. Maemo? Not so much. When ideology collides with the real world, sometimes the real world wins. I hope this changes in the future, because I didn't have any preexisting bias for android, but I can use my android phone NOW, rather than wait for the nebulous future when the planets line up just right to make devices available that run software which fits my ideology perfectly. OTOH, I can't say I have much to complain about with android so far. I've been able to run only Free (as in speech) apps to get the functionality I desire, and I can write my own using the SDK that's available. Seems like a fine situation to me.
I'm not sure that's relevant given the focus of TFA. Apps running on Android devices are free to choose their own license, as far as I can tell.
Fans of the walled garden may be happy with what they get, while those who are unhappy with that choice may be looking elsewhere for their OS environment, thus VLC for Mac may not be on their radar.
I second the motion.
Ok, Sloppy on my part - I wasn't confusing patented, I was in a hurry and grabbing a quote from memory that doesn't apply. Replace the original "patented" with "copyrighted" and reread. If the codebase started out containing copyrighted code which was then removed and replaced during the course of development, or when someone realized the code violates copyright (or the original copyright holder noticed and complained), the question is does the new body of code which no longer includes the original code constitute a derivative work subject to the original copyright? If so, then there is potentially a lot of code out there that could be a target for copyright litigation, if it can be shown that it has been touched by someone else's copyrighted code at some earlier time. This makes correcting copyright violations by removing the copyrighted material rather difficult, given that the only option left seems to be a clean-room rewrite from scratch.
The violation in your analogy would be that the car in it's original form was destroyed, thus depriving the lender of his property. The new car isn't the original property. If, during the act of replacing all the old parts you assembled them to eventually create the original car you borrowed, then your new car is yours and the original goes back to the owner. The analogy to software would be that you provided the original source code in it's original form to anyone who asked, in compliance with the original license. And any intermediate forms that still contained old code. The interesting point comes when all the original code is gone and all that is left is the new code, solely created by the new author. Other than the nebulous "derivative", I don't see how the original author should have much claim over the new work, particularly if the old work is still available.
Can't tell whether you were replying to me or gr8_phk, but I meant to imply you did try communicate with these folks and it failed, so bringing the matter to the attention of the community was warranted. Apologies if in my haste I wasn't clear.
"handling such matters" in private hasn't worked [speculation on my part]
Thanks Bruce, you just confirmed below that my speculation wasn't too far off the mark.
I'll have to agree with larry here. This touches an area that is nuanced, to say the least, but replacing the code needs to be an option in some cases. As an example, I worked on an OSS project several years back. For perfectly valid reasons, the current project maintainer wanted to change the license. He attempted to contact all the authors for their permission to relicense the code under the new license. If he got no response, or the original author said "no", then his only option was to replace the code with code he had written himself. This seems a perfectly valid approach to me, considering the old code is still available from the same source. I happened to miss noticing his request until it was too late (infrequently checked mail account), so was happy he could replace the code and move on.
I suppose if one wanted to adopt a strict interpretation of "derivative", then replacing code within an existing framework might be considered in violation of the license, but people really need to think before playing this card. It makes situations like "if you show us patented code in our application, we'll replace it" much more difficult to reconcile easily, especially if the code violating the patent was part of the original application code. Then the replacement code is 'derivative' and still subject to the original claims.
That's a mighty big can of worms you could be opening, Diesel Dave. Maybe even Pandora's box.
The following (from the original article) doesn't seem very nice either. While following the Golden Rule is good practice, "treat others with all the respect they have treated you" is sometimes warranted. Calling people out in public, particularly when "handling such matters" in private hasn't worked [speculation on my part], is a perfectly fine way to handle people that don't respect others in their community, in my opinion.
Mr. Andersen, his past employers and Mr. Landley appear to have removed some of the copyright statements of other Busybox developers, and appear to have altered license statements, in apparent violation of various laws. Mr. Landley once claimed that all of my contribution had been completely removed from the Busybox program, using a misinterpretation of Judge Walker's methods for identifying non-literal copying to justify his claim. As far as I'm aware, he was incorrect.
Americans aren't stupid, but you apparently are . . .
Hey, you just insulted someone to make your point. Oh well, I'll still respond politely.
Yeah, my bad - blame it on the Monday morning grumps. I apologize. Thanks for keeping the level of discussion high.
Americans aren't stupid, but you apparently are, since you just supported the argument made by the parent post while attempting to be contrary. After the obligatory contract period is complete (which is the exchange for getting the discounted phone), why doesn't the monthly bill "strictly cover the monthly usage of the service" instead of remaining at the same level it was while "paying for the free or discounted phone"?
My answer is that the contract period isn't really paying for the phone, it's providing a guaranteed revenue stream for the company for a specified period of time. A steady, guaranteed revenue stream is very important for a business, since it makes things a bit more predictable.
It's fascinating to me that so many people readily make excuses for companies/corporations as if they weren't made up of people who individually would not get the same benefit of the doubt. That's some pretty strong Kool aid the marketers have managed to foist upon the world.
Troll. There was no Linux in 1979. Just Linus, but a little too young to be interested in anything other than Legos.
I believe that the whole "locally compiled = better performance" is a load of hogwash since you chew up time compiling, and if you compile in the background, doesn't that affect what's going on in the foreground? This is why some people have a separate "compile machine" for Gentoo. I believe this "wasted" effort and time outweighs whatever potential benefits you get from a local compile.
Either you don't quite know what you are talking about and are just parroting what you've read elsewhere or you didn't quite think things through before posting and meant to say something better. I can't tell which.
What you 'believe' is irrelevant - facts are what matter. You give the impression that you've decided to choose a stance arbitrarily (based on your 'belief') in regard to local vs. 3rd party compilation, then manufactured (or adopted) arguments to support your position. And you're painting with a pretty broad brush, in any case. Sweeping generalizations mean little in a context where details matter. There is no easy answer to the question - it depends on the situation. Local compilation *can* lead to better performance by producing an optimized binary, and smart people who know what they want can determine whether the gain in performance (if there is one) is worth the effort.
In this particular case, you seem to have confused overall performance of a running machine with the performance of a particular binary. And you're using time in multiple senses as well (time spent compiling, time lost to reduced performance during compilation, and maybe another - I can't tell. And you're missed the most relevant one - execution time of the locally compiled binary).
In the specific case of the binary produced by a local compile, it may be more performant than the one produced for general distribution, and this is measurable. In the case where the binary is extensively used by a system dedicated to a specific purpose, the performance increase may be significant and worthwhile. In the case of a widely used library, the performance increase may impact many operations occurring on a system, so while not precisely measurable, can still provide enough of a benefit to be worth the trouble, or at least break even. This depends on what a person wants a system to do, and they have to make the decision.
Your other argument seems to be something about the act of compiling itself and it's impact on a running system. Again, the impact depends on the purpose of the machine(s) in question. In general, the time spent on the compile (both wall time and cpu time) is a small fraction of the total running time of the resulting binaries, so the overall impact is pretty low. Even on a Gentoo system experiencing frequent updates of a large fraction of packages, the time spent compiling is small relative to the uptime (in my experience). If any performance improvements are gained by local compilation, their effect will be manifest much longer than the time spent on compilation. On a dedicated server with few packages, the amount compiling due to updates is pretty small.
The problem with a source-based system like Gentoo, as others have mentioned, isn't the impact of compilation itself. It's the cognitive impact of frequent updates and the fact that they take much longer (in terms of wall time) than installing a binary package. For a busy human being, it's the time spent thinking about the update (while it's running, whether or not you watch the output scroll by) that has the most significant impact. This is what finally got me to step away from Gentoo. Your are thus correct about questioning the benefit of local compilation if that's what you meant. This is entirely separate from the question of whether local compilation can result in better performance, though. As I've said, it depends.
And Linus did much more than just 'release code into the wild' - that just results in thousands of unmaintained and abandoned projects as can be found on Sourceforge. He's done much more than just hacking away, otherwise you'd never have heard of Linux or him. But hey, why think things through when you can just take a cheap potshot at an easy target.
First off, Linus didn't do anything but release some code out to the wild. What happened happened because of others, most of whom you'll never know the name of. Linus didn't do anything except keep hacking away at his tool. Secondly, the GNU Project would most likely like to have a word with you. Founded (not by Linus) in 1983. Created most of an OS using a distributed development model (sound familiar) and was at the point that all Linus had to do was put a kernel under it in 1991. The Free Software community you attribute to Linus already existed. Linus used the fruits of their labor. The BSD project also already existed and if it weren't for a lawsuit from AT&T, you probably never would have heard of Linus Torvalds or Linux. FOSS is *much* larger then just Linux, and was around before it existed.
Maybe you haven't lived long enough to realize the significance of Linux as a world-wide collaborative project on a scale capable of producing something as complex as an operating system kernel. Less than 2 decades ago, a project like Linux was unheard of and essentially considered impossible. Anything non-trivial required the resources of a government or a corporation and that was that. What you now consider commonplace was a huge revelation when it began. Linux is one of the first projects that showed the world what the internet makes possible. Just about everything you now know as the FLOSS community happened because Linux set the example for what was possible. That *is* real change. Now, Linus was just in the right place at the right time and had the right personality to pull it off. But releasing the kernel under the GPL to encourage participation was also a big factor, so I agree with the poster below that a co-nomination with Richard Stallman would be more appropriate. I'll go so far as to suggest that Eric Raymond, Bruce Perens, Tim O'Reilly, Brian Behlendorf, Paul Vixie and Mitch Kapor belong in that group too. Maybe even Eben Moglen. In fact, considering the collaborative nature of free software, anything other than a group of key contributors would be incorrect and missing the point. I seriously think the people mentioned above (and a bunch of contributors who quietly gave of their time) changed the world in a significant way, for the better.