I consider it a defect in the HTTP protocol that Slashdotting can happen. Distributed caching ought to have been built into the protocol from the start. Coral is a step in the right direction.
3. Wireless everything. Sounds great until you realize wireless everything will probably conflict with your neighbor's wireless everything and the fact that encryption to keep your wireless everything will be another burden most users won't bother with. And of course, you still need power, so you're either back to wires or you have a lot of batteries.
First, it's possible to actually have a wireless network that works without people having to remember keys. Just use something like the resurrecting duckling protocol described here from a few years back. Basically, you have some contacts on the outside of your box. You touch your device to the contacts, and it securely transmits the network key non-wirelessly. The device then 'imprints' on your network. The also device has a reset switch so that if it ever needs to be, you can put it back in duckling mode so it can get a new key.
But, despite the utter simplicity of this scheme, all the designers of wireless networks feel compelled to design yet another stupid, worthless encryption protocol that doesn't actually work. It's pathetic, and I don't understand why things are that bad.
As for wires...
Well, having a power connecter, but no data connector would be very nice. And for a household wireless network, you could put your amp and speakers in some other part of your house than the computer for a sound system, or any number of other interesting things.
Umm, I don't think this is what's going on, since it seems that almost universally, once you trick the compiler into think it really is on an Intel CPU, you get a nice speedup on AMD and no bugs. I've seen that story repeated by 4 or 5 different people talking about their own codebases now. So, your scenario really doesn't make sense.
And even if it's what happened, it still isn't acceptable. The measure of abuse of monpoly power is the effect on the marketplace, not the intent.
I suggest pressuring Intel with a class action lawsuit. I'm certain it's the only thing they'll listen to, and I doubt they'll even listen to that. You'll probably have to win your lawsuit.
This completely misses the point and is a very stupid observation. They deliberately, with forethought and malice went to extra effort make their compiler perform badly with CPUs they don't want to sell well in the marketplace. This includes CPUs from their own line as well as CPUs from competitors.
This isn't a matter of 'supporting' someone else's CPU. This is a matter of making the extra effort to purposely cripple your software for someone else's CPU. That's not OK. If you think it is, I have a nice butt-plug, rubber suit, and rubber ball gag for you so you can wrap yourself in a nice package and submit yourself for the pleasure and abuse of a monopoly of your choice.
Reasonable amount of care meaning that you don't copy the auto_ptr out into another auto_ptr.
I actually like the default-constructor + swap idiom a little more than assignment or copy-construction, though they seem more obvious. I think it can be more efficient, and I think it matches the semantic intent a little better. I think it makes containers more complex to code only in that the standard conventions aren't used in favor of something a little odd. I don't think it adds any extra code paths or exceptional cases. In fact, I think it reduces them.
Here is what I mean by default construction + swap...
T x(y);
becomes...
T x; x.swap(y);
and...
T x; x = y;
becomes...
T x; x.swap(y);
Containers don't really have to make copies of objects. They just need to move them around. The swap idiom is fine for this purpose. If cotnainers changed to use it instead of assignment or the copy constructor, they would work fine with auto_ptr.
If you don't pass them by reference, you get what you deserve. They are not general purpose smart pointers.
I don't like the reference counted smart pointers because I think they're more expensive than what they're worth most of the time, and I think they encourage sloppy programming. If I want to program sloppily, I'll use a forgiving scripting language like Python.
But, if the vector class were re-done to not use the assignment operator or copy constructor for the contained objects, it could work just great with auto_ptr if you exercised a reasonable amount of care.
Maybe, instead, it would just be better to add a template parameter that allowed you to specify that the vector owned the pointers it contained. But I think my solution is a bit more elegant.
I actually really like auto_ptr. I think it should be a rule that containers use default constructor + 'swap' when they need to move an object in memory instead of the typical copy constructor or default constructor followed by assignment operator. That would let auto_ptr work just fine with them, and make them more resilient in the face of exceptions.
First, I don't think it matters if the size of a method pointer is random. What's the size of a structure containing a char and an int? It could be a wide range of values, and it's implementation dependent.
The boost library gives you delegates that work just fine.
Yes, the syntax and semantics are horribly ugly. But, they are well defined, and aren't implementation dependent. Now the exact size of the pointer is implementation dependent, but you shouldn't be caring what the size is anyway.
And why would anybody want a monopoly like that anyway? Seems to me that a business model of making good things for your customers is a much better model for everybody.
That's line that's much finer than you make it out to be with your simple statement. Especially since what's considered a means to commit piracy tends to be whatever people use to do it. Technically, since Linux is used by some file-swappers, it could be considered a means to commit piracy.
Consider a sane company that truly believes open source is a problem rather than a useful tool. If you face them with litigation over a GPL violation then the logical response is not to embrace open source, it's to do the minimum they have to to comply with the GPL while working on an exit strategy, whether that involves in-house development, licensing a for-pay closed-source package, or terminating the product line. Those are all rational responses.
So... what's going to happen if I try and compel cooperation is that some companies who aren't interested in cooperation will use a different piece of software. If I don't try and compel cooperation, then some of them will use my software and not give me anything for it.
My interest is not getting the source code the company writes. My interest is in not helping out someone who isn't willing to help me out in return. I don't want to give them the benefit if I don't get the reward. Plain and simple. You seem to be under the misapprehension that Open Source is pure altruism, and it is not.
Your rules are not the rules of the Open Source game. The crucial difference is that people get to reap the benefits of years of Open Source development without giving anything in return. That's not a bargain I'm willing to enter into. It is the reason why I refuse to use BSD, even though (until recently) I considered it in almost every way to be technically superior to Linux.
The GPL is the bargain that states "If you use my code, you have to let me use the changes you make to it.". That's the bargain that accurately represents my ultimate desires and provides a fair trade for my work.
I would sued the police for harassment. That's not much better than breaking your headlight then writing you a ticket for the broken headlight. It's petty and mean, and just proved the point you were making in your article.
Corporations face those kinds of risks every day. It seems like every day some corporation has a PR hassle over something they've done. So, I don't think that's an inherent risk with GPL code.
I distrust any voluntary cooperation by corporations without any teeth. No sane corporation would enter into a contract that did so little to safeguard their interests as the BSD license does, and I don't think we should either.
If they want to play the game, they can play by our rules.
I'm not sure why I found this attitude, especially their willingness to openly talk about it, so surprising.
It's because the laws don't match people's expectations, but because it involves sex and children, rational public discourse is generally not allowed.
And, the prosecutor is wrong. Juries are supposed to side with their conscience and justice, not with the law. Look up 'jury nullification' sometime. Jury nullification is the last defense against bad law, and it's a big reason that people being prosecuted under criminal statutes have a right to a trial by jury.
Or 19 year olds who've committed statuatory rape by having sex with their 17 year old significant other's. The laws about that kind of thing make no distinction.
Strong property rights, yes, I agree. And this ruling is awful. But 'intellectual property' is not really property, and I hope that you don't let your opinion about standard forms of property cloud your thinking about 'intellectual property'.
Real property is naturally rivalrous and exclusive. Neither of those qualities apply to 'intellectual property' until you add in a whole bunch of laws and people with the muscle to enforce them.
Gee, I thought the free market was supposed to encourage things that were good for customers. It doesn't seem like crippling competitors by taking away features helps anybody but the company that does it. Sounds like a market failure to me.
Slashdot Mirror
I consider it a defect in the HTTP protocol that Slashdotting can happen. Distributed caching ought to have been built into the protocol from the start. Coral is a step in the right direction.
First, it's possible to actually have a wireless network that works without people having to remember keys. Just use something like the resurrecting duckling protocol described here from a few years back. Basically, you have some contacts on the outside of your box. You touch your device to the contacts, and it securely transmits the network key non-wirelessly. The device then 'imprints' on your network. The also device has a reset switch so that if it ever needs to be, you can put it back in duckling mode so it can get a new key.
But, despite the utter simplicity of this scheme, all the designers of wireless networks feel compelled to design yet another stupid, worthless encryption protocol that doesn't actually work. It's pathetic, and I don't understand why things are that bad.
As for wires...
Well, having a power connecter, but no data connector would be very nice. And for a household wireless network, you could put your amp and speakers in some other part of your house than the computer for a sound system, or any number of other interesting things.
This isn't going to be a jury trial.
Umm, I don't think this is what's going on, since it seems that almost universally, once you trick the compiler into think it really is on an Intel CPU, you get a nice speedup on AMD and no bugs. I've seen that story repeated by 4 or 5 different people talking about their own codebases now. So, your scenario really doesn't make sense.
And even if it's what happened, it still isn't acceptable. The measure of abuse of monpoly power is the effect on the marketplace, not the intent.
I suggest pressuring Intel with a class action lawsuit. I'm certain it's the only thing they'll listen to, and I doubt they'll even listen to that. You'll probably have to win your lawsuit.
This completely misses the point and is a very stupid observation. They deliberately, with forethought and malice went to extra effort make their compiler perform badly with CPUs they don't want to sell well in the marketplace. This includes CPUs from their own line as well as CPUs from competitors.
This isn't a matter of 'supporting' someone else's CPU. This is a matter of making the extra effort to purposely cripple your software for someone else's CPU. That's not OK. If you think it is, I have a nice butt-plug, rubber suit, and rubber ball gag for you so you can wrap yourself in a nice package and submit yourself for the pleasure and abuse of a monopoly of your choice.
Reasonable amount of care meaning that you don't copy the auto_ptr out into another auto_ptr.
I actually like the default-constructor + swap idiom a little more than assignment or copy-construction, though they seem more obvious. I think it can be more efficient, and I think it matches the semantic intent a little better. I think it makes containers more complex to code only in that the standard conventions aren't used in favor of something a little odd. I don't think it adds any extra code paths or exceptional cases. In fact, I think it reduces them.
Here is what I mean by default construction + swap...
becomes...
and...
becomes...
Containers don't really have to make copies of objects. They just need to move them around. The swap idiom is fine for this purpose. If cotnainers changed to use it instead of assignment or the copy constructor, they would work fine with auto_ptr.
If you don't pass them by reference, you get what you deserve. They are not general purpose smart pointers.
I don't like the reference counted smart pointers because I think they're more expensive than what they're worth most of the time, and I think they encourage sloppy programming. If I want to program sloppily, I'll use a forgiving scripting language like Python.
But, if the vector class were re-done to not use the assignment operator or copy constructor for the contained objects, it could work just great with auto_ptr if you exercised a reasonable amount of care.
Maybe, instead, it would just be better to add a template parameter that allowed you to specify that the vector owned the pointers it contained. But I think my solution is a bit more elegant.
I actually really like auto_ptr. I think it should be a rule that containers use default constructor + 'swap' when they need to move an object in memory instead of the typical copy constructor or default constructor followed by assignment operator. That would let auto_ptr work just fine with them, and make them more resilient in the face of exceptions.
First, I don't think it matters if the size of a method pointer is random. What's the size of a structure containing a char and an int? It could be a wide range of values, and it's implementation dependent.
The boost library gives you delegates that work just fine.
Yes, the syntax and semantics are horribly ugly. But, they are well defined, and aren't implementation dependent. Now the exact size of the pointer is implementation dependent, but you shouldn't be caring what the size is anyway.
Yes. :-) I'm even in town right now. I came here for a week to visit with friens and attend Convergence.
Heck, even Christians! Oh, wait...
That's because it's true. Microsoft is the bane of the IT industry, and I've felt very strongly that way ever since I first used Windows 3.1.
And why would anybody want a monopoly like that anyway? Seems to me that a business model of making good things for your customers is a much better model for everybody.
That's line that's much finer than you make it out to be with your simple statement. Especially since what's considered a means to commit piracy tends to be whatever people use to do it. Technically, since Linux is used by some file-swappers, it could be considered a means to commit piracy.
My interest is not getting the source code the company writes. My interest is in not helping out someone who isn't willing to help me out in return. I don't want to give them the benefit if I don't get the reward. Plain and simple. You seem to be under the misapprehension that Open Source is pure altruism, and it is not.
Your rules are not the rules of the Open Source game. The crucial difference is that people get to reap the benefits of years of Open Source development without giving anything in return. That's not a bargain I'm willing to enter into. It is the reason why I refuse to use BSD, even though (until recently) I considered it in almost every way to be technically superior to Linux.
The GPL is the bargain that states "If you use my code, you have to let me use the changes you make to it.". That's the bargain that accurately represents my ultimate desires and provides a fair trade for my work.
I would sued the police for harassment. That's not much better than breaking your headlight then writing you a ticket for the broken headlight. It's petty and mean, and just proved the point you were making in your article.
So, what kind of country are you now that you have to watch what you say to avoid legal persecution?
What it tells me is that the 'advocating piracy' standard is perilously close to being a violation of the first amendment.
Corporations face those kinds of risks every day. It seems like every day some corporation has a PR hassle over something they've done. So, I don't think that's an inherent risk with GPL code.
I distrust any voluntary cooperation by corporations without any teeth. No sane corporation would enter into a contract that did so little to safeguard their interests as the BSD license does, and I don't think we should either.
If they want to play the game, they can play by our rules.
It's because the laws don't match people's expectations, but because it involves sex and children, rational public discourse is generally not allowed.
And, the prosecutor is wrong. Juries are supposed to side with their conscience and justice, not with the law. Look up 'jury nullification' sometime. Jury nullification is the last defense against bad law, and it's a big reason that people being prosecuted under criminal statutes have a right to a trial by jury.
Or 19 year olds who've committed statuatory rape by having sex with their 17 year old significant other's. The laws about that kind of thing make no distinction.
Strong property rights, yes, I agree. And this ruling is awful. But 'intellectual property' is not really property, and I hope that you don't let your opinion about standard forms of property cloud your thinking about 'intellectual property'.
Real property is naturally rivalrous and exclusive. Neither of those qualities apply to 'intellectual property' until you add in a whole bunch of laws and people with the muscle to enforce them.
Gee, I thought the free market was supposed to encourage things that were good for customers. It doesn't seem like crippling competitors by taking away features helps anybody but the company that does it. Sounds like a market failure to me.