I'm sure in 20 years we'll find German plans to make ray guns, giant mech fighers, etc. Castle Wolfenstein game plots seems less & less like fiction as the years go on.:)
Well, you know, there was a whole architectural movement in Germany based on the idea of building interiors on a regular grid, with 8-foot thick walls and no variation in elevation...
So if someone is committed to the "four freedoms", they will likely complain about GPL violations, but also violate the copyrights of others: e.g., perhaps someone wants to run OS X on their non-Apple hardware (definitely invoking freedoms 1, 2, and possibly 3 and 4). That's not hypocritical, but in fact principled.
Believing in the four freedoms and applying them to one's own software is one thing. Disregarding the copyright of others to suit one's personal tastes is completely another.
What I disagree with here is the assumption that those who choose one necessarily choose the other.
Nintendo is the belligerent party here, for preventing developers from licensing Wii games in certain ways.
Nope, not at all. It's Nintendo's choice to choose not to use open source software. You have no right to force them to do so which is what you are implying. Open source supporters talk about freedoms all the time - that includes an individuals or a companies freedom to choose not to use open source.
You extremists make the rest of us look bad - knock it off.
It's not about Nintendo not using open source software, it's about them not allowing Wii platform developers to make public any source code that uses the Wii SDK.
I still agree with you, I find the situation distasteful but I don't think Nintendo is in the wrong here. But nevertheless, it's a different issue from what you describe...
ScummVM released their software under the GPL. They did not do this with the intention of preventing Wii development, they did it with the intention of ensuring that all copies of their code, including modified copies, remain open source. ScummVM's developers would love to see ScummVM running on the Wii, and they did not attack anyone for doing this; Nintendo is the belligerent party here, for preventing developers from licensing Wii games in certain ways.
I wouldn't exactly say they're belligerent. They are just defensive about their SDK. Developers are required to agree to a non-disclosure agreement in order to get access to the SDK. This, I believe, is why GPL software cannot be used in published Wii products: developers are not allowed to disclose information about the SDK. Working code that uses that SDK would count as "information about the SDK".
For us "Free Software" lovers it's not a policy we're likely to appreciate - but I don't think it's unreasonable either. It was the developers (Mistic in particular) who created this mess, resulting in a situation where Atari can't satisfy the conflicting agreements that would allow them to sell the games.
There is no reason for Nintendo to ban any open source licenses. Third party developers are not able to use GPLv3 code because they are not allowed to distribute the signing key and so can't comply with the GPLv3 irrespective of whether Nintendo explicitly forbids them. Other licenses have no such problems.
For whatever reason, Nintendo does not want developers releasing information about the Nintendo SDK. I'm not sure why, I guess they don't want people publishing SDK information in a way in which others could then derive a "clean room" reconstruction of it - for instance as a compatibility layer to make it easier to port Wii games to other consoles.
A game written using that SDK would fall under that category. It's not specifically open source they have a problem with, as far as I can tell - Nintendo just doesn't allow developers to release their source code publicly, thus Atari can't fulfill the terms of the GPL, which would require them to release the source code for the ScummVM game engine along with the changes made to make it run on the Wii.
So if I understand the situation correctly - Nintendo does not ban open source licenses, they just ban open distribution of code written for the Wii SDK - meaning developers bound under developer agreements can't also fulfill their obligations under GPL-style licenses if they modify GPL code for their projects. Open source licenses without that requirement (more on the BSD end of the spectrum) would be fine. (Again, if I am understanding the situation correctly.)
I'm certain I'm not alone when I say "Way to go, nintendo".
I know why they did it, there has been a constant worry from closed-source developers that the GPL would force closed source code open. Nintendo is just covering their ass.
That's not it, exactly.
The demands of the GPL would have only forced the code of the game engine itself to be opened - that is, the version of ScummVM modified to work on the Wii using the Wii SDK. If the demands of the GPL license were incompatible with another agreement pertaining to the code, neither agreement would be nullified by this conflict - Atari would simply lose the ability to distribute the game.
So there's no way this could force Nintendo source code to be opened. That isn't what Nintendo is defending themselves against here.
Rather, it sounds like Nintendo only releases the Wii SDK to developers under a non-disclosure agreement. Under the terms of the agreement, I guess, publishing source code that uses SDK functions counts as disclosure. If my understanding is correct, Nintendo isn't specifically targeting open source software here - they just don't want developers to disclose the SDK or information about it... A requirement to publish source code would obviously conflict with that. So some "open source" software would be fine (for instance, Python) in a Wii game, but anything GPL wouldn't be, due to that conflict.
What's more likely is this response: OMG! GPL was violated! String Atari up by their balls!!11!!1! The GPL is sacred and must not be blasphemed like this. Grab your torches and pitchforks... we're going on a witch hunt!
What's even more ironic is that those very same people probably have no qualms violating the copyright of Apple, MSFT, members of the RIAA or the MPAA. That is hypocrisy at its finest.
I don't know who these hypothetical people are, who you're talking about... It seems that when you're talking about imaginary people you can apply whatever level of hypocrisy to their opinions that you like - in reality, I suspect you're seeing different groups of people who post on Slashdot and assuming they all hold the same set of opinions... More "groupthink" bullshit...
Based on what people posted for the Jammie Thomas $1.92 million settlement article, opinions will likely be divided into these different viewpoints:
1. Atari should pay 3x the retail cost of the GPL code. 3 x $0 = $0 2. It's only copyright which should be abolished anyways, no harm no foul 3. Code wants to be free, man... why is the GPL holding it back?
What's more likely is this response: OMG! GPL was violated! String Atari up by their balls!!11!!1! The GPL is sacred and must not be blasphemed like this. Grab your torches and pitchforks... we're going on a witch hunt!
Lovely to see such a glob of cynicism and general bad-attitude get modded "insightful". "Everyone here is a spaz and will automatically go out of their way to be offended!" +5 insightful! Blah.
Really, the whole thing just seems like an unfortunate mess brought on by the unscrupulous (or careless?) practices of one of the subcontractors working on the project. I feel bad for Atari in this position - they funded this release and now they need to essentially pull it, all because Mistic software decided to take a little shortcut.
You may or may not agree with the GPL, but the fact is that the ScummVM team has put in years of development and testing on that project - they published their code and declared the terms under which it could be used. Mistic should have known what the terms of ScummVM were and known it wasn't suitable for what they were hired to do. They screwed up and almost certainly cost Atari a lot of money as a result. One would hope this would make others think twice before contracting their services in the future.
It is a bit unfortunate that this kind of thing reinforces the idea that the GPL is a "trap"... It's true to a certain extent, with any published, copyrighted code, that there's a legal danger that someone (like a developer) will use that code without being clear about the legal implications of doing so...
Wouldn't the Iraqi government have to sign off on that, since Iraq is sovereign nation? I suspect there is enough Iranian influence that they would not allow it.
I'm sorry, what?
We're the United States of America. Hadn't you heard? We'll just find some excuse to make the Monroe Doctrine apply to the Middle East and we'll call it good. If Iraq doesn't like it, they know where to find us.
It is and it isn't. People can only learn so much about the world around them without focused study. I think science has just passed the point where laymen can be expected to absorb all of it.
No, no... that hasn't happened yet... It's going to be...
wait for it...
Now. Now laymen can no longer be expected to absorb all of science. (Seriously, was there ever a time when laymen could be expected to absorb all of science?)
What I took away from Lockhart's essay was that the concept is more important than the notation - not that the notation isn't valuable at all, just that it isn't necessary for simple problems, and by sharing the joy of the simple problems, you can get students to think.
For simple problems, this may be true. For moderately complex problems, I think the weight of the less compact representation outweighs the cost of learning to work in a more compact representation.
The problem is that many of the concepts that come into play in these problems aren't readily represented in everyday language. So the first time you introduce the concept, of course, you have to provide a full explanation of the concept in terms the reader can understand - thereafter, if you've introduced notation to represent the concept, you can rely upon that. Otherwise, each time you use the concept, you need to represent it using language that evokes that original explanation.
Imagine, for instance, using the concept "square root" without introducing symbols or language which would encapsulate that concept. Thus, every time you use the concept "square root" you would have to say something like "that which, when multiplied by itself, equals this". Or picture trying to represent moderately complex equations in written form without the use of parentheses or any other notation which "contains" parts of the expression - this would really hurt the expressive power of the notation.
These seem like extreme examples, but it's basically the same thing. The students are being introduced to a concept which is, to some extent, alien to them. To work with that concept, they need to put some kind of handle on it, something that conveniently and unambiguously refers to "that thing we learned about last week". Whether it's a word they've never seen before, or a symbol they've never seen before makes little difference - but I really think it's sensible to include this right from the start.
Profit can be made here by people who don't underestimate how big Linux is as it is. If you could get all of them to buy something for $20, wouldn't that be worth it? Games come to mind here.
How are you going to sell an application to all the Linux users? Personally I feel like paying for software often runs against the culture of the Linux userbase - not that "free as in gratis" is necessarily why we're using Free Software - but it's a nice bonus and I think we tend to stick to it quite a lot.
I agree with your overall premise, but the money flying around Linux has to be flowing for a reason. It certainly is now, and if it's for popularity's sake, that may not grow as fast as some people would hope or predict. But even without growing popularity, there's still money there. It's not the only reason for the push.
Basically people put money into Linux because they see the potential to get something out of it. (And I have no problem with that, BTW!)
For instance, Tivo or TomTom - they've taken Linux and used it as an embedded platform that provides a lot of their basic needs.
There would be two challenges with this kind of effort:
The first is the technical aspect: building an application such that people can make this sort of change without getting elbow-deep in the code, providing a convenient framework for posting changes, etc. Some of this we more or less have already (i18n string substitution, separation of GUI layout from program code via things like Glade, etc.)
The second is the logistical support: a site or sites where all these submissions can be stored, administrators to filter out all the trolls and vandals, not to mention the flat-out bad ideas, and someone to provide leadership, helping to promote promising ideas over less promising ones.
One of the basic problems with this type of system is that it actually isn't "self regulating" or "self maintaining". Not everyone who uses the system is your friend. Not everyone who uses the system will fully research the available user-submitted options (more commonly, I think, people will try no more than a few of the most visible options) - so good work can be lost in the pile of submissions, while mediocrity "designed by committee" (or "mob" - a committee has more organization than a bunch of random submitters) may become prevalent.
Additionally (and this was part of the point of the article) - the quality of any solution isn't defined in a vacuum - for instance, if the user is already familiar with one UI design, that design has a certain advantage over another, competing design. If you learn where all the commands are located in the menus, and then everything gets moved, that's disruptive. Likewise if none of the documentation for the application applies to your version, that's rather unhelpful. This means it's often more helpful to have one design thoughtfully worked out and heavily promoted by the core team, rather than a cadre of competing designs.
In the "High School Geometry" section, Lockhart talks about how a fairly simple idea - that when two lines cross, the angles on opposing sides of the crossing point will be equal - is turned into a complex and ugly chunk of notation... Lines must be identified as "AB" (with a bar over the top), there's notation for identifying the angle formed by three points, and the whole, simple idea is then backed up with a hefty "proof" in place of a simple, natural-language explanation.
Now, I don't quite agree with all of this. Maybe that's because it worked for me, and because I enjoy the idea of mathematics and logic having their own "language", and their own notation. I mean, sure, back then I always used to wonder why they threw all those Greek letters at us - in some cases it seemed totally arbitrary. Some of it is just long-standing tradition: like the capital Sigma or the long-s glyph used for summation and integration...
But what I enjoy about the use of these symbols is that they provide a compact way of identifying precisely what one is talking about. That these characters aren't part of everyday English writing means that they can be set aside to encapsulate powerful, specialized ideas.
The whole "proofs" thing worked out just fine for me, too. I think it makes sense: as part of teaching people how to build up simple ideas to form an argument in support of a more complicated idea, provide examples of how to do this: even with the simplest of ideas, the things that lend themselves most readily to intuitive understanding... If a proof is provided for a problem people naturally understand to begin with, then it will help them to understand how the proof works.
With regard to line and angle notation I think Lockhart is dead wrong. In the context of the "crossed lines" example he argues that the lines could be called "line a" and "line b" or something - and that the whole idea should be presented in a more conversational style. This could work for certain problems - especially really simple problems like that one - but there are other problems with expressing things in a conversational style. For starters, natural language is imprecise - at least the way most people use it. Precise natural language is the domain, for instance, of lawyers and logicians. It tends to be very heavy, often with its own specialized vocabulary that people don't readily understand on first exposure. Codifying the problem makes it less accessible, but also much more precise and concise.
Now, if I'd learned "High school geometry" in high school instead of, you know, 5th grade or whatever, it's possible things would have played out differently... As it stands, however, I'm a big fan of taking advantage of domain-specific vocabulary and symbols where they are available and useful.
"no real support" ? whatever do you mean, there is infinitely better support and drivers from nvidia than from intel or ati. ATI's driver doesn't compile on latest kernels without voodoo
Aw, hell... Why do I need an old 3dFX card installed just to get my ATI card working??
You linux folk should be grateful for the fact that they release a driver at all. It's not like they get any return for creating a driver that allows a handful of people to run a hardware accelerated compiz desktops.
"Troll", huh? I don't know. I actually think this is a pretty reasonable perspective. NVidia must have had their reasons for releasing drivers for Linux - honestly, though, I don't know what those reasons would be.
Until linux becomes a viable platform for the desktop (which it never will be, because of flawed ideologies), be thankful for any corporate *desktop* support you get.
This part, though... ho hum. Any time somebody talks about "Linux on the desktop" my brain shuts down. It's just such a boring issue. I don't care. I don't care if "grandma" can't figure Linux out. Linux is on my desktop (and laptop) and I quite enjoy it.
Damned if I know what flawed ideologies you refer to... but I am curious.
Google gives you Java (for App Store), but their own applications run native code?
Yes, because they want everything in the app store to be forward compatible: in future Android might run on chips that are not ARM, so native code would break, and though it would be the developers' fault it would still make their app store look bad.
That's great for Google and all - but it doesn't do much for me, you know?
As a user I want people to be able to port existing code pretty easily, and to be able to write new code that fully utilizes the power of the machine. From my perspective as a user, there's no advantage to the phone running a VM. From my perspective as a developer, the fact that the phone runs a VM for all third-party software is actually pretty distasteful. This is an embedded platform we're talking about... It hasn't got a ton of on-board storage, and wasted processor cycles mean wasted battery, too.
Slashdot Mirror
This makes me real glad that mine is the right side of the bed...
I'm sure in 20 years we'll find German plans to make ray guns, giant mech fighers, etc. Castle Wolfenstein game plots seems less & less like fiction as the years go on. :)
Well, you know, there was a whole architectural movement in Germany based on the idea of building interiors on a regular grid, with 8-foot thick walls and no variation in elevation...
So if someone is committed to the "four freedoms", they will likely complain about GPL violations, but also violate the copyrights of others: e.g., perhaps someone wants to run OS X on their non-Apple hardware (definitely invoking freedoms 1, 2, and possibly 3 and 4). That's not hypocritical, but in fact principled.
Believing in the four freedoms and applying them to one's own software is one thing. Disregarding the copyright of others to suit one's personal tastes is completely another.
What I disagree with here is the assumption that those who choose one necessarily choose the other.
Nintendo is the belligerent party here, for preventing developers from licensing Wii games in certain ways.
Nope, not at all. It's Nintendo's choice to choose not to use open source software. You have no right to force them to do so which is what you are implying. Open source supporters talk about freedoms all the time - that includes an individuals or a companies freedom to choose not to use open source.
You extremists make the rest of us look bad - knock it off.
It's not about Nintendo not using open source software, it's about them not allowing Wii platform developers to make public any source code that uses the Wii SDK.
I still agree with you, I find the situation distasteful but I don't think Nintendo is in the wrong here. But nevertheless, it's a different issue from what you describe...
ScummVM released their software under the GPL. They did not do this with the intention of preventing Wii development, they did it with the intention of ensuring that all copies of their code, including modified copies, remain open source. ScummVM's developers would love to see ScummVM running on the Wii, and they did not attack anyone for doing this; Nintendo is the belligerent party here, for preventing developers from licensing Wii games in certain ways.
I wouldn't exactly say they're belligerent. They are just defensive about their SDK. Developers are required to agree to a non-disclosure agreement in order to get access to the SDK. This, I believe, is why GPL software cannot be used in published Wii products: developers are not allowed to disclose information about the SDK. Working code that uses that SDK would count as "information about the SDK".
For us "Free Software" lovers it's not a policy we're likely to appreciate - but I don't think it's unreasonable either. It was the developers (Mistic in particular) who created this mess, resulting in a situation where Atari can't satisfy the conflicting agreements that would allow them to sell the games.
There is no reason for Nintendo to ban any open source licenses. Third party developers are not able to use GPLv3 code because they are not allowed to distribute the signing key and so can't comply with the GPLv3 irrespective of whether Nintendo explicitly forbids them. Other licenses have no such problems.
For whatever reason, Nintendo does not want developers releasing information about the Nintendo SDK. I'm not sure why, I guess they don't want people publishing SDK information in a way in which others could then derive a "clean room" reconstruction of it - for instance as a compatibility layer to make it easier to port Wii games to other consoles.
A game written using that SDK would fall under that category. It's not specifically open source they have a problem with, as far as I can tell - Nintendo just doesn't allow developers to release their source code publicly, thus Atari can't fulfill the terms of the GPL, which would require them to release the source code for the ScummVM game engine along with the changes made to make it run on the Wii.
So if I understand the situation correctly - Nintendo does not ban open source licenses, they just ban open distribution of code written for the Wii SDK - meaning developers bound under developer agreements can't also fulfill their obligations under GPL-style licenses if they modify GPL code for their projects. Open source licenses without that requirement (more on the BSD end of the spectrum) would be fine. (Again, if I am understanding the situation correctly.)
I'm certain I'm not alone when I say "Way to go, nintendo".
I know why they did it, there has been a constant worry from closed-source developers that the GPL would force closed source code open. Nintendo is just covering their ass.
That's not it, exactly.
The demands of the GPL would have only forced the code of the game engine itself to be opened - that is, the version of ScummVM modified to work on the Wii using the Wii SDK. If the demands of the GPL license were incompatible with another agreement pertaining to the code, neither agreement would be nullified by this conflict - Atari would simply lose the ability to distribute the game.
So there's no way this could force Nintendo source code to be opened. That isn't what Nintendo is defending themselves against here.
Rather, it sounds like Nintendo only releases the Wii SDK to developers under a non-disclosure agreement. Under the terms of the agreement, I guess, publishing source code that uses SDK functions counts as disclosure. If my understanding is correct, Nintendo isn't specifically targeting open source software here - they just don't want developers to disclose the SDK or information about it... A requirement to publish source code would obviously conflict with that. So some "open source" software would be fine (for instance, Python) in a Wii game, but anything GPL wouldn't be, due to that conflict.
What's more likely is this response: OMG! GPL was violated! String Atari up by their balls!!11!!1! The GPL is sacred and must not be blasphemed like this. Grab your torches and pitchforks... we're going on a witch hunt!
What's even more ironic is that those very same people probably have no qualms violating the copyright of Apple, MSFT, members of the RIAA or the MPAA. That is hypocrisy at its finest.
I don't know who these hypothetical people are, who you're talking about... It seems that when you're talking about imaginary people you can apply whatever level of hypocrisy to their opinions that you like - in reality, I suspect you're seeing different groups of people who post on Slashdot and assuming they all hold the same set of opinions... More "groupthink" bullshit...
Based on what people posted for the Jammie Thomas $1.92 million settlement article, opinions will likely be divided into these different viewpoints:
1. Atari should pay 3x the retail cost of the GPL code. 3 x $0 = $0
2. It's only copyright which should be abolished anyways, no harm no foul
3. Code wants to be free, man... why is the GPL holding it back?
What's more likely is this response: OMG! GPL was violated! String Atari up by their balls!!11!!1! The GPL is sacred and must not be blasphemed like this. Grab your torches and pitchforks... we're going on a witch hunt!
Lovely to see such a glob of cynicism and general bad-attitude get modded "insightful". "Everyone here is a spaz and will automatically go out of their way to be offended!" +5 insightful! Blah.
Really, the whole thing just seems like an unfortunate mess brought on by the unscrupulous (or careless?) practices of one of the subcontractors working on the project. I feel bad for Atari in this position - they funded this release and now they need to essentially pull it, all because Mistic software decided to take a little shortcut.
You may or may not agree with the GPL, but the fact is that the ScummVM team has put in years of development and testing on that project - they published their code and declared the terms under which it could be used. Mistic should have known what the terms of ScummVM were and known it wasn't suitable for what they were hired to do. They screwed up and almost certainly cost Atari a lot of money as a result. One would hope this would make others think twice before contracting their services in the future.
It is a bit unfortunate that this kind of thing reinforces the idea that the GPL is a "trap"... It's true to a certain extent, with any published, copyrighted code, that there's a legal danger that someone (like a developer) will use that code without being clear about the legal implications of doing so...
Why can't we just let people revolt without our interference?
Because in the history of revolting THAT IS WHAT HAS ALWAYS HAPPENED
In the history of revolting your mom occupies a field of study all her own.
Wouldn't the Iraqi government have to sign off on that, since Iraq is sovereign nation? I suspect there is enough Iranian influence that they would not allow it.
I'm sorry, what?
We're the United States of America. Hadn't you heard? We'll just find some excuse to make the Monroe Doctrine apply to the Middle East and we'll call it good. If Iraq doesn't like it, they know where to find us.
Give the handsets to the guys who smuggle booze in over the Turkish border. They've been giving Iranian authorities the runaround for years.
Never underestimate the bandwidth of a booze-smuggling cart filled with backup tapes.
This is fairly disturbing.
It is and it isn't. People can only learn so much about the world around them without focused study. I think science has just passed the point where laymen can be expected to absorb all of it.
No, no... that hasn't happened yet... It's going to be...
wait for it...
Now. Now laymen can no longer be expected to absorb all of science. (Seriously, was there ever a time when laymen could be expected to absorb all of science?)
Almost makes me want to move to one of those oppressive totalitarian regimes, just for the free Wi-Fi. I hear it's better than Verizon.
RIAA violation, "Weird" Al Yankovic wants his royalty check for you ripping off his song lyrics. :)
I'll sue ya!
I'll take all of your money
I'll sue ya!
If you even look at me funny
What kinda chip you got in there, a Dorito?
Well, wasn't there a version of Space Harrier for the C-64? Plus some flight simulators I'm sure...
Then it's settled. I'm getting a Commodore instead.
ill go you one better ill get a Commodore 64.
If you want to go one better ill, then you'd better get not only the Commodore 64 but also the ill peripheral.
What I took away from Lockhart's essay was that the concept is more important than the notation - not that the notation isn't valuable at all, just that it isn't necessary for simple problems, and by sharing the joy of the simple problems, you can get students to think.
For simple problems, this may be true. For moderately complex problems, I think the weight of the less compact representation outweighs the cost of learning to work in a more compact representation.
The problem is that many of the concepts that come into play in these problems aren't readily represented in everyday language. So the first time you introduce the concept, of course, you have to provide a full explanation of the concept in terms the reader can understand - thereafter, if you've introduced notation to represent the concept, you can rely upon that. Otherwise, each time you use the concept, you need to represent it using language that evokes that original explanation.
Imagine, for instance, using the concept "square root" without introducing symbols or language which would encapsulate that concept. Thus, every time you use the concept "square root" you would have to say something like "that which, when multiplied by itself, equals this". Or picture trying to represent moderately complex equations in written form without the use of parentheses or any other notation which "contains" parts of the expression - this would really hurt the expressive power of the notation.
These seem like extreme examples, but it's basically the same thing. The students are being introduced to a concept which is, to some extent, alien to them. To work with that concept, they need to put some kind of handle on it, something that conveniently and unambiguously refers to "that thing we learned about last week". Whether it's a word they've never seen before, or a symbol they've never seen before makes little difference - but I really think it's sensible to include this right from the start.
Profit can be made here by people who don't underestimate how big Linux is as it is. If you could get all of them to buy something for $20, wouldn't that be worth it? Games come to mind here.
How are you going to sell an application to all the Linux users? Personally I feel like paying for software often runs against the culture of the Linux userbase - not that "free as in gratis" is necessarily why we're using Free Software - but it's a nice bonus and I think we tend to stick to it quite a lot.
I agree with your overall premise, but the money flying around Linux has to be flowing for a reason. It certainly is now, and if it's for popularity's sake, that may not grow as fast as some people would hope or predict. But even without growing popularity, there's still money there. It's not the only reason for the push.
Basically people put money into Linux because they see the potential to get something out of it. (And I have no problem with that, BTW!)
For instance, Tivo or TomTom - they've taken Linux and used it as an embedded platform that provides a lot of their basic needs.
There would be two challenges with this kind of effort:
The first is the technical aspect: building an application such that people can make this sort of change without getting elbow-deep in the code, providing a convenient framework for posting changes, etc. Some of this we more or less have already (i18n string substitution, separation of GUI layout from program code via things like Glade, etc.)
The second is the logistical support: a site or sites where all these submissions can be stored, administrators to filter out all the trolls and vandals, not to mention the flat-out bad ideas, and someone to provide leadership, helping to promote promising ideas over less promising ones.
One of the basic problems with this type of system is that it actually isn't "self regulating" or "self maintaining". Not everyone who uses the system is your friend. Not everyone who uses the system will fully research the available user-submitted options (more commonly, I think, people will try no more than a few of the most visible options) - so good work can be lost in the pile of submissions, while mediocrity "designed by committee" (or "mob" - a committee has more organization than a bunch of random submitters) may become prevalent.
Additionally (and this was part of the point of the article) - the quality of any solution isn't defined in a vacuum - for instance, if the user is already familiar with one UI design, that design has a certain advantage over another, competing design. If you learn where all the commands are located in the menus, and then everything gets moved, that's disruptive. Likewise if none of the documentation for the application applies to your version, that's rather unhelpful. This means it's often more helpful to have one design thoughtfully worked out and heavily promoted by the core team, rather than a cadre of competing designs.
In the "High School Geometry" section, Lockhart talks about how a fairly simple idea - that when two lines cross, the angles on opposing sides of the crossing point will be equal - is turned into a complex and ugly chunk of notation... Lines must be identified as "AB" (with a bar over the top), there's notation for identifying the angle formed by three points, and the whole, simple idea is then backed up with a hefty "proof" in place of a simple, natural-language explanation.
Now, I don't quite agree with all of this. Maybe that's because it worked for me, and because I enjoy the idea of mathematics and logic having their own "language", and their own notation. I mean, sure, back then I always used to wonder why they threw all those Greek letters at us - in some cases it seemed totally arbitrary. Some of it is just long-standing tradition: like the capital Sigma or the long-s glyph used for summation and integration...
But what I enjoy about the use of these symbols is that they provide a compact way of identifying precisely what one is talking about. That these characters aren't part of everyday English writing means that they can be set aside to encapsulate powerful, specialized ideas.
The whole "proofs" thing worked out just fine for me, too. I think it makes sense: as part of teaching people how to build up simple ideas to form an argument in support of a more complicated idea, provide examples of how to do this: even with the simplest of ideas, the things that lend themselves most readily to intuitive understanding... If a proof is provided for a problem people naturally understand to begin with, then it will help them to understand how the proof works.
With regard to line and angle notation I think Lockhart is dead wrong. In the context of the "crossed lines" example he argues that the lines could be called "line a" and "line b" or something - and that the whole idea should be presented in a more conversational style. This could work for certain problems - especially really simple problems like that one - but there are other problems with expressing things in a conversational style. For starters, natural language is imprecise - at least the way most people use it. Precise natural language is the domain, for instance, of lawyers and logicians. It tends to be very heavy, often with its own specialized vocabulary that people don't readily understand on first exposure. Codifying the problem makes it less accessible, but also much more precise and concise.
Now, if I'd learned "High school geometry" in high school instead of, you know, 5th grade or whatever, it's possible things would have played out differently... As it stands, however, I'm a big fan of taking advantage of domain-specific vocabulary and symbols where they are available and useful.
"no real support" ? whatever do you mean, there is infinitely better support and drivers from nvidia than from intel or ati.
ATI's driver doesn't compile on latest kernels without voodoo
Aw, hell... Why do I need an old 3dFX card installed just to get my ATI card working??
You linux folk should be grateful for the fact that they release a driver at all. It's not like they get any return for creating a driver that allows a handful of people to run a hardware accelerated compiz desktops.
"Troll", huh? I don't know. I actually think this is a pretty reasonable perspective. NVidia must have had their reasons for releasing drivers for Linux - honestly, though, I don't know what those reasons would be.
Until linux becomes a viable platform for the desktop (which it never will be, because of flawed ideologies), be thankful for any corporate *desktop* support you get.
This part, though... ho hum. Any time somebody talks about "Linux on the desktop" my brain shuts down. It's just such a boring issue. I don't care. I don't care if "grandma" can't figure Linux out. Linux is on my desktop (and laptop) and I quite enjoy it.
Damned if I know what flawed ideologies you refer to... but I am curious.
Google gives you Java (for App Store), but their own applications run native code?
Yes, because they want everything in the app store to be forward compatible: in future Android might run on chips that are not ARM, so native code would break, and though it would be the developers' fault it would still make their app store look bad.
That's great for Google and all - but it doesn't do much for me, you know?
As a user I want people to be able to port existing code pretty easily, and to be able to write new code that fully utilizes the power of the machine. From my perspective as a user, there's no advantage to the phone running a VM. From my perspective as a developer, the fact that the phone runs a VM for all third-party software is actually pretty distasteful. This is an embedded platform we're talking about... It hasn't got a ton of on-board storage, and wasted processor cycles mean wasted battery, too.