You can sit down, write all the programs you'd like with the free version, test it out yourself, then switch to the commercial version when it's time to release.
No, you can't. You can't "switch" code you developed using the GPL version to the commercial version. It's not against the GPL; it is against the commercial license that TrollTech sells QT under. You can write all the programs you'd like with the free version, but you can never ever use any of that code with the commercial version of QT.
The reason for this is that QT has no run-time licenses or per-copy royalties. You only ever pay for the development you do. After that you never have to pay TrollTech again, no matter how many copies you distribute. Obviously if you could develop all your code using the GPL version, buy one commercial license, compile once and release, then TrollTech would be out of business in short order.
I would expect that iTunes on OS X would be much better. But the fact remains that iTunes on Windows is a terrible video player. Windows Media Player, RealPlayer, and Media Player Classic all play video flawlessly while task switching. That's not my main complaint, though. My main complaints are the glacially slow user interface and the wacky brightness issue.
As for the quality, have you compared it to the BitTorrent version? The difference is night and day. The show is definitely enjoyable at low resolution and there's nothing wrong with that, but even on a regular lo-def TV the low quality is apparent.
That's a stupid argument. They shut down Napster's central servers, not the software code. If they could shut down mere distribution of software then people distributing Gnutella clients would have been shut down a long time ago.
That pref in iTunes doesn't do much. It just makes the video window appear automatically instead of making you click on the album art box. It's still abysmally slow and it still disappears if you click on stuff in the iTunes window, even though the video keeps playing while you can't see it, which makes no sense for things which are not music videos (and even then it is questionable). And fullscreen mode still sucks because it doesn't have any video playback controls.
Playing the videos in QuickTime is not much better. It requires you to manually go to the folder on your hard drive where iTunes stores your music. Then you must manually open the m4v files in QuickTime because.m4v isn't associated with any program. The seek bar is still inexcusably slow, as is much of the UI, especially resizing the video window (QuickTime was never a speed demon but it used to be faster, what happened?). And of course unless you've bought QuickTime Pro you can't view the movies in fullscreen, which has always been retarded, and is even more so now that you *paid* for the videos and can watch them fullscreen in iTunes.
I bought Lost. The quality of the videos is merely okay. It's definitely watchable even on a regular-size TV, nothing like the old postage-stamp RealPlayer clips of yore. But it really pales in comparison to the BitTorrent version. Plus the BitTorrent version is widescreen. In Apple's version background details are often blurred (especially busy jungle and ocean wave backgrounds) and color banding is occasionally noticable.
The color banding problem is made much much worse by something which could be an encoding error or an iTunes bug, I'm not sure which: Each episode is displayed with completely different brightness. I have to adjust my video card's brightness and gamma settings before playing each episode. Not only is it annoying to watch something that is too dark or washed out, but H.264 plays a lot of tricks when it compresses video. If your brightness is set wrong artifacts and color banding that you otherwise wouldn't notice will start popping up everywhere. You would be amazed how much setting the proper gamma and brightness can improve a heavily compressed video clip. Yet iTunes messes it up totally.
That isn't the worst thing about playing the videos, though. Basically, iTunes sucks as a video player (at least on Windows). The UI for video is wacky and excrutiatingly slow. Dragging the seek bar is an exercise in frustration. Videos can't be watched until they are completely downloaded (and the downloads are slow). Downloading purchased items while watching a video causes terrible skipping (and once, a crash).
I expected much better quality software from Apple. To me it seems as if iTunes 6 was rushed out the door (especially coming out only a month after iTunes 5!) when Apple finalized its deal with ABC, perhaps unexpectedly early. Hopefully iTunes 7 will revamp the video parts of iTunes. Certainly they will need to do something before they open a real movie store, as I'm certain they are planning.
Really the ones you should be thanking are ABC. They had the balls to finally let somebody try real Internet distribution. Miraculously they didn't form a cartel with the other big networks to make unreasonable demands, they didn't go around "consulting" everybody to see if they thought it was a good idea, they put their biggest hits on the line, they didn't include ads, and they agreed on a quite reasonable price. ABC had all the power here and they did the right thing with it.
As for Apple's part of this deal, I downloaded Lost and my first impression was that iTunes is a terrible video player, at least on Windows. Not merely bad, but terrible. It crashes, it freezes for a second or more every time you click on something (including the seek bar, which makes it practically unusable), its user interface is completely unsuited for video, it glitches when it's not the top window, it seems to choose random brightness/contrast settings for each video (or perhaps that's just bad encoding), when downloading and watching videos at the same time it randomly pauses and skips for periods of 5 seconds or more (invariably at an important moment in the dialogue), I could go on and on. And of course you can't use any other video player because of the DRM (which AFAIK hasn't been cracked yet), unless you have a video iPod (I don't). I downloaded a BitTorrent copy to compare and the quality was *far* better, not to mention that it was in its native widescreen format (showing more of the action), and I could use a video player that didn't suck.
I still plan to buy Lost as it comes out to support legal TV downloads and because I have faith that Apple will soon fix iTunes, but when I want to actually watch those episodes I'm going to use BitTorrent.
Wrong. Firstly, IPv6 provides support for automatic network renumbering, which solves the real problem instead of hacking around it with a band-aid that ultimately changes the network architecture. Switching ISPs with IPv6 is easy. Secondly, your multihoming example doesn't require NAT at all; why would it? Each site uses its ISP's address space, and you can set up your internal routing however you like.
And once it's in a wiki hidden between [code] blocks, lean on the wiki to provide gooood documentation (think wikipedia, but with little blocks of code).
I think documentation is one area where this approach could really shine without requiring major changes to existing tools. Large projects such as KDE could create wiki documentation sites tied to the code documentation in their CVS. Developers don't like writing documentation, and they're too close to their own code to know how to write good docs. Users are in the perfect position to know what users would like in documentation, but usually they are stuck with whatever the developers decided to write. A documentation wiki is the perfect solution to this age-old software problem.
Your python wiki project sounds very interesting; what was it used for?
People depend on software to get their work done. Broken software can mess up your data. Malicious software can do bad things, like give your credit card number to Russian gangsters.
People shouldn't depend on software under active development; only released software. Obviously before releasing a piece of software some quality assurance work will have to be done. This needs a different process than normal development work; it can be done on a branch of the code. This problem is largely solved by existing large OSS projects. By adding more contributors more errors will be introduced but more errors will be fixed, and overall more useful code will be produced.
If you take the total number of people in the world who are interested in and capable of doing OSS programming, and divide by the number of OSS projects, the result is a number close to 1.
And why is that? Because OSS programming is hard to do. It's very hard to jump in and immediately contribute to a project that you use. If we make it easier, more people will do it. You could have made a similar argument against Wikipedia before it started. Who wants to write an encyclopedia article? It turns out that everybody does, if it's easy enough. Making it easy is the key.
If a Wikipedia article gets munged temporarily by someone who's stupid, uninformed, or malicious, it's no big deal, and it will probably get fixed soon. But when it's a piece of software, the consequences are potentially a lot more serious, and there's no guarantee that the damage will be detected or fixed any time soon.
Why will the damage to wikipedia get fixed soon? Because anybody can fix it. Why will the damage to the software not be fixed soon? Because only a couple of people have the ability to fix it. The idea is to give far more people the ability to fix that problem (a number which is proportional to the number of people who are likely to cause the problem, so the problems shouldn't get out of hand).
Why is the software problem more serious? Because softare is fragile. Is that inherent to software, or is it just the condition of the software development tools and processes we use today? I believe it is the latter. I believe software development tools and processes could be a lot more robust and forgiving of simple mistakes. And if projects started really opening up contributions, made it as easy as editing a Wiki, then they would be forced to become more robust. This is a good thing, not something to be avoided.
I'm not sure the conclusions from The Mythical Man Month apply directly here. The main conclusion is that adding developers to a project makes it take longer. Open source software isn't on a strict schedule, and it doesn't have central management with clearly defined lists of requirements. New contributors aren't assigned to speed up existing work, they add their own features and improve the software in their own way.
Most successful open-source projects also have exactly one author. Massive parallelization works best for something like Wikipedia that's both big and inherently parallelizable. Most software isn't like that.
I'm thinking about the big projects here. KDE, GNOME, Mozilla, Debian, etc. But why is it that developing software isn't inherently parallelizable? To the extent that is actually true, once again I blame the tools. We need better software development tools to make software development more parallelizable. I don't think there's any inherent reason why "Joe's Yet Another MP3 Database" on SourceForge shouldn't be able to use this type of develoment methodology, given the right tools.
Most insightful article about software development I've ever read. Every open source project could learn a thing or two here, and closed-source commercial products could learn a bit too.
IMHO this philosophy could go a *lot* farther too. We should be building these types of concepts into our software development tools (not just source control but IDEs and compilers and even languages). It should be as easy as possible for users to get the source, build it, modify it, and submit their changes. Ideally as easy as editing a Wiki. Though the inherent complexity of software means that Wiki simplicity will probably never be reached, we could certainly do a *lot* better than we do now.
In an open source project the ease of the process of getting, compiling, modifying, and submitting changes to the source is directly related to the number of new contributors joining the project, which is directly related to the rate of improvement. Traditional software development tools have far too many pitfalls and require far too much know-how for casual users. The process of contributing to open-source projects could and should be a lot more automatic and foolproof, because attracting contributors is the single most important thing an open source project can do to improve itself.
Certainly the desert has its problems, but they pale in comparison to the problems of city driving.
For predefined routes we already have trains and buses. There would probably be a market for an autonomous path-following cargo truck but if it couldn't navigate the last mile over city streets that market would be a *lot* smaller than it could be. Commuting pretty much requires city driving.
Of course, eventually these problems will be solved and robots will drive us everywhere; I'm sure of that. It's just that I don't think it's happening soon, even though the Grand Challenge has been won.
Yeah, the website sucks this year. The only cool part is the map; the entire rest of the site is a mess. The stats are completely inaccurate and misleading, the URLs in the RSS feed are broken, the updates are extremely sporadic, there's hardly any video, the UI sucks, the back button doesn't work, the text's too small, there's a stupid disclaimer on external links, external links always open popups, I could go on and on. Down with Flash websites!
Driving on normal roads is vastly easier than navigating the grand challenge terrain.
I disagree. In the grand challenge all you have to worry about is the terrain, and really the terrain is nothing more than empty dirt road for the most part. Plus the max speed is 40 mph, GPS is completely unobstructed save for a couple of straight tunnels, and the GPS waypoints are extremely detailed and completely accurate. To create a truly driverless car of the type where you push a button and it drives you where you want to go on the normal road system is many orders of magnitude more difficult. (Note that I'm not talking about fancy cruise control here, but real driverless cars which automatically go from point A to point B)
When driving on public roads you have to be able to go 65 mph or more, read road signs and traffic lights with _extreme_ reliability, understand the instructions on various signs (not just standard road signs but non-standard signs found in construction zones, parking lots, private roads, etc), function with complete loss of GPS readings for an extended time, compensate for incorrect or out of date map data, reliably sense the locations of other cars from hundreds of meters away, read other cars' brake lights and blinkers and predict and react to their actions, adapt to weather conditions (rain, snow, fog, ice), avoid pedestrians, navigate construction zones, avoid crashes, figure out whose turn it is at 4-way stops, recognize malfunctioning traffic lights, recognize missing or misleading or unreadable road lines, navigate parking lots and driveways for which no map data exists, be immune to simple pranks (imagine if putting some simple obstacle in the road would cause every automated vehicle that went by to turn and crash), and undoubtedly solve a million other problems I didn't think of.
Meh, it's OK. Kinda slow actually, though the switching between MSN and Google is nice. If you want something more sophisticated than Google Maps, just use Google Earth. It's much cooler than this flash thing, and it'll give you your coordinates.
You've never been able to disable Flash. The idea that you could is suggested by the UI but that's really a UI bug (#236622, filed by me, I'd link it but you can't link to bugzilla from slashdot). That dialog that "disables" plugins only stops them from being used when you view a file directly; for example when you type the address of a.swf file directly into the address bar. In 1.5 that dialog's functionality has been integrated into the new "Download Actions" dialog which makes it more clear what is really going on. To really kill Flash you should use Flashblock.
Already done (sort of). It's called Google Answers and it's not that successful (though it's a very interesting experiment). Perhaps lower payments are really the answer but no feasable solution exists. Micropayments simply haven't worked for anyone yet, and nobody knows why, except to point out that they are always too large since no feasible solution for very small payments exists yet. Such a system could likely make billions, but fraud would be a serious problem due to the difficulty of policing an order of magnitude more payments. Perhaps Google could come to the rescue again with a Google Payments?
But really, I couldn't care less about long MP3s or gapless playback. The (weak and broken) DRM ensures that I can buy music at the iTMS. The UI is good and the style is nice (girls dig iPods). The battery has worked fine for me so far, and by the time it dies I'll probably want a new one anyway (cell phones are much the same in this). I do wish it played vorbis, and I wish it had a radio, and a recorder. But I don't wish any of those enough to throw away a good gift and spend my money on something less stylish with a worse UI and no iTunes Music Store.
I read their justification for releasing the album, and I noticed just one statement I didn't agree with:
We realize that digital files are the primary means by which a huge segment of the population is exposed to new music [...]
I suppose I can't speak for the rest of the population but I don't download new music I've never heard before. I hear songs other places, decide I like them, and *then* download them. Do other people really spend time downloading random songs they've never heard before?
If vorbis files played on iPods, that torrent would be a lot faster. As it is, I can't use any music that isn't in AAC or MP3 format and I do believe quite a few others are in the same situation.
AJAX could improve bulletin boards tremendously, why isn't it used more often? Slashdot's comment system could be tremendously improved by a little Javascript and XMLHttpRequest. Imagine expanding comment trees without refreshing the page. The demand is there; there are even some Greasemonkey scripts to hack this capability into Slashdot (though I haven't gotten any to work).
We could do amazing things with what we have, if only we knew how.
That often-repeated claim fails to explain why progress in AI has been so abysmally slow. Are people really that stupid? Have we failed to see the answer lying in plain sight for so long? I believe there is a different explanation.
We don't need more computing power exactly, we need a different type of computing power. The processing needs to be closer to the memory and massively parallel, but not necessarily very fast. Simulating this type of system on a von Neumann architecture just doesn't work very well.
[...] this is precisely how not to do it. The coupling between sensors and effectors should be as short as possible, especially when your processors (neurons) are very slow.
Good advice for designing a brain made of neurons, but not good advice for a system based on today's computers. Neurons are massively parallel and not very fast; computers are lightning fast and not very parallel. Attempting to implement brain-like processing on today's computer architectures is an exercise in futility (as decades of AI research has proven). The Grand Challenge teams are using a completely reasonable approach to designing systems based on the computers available today.
If mimicking the brain is your goal, then a completely different computer architecture is needed. You need a large memory with embedded massively parallel processing units. You need a non-von Neumann architecture to eliminate the von Neumann bottleneck. Only after this brain-like computer architecture is developed will we be able to implement true AI.
The goal of the Grand Challenge is to produce useful robots, not "true AI". The designers of the contest realize that's a badly-defined goal that is unlikely to be reached in the near future (after all, people have been failing for decades). Instead they require results and don't specify the methods. If "true AI" is the best way to achieve results, then the people who use it will win. If it is not, then requiring it would be counterproductive.
With Windows you are stuck with the same pixel size fonts we used back in the 80s when 640x480 was crazy high resolution. Either that or you change the DPI setting and all your apps look like crap. On Linux things are much more adaptable; with the correct widget theme and fonts I think a TV could be quite usable as a display for light web browsing and writing emails. Also Opera would be necessary as a web browser because it zooms images and CSS sizes as well as fonts, thus keeping the proportions of the page the same when zooming.
PC input could be a problem; do any video cards do HDMI yet?
Slashdot Mirror
No, you can't. You can't "switch" code you developed using the GPL version to the commercial version. It's not against the GPL; it is against the commercial license that TrollTech sells QT under. You can write all the programs you'd like with the free version, but you can never ever use any of that code with the commercial version of QT.
The reason for this is that QT has no run-time licenses or per-copy royalties. You only ever pay for the development you do. After that you never have to pay TrollTech again, no matter how many copies you distribute. Obviously if you could develop all your code using the GPL version, buy one commercial license, compile once and release, then TrollTech would be out of business in short order.
As for the quality, have you compared it to the BitTorrent version? The difference is night and day. The show is definitely enjoyable at low resolution and there's nothing wrong with that, but even on a regular lo-def TV the low quality is apparent.
That's a stupid argument. They shut down Napster's central servers, not the software code. If they could shut down mere distribution of software then people distributing Gnutella clients would have been shut down a long time ago.
Playing the videos in QuickTime is not much better. It requires you to manually go to the folder on your hard drive where iTunes stores your music. Then you must manually open the m4v files in QuickTime because .m4v isn't associated with any program. The seek bar is still inexcusably slow, as is much of the UI, especially resizing the video window (QuickTime was never a speed demon but it used to be faster, what happened?). And of course unless you've bought QuickTime Pro you can't view the movies in fullscreen, which has always been retarded, and is even more so now that you *paid* for the videos and can watch them fullscreen in iTunes.
The color banding problem is made much much worse by something which could be an encoding error or an iTunes bug, I'm not sure which: Each episode is displayed with completely different brightness. I have to adjust my video card's brightness and gamma settings before playing each episode. Not only is it annoying to watch something that is too dark or washed out, but H.264 plays a lot of tricks when it compresses video. If your brightness is set wrong artifacts and color banding that you otherwise wouldn't notice will start popping up everywhere. You would be amazed how much setting the proper gamma and brightness can improve a heavily compressed video clip. Yet iTunes messes it up totally.
That isn't the worst thing about playing the videos, though. Basically, iTunes sucks as a video player (at least on Windows). The UI for video is wacky and excrutiatingly slow. Dragging the seek bar is an exercise in frustration. Videos can't be watched until they are completely downloaded (and the downloads are slow). Downloading purchased items while watching a video causes terrible skipping (and once, a crash).
I expected much better quality software from Apple. To me it seems as if iTunes 6 was rushed out the door (especially coming out only a month after iTunes 5!) when Apple finalized its deal with ABC, perhaps unexpectedly early. Hopefully iTunes 7 will revamp the video parts of iTunes. Certainly they will need to do something before they open a real movie store, as I'm certain they are planning.
As for Apple's part of this deal, I downloaded Lost and my first impression was that iTunes is a terrible video player, at least on Windows. Not merely bad, but terrible. It crashes, it freezes for a second or more every time you click on something (including the seek bar, which makes it practically unusable), its user interface is completely unsuited for video, it glitches when it's not the top window, it seems to choose random brightness/contrast settings for each video (or perhaps that's just bad encoding), when downloading and watching videos at the same time it randomly pauses and skips for periods of 5 seconds or more (invariably at an important moment in the dialogue), I could go on and on. And of course you can't use any other video player because of the DRM (which AFAIK hasn't been cracked yet), unless you have a video iPod (I don't). I downloaded a BitTorrent copy to compare and the quality was *far* better, not to mention that it was in its native widescreen format (showing more of the action), and I could use a video player that didn't suck.
I still plan to buy Lost as it comes out to support legal TV downloads and because I have faith that Apple will soon fix iTunes, but when I want to actually watch those episodes I'm going to use BitTorrent.
Wrong. Firstly, IPv6 provides support for automatic network renumbering, which solves the real problem instead of hacking around it with a band-aid that ultimately changes the network architecture. Switching ISPs with IPv6 is easy. Secondly, your multihoming example doesn't require NAT at all; why would it? Each site uses its ISP's address space, and you can set up your internal routing however you like.
I think documentation is one area where this approach could really shine without requiring major changes to existing tools. Large projects such as KDE could create wiki documentation sites tied to the code documentation in their CVS. Developers don't like writing documentation, and they're too close to their own code to know how to write good docs. Users are in the perfect position to know what users would like in documentation, but usually they are stuck with whatever the developers decided to write. A documentation wiki is the perfect solution to this age-old software problem.
Your python wiki project sounds very interesting; what was it used for?
People shouldn't depend on software under active development; only released software. Obviously before releasing a piece of software some quality assurance work will have to be done. This needs a different process than normal development work; it can be done on a branch of the code. This problem is largely solved by existing large OSS projects. By adding more contributors more errors will be introduced but more errors will be fixed, and overall more useful code will be produced.
If you take the total number of people in the world who are interested in and capable of doing OSS programming, and divide by the number of OSS projects, the result is a number close to 1.
And why is that? Because OSS programming is hard to do. It's very hard to jump in and immediately contribute to a project that you use. If we make it easier, more people will do it. You could have made a similar argument against Wikipedia before it started. Who wants to write an encyclopedia article? It turns out that everybody does, if it's easy enough. Making it easy is the key.
Why will the damage to wikipedia get fixed soon? Because anybody can fix it. Why will the damage to the software not be fixed soon? Because only a couple of people have the ability to fix it. The idea is to give far more people the ability to fix that problem (a number which is proportional to the number of people who are likely to cause the problem, so the problems shouldn't get out of hand).
Why is the software problem more serious? Because softare is fragile. Is that inherent to software, or is it just the condition of the software development tools and processes we use today? I believe it is the latter. I believe software development tools and processes could be a lot more robust and forgiving of simple mistakes. And if projects started really opening up contributions, made it as easy as editing a Wiki, then they would be forced to become more robust. This is a good thing, not something to be avoided.
I'm not sure the conclusions from The Mythical Man Month apply directly here. The main conclusion is that adding developers to a project makes it take longer. Open source software isn't on a strict schedule, and it doesn't have central management with clearly defined lists of requirements. New contributors aren't assigned to speed up existing work, they add their own features and improve the software in their own way.
Most successful open-source projects also have exactly one author. Massive parallelization works best for something like Wikipedia that's both big and inherently parallelizable. Most software isn't like that.
I'm thinking about the big projects here. KDE, GNOME, Mozilla, Debian, etc. But why is it that developing software isn't inherently parallelizable? To the extent that is actually true, once again I blame the tools. We need better software development tools to make software development more parallelizable. I don't think there's any inherent reason why "Joe's Yet Another MP3 Database" on SourceForge shouldn't be able to use this type of develoment methodology, given the right tools.
IMHO this philosophy could go a *lot* farther too. We should be building these types of concepts into our software development tools (not just source control but IDEs and compilers and even languages). It should be as easy as possible for users to get the source, build it, modify it, and submit their changes. Ideally as easy as editing a Wiki. Though the inherent complexity of software means that Wiki simplicity will probably never be reached, we could certainly do a *lot* better than we do now.
In an open source project the ease of the process of getting, compiling, modifying, and submitting changes to the source is directly related to the number of new contributors joining the project, which is directly related to the rate of improvement. Traditional software development tools have far too many pitfalls and require far too much know-how for casual users. The process of contributing to open-source projects could and should be a lot more automatic and foolproof, because attracting contributors is the single most important thing an open source project can do to improve itself.
For predefined routes we already have trains and buses. There would probably be a market for an autonomous path-following cargo truck but if it couldn't navigate the last mile over city streets that market would be a *lot* smaller than it could be. Commuting pretty much requires city driving.
Of course, eventually these problems will be solved and robots will drive us everywhere; I'm sure of that. It's just that I don't think it's happening soon, even though the Grand Challenge has been won.
Yeah, the website sucks this year. The only cool part is the map; the entire rest of the site is a mess. The stats are completely inaccurate and misleading, the URLs in the RSS feed are broken, the updates are extremely sporadic, there's hardly any video, the UI sucks, the back button doesn't work, the text's too small, there's a stupid disclaimer on external links, external links always open popups, I could go on and on. Down with Flash websites!
I disagree. In the grand challenge all you have to worry about is the terrain, and really the terrain is nothing more than empty dirt road for the most part. Plus the max speed is 40 mph, GPS is completely unobstructed save for a couple of straight tunnels, and the GPS waypoints are extremely detailed and completely accurate. To create a truly driverless car of the type where you push a button and it drives you where you want to go on the normal road system is many orders of magnitude more difficult. (Note that I'm not talking about fancy cruise control here, but real driverless cars which automatically go from point A to point B)
When driving on public roads you have to be able to go 65 mph or more, read road signs and traffic lights with _extreme_ reliability, understand the instructions on various signs (not just standard road signs but non-standard signs found in construction zones, parking lots, private roads, etc), function with complete loss of GPS readings for an extended time, compensate for incorrect or out of date map data, reliably sense the locations of other cars from hundreds of meters away, read other cars' brake lights and blinkers and predict and react to their actions, adapt to weather conditions (rain, snow, fog, ice), avoid pedestrians, navigate construction zones, avoid crashes, figure out whose turn it is at 4-way stops, recognize malfunctioning traffic lights, recognize missing or misleading or unreadable road lines, navigate parking lots and driveways for which no map data exists, be immune to simple pranks (imagine if putting some simple obstacle in the road would cause every automated vehicle that went by to turn and crash), and undoubtedly solve a million other problems I didn't think of.
Meh, it's OK. Kinda slow actually, though the switching between MSN and Google is nice. If you want something more sophisticated than Google Maps, just use Google Earth. It's much cooler than this flash thing, and it'll give you your coordinates.
You've never been able to disable Flash. The idea that you could is suggested by the UI but that's really a UI bug (#236622, filed by me, I'd link it but you can't link to bugzilla from slashdot). That dialog that "disables" plugins only stops them from being used when you view a file directly; for example when you type the address of a .swf file directly into the address bar. In 1.5 that dialog's functionality has been integrated into the new "Download Actions" dialog which makes it more clear what is really going on. To really kill Flash you should use Flashblock.
Already done (sort of). It's called Google Answers and it's not that successful (though it's a very interesting experiment). Perhaps lower payments are really the answer but no feasable solution exists. Micropayments simply haven't worked for anyone yet, and nobody knows why, except to point out that they are always too large since no feasible solution for very small payments exists yet. Such a system could likely make billions, but fraud would be a serious problem due to the difficulty of policing an order of magnitude more payments. Perhaps Google could come to the rescue again with a Google Payments?
But really, I couldn't care less about long MP3s or gapless playback. The (weak and broken) DRM ensures that I can buy music at the iTMS. The UI is good and the style is nice (girls dig iPods). The battery has worked fine for me so far, and by the time it dies I'll probably want a new one anyway (cell phones are much the same in this). I do wish it played vorbis, and I wish it had a radio, and a recorder. But I don't wish any of those enough to throw away a good gift and spend my money on something less stylish with a worse UI and no iTunes Music Store.
We realize that digital files are the primary means by which a huge segment of the population is exposed to new music [...]
I suppose I can't speak for the rest of the population but I don't download new music I've never heard before. I hear songs other places, decide I like them, and *then* download them. Do other people really spend time downloading random songs they've never heard before?
If vorbis files played on iPods, that torrent would be a lot faster. As it is, I can't use any music that isn't in AAC or MP3 format and I do believe quite a few others are in the same situation.
AJAX could improve bulletin boards tremendously, why isn't it used more often? Slashdot's comment system could be tremendously improved by a little Javascript and XMLHttpRequest. Imagine expanding comment trees without refreshing the page. The demand is there; there are even some Greasemonkey scripts to hack this capability into Slashdot (though I haven't gotten any to work).
That often-repeated claim fails to explain why progress in AI has been so abysmally slow. Are people really that stupid? Have we failed to see the answer lying in plain sight for so long? I believe there is a different explanation.
We don't need more computing power exactly, we need a different type of computing power. The processing needs to be closer to the memory and massively parallel, but not necessarily very fast. Simulating this type of system on a von Neumann architecture just doesn't work very well.
Good advice for designing a brain made of neurons, but not good advice for a system based on today's computers. Neurons are massively parallel and not very fast; computers are lightning fast and not very parallel. Attempting to implement brain-like processing on today's computer architectures is an exercise in futility (as decades of AI research has proven). The Grand Challenge teams are using a completely reasonable approach to designing systems based on the computers available today.
If mimicking the brain is your goal, then a completely different computer architecture is needed. You need a large memory with embedded massively parallel processing units. You need a non-von Neumann architecture to eliminate the von Neumann bottleneck. Only after this brain-like computer architecture is developed will we be able to implement true AI.
The goal of the Grand Challenge is to produce useful robots, not "true AI". The designers of the contest realize that's a badly-defined goal that is unlikely to be reached in the near future (after all, people have been failing for decades). Instead they require results and don't specify the methods. If "true AI" is the best way to achieve results, then the people who use it will win. If it is not, then requiring it would be counterproductive.
PC input could be a problem; do any video cards do HDMI yet?