The idea that by making it more difficult to pirate a game you'll get more people to buy it is flawed. Not many people who pirate stuff hardcore (as in, never buy the game, as opposed to those who try out a game, then buy it if they like it) will break down and buy it simply because they put in on-line validation requirements.
Those people who do try out a game using less-than-legitimate versions, then buy it if they like it, are much LESS likely to try it - and people who are inconvenienced by obtrusive DRM like this are also going to shy away from it in the future. Even though free Wi-Fi connections at restaurants, coffee shops, airports, etc. are becoming more widespread, there are still plenty of places where you might want to play something for a while without a network connection.
Anti-piracy measures affect sales of legitimate copies and proliferation of illegitimate copies. When they only decrease the latter, but don't increase the former, they're worthless, and if they negatively impact the legitimate sales, then they're worse than useless.
Actually, there are people who go in for the full simulation, including filing flight plans, talking to ATC (real people, running ATC simulators), fuel and weather issues, waiting for traffic, etc.
I'd say that flight simulators are an example where maximum realism (in visualization, physics and controls) can be good as a game.
They aren't patenting mixing hashes and linked lists. They have several references to using such data structures (including Knuth).
The "innovation" is to delete expired records while accessing the records, either adding new records or searching for existing ones, plus the additional "innovation" of dynamically configuring the maximum number of records to delete on each access request.
In other words, you look up the hash, go to the first record in a linked list. You check to see if it's expired, if so you delete it from the linked list, recycling the storage. You then move on to the next record. If it isn't expired, you check to see if it's the one you want. If not, rinse and repeat. Once you've deleted a configured number of records, you stop trying to delete them and just search for the one you want.
Of course, just doing this doesn't remove the need to sweep the entire database for expired records; they could be sitting in hash chains that you haven't accessed, so the storage space hasn't been recycled. Doing it this way may also incur additional overhead from needing to lock the database as you delete records (hence my suggestion to mark it as invalid using a lightweight sync, but allow anything currently using the record to continue on - sort of like RCU does).
A better way to invalidate the patent might be to attack it on utility - since it purports to be useful for large databases that have to be online at all times (as if the only way to expire records is to take everything down for a maintenance period), it seems pretty worthless since it doesn't show how to handle read and write locks, which any dynamic database would seem to need in some fashion (for instance, some process is in the middle of using the record that you're trying to delete - do you block (thus delaying the current query) until the other process has finished with the record?).
My post is a public disclosure and would invalidate any patent that uses it unchanged (patent must be filed within a year from my post AND show that the innovation was developed before my post in order to be valid). Doesn't mean someone couldn't get a patent, but the existence of that post would be the very definition of prior art. Not that I'm saying my suggestion is worthy of being patented, mind you.
I won't comment on the validity, it seems pretty obvious to combine techniques for accessing/modifying a hashed/linked list with combing a list for items to delete, but there's a trivial work-around for it.
Don't delete items as you comb through them, simply mark them as invalid and put them on a list of records to be recovered. Periodically, or when running low on storage, delete items on the to-be-deleted list. Might even be faster when multi-threaded if the invalidate can be done with a lightweight synchronization rather than locking the record(s) out while recycling them; can even keep a private list of invalidated records, then add that to a global list to be recycled.
Claims 2, 4, 6, 8 are ridiculous on the face of it, though - using dynamic limits for ANYTHING is not novel unless you can show a significant problem that hasn't been solved before. Simply specifying a dynamic value that a routine uses to count the number of iterations of a process, length of time to spend doing something, number of things to do in a pass, etc, is 40 years old at least.
What I'm suggesting is not a fixed "drop to 70%/drop to 50%/drop to 10%" after a certain amount of usage (though what you describe is certainly better than almost all current cap systems, since it resets after a short while). What I'm suggesting is a system that drops you down to whatever rate is available (giving everyone who wants to use more the exact same bandwidth, and not affecting anyone else).
Your description of a once-a-month reset is an example of a bad way of doing it, and with what I suggest, you don't need an explicit night-time cap/pricing, you just naturally get to use more bandwidth at night since demand is lower. It doesn't ever penalize you for transferring a lot of data, it simply throttles you only when it needs to, and then it never throttles you lower than anyone else is being throttled.
It really isn't any different from a cable connection - there's a maximum total bandwidth available in any specific location, and using less than that bandwidth doesn't reduce costs.
What I'd like to see is a fairly quickly changing prioritization based on recent usage. If you haven't used any bandwidth in the last few minutes, then you have highest priority which allows you to transfer at a high rate for a short time. Keep track of recent bandwidth through a decaying average; if too much total bandwidth is being used (over the system/area/cell/whatever bottleneck), start moving a cap value down until the total is back down to acceptable range. Anyone who is using more than the cap is brought down to that value; anyone using less is not affected. A short time of no use at all (say a minute or two) would leave you back at normal high priority.
Tune it so things like loading a normal web page or downloading a reasonable amount of e-mail runs fast, and high volume transfers will run at whatever rate is available rather than an artificial limit. People will shift their usage to times when more is available (because there's less demand) which is exactly what you want.
Putting on a pair of glasses with a color filter is a simple way to give someone the ability to be color-blind, in those rare cases such as this where it would be an advantage. It's not so easy going the other way. Interesting article, nonetheless.
You use a lot of words, but they don't really make sense when put together. A "tutor script"? A timeout error every second that flushes the keyboard buffer to common?
The common "chat" program was talkomatic ("talk" on Unix systems is very similar, it allowed up to 6 people to communicate at once, with any number of additional people to monitor a channel), and it really wouldn't matter if everyone on the system was in it, it was fairly efficient, so I don't know why they'd want to prevent people from using it. The only resource it would use would be a terminal. Did they also disable TERM-talk, Personal Notes, notesfiles, and all games as well? I'd have thought you'd be more interested in writing a game in order to stick it to them rather than write a hideously inelegant and inefficient version of talkomatic.
PLATO was fairly conservative in giving out resources - if you went in "background" mode, you could use all the processing available, but got lower priority, and wouldn't interfere with anyone else running in "foreground".
Why wouldn't they just delete the author signons of anyone who implemented code they didn't want on the system, anyway? You can't write code anonymously on a PLATO system, and if they were trying to control things so tightly that they objected to people talking to one another, surely they'd tightly control who got author signons.
I really don't think Charley was trying to crash it, so it wasn't a "denial of service" attack. In fact, there was no service, so nothing was being denied! All these stories of "well, I typed this and it crashed the system" aren't DOS attacks. Deliberately doing it repeatedly, and in a way that couldn't be easily locked out (e.g. by deleting your user account and banning you from the computer room) might constitute a DOS attack, but there has to be an intent to Deny Service to one or more other people.
Well, the -ext- command was used to send data to an arbitrary piece of "external" equipment attached to the terminal. A couple devices were a 4-voice music synthesizer, a Votrax voice synthesizer, and a random-access audio play-back device.
It was useful with some of the equipment for another user's program to be able to send such external data to your equipment and vice versa. Most people didn't have anything attached, but the system didn't know that. With nothing attached, all it did was make your terminal really really slow, as the other program queued up output for you that was basically thrown away, but had to be sent anyway (the external data took up about 3 character's worth in the data stream, with about 180 characters/second being output).
The system actually had pretty good security, and insulated each user from the other in terms of resource usage, and this wasn't strictly speaking a security breach, but this was a way to interfere with other users in an unintended way. It didn't take the entire system down, it only interfered with the terminals that were targeted.
Asking him if he's done his homework isn't inappropriate.
If you read the article, you'll see that the case in question was a 32 year old man posing as a 17 year old, talking to a 12 year old girl who claimed to be 13. He was talking to the girl on-line and over the phone, and at issue was whether a) he actually intended to have physical contact with her; and b) if the talk in question was sexually explicit (the talk was sexual in nature, but not "explicit"). The judge ruled that his acquittal was too strict an interpretation of the law, and that
"facilitating" could be interpreted to mean anything that would make it easier or more probable for a young person to be taken advantage of.
The law in question makes it a crime to
communicate by computer with underage children or adolescents for the purpose of facilitating the commission of the offences.
So first, the law hasn't been changed; second, the interpretation is nowhere near that you can be charged under it for any old conversation with a kid. You should indeed be very careful if you start getting into areas of sexuality, and I'm troubled that it does leave things a bit vague, but it isn't nearly as bad as everyone is making it out to be.
A fair-allocation method would be fine, but there's no need to tie it to "using > x rate for more than y minutes" or leave you in a lower priority status for a specified time, nor would there need to be any sort of transfer cap. A proper fair-allocation algorithm would kick in when the capacity approaches 100% (more to the point, when queuing delays exceed some bound), at which point the highest bandwidth users get throttled down to whatever point drops the demand low enough. Anyone trying to use more than that would be given that much, no more. Anyone using less than that wouldn't be throttled at all.
A throttling mechanism that simply throws packets away is almost worse than no mechanism at all. It should queue up packets and send them out at the throttled rate, as much as possible, and send ICMP source quench messages to allow the sender to slow down without having traffic dropped. Otherwise you can increase congestion with all the error correcting going on.
Speaking as someone who actually thought about these exact issues in the 80's, I can tell you that it was obvious even then. An even better solution than what you said (I haven't read the patent, so I'm not sure EXACTLY what their solution is) is to aggregate the RESULTS of the incoming messages in the server, then send out a periodic update of all changed status (e.g. of ship velocity, damage done, etc.) This applies also to game-generated changes (monster hits you for xxx, two asteroids collided and bounced or were destroyed, whatever).
Much more interesting is the issue of security vs. server load - i.e. what should the server do to prevent cheats by the client, do you trust the client or do you have the server carry out most actions and only distribute information that the client should have (e.g. the location of a unit behind a wall, do you send that to the client and then trust the client to not show the user, or do you not even send it in order to prevent a client cheat even though that costs server CPU cycles to determine). You can never really prevent aim-bots and the like, but at least you can prevent seeing through (or even shooting through) walls. Note that cheats like these are primarily of interest for PvP play, and thus are also most annoying for people who want an even playing field.
CVS does not allow you to commit a file that is not the same revision as the one you checked out. That's one of the primary functions. You MUST do an update (merge committed changes to that file back into your working copy and take care of any conflicts) before you can commit it. What it doesn't enforce is that you've updated all the files in your working directory, so inter-file inconsistencies can still bite you.
The only real problem I had with CVS is the "magic revision" numbers for branches and no good support for easily tagging a release version - each file is independent, each has to be updated with the tag for a specific revision, it's easy to create branches that only cover some files, so easy to get inconsistent branch labels, etc. It also didn't have any mechanism (other than comments) for marking what was merged with what. I'd have preferred something where you could "freeze" a release by saving the file revision numbers for the release into a specific file, and also having a "branch" file that simply saved the branch point and current revision, rather than doing magic with RCS tags and revision numbers.
CVS is very good with the "vendor branch" concept, something SVN doesn't really do. It's really nice if you simply get updated releases from another project, but have local changes that you want to keep across those updates.
Another good thing about CVS is also a weakness if you're a stickler for "correctness", as the underlying file structure is just a bunch of RCS files; that means you can use RCS commands on the repository to fix things up and use RCS commands to get information.
Very few people are going to mistakenly buy a Windows machine when they meant to buy one with Linux. That means that almost every return because it wasn't what they thought they were buying is going to be a return of Linux. No surprise there. Doesn't mean that people don't like Linux, and you won't see how many people mistakenly bought one with Linux and then decided to keep it anyway.
The only thing the return rate for Linux would be useful for is to add a bit of reality to sales figures, to correct Linux sales figures down a bit to account for those sales which were by mistake. THAT's a reasonable use of such a figure.
It makes more sense to do it as a loan calculation at a fixed interest rate; at a 5% interest rate and $250/month savings (that's used to pay off the loan), a $38,000 loan is paid off in 20 years. That's not taking into account the deterioration of the cells, nor any maintenance to batteries, but also assumes the cost of electricity is going to remain constant. If electricity rates increase and more than offset any decrease in the amount of power generated, the payoff time is less.
At 7%, it's about 30 years to pay off. At 4% it's a bit under 18 years.
At the end of the payoff period, it doesn't matter if the worth of the system has depreciated to zero. At worst you broke even; most likely some parts of the system are still useable, and the price of replacement panels will be very low, and efficiency much higher than it is now. It may even make economic sense to replace the panels sooner if you're still using any electricity off the grid.
Although I have no problem with Microsoft holding a monopoly on this sort of "innovation", commercial operating systems have always had different levels of functionality that can be enabled or disabled. Sun's UNIX, for example, had a very complex set of rights to run compilers, debuggers, specify the number of CPUs, and otherwise limit the available features or products that could run, with many different types of licensing schemes (e.g. number of simultaneous users).
Now, maybe the MS patent details some particularly clever method of validating usage, or changing allowed usage, but this type of thing is definitely not new.
Remember the IBM mainframes where you "upgraded" your hardware to have more disk space or memory by the Customer Engineer flipping a switch?
It's amazing how much money and effort has been spent on making products do less for the customer, and making them less reliable in the process. Wouldn't we all be better off if all that had been used to produce systems that worked better? Instead of HDTV sets that can't display high-resolution images from your computer because it doesn't have the right version of HDMI, they could have actually improved the quality and decreased the price, all because we can't solve the free rider problem in a more elegant fashion. My TV set won't pass on the full digital audio from my Blu-Ray player's HDMI output to my amp, it downsamples it to PCM stereo, even though the Blu-Ray player is happy to send a full resolution optical digital audio stream to that same amp. It isn't a problem with the TV, it happily sends 5-channel audio to the amp from digital broadcasts. It's so stupid that we have to put up with this garbage all so one industry can maximize profits.
That doesn't make much sense. There's maybe 20-30 bytes of data sent at the beginning of an HTTP session, then you send a selector string, and it sends you the result. Pretty much exactly the same as Gopher. It's HTML that's high overhead, not HTTP.
Only if you wanted to use their code. It was very easy to write a simple Gopher server. Not saying that NCSA making their http server code freely available didn't help in the adoption of http/html, it certainly was a strong factor, but the U of M gopher server wasn't the only one out there.
There were Gopher clients that didn't need external viewers for images (depending on the type of image file) or sound (depending on the type of sound file). I don't recall any that played movies, but the bandwidth wasn't really there for that anyway (for most people, that is). That wasn't really an issue. Adding HTML to Gopher would have solved a lot of Gopher's problems, but the real problem was that the Gopher protocol wasn't very flexible.
But Gopher had photos, music, and you clicked with a mouse to go where you wanted, did you ever use Gopher? The problem with Gopher was it was inflexible. Everything had to be in a tree hierarchy, and you ended up with one single piece of "content". So what HTML did (which, combined with the URL, is what the Web is; HTTP is not the best nor worst way of accessing it) was to add a layout language (which allowed playing music on a page with multiple pictures, for example) and combine content with the links that Gopher already had, which made it so that content pages were not all leaf nodes in the tree. By breaking the tree structure at that level, it basically freed the whole thing up to be an arbitrarily connected set of nodes. In other words, THE single most important thing that HTML introduced was <a href=...>, followed closely by <img...>
The main problem with Gopher was that all the content types were predefined, and links to other pages couldn't be mixed with any of those content types, only contained in an index page. So, all your content was always a leaf node, anything that wasn't a leaf node was an index page.
Before Mosaic came along there were proposals and (not very widespread) implementations of having one of the content types being "html".
The other problem with Gopher was that the "solution" to the initial inflexibility of the Gopher protocol was a real hack. Gopher+ was never widely used that I ever saw.
However, a Gopher server is simplicity itself. I wrote a Gopher server in C in about 120 lines of code (with all content/directory being static with shell scripts for managing them). Of course, you can do the same thing with an HTTP server, but it's somewhat bigger and slightly more complex. A Gopher client (without HTML support) is also a lot simpler to write than a full-blown HTML/HTTP client.
The other advantage of Gopher is that by having only one place for links, in a very fixed format, searching and indexing it was very easy.
Slashdot Mirror
The idea that by making it more difficult to pirate a game you'll get more people to buy it is flawed. Not many people who pirate stuff hardcore (as in, never buy the game, as opposed to those who try out a game, then buy it if they like it) will break down and buy it simply because they put in on-line validation requirements.
Those people who do try out a game using less-than-legitimate versions, then buy it if they like it, are much LESS likely to try it - and people who are inconvenienced by obtrusive DRM like this are also going to shy away from it in the future. Even though free Wi-Fi connections at restaurants, coffee shops, airports, etc. are becoming more widespread, there are still plenty of places where you might want to play something for a while without a network connection.
Anti-piracy measures affect sales of legitimate copies and proliferation of illegitimate copies. When they only decrease the latter, but don't increase the former, they're worthless, and if they negatively impact the legitimate sales, then they're worse than useless.
Actually, there are people who go in for the full simulation, including filing flight plans, talking to ATC (real people, running ATC simulators), fuel and weather issues, waiting for traffic, etc.
I'd say that flight simulators are an example where maximum realism (in visualization, physics and controls) can be good as a game.
They aren't patenting mixing hashes and linked lists. They have several references to using such data structures (including Knuth).
The "innovation" is to delete expired records while accessing the records, either adding new records or searching for existing ones, plus the additional "innovation" of dynamically configuring the maximum number of records to delete on each access request.
In other words, you look up the hash, go to the first record in a linked list. You check to see if it's expired, if so you delete it from the linked list, recycling the storage. You then move on to the next record. If it isn't expired, you check to see if it's the one you want. If not, rinse and repeat. Once you've deleted a configured number of records, you stop trying to delete them and just search for the one you want.
Of course, just doing this doesn't remove the need to sweep the entire database for expired records; they could be sitting in hash chains that you haven't accessed, so the storage space hasn't been recycled. Doing it this way may also incur additional overhead from needing to lock the database as you delete records (hence my suggestion to mark it as invalid using a lightweight sync, but allow anything currently using the record to continue on - sort of like RCU does).
A better way to invalidate the patent might be to attack it on utility - since it purports to be useful for large databases that have to be online at all times (as if the only way to expire records is to take everything down for a maintenance period), it seems pretty worthless since it doesn't show how to handle read and write locks, which any dynamic database would seem to need in some fashion (for instance, some process is in the middle of using the record that you're trying to delete - do you block (thus delaying the current query) until the other process has finished with the record?).
My post is a public disclosure and would invalidate any patent that uses it unchanged (patent must be filed within a year from my post AND show that the innovation was developed before my post in order to be valid). Doesn't mean someone couldn't get a patent, but the existence of that post would be the very definition of prior art. Not that I'm saying my suggestion is worthy of being patented, mind you.
I won't comment on the validity, it seems pretty obvious to combine techniques for accessing/modifying a hashed/linked list with combing a list for items to delete, but there's a trivial work-around for it. Don't delete items as you comb through them, simply mark them as invalid and put them on a list of records to be recovered. Periodically, or when running low on storage, delete items on the to-be-deleted list. Might even be faster when multi-threaded if the invalidate can be done with a lightweight synchronization rather than locking the record(s) out while recycling them; can even keep a private list of invalidated records, then add that to a global list to be recycled. Claims 2, 4, 6, 8 are ridiculous on the face of it, though - using dynamic limits for ANYTHING is not novel unless you can show a significant problem that hasn't been solved before. Simply specifying a dynamic value that a routine uses to count the number of iterations of a process, length of time to spend doing something, number of things to do in a pass, etc, is 40 years old at least.
What I'm suggesting is not a fixed "drop to 70%/drop to 50%/drop to 10%" after a certain amount of usage (though what you describe is certainly better than almost all current cap systems, since it resets after a short while). What I'm suggesting is a system that drops you down to whatever rate is available (giving everyone who wants to use more the exact same bandwidth, and not affecting anyone else).
Your description of a once-a-month reset is an example of a bad way of doing it, and with what I suggest, you don't need an explicit night-time cap/pricing, you just naturally get to use more bandwidth at night since demand is lower. It doesn't ever penalize you for transferring a lot of data, it simply throttles you only when it needs to, and then it never throttles you lower than anyone else is being throttled.
For a cell connection, the limited resource is bandwidth to the cell you're connected to. The bandwidth in some other time zone is irrelevant.
It really isn't any different from a cable connection - there's a maximum total bandwidth available in any specific location, and using less than that bandwidth doesn't reduce costs.
What I'd like to see is a fairly quickly changing prioritization based on recent usage. If you haven't used any bandwidth in the last few minutes, then you have highest priority which allows you to transfer at a high rate for a short time. Keep track of recent bandwidth through a decaying average; if too much total bandwidth is being used (over the system/area/cell/whatever bottleneck), start moving a cap value down until the total is back down to acceptable range. Anyone who is using more than the cap is brought down to that value; anyone using less is not affected. A short time of no use at all (say a minute or two) would leave you back at normal high priority.
Tune it so things like loading a normal web page or downloading a reasonable amount of e-mail runs fast, and high volume transfers will run at whatever rate is available rather than an artificial limit. People will shift their usage to times when more is available (because there's less demand) which is exactly what you want.
Putting on a pair of glasses with a color filter is a simple way to give someone the ability to be color-blind, in those rare cases such as this where it would be an advantage. It's not so easy going the other way. Interesting article, nonetheless.
You use a lot of words, but they don't really make sense when put together. A "tutor script"? A timeout error every second that flushes the keyboard buffer to common?
The common "chat" program was talkomatic ("talk" on Unix systems is very similar, it allowed up to 6 people to communicate at once, with any number of additional people to monitor a channel), and it really wouldn't matter if everyone on the system was in it, it was fairly efficient, so I don't know why they'd want to prevent people from using it. The only resource it would use would be a terminal. Did they also disable TERM-talk, Personal Notes, notesfiles, and all games as well? I'd have thought you'd be more interested in writing a game in order to stick it to them rather than write a hideously inelegant and inefficient version of talkomatic.
PLATO was fairly conservative in giving out resources - if you went in "background" mode, you could use all the processing available, but got lower priority, and wouldn't interfere with anyone else running in "foreground".
Why wouldn't they just delete the author signons of anyone who implemented code they didn't want on the system, anyway? You can't write code anonymously on a PLATO system, and if they were trying to control things so tightly that they objected to people talking to one another, surely they'd tightly control who got author signons.
So, your story doesn't really make any sense.
I really don't think Charley was trying to crash it, so it wasn't a "denial of service" attack. In fact, there was no service, so nothing was being denied! All these stories of "well, I typed this and it crashed the system" aren't DOS attacks. Deliberately doing it repeatedly, and in a way that couldn't be easily locked out (e.g. by deleting your user account and banning you from the computer room) might constitute a DOS attack, but there has to be an intent to Deny Service to one or more other people.
Well, the -ext- command was used to send data to an arbitrary piece of "external" equipment attached to the terminal. A couple devices were a 4-voice music synthesizer, a Votrax voice synthesizer, and a random-access audio play-back device.
It was useful with some of the equipment for another user's program to be able to send such external data to your equipment and vice versa. Most people didn't have anything attached, but the system didn't know that. With nothing attached, all it did was make your terminal really really slow, as the other program queued up output for you that was basically thrown away, but had to be sent anyway (the external data took up about 3 character's worth in the data stream, with about 180 characters/second being output).
The system actually had pretty good security, and insulated each user from the other in terms of resource usage, and this wasn't strictly speaking a security breach, but this was a way to interfere with other users in an unintended way. It didn't take the entire system down, it only interfered with the terminals that were targeted.
Asking him if he's done his homework isn't inappropriate.
If you read the article, you'll see that the case in question was a 32 year old man posing as a 17 year old, talking to a 12 year old girl who claimed to be 13. He was talking to the girl on-line and over the phone, and at issue was whether a) he actually intended to have physical contact with her; and b) if the talk in question was sexually explicit (the talk was sexual in nature, but not "explicit"). The judge ruled that his acquittal was too strict an interpretation of the law, and that
The law in question makes it a crime to
So first, the law hasn't been changed; second, the interpretation is nowhere near that you can be charged under it for any old conversation with a kid. You should indeed be very careful if you start getting into areas of sexuality, and I'm troubled that it does leave things a bit vague, but it isn't nearly as bad as everyone is making it out to be.
NC-17 may or may not be "obscenity". Just because it goes beyond R doesn't mean it has no artistic merit, etc. Be careful how you label things.
A fair-allocation method would be fine, but there's no need to tie it to "using > x rate for more than y minutes" or leave you in a lower priority status for a specified time, nor would there need to be any sort of transfer cap. A proper fair-allocation algorithm would kick in when the capacity approaches 100% (more to the point, when queuing delays exceed some bound), at which point the highest bandwidth users get throttled down to whatever point drops the demand low enough. Anyone trying to use more than that would be given that much, no more. Anyone using less than that wouldn't be throttled at all.
A throttling mechanism that simply throws packets away is almost worse than no mechanism at all. It should queue up packets and send them out at the throttled rate, as much as possible, and send ICMP source quench messages to allow the sender to slow down without having traffic dropped. Otherwise you can increase congestion with all the error correcting going on.
Speaking as someone who actually thought about these exact issues in the 80's, I can tell you that it was obvious even then. An even better solution than what you said (I haven't read the patent, so I'm not sure EXACTLY what their solution is) is to aggregate the RESULTS of the incoming messages in the server, then send out a periodic update of all changed status (e.g. of ship velocity, damage done, etc.) This applies also to game-generated changes (monster hits you for xxx, two asteroids collided and bounced or were destroyed, whatever).
Much more interesting is the issue of security vs. server load - i.e. what should the server do to prevent cheats by the client, do you trust the client or do you have the server carry out most actions and only distribute information that the client should have (e.g. the location of a unit behind a wall, do you send that to the client and then trust the client to not show the user, or do you not even send it in order to prevent a client cheat even though that costs server CPU cycles to determine). You can never really prevent aim-bots and the like, but at least you can prevent seeing through (or even shooting through) walls. Note that cheats like these are primarily of interest for PvP play, and thus are also most annoying for people who want an even playing field.
CVS does not allow you to commit a file that is not the same revision as the one you checked out. That's one of the primary functions. You MUST do an update (merge committed changes to that file back into your working copy and take care of any conflicts) before you can commit it. What it doesn't enforce is that you've updated all the files in your working directory, so inter-file inconsistencies can still bite you.
The only real problem I had with CVS is the "magic revision" numbers for branches and no good support for easily tagging a release version - each file is independent, each has to be updated with the tag for a specific revision, it's easy to create branches that only cover some files, so easy to get inconsistent branch labels, etc. It also didn't have any mechanism (other than comments) for marking what was merged with what. I'd have preferred something where you could "freeze" a release by saving the file revision numbers for the release into a specific file, and also having a "branch" file that simply saved the branch point and current revision, rather than doing magic with RCS tags and revision numbers.
CVS is very good with the "vendor branch" concept, something SVN doesn't really do. It's really nice if you simply get updated releases from another project, but have local changes that you want to keep across those updates.
Another good thing about CVS is also a weakness if you're a stickler for "correctness", as the underlying file structure is just a bunch of RCS files; that means you can use RCS commands on the repository to fix things up and use RCS commands to get information.
Very few people are going to mistakenly buy a Windows machine when they meant to buy one with Linux. That means that almost every return because it wasn't what they thought they were buying is going to be a return of Linux. No surprise there. Doesn't mean that people don't like Linux, and you won't see how many people mistakenly bought one with Linux and then decided to keep it anyway.
The only thing the return rate for Linux would be useful for is to add a bit of reality to sales figures, to correct Linux sales figures down a bit to account for those sales which were by mistake. THAT's a reasonable use of such a figure.
It makes more sense to do it as a loan calculation at a fixed interest rate; at a 5% interest rate and $250/month savings (that's used to pay off the loan), a $38,000 loan is paid off in 20 years. That's not taking into account the deterioration of the cells, nor any maintenance to batteries, but also assumes the cost of electricity is going to remain constant. If electricity rates increase and more than offset any decrease in the amount of power generated, the payoff time is less.
At 7%, it's about 30 years to pay off. At 4% it's a bit under 18 years.
At the end of the payoff period, it doesn't matter if the worth of the system has depreciated to zero. At worst you broke even; most likely some parts of the system are still useable, and the price of replacement panels will be very low, and efficiency much higher than it is now. It may even make economic sense to replace the panels sooner if you're still using any electricity off the grid.
Although I have no problem with Microsoft holding a monopoly on this sort of "innovation", commercial operating systems have always had different levels of functionality that can be enabled or disabled. Sun's UNIX, for example, had a very complex set of rights to run compilers, debuggers, specify the number of CPUs, and otherwise limit the available features or products that could run, with many different types of licensing schemes (e.g. number of simultaneous users).
Now, maybe the MS patent details some particularly clever method of validating usage, or changing allowed usage, but this type of thing is definitely not new.
Remember the IBM mainframes where you "upgraded" your hardware to have more disk space or memory by the Customer Engineer flipping a switch?
It's amazing how much money and effort has been spent on making products do less for the customer, and making them less reliable in the process. Wouldn't we all be better off if all that had been used to produce systems that worked better? Instead of HDTV sets that can't display high-resolution images from your computer because it doesn't have the right version of HDMI, they could have actually improved the quality and decreased the price, all because we can't solve the free rider problem in a more elegant fashion. My TV set won't pass on the full digital audio from my Blu-Ray player's HDMI output to my amp, it downsamples it to PCM stereo, even though the Blu-Ray player is happy to send a full resolution optical digital audio stream to that same amp. It isn't a problem with the TV, it happily sends 5-channel audio to the amp from digital broadcasts. It's so stupid that we have to put up with this garbage all so one industry can maximize profits.
That doesn't make much sense. There's maybe 20-30 bytes of data sent at the beginning of an HTTP session, then you send a selector string, and it sends you the result. Pretty much exactly the same as Gopher. It's HTML that's high overhead, not HTTP.
Only if you wanted to use their code. It was very easy to write a simple Gopher server. Not saying that NCSA making their http server code freely available didn't help in the adoption of http/html, it certainly was a strong factor, but the U of M gopher server wasn't the only one out there.
There were Gopher clients that didn't need external viewers for images (depending on the type of image file) or sound (depending on the type of sound file). I don't recall any that played movies, but the bandwidth wasn't really there for that anyway (for most people, that is). That wasn't really an issue. Adding HTML to Gopher would have solved a lot of Gopher's problems, but the real problem was that the Gopher protocol wasn't very flexible.
But Gopher had photos, music, and you clicked with a mouse to go where you wanted, did you ever use Gopher? The problem with Gopher was it was inflexible. Everything had to be in a tree hierarchy, and you ended up with one single piece of "content". So what HTML did (which, combined with the URL, is what the Web is; HTTP is not the best nor worst way of accessing it) was to add a layout language (which allowed playing music on a page with multiple pictures, for example) and combine content with the links that Gopher already had, which made it so that content pages were not all leaf nodes in the tree. By breaking the tree structure at that level, it basically freed the whole thing up to be an arbitrarily connected set of nodes. In other words, THE single most important thing that HTML introduced was <a href=...>, followed closely by <img ...>
The main problem with Gopher was that all the content types were predefined, and links to other pages couldn't be mixed with any of those content types, only contained in an index page. So, all your content was always a leaf node, anything that wasn't a leaf node was an index page.
Before Mosaic came along there were proposals and (not very widespread) implementations of having one of the content types being "html".
The other problem with Gopher was that the "solution" to the initial inflexibility of the Gopher protocol was a real hack. Gopher+ was never widely used that I ever saw.
However, a Gopher server is simplicity itself. I wrote a Gopher server in C in about 120 lines of code (with all content/directory being static with shell scripts for managing them). Of course, you can do the same thing with an HTTP server, but it's somewhat bigger and slightly more complex. A Gopher client (without HTML support) is also a lot simpler to write than a full-blown HTML/HTTP client.
The other advantage of Gopher is that by having only one place for links, in a very fixed format, searching and indexing it was very easy.