When I was in Comp. Sci. at Carleton a couple years ago, I used an old EO 440 machine for taking notes, and a seriously hacked up Palm "Pilot 5000" as my calandar.
The Palm was absolutely indispensible for me. I found, before I had it, that I would frequently come to class and people would say "So, are you ready to hand in that assignment tomorrow?" to which I would inevitably reply "What assignment?"
Having a little box in my pocket that would beep at me two or three days before an assignment was due (or, better, an exam was coming up) made it so I never had to worry about this stuff (well... except in the classes I never went to, and therefore never found out about the assignments and exams:).
The EO (or, I suppose a Tablet PC, if you want to come into the 21st century:) is a much better device for taking notes than a Palm. The EO was much closer to a full 8.5x11" sheet of paper, which is what most of us are used to taking notes on. I usually even had doodles in my margins. The Palm just doesn't have the necissary screen real-estate.
I also tried using a laptop for a while. This works well for the most part. The exception is in math courses. It's a little difficult to quickly enter in a complex formula from a keyboard, especially one with many exponents/subscripts/greek letters/integrals. You'll find yourself developing little short-hands like "OMEGA" or "INTEGRATE(...)", but that can only take you so far, and it's still a little cumbersome. Physics classes had simliar problems, although there you find yourself trying to draw out free-body diagrams in ASCII art. Both of these problems are resolved on a tablet where you can just draw the formulas/diagrams.
The problem is that ATI's "optimization" applies ONLY for this particular benchmark. An actual game which used these shaders would not benefit from ATI's "optimization". Since the optimization affects only the performance of the benchmark, and not real-world performance, it is a cheat.
You're loosing sight of what 3DMark03 is trying to acheive here; the objective of a benchmark is to provide two or more systems with the same input, and therefore the same workload, and see which system performs more favorably. There are lots of things you could do to improve the performance of 3DMark03 without affecting image quality (such as Nvidia's failing to clear the back buffer when the stars were not visible in "The Battle of Proxycon"), however if only ONE card does these things, then that one card has to do less work throughout the benchmark than the other cards. The fact that the pretty pictures it produces are the same is irrelevant, as that is not what the benchmark is trying to measure.
Imagine if we were testing processors. We write a benchmarking program which does a brute-force sort of a large array of numbers, and the algorithim runs in O(n^2) time. If Intel writes a little hack into some Windows driver, such that when our program runs, it does a quick-sort instead of our naive sorting algorithim, then their processor would appear to mop the floor with other processors, and they will still correctly sort the array. The problem is that the objective of our test was to give each processor an equal workload; the fact that the array of numbers ends up sorted is irrelevant.
Now, if ATI's optimizations applied to ALL games, it would be a differnt story, since then we could claim that ATI had found a clever way for the card to reduce it's own workload.
If ATI's card and NVidia's card had dramatically different architechtures, and a given pixel shader ran very well on one card and very poorly on the other, it would be arguable that the benchmark was skewed towards one card. Alternatively, though, you could claim that the one card had a superior architecture and ran a wider range of pixel shaders optimally (you would need to test a number of pixel shaders to make the claim one way or the other).
ATI's "optimization" was definately a cheat, and should definately be removed. It was, in my mind, a "lesser" cheat than NVidia's, and not only because of the smaller performance gain, but it is a cheat all the same.
I would think any number of usenet *.forsale groups would provide prior art to counter this patent (epecially claim 12). Ott.forsale has been around a lot longer than Amazon.com, and provides exactly what this patent describes.
I expected this game to do poorly in the reviews. The problem is that the game starts out very easy (along with little tips that flash up at the bottom of the screen that say "Walk up to the ledge and press 'space' to jump up onto it"), and gets progressively more difficult. The game IS boring and easy, for the first while. But once you get past the "purple baboon-like 'Giddy Goons'", the game starts to get interesting.
The game could definately use a "difficulty" setting, or a tutorial that you could skip, instead of essentially making the tutorial part of the game.
I agree with the article's assertion that the camera was annoying at times, but no more so than most third-person view games.
As for the controls; I personally found using a keyboard to control dirk to be slightly annoying. There's little things like; if you press up twice in quick succession, Dirk will dash forwards a couple steps (same with the other directions). This SOUNDS ok, but every now and then when you're trying to get up close to the edge of a ledge, you'll do it by accident and leap of the ledge. Also, in some portions of the game the camera is fixed, and using four arrow keys (or, in my case, ASDW) limits you to 8 directions (whereas anywhere else you can use the mouse to "look", again, like in most games of this style). I don't know what the article is talking about with it's jumping "sweet spot"... I didn't have this problem at all.
I did not have any problems that would not be fixed by playing the game with a handheld controller with an analog stick (like you would use on the numerous console versions of this game).
I've sent two SMS messages to myself. The first one I received over 17 times. My delivery rate is therefore 1800%, which is considerably better than 92.5%.:D
The idea of writing "strikeback" scripts, as you describe, has been tossed around before. I recall reading a quick-and-dirty script for Apache posted on slashdot some time ago that would detect attacks from machines infected with Code Red, and would then exploit the security holes Code Red had opened on those machines to clean them. I used to support this idea, but I'm afraid after some thought, I've changed my mind.
I'd agree that if a worm is running on someone's machine without their knowledge, then the owner of that machine has no rights to that process (the obvious exception being the person who is spreading the worm, who runs it intentionally on his or her own machine, but we'll ignore him or her for now). In order for you to terminate that process, however, you have to break into their machine, and run your own process. You are, in effect, creating your own worm. Your worm may only run for a short while, and may be "for the greater good", but that doesn't change the fact that you are running code on other poeple's machines without their consent.
Even if we opt to ignore the ethics and look at this from a more practical angle, can you guarantee that your strikeback process is not going to adversely affect the machines it cleanses? What if your strikeback process causes a machine gathering scientific data to reboot, or kills the wrong task? This has the potential to set someone back by several days in their work. What if it reboots a machine monitoring medical equipment? You could end up killing more than just a process, if you catch my meaning, however unlikely that may be.
Since you are intentionally running a process on someone else's machine, you are accountable for it's results. If you cause damage to a machine, or cause data to be lost, even if it is inadvertant, you open yourself up to litigation from the owners of those machines.
What would be interesting is to compute "partial game trees". For example, given game x, we can usually make a game x' which is identical except for two moves (say, for example, two pawns in the corners of the board). So the trees for these games could effectively be merged into one. Many moves are also "not productive" and don't need to be factored in. I wonder how small you could get this tree in reality? Providing lower bounds would make an interesting PHD topic.:)
a company elsewhere in the world, simply because it makes money off of U.S. Citizens, then don't I have juristiction over the RIAA, since they sell things to people in my house?
I think the US will see just about the same as far as results are concerned as I will in my 10 billion dollar lawsuit against the RIAA for violating rules in my house.
So the CD sends information to the drive using an on-board LED.... What powers this LED? Am I going to have to recharge my copy of Quake before I can use it?
Perhaps little magnets on springs! Then they could just stop and restart the disc spinning several times to move the magnets around, and use induction to run the LED.
Anyways, ultimately all you have to do to defeat this is to write some software that asks the smart card for it's key, then write some more software to make a decrypted copy of the disk
If I can relicense my music so easily, what's to stop someone else from doing it? What's the point in "protecting" a file with a license, when anyone can relicense the file whenever they wish?
Does this make sense to anyone? Am I missing something here?
Requirements review and Design review find more defects per person hour than code review, especially when you consider that a single requirement defect will result in multiple design defects, and a single design defect in multiple implementation defects.
There are two subjects I want to discuss here. First of all, I'm going to present the "jelly bean model" of defect discovery, then I'm going to talk about why the "testing to improve quality" model is fundamentally flawed.
The Jelly Bean model goes like this: Let's suppose you have a big vat of red and blue jelly beans. Your objective is to remove all the blue beans. You do this by reaching in, grabing a hand full of beans, throwing away all the blue ones, and dumping the red ones back in.
At the begining, it will be very easy to find the blue beans (assuming the blue-bean density is high), and towards the end, it will be very difficult (since the blue-bean density will be low). If you graph the cumulative number of blue beans you remove each day, you'll get a exponential curve; quite steep at the begining (high rate of discovery) and which flattens out as you approach total bean removal.
Software defect discovery follows this model exactly. Defects are easy to find at the begining if there are a lot of them, and hard to find towards the end. This means that if your defect discovery rate is pretty much constant (with respect to the number of hours of testing you've done) then you're probably still way down in the very first part of the curve, and your number of defects is probably very high.
Here's the important thing to remember though; the quality of your product has nothing to do with how many defects you find and fix during testing. The quality of your product is determined by the number of defects remaining! If you find and fix 10,000 problems, you might think you're doing very well, but if there are 10,000,000 defects remaining, your product is still crap.
You can estimate the number of defects remaining by trying to fit the number of defects you've found so far onto that exponential graph I mentioned above. The most popular method to use a Weibull curve, or Quadradic Regression.
Now, why is testing to improve quality a bad plan?
Let's say you worked at Ford, and roughly 50% of the cars you turned out had something wrong with them. You get lots of unhappy customers demanding their money back. Is your problem:
a) That you have a design defect in your car. b) That you are introducing defects in production. c) That you are testing cars insufficiently.
Most people realize that to test every car as it comes off the line is futile. There's too many of them, with too many potential points of failure. There's no way you can test them all. The root cause of the problem has to be in either a or b, and if you're looking to improve the qulaity of your cars, this is where you would spend your money. This isn't to say that Ford doesn't test their cars, I'm sure they do, but testing should be a means of verifying quality (IE, 1/1000 cars tested had a defect, our goal was 1/500, so therefore we can stop spending money on finding design and production faults), and not a means of improving it.
It's so easy to see this when we're talking about cars. Why does everyone get it backwards when we start talking about software?
Not only is it impossible to test every possible combination of inputs to most software, it's also very expensive to find and fix problems this way. If you find a problem in design review, or code inspection, then you have your finger on it. You know EXACTLY where the defect is, and how to fix it. On the other hand, when you say "Microsoft Word crashes when I try to select a paragraph and make it Bold", you have no idea where the fault is. Any one of several thousand lines of code could be the problem. It can take literally days to track down and fix the defect.
Your testing should not be a means of finding faults, but a means of verifying the quality of your product. Testing is not part of the development process.
CBC Television has started airing a show called Zed which they call "Open Source Television". It's not nearly as open source as what Cringly proposes, and they're still ironing out the kinks, but basically it's a show where viewers create content, and vote about what gets put on the air. Check it out:
Only he's had it for years and it only cost him $20.
His has a wooden handle and crank, and the "barel" is an asterisk shaped plastic thing (literally asterisk shapped from the front).
You tie a piece of string a spool on the handle, and then wrap the string once around the base of the barel. Then you put a rubber band on each fin (each leg of the asterisk). Repeat 'till you're out of rubber bands. Turn the handle, it pulls on the string, which lifts up the back edge of a rubber band, and the band flies accross the room. It literally makes a cloud of flying rubber bands.
This one seems much more complex (lots of crazy gears and stuff, if you look at the photos). But all in all I'd settle for the $20, given the price difference.
When I started in CS, I thought the same thing. I'd writen my first Basic program on a Sinclair 1000 when I was around 5 or 6. I think, for the most part, I didn't really pick up any substantial amount of new information in my first three years, with perhaps the exception of Calculus (wasn't offered at my highschool... Long story)... I had, however, spent much of my highschool career "home sick" reading university level texts.
My fourth year, however, (and all the fourth year courses I took as electives in first through third years:) were, for the most part, fun, informative, and packed with things I didn't know. I can now prove not all true statements are proovable, or that there are certain non-finite strings of 1s and 0s that you can't generate, that there are well defined problems you can't compute the answer to, irrespective of how much computing power you have. I know vastly more about distributed an parallel computing and how to construct efficient algorithims for either. I know how to prove that a specific problem takes a minimum amount of time to compute the answer to, and therefore, there is a point at which you cannot create a faster algorithim to solve it. I know stupidly more about algorithim analysis than I ever did before. Try and pick a university or college with a strong course on software design, too, because even a lot of the computer engineering guys at work have a hard time with software design.
If you don't know what "big O" notation is, or what an ALU is (Arithmetic Logic Unit - but what is it and how does it work?), or what the stack is, how dynamic memory is allocated, or the difference between microcode and machine code, then you've still got lots of second/third year level stuff to learn too.
There's a lot out there that you won't learn from "amateur" programming (or at least, there was a lot I didn't learn). For those courses that you don't think you need to take, Canadian universities will let you "challenge" the course, which means you just sit the final exam, you don't actually need to go to classes. It's a little... dangerous... since your entire mark is based on a single exam, as opposed to two exams and usually some assignments. You have a bad day, you fail the course, which is no good. Still, for first year stuff, it's probably your best route.
When a hacker goes to jail for five years, everyone moans over the fact that the hacker is given hard time equivalent to a murderer, even though the crime is obviously far lesser. Then, when something like this happens, everyone calls it a slap on the wrist... ??
I have to wonder. If this had happened in the political climate of the 1860s, would you have cried out:
"All you 'patriots' who were arguing that we should let colored people have equal rights had better get used to terrorism. Because of your whining about 'rights', the terrorists were allowed to board a plane, and look what they've done now. The blood of the innocent is on YOUR hands!"
You see how preposterous it sounds? You're spouting the same crap, my friend. Encryption didn't hijack those planes, and Carnivore installed in every ISP in the country wouldn't stop people from making plans like this just by speaking face to face.
"The cry has been that when war is declared, all opposition should therefore be hushed. A sentiment more unworthy of a free country could hardly be propagated. If the doctrine be admitted, rulers have only to declare war and they are screened at once from scrutiny.... In war, then, as in peace, assert the freedom of speech and of the press. Cling to this as the bulwark of all our rights and privileges."
-- William Ellery Channing
Better yet, why not go after the individual users? It's not Napster's fault that users are using their service for evil, instead of for good.
And even better yet (and what I expect to actually happen), go after MP3.com, AND Napster, AND the individual users. Afterall "We have a need to be ir^H^Hresponsible".
Doesn't that make Pi illegal to distribute? I bet it can break e-book encryption too!
I can see the headlines now;
RIAA and DVD-CCA Join Forces, Battle Circles
Judge Patel Rules Depections of Circles Illegal
Government Passes Controversial "Digital Millenium Circle Act" Banning Distribution of Circles as Circumvention Devices
"It's now illegal, for example, to walk around a fence post designed to keep you out, even if there's no fence, since you'd have to walk a partial circle around the fence post, and the post, in the government's eyes, constitutes an effective measure to prevent access."
But if I write software to do it, I'm bypassing a technological measure, and then I go to jail for 5 years and pay a $500,000 fine next time I visit the United States.
See, you can claim you've just writen software to fix up scratched CDs - interpolate around the scratches, but the RIAA knows better; you're a pirate! All you naughty naughty consumers! Pirates every one of you!
When I was in Comp. Sci. at Carleton a couple years ago, I used an old EO 440 machine for taking notes, and a seriously hacked up Palm "Pilot 5000" as my calandar.
The Palm was absolutely indispensible for me. I found, before I had it, that I would frequently come to class and people would say "So, are you ready to hand in that assignment tomorrow?" to which I would inevitably reply "What assignment?"
Having a little box in my pocket that would beep at me two or three days before an assignment was due (or, better, an exam was coming up) made it so I never had to worry about this stuff (well... except in the classes I never went to, and therefore never found out about the assignments and exams :).
The EO (or, I suppose a Tablet PC, if you want to come into the 21st century :) is a much better device for taking notes than a Palm. The EO was much closer to a full 8.5x11" sheet of paper, which is what most of us are used to taking notes on. I usually even had doodles in my margins. The Palm just doesn't have the necissary screen real-estate.
I also tried using a laptop for a while. This works well for the most part. The exception is in math courses. It's a little difficult to quickly enter in a complex formula from a keyboard, especially one with many exponents/subscripts/greek letters/integrals. You'll find yourself developing little short-hands like "OMEGA" or "INTEGRATE(...)", but that can only take you so far, and it's still a little cumbersome. Physics classes had simliar problems, although there you find yourself trying to draw out free-body diagrams in ASCII art. Both of these problems are resolved on a tablet where you can just draw the formulas/diagrams.
The problem is that ATI's "optimization" applies ONLY for this particular benchmark. An actual game which used these shaders would not benefit from ATI's "optimization". Since the optimization affects only the performance of the benchmark, and not real-world performance, it is a cheat.
You're loosing sight of what 3DMark03 is trying to acheive here; the objective of a benchmark is to provide two or more systems with the same input, and therefore the same workload, and see which system performs more favorably. There are lots of things you could do to improve the performance of 3DMark03 without affecting image quality (such as Nvidia's failing to clear the back buffer when the stars were not visible in "The Battle of Proxycon"), however if only ONE card does these things, then that one card has to do less work throughout the benchmark than the other cards. The fact that the pretty pictures it produces are the same is irrelevant, as that is not what the benchmark is trying to measure.
Imagine if we were testing processors. We write a benchmarking program which does a brute-force sort of a large array of numbers, and the algorithim runs in O(n^2) time. If Intel writes a little hack into some Windows driver, such that when our program runs, it does a quick-sort instead of our naive sorting algorithim, then their processor would appear to mop the floor with other processors, and they will still correctly sort the array. The problem is that the objective of our test was to give each processor an equal workload; the fact that the array of numbers ends up sorted is irrelevant.
Now, if ATI's optimizations applied to ALL games, it would be a differnt story, since then we could claim that ATI had found a clever way for the card to reduce it's own workload.
If ATI's card and NVidia's card had dramatically different architechtures, and a given pixel shader ran very well on one card and very poorly on the other, it would be arguable that the benchmark was skewed towards one card. Alternatively, though, you could claim that the one card had a superior architecture and ran a wider range of pixel shaders optimally (you would need to test a number of pixel shaders to make the claim one way or the other).
ATI's "optimization" was definately a cheat, and should definately be removed. It was, in my mind, a "lesser" cheat than NVidia's, and not only because of the smaller performance gain, but it is a cheat all the same.
I would think any number of usenet *.forsale groups would provide prior art to counter this patent (epecially claim 12). Ott.forsale has been around a lot longer than Amazon.com, and provides exactly what this patent describes.
I expected this game to do poorly in the reviews. The problem is that the game starts out very easy (along with little tips that flash up at the bottom of the screen that say "Walk up to the ledge and press 'space' to jump up onto it"), and gets progressively more difficult. The game IS boring and easy, for the first while. But once you get past the "purple baboon-like 'Giddy Goons'", the game starts to get interesting.
The game could definately use a "difficulty" setting, or a tutorial that you could skip, instead of essentially making the tutorial part of the game.
I agree with the article's assertion that the camera was annoying at times, but no more so than most third-person view games.
As for the controls; I personally found using a keyboard to control dirk to be slightly annoying. There's little things like; if you press up twice in quick succession, Dirk will dash forwards a couple steps (same with the other directions). This SOUNDS ok, but every now and then when you're trying to get up close to the edge of a ledge, you'll do it by accident and leap of the ledge. Also, in some portions of the game the camera is fixed, and using four arrow keys (or, in my case, ASDW) limits you to 8 directions (whereas anywhere else you can use the mouse to "look", again, like in most games of this style). I don't know what the article is talking about with it's jumping "sweet spot"... I didn't have this problem at all.
I did not have any problems that would not be fixed by playing the game with a handheld controller with an analog stick (like you would use on the numerous console versions of this game).
I've sent two SMS messages to myself. The first one I received over 17 times. My delivery rate is therefore 1800%, which is considerably better than 92.5%. :D
The idea of writing "strikeback" scripts, as you describe, has been tossed around before. I recall reading a quick-and-dirty script for Apache posted on slashdot some time ago that would detect attacks from machines infected with Code Red, and would then exploit the security holes Code Red had opened on those machines to clean them. I used to support this idea, but I'm afraid after some thought, I've changed my mind.
I'd agree that if a worm is running on someone's machine without their knowledge, then the owner of that machine has no rights to that process (the obvious exception being the person who is spreading the worm, who runs it intentionally on his or her own machine, but we'll ignore him or her for now). In order for you to terminate that process, however, you have to break into their machine, and run your own process. You are, in effect, creating your own worm. Your worm may only run for a short while, and may be "for the greater good", but that doesn't change the fact that you are running code on other poeple's machines without their consent.
Even if we opt to ignore the ethics and look at this from a more practical angle, can you guarantee that your strikeback process is not going to adversely affect the machines it cleanses? What if your strikeback process causes a machine gathering scientific data to reboot, or kills the wrong task? This has the potential to set someone back by several days in their work. What if it reboots a machine monitoring medical equipment? You could end up killing more than just a process, if you catch my meaning, however unlikely that may be.
Since you are intentionally running a process on someone else's machine, you are accountable for it's results. If you cause damage to a machine, or cause data to be lost, even if it is inadvertant, you open yourself up to litigation from the owners of those machines.
I'll be able to wardrive without leaving my own home! :)
What would be interesting is to compute "partial game trees". For example, given game x, we can usually make a game x' which is identical except for two moves (say, for example, two pawns in the corners of the board). So the trees for these games could effectively be merged into one. Many moves are also "not productive" and don't need to be factored in. I wonder how small you could get this tree in reality? Providing lower bounds would make an interesting PHD topic. :)
a company elsewhere in the world, simply because it makes money off of U.S. Citizens, then don't I have juristiction over the RIAA, since they sell things to people in my house?
I think the US will see just about the same as far as results are concerned as I will in my 10 billion dollar lawsuit against the RIAA for violating rules in my house.
I believe Dean Ing has prior art in his (somewhat lame) book, The Ransom of Black Stealth One.
He wrote about using photodetectors on an aircraft and a light emitting "skin" to render a plane invisible.
So the CD sends information to the drive using an on-board LED.... What powers this LED? Am I going to have to recharge my copy of Quake before I can use it?
Perhaps little magnets on springs! Then they could just stop and restart the disc spinning several times to move the magnets around, and use induction to run the LED.
Anyways, ultimately all you have to do to defeat this is to write some software that asks the smart card for it's key, then write some more software to make a decrypted copy of the disk
If I can relicense my music so easily, what's to stop someone else from doing it? What's the point in "protecting" a file with a license, when anyone can relicense the file whenever they wish?
Does this make sense to anyone? Am I missing something here?
Well, no actually.
Requirements review and Design review find more defects per person hour than code review, especially when you consider that a single requirement defect will result in multiple design defects, and a single design defect in multiple implementation defects.
But yes, code review is a good plan all the same.
There are two subjects I want to discuss here. First of all, I'm going to present the "jelly bean model" of defect discovery, then I'm going to talk about why the "testing to improve quality" model is fundamentally flawed.
The Jelly Bean model goes like this: Let's suppose you have a big vat of red and blue jelly beans. Your objective is to remove all the blue beans. You do this by reaching in, grabing a hand full of beans, throwing away all the blue ones, and dumping the red ones back in.
At the begining, it will be very easy to find the blue beans (assuming the blue-bean density is high), and towards the end, it will be very difficult (since the blue-bean density will be low). If you graph the cumulative number of blue beans you remove each day, you'll get a exponential curve; quite steep at the begining (high rate of discovery) and which flattens out as you approach total bean removal.
Software defect discovery follows this model exactly. Defects are easy to find at the begining if there are a lot of them, and hard to find towards the end. This means that if your defect discovery rate is pretty much constant (with respect to the number of hours of testing you've done) then you're probably still way down in the very first part of the curve, and your number of defects is probably very high.
Here's the important thing to remember though; the quality of your product has nothing to do with how many defects you find and fix during testing. The quality of your product is determined by the number of defects remaining! If you find and fix 10,000 problems, you might think you're doing very well, but if there are 10,000,000 defects remaining, your product is still crap.
You can estimate the number of defects remaining by trying to fit the number of defects you've found so far onto that exponential graph I mentioned above. The most popular method to use a Weibull curve, or Quadradic Regression.
Now, why is testing to improve quality a bad plan?
Let's say you worked at Ford, and roughly 50% of the cars you turned out had something wrong with them. You get lots of unhappy customers demanding their money back. Is your problem:
a) That you have a design defect in your car.
b) That you are introducing defects in production.
c) That you are testing cars insufficiently.
Most people realize that to test every car as it comes off the line is futile. There's too many of them, with too many potential points of failure. There's no way you can test them all. The root cause of the problem has to be in either a or b, and if you're looking to improve the qulaity of your cars, this is where you would spend your money. This isn't to say that Ford doesn't test their cars, I'm sure they do, but testing should be a means of verifying quality (IE, 1/1000 cars tested had a defect, our goal was 1/500, so therefore we can stop spending money on finding design and production faults), and not a means of improving it.
It's so easy to see this when we're talking about cars. Why does everyone get it backwards when we start talking about software?
Not only is it impossible to test every possible combination of inputs to most software, it's also very expensive to find and fix problems this way. If you find a problem in design review, or code inspection, then you have your finger on it. You know EXACTLY where the defect is, and how to fix it. On the other hand, when you say "Microsoft Word crashes when I try to select a paragraph and make it Bold", you have no idea where the fault is. Any one of several thousand lines of code could be the problem. It can take literally days to track down and fix the defect.
Your testing should not be a means of finding faults, but a means of verifying the quality of your product. Testing is not part of the development process.
I wrote an article about this:
http://thedreaming.org/~quartz/201/
CBC Television has started airing a show called Zed which they call "Open Source Television". It's not nearly as open source as what Cringly proposes, and they're still ironing out the kinks, but basically it's a show where viewers create content, and vote about what gets put on the air. Check it out:
http://zed.cbc.ca/
Only he's had it for years and it only cost him $20.
His has a wooden handle and crank, and the "barel" is an asterisk shaped plastic thing (literally asterisk shapped from the front).
You tie a piece of string a spool on the handle, and then wrap the string once around the base of the barel. Then you put a rubber band on each fin (each leg of the asterisk). Repeat 'till you're out of rubber bands. Turn the handle, it pulls on the string, which lifts up the back edge of a rubber band, and the band flies accross the room. It literally makes a cloud of flying rubber bands.
This one seems much more complex (lots of crazy gears and stuff, if you look at the photos). But all in all I'd settle for the $20, given the price difference.
On a related note, Ars Technica recently pushed out a Flat Panel buyer's guide.
When I started in CS, I thought the same thing. I'd writen my first Basic program on a Sinclair 1000 when I was around 5 or 6. I think, for the most part, I didn't really pick up any substantial amount of new information in my first three years, with perhaps the exception of Calculus (wasn't offered at my highschool... Long story)... I had, however, spent much of my highschool career "home sick" reading university level texts.
:) were, for the most part, fun, informative, and packed with things I didn't know. I can now prove not all true statements are proovable, or that there are certain non-finite strings of 1s and 0s that you can't generate, that there are well defined problems you can't compute the answer to, irrespective of how much computing power you have. I know vastly more about distributed an parallel computing and how to construct efficient algorithims for either. I know how to prove that a specific problem takes a minimum amount of time to compute the answer to, and therefore, there is a point at which you cannot create a faster algorithim to solve it. I know stupidly more about algorithim analysis than I ever did before. Try and pick a university or college with a strong course on software design, too, because even a lot of the computer engineering guys at work have a hard time with software design.
My fourth year, however, (and all the fourth year courses I took as electives in first through third years
If you don't know what "big O" notation is, or what an ALU is (Arithmetic Logic Unit - but what is it and how does it work?), or what the stack is, how dynamic memory is allocated, or the difference between microcode and machine code, then you've still got lots of second/third year level stuff to learn too.
There's a lot out there that you won't learn from "amateur" programming (or at least, there was a lot I didn't learn). For those courses that you don't think you need to take, Canadian universities will let you "challenge" the course, which means you just sit the final exam, you don't actually need to go to classes. It's a little... dangerous... since your entire mark is based on a single exam, as opposed to two exams and usually some assignments. You have a bad day, you fail the course, which is no good. Still, for first year stuff, it's probably your best route.
When a hacker goes to jail for five years, everyone moans over the fact that the hacker is given hard time equivalent to a murderer, even though the crime is obviously far lesser. Then, when something like this happens, everyone calls it a slap on the wrist... ??
I have to wonder. If this had happened in the political climate of the 1860s, would you have cried out:
... In war, then, as in peace, assert the freedom of speech and of the press. Cling to this as the bulwark of all our rights and privileges."
"All you 'patriots' who were arguing that we should let colored people have equal rights had better get used to terrorism. Because of your whining about 'rights', the terrorists were allowed to board a plane, and look what they've done now. The blood of the innocent is on YOUR hands!"
You see how preposterous it sounds? You're spouting the same crap, my friend. Encryption didn't hijack those planes, and Carnivore installed in every ISP in the country wouldn't stop people from making plans like this just by speaking face to face.
"The cry has been that when war is declared, all opposition should therefore be hushed. A sentiment more unworthy of a free country could hardly be propagated. If the doctrine be admitted, rulers have only to declare war and they are screened at once from scrutiny.
-- William Ellery Channing
Better yet, why not go after the individual users? It's not Napster's fault that users are using their service for evil, instead of for good.
And even better yet (and what I expect to actually happen), go after MP3.com, AND Napster, AND the individual users. Afterall "We have a need to be ir^H^Hresponsible".
Doesn't that make Pi illegal to distribute? I bet it can break e-book encryption too!
I can see the headlines now;
RIAA and DVD-CCA Join Forces, Battle Circles
Judge Patel Rules Depections of Circles Illegal
Government Passes Controversial "Digital Millenium Circle Act" Banning Distribution of Circles as Circumvention Devices
"It's now illegal, for example, to walk around a fence post designed to keep you out, even if there's no fence, since you'd have to walk a partial circle around the fence post, and the post, in the government's eyes, constitutes an effective measure to prevent access."
But if I write software to do it, I'm bypassing a technological measure, and then I go to jail for 5 years and pay a $500,000 fine next time I visit the United States.
See, you can claim you've just writen software to fix up scratched CDs - interpolate around the scratches, but the RIAA knows better; you're a pirate! All you naughty naughty consumers! Pirates every one of you!
I don't know how much use I'd have for those games, but I'd be up for the grill! :)