No, what happens is that if you sue, your permission to modify is rescinded. If you claim it was of no worth to be able to do that, then you can't claim it is damaging in any way to not be allowed to continue to use the modified version. If it is of no worth to modify and use it, then why did you do it?
A derived work IS the "property" of the person who modified it (along with the original creators, of course). Your argument makes no sense. The GPL requires that you provide sources to anyone who asks for it, and sets a limit on the amount of money you can charge for that service. How is that any different? You make the same kind of promise, that you will provide a service for a period of time with a cap on the amount of money you will charge for it. If you fail to fulfill that promise, then your original permission to modify and distribute becomes void, and you are guilty of copyright infringement. If you think it was of no value, then you don't need to worry about that, as there won't be any damages, right? Just violate away, what you're copying and modifying is of no value, and you're obviously doing it for no reason.
The terms of the re-distribution requirements are directly related to the value of the copyrighted material you were permitted to modify and distribute, just as the patent clause is, and the terms are reasonable. If you don't agree with the terms, then you have no right to unilaterally violate copyright. If you do agree with the terms, then either your agreement had no value (or why would you agree), or you believe that the right to modify and/or distribute is of some worth.
How can a promise not to sue for patent infringement, in trade for a promise not to sue for copyright infringement, not be an equitable exchange?
I think that someone else's freedom to kidnap or murder me would make me less free than do restrictions on me to kidnap or murder someone else. I think most people think similarly, which is why we have such restrictions. As there's no such thing as "total freedom", all we can do is try to be more rather than less free.
The new proposed GNU Simpler Free Documentation License [ . . . ] has no requirements to maintain Cover Texts and Invariant Sections. This will provide a simpler licensing option for authors who do not wish to use these features in the GNU FDL.
That's like saying you're not really in a free society because there are laws against fraud, property damage, theft, assault, battery, rape, murder, and they even make you uphold your end of a bargain - how can you truly be free if you can't do all those things to other people? How can software be truly free if you can't turn it into unfree software? Oh, the horror!
So continue to use GPLv2, if that's what you want. Note, however, that if you could combine your code with GPLv2 code, and not release parts of your codebase along with it, you can still do the same thing with GPLv3 as well. The basic idea of a derivative work versus "aggregation" hasn't changed. You can release parts of your program under GPLv3 and still release the rest with your macho patented code under any other license you want. If you can't do that under GPLv3, then you couldn't keep the source code for that part proprietary under GPLv2 either.
One way to look at the patent clause is that they realized that the "this license doesn't cover using the program, as no such permission is necessary" isn't quite adequate; they are requiring that IF a patent is involved, permission to USE the patent must be included along with the permissions under copyright law; if you can't or won't give (or pass along) such permission, you can't distribute it. Otherwise, people can be in the awkward position of having code that they can modify and distribute but not actually use, which sort of makes the rest of your rights under the license fairly useless.
If you think BSD is the right way to go, then why do you even care about GPLv2 vs. GPLv3? Neither suits your purpose. If TiVo wants to use BSD code instead, then why don't they? BSD doesn't require that you let the end user modify the software you sell them, nor even provide source code. Sounds perfect for what they want to do.
The philosophy is the same. The primary motivating goal behind the GPL has always been to enable the end user the freedom to modify the software that they receive, in whatever fashion, and be able to share the software they're using (modified or not) with others. Patents inhibit that freedom. The restrictions on someone who uses patents as a weapon against Free Software are ONLY to the acts of modifying and distributing it, which is completely within copyright law.
They are not allowing you to distribute a modified version of the software that relies on patented methods unless you promise not to sue anyone for patent infringement on those methods. They are also not allowing you to use modified versions of the software that you've kept private if you have sued someone for patent infringement on anything that the modified version does (even if the unmodified version already did it).
Neither of these are "EULA". They are taking away permission to modify and distribute, as copyright law allows them to do. You can still USE a version that is publicly available even then, you just can't modify it to use your patented method if you're trying to prevent anyone else from using it as well. Actually, it looks like if you modify it to NOT use your patented method, you could use or release it then, but I'm not sure of that.
To the extent copyright law wouldn't restrict using a modified version without permission, you could still use it (but still not distribute it). An example would be a "necessary" modification to make it run. At least, that's how I read it.
It's even simpler than that. The "high quality proprietary software" that they're looking at is going to be specialized software, running on well-defined hardware, with all components completely specified (operating system, if any, library, compiler). It isn't going to be written to be as flexible as possible, able to be compiled for 10 flavors of Unix/Linux/Mac/Windows, using ANSI and non-ANSI compilers and a variety of standard libraries on 8 different processor families, with different endian and word sizes. It isn't going to have compile-time enabling or disabling of the various features that different people think are important to have or are not important enough to compile in. It isn't going to have support for multiple languages, multiple time zones, alternate collating sequences. It won't have a configuration file that can drastically alter the way it works, with several levels of defaults, working in multiple "standard" file-system layouts.
It is probably going to be a program that has been in use, mostly unchanged, for many years. It is going to have a very specific set of well-defined operating characteristics. The level of complexity in operating modes and interactions between components in the product will be low. It also won't have a lot of people clamoring for new and changed features, so it will be stable.
Now, there are going to be some Open Source programs with similar characteristics. However, you won't find them by scanning the "50 most popular" ones.
That's not even considering that they're only looking at suspicious code that might cause clearly undesirable behavior. They aren't looking at ALL if the software actually does what it is supposed to do, or doing it in a considerate manner (considerate to the end user, that is). If the program fails to save my file in certain circumstances because it didn't set a flag in the right place, their checks won't find it, yet that could be as disastrous to me as the whole program crashing on a null pointer dereference. Similarly, it isn't going to see that the auto-pilot function will cause the aircraft to suddenly engage reverse thrusters when you cross over the North Pole, for example, nor is it going to notice that the stupid VCR firmware cancels the program if I don't turn power off in time instead of starting to record even though it is 5 seconds into the show.
a) it's not a show stopper, and b) it isn't even really a bug. Although doing it a different way is arguably slightly more correct, it also removes capability. Given that at the level this is being done, the code can do pretty much anything it wants anyway, the security implications of doing it one way or the other are pretty much nil. It is good to note that this is one way of modifying the behavior of the kernel that some security kits may not check for, however.
Their fix doesn't even make this more secure. Something that can load a binary format handler and have it register itself can easily find ways to patch that linked list directly. For example, it can find the symbol *formats* in many possible ways: by looking in the boot image; by looking in/proc/kallsyms, by looking for the system map in various places; there's a non-local variable "core_uses_pid", which is the variable just before it in memory, that it can link to. It can verify that it found the correct location by registering it normally, then verify that the suspected location actually does link to its handler structure. It could even look in the code of the register routine to find a likely pointer to it.
They're complaining that when you add a new binary format handler, the new one is inserted at the beginning of the list instead of at the end. Since your fake handler can always return "not mine", it doesn't affect the others, but allows your code to get control every time a process does an exec(). They recommend adding the new handler at the end of the list, so it usually doesn't get called (in fact, will only get called when something tries to exec a file type that isn't recognized).
It's effectively a way of patching the exec call in a somewhat sneaky fashion that might not be detected by some counter-measures. Technically, adding the new handler to the end of the list is more secure, since a new format can't hijack any existing formats (by accident or on purpose). Operationally, putting it at the end of the list is less flexible, as it makes it easy to override an existing format, thus being able to test a new handler, or conditionally run the new or old handler for some cases. Since this is a highly sensitive operation in the first place, adding slightly more security doesn't seem to me to be worth removing the added flexibility. In either case, you already own the system.
I don't need a defense, I was giving an example of code that current compilers don't analyze as completely as possible, as an example of the type of thing that a code verifier would have to be able to analyze in order to find obscure problems. It wasn't being held up as an example of fine programming.
I don't need to assume anything about b and c outside the loop, as I didn't give any code outside the loop. You're the one assuming for some reason that b and/or c would be needed after the loop. I was saying ONLY that if b and c were not initialized at the beginning of the loop, some compilers would complain about b being possibly uninitialized, and some would not but still complain about c being possibly uninitialized, in the code that was given.
And yes, they COULD be used in the "proper context", i.e. code which is only executed if n >= 1 (or >0 for using only b).
Ok, so let's say that DRM becomes untenable (DMCA is killed, GPLv3 is widely accepted, copyright law is changed so that you don't have a copyright on the binary unless you distribute the source code, Microsoft goes under and Linux (GPLv3) becomes the predominant operating system, copyright law is modified to explicitly allow P2P); the megacorporations do what, stop selling music because they can't compete with P2P? Ok, so maybe they do, so what do the bands do? Stop writing and performing music?
Many many MANY bands are out there, performing in small venues, maybe releasing an album on their own, hoping to get back enough money to cover their cost of producing it. They'd probably do MUCH better in an environment where most of the advertising, publicity and airtime is devoted to whoever the big labels are pushing. I think you'd find a much healthier music business - not one that makes a lot more money, but one that produces a lot more music and returns more to the people who actually are creating it.
b and c will be uninitialized outside the loop, true, but they aren't used outside the loop. Note that I don't declare the variables, inside or outside the loop, and it isn't even necessarily C code. Even if b or c are used later, it could well be that they are used in a context where n is known to be >= 1. You can't read more into code fragments than what is presented.
If I were to use b or c after the end of the loop (with no other initializations or conditions), then a program verifier might add in, or require me to add in, an assertion that n >=1, and anything that called that code would be flagged in error if it couldn't be proven that was true. Granted, that isn't necessarily the best way to handle such code, but assuming that the code was intended to handle non-integer values, or any values
Remember, this was just an example of the type of code analysis that current compilers don't do. It isn't really a problem there, it isn't designed nor required to catch every place that you DON'T need to initialize something, and a spurious initialization isn't exactly a huge performance hit. The real question would then be if there are any program verifiers that are even smart enough to figure out this example on their own. How much analysis can a program verifier do in similar situations? Do you have to lead it by the hand to prove your program doesn't have errors, or can it figure out a bunch of it on its own? The more you have to do, the less useful a program verifier is. Of course, even that type of verification just proves that you never reference uninitialized variables, dereference NULL pointers, get array subscripts out of bounds, or have memory leaks, etc.
At some level the verification that the program actually accomplishes what you want boils down to re-writing the way you specify what it is supposed to do, and if there is an error in those specifications (which, after all, will just be another programming language), then the verifier will happily verify that your program does the wrong thing. At least there's a good chance that if the specifications are wrong, the implementation won't match, and you can then look more closely at both to determine which one is incorrect. It should also be pretty good at pointing out code that can never work as intended.
Let's see - retail price for a Blu-Ray player, vs. Sony's cost for a Blu-Ray raw drive. Remember, they're trying to recover the sunk costs (R & D, facilities) with the retail price. With the cost for a raw drive, in a device supposedly being sold at below cost, you can't assign sunk costs to the unit when deciding if they're selling it at a loss or not. The rest of the mechanism for the drive may have had it's difficulties in design, but the actual marginal cost to manufacture is unlikely to be more than twice as much as for a DVD drive, leaving only the cost of a blue laser to make up for the "$200-300 estimated" cost of a Blu-Ray drive. How much does the laser cost in a DVD player (or the two lasers in most players, actually)? Is a blue laser really going to cost that much more, even if production yields are horrible?
You make a good point, but since I was only giving code fragments, you didn't see that this was C code and n was declared as an int parameter...but, let's say it's a dynamically-typed language, should it flag this code fragment as the error, or the location where I call it with a value that it can't prove is = 1? You can go a long way with assertions, and a program verifier can use assertions to guide it in it's proofs (although the assertions have to verifiable from the code, which means you have to lay out a proof-by-assertion for the verifier). However, at some point it isn't going to be able to show that the program really does what you want it to do. You can probably prove a lot about the parts of it, though.
There are many simple things that a program verifier can check for. I can see a program figuring out that your foo(NULL) call is always going to be wrong (e.g. by having the verifier notice that you are dereferencing it without checking if it is NULL and adding an assertion to the exported definition of the function; in this case the assertion will be a constant so it can be a compile-time error).
A lot of the "variable may be uninitialized" errors that a good compiler will spit out are along those lines. They could be much better, though:
a = 0;
while (a < n) { if (a == 0) b = 1; else b += a;
if (b <= n) c = a + b;
a += b + c; }
("n" is a passed parameter in the above). Some compilers will require a spurious initialization of b in the above to avoid getting a warning the assignment "b += a". They're smart enough to know that b is initialized after the if-else, so the "a += b" line isn't flagged, but the "b += a" line will be. Note, gcc isn't one of those, it has no problem with that line.
However, even gcc complains about c being possibly uninitialized, even though we can tell from looking at the code that n MUST be greater than 0, so on the first pass through the code, the second if clause must be true, thus c will always have a valid value.
If you extend this to code that has to figure out relationships between inputs to and outputs from a function, and thus what values might or might not be legal to pass in, you've passed well beyond what a program verifier can currently do.
Take, for instance, a common code sequence:
n = int(x/b); r = x - (n * b);
If I put an assertion that (((x >= 0) && (b > 0)) implies ((r >= 0) && (r
"The way to write software is to design it, not have a random number generator spit out text, wait until a given chunk compiles, then test it to see if it does what you want."
And you say "that's not true, it will eventually produce a correct program! It might be easier to write a program by designing it, but that's a different question."
Anyway, if you are in orbit and you continually accelerate directly away from Earth (which means that you are continually changing your thrust vector as you continue to orbit), I think it depends on how much thrust you have whether you can reach escape velocity, whereas you can eventually achieve escape velocity with minimal thrust if you are always accelerating along your orbital path (which, again, means you're constantly changing your thrust vector). Not that I'm a rocket scientist or anything.
Right, hence my question: how much does a blue laser cost? That would be the ONLY thing with a significant cost. Those estimates of "between $200-300 per unit" are worthless, unless they're based on real known costs of around $150-250 per laser. Or can you tell me some reason why the rest of the drive would cost any more than twice as much as a DVD drive?
Actually, you often do not get enough information to figure out things like "how much does each one cost" to make.
In any event, they are speculating on information that hasn't come out yet. Yes, you can figure out about how much money Sony's spent on developing the various bits and pieces. That tells you absolutely nothing about component costs, just how much profit you're going to have to take in order to for that investment in infrastructure to pay off eventually.
Yes, I consider "cost estimates" for a Blu-Ray drive at $200 (or even "way up" from there, according to the article) to be ridiculous. Yes, blue lasers are in short supply, but exactly how much do they cost when you can get them? $150?
Yeah, $0.02 per second is $72 per hour! Burger flipping suddenly seems like a good career move!
One mistake people make (other than misplacing decimal points) is confusing fixed costs with variable costs with sunk costs. It doesn't cost McDonald's more labor money when you come in to buy a hamburger, so that isn't (directly) a part of the marginal cost of each one. True, if there is a very large shift in customer demand, either way, they'll get more or fewer people to work for them, so there's a loose coupling, but VERY loose. You really have to look at peak demand time to figure out how much the time it take to put together a sandwich and sell it to a customer costs you, because only then is time going to be a limiting factor in how many you can sell.
(a) you're assuming that the parts inside are worth more than the whole package; but you're not going to be able to use everything there, the enclosure, the controller, plenty of stuff that won't be useful except in a game console. In other words, the assumed cost to Sony of making a console includes a fair bit more than the purchase price of the parts you'll find usable.
(b) you're not counting the time it takes to take apart those consoles. It is unlikely you'll find it cost effective to even spend the time to take out connectors, cables, switches, etc, but those are all things that went into the cost of it (not to mention putting it all together, which you're now undoing).
(c) you're assuming that those reports are correct of how it costs Sony so much more to produce than they're charging for it.
It seems unlikely, for instance, that a Blu-Ray drive will cost them more than twice as much as a DVD drive costs. I mean, how much does a blue laser cost, anyway? $150? That's the only way I could see a Blu-Ray drive costing them $200.
I think Sony will NOT be losing any money on each console, at least if you're talking marginal costs. I think they're pricing them to make back some of their sunk costs on the initial gotta-have-it crowd. Once that starts to slow down, they'll be able to reduce their price and still make money, in part because their costs will go down as their volume goes up. Yes, they have to make back the money they've invested on it eventually, but that doesn't mean it is COSTING them money to sell each console. Look for at least one, if not two price reductions in 2007, and NOT because they're desperate.
I thought the article was pretty stupid. "A distant third" because they'll only sell 2 million consoles this year, compared to 10 million that Microsoft will have sold (supposedly). The big question is, how many will Microsoft sell in the same period, from the time the PS3 goes on sale? THAT will tell you how it's going, not using an artificial "yearly sales" value. How about you include sales of PS2 if you want to include the whole year?
Slashdot Mirror
It seems likely that if the buses aren't running at a particular time, then the peak-use tolls also wouldn't be in effect.
No, what happens is that if you sue, your permission to modify is rescinded. If you claim it was of no worth to be able to do that, then you can't claim it is damaging in any way to not be allowed to continue to use the modified version. If it is of no worth to modify and use it, then why did you do it?
A derived work IS the "property" of the person who modified it (along with the original creators, of course). Your argument makes no sense. The GPL requires that you provide sources to anyone who asks for it, and sets a limit on the amount of money you can charge for that service. How is that any different? You make the same kind of promise, that you will provide a service for a period of time with a cap on the amount of money you will charge for it. If you fail to fulfill that promise, then your original permission to modify and distribute becomes void, and you are guilty of copyright infringement. If you think it was of no value, then you don't need to worry about that, as there won't be any damages, right? Just violate away, what you're copying and modifying is of no value, and you're obviously doing it for no reason.
The terms of the re-distribution requirements are directly related to the value of the copyrighted material you were permitted to modify and distribute, just as the patent clause is, and the terms are reasonable. If you don't agree with the terms, then you have no right to unilaterally violate copyright. If you do agree with the terms, then either your agreement had no value (or why would you agree), or you believe that the right to modify and/or distribute is of some worth.
How can a promise not to sue for patent infringement, in trade for a promise not to sue for copyright infringement, not be an equitable exchange?
I think that someone else's freedom to kidnap or murder me would make me less free than do restrictions on me to kidnap or murder someone else. I think most people think similarly, which is why we have such restrictions. As there's no such thing as "total freedom", all we can do is try to be more rather than less free.
You can read it here.
That's like saying you're not really in a free society because there are laws against fraud, property damage, theft, assault, battery, rape, murder, and they even make you uphold your end of a bargain - how can you truly be free if you can't do all those things to other people? How can software be truly free if you can't turn it into unfree software? Oh, the horror!
So continue to use GPLv2, if that's what you want. Note, however, that if you could combine your code with GPLv2 code, and not release parts of your codebase along with it, you can still do the same thing with GPLv3 as well. The basic idea of a derivative work versus "aggregation" hasn't changed. You can release parts of your program under GPLv3 and still release the rest with your macho patented code under any other license you want. If you can't do that under GPLv3, then you couldn't keep the source code for that part proprietary under GPLv2 either.
One way to look at the patent clause is that they realized that the "this license doesn't cover using the program, as no such permission is necessary" isn't quite adequate; they are requiring that IF a patent is involved, permission to USE the patent must be included along with the permissions under copyright law; if you can't or won't give (or pass along) such permission, you can't distribute it. Otherwise, people can be in the awkward position of having code that they can modify and distribute but not actually use, which sort of makes the rest of your rights under the license fairly useless.
If you think BSD is the right way to go, then why do you even care about GPLv2 vs. GPLv3? Neither suits your purpose. If TiVo wants to use BSD code instead, then why don't they? BSD doesn't require that you let the end user modify the software you sell them, nor even provide source code. Sounds perfect for what they want to do.
The philosophy is the same. The primary motivating goal behind the GPL has always been to enable the end user the freedom to modify the software that they receive, in whatever fashion, and be able to share the software they're using (modified or not) with others. Patents inhibit that freedom. The restrictions on someone who uses patents as a weapon against Free Software are ONLY to the acts of modifying and distributing it, which is completely within copyright law.
They are not allowing you to distribute a modified version of the software that relies on patented methods unless you promise not to sue anyone for patent infringement on those methods. They are also not allowing you to use modified versions of the software that you've kept private if you have sued someone for patent infringement on anything that the modified version does (even if the unmodified version already did it).
Neither of these are "EULA". They are taking away permission to modify and distribute, as copyright law allows them to do. You can still USE a version that is publicly available even then, you just can't modify it to use your patented method if you're trying to prevent anyone else from using it as well. Actually, it looks like if you modify it to NOT use your patented method, you could use or release it then, but I'm not sure of that.
To the extent copyright law wouldn't restrict using a modified version without permission, you could still use it (but still not distribute it). An example would be a "necessary" modification to make it run. At least, that's how I read it.
It's even simpler than that. The "high quality proprietary software" that they're looking at is going to be specialized software, running on well-defined hardware, with all components completely specified (operating system, if any, library, compiler). It isn't going to be written to be as flexible as possible, able to be compiled for 10 flavors of Unix/Linux/Mac/Windows, using ANSI and non-ANSI compilers and a variety of standard libraries on 8 different processor families, with different endian and word sizes. It isn't going to have compile-time enabling or disabling of the various features that different people think are important to have or are not important enough to compile in. It isn't going to have support for multiple languages, multiple time zones, alternate collating sequences. It won't have a configuration file that can drastically alter the way it works, with several levels of defaults, working in multiple "standard" file-system layouts.
It is probably going to be a program that has been in use, mostly unchanged, for many years. It is going to have a very specific set of well-defined operating characteristics. The level of complexity in operating modes and interactions between components in the product will be low. It also won't have a lot of people clamoring for new and changed features, so it will be stable.
Now, there are going to be some Open Source programs with similar characteristics. However, you won't find them by scanning the "50 most popular" ones.
That's not even considering that they're only looking at suspicious code that might cause clearly undesirable behavior. They aren't looking at ALL if the software actually does what it is supposed to do, or doing it in a considerate manner (considerate to the end user, that is). If the program fails to save my file in certain circumstances because it didn't set a flag in the right place, their checks won't find it, yet that could be as disastrous to me as the whole program crashing on a null pointer dereference. Similarly, it isn't going to see that the auto-pilot function will cause the aircraft to suddenly engage reverse thrusters when you cross over the North Pole, for example, nor is it going to notice that the stupid VCR firmware cancels the program if I don't turn power off in time instead of starting to record even though it is 5 seconds into the show.
a) it's not a show stopper, and b) it isn't even really a bug. Although doing it a different way is arguably slightly more correct, it also removes capability. Given that at the level this is being done, the code can do pretty much anything it wants anyway, the security implications of doing it one way or the other are pretty much nil. It is good to note that this is one way of modifying the behavior of the kernel that some security kits may not check for, however.
Their fix doesn't even make this more secure. Something that can load a binary format handler and have it register itself can easily find ways to patch that linked list directly. For example, it can find the symbol *formats* in many possible ways: by looking in the boot image; by looking in /proc/kallsyms, by looking for the system map in various places; there's a non-local variable "core_uses_pid", which is the variable just before it in memory, that it can link to. It can verify that it found the correct location by registering it normally, then verify that the suspected location actually does link to its handler structure. It could even look in the code of the register routine to find a likely pointer to it.
They're complaining that when you add a new binary format handler, the new one is inserted at the beginning of the list instead of at the end. Since your fake handler can always return "not mine", it doesn't affect the others, but allows your code to get control every time a process does an exec(). They recommend adding the new handler at the end of the list, so it usually doesn't get called (in fact, will only get called when something tries to exec a file type that isn't recognized).
It's effectively a way of patching the exec call in a somewhat sneaky fashion that might not be detected by some counter-measures. Technically, adding the new handler to the end of the list is more secure, since a new format can't hijack any existing formats (by accident or on purpose). Operationally, putting it at the end of the list is less flexible, as it makes it easy to override an existing format, thus being able to test a new handler, or conditionally run the new or old handler for some cases. Since this is a highly sensitive operation in the first place, adding slightly more security doesn't seem to me to be worth removing the added flexibility. In either case, you already own the system.
I don't need a defense, I was giving an example of code that current compilers don't analyze as completely as possible, as an example of the type of thing that a code verifier would have to be able to analyze in order to find obscure problems. It wasn't being held up as an example of fine programming.
I don't need to assume anything about b and c outside the loop, as I didn't give any code outside the loop. You're the one assuming for some reason that b and/or c would be needed after the loop. I was saying ONLY that if b and c were not initialized at the beginning of the loop, some compilers would complain about b being possibly uninitialized, and some would not but still complain about c being possibly uninitialized, in the code that was given.
And yes, they COULD be used in the "proper context", i.e. code which is only executed if n >= 1 (or >0 for using only b).
Ok, so let's say that DRM becomes untenable (DMCA is killed, GPLv3 is widely accepted, copyright law is changed so that you don't have a copyright on the binary unless you distribute the source code, Microsoft goes under and Linux (GPLv3) becomes the predominant operating system, copyright law is modified to explicitly allow P2P); the megacorporations do what, stop selling music because they can't compete with P2P? Ok, so maybe they do, so what do the bands do? Stop writing and performing music?
Many many MANY bands are out there, performing in small venues, maybe releasing an album on their own, hoping to get back enough money to cover their cost of producing it. They'd probably do MUCH better in an environment where most of the advertising, publicity and airtime is devoted to whoever the big labels are pushing. I think you'd find a much healthier music business - not one that makes a lot more money, but one that produces a lot more music and returns more to the people who actually are creating it.
b and c will be uninitialized outside the loop, true, but they aren't used outside the loop. Note that I don't declare the variables, inside or outside the loop, and it isn't even necessarily C code. Even if b or c are used later, it could well be that they are used in a context where n is known to be >= 1. You can't read more into code fragments than what is presented.
If I were to use b or c after the end of the loop (with no other initializations or conditions), then a program verifier might add in, or require me to add in, an assertion that n >=1, and anything that called that code would be flagged in error if it couldn't be proven that was true. Granted, that isn't necessarily the best way to handle such code, but assuming that the code was intended to handle non-integer values, or any values
Remember, this was just an example of the type of code analysis that current compilers don't do. It isn't really a problem there, it isn't designed nor required to catch every place that you DON'T need to initialize something, and a spurious initialization isn't exactly a huge performance hit. The real question would then be if there are any program verifiers that are even smart enough to figure out this example on their own. How much analysis can a program verifier do in similar situations? Do you have to lead it by the hand to prove your program doesn't have errors, or can it figure out a bunch of it on its own? The more you have to do, the less useful a program verifier is. Of course, even that type of verification just proves that you never reference uninitialized variables, dereference NULL pointers, get array subscripts out of bounds, or have memory leaks, etc.
At some level the verification that the program actually accomplishes what you want boils down to re-writing the way you specify what it is supposed to do, and if there is an error in those specifications (which, after all, will just be another programming language), then the verifier will happily verify that your program does the wrong thing. At least there's a good chance that if the specifications are wrong, the implementation won't match, and you can then look more closely at both to determine which one is incorrect. It should also be pretty good at pointing out code that can never work as intended.
Let's see - retail price for a Blu-Ray player, vs. Sony's cost for a Blu-Ray raw drive. Remember, they're trying to recover the sunk costs (R & D, facilities) with the retail price. With the cost for a raw drive, in a device supposedly being sold at below cost, you can't assign sunk costs to the unit when deciding if they're selling it at a loss or not. The rest of the mechanism for the drive may have had it's difficulties in design, but the actual marginal cost to manufacture is unlikely to be more than twice as much as for a DVD drive, leaving only the cost of a blue laser to make up for the "$200-300 estimated" cost of a Blu-Ray drive. How much does the laser cost in a DVD player (or the two lasers in most players, actually)? Is a blue laser really going to cost that much more, even if production yields are horrible?
We have open primaries in Illinois...
You make a good point, but since I was only giving code fragments, you didn't see that this was C code and n was declared as an int parameter...but, let's say it's a dynamically-typed language, should it flag this code fragment as the error, or the location where I call it with a value that it can't prove is = 1? You can go a long way with assertions, and a program verifier can use assertions to guide it in it's proofs (although the assertions have to verifiable from the code, which means you have to lay out a proof-by-assertion for the verifier). However, at some point it isn't going to be able to show that the program really does what you want it to do. You can probably prove a lot about the parts of it, though.
There are many simple things that a program verifier can check for. I can see a program figuring out that your foo(NULL) call is always going to be wrong (e.g. by having the verifier notice that you are dereferencing it without checking if it is NULL and adding an assertion to the exported definition of the function; in this case the assertion will be a constant so it can be a compile-time error).
A lot of the "variable may be uninitialized" errors that a good compiler will spit out are along those lines. They could be much better, though:
("n" is a passed parameter in the above). Some compilers will require a spurious initialization of b in the above to avoid getting a warning the assignment "b += a". They're smart enough to know that b is initialized after the if-else, so the "a += b" line isn't flagged, but the "b += a" line will be. Note, gcc isn't one of those, it has no problem with that line.
However, even gcc complains about c being possibly uninitialized, even though we can tell from looking at the code that n MUST be greater than 0, so on the first pass through the code, the second if clause must be true, thus c will always have a valid value.
If you extend this to code that has to figure out relationships between inputs to and outputs from a function, and thus what values might or might not be legal to pass in, you've passed well beyond what a program verifier can currently do.
Take, for instance, a common code sequence:
If I put an assertion that (((x >= 0) && (b > 0)) implies ((r >= 0) && (r
"The way to write software is to design it, not have a random number generator spit out text, wait until a given chunk compiles, then test it to see if it does what you want."
And you say "that's not true, it will eventually produce a correct program! It might be easier to write a program by designing it, but that's a different question."Anyway, if you are in orbit and you continually accelerate directly away from Earth (which means that you are continually changing your thrust vector as you continue to orbit), I think it depends on how much thrust you have whether you can reach escape velocity, whereas you can eventually achieve escape velocity with minimal thrust if you are always accelerating along your orbital path (which, again, means you're constantly changing your thrust vector). Not that I'm a rocket scientist or anything.
Right, hence my question: how much does a blue laser cost? That would be the ONLY thing with a significant cost. Those estimates of "between $200-300 per unit" are worthless, unless they're based on real known costs of around $150-250 per laser. Or can you tell me some reason why the rest of the drive would cost any more than twice as much as a DVD drive?
How much does a blue laser cost? Add $20, that's probably about how much more the PS3 costs because of Blu-Ray instead of a DVD drive.
Why, you almost can't afford to NOT buy thirty games! Look how much you save!
Actually, you often do not get enough information to figure out things like "how much does each one cost" to make.
In any event, they are speculating on information that hasn't come out yet. Yes, you can figure out about how much money Sony's spent on developing the various bits and pieces. That tells you absolutely nothing about component costs, just how much profit you're going to have to take in order to for that investment in infrastructure to pay off eventually.
Yes, I consider "cost estimates" for a Blu-Ray drive at $200 (or even "way up" from there, according to the article) to be ridiculous. Yes, blue lasers are in short supply, but exactly how much do they cost when you can get them? $150?
Yeah, $0.02 per second is $72 per hour! Burger flipping suddenly seems like a good career move!
One mistake people make (other than misplacing decimal points) is confusing fixed costs with variable costs with sunk costs. It doesn't cost McDonald's more labor money when you come in to buy a hamburger, so that isn't (directly) a part of the marginal cost of each one. True, if there is a very large shift in customer demand, either way, they'll get more or fewer people to work for them, so there's a loose coupling, but VERY loose. You really have to look at peak demand time to figure out how much the time it take to put together a sandwich and sell it to a customer costs you, because only then is time going to be a limiting factor in how many you can sell.
(a) you're assuming that the parts inside are worth more than the whole package; but you're not going to be able to use everything there, the enclosure, the controller, plenty of stuff that won't be useful except in a game console. In other words, the assumed cost to Sony of making a console includes a fair bit more than the purchase price of the parts you'll find usable.
(b) you're not counting the time it takes to take apart those consoles. It is unlikely you'll find it cost effective to even spend the time to take out connectors, cables, switches, etc, but those are all things that went into the cost of it (not to mention putting it all together, which you're now undoing).
(c) you're assuming that those reports are correct of how it costs Sony so much more to produce than they're charging for it.
It seems unlikely, for instance, that a Blu-Ray drive will cost them more than twice as much as a DVD drive costs. I mean, how much does a blue laser cost, anyway? $150? That's the only way I could see a Blu-Ray drive costing them $200.
I think Sony will NOT be losing any money on each console, at least if you're talking marginal costs. I think they're pricing them to make back some of their sunk costs on the initial gotta-have-it crowd. Once that starts to slow down, they'll be able to reduce their price and still make money, in part because their costs will go down as their volume goes up. Yes, they have to make back the money they've invested on it eventually, but that doesn't mean it is COSTING them money to sell each console. Look for at least one, if not two price reductions in 2007, and NOT because they're desperate.
I thought the article was pretty stupid. "A distant third" because they'll only sell 2 million consoles this year, compared to 10 million that Microsoft will have sold (supposedly). The big question is, how many will Microsoft sell in the same period, from the time the PS3 goes on sale? THAT will tell you how it's going, not using an artificial "yearly sales" value. How about you include sales of PS2 if you want to include the whole year?