Not at all. The transaction is just a way of submitting the credit information. The checking of that information against the bank records is done by the bank... those records are the secrets in this transaction.
All the code does is take the number the merchant types/scans in and sends it off to the bank saying "Can this #/Exp Date, purchase this ammount? (y/n)". If the merchant types in a bogus number, or scans a fake card, the software will ask the bank about it, and should. It's the job of the bank to not authorize accounts that don't exist.
The software might do some basic checking, for the correct number of digits, or such, but that'd just be to save network traffic on obviously incorrect entries, not for the verification itself.
There is no honest security reason for not releasing source, it's just part of an overall policy of not releasing any information. This isn't even really security related.
Re:But is it worht the risk to attempt
on
Living Terrors
·
· Score: 2
Greg Egan wrote a short story about that in his book _Axiomatic_. The character creating the virus tailors it to eat rubber (to stop people from using condoms) and be deadly almost instantly. It was designed to infect everyone (airborne) and then pairbond to the first body-fluid sample it found from another carrier. After that, any other swapping of body fluids was deady.
The character spread it by infecting himself with the airborne stage of it and taking a world tour.
Paying a flat fee for Napster access regardless of downloading big-business music like the Backstreet Boys or indie music like Chris's subsidizes the studios by penalizing the independants.
It's as if you were buying MP3s on a CD from Napster, and they charged $5/disk for special music CDs (like in Canada) on which the tax goes to the MPAA to distribute to artists. But they distribute it to their artists, not to the independent artist whose music you actually filled the CD with.
We will invent new payment methods, but we need to make sure that we end up paying the artists, not a hold-over company that doesn't do anything.
If Napster does go with a flat fee, they need to track whose music was downloaded and pass the correct percentage of that along to the artists who made the music that was downloaded.
We need to make sure that nobody tries to enforce a mandatory MP3 sales tax even on free music. That would be a barrier to people trying new music, and it would drive independant musicians out of business with the management costs. (If every artist who distributed their work on the net was required to collect an MP3 tax, they'd all have to support some approved payment method, and then pass that money on to the government (and thus to the MPAA) at the end of the year...)
So whatever payment method is developed needs to be one that directly rewards the artist, if they choose to accept it, and if not, is completely free to the consumer.
That's a pretty good description of how it'll work...
I wonder though where they're going to get an embedded CPU capable of doing realtime decryption of data at a speed anywhere near what the hard-drive can read at. If they can't, and this is a moving target, they're going to end up with a crippled product where protected media is read at a crawl, imagine trying to seek in a large movie this way... Ugh.
And this protection assumes that someone isn't going to crack it once and distribute the resulting unprotected media. Especially because 'cracking' in this sense means using something akin to 'Play to Disk' in your MP3 player, or recording the data it sends to the audio out disk.
This just prevents basic copying, but as soon as one of the readers gets compromised and distributed, anyone will be able to make unemcumbered copies with ease.
It'll be just like now, except that people like me (bored sysadmins with an OC3 available) will have a personal grievance with the media companies.
Once again, the stupid media companies are the weakest link in their own chain. They'll never get anything right and they'll piss everyone off trying.
Heinlein writes a lot about how communism is bad, which falls into the trap of assuming that communism is the same as a *archy, and that capitalism is a democracy.
The got way too caught up in the anti-Russia thing to realize that he was anti *Russia*, not anti *communism*. (Yes, he may have problems with communism too, but he presents anti-Russia arguments against both.)
Admittedly, this is circumstantial, because it says nothing about his views on how to vote to make a democracy work, but it does show that he can't clearly identify the issue, and that he's got a large stake in pushing democracy even if it's got flaws.
Do you understand the GPL? If they were to release binaries of modified GPLed programs for public consumption, they'd need to release source. If they either distribute patches in house only, or don't modify existing progs, they'll be fine.
Anything they write to run on Linux doesn't have any restrictions about GPL, because it's not a modification to an existing program (or doesn't have to be) so they can use whatever license they like, if any.
You say it WILL fail... Well, everything will fail eventually. But I've had OCed systems that have run just as long as non OCed systems.
As the poster you replied to said, increasing a bus from 66 to 100 will almost always (and it's easy to check) simple increase the PCI and AGP divisors, and you'll end up with a system where all the components except the CPU are running at rated speed.
So, you can go from 366 -> 550 in your Celeron, and the only part that is running above spec is the CPU. And CPUs all came out of the same batch anyways, meaning you've probably got a CPU from the same set as others that ended up marked at 450s and 500s, so it's probably barely above spec.
So, if anything fails, it'll be the CPU, because it's the only thing that'll be running fast, and CPUs are some of the most robust parts. With a proper fan you'll get five or six years, easily, of 24/7 usage from a good CPU. If OCing it drop that a year, who cares? It'll still be many times longer than that system will end up in production usage.
Cons: Perhaps shorter CPU life. (unproven, with good cooling)
Pros: Cheaper, faster.
With the savings from buying a 366 instead of a 550, you could probably buy 256MB of ram, definately 128... That would boost the performance even more.
In a cost/benefit scenario. Your wages - at least $150 a day... The CPU price difference between what you buy, and what it would cost to buy what you OC it to - probably $100 - $200... So you're spending at most 30 minutes to overclock, toss a decent fan on, and test it. The math works out strongly in favour of doing the overclocking.
Parsing the BSP is fairly simple. I mean, the specs for the format are published, and the format makes sense, it was picked for ease of use and speed, not obscurity. (Worst comes to work, run a Q2 bot with a side-by-side mod that simply exists to do traceline calls between the bot and it's victim, using the actual Q2 engine itself.)
Shooting at feet and such is trivial. If the weapon is the RL, aim lower...
What's hard is using area-denying weapons to herd players. Spam a few grens in an area, not to hit the enemy, but to keep them from running there. Then work them towards a spot you can hit them from a distance by shooting around them, gradually narrowing the net, forcing them to move to the shrinking safe area or take damage.
I've never seen a bot handle this well on either end. They don't understand delayed gratification. They don't understand trying to miss when you have a low chance of hitting, because of a much higher chance later. Similarly, they are easily trapped, not realizing some splash now is better than being herded into lava later.
Movement analysis is fairly easy. To figure out how the enemy moves around and shoot them. What is hard to being able to do clever things instead of making impossible shots.
As soon as they hire me, to do what is immediately obvious to anyone smarter than a troll.
If id was going for cheat-proof, they'd have done this long ago. They're not, they're going for other goals, and making some tradeoffs.
Two people can both be right and come up with different answers, if they ask slightly different questions. Id's priorities are not the same as when they first wrote the game, and are not the same as mine would be, were I to tinked with the source now.
They'll think you're incapable of reading the posts you reply to.
The idea is that trusted computers, for limited applications *can* exist, provided all work done to them is done by a trusted company with trusted employees.
You can send data to Bob, to get it processed, without Alice intercepting it, you can also keep Bob from actually viewing the data, he just supplies the black-boxes need to process it. You still need two trusted parties, but they don't have to be the two main parties, as long as one client is using a trusted and secure client.
I doubt you'd sell many of these, but if data-havens ever become possible, it might happen. Ditto with a lot of off-site checking on stuff like circuits.
Sure. In this case, the chip is the black box, with extra stuff tacked on, at low levels.
I still have doubts though... If the chip doesn't do onboard public key crypto, fast enough to swap banks of ram in and out, then this can't work. It'll only work if the only data outside of the trusted area is encrypted.
It could happen, but it's simply shrinking the trusted part from the whole computer to the CPU, making the CPU do the authentication at every step, instead of making it do the work once as it loads the info into the computer.
[...] limit reign in on the amazing amount of flexibility purposely built into the engine in the first place?
Sure, and they didn't implement skeletal animation, which reduced the number of mods. And they didn't implement specular highlights, or accurate sound reverb, or a million other things. These all limit the flexability of the engine, but none of these lacks ruined the game. A lack of fullbright colors could be more accurately represented with light generation, if it was *needed* in a mod anyway. Changes in Quake mean that the new game wouldn't be exactly like Quake, but that's not a bad thing. Quake wasn't exactly like doom, yet still rocked. Quake isn't gospel, and changes to it aren't heresy.
I might be inferring this incorrectly, but it sounds like your saying using the PHS at all is a bad thing. If that's the case, all I can say is NOT using the PHS is a BAD thing. It's a TREMENDOUS speed up [...]
Yes, using the PHS is a speed up. It's a kludge. Imperfect results, but close enough for government work, and results in a speed increase.
But, if they had thought about the Stooge bots, and ZBots of the future, they might have decided that a bit of speed was a good trade for less chance to cheat.
Having a more accurate PHS and PVS, to determine when sounds and enemy models are sent would save network traffic, and would drastically reduce the chance of cheating. With a large PVS, someone can be directly opposite you on a wall, like in the Q1 start map by the inital start spot. The location of their model will be sent to you even if you've got a wall between you, because you're in the same PVS leaf. This would happen in a long hallway too, where clients seperated by 10 seconds of running could be 'visible' to each other, through the walls. Not only is this a waste of bandwidth, but it gives the cheater ample time to identify their enemy's movement.
If models were sent only when they could possibly be seen, you'd have a flicker of warning before the enemy ran around the wall, if you were cheating, but you wouldn't have the seconds of warning you often have.
Recording the shortest distance between all portals visible to each other, like a mini-vis table, would speed distance calculation. Do a search from the player, to the nearest portal, to the one next closest to the enemy, etc, to the enemy. If the shortest distance is N units, send model info. Certain bizarre rooms, with millions of pillars for instance, would play havok with these, but they already kill performance for vis reasons...
This isn't a perfect solution, and it just what I came up with in a few minutes. I'm sure Carmack, with testing could come up with something better, if cheating prevention was higher on their list of priorities.
Yes, the game is incredible. But it was made with goals other than being cheat resistant. Yes, all ideas mentioned would limit either speed or flexability to a degree. But, have you ever heard "One time, Under Budget, Error Free - pick two"? Everything involves tradeoffs. They didn't make some because their priorities were different than they are now.
Got me there. I meant "Can't [easily]..." but was lazy.
As you yourself already said, [include link...]
Hey, no fair actually reading what I write to make me stay consistent...:)
I mean, bots can't plug in a simple mathematical formula and cope with it. Herding a player involves knowing where you don't want that player to be, and knowing the area well enough to know where you do want them to be, and the choke points involved in cutting them off.
Theoretically a bot could figure this out on the fly, but more likely, for a few years at any rate, it'll simply launch rockets at the 'protected' item and dare you to get too close, instead of defending it in a clever and dynamic way.
So, I stand by the "bots can't" part of my post in all but the most theoretical ways...
And, there's the problem. An untrustable system being expected to run a trusted program. It's theoretically impossible, even given perfect implementation.
If they want this to work, they'd need to sell black-box PCs, which exist for this purpose only, and can be passed an encrypted file, decrypt it, check for bugs, and return a 'yes' or 'error in area x,y'...
The system doesn't need to be, and in fact, shouldn't be, closed source.
It just has to be designed in such a way that any tampering with it will render it unoperable before it's opened to the point where data can be read off of it. Nothing is 100%, so they'd need to set a target budget, like the model that is simply encased in black plastic is rated to take $100k to break, the model shipped in plastic, in a safe, guarded by the marines, is estimate to take $5M to break, etc.
But the machine can't be modifiable by anyone 'untrusted' at any point. All modification need to be done by the trusted vendor of the product, who one expects to be bonded and insured, etc etc..
Only then can trusted programs be run on the system and be expected to be safe.
Designing Quake in open source wouldn't solve the problem of writing aim bots. Aim bots take that knowledge the play has, or could easily have (by looking behind them) and acting upon it.
But, designing Quake as open source, and seeing how easy a hack like making players show through walls, for instance, would be could be expected to lead to different design choices.
Quake uses the PVS and PHS (potentially visible/hearable sets. The PVS is the list of all 'areas' visible from the player's location, and the PHS is the PVS and all PVSes...) for knowing when to send information about one player to the next. In some fairly connected levels, the PHS is *huge* and the client knows where the other players are far in advance. This could be changed to use an algorithm to determine the quickest route for both entities to take before being visible to each other, and if that's under the update delay (ie, likely to happen before the next upate) then the information would be sent. Otherwise, it wouldn't. Thus, cheaters would have a much smaller window of opportunity.
One other 'bug' is that if the player models are replaces with a big pointy model, where each axis has a big arrow, you can see these arrows far ahead of the actual player, even through walls and floors (in the other player is in your PHS). Writing the code, in many spots, to generate errors if the models were above a certain maximum reasonable size, and if they passed through world brushes, would make this a non-trivial hack, unlike now where you load the models into an editor, add a couple of points, and boom, can see people through walls.
The skin, the image that wraps around the wireframe, can be altered. A white skin naturally shows up better in shadows than a dark one. In Quake some colors are 'full bright', meaning that they 'emit light'... A skin made up on these literally is visible in complete darkness. If they changed the renderer to not use these drawing modes for characters skins, this would eliminate this easy for of cheating. A skilled programmer could add this in, but it would take a lot more work than simply opening up MS Paint and flood-filling a PCX...
Also, the design of the basic game could change a little. Quake 1 had few instant-hit weapons. The shotgun and the lightning gun are the only ones. Bots of course favor instant-hit weapons because they don't have to predict the enemy's movements, they simply line up the crosshairs and fire. The shotgun isn't a big deal because it's fairly low damage and the spread makes it less effective at medium or long range. The lightning gun is a Quake1 bot's favorite weapon. Knowing this, they could have designed the game to reduce the effectiveness of the lightning gun in such a way.
Perhaps it's heavy and induces some movement lag on the character, preventing instant-turn shot... These are many ways the game could have been changed to prevent there from being a perfect weapon for the bots. And really, the lightning gun, and later the railgun, are no-brainer guns. All it takes are reflexes and a fast computer/vid card. Other weapons take thought, to predict the enemy movements, something a bot isn't good at.
There are *many* design changes they could have, and pretty well, would have to have made, if Quake 1 was designed with open source in mind.
To be precise, if you have a hacking contest where you pay $x to the winner, if the computer is not cracked, all you have proved is that the machine is not crackable in that ammount of time, by anyone who values $x more than a potential $x * n, where n is the number of potential juicy targets running this system, or by anyone who values $x more than being anonymous.
So, if you offer $10k for a two-month contest to crack into a potential bank security system, you may get a few bored people playing around with it, but the real devious people will wait till it's "proven" uncrackable, and they'll crack into the bank running it, perhaps getting away with more money.
This does produce semi-valid results, for small values of 'n', the number of potential juicy targets, or very high values of $x... If Microsoft paid $1M for 'arbitrary binary' exploits on Win9x, they'd get a lot of takers, because $1M is more than you'd probably get in any reasonable win9x attacks, because nobody uses win9x for anything important. Similarly, if you only had one system, and $x was high enough to rival any potential gains from cracking the system later, you might get people seriously trying.
But, over all, it's a publicity stunt. You aren't guaranteed to get the same people trying, or with the same motivation, so you can't expect the same results.
And I'm not a bullshit OOP bigot. I do 90% of my 'real' code in C.
In C, if you read a string of characters, you need to have space allocated for it. You can either read a set ammount and truncate, or read a variable ammount and auto-allocate.
But, whatever you do, you need to do it yourself. You can't simply say "string data; data stdin;" and get the whole string, to the limit of available memory.
You can code a routine to do this, anyone who writes anything which accepts user input has probably written a reusable 'safe input' module. But, you still have to do it yourself.
And you have to do it EVERYWHERE you look at data. You can't make any assumptions. If 999 of 1000 expected comma seperated integers are integers, the 1000th might be something else entirely, consisting of non-numeric characters. You need to check for nor just the correct inputs, but ALL forms of incorrect input. And then, you need to attach basic error handling to all of these.
If a fucking pain. A good half, at least, of anything I write is spent in input checking, even when the actual input it done in a couple of lines, and could be scanned with a few scanf()s (albeit badly.)
It's not a good reason to switch to what might be a more crippled language, just because that language keeps you from making errors, but you need to recognize the weaknesses of your tools or you can't work past them.
Congrats on a well written explanation of how it's possible to have a more secure system...
But, how is this possible without trusted binaries and all?
I mean, eventually there's an account which can do disk maintenance. This account has to be able to read the HD, and thus can read all information and write it to files another user has access to.
How do you allow ultimate access without creating what is essentially a root login with a restricted shell?
What seems to me to be the best idea is to modify most everything so that only the barest cores of the OS run as root, everything else would run as a user. Thus TCP stack exploits could crash the TCP stack, and take the machine off the net, but they couldn't give access to anything, etc.
Heh, I was suprised to read a post by someone who actually understood that you need two trusted parties for encryption to work, and who understood the Quake client/server model and it's strengths/limitations... Then I read the name...
The 'unfortunate' truth is that there is nothing which runs on your computer which you can't subvert with some work. As long as the computer is an open platform, which you can debug programs on, and monitor device traffic on, this will be the case. There is NO way around this. Anything the program can run for authentication, the hacker can rip apart to spoof said authentication.
Both game models, peer-to-peer and client-server are vulnerable to this, in their own ways.
The problem is that you can't control what the client does. If it returns the same information, you don't know what program is running.
There is no cryptographic was around this. For crypto to be used to communicate between two parties, you have to trust both. If I send you a private encrypted message, I can make sure it can't be decrypted without the key (or cracking, which we'll assume is impossible in the scope of the problem.) but once you have that message, you can share it with the world and I can't stop you.
Likewise, with digital signatures, I can be sure you sent me the information that appears to be from you, but that doesn't tell me if you're telling the truth or lying.
Anything added onto this is security by obscurity (which, is possible in open source code, simply see the OCCC for proof...) If the source code is available, it's a bit easier, but that doesn't mean binaries are secure. Anything that happens on my computer is ultimately subject to my control.
So, what can be done?
Nothing really. Servers can check for unlikely shots and moves, but as JC notes, this ends up eventually kicking off Threshes as bots, and allowing any bots set to perform well but still below the cutoff.
There are some tricks, such as invisible targets that are labelled players, but that the humans don't see, this will stop bots, until someone analyzes stored network code from before they got detected as a bot, sees this invisible target, and codes the bot to ignore invisible targets. One generation of bots stopped, no net gain.
The only way to stop cheaters is to ship computers as black-boxes, that run a restricted OS, don't allow OS-level code, for debuggers and such, and that have private keys and serial numbers embedded, and are encassed in tamper-resistant materials. But, if we liked that sort of computer, we'd be using an N64...
Half measures, such as dongles, have been suggested, but are simply more obscurity. Any half-measure *will* fail.
So, are we doomed? Are good network games something we'll never have?
Nope.
I downloaded a ZBot, as did most people I know. Certainly any quake-playing programming person I know downloaded one. But I don't play with it. I don't even keep it installed. Why? Because it's not fun. A few wankers find distupting games to be fun, but if we simply vote to kick them and continue, they will eventually go away, simply because bugging people for fun relies on people being bugged.
We have to put up with these people if we want the freedom of open computers, in the same way we have to put up with street mimes in a free society. But, if you just ignore them, they will go away.
I should mention that bots exist in games like Quake because there are some actions that require little mental skill.
Shooting a railgun is trivial. A monkey could be trained to do it, if they had a fast computer and a nice video card. This is why bots are usually used with the railgun. It's a no-brainer. You don't often see bots use weapons like rockets, or grenaes, especially across an open area, because those are least effective when fired at the current player location. To work, they need to be fired either where the player is going to be, or where you don't want the player, to herd them. Bots can't do this.
If we want to get rid of bots, we'd be 90% of the way there if we'd remove the no-brainer weapons.
Your comments about proxy bots are... unimaginative.
I can find a poorly written proxy bot that I can kill by exploiting obvious weaknesses, but that doesn't mean all proxy bots have to be that flawed.
The fire-frame-unsync you mention is a 'bug' in Quake and Quake2 (perhaps in Quake3) where certain animations override others. For instance, everyone in Q2 slid when they ran and fired, because there wasn't a proper running & shooting animation... There's no reason a bot's shots would look different from those of a players, the network code is the same after all, if there wasn't a complete spin in there, which only happens if the bots are given a 360 degree field of view.
A 'skilled' bot operator runs a bot with a much smaller field of view, and plays an intelligent game as well. They aren't so easy to spot, or kill.
I personally doubt you could kill a 360-degree viewing z-bot in q2dm1, with a semi intelligent player (ie, grabbing the odd bit of health). Your only strategy would be to stock up on armor to try to take enough rail hits to give you time to brute-force it to death.
And I know you couldn't take on a reasonably skilled player using the zbot 'intelligently', and subtly enough to not be noticed as a bot.
If bots are programmed to expect movement in straight lines, then parabolic curves will fool them, and jumping will make them miss. If you teach them about parabolic curves, then they'll hit jumpers. Air control will still avoid their shots, until they are programmed to cope with it. Anything you can do can be programmed into a client-side bot. Eventually the only thing you'll be able to do is dodge randomly and hope that the bot's lag keeps it from tracking you.
Quake already does this. The server is completely in charge of if you live or die, if you run out of health, you fall over, even if you've found the bytes for health and locked them at 100...
What you're concerned about is actions... Bots can shoot better, and dodge better (theoretically) than humans. How does the server tell it that perfect spin while holding the lightning on a guy who ran by was Thresh, or a bot?
Similarly, the client can change the way information is displayed. Perhaps they change the Z sorting for items, so that all players that are drawn are drawn in front of walls, even if they'd normally be behind... Throw in a simple GL effect to indicate the difference between an X-Ray view and a non-X-Ray view and you've got a way to avoid ever being suprised at corners.
It's impossible to stop cheating in an environment with untrusted clients. Even with black boxes like console systems, it just raises the bar, making it harder to cheat.
Oh, I'm anti-patent, so I kill diabetics... Way to bring in the irrelevant information.
I said, the only way to *make money* with a patent is to use it as a landmine. There's a difference between using a patent to prevent others from copying your work, and using the patent to make money directly.
The use ou describe for patents is the intended, and legitimate usage. What people want to stop is the devious, patent-warfare that we hear all about on Slashdot.
And I don't doubt that patents have stifled devolopment on many products. Patents can serve to keep competitors from stealing a hard-earned research project, or to mine an area, by patenting enough of the 'fairly obvious' methods that a competitor will have to step on some of your patents to do any work in that area.
You have the common myopic view, "if it's good in my field, it must be good in all fields."
You may work as a contracter, but you don't understand the logistics involved in writing a complex contract[...]
Really? I do something every two weeks or so on average, and run a profitable business, yet I don't understand what I'm doing. And you base your opinion on my lack of comprehension on the fact that I don't agree with your knee-jerk myopic and brashly stated opinions?
I understand perfectly well that there are so many loopholes in what should be fairly straightforward rules that a complex contract can't be considered secure without passing it to a lawyer, and then it's only 'probably secure'.
That's not a decent way to run a legal system, with rules so complex that no one person, with a lifetime of study, can understand them all. In this system, ignorance is not a defense, but it's guaranteed, there *will be* laws that someone has not heard of, not to mention loopholes, and specific cases, of those laws. And this is before you get to the tons of precedents which can in some cases go almost completely against the spirit or letter of the written law.
I can also understand, and you seem to fail to grasp this, the difference between a needlessly complex legal system, and a patent system. I can also understand that some things need changing, not abolishing.
I'm not against patents, I'm against patents being used to stifle innovation. I'm against a patent system so complex that a patent registration, done properly, is estimated to cost at least a million dollars, after all paperwork and legal fees are paid.
Any idiot can, as you did, find a few successes in anything, Mussolini is said to have made the trains run on time, but this, even if assumed to be true, says nothing about the man or his polcies. To similarly point to a few examples, in one industry, of patents being necessary, doesn't mean they're implemented tolerably, let alone the best they could be, or that they should be applied in an identical fashion across all industries.
Anyhow, i'm going on vacation now, no reply. Bye
This, your personal attacks, and the irrelevant "I'm saving lives, so you're wrong" arguments you use are perfect examples of what to do when you don't have a logical leg to stand on.
Have fun on your vacation, it's very common that they start late on christmas.
Or maybe you just wanted to get the last word, fling a little mud, insult someone, and then walk away...
Yes, but how does this justify shortening the life of a patent? Even within a given industry different technologies have different lifetimes. You can't say on granting a patent, well, this invention looks like it will have a useful life of 8 years. There is no way to predict anything of the sort.
A computer design may have a life of 5 years, but there are technologies in it that have lots longer lifetimes. Look at how long people have been using the basic photoresist process. The only real change has been to go to shorter UV wavelengths. If you have a technology in a rapidly moving field that is still useful after 20 years, you must have come up with a sound invention, and you deserve the benefits.
Patents, if enforced in a rapidly moving industry, can limit innovation. Rarely is a good idea protected by a single patent, it's usually completely covered by patenting it, and every possible variation of it, meaning that almost anything based on it is covered, meaning that if anyone wants to improve on what's often a fairly basic idea, they have to come at it from a whole new angle, or go through a couple of generations of development with no hope of a return on the investment.
It wouldn't be hard to stall development, if What's His Name actually did have an enforceable patent on the microchip, people would have either had to license it, or find some completely new technology, and the industry probably wouldn't have developed so quickly.
[...] and THEN you are looking at waiting in some cases up to 50 years to get your product sold.
Not likely. I haven't seen any company that will develop technology they don't intend to pay off sooner than that. Just because new computers tend to be bought every 18 months, doesn't mean there's 17 dry months, and 1 boom month.
And patent disclosure isn't complete. You have to make public the details of the protected invention, but all the skills the company developed in working in that area aren't required to be disclosed. Even if the patent period was almost expired, the company would still have a headstart in competing with the other companies looking to enter the field, both in experience, and in market share, having been the first to market.
Well, you must mean BEFORE filing the patent.
No. If independant discovery can be proved, and there's no reason to expect that the burden of proof wouldn't be with the claimant, then the patent should be nullified. The idea of a patent is that you get monopoly protection in exchange for publicising your novel idea. If someone else provably invents the same thing independantly, then your idea isn't that novel, and doesn't deserve protection.
Or, if it is ruled to be novel, but you and the other inventor both happened onto it at the same time by chance, then a coinventor status seems to be a good idea. Seems to be a better idea than immediately striking down the patent if there's a coinventor...
Obvious because there were two independent inventors? No Way.
Exactly, it's still a novel idea, even though two people did develop it at the same time, so if it was a physical process (ie, patentable) it would deserve some protection, but is the work of one of them more deserving simply because they filed the papers sooner than the other?
Not needed. It's already part of the law. In fact this is why Xerox lost when it sued Apple for copying the GUI from PARC. It waited until the Mac had been on the market for 5 years. The Judge threw it out for lack of diligence.
And yet, we see many examples of companies patenting trivial things, like selling data over a network, and then suing companies, years later (the patents are dated in the early to mid nineties) suing companies that have started businesses in those areas.
Sure, these may get struck down, if anyone could afford a legal battle, but with the 'valid until proved otherwise' attitude of the patent office, a stupid patent you can't afford to fight is as dangerous as a valid patent.
I'd also like to see the patent office foot the initial bill in patent challenges, and bill the loser only after the fight, so that companies can afford to challenge crooks who patent the insanely obvious. They might start to raise the bar on applications if they got stuck with the bill from morons patenting air, going bankrupt when presented with a bill for the failed defense, and vanishing.
Whoa, good comeback. I don't agree with you, so I'm wrong. Wow, did you spend much time in school to be able to come up with that? It's a given that you'll be a trial lawyer, with big fancy city talk like that.
I'm out of school, own my own business, and do programming as a consultant. I've probably signed more contracts than most people, because every job I do has at least one.
Feh, you're the ignorant one. If I don't bow and scrape and thank lawyers for every complex and pointless law, then I'm just too ivory tower. You probably think I'm a communist too, don't you.
I'm sick of the fact that laws can't be straightforward. I think the biggest reason is that it's job security for lawyers, like spaghetti code is for programmers. Our legal system is setup to require every participant to have a lawyer, and to stretch everything out as long as possible.
Haven't you heard the quotes like "The only people who win in a patent trial are the lawyers"? The only way to make money on a patent it to use them like landmines, catching companies after they've independantly invented whatever it was you patented, and making it cheaper for them to bow down to your legal blackmail than fight.
And the lawyers get rich from this. Is it any wonder that so many laws go on a lawmakers, and that laws get more and more complex?
Different industries move at different speeds, a computer hardware idea from conception to market, and one market cycle (8 months or so) is around five years. For software, it's around two years, and with interface design (one-click type things) probably three years.
Big changes, in a slower-moving industry, should be protected longer, because the product cycle, at the end of which, a very different set of products is released, is longer. Not only would it take a lot longer to design and prototype a new chassis, but safety testing would add to that. And then, one year of car sales doesn't see a lot of change. A '98 is much the same as a '99, only over five or so years do you see the ammount of change you do in the computer industry in a few seasons.
So, some parts of the automotive industry would deserve longer protection.
The length of protection needs to be based on the ammount of time needed to develop the product, and to market it, taking advantage of it for long enough to recoup development costs.
The example of the metallic glass alloys isn't valid. If they didn't have the technology finished, they shouldn't have been able to patent it. And if they had it ready, but couldn't convince people to use it, this is a marketting problem, not a patent problem. But, if the industry moves so slowly that factory upgrades are very infrequent, maybe longer protection would be appropriate in this limited area.
My changes to the patent process...
7. Independant discovery either nullifies the patent completely, or grants identical rights to the other developers.
8. Protect it or lose it, like trademarks. If you are aware of, or should be with due vigilance, a company using your patented method, and you don't immediately notify them of your patent, you lose all rights regarding that patent.
#7 is obvious. If someone else independantly discovered it, then it's either too obvious to warrant a patent, or both parties deserve rights to it. This is for thing like Calculus, independantly discovered by Newton and Leibniz, which are definately unobvious, even today not many people independantly discover them, but neither one deserves total credit. (Or in the case of Calculus being a patentable physical process, total patent control.)
#8 would prevent companies from patenting a wide range of fairly simple ideas, then using them like landmines. Wait till a company uses those ideas in a product and is making money, then notify them of their infringement and force a massive settlement.
Slashdot Mirror
Not at all. The transaction is just a way of submitting the credit information. The checking of that information against the bank records is done by the bank... those records are the secrets in this transaction.
All the code does is take the number the merchant types/scans in and sends it off to the bank saying "Can this #/Exp Date, purchase this ammount? (y/n)". If the merchant types in a bogus number, or scans a fake card, the software will ask the bank about it, and should. It's the job of the bank to not authorize accounts that don't exist.
The software might do some basic checking, for the correct number of digits, or such, but that'd just be to save network traffic on obviously incorrect entries, not for the verification itself.
There is no honest security reason for not releasing source, it's just part of an overall policy of not releasing any information. This isn't even really security related.
Greg Egan wrote a short story about that in his book _Axiomatic_. The character creating the virus tailors it to eat rubber (to stop people from using condoms) and be deadly almost instantly. It was designed to infect everyone (airborne) and then pairbond to the first body-fluid sample it found from another carrier. After that, any other swapping of body fluids was deady.
The character spread it by infecting himself with the airborne stage of it and taking a world tour.
It's an interesting story.
I think Chris makes sense.
Paying a flat fee for Napster access regardless of downloading big-business music like the Backstreet Boys or indie music like Chris's subsidizes the studios by penalizing the independants.
It's as if you were buying MP3s on a CD from Napster, and they charged $5/disk for special music CDs (like in Canada) on which the tax goes to the MPAA to distribute to artists. But they distribute it to their artists, not to the independent artist whose music you actually filled the CD with.
We will invent new payment methods, but we need to make sure that we end up paying the artists, not a hold-over company that doesn't do anything.
If Napster does go with a flat fee, they need to track whose music was downloaded and pass the correct percentage of that along to the artists who made the music that was downloaded.
We need to make sure that nobody tries to enforce a mandatory MP3 sales tax even on free music. That would be a barrier to people trying new music, and it would drive independant musicians out of business with the management costs. (If every artist who distributed their work on the net was required to collect an MP3 tax, they'd all have to support some approved payment method, and then pass that money on to the government (and thus to the MPAA) at the end of the year...)
So whatever payment method is developed needs to be one that directly rewards the artist, if they choose to accept it, and if not, is completely free to the consumer.
That's a pretty good description of how it'll work...
I wonder though where they're going to get an embedded CPU capable of doing realtime decryption of data at a speed anywhere near what the hard-drive can read at. If they can't, and this is a moving target, they're going to end up with a crippled product where protected media is read at a crawl, imagine trying to seek in a large movie this way... Ugh.
And this protection assumes that someone isn't going to crack it once and distribute the resulting unprotected media. Especially because 'cracking' in this sense means using something akin to 'Play to Disk' in your MP3 player, or recording the data it sends to the audio out disk.
This just prevents basic copying, but as soon as one of the readers gets compromised and distributed, anyone will be able to make unemcumbered copies with ease.
It'll be just like now, except that people like me (bored sysadmins with an OC3 available) will have a personal grievance with the media companies.
Once again, the stupid media companies are the weakest link in their own chain. They'll never get anything right and they'll piss everyone off trying.
I have to agree...
Heinlein writes a lot about how communism is bad, which falls into the trap of assuming that communism is the same as a *archy, and that capitalism is a democracy.
The got way too caught up in the anti-Russia thing to realize that he was anti *Russia*, not anti *communism*. (Yes, he may have problems with communism too, but he presents anti-Russia arguments against both.)
Admittedly, this is circumstantial, because it says nothing about his views on how to vote to make a democracy work, but it does show that he can't clearly identify the issue, and that he's got a large stake in pushing democracy even if it's got flaws.
Do you understand the GPL? If they were to release binaries of modified GPLed programs for public consumption, they'd need to release source. If they either distribute patches in house only, or don't modify existing progs, they'll be fine.
Anything they write to run on Linux doesn't have any restrictions about GPL, because it's not a modification to an existing program (or doesn't have to be) so they can use whatever license they like, if any.
You say it WILL fail... Well, everything will fail eventually. But I've had OCed systems that have run just as long as non OCed systems.
As the poster you replied to said, increasing a bus from 66 to 100 will almost always (and it's easy to check) simple increase the PCI and AGP divisors, and you'll end up with a system where all the components except the CPU are running at rated speed.
So, you can go from 366 -> 550 in your Celeron, and the only part that is running above spec is the CPU. And CPUs all came out of the same batch anyways, meaning you've probably got a CPU from the same set as others that ended up marked at 450s and 500s, so it's probably barely above spec.
So, if anything fails, it'll be the CPU, because it's the only thing that'll be running fast, and CPUs are some of the most robust parts. With a proper fan you'll get five or six years, easily, of 24/7 usage from a good CPU. If OCing it drop that a year, who cares? It'll still be many times longer than that system will end up in production usage.
Cons: Perhaps shorter CPU life. (unproven, with good cooling)
Pros: Cheaper, faster.
With the savings from buying a 366 instead of a 550, you could probably buy 256MB of ram, definately 128... That would boost the performance even more.
In a cost/benefit scenario. Your wages - at least $150 a day... The CPU price difference between what you buy, and what it would cost to buy what you OC it to - probably $100 - $200... So you're spending at most 30 minutes to overclock, toss a decent fan on, and test it. The math works out strongly in favour of doing the overclocking.
Parsing the BSP is fairly simple. I mean, the specs for the format are published, and the format makes sense, it was picked for ease of use and speed, not obscurity. (Worst comes to work, run a Q2 bot with a side-by-side mod that simply exists to do traceline calls between the bot and it's victim, using the actual Q2 engine itself.)
Shooting at feet and such is trivial. If the weapon is the RL, aim lower...
What's hard is using area-denying weapons to herd players. Spam a few grens in an area, not to hit the enemy, but to keep them from running there. Then work them towards a spot you can hit them from a distance by shooting around them, gradually narrowing the net, forcing them to move to the shrinking safe area or take damage.
I've never seen a bot handle this well on either end. They don't understand delayed gratification. They don't understand trying to miss when you have a low chance of hitting, because of a much higher chance later. Similarly, they are easily trapped, not realizing some splash now is better than being herded into lava later.
Movement analysis is fairly easy. To figure out how the enemy moves around and shoot them. What is hard to being able to do clever things instead of making impossible shots.
As soon as they hire me, to do what is immediately obvious to anyone smarter than a troll.
If id was going for cheat-proof, they'd have done this long ago. They're not, they're going for other goals, and making some tradeoffs.
Two people can both be right and come up with different answers, if they ask slightly different questions. Id's priorities are not the same as when they first wrote the game, and are not the same as mine would be, were I to tinked with the source now.
They'll think you're incapable of reading the posts you reply to.
The idea is that trusted computers, for limited applications *can* exist, provided all work done to them is done by a trusted company with trusted employees.
You can send data to Bob, to get it processed, without Alice intercepting it, you can also keep Bob from actually viewing the data, he just supplies the black-boxes need to process it. You still need two trusted parties, but they don't have to be the two main parties, as long as one client is using a trusted and secure client.
I doubt you'd sell many of these, but if data-havens ever become possible, it might happen. Ditto with a lot of off-site checking on stuff like circuits.
Sure. In this case, the chip is the black box, with extra stuff tacked on, at low levels.
I still have doubts though... If the chip doesn't do onboard public key crypto, fast enough to swap banks of ram in and out, then this can't work. It'll only work if the only data outside of the trusted area is encrypted.
It could happen, but it's simply shrinking the trusted part from the whole computer to the CPU, making the CPU do the authentication at every step, instead of making it do the work once as it loads the info into the computer.
Sure, and they didn't implement skeletal animation, which reduced the number of mods. And they didn't implement specular highlights, or accurate sound reverb, or a million other things. These all limit the flexability of the engine, but none of these lacks ruined the game. A lack of fullbright colors could be more accurately represented with light generation, if it was *needed* in a mod anyway. Changes in Quake mean that the new game wouldn't be exactly like Quake, but that's not a bad thing. Quake wasn't exactly like doom, yet still rocked. Quake isn't gospel, and changes to it aren't heresy.
Yes, using the PHS is a speed up. It's a kludge. Imperfect results, but close enough for government work, and results in a speed increase.
But, if they had thought about the Stooge bots, and ZBots of the future, they might have decided that a bit of speed was a good trade for less chance to cheat.
Having a more accurate PHS and PVS, to determine when sounds and enemy models are sent would save network traffic, and would drastically reduce the chance of cheating. With a large PVS, someone can be directly opposite you on a wall, like in the Q1 start map by the inital start spot. The location of their model will be sent to you even if you've got a wall between you, because you're in the same PVS leaf. This would happen in a long hallway too, where clients seperated by 10 seconds of running could be 'visible' to each other, through the walls. Not only is this a waste of bandwidth, but it gives the cheater ample time to identify their enemy's movement.
If models were sent only when they could possibly be seen, you'd have a flicker of warning before the enemy ran around the wall, if you were cheating, but you wouldn't have the seconds of warning you often have.
Recording the shortest distance between all portals visible to each other, like a mini-vis table, would speed distance calculation. Do a search from the player, to the nearest portal, to the one next closest to the enemy, etc, to the enemy. If the shortest distance is N units, send model info. Certain bizarre rooms, with millions of pillars for instance, would play havok with these, but they already kill performance for vis reasons...
This isn't a perfect solution, and it just what I came up with in a few minutes. I'm sure Carmack, with testing could come up with something better, if cheating prevention was higher on their list of priorities.
Yes, the game is incredible. But it was made with goals other than being cheat resistant. Yes, all ideas mentioned would limit either speed or flexability to a degree. But, have you ever heard "One time, Under Budget, Error Free - pick two"? Everything involves tradeoffs. They didn't make some because their priorities were different than they are now.
Got me there. I meant "Can't [easily]
Hey, no fair actually reading what I write to make me stay consistent...
I mean, bots can't plug in a simple mathematical formula and cope with it. Herding a player involves knowing where you don't want that player to be, and knowing the area well enough to know where you do want them to be, and the choke points involved in cutting them off.
Theoretically a bot could figure this out on the fly, but more likely, for a few years at any rate, it'll simply launch rockets at the 'protected' item and dare you to get too close, instead of defending it in a clever and dynamic way.
So, I stand by the "bots can't" part of my post in all but the most theoretical ways...
And, there's the problem. An untrustable system being expected to run a trusted program. It's theoretically impossible, even given perfect implementation.
If they want this to work, they'd need to sell black-box PCs, which exist for this purpose only, and can be passed an encrypted file, decrypt it, check for bugs, and return a 'yes' or 'error in area x,y'...
The system doesn't need to be, and in fact, shouldn't be, closed source.
It just has to be designed in such a way that any tampering with it will render it unoperable before it's opened to the point where data can be read off of it. Nothing is 100%, so they'd need to set a target budget, like the model that is simply encased in black plastic is rated to take $100k to break, the model shipped in plastic, in a safe, guarded by the marines, is estimate to take $5M to break, etc.
But the machine can't be modifiable by anyone 'untrusted' at any point. All modification need to be done by the trusted vendor of the product, who one expects to be bonded and insured, etc etc..
Only then can trusted programs be run on the system and be expected to be safe.
Designing Quake in open source wouldn't solve the problem of writing aim bots. Aim bots take that knowledge the play has, or could easily have (by looking behind them) and acting upon it.
But, designing Quake as open source, and seeing how easy a hack like making players show through walls, for instance, would be could be expected to lead to different design choices.
Quake uses the PVS and PHS (potentially visible/hearable sets. The PVS is the list of all 'areas' visible from the player's location, and the PHS is the PVS and all PVSes...) for knowing when to send information about one player to the next. In some fairly connected levels, the PHS is *huge* and the client knows where the other players are far in advance. This could be changed to use an algorithm to determine the quickest route for both entities to take before being visible to each other, and if that's under the update delay (ie, likely to happen before the next upate) then the information would be sent. Otherwise, it wouldn't. Thus, cheaters would have a much smaller window of opportunity.
One other 'bug' is that if the player models are replaces with a big pointy model, where each axis has a big arrow, you can see these arrows far ahead of the actual player, even through walls and floors (in the other player is in your PHS). Writing the code, in many spots, to generate errors if the models were above a certain maximum reasonable size, and if they passed through world brushes, would make this a non-trivial hack, unlike now where you load the models into an editor, add a couple of points, and boom, can see people through walls.
The skin, the image that wraps around the wireframe, can be altered. A white skin naturally shows up better in shadows than a dark one. In Quake some colors are 'full bright', meaning that they 'emit light'... A skin made up on these literally is visible in complete darkness. If they changed the renderer to not use these drawing modes for characters skins, this would eliminate this easy for of cheating. A skilled programmer could add this in, but it would take a lot more work than simply opening up MS Paint and flood-filling a PCX...
Also, the design of the basic game could change a little. Quake 1 had few instant-hit weapons. The shotgun and the lightning gun are the only ones. Bots of course favor instant-hit weapons because they don't have to predict the enemy's movements, they simply line up the crosshairs and fire. The shotgun isn't a big deal because it's fairly low damage and the spread makes it less effective at medium or long range. The lightning gun is a Quake1 bot's favorite weapon. Knowing this, they could have designed the game to reduce the effectiveness of the lightning gun in such a way.
Perhaps it's heavy and induces some movement lag on the character, preventing instant-turn shot... These are many ways the game could have been changed to prevent there from being a perfect weapon for the bots. And really, the lightning gun, and later the railgun, are no-brainer guns. All it takes are reflexes and a fast computer/vid card. Other weapons take thought, to predict the enemy movements, something a bot isn't good at.
There are *many* design changes they could have, and pretty well, would have to have made, if Quake 1 was designed with open source in mind.
To be precise, if you have a hacking contest where you pay $x to the winner, if the computer is not cracked, all you have proved is that the machine is not crackable in that ammount of time, by anyone who values $x more than a potential $x * n, where n is the number of potential juicy targets running this system, or by anyone who values $x more than being anonymous.
So, if you offer $10k for a two-month contest to crack into a potential bank security system, you may get a few bored people playing around with it, but the real devious people will wait till it's "proven" uncrackable, and they'll crack into the bank running it, perhaps getting away with more money.
This does produce semi-valid results, for small values of 'n', the number of potential juicy targets, or very high values of $x... If Microsoft paid $1M for 'arbitrary binary' exploits on Win9x, they'd get a lot of takers, because $1M is more than you'd probably get in any reasonable win9x attacks, because nobody uses win9x for anything important. Similarly, if you only had one system, and $x was high enough to rival any potential gains from cracking the system later, you might get people seriously trying.
But, over all, it's a publicity stunt. You aren't guaranteed to get the same people trying, or with the same motivation, so you can't expect the same results.
Not true.
And I'm not a bullshit OOP bigot. I do 90% of my 'real' code in C.
In C, if you read a string of characters, you need to have space allocated for it. You can either read a set ammount and truncate, or read a variable ammount and auto-allocate.
But, whatever you do, you need to do it yourself. You can't simply say "string data; data stdin;" and get the whole string, to the limit of available memory.
You can code a routine to do this, anyone who writes anything which accepts user input has probably written a reusable 'safe input' module. But, you still have to do it yourself.
And you have to do it EVERYWHERE you look at data. You can't make any assumptions. If 999 of 1000 expected comma seperated integers are integers, the 1000th might be something else entirely, consisting of non-numeric characters. You need to check for nor just the correct inputs, but ALL forms of incorrect input. And then, you need to attach basic error handling to all of these.
If a fucking pain. A good half, at least, of anything I write is spent in input checking, even when the actual input it done in a couple of lines, and could be scanned with a few scanf()s (albeit badly.)
It's not a good reason to switch to what might be a more crippled language, just because that language keeps you from making errors, but you need to recognize the weaknesses of your tools or you can't work past them.
Congrats on a well written explanation of how it's possible to have a more secure system...
But, how is this possible without trusted binaries and all?
I mean, eventually there's an account which can do disk maintenance. This account has to be able to read the HD, and thus can read all information and write it to files another user has access to.
How do you allow ultimate access without creating what is essentially a root login with a restricted shell?
What seems to me to be the best idea is to modify most everything so that only the barest cores of the OS run as root, everything else would run as a user. Thus TCP stack exploits could crash the TCP stack, and take the machine off the net, but they couldn't give access to anything, etc.
Heh, I was suprised to read a post by someone who actually understood that you need two trusted parties for encryption to work, and who understood the Quake client/server model and it's strengths/limitations... Then I read the name...
The 'unfortunate' truth is that there is nothing which runs on your computer which you can't subvert with some work. As long as the computer is an open platform, which you can debug programs on, and monitor device traffic on, this will be the case. There is NO way around this. Anything the program can run for authentication, the hacker can rip apart to spoof said authentication.
Both game models, peer-to-peer and client-server are vulnerable to this, in their own ways.
The problem is that you can't control what the client does. If it returns the same information, you don't know what program is running.
There is no cryptographic was around this. For crypto to be used to communicate between two parties, you have to trust both. If I send you a private encrypted message, I can make sure it can't be decrypted without the key (or cracking, which we'll assume is impossible in the scope of the problem.) but once you have that message, you can share it with the world and I can't stop you.
Likewise, with digital signatures, I can be sure you sent me the information that appears to be from you, but that doesn't tell me if you're telling the truth or lying.
Anything added onto this is security by obscurity (which, is possible in open source code, simply see the OCCC for proof...) If the source code is available, it's a bit easier, but that doesn't mean binaries are secure. Anything that happens on my computer is ultimately subject to my control.
So, what can be done?
Nothing really. Servers can check for unlikely shots and moves, but as JC notes, this ends up eventually kicking off Threshes as bots, and allowing any bots set to perform well but still below the cutoff.
There are some tricks, such as invisible targets that are labelled players, but that the humans don't see, this will stop bots, until someone analyzes stored network code from before they got detected as a bot, sees this invisible target, and codes the bot to ignore invisible targets. One generation of bots stopped, no net gain.
The only way to stop cheaters is to ship computers as black-boxes, that run a restricted OS, don't allow OS-level code, for debuggers and such, and that have private keys and serial numbers embedded, and are encassed in tamper-resistant materials. But, if we liked that sort of computer, we'd be using an N64...
Half measures, such as dongles, have been suggested, but are simply more obscurity. Any half-measure *will* fail.
So, are we doomed? Are good network games something we'll never have?
Nope.
I downloaded a ZBot, as did most people I know. Certainly any quake-playing programming person I know downloaded one. But I don't play with it. I don't even keep it installed. Why? Because it's not fun. A few wankers find distupting games to be fun, but if we simply vote to kick them and continue, they will eventually go away, simply because bugging people for fun relies on people being bugged.
We have to put up with these people if we want the freedom of open computers, in the same way we have to put up with street mimes in a free society. But, if you just ignore them, they will go away.
I should mention that bots exist in games like Quake because there are some actions that require little mental skill.
Shooting a railgun is trivial. A monkey could be trained to do it, if they had a fast computer and a nice video card. This is why bots are usually used with the railgun. It's a no-brainer. You don't often see bots use weapons like rockets, or grenaes, especially across an open area, because those are least effective when fired at the current player location. To work, they need to be fired either where the player is going to be, or where you don't want the player, to herd them. Bots can't do this.
If we want to get rid of bots, we'd be 90% of the way there if we'd remove the no-brainer weapons.
Your comments about proxy bots are... unimaginative.
I can find a poorly written proxy bot that I can kill by exploiting obvious weaknesses, but that doesn't mean all proxy bots have to be that flawed.
The fire-frame-unsync you mention is a 'bug' in Quake and Quake2 (perhaps in Quake3) where certain animations override others. For instance, everyone in Q2 slid when they ran and fired, because there wasn't a proper running & shooting animation... There's no reason a bot's shots would look different from those of a players, the network code is the same after all, if there wasn't a complete spin in there, which only happens if the bots are given a 360 degree field of view.
A 'skilled' bot operator runs a bot with a much smaller field of view, and plays an intelligent game as well. They aren't so easy to spot, or kill.
I personally doubt you could kill a 360-degree viewing z-bot in q2dm1, with a semi intelligent player (ie, grabbing the odd bit of health). Your only strategy would be to stock up on armor to try to take enough rail hits to give you time to brute-force it to death.
And I know you couldn't take on a reasonably skilled player using the zbot 'intelligently', and subtly enough to not be noticed as a bot.
If bots are programmed to expect movement in straight lines, then parabolic curves will fool them, and jumping will make them miss. If you teach them about parabolic curves, then they'll hit jumpers. Air control will still avoid their shots, until they are programmed to cope with it. Anything you can do can be programmed into a client-side bot. Eventually the only thing you'll be able to do is dodge randomly and hope that the bot's lag keeps it from tracking you.
Quake already does this. The server is completely in charge of if you live or die, if you run out of health, you fall over, even if you've found the bytes for health and locked them at 100...
What you're concerned about is actions... Bots can shoot better, and dodge better (theoretically) than humans. How does the server tell it that perfect spin while holding the lightning on a guy who ran by was Thresh, or a bot?
Similarly, the client can change the way information is displayed. Perhaps they change the Z sorting for items, so that all players that are drawn are drawn in front of walls, even if they'd normally be behind... Throw in a simple GL effect to indicate the difference between an X-Ray view and a non-X-Ray view and you've got a way to avoid ever being suprised at corners.
It's impossible to stop cheating in an environment with untrusted clients. Even with black boxes like console systems, it just raises the bar, making it harder to cheat.
I said, the only way to *make money* with a patent is to use it as a landmine. There's a difference between using a patent to prevent others from copying your work, and using the patent to make money directly.
The use ou describe for patents is the intended, and legitimate usage. What people want to stop is the devious, patent-warfare that we hear all about on Slashdot.
And I don't doubt that patents have stifled devolopment on many products. Patents can serve to keep competitors from stealing a hard-earned research project, or to mine an area, by patenting enough of the 'fairly obvious' methods that a competitor will have to step on some of your patents to do any work in that area.
You have the common myopic view, "if it's good in my field, it must be good in all fields."
Really? I do something every two weeks or so on average, and run a profitable business, yet I don't understand what I'm doing. And you base your opinion on my lack of comprehension on the fact that I don't agree with your knee-jerk myopic and brashly stated opinions?
I understand perfectly well that there are so many loopholes in what should be fairly straightforward rules that a complex contract can't be considered secure without passing it to a lawyer, and then it's only 'probably secure'.
That's not a decent way to run a legal system, with rules so complex that no one person, with a lifetime of study, can understand them all. In this system, ignorance is not a defense, but it's guaranteed, there *will be* laws that someone has not heard of, not to mention loopholes, and specific cases, of those laws. And this is before you get to the tons of precedents which can in some cases go almost completely against the spirit or letter of the written law.
I can also understand, and you seem to fail to grasp this, the difference between a needlessly complex legal system, and a patent system. I can also understand that some things need changing, not abolishing.
I'm not against patents, I'm against patents being used to stifle innovation. I'm against a patent system so complex that a patent registration, done properly, is estimated to cost at least a million dollars, after all paperwork and legal fees are paid.
Any idiot can, as you did, find a few successes in anything, Mussolini is said to have made the trains run on time, but this, even if assumed to be true, says nothing about the man or his polcies. To similarly point to a few examples, in one industry, of patents being necessary, doesn't mean they're implemented tolerably, let alone the best they could be, or that they should be applied in an identical fashion across all industries.
This, your personal attacks, and the irrelevant "I'm saving lives, so you're wrong" arguments you use are perfect examples of what to do when you don't have a logical leg to stand on.
Have fun on your vacation, it's very common that they start late on christmas.
Or maybe you just wanted to get the last word, fling a little mud, insult someone, and then walk away...
Patents, if enforced in a rapidly moving industry, can limit innovation. Rarely is a good idea protected by a single patent, it's usually completely covered by patenting it, and every possible variation of it, meaning that almost anything based on it is covered, meaning that if anyone wants to improve on what's often a fairly basic idea, they have to come at it from a whole new angle, or go through a couple of generations of development with no hope of a return on the investment.
It wouldn't be hard to stall development, if What's His Name actually did have an enforceable patent on the microchip, people would have either had to license it, or find some completely new technology, and the industry probably wouldn't have developed so quickly.
Not likely. I haven't seen any company that will develop technology they don't intend to pay off sooner than that. Just because new computers tend to be bought every 18 months, doesn't mean there's 17 dry months, and 1 boom month.
And patent disclosure isn't complete. You have to make public the details of the protected invention, but all the skills the company developed in working in that area aren't required to be disclosed. Even if the patent period was almost expired, the company would still have a headstart in competing with the other companies looking to enter the field, both in experience, and in market share, having been the first to market.
No. If independant discovery can be proved, and there's no reason to expect that the burden of proof wouldn't be with the claimant, then the patent should be nullified. The idea of a patent is that you get monopoly protection in exchange for publicising your novel idea. If someone else provably invents the same thing independantly, then your idea isn't that novel, and doesn't deserve protection.
Or, if it is ruled to be novel, but you and the other inventor both happened onto it at the same time by chance, then a coinventor status seems to be a good idea. Seems to be a better idea than immediately striking down the patent if there's a coinventor...
Exactly, it's still a novel idea, even though two people did develop it at the same time, so if it was a physical process (ie, patentable) it would deserve some protection, but is the work of one of them more deserving simply because they filed the papers sooner than the other?
And yet, we see many examples of companies patenting trivial things, like selling data over a network, and then suing companies, years later (the patents are dated in the early to mid nineties) suing companies that have started businesses in those areas.
Sure, these may get struck down, if anyone could afford a legal battle, but with the 'valid until proved otherwise' attitude of the patent office, a stupid patent you can't afford to fight is as dangerous as a valid patent.
I'd also like to see the patent office foot the initial bill in patent challenges, and bill the loser only after the fight, so that companies can afford to challenge crooks who patent the insanely obvious. They might start to raise the bar on applications if they got stuck with the bill from morons patenting air, going bankrupt when presented with a bill for the failed defense, and vanishing.
Whoa, good comeback. I don't agree with you, so I'm wrong. Wow, did you spend much time in school to be able to come up with that? It's a given that you'll be a trial lawyer, with big fancy city talk like that.
I'm out of school, own my own business, and do programming as a consultant. I've probably signed more contracts than most people, because every job I do has at least one.
Feh, you're the ignorant one. If I don't bow and scrape and thank lawyers for every complex and pointless law, then I'm just too ivory tower. You probably think I'm a communist too, don't you.
I'm sick of the fact that laws can't be straightforward. I think the biggest reason is that it's job security for lawyers, like spaghetti code is for programmers. Our legal system is setup to require every participant to have a lawyer, and to stretch everything out as long as possible.
Haven't you heard the quotes like "The only people who win in a patent trial are the lawyers"? The only way to make money on a patent it to use them like landmines, catching companies after they've independantly invented whatever it was you patented, and making it cheaper for them to bow down to your legal blackmail than fight.
And the lawyers get rich from this. Is it any wonder that so many laws go on a lawmakers, and that laws get more and more complex?
Different industries move at different speeds, a computer hardware idea from conception to market, and one market cycle (8 months or so) is around five years. For software, it's around two years, and with interface design (one-click type things) probably three years.
Big changes, in a slower-moving industry, should be protected longer, because the product cycle, at the end of which, a very different set of products is released, is longer. Not only would it take a lot longer to design and prototype a new chassis, but safety testing would add to that. And then, one year of car sales doesn't see a lot of change. A '98 is much the same as a '99, only over five or so years do you see the ammount of change you do in the computer industry in a few seasons.
So, some parts of the automotive industry would deserve longer protection.
The length of protection needs to be based on the ammount of time needed to develop the product, and to market it, taking advantage of it for long enough to recoup development costs.
The example of the metallic glass alloys isn't valid. If they didn't have the technology finished, they shouldn't have been able to patent it. And if they had it ready, but couldn't convince people to use it, this is a marketting problem, not a patent problem. But, if the industry moves so slowly that factory upgrades are very infrequent, maybe longer protection would be appropriate in this limited area.
My changes to the patent process...
7. Independant discovery either nullifies the patent completely, or grants identical rights to the other developers.
8. Protect it or lose it, like trademarks. If you are aware of, or should be with due vigilance, a company using your patented method, and you don't immediately notify them of your patent, you lose all rights regarding that patent.
#7 is obvious. If someone else independantly discovered it, then it's either too obvious to warrant a patent, or both parties deserve rights to it. This is for thing like Calculus, independantly discovered by Newton and Leibniz, which are definately unobvious, even today not many people independantly discover them, but neither one deserves total credit. (Or in the case of Calculus being a patentable physical process, total patent control.)
#8 would prevent companies from patenting a wide range of fairly simple ideas, then using them like landmines. Wait till a company uses those ideas in a product and is making money, then notify them of their infringement and force a massive settlement.