I always fiddle with the settings using the provided remote or buttons on the side. The particular TV I was looking at did have its backlight set up all the way, but after I set it down it wasn't really improved much. It didn't seem to have a store demo mode. The burn-in thing is why I will never get a plasma. I'm going to be using this thing as a computer monitor and video game station and I don't want to see the taskbar burned in to the bottom, or Link's heart containers burned in to the upper left.
I was just looking at TVs today. At Best Buy there was a sweet 37" LCD TV I was seriously thinking about buying. Unfortunately the picture quality in LCDs still doesn't seem that great. I'm not talking about motion blur; everyone claims it's terrible but the new panels really have that problem licked IMHO. The problem now is the black level is way too bright, so the picture is washed out. Plasmas have insane contrast ratios and great black levels and it really shows when you put them side by side with LCDs in a showroom. Don't buy an LCD TV until you've seen it next to a plasma.
I noticed the LCD TV claimed to have a 1000:1 contrast ratio. The picture didn't look any better than last time I looked at LCD TVs, but back then they only claimed 400:1 ratios. Did they just start lying, or what? Do any LCD TVs out there actually have a decent black level and actual good contrast ratio, or is the tech just not there yet?
I used KMail for a while. It's a good mailer. It threaded messages, but it often got things wrong, was awkward to use, didn't include your replies in the thread, and didn't provide the awesome streamlined UI that GMail does for threads. My roommate used Eudora, it sucked in so many ways I won't even bother to mention them. It's possible it's improved since then. But I have never seen another mail client do threading anything like GMail does. GMail does occasionally get threading wrong but not that often. I admit I've never used Mutt or Evolution or Sylpheed or The Bat or $YOUR_FAVORITE_MAIL_CLIENT, but I don't think any of them do threading like GMail does either. Feel free to correct me if I'm wrong.
Lag on the order of a second is noticable and annoying in a user interface, especially when combined with the flashing that accompanies a page reload. It may seem like nitpicking but instant smooth response is very, very nice and a real usability issue (compare google maps to the old mapquest; even with 1-second page reloads on mapquest Google beats the pants off it any day of the week). Just because GMail is faster than some websites doesn't necessarily make it fast *enough*. GMail isn't just a website, it's an application replacement, and it competes with applications running locally. More speed is always welcome, and very possible. For example, the first thing I do when loading GMail is click on my unread conversations. GMail could preload those and have them ready as I click, and switch to them without reloading the page, with all the flashing that entails.
The ability to view mails without reloading the page is the biggest improvement I see in this new UI. That is one valid complaint about GMail: they use AJAX but still need lots of full-page loads, which messes up your browser history and is slow. Many people rave about GMail's speed but I actually find it not that great speed-wise. The AJAX parts are lightning fast of course (expanding messages in conversations, going to the inbox from a conversation view), but whenever it needs to do a full page load (which is often) it slows down. Also first logging in is too slow. The plain HTML version is actually faster in places.
Exactly. GMail threads mail more reliably and more usably than any other mail client I've ever used, web-based or not (for example showing you your own replies right there in the thread, and showing the first sentence of collapsed messages in the header's empty space). This Yahoo thing looks just like Outlook, showing you only one mail at a time and forcing you to hunt for related ones. That is a giant step backwards, all in the name of looking like Outlook.
Interesting. I can see that you have done some analysis here. However, I don't think your result is that impressive. Again, the system is technically not in equilibrium, but it is not a significant defect. Have you measured the actual advantage you can gain by not unchoking? If (as I expect) it is not large, then BitTorrent users have nothing to worry about. BitTorrent is not a theoretical system; it is a practical one, and small theoretical defects which can't be exploited for significant gain are not a real problem.
In many ways your argument is like advocating mergesort over quicksort because it's not asymptotically optimal. Quicksort and BitTorrent work great in practice. If you really have a significantly better solution then code it up and the world will beat a path to your door. If you can make a BitTorrent client that exploits your theoretical flaws to provide significantly improved download speeds, quite a few people would be interested I'm sure. You might even be able to sell it.
P.S. I really must comment here on an amazing fact: this is the first Slashdot discussion I have ever seen which progressed from throwing insults to calm discussion instead of the other way around. Kudos, sir, for showing restraint and preferring rational discourse to name-calling.
Take a look at Klik. I think something like this must be the future of Linux packaging. Assume a very small base system, then include most of your dependencies in the package, and damn the inefficiency. People whining about a few wasted MB are holding Linux back. Buy some RAM! If you want to conserve every last byte, then build Linux From Scratch. The rest of us want easy installs that are guaranteed to work.
BT really appeals to publishers of data, not because it gives great speed to downloaders, but because it is scalable.
BitTorrent appeals to publishers and consumers alike beacuse it *achieves* speed while *remaining* scalable.
You are still talking about the "unfairness" of the protocol, yet the only unfairness you've actually demonstrated is automatic seeding, which users generally don't mind. The only "exploit" made possible by automatic seeding is disabling it. Your solution is to disable it. I don't see how that helps anyone. You can already disable it in most clients through a config option; the fact that most people don't bother is proof that it is not important to them. You have not demonstrated that the current state of the BitTorrent protocol is otherwise not a Nash equilibrium.
You have brought up the issue of bandwidth distribution between multiple torrents from one seed. This is the one situation where your idea *might* actually help, by automatically distributing seed bandwidth to torrents which need it. However, there is still the problem of the doubled (at least) bandwidth consumption. Manual adjustment of seed bandwidth seems to work fine in practice without wasting all that extra bandwidth.
If you truly think automatic bandwidth distribution between multiple torrents is worth doubling seed bandwidth, then go for it: write your own protocol. Call it ByteSwapper or something. Do the testing in the real world, and see if it works. See if people adopt it.
Oh, of course now that I post that, I find the option has been buried way deep in the menus all along. I guess I just missed it earlier. Anyway, it's still annoying that it's on by default when nobody really wants it.
I can definitely imagine; many phones already do this. An incredibly loud stereotypical "camera" noise is made whenever you take a picture. Extremely annoying; it makes me reluctant to use the camera at all. Anybody know of a hack to disable the camera sound on a Nokia 3200?
Several people have responded [...] Someone stated that [...]
I'm not going to defend other people's arguments here.
If every client had a "seed?" checkbox that was disabled by default, and everyone were rational, only those who are genuinely interested in distributing the information would seed. This is exactly the way it should be. The way it is now, users are tricked
Even in your hypothetical economically ideal system, the system could benefit from people being tricked into giving more than they intended. The client authors benefit from "tricking" the users. In a free market there's nothing wrong with attempting to trick people for your benefit; the fault is squarely on the shoulders of the people being tricked. In the case of BitTorrent, people are only "tricked" into "wasting" upload bandwidth that would otherwise have gone unused, so most users are pretty ambivalent about it and there is no reason to modify clients to remove automatic seeding. If ISPs moved to a pay-per-uploaded-byte system, you can bet BitTorrent clients would remove this feature.
Everyone will still request pieces from seeds, even if seeding is not necessary for the health of the swarm. My proposed solution makes seeds seed only when it is absolutely necessary.
Ah, now I understand. Your pet peeve with the BitTorrent protocol is that seeds always upload as fast as possible, when that isn't always necessary to get the file distributed. Well I think you have the objective of the BitTorrent protocol wrong. You think it is to distribute a file to as many people as possible while transferring the minimum possible number of bytes. I think it is to distribute a file as fast as possible with a fixed limit on seeding bandwidth. Speed is an important characteristic of the BitTorrent protocol. If nobody cared about speed, we'd all be using Freenet. On The Pirate Bay, they all just want the files distributed as fast as possible. With the objective of speed in mind, a seed can always distribute the file faster by uploading more. So an excess of requests doesn't matter; the seed is happy to fulfill all the requests it can.
Furthermore, even if the objective of seeders was to conserve total bandwidth, I don't think your scheme would achieve that in most situations, since it would require 3x the bandwidth for each useful byte transferred from a seed. And the speeds would be terrible. A seed on a symmetric connection would only use half of its upload at maximum, meaning slower downloads for everyone. A client could only download from a seed at half its upload, so downloading from swarms with mostly seeds would be vastly slower. Lots of bandwidth would ultimately be wasted.
I will say again, one of the most important attractions of the BitTorrent protocol to users and distributors is its speed. Hypothetically, *if* your system reduced seed bandwidth, it might appeal to a few bandwidth misers who wouldn't mind the complaints of users. But I think people would prefer the speed of BitTorrent as it is today.
As for Nash Equilibriums, I don't see how you've demonstrated that the current state of the BitTorrent protocol is *not* a Nash Equilibrium. As an expert, how have you hacked your client to download significantly faster than others?
Hmm, after reading the great-grandparent post again I see that wasn't the focus of your question. Let me put it this way: Choosing the correct features, implementing them in a simple and elegant way, integrating them into a decent practical syntax which is similar to widely-used langages in a way such that teams of non-experts can understand and use it in an everyday environment; *that* is the innovation. It is very difficult; this is not merely copying Lisp even if you could theoretically implement these types of features in Lisp. It is true innovation.
Visual Studio. MSDN documentation. Support from Microsoft and adoption by thousands if not millions of developers around the world. Tight integration with Windows, SQL Server, IIS, Office. Excellent form designer. Drop-dead simple integration with legacy code written in C/C++. Decent syntax. Similarity to existing established languages.
C# 3.0 will have anonymous structs, meaning that you can return two (or N) values from a function without explicitly declaring a type and without using "out" or "ref" parameters. They're better than tuples because each member of the anonymous struct can be given a sensible name. "out" and "ref" are mostly useful in interop with C or C++ functions that have pointer parameters, and in that role they work very well. Any pure C# code that uses "out" and "ref" should be rethought. Luckily they don't seem to get abused much in my experience.
The "vulnerability" only works if you are sending data to a tracker which tracks ratios, which is not most trackers. This is a stat-tracking problem and as such is only relevant in members-only BitTorrent communities where stat tracking is done. If you use public trackers like those mostly found on The Pirate Bay or Mininova you are not affected. And of course trackerless torrents don't track stats either.
The simplest and best solution to this problem is the one that idiots (especially BT client developers like Bram Cohen and the Azureus dev team) tend to dislike the most [...] The current system is like socialism. It needs to become more like capitalism [...] Why no one realizes this is beyond me.
What a wanking piece of haughty, uninformed bullshit! How this got modded up to +4 is beyond me. Bram Cohen has realized this from the beginning, and all client authors understand it as well. The design of the BitTorrent protocol is and always has been grounded in the economic principles of the free market. Seeding requirements are *not* enforced in the official client or tracker. Clients only upload to people who upload to them, and if people break their agreements they *do* get banned.
Your suggestion requiring uploads to seeds is stupid, because people would be even *less* likely to seed if it wasted their download bandwidth as well as their upload bandwidth (and twice as much of it too!). If you want to discourage downloads from seeds, simply make the seeds slow.
The idea of assigning economic values to individual pieces is already in the protocol implicitly; the economic value of a piece is inversely proportional to the number of clients who have it. If you have a piece nobody else does, you can upload it to anyone and get a piece in return, therefore that piece has high value. If everybody else has the piece, nobody will accept it in a trade. Therefore it's already in a client's best interest to grab the most rare pieces; additional incentive for this is not necessary.
If you have such awesome ideas about how to build a BitTorrent client that no one else does, then why don't you build one yourself and change the world? It's not that difficult; the protocol is simple by design. Otherwise, shut your trap about how stupid the people actually working on clients are.
The people who are not acting like a free market here are the writers of the *trackers* which trust reported uploads by clients (clients never trust these numbers for anything useful). Your entire rant is misguided and off-base; it should be aimed at the writers and users of ratio trackers, not the clients.
Don't you think if a swordfighting game existed, the press would have been shown that? Those actors were just waving controllers around, they weren't playing actual games. The games shown to the press were less impressive technically than the concept games the actors were shown playing. And though the press was impressed overall, none of the reports I've seen have answered any of the questions I asked. I simply don't believe nintendo can put good enough tracking in a product durable enough for kids to play with and cheap enough to be included with a $200 console. I think the final controller won't live up to the sky-high expectations everyone is taking away from that video, though it could still be a useful controller even if it is missing some of those capabilities.
I'm not worried they won't think of this stuff; I'm worried that the technology isn't mature enough and it's not possible to put good enough tracking in a cheap durable device yet.
it doesn't look like it has gyroscopic feedback- like using gyroscopic inertia to make it feel like you're carrying something heavy, or that your sword has hit something
That's because it's pretty much impossible to produce enough force for a meaningful effect, especially in a small and battery-powered device. Furthermore, it couldn't possibly make the controller heavier or stop your sword swing in mid-air, it would only resist changes in orientation, not position. It really wouldn't work that well even if they did implement it. It would just feel kinda strange, not much at all like moving real massive objects around.
You thought the N64 controller was cool? I thought it was an abomination at first (I didn't understand the analog stick). After I used it I came around. I'd definitely choose any of the later controllers to it, though.
They do all have their little flaws. The PS2 controller has too many confusingly similar buttons and no analog triggers ("analog buttons" don't count). The XBox S controller is better, but the triggers are too hard to press for extended periods of time, the four face buttons are still too similar, and the black and white buttons are inconvenient. The gamecube controller has good face buttons and sticks. However, all three shoulder buttons are terrible, and the controller is just a bit too small overall. The 360 controller is close to perfect except for the still-too-similar four face buttons, and I'm not quite sure about the action on the new "black" and "white" shoulder buttons, but that may have been changed from the E3 prototypes. I'm reserving judgement on the PS3 controller until it's actually finalized.
This Revolution controller looks awesome if the tracking accuracy is as good as implied; in that case I'm sold. But I am skeptical; I'm afraid it will turn out to be a much less awesome device than that video made it look, with unreliable tracking and restrictive range. I won't know until I can use it myself.
The arrow could simply have been pointing where the last known location of the controller was, the reporter didn't elaborate. Dang journalists have no idea how to test a piece of hardware. All these different sites with reports, and no real hard info about the technology, just 20 different descriptions of the demo games.
I am not convinced the technology can live up to our expectations. The video looked cool, but those actors weren't actually controlling anything, and those are game concepts, not actual games. This type of technology has always been rather fiddly when you use it in real life. It will live or die based on how good Nintendo's tracking technology is, and I'm not convinced good enough tracking can be put into a durable consumer product. People's kids are going to be slamming these things, and it has to be reasonably cheap too.
I have so many questions that can only really be answered by testing one myself. Does it have to be pointed at the TV to work? (I have read there are sensors you must place on top your TV). That right there would eliminate good swordfighting. How good is the accuracy really? Does it drift? If you move the controller quickly, or hit a hard surface with it, does it lose tracking? Does the accuracy get worse as the controller suffers from wear and tear? Does it have a limited tracking space? For four players, you would need a very large tracking space, or you would be hitting each other all the time. A very large tracking space could enable some really cool single player games, too. Could you walk around and wave the controller all over, or are you restricted to sitting down while holding the controller steady in a small "zone" and pointing it at the TV? One of the reporters mentioned that if you moved out it of a certain box while playing the demos, you would have to move back before continuing.
Not only the D-pad and the analog stick, but the rumble pak, controller expansion slot, top trigger buttons, wireless controller, and of course the DS. Where would gaming be without Nintendo? Nintendo's controllers have always been great despite the criticism. Much like their games.
They put more thought into their designs than their competitors. For example, Sony's buttons are neatly arranged, but it takes a while to memorize which one is square, or whether L2 is the top or bottom one. The Gamecube controller looks odd at first glance, but you never have to stop and think about which one is the little red "B" button, or which is the vertical bean-shaped "X" button. And that's exactly why Nintendo made it that way.
Slashdot Mirror
I always fiddle with the settings using the provided remote or buttons on the side. The particular TV I was looking at did have its backlight set up all the way, but after I set it down it wasn't really improved much. It didn't seem to have a store demo mode. The burn-in thing is why I will never get a plasma. I'm going to be using this thing as a computer monitor and video game station and I don't want to see the taskbar burned in to the bottom, or Link's heart containers burned in to the upper left.
I noticed the LCD TV claimed to have a 1000:1 contrast ratio. The picture didn't look any better than last time I looked at LCD TVs, but back then they only claimed 400:1 ratios. Did they just start lying, or what? Do any LCD TVs out there actually have a decent black level and actual good contrast ratio, or is the tech just not there yet?
I used KMail for a while. It's a good mailer. It threaded messages, but it often got things wrong, was awkward to use, didn't include your replies in the thread, and didn't provide the awesome streamlined UI that GMail does for threads. My roommate used Eudora, it sucked in so many ways I won't even bother to mention them. It's possible it's improved since then. But I have never seen another mail client do threading anything like GMail does. GMail does occasionally get threading wrong but not that often. I admit I've never used Mutt or Evolution or Sylpheed or The Bat or $YOUR_FAVORITE_MAIL_CLIENT, but I don't think any of them do threading like GMail does either. Feel free to correct me if I'm wrong.
Lag on the order of a second is noticable and annoying in a user interface, especially when combined with the flashing that accompanies a page reload. It may seem like nitpicking but instant smooth response is very, very nice and a real usability issue (compare google maps to the old mapquest; even with 1-second page reloads on mapquest Google beats the pants off it any day of the week). Just because GMail is faster than some websites doesn't necessarily make it fast *enough*. GMail isn't just a website, it's an application replacement, and it competes with applications running locally. More speed is always welcome, and very possible. For example, the first thing I do when loading GMail is click on my unread conversations. GMail could preload those and have them ready as I click, and switch to them without reloading the page, with all the flashing that entails.
The ability to view mails without reloading the page is the biggest improvement I see in this new UI. That is one valid complaint about GMail: they use AJAX but still need lots of full-page loads, which messes up your browser history and is slow. Many people rave about GMail's speed but I actually find it not that great speed-wise. The AJAX parts are lightning fast of course (expanding messages in conversations, going to the inbox from a conversation view), but whenever it needs to do a full page load (which is often) it slows down. Also first logging in is too slow. The plain HTML version is actually faster in places.
Exactly. GMail threads mail more reliably and more usably than any other mail client I've ever used, web-based or not (for example showing you your own replies right there in the thread, and showing the first sentence of collapsed messages in the header's empty space). This Yahoo thing looks just like Outlook, showing you only one mail at a time and forcing you to hunt for related ones. That is a giant step backwards, all in the name of looking like Outlook.
In many ways your argument is like advocating mergesort over quicksort because it's not asymptotically optimal. Quicksort and BitTorrent work great in practice. If you really have a significantly better solution then code it up and the world will beat a path to your door. If you can make a BitTorrent client that exploits your theoretical flaws to provide significantly improved download speeds, quite a few people would be interested I'm sure. You might even be able to sell it.
P.S. I really must comment here on an amazing fact: this is the first Slashdot discussion I have ever seen which progressed from throwing insults to calm discussion instead of the other way around. Kudos, sir, for showing restraint and preferring rational discourse to name-calling.
Take a look at Klik. I think something like this must be the future of Linux packaging. Assume a very small base system, then include most of your dependencies in the package, and damn the inefficiency. People whining about a few wasted MB are holding Linux back. Buy some RAM! If you want to conserve every last byte, then build Linux From Scratch. The rest of us want easy installs that are guaranteed to work.
BitTorrent appeals to publishers and consumers alike beacuse it *achieves* speed while *remaining* scalable.
You are still talking about the "unfairness" of the protocol, yet the only unfairness you've actually demonstrated is automatic seeding, which users generally don't mind. The only "exploit" made possible by automatic seeding is disabling it. Your solution is to disable it. I don't see how that helps anyone. You can already disable it in most clients through a config option; the fact that most people don't bother is proof that it is not important to them. You have not demonstrated that the current state of the BitTorrent protocol is otherwise not a Nash equilibrium.
You have brought up the issue of bandwidth distribution between multiple torrents from one seed. This is the one situation where your idea *might* actually help, by automatically distributing seed bandwidth to torrents which need it. However, there is still the problem of the doubled (at least) bandwidth consumption. Manual adjustment of seed bandwidth seems to work fine in practice without wasting all that extra bandwidth.
If you truly think automatic bandwidth distribution between multiple torrents is worth doubling seed bandwidth, then go for it: write your own protocol. Call it ByteSwapper or something. Do the testing in the real world, and see if it works. See if people adopt it.
Oh, of course now that I post that, I find the option has been buried way deep in the menus all along. I guess I just missed it earlier. Anyway, it's still annoying that it's on by default when nobody really wants it.
I can definitely imagine; many phones already do this. An incredibly loud stereotypical "camera" noise is made whenever you take a picture. Extremely annoying; it makes me reluctant to use the camera at all. Anybody know of a hack to disable the camera sound on a Nokia 3200?
I'm not going to defend other people's arguments here.
If every client had a "seed?" checkbox that was disabled by default, and everyone were rational, only those who are genuinely interested in distributing the information would seed. This is exactly the way it should be. The way it is now, users are tricked
Even in your hypothetical economically ideal system, the system could benefit from people being tricked into giving more than they intended. The client authors benefit from "tricking" the users. In a free market there's nothing wrong with attempting to trick people for your benefit; the fault is squarely on the shoulders of the people being tricked. In the case of BitTorrent, people are only "tricked" into "wasting" upload bandwidth that would otherwise have gone unused, so most users are pretty ambivalent about it and there is no reason to modify clients to remove automatic seeding. If ISPs moved to a pay-per-uploaded-byte system, you can bet BitTorrent clients would remove this feature.
Everyone will still request pieces from seeds, even if seeding is not necessary for the health of the swarm. My proposed solution makes seeds seed only when it is absolutely necessary.
Ah, now I understand. Your pet peeve with the BitTorrent protocol is that seeds always upload as fast as possible, when that isn't always necessary to get the file distributed. Well I think you have the objective of the BitTorrent protocol wrong. You think it is to distribute a file to as many people as possible while transferring the minimum possible number of bytes. I think it is to distribute a file as fast as possible with a fixed limit on seeding bandwidth. Speed is an important characteristic of the BitTorrent protocol. If nobody cared about speed, we'd all be using Freenet. On The Pirate Bay, they all just want the files distributed as fast as possible. With the objective of speed in mind, a seed can always distribute the file faster by uploading more. So an excess of requests doesn't matter; the seed is happy to fulfill all the requests it can.
Furthermore, even if the objective of seeders was to conserve total bandwidth, I don't think your scheme would achieve that in most situations, since it would require 3x the bandwidth for each useful byte transferred from a seed. And the speeds would be terrible. A seed on a symmetric connection would only use half of its upload at maximum, meaning slower downloads for everyone. A client could only download from a seed at half its upload, so downloading from swarms with mostly seeds would be vastly slower. Lots of bandwidth would ultimately be wasted.
I will say again, one of the most important attractions of the BitTorrent protocol to users and distributors is its speed. Hypothetically, *if* your system reduced seed bandwidth, it might appeal to a few bandwidth misers who wouldn't mind the complaints of users. But I think people would prefer the speed of BitTorrent as it is today.
As for Nash Equilibriums, I don't see how you've demonstrated that the current state of the BitTorrent protocol is *not* a Nash Equilibrium. As an expert, how have you hacked your client to download significantly faster than others?
Hmm, after reading the great-grandparent post again I see that wasn't the focus of your question. Let me put it this way: Choosing the correct features, implementing them in a simple and elegant way, integrating them into a decent practical syntax which is similar to widely-used langages in a way such that teams of non-experts can understand and use it in an everyday environment; *that* is the innovation. It is very difficult; this is not merely copying Lisp even if you could theoretically implement these types of features in Lisp. It is true innovation.
Visual Studio. MSDN documentation. Support from Microsoft and adoption by thousands if not millions of developers around the world. Tight integration with Windows, SQL Server, IIS, Office. Excellent form designer. Drop-dead simple integration with legacy code written in C/C++. Decent syntax. Similarity to existing established languages.
C# 3.0 will have anonymous structs, meaning that you can return two (or N) values from a function without explicitly declaring a type and without using "out" or "ref" parameters. They're better than tuples because each member of the anonymous struct can be given a sensible name. "out" and "ref" are mostly useful in interop with C or C++ functions that have pointer parameters, and in that role they work very well. Any pure C# code that uses "out" and "ref" should be rethought. Luckily they don't seem to get abused much in my experience.
The "vulnerability" only works if you are sending data to a tracker which tracks ratios, which is not most trackers. This is a stat-tracking problem and as such is only relevant in members-only BitTorrent communities where stat tracking is done. If you use public trackers like those mostly found on The Pirate Bay or Mininova you are not affected. And of course trackerless torrents don't track stats either.
Interesting... Do you know how the gyroremote senses its absolute position to avoid drift in its accelerometer readings?
What a wanking piece of haughty, uninformed bullshit! How this got modded up to +4 is beyond me. Bram Cohen has realized this from the beginning, and all client authors understand it as well. The design of the BitTorrent protocol is and always has been grounded in the economic principles of the free market. Seeding requirements are *not* enforced in the official client or tracker. Clients only upload to people who upload to them, and if people break their agreements they *do* get banned.
Your suggestion requiring uploads to seeds is stupid, because people would be even *less* likely to seed if it wasted their download bandwidth as well as their upload bandwidth (and twice as much of it too!). If you want to discourage downloads from seeds, simply make the seeds slow.
The idea of assigning economic values to individual pieces is already in the protocol implicitly; the economic value of a piece is inversely proportional to the number of clients who have it. If you have a piece nobody else does, you can upload it to anyone and get a piece in return, therefore that piece has high value. If everybody else has the piece, nobody will accept it in a trade. Therefore it's already in a client's best interest to grab the most rare pieces; additional incentive for this is not necessary.
If you have such awesome ideas about how to build a BitTorrent client that no one else does, then why don't you build one yourself and change the world? It's not that difficult; the protocol is simple by design. Otherwise, shut your trap about how stupid the people actually working on clients are.
The people who are not acting like a free market here are the writers of the *trackers* which trust reported uploads by clients (clients never trust these numbers for anything useful). Your entire rant is misguided and off-base; it should be aimed at the writers and users of ratio trackers, not the clients.
Don't you think if a swordfighting game existed, the press would have been shown that? Those actors were just waving controllers around, they weren't playing actual games. The games shown to the press were less impressive technically than the concept games the actors were shown playing. And though the press was impressed overall, none of the reports I've seen have answered any of the questions I asked. I simply don't believe nintendo can put good enough tracking in a product durable enough for kids to play with and cheap enough to be included with a $200 console. I think the final controller won't live up to the sky-high expectations everyone is taking away from that video, though it could still be a useful controller even if it is missing some of those capabilities.
I'm not worried they won't think of this stuff; I'm worried that the technology isn't mature enough and it's not possible to put good enough tracking in a cheap durable device yet.
That's because it's pretty much impossible to produce enough force for a meaningful effect, especially in a small and battery-powered device. Furthermore, it couldn't possibly make the controller heavier or stop your sword swing in mid-air, it would only resist changes in orientation, not position. It really wouldn't work that well even if they did implement it. It would just feel kinda strange, not much at all like moving real massive objects around.
They do all have their little flaws. The PS2 controller has too many confusingly similar buttons and no analog triggers ("analog buttons" don't count). The XBox S controller is better, but the triggers are too hard to press for extended periods of time, the four face buttons are still too similar, and the black and white buttons are inconvenient. The gamecube controller has good face buttons and sticks. However, all three shoulder buttons are terrible, and the controller is just a bit too small overall. The 360 controller is close to perfect except for the still-too-similar four face buttons, and I'm not quite sure about the action on the new "black" and "white" shoulder buttons, but that may have been changed from the E3 prototypes. I'm reserving judgement on the PS3 controller until it's actually finalized.
This Revolution controller looks awesome if the tracking accuracy is as good as implied; in that case I'm sold. But I am skeptical; I'm afraid it will turn out to be a much less awesome device than that video made it look, with unreliable tracking and restrictive range. I won't know until I can use it myself.
The arrow could simply have been pointing where the last known location of the controller was, the reporter didn't elaborate. Dang journalists have no idea how to test a piece of hardware. All these different sites with reports, and no real hard info about the technology, just 20 different descriptions of the demo games.
I have so many questions that can only really be answered by testing one myself. Does it have to be pointed at the TV to work? (I have read there are sensors you must place on top your TV). That right there would eliminate good swordfighting. How good is the accuracy really? Does it drift? If you move the controller quickly, or hit a hard surface with it, does it lose tracking? Does the accuracy get worse as the controller suffers from wear and tear? Does it have a limited tracking space? For four players, you would need a very large tracking space, or you would be hitting each other all the time. A very large tracking space could enable some really cool single player games, too. Could you walk around and wave the controller all over, or are you restricted to sitting down while holding the controller steady in a small "zone" and pointing it at the TV? One of the reporters mentioned that if you moved out it of a certain box while playing the demos, you would have to move back before continuing.
They put more thought into their designs than their competitors. For example, Sony's buttons are neatly arranged, but it takes a while to memorize which one is square, or whether L2 is the top or bottom one. The Gamecube controller looks odd at first glance, but you never have to stop and think about which one is the little red "B" button, or which is the vertical bean-shaped "X" button. And that's exactly why Nintendo made it that way.