If you put Office on a PC, it can be one-third of the material cost of the system. Is that sustainable? ...
I think what we need to make sure of is customer perception of value versus competitive offerings.
This is what Microsoft either (a) figured out first or (b) did the best job of taking advantage of: three components to pricing.
Actual value
Perceived value
Available alternatives
Therefore, manipulate the perception of value (OpenSource will eat your children!) and make sure that the number of available alternatives approaches zero awful damn quick.
I think, read as a whole, this question constitutes an admission that they are fully committed to the unsustainability of the pricing on Office until one of these three conditions changes.
Ballmer (essentially) said he's fully willing to have the relative pricing of Office compared to a computer not just stay at 1/3 but to have no inherent relationship to the price of anything else (I smell a user-level subscription model . ..) because once you cross conditions 2 and 3, there's no limit.
I'm not sure whether "place" means a geographic location (such as my house) or a network address (such as my IP address) or an identifier (such as a DNS address or email address, either of which might correspond to a person).
The effect of the DMCA on reverse engineering is complicated.... I hate to dodge your question, but I'm not really qualified to say whether what the clone makers did would be legal under 2003 law.
An example: auto parts manufacturers are worried by recent DMCA developments, such as the case where Lexmark has successfully (so far) used the DMCA against a maker of replacement parts for Lexmark printers.
This sounds like a likely DMCA violation, but you'll have to consult your lawyer to be sure.
Felten says "The new regulations on technology will impose a drag on our technological capabilities, and hence on our productivity." And this is clearly true.
But consider that it's actually true in two ways:
The obvious sense - DMCA and kin will make it illegal to do things we otherwise would have done
The "meta" sense - DMCA and kin mean that we have to stop what we're doing and ask it if would be legal if we did it
So, obviously, all laws have these two kinds of cost. But the pernicious effect of regulation in spheres of otherwise normal activity (and particularly of regulation as poorly drafted as the DMCA) is that it brings vast swaths of life into the domain of expert legal opinion.
Can we reverse engineer this? Will this interoperability be allowed to work? Even, is my firewall legal?
The chilling effect on development and innovation will be horrible until these developments get filtered through the courts. No one can innovate well in a world where much innovation may be bluntly illegal.
Seriously -- actual intelligent literary reference on slashdot in a Java performance discussion. Who'd thunk it.
Also, if really quoting from memory, the author deserves some credit, since it's letter-but-not-punctuation perfect for the stanzas quoted, at least according to this source.
(Well, except for two missing lines in this stanza:
O happy living things ! no tongue
Their beauty might declare:
A spring of love gushed from my heart,
And I blessed them unaware: Sure my kind saint took pity on me,
And I blessed them unaware.)
The clarification is appreciated, I suppose, but I was never maintaining anything different. My point was that for the purposes of collections, which is the use of templates that the parent post was speaking to, the advantages of templates over everything-from-Object is largely compile-time typesafety.
Also, a reference-counted smart pointer won't impress a Java coder such as the parent poster, since garbage collection makes it irrelevant.
I was actually going to bring up Blitz++ as well . . . as an example of when templates are both remarkably useful and mind-bendingly obscure.
I'm not a language designer, but it seems to me that what is needed is some kind of a compromise or hybrid between the intended Java approach to templates/generics and the C++ approach.
If memory serves, Java templates are going to be implemented by erasure, a la GJ. The point behind this is that Java needs bytecode backwards compatibility, so it can't adopt parametric types into the runtime language.
Basically, the compiler will use generics to figure out whether or not operations are guaranteed type-safe and then do the casting for you. (Not sure if it's bright enough to pull off making the cast cheap once it's known to be safe; also not sure if this is safe during reflection. Check out this comment and the discussion surrounding it for more.)
Anyway, if erasure can be made cheap (i.e., without the cost of <dynamic_cast>) then doing (at least basic) templates with erasure could resovle some of the issues with #define templatizing. So you could leave the truly hairy stuff with C++ style templates and simple collection manipulation with erasure-templates.
Now I'll wait for someone to tell me why this is a horrible idea.
But far beyond convenience when typing, the important point is that using templates or generics in collections turns the typesafety of collections into a compile-time check rather than a runtime exception. Which is a Good Thing.
I also worked in a CMM'd company (oh, the temptation to find a new meaning for that acronym).
I saw two major problems with our code reviews, other than the one noted above, which was also present.
First, timeframe issues. Inspections quickly become the enemy (rightly or wrongly) when you have irrational deadlines. Then the deadline causes managers to exert pressure to "streamline" inspections, which, regardless of the intent of the manager, means that inspections get turned into puppet theater, and good engineers learn to hate them. Presto: vicious cycle.
Second, "inspector distance". By this I mean that the available inspectors in most closed-source development models are likely too close to the implementation to inspect it appropriately. They've either (1) written the requirements, (2) consulted with or mentored the developer who actually wrote the code, (3) done the architectural design, etc. (Or all of the above.)
Now, the same thing clearly is true (to a degree) in open-source development, and those people are likely to be the best inspectors available. But I think there's an important psychological effect in inspection-at-a-distance. Reviewing the code of someone who doesn't just sit two cubes away from you with whom you talk about the product over coffee helps open one's eyes.
Does the "for infringement of claims" restrict this only to infringement suits on other patents?
What would happen, for instance, in a firefight over copyright license? Particularly if the suit is over an open-source license where patents are implicated?
Most comments will probably be about what the FSF got exercised over, namely the restriction of the royalty free license to standard implementations.
The summary page mentioned in the article, however, also has an interesting point:
The license may be suspended if the licensee sues the licensor.
(Disclaimer: IANAL, nor have I yet waded through the legalese of the proposal itself -- just the summary)
Does that mean that the following can happen:
Entity A implements a W3C standard, in the process receiving a royalty-free license for some implicated technology from Entity B.
A distributes its implementation.
time passes . ..
A sues B on an unrelated matter, say for example, getting B to abide by the terms of an open-source license.
B suspends A's royalty-free license on the technology in the standard implementation.
All distributions of A's implementation now in license limbo courtesy of a suit on an unrelated matter?
Well, patents aren't strictly for physical items, if by physical you mean "I can poke it." (Which seems to be the case in your post.)
There are good patents for non-tangible things.
The real point, seems to me, is that you can patent how to do something, but you can't patent what it is that gets done. In other words, I can patent how I build an particular type of car engine, but I can't make that patent extend to anything that is self-moving on 4 wheels. (Or at least I shouldn't be able to, because such patents are overbroad.)
If somebody else can build an entirely different thing that does what I do but doesn't do it how I do it, my patent can't cover it.
The problem with software is that the distance between what and how is much, much smaller. So it's easier for a patent applicant to say "This covers everything that even conceivably does what I do, because in the process of describing how I do it, I cover every rational way of doing it."
How do you fix it? Well, as pointed out in the parent post, copyright is the proper area of law to address this. Other issues: companies need to realize that you can't make money by trying to slap a patent on whatever any half-bright programmer can produce.
Maybe we need to make software generally unpatentable, and make exceptions in certain tightly defined areas (highly evolved algorithms, certain kinds of codecs, etc).
Slashdot Mirror
This is what Microsoft either (a) figured out first or (b) did the best job of taking advantage of: three components to pricing.
Therefore, manipulate the perception of value (OpenSource will eat your children!) and make sure that the number of available alternatives approaches zero awful damn quick.
I think, read as a whole, this question constitutes an admission that they are fully committed to the unsustainability of the pricing on Office until one of these three conditions changes.
Ballmer (essentially) said he's fully willing to have the relative pricing of Office compared to a computer not just stay at 1/3 but to have no inherent relationship to the price of anything else (I smell a user-level subscription model . . .) because once you cross conditions 2 and 3, there's no limit.
Time to contribute to OpenOffice, methinks.
Felten says "The new regulations on technology will impose a drag on our technological capabilities, and hence on our productivity." And this is clearly true.
But consider that it's actually true in two ways:
So, obviously, all laws have these two kinds of cost. But the pernicious effect of regulation in spheres of otherwise normal activity (and particularly of regulation as poorly drafted as the DMCA) is that it brings vast swaths of life into the domain of expert legal opinion.
Can we reverse engineer this? Will this interoperability be allowed to work? Even, is my firewall legal?
The chilling effect on development and innovation will be horrible until these developments get filtered through the courts. No one can innovate well in a world where much innovation may be bluntly illegal.
Also, if really quoting from memory, the author deserves some credit, since it's letter-but-not-punctuation perfect for the stanzas quoted, at least according to this source.
(Well, except for two missing lines in this stanza: : :
O happy living things ! no tongue
Their beauty might declare
A spring of love gushed from my heart,
And I blessed them unaware
Sure my kind saint took pity on me,
And I blessed them unaware.)
Also, a reference-counted smart pointer won't impress a Java coder such as the parent poster, since garbage collection makes it irrelevant.
I'm not a language designer, but it seems to me that what is needed is some kind of a compromise or hybrid between the intended Java approach to templates/generics and the C++ approach.
If memory serves, Java templates are going to be implemented by erasure, a la GJ. The point behind this is that Java needs bytecode backwards compatibility, so it can't adopt parametric types into the runtime language.
Basically, the compiler will use generics to figure out whether or not operations are guaranteed type-safe and then do the casting for you. (Not sure if it's bright enough to pull off making the cast cheap once it's known to be safe; also not sure if this is safe during reflection. Check out this comment and the discussion surrounding it for more.)
Anyway, if erasure can be made cheap (i.e., without the cost of <dynamic_cast>) then doing (at least basic) templates with erasure could resovle some of the issues with #define templatizing. So you could leave the truly hairy stuff with C++ style templates and simple collection manipulation with erasure-templates.
Now I'll wait for someone to tell me why this is a horrible idea.
One of the major strengths of templates is to avoid exactly the situation that Java everything-from-Object inheritance causes in collections.
In other words, this code:
gets boring really quickly. Templates in collections saves you all that downcasting.In fact, it's so useful, it's appearing in Java in JDK1.5, courtesy of JSR 14.
But far beyond convenience when typing, the important point is that using templates or generics in collections turns the typesafety of collections into a compile-time check rather than a runtime exception. Which is a Good Thing.
I saw two major problems with our code reviews, other than the one noted above, which was also present.
First, timeframe issues. Inspections quickly become the enemy (rightly or wrongly) when you have irrational deadlines. Then the deadline causes managers to exert pressure to "streamline" inspections, which, regardless of the intent of the manager, means that inspections get turned into puppet theater, and good engineers learn to hate them. Presto: vicious cycle.
Second, "inspector distance". By this I mean that the available inspectors in most closed-source development models are likely too close to the implementation to inspect it appropriately. They've either (1) written the requirements, (2) consulted with or mentored the developer who actually wrote the code, (3) done the architectural design, etc. (Or all of the above.)
Now, the same thing clearly is true (to a degree) in open-source development, and those people are likely to be the best inspectors available. But I think there's an important psychological effect in inspection-at-a-distance. Reviewing the code of someone who doesn't just sit two cubes away from you with whom you talk about the product over coffee helps open one's eyes.
Does the "for infringement of claims" restrict this only to infringement suits on other patents?
What would happen, for instance, in a firefight over copyright license? Particularly if the suit is over an open-source license where patents are implicated?
- The license may be suspended if the licensee sues the licensor.
(Disclaimer: IANAL, nor have I yet waded through the legalese of the proposal itself -- just the summary)Does that mean that the following can happen:
- Entity A implements a W3C standard, in the process receiving a royalty-free license for some implicated technology from Entity B.
- A distributes its implementation.
- time passes . .
.
- A sues B on an unrelated matter, say for example, getting B to abide by the terms of an open-source license.
- B suspends A's royalty-free license on the technology in the standard implementation.
- All distributions of A's implementation now in license limbo courtesy of a suit on an unrelated matter?
How on earth can this be a good idea?There are good patents for non-tangible things.
The real point, seems to me, is that you can patent how to do something, but you can't patent what it is that gets done. In other words, I can patent how I build an particular type of car engine, but I can't make that patent extend to anything that is self-moving on 4 wheels. (Or at least I shouldn't be able to, because such patents are overbroad.)
If somebody else can build an entirely different thing that does what I do but doesn't do it how I do it, my patent can't cover it.
The problem with software is that the distance between what and how is much, much smaller. So it's easier for a patent applicant to say "This covers everything that even conceivably does what I do, because in the process of describing how I do it, I cover every rational way of doing it."
How do you fix it? Well, as pointed out in the parent post, copyright is the proper area of law to address this. Other issues: companies need to realize that you can't make money by trying to slap a patent on whatever any half-bright programmer can produce.
Maybe we need to make software generally unpatentable, and make exceptions in certain tightly defined areas (highly evolved algorithms, certain kinds of codecs, etc).
Was going to moderate the parent of this comment; unfortunately you can't moderate something as "just plain stupid". Honestly. Chick tracts.