A boycott can make a difference for a company like Amazon. Amazon doesn't have anything special going for it over any other book selling site. You don't have to give anything up to not go there. You can even just look at the reviews on Amazon, and then pop somewhere else for the actual purchase.
As far as patents go, the courts are predisposed to trust the PTO. If you can show prior art, you can invalidate a patent. It's tough to invalidate based on obviousness. The courts presume that the PTO already considered obviousness. We know they didn't, but the court doesn't.
If you have prior art before September 1997, great. Send it to Barnes & Noble.
Your life will be consumed with inane and demoralizing questions like "how to I run make?"
I've faced these sorts of questions, and I don't mean to minimize the problem. However, there is a solution: learn to be unhelpful. Learn the words ``I can help you with questions about X, but I'm afraid I can't help you with that question. Please ask somebody else. Sorry.'' Most of the time, they'll go ask somebody else, and they won't even think bad thoughts about you.
They don't have to support 10 thousand different compilers, repeatedly tell people not to use -O99 when they compile, or explain to people that you need version x.y of the foo library.
The way to handle these sorts of questions is through a FAQ. Then reply to people saying ``please see the FAQ at....''
In other words, these problems can be solved, once you stop trying to solve problems merely because you know how to solve them. Never forget that your time is your own. By all means give it to other people when you can, but don't ignore the cost to yourself.
It's possible to use CVS to check in code without others seeing it, but it's awkward.
One approach is to use a tag, e.g., `stable', and have others do cvs co -r stable FILE. This will become a sticky tag in their working directory. If you check in changes, others will not see them until you change the tag. When you do change it, they will get the new version when they update. Of course, this only works if you are the only person working on that file.
Another approach is to use a branch. Then you merge the branch into the mainline when you are done with your development, using cvs co -j.
Exclusive checkouts is a bug, not a feature. Once you've tried working without them, you'll never go back.
However, if you really want exclusive checkouts, you can use cvs watch and cvs edit.
CVS doesn't merge binary files. If you mark a file as binary, CVS will reject a conflict, rather than attempting to merge it. You must then resolve the conflict manually.
CVS and RCS aren't really comparable, although CVS is built on top of RCS. RCS provides revision control on a single file. CVS provides concurrent development on an entire repository.
It may make sense for Apple to be sold, but it doesn't make sense for anybody to actually buy it, at least not the companies mentioned in the article.
Disney and Sony are in the entertainment business. Why would they want to get into the niche computer manufacturer business? They don't need the technology. They don't need the cash--and Apple's cash flow is a hardly a sure thing, particularly compared to Disney's. Nobody is going to buy a big company like Apple just because they think the iMac is cool.
Selling a company like Apple only happens if it looks good to both the buyer and the seller. Disney buying Apple looks pretty good for Apple, but it doesn't look that good for Disney.
Although hackers operate in a gift culture, it is radically different from the gift cultures studied in anthropology courses. Traditional gift cultures give away material goods; hackers give away information, which as we all know is the gift that can be given to somebody else without losing the use of it yourself. The true gift of the hacker is the time spent programming, not the actual goods given away.
But giving away time needs no special explanation. Many people volunteer for charities, write letters to the editor or/., or just spend time on their on personal hobbies. After all, you have to spend the day somehow; it would be absurd to analyze's everybody's hobbies in terms of their contribution to reproductive success. Hackers are a very unusual case in that the time spent hacking produces an object with near-magical properties: it can be replicated an unbounded number of times, and it can bring a direct benefit to other people.
There is no need to use special psychology to explain the hacker culture. The key is to understand the unprecedented nature of the medium within which they work.
The author makes a detour into evolutionary psychology to attempt to explain gift cultures. Here he makes the usual mistake of thinking that all human behaviour can be explained with reference to reproduction. This is implausible on the face of it, as can be seen by the existence of strict homosexuals and monasteries. Humans, conscious thinking beings, have a much wider range of motivations than the simple desire to reproduce.
Even in the terms of evolutionary psychology, the reasoning is suspect. The sexual selection strategy of peacocks is indeed interesting and instructive (although I'll note that Darwin anticipated sexual selection strategies, so the comment that the peacocks had not read the Origin of Species misstates Darwin's understanding of the idea he invented). However, when it comes to the example of the hunter (presumed to be male), it's hardly obvious that women are selecting good hunters on the basis of respect. A good hunter can do well for the very obvious reason that he is a good hunter, quite apart from the benefits of respect. Women might prefer to have children with such a hunter simply because those children would in turn be good hunters and would therefore do well, to say nothing of the benefits of having a good hunter caring for the children. Even if we buy into the notion that reproduction is the main determinant of human behaviour, this example gives very little reason to think that respect is a primary sexual selection characteristic.
The author makes a detour into evolutionary psychology to attempt to explain gift cultures. Here he makes the usual mistake of thinking that all human behaviour can be explained with reference to reproduction. This is implausible on the face of it, as can be seen by the existence of strict homosexuals and monasteries. Humans, conscious thinking beings, have a much wider range of motivations than the simple desire to reproduce.
Even in the terms of evolutionary psychology, the reasoning is suspect. The sexual selection strategy of peacocks is indeed interesting and instructive (although I'll note that Darwin anticipated sexual selection strategies, so the comment that the peacocks had not read the Origin of Species misstates Darwin's understanding of the idea he invented). However, when it comes to the example of the hunter (presumed to be male), it's hardly obvious that women are selecting good hunters on the basis of respect. A good hunter can do well for the very obvious reason that he is a good hunter, quite apart from the benefits of respect. Women might prefer to have children with such a hunter simply because those children would in turn be good hunters and would therefore do well, to say nothing of the benefits of having a good hunter caring for the children. Even if we buy into the notion that reproduction is the main determinant of human behaviour, this example gives very little reason to think that respect is a prim
The author argues that selection for respect helped lead to potlatch cultures. Potlatch cultures developed in an unusual area with a large amount of resources available for easy gathering. It's interesting to note that the potlatch cultures did not develop traditional agriculture, but were nevertheless able to create large settled communities, simply because the natural resources were so abundant.
Just as we in the U.S. prefer to elect a president who keeps the economy running strong, the potlatch culture villages preferred leaders who were able to supply their needs well. In a culture of abundance, it became possible for a leader to demonstrate that ability by showing that he had a super-abundance--so much stuff that he had no need for it, and could actually destroy it and still be well off. Clearly somebody that well off would be a good supplier.
Of course, that explanation is just as simple-minded as the one based on evolutionary psychology. In reality, people's motivations are complex, and can not be so easily analyzed. The point is that there is no need to refer human actions back to reproductive strategies; other explanations serve just as well.
The fragmentation of Unix may indeed be its greatest technical strength. However, it is a great weakness in the mass market, where people prefer to learn only one system. Windows isn't the most widely-used OS because it's technically superior.
Fortunately, there are various solutions which preserve technical competition with consumer standardization. I think that either the branding or open source approaches I mentioned could work well.
As far as your concerns about Windows gaining potency, I personally prefer to use Unix, but that doesn't mean that I want Windows to be bad. It's not a zero-sum game in which a gain for Windows is a loss for Unix.
Remember what happened to Unix? Each Unix company developed their own Unix variant. They were all slightly different. Moving programs back and forth became so difficult that there is a GNU package specifically designed to handle it (autoconf).
If there were two or more owners of Windows, the same thing would happen. In the case of Windows, as the market split, people would stick with the known vendor: Microsoft.
I don't think this solution is any solution at all.
A better approach along the same lines would be to create a standards body with the ability to brand versions of Windows. Require that all Microsoft versions meet the branding. For anybody else, branding would be optional. Let the organization evolve the brand over time. However, this is quite complex, and it's hard to imagine that the court could create an organization which could adapt quickly enough and fairly enough to the rapidly moving market.
I think the simplest solution would be to require Microsoft to license the entire Windows OS under some open source licence. That would give Microsoft a choice: bundle it in and make it open, or keep it proprietary and don't bundle it.
I haven't read the anniversary edition, only the original. However, I think one of the most striking things about this book is how relevant it still is. Most software organizations still do not practice the approaches suggested in this 25 year old book: egoless programming, code reviews, etc.
The software industry still has very little understanding of how software is actually created. That contributes to the constant schedule slipping and buggy releases.
This book could have helped to solve the problem. Unfortunately, it turned out to be just a voice in the wilderness. Perhaps this new edition will help remind people that the problems of 25 years ago are still with us today.
Slashdot Mirror
I just checked, and it looks like Slashdot will still put up links to Amazon.
Is Slashdot going to participate in the boycott by removing those links? Why or why not?
Not that I'm encouraging hasty action. Perhaps Amazon will back down on this, as they backed down (somewhat) on their hidden advertising.
A boycott can make a difference for a company like Amazon. Amazon doesn't have anything special going for it over any other book selling site. You don't have to give anything up to not go there. You can even just look at the reviews on Amazon, and then pop somewhere else for the actual purchase.
As far as patents go, the courts are predisposed to trust the PTO. If you can show prior art, you can invalidate a patent. It's tough to invalidate based on obviousness. The courts presume that the PTO already considered obviousness. We know they didn't, but the court doesn't.
If you have prior art before September 1997, great. Send it to Barnes & Noble.
Your life will be consumed with inane and demoralizing questions like "how to I run make?"
I've faced these sorts of questions, and I don't mean to minimize the problem. However, there is a solution: learn to be unhelpful. Learn the words ``I can help you with questions about X, but I'm afraid I can't help you with that question. Please ask somebody else. Sorry.'' Most of the time, they'll go ask somebody else, and they won't even think bad thoughts about you.
They don't have to support 10 thousand different compilers, repeatedly tell people not to use -O99 when they compile, or explain to people that you need version x.y of the foo library.
The way to handle these sorts of questions is through a FAQ. Then reply to people saying ``please see the FAQ at ....''
In other words, these problems can be solved, once you stop trying to solve problems merely because you know how to solve them. Never forget that your time is your own. By all means give it to other people when you can, but don't ignore the cost to yourself.
It's possible to use CVS to check in code without others seeing it, but it's awkward.
One approach is to use a tag, e.g., `stable', and have others do cvs co -r stable FILE. This will become a sticky tag in their working directory. If you check in changes, others will not see them until you change the tag. When you do change it, they will get the new version when they update. Of course, this only works if you are the only person working on that file.
Another approach is to use a branch. Then you merge the branch into the mainline when you are done with your development, using cvs co -j.
Exclusive checkouts is a bug, not a feature. Once you've tried working without them, you'll never go back.
However, if you really want exclusive checkouts, you can use cvs watch and cvs edit.
CVS doesn't merge binary files. If you mark a file as binary, CVS will reject a conflict, rather than attempting to merge it. You must then resolve the conflict manually.
CVS and RCS aren't really comparable, although CVS is built on top of RCS. RCS provides revision control on a single file. CVS provides concurrent development on an entire repository.
It may make sense for Apple to be sold, but it doesn't make sense for anybody to actually buy it, at least not the companies mentioned in the article.
Disney and Sony are in the entertainment business. Why would they want to get into the niche computer manufacturer business? They don't need the technology. They don't need the cash--and Apple's cash flow is a hardly a sure thing, particularly compared to Disney's. Nobody is going to buy a big company like Apple just because they think the iMac is cool.
Selling a company like Apple only happens if it looks good to both the buyer and the seller. Disney buying Apple looks pretty good for Apple, but it doesn't look that good for Disney.
Although hackers operate in a gift culture, it is radically different from the gift cultures studied in anthropology courses. Traditional gift cultures give away material goods; hackers give away information, which as we all know is the gift that can be given to somebody else without losing the use of it yourself. The true gift of the hacker is the time spent programming, not the actual goods given away.
But giving away time needs no special explanation. Many people volunteer for charities, write letters to the editor or /., or just spend time on their on personal hobbies. After all, you have to spend the day somehow; it would be absurd to analyze's everybody's hobbies in terms of their contribution to reproductive success. Hackers are a very unusual case in that the time spent hacking produces an object with near-magical properties: it can be replicated an unbounded number of times, and it can bring a direct benefit to other people.
There is no need to use special psychology to explain the hacker culture. The key is to understand the unprecedented nature of the medium within which they work.
The author makes a detour into evolutionary psychology to attempt to explain gift cultures. Here he makes the usual mistake of thinking that all human behaviour can be explained with reference to reproduction. This is implausible on the face of it, as can be seen by the existence of strict homosexuals and monasteries. Humans, conscious thinking beings, have a much wider range of motivations than the simple desire to reproduce.
Even in the terms of evolutionary psychology, the reasoning is suspect. The sexual selection strategy of peacocks is indeed interesting and instructive (although I'll note that Darwin anticipated sexual selection strategies, so the comment that the peacocks had not read the Origin of Species misstates Darwin's understanding of the idea he invented). However, when it comes to the example of the hunter (presumed to be male), it's hardly obvious that women are selecting good hunters on the basis of respect. A good hunter can do well for the very obvious reason that he is a good hunter, quite apart from the benefits of respect. Women might prefer to have children with such a hunter simply because those children would in turn be good hunters and would therefore do well, to say nothing of the benefits of having a good hunter caring for the children. Even if we buy into the notion that reproduction is the main determinant of human behaviour, this example gives very little reason to think that respect is a primary sexual selection characteristic.
The author makes a detour into evolutionary psychology to attempt to explain gift cultures. Here he makes the usual mistake of thinking that all human behaviour can be explained with reference to reproduction. This is implausible on the face of it, as can be seen by the existence of strict homosexuals and monasteries. Humans, conscious thinking beings, have a much wider range of motivations than the simple desire to reproduce.
Even in the terms of evolutionary psychology, the reasoning is suspect. The sexual selection strategy of peacocks is indeed interesting and instructive (although I'll note that Darwin anticipated sexual selection strategies, so the comment that the peacocks had not read the Origin of Species misstates Darwin's understanding of the idea he invented). However, when it comes to the example of the hunter (presumed to be male), it's hardly obvious that women are selecting good hunters on the basis of respect. A good hunter can do well for the very obvious reason that he is a good hunter, quite apart from the benefits of respect. Women might prefer to have children with such a hunter simply because those children would in turn be good hunters and would therefore do well, to say nothing of the benefits of having a good hunter caring for the children. Even if we buy into the notion that reproduction is the main determinant of human behaviour, this example gives very little reason to think that respect is a prim
The author argues that selection for respect helped lead to potlatch cultures. Potlatch cultures developed in an unusual area with a large amount of resources available for easy gathering. It's interesting to note that the potlatch cultures did not develop traditional agriculture, but were nevertheless able to create large settled communities, simply because the natural resources were so abundant.
Just as we in the U.S. prefer to elect a president who keeps the economy running strong, the potlatch culture villages preferred leaders who were able to supply their needs well. In a culture of abundance, it became possible for a leader to demonstrate that ability by showing that he had a super-abundance--so much stuff that he had no need for it, and could actually destroy it and still be well off. Clearly somebody that well off would be a good supplier.
Of course, that explanation is just as simple-minded as the one based on evolutionary psychology. In reality, people's motivations are complex, and can not be so easily analyzed. The point is that there is no need to refer human actions back to reproductive strategies; other explanations serve just as well.
The fragmentation of Unix may indeed be its greatest technical strength. However, it is a great weakness in the mass market, where people prefer to learn only one system. Windows isn't the most widely-used OS because it's technically superior.
Fortunately, there are various solutions which preserve technical competition with consumer standardization. I think that either the branding or open source approaches I mentioned could work well.
As far as your concerns about Windows gaining potency, I personally prefer to use Unix, but that doesn't mean that I want Windows to be bad. It's not a zero-sum game in which a gain for Windows is a loss for Unix.
Remember what happened to Unix? Each Unix company developed their own Unix variant. They were all slightly different. Moving programs back and forth became so difficult that there is a GNU package specifically designed to handle it (autoconf).
If there were two or more owners of Windows, the same thing would happen. In the case of Windows, as the market split, people would stick with the known vendor: Microsoft.
I don't think this solution is any solution at all.
A better approach along the same lines would be to create a standards body with the ability to brand versions of Windows. Require that all Microsoft versions meet the branding. For anybody else, branding would be optional. Let the organization evolve the brand over time. However, this is quite complex, and it's hard to imagine that the court could create an organization which could adapt quickly enough and fairly enough to the rapidly moving market.
I think the simplest solution would be to require Microsoft to license the entire Windows OS under some open source licence. That would give Microsoft a choice: bundle it in and make it open, or keep it proprietary and don't bundle it.
I haven't read the anniversary edition, only the original. However, I think one of the most striking things about this book is how relevant it still is. Most software organizations still do not practice the approaches suggested in this 25 year old book: egoless programming, code reviews, etc.
The software industry still has very little understanding of how software is actually created. That contributes to the constant schedule slipping and buggy releases.
This book could have helped to solve the problem. Unfortunately, it turned out to be just a voice in the wilderness. Perhaps this new edition will help remind people that the problems of 25 years ago are still with us today.