No, you can return 1 list in Perl. It's hardly the same thing; it's a data structure that must be unpacked to be used. For one thing, if the second member of the list is the error code, then just treating it as returning a scalar will ignore the error code without even admitting its existance.
When the value exceded the max size of int, the value went negative
Yes, but...
and the computer thought the rocket had flipped and auto-destruct was triggered.
...no, this is simply wrong. Where did you get this idea? A simple search on google will let you confirm the inaccuracy of this claim with a dozen independent sources. The code in question served no purpose in the air, it was used to align the rocket on the ground. The flight software worked perfectly.
When it went negative, it failed an assertion and threw a math exception. The system read this as "this chip is fried" and shut it down. Then, because the 2 redundant backups were running the exact same programs with the exact same data, it did this twice more. With the computers down, the rocket went wild, and then blew up.
Like most disasters on this scale, many mistakes had to be made simultaneously. If they had stopped running this irrelevant code on launch, it would have been fine, if they had used a larger integer, it would have been fine, if they had used Ada's integer protection, it would have been fine, if they had caught the exception, it would have been fine.
But the things that gets me are 1) that the system was set up not to pass control from a seemingly defective chip to a seemingly good chip, but to yield control from any seemingly defective chip, whether there was another good chip or not and 2) any uncaught exception (not just a specific "We're really sure there's a hardware problem." exception) was taken as proof that the chip was defective. These were both well-known, meaning that there was a concious, considered decision that it was better to halt the system, and completely shut down the guidance system (the only possible result of an uncaught exception due to a software bug) than to face the unknown consequences of running despite an exception they didn't think to catch.
The blame lies with all of those flaws, not just one or two of them. It indeed also lies with the testing that didn't catch it and the decision to reuse legacy code of an older, slower rocket. But note that most of the direct causes were consequences of the exception-handling style of error-handling, and the single most direct cause was a mechanism inspired by the specific belief that halting the system was better than allowing it to run with any one unknown flaw.
I'm not familiar with the rocket you describe, but yes, it is a superior error-handling philosophy. Imagine if there was an unchecked error, and the rocket, instead of detonating, landed in civilian housing?
Why would you assume the rocket was intentionally detonated by the computer? Its computers went down and it went completely out of control. It was only blown up after it broke apart because it happened to go into a spin. There is no upside to this computer failure.
You call blowing up a commercial satellite launch vehicle non-destructive? If this error was ignored the rocket would not have been affected by it, it was an utterly irrelevant mathematical value overflow error in a program that only did anything before launch.
This program became destructive because of the "error management." In particular, the error management philosophy that halting a suspicious system is always safer than allowing it to run.
The point you seem to have missed is that halting the program is often more destructive than ignoring the error. Data loss, control loss, vital services suspended, etc.
That's like saying there's no reason to assume knowing about a bug is better than just allowing a program to go on its merry way. Uncaught bugs are the cause of 99% of the security holes out there. It's always better to know when there is a problem.
I'm sure the European Space Agency found it worth every penny of the estimated half-billion dollars lost to find this otherwise irrelevant bug. After all, it's always better to know, whatever the cost of halting the system, right?
One thing that really bugs me about most programming languages is that they only allow 1 return value by their most natural idiom. So you get these stupid hacks where some settings of the returned value mean errors and some are useful results, of you have to define a new named data structure just for the return value of this one function, or you end up having to mix output variables with the inputs for a function.
This is one thing I like about Forth-style languages, where it's just as natural for a function to return multiple results as to receive multiple arguments, letting you do either:
A B / on_error{ log_error cleanup exit }else{ use_result } return or
A B / on_error{ store_exception drop_result push_unhandled_exception_errcode }else{ use_result } return or
A B / drop_error use_result return
Unlike with exceptions, the possibility of an error isn't hidden away somewhere; if you ignore it, or hand it down to reach exception handling code, you have to do so right there and then, explicitly at every step. Actually, that's a general plus: with a stack language, you have to explicitly dispose of everything, which makes it harder to ignore return values, and impossible to write programs without knowing whether a function returns anything ("What do you mean it can return an error code? I though it was void!").
Exceptions make sure that if an error occurs, and you aren't aware of it, your program dies, and doesn't go on its merry way, causing a security hole/unstable software.
You mean like that Ariane rocket that blew up when its double-redundant computer system was halted because of an utterly irrelevant uncaught exception? Yeah, that's definitely a superior error-handling philosophy.
Aside from the conceptual problems of what are essentially COMEFROM statements with scope management, there's no reason to assume that halting the program is better than just allowing it to run.
This is about detected bugs which haven't been fixed yet.
Basically, his complaints boil down to, "bugs exist, causing error messages, why aren't all the ones that cause error messages fixed yet?"
Then he goes off on a confused tangent, apparently suggesting that "error handling" be added to work around any bugs. After all, if it can log the errors caused by bugs, it can respond to them in any way, up to and including fixing the problem (i.e. doing what the code should have done, except for the bug)! For example, if a system file is missing (meaning either a bug in the install, a bug in the program requesting something that isn't really a required system file, or an externally damaged system that can't be expected to work at all), just pop up a dialog to let the user search for it! Because of course the user should attempt to patch things up with his intimate knowledge of system internals instead of just seeing that there's a bug to report.
Hooooo boy....
I didn't see a single example of a genuine external error that wasn't handled properly, just bugs which should be fixed.
Don't you think that we've hauled along the old 8086/XT baggage long enough?
Hauling baggage builds character, consarnit! I was born with a new x86 chip on the market, and I'll die with a new x86 chip on the market.
Some day, I aim to teach my great-grandchild to xor the accumulator by itself to save a byte off the executable, so don't you go a-messin' with that dream!
And ATI isn't giving them that fine control with this hack either.
That doesn't mean that they aren't exercising that fine control. My whole point was that it would be counterproductive to offer that complex, fine control to the end-user.
It does the same thing that the simple Q3 options let anyone do
There is no evidence to support this claim. There are many aspects of image quality ("more things in heaven and earth than are dreamt of in your philosophy"), and nobody has presented evidence that the exact performance of the Quake exe can be duplicated in the Quack exe merely by changing settings available to the user.
I don't accept that the Quake images are simply of worse quality, either. I've looked at the images, and while there are distinct differences, it's hard to say which is better. In the zipped tgas provided, there is more detail in the textures of of the Quack sample (especially noticable on the teeth), but some of the complex relief shading (particularly on the armor) seems indistinct by comparison. Also, the jaggies seem worse in the Quack version. It's even harder to say which looks better when you're playing just by looking at stills.
Besides, maybe Quake 3 has a few scenes that cause it to really bog down with the default settings: you go around, happily accepting your 15% FPS hit for the slightly better image quality, then you go around a corner and suddenly it's an 80% FPS hit in a crucial scene, and practically unplayable. It's better not to allow users to set it that way if it's not sustainable, because people get really annoyed at that kind of inconsistant performance.
The fact of the matter is that we don't know why they did it, and until you try it for yourself, you don't even know what the real effect is. Of course it's possible that this was an underhanded trick, but we don't know that yet. I'm sure we'll hear more as the testers dig into it and ATI responds, so keep an open mind instead of jumping to conclusions.
There's a very simple way for "the people" to take control of open source development: donate money to projects they like. Those who do so demonstrate that catering to their tastes will be rewarded, and then it's in commercial developers' best interests to make OSS with established donors in mind.
It's the simplest, most direct exchange of the relevant scarce resources: money for control over what is produced.
The point is that users can already lower the settings to get better framerates.
But can they do it in the same way?
Just how complicated should user configuration be? If it's a matter of juggling a dozen different variables to come up with an optimal view, then it's better not to give that control to the user, though it would be impolitic for them to say so. Regardless of how complex the problem is, most gamers (especially the more vocal ones) would believe they could come up with a better configuration, so they'd fiddle with the settings, then blame any problems this causes on the video card and be bitchy over the time they "had to waste to get it to work half-decently."
The problem doesn't likely reduce to a single slider-control that runs from high-quality/low speed to low-quality/high speed.
Different video cards give different quality video, so benchmarks have to take that into account. Some are butt-ugly or just plain wrong, and competent hardware reviewers mention that.
They always have to make trade-offs between frame rate and image quality, what makes tweaking this trade-off for certain games necessarily some kind of trickery?
Id's games have always tended to be a bit freakish, based on unusual, privately researched approaches. Maybe the standard approach isn't perceived as being as playable for Quake 3.
Ideally, they could tweak the system for every individual game, but maybe it's just a case of focusing such efforts on a particularly popular title. Others have pointed out that there are more popular high-performance games, but it would make sense that the default would be optimized for the most popular games, and exceptions coded only for those nearly as popular but different enough for the default settings to be sub-optimal.
I'm sure lots of people have their own tiny project to show off.
I'll start the ball rolling with my Buskpledge Windows program, for collecting and managing donation pledges. It lets you make 2-click pledges from web-pages, view and edit the pledges individually or en masse, and can redirect you to direct donation pages such as Amazon Honor System or PayPal. Full install and uninstall in under 35k.
Source is available at the project page. It's a little wierd, using a custom semi-literate programming tool, and a half-assed gzip clone for internal compression.
Selling gaming platforms at a loss, and making it up on game royalties is fairly standard practice. People don't like to part with that big a chunk of money, and they generally don't seem inclined to compare game prices very carefully in advance.
I mean, you see 2 consoles for sale, one for $500, one for $300. You see that the first has games in the price range $40-$80, and the second $55-$95. Which do you buy? That $200 right now weighs in a lot more with most people than the $15/game, even if you end up getting 30 games.
It always seemed irresponsible to me to go around insisting that software be handed out in source form, freely reusable and redistributable by anyone, without regard for whether there was some expectation that the software would get paid for. Of course, I'm talking about fanatical promoters like RMS, not people who just put their own effort in for their own reasons without saying that others are immoral for doing otherwise.
But then, I have a bad habit of thinking that things change overnight. I suppose it's a reasonable assumption that some form of compensation would be worked out before all programmers ended up sleeping in dumpsters, and it was probably a better idea to get things rolling on principle right away than to demand that all the specifics get worked out in advance.
Anyhow, there's a bit of critique in the essay linked below (along with my 2 bits on how to get it all paid for).
I would also suggest organizing mock terrorist and organized crime cells. Have fun with the cops by sending logistics data back and forth between friends about assasinations, pipe bombs etc. Don't encrypt these, but make them sound serious. If they want to read our emails, then we should fuck with them.
There's a word for such irresponsible pranks: "mischief." It's a crime. There are better ways to fight an invasion of privacy.
Guru (gu'ru): from ancient Hindi guy (guy) and uru (beard) literally "guy with a freaky big beard." Modern meaning: guy with a freaky big beard (generally bad personal hygiene habits add. imp.).
Monty Python, the Argument Sketch. We're going round and round without accomplishing much.
Heh, good point.
I was taking a rather limited view of fair use, but IMHO the most imporant fair-use right is the right to report the evidence of your own senses, and DRM can never touch that. The rest of it seems like fairly minor conveniences. YMMV
...and of course there won't be any cheap digital equipment when no analog equipment is available. I mean, even if you ignore the webcams and sound cards available today.
I point you to iObjects whose DadioOS is used in HipZip, and plays.ogg,.wma,.mp3, and.aac files, and incorporates DRM into the OS of the player
...and so surely you will point me to the evidence that this is installed in machines which are used for recording with a microphone, and that it can recognize copyrighted material coming in through the microphone jack and refuse to record it.
For one thing, because almost nobody has seen it yet, and I haven't seen any indication that anybody has found it useful. It's new, and I've been putting off promoting it while I work on better tools.
If you look around www.boswa.com, my main software page that's been up for a while, you won't see much. Just a few goofy toys and an early draft of an essay. That's what collected about $5 for, all through e-gold, a relatively obscure micropayment system, and I didn't even have a PayPal link for most of the time.
Look around more. Penny Arcade for instance, which has been surviving on donations for months, and using services that shave off an absurd portion of each one.
At any rate, my own failure would hardly indicate that the whole model is invalid.
And I do believe that the majority of people are MORE THAN WILLING to download MP3s of songs they have never purchased.
And what, precisely is wrong with that?
It doesn't demonstrate in any way that they wouldn't happily donate $0.05 or $1.00 or $0.001 or whatever for every one they download if it was convenient.
I don't support the right of content producers to extract arbitrary prices from users. I don't see anything at all wrong, in an ethical or moral sense, with unauthorized copying.
I don't consider the pathetic fallacy (describing a phenomenon as if the objects involved were humans acting it out) to be a fallacy at all, but a useful metaphorical device.
"Water seeks its level." - no, sufficient quantities of water tend to be arranged by the force of gravity over time such that its open surface is roughly equidistant from the center of gravity
"Opposite electrical charges are attracted to each other." - no, there is a force on any two objects of opposite electrical charge each toward the other
"Information wants to be free." - no, it is difficult for one party to limit the distribution of information to only those parties it approves of
The common quotes are shorter and more digestable, literal truth is not relevant compared to effective communication.
On the other hand, the literal expressions are more likely to be left alone by those who don't understand them.
That's fine and well, but analog formats are slowly being phased out and replaced with digital ones. When all the analogue equipment is gone, what will you use to exercise your right, then?
Actually, I didn't mention analog equipment at all, and I doubt we'll ever see digital cameras and audio recorders that recognize and block copyrighted materials. That would be ridiculously hard, and the recognition would cost at least a hundred times as much as the recording itself.
To me, fair use rights aren't a big concern. If you can see it or hear it, you can get an adequate sample for fair use with a cheap camera or audio recorder. You don't need perfect digital video samples to make your point for a review.
The larger issue here is this desperate attempt to cling to a ridiculously outdated and inefficient method of securing profit in return for desirable intellectual production.
Put in simple terms, DRM hurts our economy. Very, very badly.
Economic growth comes from improvements of efficiency, clearing out the dead wood and finding a use for it elsewhere. Following the analogy, DRM is better systems of stakes and cables holding the dead wood from being carted off.
There is a whole ridiculous, unproductive structure built around milking every penny out of copyrighted works. This is justified essentially by accusing every citizen of the stupidest kind of miserliness, unwilling to give a dime to make they're favorite movie studio make another next year, but willing to pay a dollar as long as you don't let them into the theater otherwise.
Yes, there are people out there like that, but I don't believe they're the majority for a second!
The tools are out there, and could be supported and working everywhere in weeks if people want them to be. Don't like the details of that system? Propose another. It's not rocket science: donation doesn't need real-time verification, so it's an easy problem, as long as we agree on some system.
Once people get in the habit of freely parting with their pocket change for things that they'd gladly pay much more for, copyright will be a ridiculous anachronism, and we can finally get on with reaping the benefits of the information age.
CMOS. = Complementry Metal Oxide Semiconductor. This is relatively slow and expensive, but it retains its state when there is no power, hence its use in Bios memory. Most circutry is done in doped silicon.
Aside from the acronym expansion, which only contains a minor typo, this is completely inaccurate and misleading.
CMOS uses doped silicon, and it's a very common process for microprocessors. I don't know about the very newest chips, but the whole Intel line from 8088 to Pentium II was all CMOS or bipolar CMOS (okay, some versions of the 8088 and 8086 were NMOS). It's cheap and fast.
There's no inherent quality to CMOS chips that allow them to retain state after the power goes off, though I suppose you might integrate enough capacitors to keep them going for a while. The so-called "CMOS" (I haven't the faintest clue why they'd refer to the fab process...) settings of your computer are sustained by a battery (or were... maybe the newer ones use flash RAM or something).
Slashdot Mirror
No, you can return 1 list in Perl. It's hardly the same thing; it's a data structure that must be unpacked to be used. For one thing, if the second member of the list is the error code, then just treating it as returning a scalar will ignore the error code without even admitting its existance.
When the value exceded the max size of int, the value went negative
Yes, but...
and the computer thought the rocket had flipped and auto-destruct was triggered.
...no, this is simply wrong. Where did you get this idea? A simple search on google will let you confirm the inaccuracy of this claim with a dozen independent sources. The code in question served no purpose in the air, it was used to align the rocket on the ground. The flight software worked perfectly.
When it went negative, it failed an assertion and threw a math exception. The system read this as "this chip is fried" and shut it down. Then, because the 2 redundant backups were running the exact same programs with the exact same data, it did this twice more. With the computers down, the rocket went wild, and then blew up.
Like most disasters on this scale, many mistakes had to be made simultaneously. If they had stopped running this irrelevant code on launch, it would have been fine, if they had used a larger integer, it would have been fine, if they had used Ada's integer protection, it would have been fine, if they had caught the exception, it would have been fine.
But the things that gets me are 1) that the system was set up not to pass control from a seemingly defective chip to a seemingly good chip, but to yield control from any seemingly defective chip, whether there was another good chip or not and 2) any uncaught exception (not just a specific "We're really sure there's a hardware problem." exception) was taken as proof that the chip was defective. These were both well-known, meaning that there was a concious, considered decision that it was better to halt the system, and completely shut down the guidance system (the only possible result of an uncaught exception due to a software bug) than to face the unknown consequences of running despite an exception they didn't think to catch.
The blame lies with all of those flaws, not just one or two of them. It indeed also lies with the testing that didn't catch it and the decision to reuse legacy code of an older, slower rocket. But note that most of the direct causes were consequences of the exception-handling style of error-handling, and the single most direct cause was a mechanism inspired by the specific belief that halting the system was better than allowing it to run with any one unknown flaw.
I'm not familiar with the rocket you describe, but yes, it is a superior error-handling philosophy. Imagine if there was an unchecked error, and the rocket, instead of detonating, landed in civilian housing?
Why would you assume the rocket was intentionally detonated by the computer? Its computers went down and it went completely out of control. It was only blown up after it broke apart because it happened to go into a spin. There is no upside to this computer failure.
You call blowing up a commercial satellite launch vehicle non-destructive? If this error was ignored the rocket would not have been affected by it, it was an utterly irrelevant mathematical value overflow error in a program that only did anything before launch.
This program became destructive because of the "error management." In particular, the error management philosophy that halting a suspicious system is always safer than allowing it to run.
The point you seem to have missed is that halting the program is often more destructive than ignoring the error. Data loss, control loss, vital services suspended, etc.
That's like saying there's no reason to assume knowing about a bug is better than just allowing a program to go on its merry way. Uncaught bugs are the cause of 99% of the security holes out there. It's always better to know when there is a problem.
I'm sure the European Space Agency found it worth every penny of the estimated half-billion dollars lost to find this otherwise irrelevant bug. After all, it's always better to know, whatever the cost of halting the system, right?
One thing that really bugs me about most programming languages is that they only allow 1 return value by their most natural idiom. So you get these stupid hacks where some settings of the returned value mean errors and some are useful results, of you have to define a new named data structure just for the return value of this one function, or you end up having to mix output variables with the inputs for a function.
This is one thing I like about Forth-style languages, where it's just as natural for a function to return multiple results as to receive multiple arguments, letting you do either:
A B / on_error{ log_error cleanup exit }else{ use_result } return
or
A B / on_error{ store_exception drop_result push_unhandled_exception_errcode }else{ use_result } return
or
A B / drop_error use_result return
Unlike with exceptions, the possibility of an error isn't hidden away somewhere; if you ignore it, or hand it down to reach exception handling code, you have to do so right there and then, explicitly at every step. Actually, that's a general plus: with a stack language, you have to explicitly dispose of everything, which makes it harder to ignore return values, and impossible to write programs without knowing whether a function returns anything ("What do you mean it can return an error code? I though it was void!").
Exceptions make sure that if an error occurs, and you aren't aware of it, your program dies, and doesn't go on its merry way, causing a security hole/unstable software.
You mean like that Ariane rocket that blew up when its double-redundant computer system was halted because of an utterly irrelevant uncaught exception? Yeah, that's definitely a superior error-handling philosophy.
Aside from the conceptual problems of what are essentially COMEFROM statements with scope management, there's no reason to assume that halting the program is better than just allowing it to run.
This is about detected bugs which haven't been fixed yet.
Basically, his complaints boil down to, "bugs exist, causing error messages, why aren't all the ones that cause error messages fixed yet?"
Then he goes off on a confused tangent, apparently suggesting that "error handling" be added to work around any bugs. After all, if it can log the errors caused by bugs, it can respond to them in any way, up to and including fixing the problem (i.e. doing what the code should have done, except for the bug)! For example, if a system file is missing (meaning either a bug in the install, a bug in the program requesting something that isn't really a required system file, or an externally damaged system that can't be expected to work at all), just pop up a dialog to let the user search for it! Because of course the user should attempt to patch things up with his intimate knowledge of system internals instead of just seeing that there's a bug to report.
Hooooo boy....
I didn't see a single example of a genuine external error that wasn't handled properly, just bugs which should be fixed.
Don't you think that we've hauled along the old 8086/XT baggage long enough?
Hauling baggage builds character, consarnit! I was born with a new x86 chip on the market, and I'll die with a new x86 chip on the market.
Some day, I aim to teach my great-grandchild to xor the accumulator by itself to save a byte off the executable, so don't you go a-messin' with that dream!
And ATI isn't giving them that fine control with this hack either.
That doesn't mean that they aren't exercising that fine control. My whole point was that it would be counterproductive to offer that complex, fine control to the end-user.
It does the same thing that the simple Q3 options let anyone do
There is no evidence to support this claim. There are many aspects of image quality ("more things in heaven and earth than are dreamt of in your philosophy"), and nobody has presented evidence that the exact performance of the Quake exe can be duplicated in the Quack exe merely by changing settings available to the user.
I don't accept that the Quake images are simply of worse quality, either. I've looked at the images, and while there are distinct differences, it's hard to say which is better. In the zipped tgas provided, there is more detail in the textures of of the Quack sample (especially noticable on the teeth), but some of the complex relief shading (particularly on the armor) seems indistinct by comparison. Also, the jaggies seem worse in the Quack version. It's even harder to say which looks better when you're playing just by looking at stills.
Besides, maybe Quake 3 has a few scenes that cause it to really bog down with the default settings: you go around, happily accepting your 15% FPS hit for the slightly better image quality, then you go around a corner and suddenly it's an 80% FPS hit in a crucial scene, and practically unplayable. It's better not to allow users to set it that way if it's not sustainable, because people get really annoyed at that kind of inconsistant performance.
The fact of the matter is that we don't know why they did it, and until you try it for yourself, you don't even know what the real effect is. Of course it's possible that this was an underhanded trick, but we don't know that yet. I'm sure we'll hear more as the testers dig into it and ATI responds, so keep an open mind instead of jumping to conclusions.
There's a very simple way for "the people" to take control of open source development: donate money to projects they like. Those who do so demonstrate that catering to their tastes will be rewarded, and then it's in commercial developers' best interests to make OSS with established donors in mind.
It's the simplest, most direct exchange of the relevant scarce resources: money for control over what is produced.
If you're interested, follow my sig.
The point is that users can already lower the settings to get better framerates.
But can they do it in the same way?
Just how complicated should user configuration be? If it's a matter of juggling a dozen different variables to come up with an optimal view, then it's better not to give that control to the user, though it would be impolitic for them to say so. Regardless of how complex the problem is, most gamers (especially the more vocal ones) would believe they could come up with a better configuration, so they'd fiddle with the settings, then blame any problems this causes on the video card and be bitchy over the time they "had to waste to get it to work half-decently."
The problem doesn't likely reduce to a single slider-control that runs from high-quality/low speed to low-quality/high speed.
Different video cards give different quality video, so benchmarks have to take that into account. Some are butt-ugly or just plain wrong, and competent hardware reviewers mention that.
They always have to make trade-offs between frame rate and image quality, what makes tweaking this trade-off for certain games necessarily some kind of trickery?
Id's games have always tended to be a bit freakish, based on unusual, privately researched approaches. Maybe the standard approach isn't perceived as being as playable for Quake 3.
Ideally, they could tweak the system for every individual game, but maybe it's just a case of focusing such efforts on a particularly popular title. Others have pointed out that there are more popular high-performance games, but it would make sense that the default would be optimized for the most popular games, and exceptions coded only for those nearly as popular but different enough for the default settings to be sub-optimal.
the source is here
I'm sure lots of people have their own tiny project to show off.
I'll start the ball rolling with my Buskpledge Windows program, for collecting and managing donation pledges. It lets you make 2-click pledges from web-pages, view and edit the pledges individually or en masse, and can redirect you to direct donation pages such as Amazon Honor System or PayPal. Full install and uninstall in under 35k.
Source is available at the project page. It's a little wierd, using a custom semi-literate programming tool, and a half-assed gzip clone for internal compression.
$400 to manufacture when they sell at $299?
Ever hear "give away the razor, sell the blades"?
Selling gaming platforms at a loss, and making it up on game royalties is fairly standard practice. People don't like to part with that big a chunk of money, and they generally don't seem inclined to compare game prices very carefully in advance.
I mean, you see 2 consoles for sale, one for $500, one for $300. You see that the first has games in the price range $40-$80, and the second $55-$95. Which do you buy? That $200 right now weighs in a lot more with most people than the $15/game, even if you end up getting 30 games.
...was the obvious: who's paying for this?
It always seemed irresponsible to me to go around insisting that software be handed out in source form, freely reusable and redistributable by anyone, without regard for whether there was some expectation that the software would get paid for. Of course, I'm talking about fanatical promoters like RMS, not people who just put their own effort in for their own reasons without saying that others are immoral for doing otherwise.
But then, I have a bad habit of thinking that things change overnight. I suppose it's a reasonable assumption that some form of compensation would be worked out before all programmers ended up sleeping in dumpsters, and it was probably a better idea to get things rolling on principle right away than to demand that all the specifics get worked out in advance.
Anyhow, there's a bit of critique in the essay linked below (along with my 2 bits on how to get it all paid for).
I would also suggest organizing mock terrorist and organized crime cells. Have fun with the cops by sending logistics data back and forth between friends about assasinations, pipe bombs etc. Don't encrypt these, but make them sound serious. If they want to read our emails, then we should fuck with them.
There's a word for such irresponsible pranks: "mischief." It's a crime. There are better ways to fight an invasion of privacy.
Guru (gu'ru): from ancient Hindi guy (guy) and uru (beard) literally "guy with a freaky big beard." Modern meaning: guy with a freaky big beard (generally bad personal hygiene habits add. imp.).
Monty Python, the Argument Sketch. We're going round and round without accomplishing much.
Heh, good point.
I was taking a rather limited view of fair use, but IMHO the most imporant fair-use right is the right to report the evidence of your own senses, and DRM can never touch that. The rest of it seems like fairly minor conveniences. YMMV
I know of no cheap digital equipment.
.ogg, .wma, .mp3, and .aac files, and incorporates DRM into the OS of the player
...and of course there won't be any cheap digital equipment when no analog equipment is available. I mean, even if you ignore the webcams and sound cards available today.
I point you to iObjects whose DadioOS is used in HipZip, and plays
...and so surely you will point me to the evidence that this is installed in machines which are used for recording with a microphone, and that it can recognize copyrighted material coming in through the microphone jack and refuse to record it.
why isn't buskware.org raking in the money?
For one thing, because almost nobody has seen it yet, and I haven't seen any indication that anybody has found it useful. It's new, and I've been putting off promoting it while I work on better tools.
If you look around www.boswa.com, my main software page that's been up for a while, you won't see much. Just a few goofy toys and an early draft of an essay. That's what collected about $5 for, all through e-gold, a relatively obscure micropayment system, and I didn't even have a PayPal link for most of the time.
Look around more. Penny Arcade for instance, which has been surviving on donations for months, and using services that shave off an absurd portion of each one.
At any rate, my own failure would hardly indicate that the whole model is invalid.
And I do believe that the majority of people are MORE THAN WILLING to download MP3s of songs they have never purchased.
And what, precisely is wrong with that?
It doesn't demonstrate in any way that they wouldn't happily donate $0.05 or $1.00 or $0.001 or whatever for every one they download if it was convenient.
I don't support the right of content producers to extract arbitrary prices from users. I don't see anything at all wrong, in an ethical or moral sense, with unauthorized copying.
I don't consider the pathetic fallacy (describing a phenomenon as if the objects involved were humans acting it out) to be a fallacy at all, but a useful metaphorical device.
"Water seeks its level." - no, sufficient quantities of water tend to be arranged by the force of gravity over time such that its open surface is roughly equidistant from the center of gravity
"Opposite electrical charges are attracted to each other." - no, there is a force on any two objects of opposite electrical charge each toward the other
"Information wants to be free." - no, it is difficult for one party to limit the distribution of information to only those parties it approves of
The common quotes are shorter and more digestable, literal truth is not relevant compared to effective communication.
On the other hand, the literal expressions are more likely to be left alone by those who don't understand them.
That's fine and well, but analog formats are slowly being phased out and replaced with digital ones. When all the analogue equipment is gone, what will you use to exercise your right, then?
Actually, I didn't mention analog equipment at all, and I doubt we'll ever see digital cameras and audio recorders that recognize and block copyrighted materials. That would be ridiculously hard, and the recognition would cost at least a hundred times as much as the recording itself.
To me, fair use rights aren't a big concern. If you can see it or hear it, you can get an adequate sample for fair use with a cheap camera or audio recorder. You don't need perfect digital video samples to make your point for a review.
The larger issue here is this desperate attempt to cling to a ridiculously outdated and inefficient method of securing profit in return for desirable intellectual production.
Put in simple terms, DRM hurts our economy. Very, very badly.
Economic growth comes from improvements of efficiency, clearing out the dead wood and finding a use for it elsewhere. Following the analogy, DRM is better systems of stakes and cables holding the dead wood from being carted off.
There is a whole ridiculous, unproductive structure built around milking every penny out of copyrighted works. This is justified essentially by accusing every citizen of the stupidest kind of miserliness, unwilling to give a dime to make they're favorite movie studio make another next year, but willing to pay a dollar as long as you don't let them into the theater otherwise.
Yes, there are people out there like that, but I don't believe they're the majority for a second!
The tools are out there, and could be supported and working everywhere in weeks if people want them to be. Don't like the details of that system? Propose another. It's not rocket science: donation doesn't need real-time verification, so it's an easy problem, as long as we agree on some system.
Once people get in the habit of freely parting with their pocket change for things that they'd gladly pay much more for, copyright will be a ridiculous anachronism, and we can finally get on with reaping the benefits of the information age.
CMOS. = Complementry Metal Oxide Semiconductor. This is relatively slow and expensive, but it retains its state when there is no power, hence its use in Bios memory. Most circutry is done in doped silicon.
Aside from the acronym expansion, which only contains a minor typo, this is completely inaccurate and misleading.
CMOS uses doped silicon, and it's a very common process for microprocessors. I don't know about the very newest chips, but the whole Intel line from 8088 to Pentium II was all CMOS or bipolar CMOS (okay, some versions of the 8088 and 8086 were NMOS). It's cheap and fast.
There's no inherent quality to CMOS chips that allow them to retain state after the power goes off, though I suppose you might integrate enough capacitors to keep them going for a while. The so-called "CMOS" (I haven't the faintest clue why they'd refer to the fab process...) settings of your computer are sustained by a battery (or were... maybe the newer ones use flash RAM or something).