Then someone decided "options are bad" and started taking it all away.
The guiding thought is that every option MULTIPLIES code complexity. Options tend to interact with other options, and testing is required to verify that all options work together, or that the system provides a means of preventing options that don't from being used together. The drive to simplify interfaces is intended to reduce the number of bugs present in the system.
As a secondary effect, removing optional behavior forces developers to make sure that the normal behavior is sane and doesn't need dozens of radio buttons on a configuration app.
No, it isn't. I have a number of non-tech friends (and my mom) who use Fedora with GNOME Shell. I use Fedora with GNOME Shell. I know a fairly large number of GNU/Linux users, and very few of them actually hate GNOME Shell. Not none, but few. For my part, I think notifications aren't very good, but otherwise the system does what it's supposed to. It stays out of my way. It isn't distracting and it uses minimal screen space. I like those things quite a lot.
Thus, they figure, it's better to remove every shred of choice. Because, you know, choice is hard and confusing.
People continue to repeat this reasoning, attributed to various developers, but that doesn't make it true. The guiding thought is not that users cannot make choices. It is that every option MULTIPLIES code complexity. Options tend to interact with other options, and testing is required to verify that all options work together, or that the system provides a means of preventing options that don't from being used together. The drive to simplify interfaces is intended to reduce the number of bugs present in the system.
As a secondary effect, removing optional behavior forces developers to make sure that the normal behavior is sane and doesn't need dozens of radio buttons on a configuration app.
I understand people talking about Chrome being a faster browser, and I don't begrudge them that. However, anyone who contends that Chrome uses less memory doesn't know what they're talking about. Firefox uses less memory, is a smaller download, and is a much smaller installation than Chrome (particularly if you only measure code and leave out translations).
The Firefox installer on Win32 is almost half the size of Chrome, and the installed code is about half the size of Chrome as well. It's no wonder it uses less memory.
Increasing your WAP broadcast power does nothing to improve signal in the other direction, so while it will make your mobile devices show more bars, it won't actually improve network performance. TCP doesn't work unless a host can both send and receive (packets need to be ACKed), so even if the client receives further away from the WAP, it'll stop getting new packets if it can't notify the sender that those packets were received.
All that really happens when you increase broadcast power is an increase in interference with neighboring WAPs, which tends to lead other people to the conclusion that they also need to increase broadcast power in order to overcome the interference that you created.
As far as I know, OS X uses very little GNU-produced or GPL-licensed code. XCode has replaced gcc with LLVM as the default compiler, and Samba has been replaced with an Apple-created SMB/CIFS server.
That's actually an interesting question. If NVIDIA wants to use the Linux API in the way that Google used the Java API for Dalvik, they would need to create a kernel that was capable of operating a computer system and supported all of the APIs that the NVIDIA binary driver used. If such a system existed, and was able to run X11 and the binary drivers, they may be able to argue that their driver was capable of operating independently of Linux and was not, therefore a derived work. NVIDIA might even be able to start with a FreeBSD or other permissively licensed system and add the Linux APIs that they wanted to use. They still wouldn't be licensed to use the implementation that appears in Linux, but it might be more difficult to successfully prosecute them for publishing source code that used a compatible interface.
I don't think a court would fail to see such a blatant attempt to evade the obligations of creating a derived work of the Linux kernel, but I have no basis on which to predict whether they'd find such an evasion to be illegal.
The shim can only call non-GPL-only APIs in the kernel.
Code on Linux, whether it runs in kernel space or not, calls Linux kernel functions. In order to differentiate what will and will not be considered a "derived work" of the GPL licensed kernel, some APIs are specifically designated as being non-public. These interfaces do not appear in non-Linux operating systems, and developers cannot claim that code which uses those interfaces will function independently of Linux. If the code cannot function independent of Linux, it is a derived work under the terms of the GPL.
Public interfaces, for comparison, do appear in non-Linux operating systems. Bash can operate on FreeBSD because FreeBSD supports the APIs used by Bash. Bash, therefore, can function independently of Linux and is not a derived work.
IIRC Bain sold off Staples in the 90s when they became public, so at present those two companies have no association.
Yes, that's how Bain operates, as I pointed out. Bain increases revenue through acquisitions and then sells the company, leaving it with tremendous debt. Bain gets to claim that businesses do well while Bain has a controlling interest, largely because they divest their interest before the effects of the acquisition policy can affect the company.
However, even if they did, it wouldn't be because of Bain.
You think that making large debt payments during an economic recession doesn't impact the company's bottom line?
You are confused. Android systems are definitely Linux. TiVo is Linux. Many smart TVs are Linux systems. What all of those things are not is GNU systems. That's why GNU people suggest that you refer to GNU/Linux systems as such.
No one would suggest that Android is a GNU/Linux system, but it's definitely Linux. Anything written to run on Linux should work on an Android system. However, as Android does not feature a complete POSIX implementation, you would not expect an application written for a POSIX system to necessarily work on Android the way that you would expect it to run on a GNU system.
The cry that he doesn't have details is merely a tactic, because they have so little else of "meat" to argue.
That's a load of nonsense.
Mitt and Ann have said that they can't talk specifics, because that would give their critics a target. They've said that once they were elected, that there were going to be changes that people wouldn't like. They can't talk about their plans, because they know we won't vote for them if we know what they're going to do. That's good enough for me. If knowing their plans is going to make me not vote for them, then I have enough information to know that I don't want to vote for them.
Then there's Ryan. Questioned about how his budget plan would work, he replied that they hadn't run the numbers on it. That's really the essence of conservative thought today, in a nutshell. It's all ideology, and no data. They don't care enough to actually test their theories, or examine how they'll work in practice. They go with their gut and hope for the best. It's absolutely ridiculous.
I looked this up, and found that Bain Capital was actually responsible for the success of many companies that have tons of employees (Staples and Domino's among them.)
In a huge "fuck you" to Bain, Staples just published a press release titled "Staples, Inc. Announces Strategic Plan to Accelerate Growth" in which they announced plans to CLOSE 60 stores.
Bain's strategy is to take over a company with a small amount of their own cash and a large amount of debt. They increase the company's revenue through acquisitions (which may hide any revenue which is lost relative to the the sum of the individual company revenues prior to the acquisition), and sell their interest in the companies. The companies, meanwhile, have the responsibility of paying the debt that Bain used to take them over. http://www.salon.com/2012/10/02/how_mitt_romneys_bain_harvested_sealy_mattress_company/
I'm not going to say that half of those companies fail, but if you think that a failure rate of nearly half is acceptable, I have no idea what planet you're from. Failure rate among Bain's acquisitions is vastly higher than it is among operating businesses in general.
The DoE did make loans to some green energy companies that failed. Not "half", as Romney claimed during their debate, but less than 10%. That's in line with start-up businesses in general. It's disappointing, but realistic. That's not pilfering, it's not even a sign of bad choices.
Coincidentally, I'm nearing the end of a fascinating book on this exact topic. "The Last Lone Inventor: A Tale of Genius, Deceit, and the Birth of Television" by Evan Schwartz. The book documents the struggle of Philo Farnsworth to produce the first television.
The account is interesting for several reasons.
First, it really adds perspective to the "non-obvious" requirement for patents. In the 1920's Farnsworth found backers that paid hundreds of thousands of dollars, while the RCA group was paying MILLIONS of dollars to very gifted scientists in order to create the technology required to electronically scan images, transmit the scan, and reassemble the transmission into an image. Before Farnsworth, a lot of work was being done that probably never would have yielded a useful product. Compare that to Apple's snap-back-to-the-end scrolling.
The patent system is intended to be an exchange. Inventors who create technology whose working is not obvious, and could not be readily implemented without their documentation, provide complete documentation in exchange for a monopoly on its use. If we don't need any reference for their invention, then there's no reason for us, as a public, to grant them a monopoly. We get nothing in return. Monopoly on production is a precious commodity, and one we should not readily give away.
The other interesting aspect to the account is that it clearly describes a system where the inventor would have lost all of his investment, and all of his backers investments without the protection of the patent system. The RCA group, headed by David Sarnoff, was extremely predatory in the matter of the creation of television. The patent system offered some assurance to Farnsworth and the people who paid him and his staff, for years, to develop television that their investment would not be lost.
WebOS's failure in the market had nothing to do with native iOS apps. WebOS and its applications were great, but the implementation was awful. The OS wasn't stable, so the phones weren't reliable.
For usability, I was disappointed when I moved to an Android phone. However, having my alarms actually ring every time was quite welcome. I couldn't trust WebOS notifications.
First, AOSP isn't GPL for the most part. Aside from the Linux kernel, you're dealing mostly with the Apache 2.0 license, which includes different terms for distribution.
Second, the GPL license requires you to distribute the source if you distribute compiled object code. If you build and distribute, you are obligated to also distribute source. Those are the terms. A related issue was actually one of the motivations of the GPL v3. Under 2, you were obligated to distribute source if you distribute object code. There was some concern that those terms technically made BitTorrent distribution of GNU/Linux systems a violation of the license terms. The terms of GPL v3 clarified this and allowed simple redistribution.
Actually, you're missing the point. I can tell you have never had to support an existing corporate infrastructure that just can not upgrade to the "latest bleeding edge" because they don't have the resources to test everything possible code path to tell what broke, what works, etc.
I think you're missing the point. Mozilla hasn't changed the way version numbers work.
Because of demand from those corporate types, Mozilla now provides extended support releases. Both those and the standard releases use the widely recognised major.minor.patch versioning numbers. The current mainline release is 13.0.1, which is a patch update to version 13.
Everything you used to learn from version numbers, you still do. The difference is that each new release introduces fewer new features (which makes it more stable!), and releases happen more quickly.
The alternative is infrequent releases with many significant changes which haven't been widely tested. This is exactly what makes those.0 release something that users avoid. Making numerous major changes simultaneously drastically increases the amount of testing required. Users are going to find bugs under either release strategy, but with fewer new features per release, the number of bugs they'll find is drastically reduced, and typically so is the impact of those bugs.
But more important in my mind is this: The slow-release system is a symptom of the software sales revenue model. Businesses drive revenue by bundling up new features until there's enough to make a sales pitch. Users who buy a release get only bug fixes to that release, and no guarantee that all of the bugs will be addressed. Very often, buying the current version is the only way to get a bug fix. In Free Software, we don't have to deal with that garbage. The vendor isn't trying to sell us each upgrade, so they don't need to hold back new features.
The current numbering schema in FF is a "revision" number
No, it isn't. It's the same as it used to be.
How do I *easily* tell when a) features were added? and, b) features deprecated? and c) features removed?
The same way you always have: by checking the release notes. There's no additional complexity.
How many more versions do we have to go before they _finally_ fix the dam memory leak??
Firefox has been repeatedly demonstrated to use less memory than Chrome, for a long time. Chrome's advantages have been in a somewhat faster JavaScript engine and faster startup/new tab time. Firefox has a better plugin API (AdBlock can prevent advertisements from being loaded rather than merely preventing them from being displayed) and lower memory use. I prefer Firefox.
No, I'm not. In my experience, the commands available in powershell have consistent and descriptive naming, arguments and options, and documentation. A Unix shell environment typically has one of those at best.
The size of the executable code differs, but I think the remaining differences are exaggerated in your mind.
Your teletype is less complex than X11, but don't underestimate the complexity of tty handling, terminfo, and curses.
Your browser connects by shared memory; bash by unix pipes.
Your browser relays your input over http, but that shouldn't influence your perception of whether the interface is a CLI. Does bash cease to be a CLI when you connect over SSH? SSH is more complex than HTTP. Would Google's interface become a CLI if it were local rather than interfaced by HTTP?
Basically, I think your argument is.. simple and unconvincing.
I very rarely say anything good about Microsoft technology, but Powershell is actually really nice. It's consistent in a way that Unix shells aren't, and well documented. The commands are descriptive, unlike many Unix commands.
It's slow. Really, really slow. That one flaw aside, it's very well implemented and the competent Windows admins that I work with are very enthusiastic about it. I agree with them.
Yes, I'm suggesting that if you're a Windows admin and you don't know or like Powershell, you probably are less competent than those who do.
I know, they are providing the Tegra code upstream, so I guess it is kind if inacurate to use it as an example
I don't think it is. The value of Linux should not be underestimated. NVidia is able to use that platform free of charge. Since the Tegra hardware isn't a discrete component, NVidia can't (or can't easily) make improvements in a module separate from the Linux kernel, and are obligated to distribute source. It's not unfair to believe that they would not otherwise do so. They meet the minimum requirements of the license, but the value that they receive from the Linux and Android development communities is far greater than their contribution.
Saying that NVidia gives little back is pretty accurate, I think.
Slashdot Mirror
Then someone decided "options are bad" and started taking it all away.
The guiding thought is that every option MULTIPLIES code complexity. Options tend to interact with other options, and testing is required to verify that all options work together, or that the system provides a means of preventing options that don't from being used together. The drive to simplify interfaces is intended to reduce the number of bugs present in the system.
As a secondary effect, removing optional behavior forces developers to make sure that the normal behavior is sane and doesn't need dozens of radio buttons on a configuration app.
GNOME Shell is universally hated.
No, it isn't. I have a number of non-tech friends (and my mom) who use Fedora with GNOME Shell. I use Fedora with GNOME Shell. I know a fairly large number of GNU/Linux users, and very few of them actually hate GNOME Shell. Not none, but few. For my part, I think notifications aren't very good, but otherwise the system does what it's supposed to. It stays out of my way. It isn't distracting and it uses minimal screen space. I like those things quite a lot.
Thus, they figure, it's better to remove every shred of choice. Because, you know, choice is hard and confusing.
People continue to repeat this reasoning, attributed to various developers, but that doesn't make it true. The guiding thought is not that users cannot make choices. It is that every option MULTIPLIES code complexity. Options tend to interact with other options, and testing is required to verify that all options work together, or that the system provides a means of preventing options that don't from being used together. The drive to simplify interfaces is intended to reduce the number of bugs present in the system.
As a secondary effect, removing optional behavior forces developers to make sure that the normal behavior is sane and doesn't need dozens of radio buttons on a configuration app.
being a memory hog
I understand people talking about Chrome being a faster browser, and I don't begrudge them that. However, anyone who contends that Chrome uses less memory doesn't know what they're talking about. Firefox uses less memory, is a smaller download, and is a much smaller installation than Chrome (particularly if you only measure code and leave out translations).
The Firefox installer on Win32 is almost half the size of Chrome, and the installed code is about half the size of Chrome as well. It's no wonder it uses less memory.
PLEASE STOP OFFERING THIS ADVICE.
Increasing your WAP broadcast power does nothing to improve signal in the other direction, so while it will make your mobile devices show more bars, it won't actually improve network performance. TCP doesn't work unless a host can both send and receive (packets need to be ACKed), so even if the client receives further away from the WAP, it'll stop getting new packets if it can't notify the sender that those packets were received.
All that really happens when you increase broadcast power is an increase in interference with neighboring WAPs, which tends to lead other people to the conclusion that they also need to increase broadcast power in order to overcome the interference that you created.
As far as I know, OS X uses very little GNU-produced or GPL-licensed code. XCode has replaced gcc with LLVM as the default compiler, and Samba has been replaced with an Apple-created SMB/CIFS server.
That's actually an interesting question. If NVIDIA wants to use the Linux API in the way that Google used the Java API for Dalvik, they would need to create a kernel that was capable of operating a computer system and supported all of the APIs that the NVIDIA binary driver used. If such a system existed, and was able to run X11 and the binary drivers, they may be able to argue that their driver was capable of operating independently of Linux and was not, therefore a derived work. NVIDIA might even be able to start with a FreeBSD or other permissively licensed system and add the Linux APIs that they wanted to use. They still wouldn't be licensed to use the implementation that appears in Linux, but it might be more difficult to successfully prosecute them for publishing source code that used a compatible interface.
I don't think a court would fail to see such a blatant attempt to evade the obligations of creating a derived work of the Linux kernel, but I have no basis on which to predict whether they'd find such an evasion to be illegal.
The shim can only call non-GPL-only APIs in the kernel.
Code on Linux, whether it runs in kernel space or not, calls Linux kernel functions. In order to differentiate what will and will not be considered a "derived work" of the GPL licensed kernel, some APIs are specifically designated as being non-public. These interfaces do not appear in non-Linux operating systems, and developers cannot claim that code which uses those interfaces will function independently of Linux. If the code cannot function independent of Linux, it is a derived work under the terms of the GPL.
Public interfaces, for comparison, do appear in non-Linux operating systems. Bash can operate on FreeBSD because FreeBSD supports the APIs used by Bash. Bash, therefore, can function independently of Linux and is not a derived work.
No, this is the sort of thing I'm talking about:
http://thinkprogress.org/election/2012/10/07/972501/gop-strategist-admits-romney-is-witholding-details-of-his-tax-plan-to-avoid-criticism/
That line of reasoning has been the campaign's excuse for not being specific about their tax plans.
IIRC Bain sold off Staples in the 90s when they became public, so at present those two companies have no association.
Yes, that's how Bain operates, as I pointed out. Bain increases revenue through acquisitions and then sells the company, leaving it with tremendous debt. Bain gets to claim that businesses do well while Bain has a controlling interest, largely because they divest their interest before the effects of the acquisition policy can affect the company.
However, even if they did, it wouldn't be because of Bain.
You think that making large debt payments during an economic recession doesn't impact the company's bottom line?
You are confused. Android systems are definitely Linux. TiVo is Linux. Many smart TVs are Linux systems. What all of those things are not is GNU systems. That's why GNU people suggest that you refer to GNU/Linux systems as such.
No one would suggest that Android is a GNU/Linux system, but it's definitely Linux. Anything written to run on Linux should work on an Android system. However, as Android does not feature a complete POSIX implementation, you would not expect an application written for a POSIX system to necessarily work on Android the way that you would expect it to run on a GNU system.
Do you see the difference now?
That's a load of nonsense.
Mitt and Ann have said that they can't talk specifics, because that would give their critics a target. They've said that once they were elected, that there were going to be changes that people wouldn't like. They can't talk about their plans, because they know we won't vote for them if we know what they're going to do. That's good enough for me. If knowing their plans is going to make me not vote for them, then I have enough information to know that I don't want to vote for them.
Then there's Ryan. Questioned about how his budget plan would work, he replied that they hadn't run the numbers on it. That's really the essence of conservative thought today, in a nutshell. It's all ideology, and no data. They don't care enough to actually test their theories, or examine how they'll work in practice. They go with their gut and hope for the best. It's absolutely ridiculous.
In a huge "fuck you" to Bain, Staples just published a press release titled "Staples, Inc. Announces Strategic Plan to Accelerate Growth" in which they announced plans to CLOSE 60 stores.
Bain's strategy is to take over a company with a small amount of their own cash and a large amount of debt. They increase the company's revenue through acquisitions (which may hide any revenue which is lost relative to the the sum of the individual company revenues prior to the acquisition), and sell their interest in the companies. The companies, meanwhile, have the responsibility of paying the debt that Bain used to take them over.
http://www.salon.com/2012/10/02/how_mitt_romneys_bain_harvested_sealy_mattress_company/
I'm not going to say that half of those companies fail, but if you think that a failure rate of nearly half is acceptable, I have no idea what planet you're from. Failure rate among Bain's acquisitions is vastly higher than it is among operating businesses in general.
The DoE did make loans to some green energy companies that failed. Not "half", as Romney claimed during their debate, but less than 10%. That's in line with start-up businesses in general. It's disappointing, but realistic. That's not pilfering, it's not even a sign of bad choices.
I think you're going for a joke in there, but how often is government actually less efficient than big business?
Coincidentally, I'm nearing the end of a fascinating book on this exact topic. "The Last Lone Inventor:
A Tale of Genius, Deceit, and the Birth of Television" by Evan Schwartz. The book documents the struggle of Philo Farnsworth to produce the first television.
The account is interesting for several reasons.
First, it really adds perspective to the "non-obvious" requirement for patents. In the 1920's Farnsworth found backers that paid hundreds of thousands of dollars, while the RCA group was paying MILLIONS of dollars to very gifted scientists in order to create the technology required to electronically scan images, transmit the scan, and reassemble the transmission into an image. Before Farnsworth, a lot of work was being done that probably never would have yielded a useful product. Compare that to Apple's snap-back-to-the-end scrolling.
The patent system is intended to be an exchange. Inventors who create technology whose working is not obvious, and could not be readily implemented without their documentation, provide complete documentation in exchange for a monopoly on its use. If we don't need any reference for their invention, then there's no reason for us, as a public, to grant them a monopoly. We get nothing in return. Monopoly on production is a precious commodity, and one we should not readily give away.
The other interesting aspect to the account is that it clearly describes a system where the inventor would have lost all of his investment, and all of his backers investments without the protection of the patent system. The RCA group, headed by David Sarnoff, was extremely predatory in the matter of the creation of television. The patent system offered some assurance to Farnsworth and the people who paid him and his staff, for years, to develop television that their investment would not be lost.
WebOS's failure in the market had nothing to do with native iOS apps. WebOS and its applications were great, but the implementation was awful. The OS wasn't stable, so the phones weren't reliable.
For usability, I was disappointed when I moved to an Android phone. However, having my alarms actually ring every time was quite welcome. I couldn't trust WebOS notifications.
First, AOSP isn't GPL for the most part. Aside from the Linux kernel, you're dealing mostly with the Apache 2.0 license, which includes different terms for distribution.
Second, the GPL license requires you to distribute the source if you distribute compiled object code. If you build and distribute, you are obligated to also distribute source. Those are the terms. A related issue was actually one of the motivations of the GPL v3. Under 2, you were obligated to distribute source if you distribute object code. There was some concern that those terms technically made BitTorrent distribution of GNU/Linux systems a violation of the license terms. The terms of GPL v3 clarified this and allowed simple redistribution.
Actually, most of Microsoft's development tools refer to the architecture as AMD64.
Remember that you're not buying games, you're donating to charity! Give generously!
I think you're missing the point. Mozilla hasn't changed the way version numbers work.
Because of demand from those corporate types, Mozilla now provides extended support releases. Both those and the standard releases use the widely recognised major.minor.patch versioning numbers. The current mainline release is 13.0.1, which is a patch update to version 13.
Everything you used to learn from version numbers, you still do. The difference is that each new release introduces fewer new features (which makes it more stable!), and releases happen more quickly.
The alternative is infrequent releases with many significant changes which haven't been widely tested. This is exactly what makes those .0 release something that users avoid. Making numerous major changes simultaneously drastically increases the amount of testing required. Users are going to find bugs under either release strategy, but with fewer new features per release, the number of bugs they'll find is drastically reduced, and typically so is the impact of those bugs.
But more important in my mind is this: The slow-release system is a symptom of the software sales revenue model. Businesses drive revenue by bundling up new features until there's enough to make a sales pitch. Users who buy a release get only bug fixes to that release, and no guarantee that all of the bugs will be addressed. Very often, buying the current version is the only way to get a bug fix. In Free Software, we don't have to deal with that garbage. The vendor isn't trying to sell us each upgrade, so they don't need to hold back new features.
No, it isn't. It's the same as it used to be.
The same way you always have: by checking the release notes. There's no additional complexity.
Firefox has been repeatedly demonstrated to use less memory than Chrome, for a long time. Chrome's advantages have been in a somewhat faster JavaScript engine and faster startup/new tab time. Firefox has a better plugin API (AdBlock can prevent advertisements from being loaded rather than merely preventing them from being displayed) and lower memory use. I prefer Firefox.
No, I'm not. In my experience, the commands available in powershell have consistent and descriptive naming, arguments and options, and documentation. A Unix shell environment typically has one of those at best.
The size of the executable code differs, but I think the remaining differences are exaggerated in your mind.
Your teletype is less complex than X11, but don't underestimate the complexity of tty handling, terminfo, and curses.
Your browser connects by shared memory; bash by unix pipes.
Your browser relays your input over http, but that shouldn't influence your perception of whether the interface is a CLI. Does bash cease to be a CLI when you connect over SSH? SSH is more complex than HTTP. Would Google's interface become a CLI if it were local rather than interfaced by HTTP?
Basically, I think your argument is .. simple and unconvincing.
I very rarely say anything good about Microsoft technology, but Powershell is actually really nice. It's consistent in a way that Unix shells aren't, and well documented. The commands are descriptive, unlike many Unix commands.
It's slow. Really, really slow. That one flaw aside, it's very well implemented and the competent Windows admins that I work with are very enthusiastic about it. I agree with them.
Yes, I'm suggesting that if you're a Windows admin and you don't know or like Powershell, you probably are less competent than those who do.
udev is usable without systemd. They are maintained in a single code base because there's a lot of shared code.
Which makes your argument funny... The reasons you'd dislike systemd are pretty much exactly the reasons people didn't like udev to begin with.
I know, they are providing the Tegra code upstream, so I guess it is kind if inacurate to use it as an example
I don't think it is. The value of Linux should not be underestimated. NVidia is able to use that platform free of charge. Since the Tegra hardware isn't a discrete component, NVidia can't (or can't easily) make improvements in a module separate from the Linux kernel, and are obligated to distribute source. It's not unfair to believe that they would not otherwise do so. They meet the minimum requirements of the license, but the value that they receive from the Linux and Android development communities is far greater than their contribution.
Saying that NVidia gives little back is pretty accurate, I think.