Wouldn't this mean that this is just another step in the direction of letting anyone make movies (without needing a billion dollars with of computers and another billion dollars worth of actors)?
The big problem there is not graphics quality - that's already there, take a look at Fallout 3 or Arkham Asylum at maximum graphical settings - it's the quality of tools. You'd need "digital actors" able to move, react and emote without you having to put every eyebrwo into place manually. You'd also need good-quality soft-body collision detection, physics, etc.
Everyone will be able to make movies when AI gets good enough to read the script and let you play the director with a microphone. Until then, that's limited to people with technical expertise and lots of free time on their hands.
Christ, what ever happened to basic responsibility? Or buy beware?
"Buyer beware" died with Rome. And good riddance too; after all, why wouldn't the sellers have responsibility for ensuring that their wares are what they're claiming them to be: a useful product? And no, burying "this might be junk" somewhere in a 50-page mumbo-jumbo legalese memo doesn't absolve you.
Why is it that people who talk about "responsibility" so often wish to absolve one party of all?
How about reading reviews before buying something or returning the product if you dont like it?
How about ensuring that what you're selling is of sufficient quality that the buyers don't demand your head on a spike?
Is lawsuit now the default action?
Should claiming that it's the buyer's fault you sold junk as working stuff be?
Currently, it could well be said that the two parties in the US are being run by the Nuts and the Creeps. I'll leave it to you to decide which is which.
If either of them had the nuts to stand up to their corporate overlords, we wouldn't be in the mess we are now.
I mean we're talking 720p is 1280x720. That's not exactly high resolution when you think of what the average monitor from 1990 or even 2000 can do, let alone now.
The average CRT monitor from 2000 could do far higher resolutions than the average LCD panel can nowadays. That's one thing we've regressed at.
I wonder if it would be possible to forget LCD and just build the monitor from small diodes? They are semiconductors, so there should be no reason they can't be made very small, and a quick look at Wikipedia seems to suggest that they come in red, green and blue.
If you would have considered this approach, your application would have rejected the message with duplicate images (perhaps logging this reaction somewhere for you to review later), and continued churning along without crashing.
It did reject the message. It simply happened at such a late stage of input processing (during database insertion) that the resulting exception went unhandled and caused the program to exit - which was precisely what I wanted to happen, since it left all the previous messages on-screen for me to see, and made it really clear just where the unexpected error happened.
Alternatively, you could have modeled your application on the Real World and realized that messages may contain, and often do, the same image more than once and expected that; but I understand that problem analysis is not very common these days.
So the way to avoid bugs is to not make any mistakes? Thanks, I'll keep that very useful advice in mind. You've certainly analyzed the problem well here, to come up with a solution that's so well applicable in the Real World.
Check out the OWASP Top Ten. Trying to maintain a black-list of all known bad input and all its variants is akin to an arms race in which you will always find yourself at the losing, reactionary end.
For what's basically a data mining program, there is no bad input. There's at most pointless input (in this case, messages that don't contain images), but the program can't know that given input is that before it has already been parsed.
Extract images, check if they are already in the database, insert those that are not, insert message contents (minus the images), and set up a connection between the message and images it contained. Also parse whatever info you can from the message (newsgroup, date, etc) and link them to the message and, by extension, the image. There are no erroneous inputs, just inputs that we can extract less or no information from.
It is nearly impossible if you want to enumerate all possible ways input can be wrong. Thus you should just enumerate all ways input is right. If you expecting for instance numerical input, don't look for ";" or ")" or anything that could have been inserted maliciously. Just throw everything away that doesn't fit [0-9]*.
That's nice and good if you can do it, but in general you can't. In my example before, the input is a string who's character encoding may or may not be known. Parts of it are machine-generated, parts are human-generated, everything is mixed together into a cheerful mess, and even the machine-generated parts tend to have errors (but a least in a predictable pattern). And I can't simply reject unclear input, since the channel is one-way, so what I get is the best I'm ever going to get; I either parse it succesfully, or lose the information.
More generally, as the power of the application input system approaches a Turing machine, input verification approaches impossible. You either use heuristics and accept that tehre's false positives or false negatives or both, or use strict verification and accept that verification of some inputs takes literally forever. And if you can't contact the user in unclear cases, you're faced with the task of deciding what level of ambiguity and chance of error is more acceptable than rejecting the input completely and with it any chance of getting it right.
You know the input your program can work with. So instead of trying to formulate rules how input may differ from the input you want to catch errors, write down the rules the input has to follow and reject everything else. This is straightforward.
Only for simple programs, or programs that can afford to not tolerate any error. However, anal-retentive error checking is a pain to work with; the end user ends up using most of his time to figuring out ways to get past the safeguards to get the program to do what he wants. If he can't control some part of the input (like my news archiver), he's out of luck. That's not really acceptable.
The best you can do in that kind of case is to make input parsing in layers. Each tries to make sense of the input from the previous layer, and is increasingly strict about it. In my example above, the error was finally caught at the database layer, which caused the insert program to shutdown - but the database itself remained fine and uncorrupted, and the insert program was supposed to quit in those conditions, since there's no way to handle an unknown error in a meaningful way without artificial intelligence.
I'm assuming you're joking, since I said nothing about amperage, and naturally if we're talking about an actual flip-flop unit in a stick of RAM, we're going to be talking about mA or even nA.
Which would take the peak power requirements down to 200 megawatts or 200 kilowatts, respectively. That's not exactly realistic either, if you think about it.
You'll excuse my ignorance, but from college I remember that usually you have 0-2V represent 0 and 3-5V represent 1. Does a 0 have a corresponding increase in amperage so that it levels out and uses the same amount of power?
If it did, then storing one zero bit would require 0-4 Watts and storing 1 requires 9-25 Watts. A full byte of ones would require 72-200 Watts, and a gigabyte around 77-215 gigawatts. Byt contrast, Hoover Dam has peak capacity of about 2 gigawatts.
And yes, security takes longer than doing it improperly. It always does, and that has to be taken seriously. And it is still cheaper than cleaning up the costs of exposing your customer's banking information to hackers, or your research to competitors in China.
Indeed. However, the customer disagrees, gives the job to whoever does it cheapest, and damn security. Then, when the shit they bought blows up on their faces, they'll get angry and write articles demanding the incompetent minimum wage programmers they insisted using due to being cheap be held legally liable for being worth every penny they got paid, and not a single one more.
Stop whining, man up, and take your shit seriously.
Hey, you make people compete with Chinese slave labour for lowest pay, don't be amazed they'll also compete for lowest quality.
For the bridge analogy, I'd consider a buffer overflow equivalent to missing a rivet. If you know what you're doing it shouldn't be possible. Trusting user-generated input is one of the first taboos you learn about in computer science.
I once coded a program for my own use that downloaded images from binary newsgroups, decoded them, and inserted them into a PostgreSQL database, with keywords extracted from the message. It was a nice program, handled multipart messages, and only stored each image once, using SHA1 hashes to check for dublicates - I even took the possibility of a hash collision into account and only used them as an index. No buffer overruns, no SQL injections, no nothing. Yet it crashed. So why did it crash?
Some moron included the same image twice in a single message.
It's fine to say "don't trust user input", but it's pretty much impossible to actually make sure that you've accounted for all possible ways it can be faulty, and this becomes harder the more powerful the program is, since using that power requires more complex input.
The reason? My CRT is very clear and is 1600x1200. The "upgrades" are 1280x1024. No, sorry.
My 19" CRT is also capable of 1600x1200@85Hz, but only use that resolution for games. My desktop runs at 1154x864, since that's the smallest size text stays readable. Windows's DPI scaling doesn't seem to work well in a single program...
I bought 5 surplus P4 machines with 512mb ram and 40gb HDDs for my community center's library. They have *CRT* monitors. Beat that!
My previous computer, before the current i5-750/Radeon 7550, was a 1GHz AMD Duron with Geforce 2MX. And I still use a CRT monitor, which is fine now that I've finally forced Windows to accept that refresh rate below 85Hz is not acceptable, no matter how badly some games want 60Hz.
Bugs are an error in the process, not the code. If you find a bug, you need to find the process error that allowed that bug to occur.
The error is inherent in the act of programming: you are turning vague descriptions into exact algorithm. Since the vague description can't specify the correct behaviour in all circumstances - if it did, it would be a complete and runnable program in itself - the programmer must use his imagination to try to find the circumstances where the resulting program might behave in an undesirable manner, and decide what it should do instead. Since it is impossible to guarantee that you've thought of every possible situation, you can't guarantee that the code is bug-free.
Of course there are ways to reduce bugs - checking that your inputs are within expected range, checking that memory allocations succeeded, checking that you aren't trying to stuff more stuff to a buffer than it can hold - but in general, any nontrivial program will have bugs. It's not avoidable, and you should plan your systems with that fact in mind (memory protection, sandboxing, firewalling, making core can't-fail-or-system-crashes components as trivially simple as possible, etc).
Making a movie where that's the plot and putting Asimov's name on it is like doing a movie about Lord of the Rings - and having Saruon as a misunderstood rebel, who's really all right underneath.
Why not? Alternative character interpretations are all the rage nowadays, from His Dark Materials to some more disturbing pieces of fanfiction about just how Luthien put Morgoth to sleep (hint: not by dancing)...
Speaking of disturbing romances, just why did Galadriel keep the image of Sauron in her viewing mirror ?-)
That's the writing we have to look forward to? And the guy who wrote that is directing?
Daneel: "I can't harm humans."
Villain: "Gee, that's too bad, isn't it?"
Villain turns and starts walking away.
Daneel: "Ah, screw it."
Daneel runs up to the villain, rips out his arms and beats him to death with them.
Daneel (still perfectly calmly): "This is the Zeroeth Rule, bitch."
Seriously, the other movies were all action spectacles. Foundation is not, it's a political/psychological story that spans centuries, with some psychics thrown in for whatever reason. Turning it into a movie is not going to work; but I suppose they could simply make a war movie about, say, the Four Kingdoms trying to conquer Foundation.
Look at male nipples. There is nothing intelligent or "by design" about it. Unless we are talking about a very incompetent designer.
I have to disagree here. If I was designing humans, I'd put them there too. They don't harm anything, and removing them increases the chances that something goes wrong and a female - who needs them - doesn't get them. Furthermore, they act as a convenient visual cue for erogenous zones.
That sounds good in theory and might even work for awhile, until you get yourself some future president who resembles Mao Tse Tung. Said future president will define anything he doesn't like as "false" and imprison you. For example: "The communists killed hundreds in Tianneman Square." "No we didn't. That's libel. Welcome to prison."
Mussolini, Mao... Do you have any argument that doesn't devolve into scaremongering?
You need to write your laws, not just for the present, but also so they cannot be abused by future tyrants. Libel/slander laws can and have been abused by governments to silence citizens.
A tyrant will simply rewrite/re-interpret the laws to his advantage.
And that's the problem. To some people, it's just the internet. It's not a technology that has revolutionized the entire world. It's just the way to get where they want to be. Like a car.
The Internet is not a car. The Internet is the very concept of a road itself.
Its not like these things are autonomous or have even the remotest capability of independent decision making.
In that case it would be horribly dangerous to use them in urban situations, because if the control signal is interrupted, they come crashing down. At the very least they require autopilot with staying stationary, collision avoidance, and returning to preset coordinates (the base) if control is lost and not restored within a certain time, avoiding collisions along the way.
Materialist monism is like logging into World of Warcraft and believing that the virtual world in front of your simulated eyes is by definition 'real' and that all the servers which run it MUST be built out of VR constructs. At one level that's correct, but believing that that's all there is will lead to confusion. Yes, things exist in our 'physical' (simulation) world, but their existence comes from a higher level.
The problem with this example is that the physics of WoW are incapable of explaining the behaviour of PCs, while physics of the real world seem to be capable of explaining the behaviour of humans. In other words, WoW characters are dualistic, with their "body" being just a puppet on the strings to an entity that resides elsewhere, while all evidence - specifically, the effects of drugs, medicine and brain damage - points to a human beings command center being part of the physical body.
Roger Penrose has the idea that the brain is more like a receiver/transmitter than a generator of consciousness. In the 'WoW cosmology', a similar thing occurs; the avatar is a telepresence device linking the virtual world to the physical above it. I think this is roughly what the human brain/body is like.
That theory is easy to test: just get drunk. If your mental processes reside outside your body, they shouldn't be affected. Your perceptions and motor control might be, but your judgement shouldn't. In any game that tries to simulate drunkenness, that's true; in real life, it's notoriously false.
This test is not entirely airtight, as it's possible to arrange the incoming/outgoing communication in such a way that your consciousness doesn't work properly without stimulation signal from the body, but that would pretty much require purposeful design, and I really don't want to get to a debate about ID here.
Consider a computer that is as just as powerful as the human mind -- orders of magnitude more powerful than any computer today. What do you do with it? You have to teach it. And we _suck_ at teaching. We have 6 billion human-level super computers on the world right now, with another 300,000 arriving daily, and we have no idea what to do with them. What is one more, made of silicon, going to offer us?
The ability to easily copy models from one computer to another, for starters. So you teach the first computer, then begin mass-producing them, and let the old ones upload a copy of their database of knowledge into new ones.
Also, humans aren't supercomputers. Humans are concerned with social matters, getting their next meal, entertainment, sleep etc. A supercomputer doesn't need to be concerned by any of that, it can just work 24 hours a day 7 days a week 365 days a year.
Finally, an intelligent computer might not be much more capable that today's machines in terms of raw capability, but it's much easier to interact with. For example, rather than downloading, installing and learning to use an e-mail program, you can just tell it to retrieve your e-mails. Rather than worrying if its network stack supports IPv6, you can simply give it the IPv6 specification, and it'll make the necessary modifications by itself; in fact, it could simply have noted that there were a lot of talk about said protocol recently, found the spec online, and implemented it by itself already. Not to mention patching its own security holes etc.
Do not underestimate the leap of productivity that occurs with autonomous computers that don't need to be directed by someone all the time.
Slashdot Mirror
The big problem there is not graphics quality - that's already there, take a look at Fallout 3 or Arkham Asylum at maximum graphical settings - it's the quality of tools. You'd need "digital actors" able to move, react and emote without you having to put every eyebrwo into place manually. You'd also need good-quality soft-body collision detection, physics, etc.
Everyone will be able to make movies when AI gets good enough to read the script and let you play the director with a microphone. Until then, that's limited to people with technical expertise and lots of free time on their hands.
"Buyer beware" died with Rome. And good riddance too; after all, why wouldn't the sellers have responsibility for ensuring that their wares are what they're claiming them to be: a useful product? And no, burying "this might be junk" somewhere in a 50-page mumbo-jumbo legalese memo doesn't absolve you.
Why is it that people who talk about "responsibility" so often wish to absolve one party of all?
How about ensuring that what you're selling is of sufficient quality that the buyers don't demand your head on a spike?
Should claiming that it's the buyer's fault you sold junk as working stuff be?
If either of them had the nuts to stand up to their corporate overlords, we wouldn't be in the mess we are now.
There is no Slashdot posts either, just cohesive list of letters, but it doesn't seem to stop people from reading them.
Claiming that there is no forest, just lots of trees near each other, is kinda stupid argument.
The average CRT monitor from 2000 could do far higher resolutions than the average LCD panel can nowadays. That's one thing we've regressed at.
I wonder if it would be possible to forget LCD and just build the monitor from small diodes? They are semiconductors, so there should be no reason they can't be made very small, and a quick look at Wikipedia seems to suggest that they come in red, green and blue.
Or just get the disinfected version from Pirate Bay.
Media industry does a pretty good imitation of The Three Stooges nowadays.
Not for me, thought; I didn't know they were on until someone left a TV on.
Ignorance is bliss, as long as you are selective of things you ignore.
It did reject the message. It simply happened at such a late stage of input processing (during database insertion) that the resulting exception went unhandled and caused the program to exit - which was precisely what I wanted to happen, since it left all the previous messages on-screen for me to see, and made it really clear just where the unexpected error happened.
So the way to avoid bugs is to not make any mistakes? Thanks, I'll keep that very useful advice in mind. You've certainly analyzed the problem well here, to come up with a solution that's so well applicable in the Real World.
For what's basically a data mining program, there is no bad input. There's at most pointless input (in this case, messages that don't contain images), but the program can't know that given input is that before it has already been parsed.
Extract images, check if they are already in the database, insert those that are not, insert message contents (minus the images), and set up a connection between the message and images it contained. Also parse whatever info you can from the message (newsgroup, date, etc) and link them to the message and, by extension, the image. There are no erroneous inputs, just inputs that we can extract less or no information from.
That's nice and good if you can do it, but in general you can't. In my example before, the input is a string who's character encoding may or may not be known. Parts of it are machine-generated, parts are human-generated, everything is mixed together into a cheerful mess, and even the machine-generated parts tend to have errors (but a least in a predictable pattern). And I can't simply reject unclear input, since the channel is one-way, so what I get is the best I'm ever going to get; I either parse it succesfully, or lose the information.
More generally, as the power of the application input system approaches a Turing machine, input verification approaches impossible. You either use heuristics and accept that tehre's false positives or false negatives or both, or use strict verification and accept that verification of some inputs takes literally forever. And if you can't contact the user in unclear cases, you're faced with the task of deciding what level of ambiguity and chance of error is more acceptable than rejecting the input completely and with it any chance of getting it right.
Only for simple programs, or programs that can afford to not tolerate any error. However, anal-retentive error checking is a pain to work with; the end user ends up using most of his time to figuring out ways to get past the safeguards to get the program to do what he wants. If he can't control some part of the input (like my news archiver), he's out of luck. That's not really acceptable.
The best you can do in that kind of case is to make input parsing in layers. Each tries to make sense of the input from the previous layer, and is increasingly strict about it. In my example above, the error was finally caught at the database layer, which caused the insert program to shutdown - but the database itself remained fine and uncorrupted, and the insert program was supposed to quit in those conditions, since there's no way to handle an unknown error in a meaningful way without artificial intelligence.
Which would take the peak power requirements down to 200 megawatts or 200 kilowatts, respectively. That's not exactly realistic either, if you think about it.
But yes, I'm joking.
If it did, then storing one zero bit would require 0-4 Watts and storing 1 requires 9-25 Watts. A full byte of ones would require 72-200 Watts, and a gigabyte around 77-215 gigawatts. Byt contrast, Hoover Dam has peak capacity of about 2 gigawatts.
In other words,I doubt it ;).
Indeed. However, the customer disagrees, gives the job to whoever does it cheapest, and damn security. Then, when the shit they bought blows up on their faces, they'll get angry and write articles demanding the incompetent minimum wage programmers they insisted using due to being cheap be held legally liable for being worth every penny they got paid, and not a single one more.
Hey, you make people compete with Chinese slave labour for lowest pay, don't be amazed they'll also compete for lowest quality.
I once coded a program for my own use that downloaded images from binary newsgroups, decoded them, and inserted them into a PostgreSQL database, with keywords extracted from the message. It was a nice program, handled multipart messages, and only stored each image once, using SHA1 hashes to check for dublicates - I even took the possibility of a hash collision into account and only used them as an index. No buffer overruns, no SQL injections, no nothing. Yet it crashed. So why did it crash?
Some moron included the same image twice in a single message.
It's fine to say "don't trust user input", but it's pretty much impossible to actually make sure that you've accounted for all possible ways it can be faulty, and this becomes harder the more powerful the program is, since using that power requires more complex input.
My 19" CRT is also capable of 1600x1200@85Hz, but only use that resolution for games. My desktop runs at 1154x864, since that's the smallest size text stays readable. Windows's DPI scaling doesn't seem to work well in a single program...
My previous computer, before the current i5-750/Radeon 7550, was a 1GHz AMD Duron with Geforce 2MX. And I still use a CRT monitor, which is fine now that I've finally forced Windows to accept that refresh rate below 85Hz is not acceptable, no matter how badly some games want 60Hz.
The error is inherent in the act of programming: you are turning vague descriptions into exact algorithm. Since the vague description can't specify the correct behaviour in all circumstances - if it did, it would be a complete and runnable program in itself - the programmer must use his imagination to try to find the circumstances where the resulting program might behave in an undesirable manner, and decide what it should do instead. Since it is impossible to guarantee that you've thought of every possible situation, you can't guarantee that the code is bug-free.
Of course there are ways to reduce bugs - checking that your inputs are within expected range, checking that memory allocations succeeded, checking that you aren't trying to stuff more stuff to a buffer than it can hold - but in general, any nontrivial program will have bugs. It's not avoidable, and you should plan your systems with that fact in mind (memory protection, sandboxing, firewalling, making core can't-fail-or-system-crashes components as trivially simple as possible, etc).
Why not? Alternative character interpretations are all the rage nowadays, from His Dark Materials to some more disturbing pieces of fanfiction about just how Luthien put Morgoth to sleep (hint: not by dancing)...
Speaking of disturbing romances, just why did Galadriel keep the image of Sauron in her viewing mirror ?-)
Daneel: "I can't harm humans."
Villain: "Gee, that's too bad, isn't it?"
Villain turns and starts walking away.
Daneel: "Ah, screw it."
Daneel runs up to the villain, rips out his arms and beats him to death with them.
Daneel (still perfectly calmly): "This is the Zeroeth Rule, bitch."
Seriously, the other movies were all action spectacles. Foundation is not, it's a political/psychological story that spans centuries, with some psychics thrown in for whatever reason. Turning it into a movie is not going to work; but I suppose they could simply make a war movie about, say, the Four Kingdoms trying to conquer Foundation.
I have to disagree here. If I was designing humans, I'd put them there too. They don't harm anything, and removing them increases the chances that something goes wrong and a female - who needs them - doesn't get them. Furthermore, they act as a convenient visual cue for erogenous zones.
Let's compromise: tunnels :).
Mussolini, Mao... Do you have any argument that doesn't devolve into scaremongering?
A tyrant will simply rewrite/re-interpret the laws to his advantage.
The Internet is not a car. The Internet is the very concept of a road itself.
In that case it would be horribly dangerous to use them in urban situations, because if the control signal is interrupted, they come crashing down. At the very least they require autopilot with staying stationary, collision avoidance, and returning to preset coordinates (the base) if control is lost and not restored within a certain time, avoiding collisions along the way.
The problem with this example is that the physics of WoW are incapable of explaining the behaviour of PCs, while physics of the real world seem to be capable of explaining the behaviour of humans. In other words, WoW characters are dualistic, with their "body" being just a puppet on the strings to an entity that resides elsewhere, while all evidence - specifically, the effects of drugs, medicine and brain damage - points to a human beings command center being part of the physical body.
That theory is easy to test: just get drunk. If your mental processes reside outside your body, they shouldn't be affected. Your perceptions and motor control might be, but your judgement shouldn't. In any game that tries to simulate drunkenness, that's true; in real life, it's notoriously false.
This test is not entirely airtight, as it's possible to arrange the incoming/outgoing communication in such a way that your consciousness doesn't work properly without stimulation signal from the body, but that would pretty much require purposeful design, and I really don't want to get to a debate about ID here.
The ability to easily copy models from one computer to another, for starters. So you teach the first computer, then begin mass-producing them, and let the old ones upload a copy of their database of knowledge into new ones.
Also, humans aren't supercomputers. Humans are concerned with social matters, getting their next meal, entertainment, sleep etc. A supercomputer doesn't need to be concerned by any of that, it can just work 24 hours a day 7 days a week 365 days a year.
Finally, an intelligent computer might not be much more capable that today's machines in terms of raw capability, but it's much easier to interact with. For example, rather than downloading, installing and learning to use an e-mail program, you can just tell it to retrieve your e-mails. Rather than worrying if its network stack supports IPv6, you can simply give it the IPv6 specification, and it'll make the necessary modifications by itself; in fact, it could simply have noted that there were a lot of talk about said protocol recently, found the spec online, and implemented it by itself already. Not to mention patching its own security holes etc.
Do not underestimate the leap of productivity that occurs with autonomous computers that don't need to be directed by someone all the time.