"The point I'm trying to make is that developers have always had to figure out how to get the most out of new CPUs. Optimizing for modern CPUs is very, very tricky even ignoring multi-core or multi-thread issues. For example, you can't just add up the number of clock cycles for each instruction on any modern x86 or x86-64 CPU. You can't easily anticipate cache effects, mispredicted branched, and any number of other things."
For the reasons you state, I'd say that such optimization is a fool's errand. It also shows why you shouldn't try to create real-time software to run on x86 system.
"Multi-CPU systems started becoming common in the mid 1990s so developers being a decade behind the times is a little embarrassing and there are many situations where the task is not completly serial."
So after a decade of poor adoption on the part of software developers, the chip makers have ignored the fact that the wisdom of the (programming) mob indicates that multi-processing is not an attractive solution. Chip makers have known for more than two decades that they were going to run into physical limits eventually using the current technology, but opted for milking the 1970's model as long as possible rather than developing new technologies that might lead to much better single-core performance.
"What good is a 32-bit CPU without developers making 32-bit code? What good are MMX or SSE instructions if developers don't use them?"
At the application level it's often not necessary to do something special to run 32-bit software.
The point is that the performance improvements of the past were primarily intended to boost new processor sales rather than do something for software developers. The fact that legacy software ran faster on a new processor is a great way to get people to upgrade their hardware, but really has no effect on software sales.
They're supposed to be the ones to optimize this stuff. Oh well, I guess they'll have to come up with some new goof-ball interview questions. "See, there's a swarm of bees passing through a cloud..."
Instead of developing single-core chips with better performance, chip makers are now making multicore machines and expecting developers to provide the extra performance.
Without the work of developers, multi-core chips will be like the extra transistors in transistor radios in the 1960s: good for marketing but functionally useless.
Your original statement was: "If you go back before 1983 you'll see source used to be open by default."
Unix is just one OS that was invented long after computers were in common use, so it can't be used as evidence to prove your statement. The primary reason why Unix ended up being "open" was because of the poor IP management that ATT did. It obviously wasn't ATT intention or there wouldn't have been any reason for a settlement.
Even in those cases where source code was supplied, it was paid for and permission to alter it wasn't necessarily given. It wasn't "free" in the way RMS defined it. In any case, there was a lot of code written in assembly prior to 1983 so those couldn't be compiled. In addition in the 1960's most computer customers rented their computers and many of them didn't even employ programmers.
If you think about it, RMS had little experience in the computer business at the time he created GNU and doesn't have much more now.
The only way you can fully follow your own agenda is to work by yourself or be dictating leader. Note that the license you use is not an issue. Anyone who has looked at the rules for contributing to an open source project can see that they'll be following somebody else's agenda.
I can't say for sure that there hasn't always some small amount of free software around, but it wasn't common in the early days for the computer industry to provide source code to paying customers and certainly it wasn't provided to anybody who was interested.
I have no doubt that a 1983 level of effort in open source is quite sustainable, the question is whether a level of effort necessary to continue open source's market share is sustainable.
The monopoly product is supposed to promote the new product, not the other way around. So, if MS made it impossible to run iTunes on Windows, that could be considered an illegal tie-in to promote the Zune.
It's not illegal for a monopoly to fund a new product category by using the profits of their monopoly market. It would only be illegal if there was some technological tie-in between the products that made competing products in the new market be at a disadvantage.
Reading Slasdot, you could get the impression that from now on everything MS does violates antitrust laws. As a practical matter this chapter of MS history is about closed and in the future the argument that "it's different because MS is a monopoly" is going to be defunct.
"RMS is an idealist, whilst the people behind the CC organization are pragmatists."
Besides, if RMS was so idealistic he wouldn't have allowed you to modify the code for internal use without making the changes public. Just because you're not redistributing the code doesn't mean that the code doesn't want to be "free". This was a pragmatic compromise to lure organizations into using GPL'd code.
"I'd submit that creative freedom is more important to talented people, however. Speaking anecdotally, although all levels of talent are represented, I've encountered a much higher proportion of very talented programmers in Open Source than I have at work in the commercial/proprietary world."
I guess I've never seen a significant relationship between the desire for creative freedom and talent. I guess I've met too many people who crave creative freedom while those around them are rolling their eyes behind their back.
As far as your own observations about open vs. closed development, it depends on how much experience you have and what kind of people you've worked with. Certainly if you're comparing closed source IT folks with open source developers, it's not a fair comparison (I'm not saying you have).
"You don't believe that talented people gravitate towards environments which offer them creative freedom?"
I don't think that talented people are unique in their desire to have it their own way, no. Furthermore, a group of people who all get to do whatever they individually want to do, don't make a great team. That's true for both open and closed source development.
"But Open Source gives you the freedom to do things the way you want to, and it's a good way to interact with a population of other talented coders, both of which are generally hard to get consistently in the commercial world."
Sure, because a group of people who all get to do things the way they want to do it are known to be more talented and accomplished than an organized team creating products for paying customers.
"If you instead rewrite the code, you face the possible claim that your new code is a derivative work which is also covered by the original author's copyright. The "cleanroom" approach is sometimes used to avoid this."
If there's no common code I don't see how anybody could successfully claim it as a derivative work. It's not like writing a story about a boy with a scar who attends a 7 year wizard school.
In addition, the cleanroom approach is really more relevent to a trade secret - it proves that you had no knowledge of the secret. If somehow you accidently recreated somebody else's copyrighted work without any knowledge of the original, I doubt that you could use that as a defense.
"Some apps are too heavy for the hardware, that's not linux's fault but rather the individual apps and the hardware. A program designed for a supercomputer with a terabyte of ram won't work very well on even a high end gaming pc."
In other words, the claim that Linux (or Windows, or some other OS) runs at all these different scales isn't really meaningful in the general case. If your cell phone was the size of a mainframe, it might be able to run enterprise applications by mere recompiling, but since it isn't - who cares?
"The poster child for the situation is Netscape, but Microsoft has "done a Netscape" on lots of other startups"
Ironically, if MS hadn't been antitrust bait and Netscape had to be sold for its value as a company rather than its value as a MS plantiff, the founders would have made a lot less money. Jim Clark is known for losing interest in his starups once they become succesful and that's probably part of the reason Netscape was slow to upgrade their browser and failed to successfully expand beyond the narrow browser market.
The stability of any of the real mode Windows versions really depends on what applications you run. Lotus ccmail would crash Windows 95,98,ME on a regular basis. On Windows NT and beyond, it would only crash itself.
Slashdot Mirror
"The point I'm trying to make is that developers have always had to figure out how to get the most out of new CPUs. Optimizing for modern CPUs is very, very tricky even ignoring multi-core or multi-thread issues. For example, you can't just add up the number of clock cycles for each instruction on any modern x86 or x86-64 CPU. You can't easily anticipate cache effects, mispredicted branched, and any number of other things."
For the reasons you state, I'd say that such optimization is a fool's errand. It also shows why you shouldn't try to create real-time software to run on x86 system.
"Multi-CPU systems started becoming common in the mid 1990s so developers being a decade behind the times is a little embarrassing and there are many situations where the task is not completly serial."
So after a decade of poor adoption on the part of software developers, the chip makers have ignored the fact that the wisdom of the (programming) mob indicates that multi-processing is not an attractive solution. Chip makers have known for more than two decades that they were going to run into physical limits eventually using the current technology, but opted for milking the 1970's model as long as possible rather than developing new technologies that might lead to much better single-core performance.
"What good is a 32-bit CPU without developers making 32-bit code? What good are MMX or SSE instructions if developers don't use them?"
At the application level it's often not necessary to do something special to run 32-bit software.
The point is that the performance improvements of the past were primarily intended to boost new processor sales rather than do something for software developers. The fact that legacy software ran faster on a new processor is a great way to get people to upgrade their hardware, but really has no effect on software sales.
They're supposed to be the ones to optimize this stuff. Oh well, I guess they'll have to come up with some new goof-ball interview questions. "See, there's a swarm of bees passing through a cloud ..."
Instead of developing single-core chips with better performance, chip makers are now making multicore machines and expecting developers to provide the extra performance.
Without the work of developers, multi-core chips will be like the extra transistors in transistor radios in the 1960s: good for marketing but functionally useless.
Your original statement was: "If you go back before 1983 you'll see source used to be open by default."
Unix is just one OS that was invented long after computers were in common use, so it can't be used as evidence to prove your statement. The primary reason why Unix ended up being "open" was because of the poor IP management that ATT did. It obviously wasn't ATT intention or there wouldn't have been any reason for a settlement.
It's a question of the degree of alignment between your agenda and other people's. Of course your example could equally apply to non-FOSS agendas.
Even in those cases where source code was supplied, it was paid for and permission to alter it wasn't necessarily given. It wasn't "free" in the way RMS defined it. In any case, there was a lot of code written in assembly prior to 1983 so those couldn't be compiled. In addition in the 1960's most computer customers rented their computers and many of them didn't even employ programmers.
If you think about it, RMS had little experience in the computer business at the time he created GNU and doesn't have much more now.
The only way you can fully follow your own agenda is to work by yourself or be dictating leader. Note that the license you use is not an issue. Anyone who has looked at the rules for contributing to an open source project can see that they'll be following somebody else's agenda.
I can't say for sure that there hasn't always some small amount of free software around, but it wasn't common in the early days for the computer industry to provide source code to paying customers and certainly it wasn't provided to anybody who was interested.
I have no doubt that a 1983 level of effort in open source is quite sustainable, the question is whether a level of effort necessary to continue open source's market share is sustainable.
Dilbert was mocking this practice a decade ago.
The monopoly product is supposed to promote the new product, not the other way around. So, if MS made it impossible to run iTunes on Windows, that could be considered an illegal tie-in to promote the Zune.
It's not illegal for a monopoly to fund a new product category by using the profits of their monopoly market. It would only be illegal if there was some technological tie-in between the products that made competing products in the new market be at a disadvantage.
Reading Slasdot, you could get the impression that from now on everything MS does violates antitrust laws. As a practical matter this chapter of MS history is about closed and in the future the argument that "it's different because MS is a monopoly" is going to be defunct.
"RMS is an idealist, whilst the people behind the CC organization are pragmatists."
Besides, if RMS was so idealistic he wouldn't have allowed you to modify the code for internal use without making the changes public. Just because you're not redistributing the code doesn't mean that the code doesn't want to be "free". This was a pragmatic compromise to lure organizations into using GPL'd code.
"NOWHERE in the GPL does it restrict you from accepting money for the software."
It's getting customers who are willing to pay for something that they can get for free that is the problem.
"I'd submit that creative freedom is more important to talented people, however. Speaking anecdotally, although all levels of talent are represented, I've encountered a much higher proportion of very talented programmers in Open Source than I have at work in the commercial/proprietary world."
I guess I've never seen a significant relationship between the desire for creative freedom and talent. I guess I've met too many people who crave creative freedom while those around them are rolling their eyes behind their back.
As far as your own observations about open vs. closed development, it depends on how much experience you have and what kind of people you've worked with. Certainly if you're comparing closed source IT folks with open source developers, it's not a fair comparison (I'm not saying you have).
"You don't believe that talented people gravitate towards environments which offer them creative freedom?"
I don't think that talented people are unique in their desire to have it their own way, no. Furthermore, a group of people who all get to do whatever they individually want to do, don't make a great team. That's true for both open and closed source development.
"But Open Source gives you the freedom to do things the way you want to, and it's a good way to interact with a population of other talented coders, both of which are generally hard to get consistently in the commercial world."
Sure, because a group of people who all get to do things the way they want to do it are known to be more talented and accomplished than an organized team creating products for paying customers.
We're not talking here about copying an idea or a mathematical result, but a word for word duplication.
"If you instead rewrite the code, you face the possible claim that your new code is a derivative work which is also covered by the original author's copyright. The "cleanroom" approach is sometimes used to avoid this."
If there's no common code I don't see how anybody could successfully claim it as a derivative work. It's not like writing a story about a boy with a scar who attends a 7 year wizard school.
In addition, the cleanroom approach is really more relevent to a trade secret - it proves that you had no knowledge of the secret. If somehow you accidently recreated somebody else's copyrighted work without any knowledge of the original, I doubt that you could use that as a defense.
Nine old obscure products I can use as an excuse to slam Vista.
"Some apps are too heavy for the hardware, that's not linux's fault but rather the individual apps and the hardware. A program designed for a supercomputer with a terabyte of ram won't work very well on even a high end gaming pc."
In other words, the claim that Linux (or Windows, or some other OS) runs at all these different scales isn't really meaningful in the general case. If your cell phone was the size of a mainframe, it might be able to run enterprise applications by mere recompiling, but since it isn't - who cares?
"The poster child for the situation is Netscape, but Microsoft has "done a Netscape" on lots of other startups"
Ironically, if MS hadn't been antitrust bait and Netscape had to be sold for its value as a company rather than its value as a MS plantiff, the founders would have made a lot less money. Jim Clark is known for losing interest in his starups once they become succesful and that's probably part of the reason Netscape was slow to upgrade their browser and failed to successfully expand beyond the narrow browser market.
"Slashdot is a blog not a news source."
Sure, that's why they call each main thread a "story".
The stability of any of the real mode Windows versions really depends on what applications you run. Lotus ccmail would crash Windows 95,98,ME on a regular basis. On Windows NT and beyond, it would only crash itself.