Look at the chart showing Linux's market share. The highest percentage shown is 6% (its projected market share in 2006). If a chart of the full range of percentages were displayed at the same scale it couldn't be shown on a single page. You'd have to go to page 2 and scroll to the bottom to find Linux.
As for the projection of 6% in 2006, it doesn't seem to be supported by the trend in the actual data. It looks like growth slowed by about 90% in 2002-2003 as compared to 2001-2002.
If, as you claim, XP is a mess due to the hacks used for backward compatability, then the OSS community would have to support all those hacks no matter how much "choking" they would do.
It's the compatibility that is the major challenge of maintaining Windows. Anybody can "fix" XP if they're willing to forgo the #1 customer requirement. You might as well just as well rename Linux to Windows XP if compatability is not retained.
I'd debate you on the facts, but you haven't presented any.
You have the right to believe that the OSS community would do a better job building XP, but you're going to have to present some evidence to convince me. It would probably take years for the OSS community just to read the code, let alone understand or improve it.
I think the problem is that people assume that if you have a few quarters of profit, you're a successful company. You're minimally successful when the amount of profit made exceeds the amount of investment that has been made over the life of the company. Of course this minimal requirement is still less profitable then a simple savings account would have been.
So I guess that's why the vast majority of profit comes from open source software, and companies like MS haven't been able to make any money. You know, due to having to hire a bunch of smart people, having competitors, etc.
He didn't say anything about usernames and passwords. He said that the reading the source code would reveal aspects of the business. Explain how you can implement business logic without some traceability to your business processes?
I don't support it and I don't see how anything I've argued supports it either. I simply said that you can minimize some of the negative effects by having someone other than your programming staff enforce it.
I didn't say anything specific about an 80 character limit either. My point is that too much time energy and money is spent on non-functional "correctness".
You can take code from one organization and give it to another with different coding standards and suddenly that code is defective. This is a cultural issue and has nothing to do with engineering or science.
Often a coding convention can be quite a distraction from finding bugs because violations of it are usually the "low-hanging fruit" of a code review. Why slog through all that logic stuff when you can contribute to the meeting by pointing out that someone left off the sz prefix for a string variable?
If you're going to enforce a coding convention, perhaps the best way would be to have a knowledgeable administrative assistant go through the code looking for violations and report back to the team lead. Then after addressing those issues, conduct a code review with the programmers. In that review, only allow comments on logic issues and not on convention violations.
"If you want to get quantitative data on how source code organization may affect ease of perception, you're going to pay for the study yourself or wait for a very long while."
The fact that evidence is difficult or expensive to obtain doesn't negate the need for it to prove something. Anecdotal evidence isn't that illuminating, but in my 20+ years of software development experience I haven't found the consistency of names to correlate in any way with the difficulty of understanding code someone else has written.
"Strawman, and not a very good one."
After reviewing your entire original post I admit that you never said that consistency was all that mattered the way I "remembered" it. I believe the experiment I proposed was a good one for testing someone's commitment to that argument, but it wasn't exactly yours.
Well, it seems you're well informed about the conventional wisdom in this area. The problem is that this idea that consistency aids maintenance has never really been proven.
For an alternate view, try adopting a convention that everybody on the team hates. If consistency is all that matters, then it should work fine. The problem is that the alpha programmers won't get their way.
Re:Embed Linux? It's not an ideal choice.
on
How to Embed Linux
·
· Score: 1
I'm not sure who started it, but Sun was talking about embedded Java long before MS was taking about embedded XP.
I think this issue is really about how geeks love to create rules for everything and think everyone should follow their lead. Don't we have enough functional bugs in our code to worry about without finding additional ways for code to be defective (layout, column limits, naming conventions, etc.).
Re:Embed Linux? It's not an ideal choice.
on
How to Embed Linux
·
· Score: 1
Embedded != portable
I think what's happening is that the term embedded is being watered down.
A basic PDA that acts as an electronic address book and has no connectivity would qualify under the traditional definition, while something like a Pocket PC would not. The essential character of a traditional embedded system is that it is a special purpose device, like a washing machine or a basic calculator.
Under the new definition, a desktop PC could be considered "embedded" just as easily as most PDA's.
"He's not saying that *any* measurement is better than no measurement. He's saying that there exists a measurement that is better than no measurement."
Then he's really making a philosophical statement that probably has little value in a practical sense. Even if it were true, a measurement that you can't identify, is exactly the same as no measurement at all.
So we just have to go back to basics and say that any proposed measurement should be supported by evidence and we should reject those that aren't.
Gilb's law doesn't appear to be based on logic. It suggests a relationship between your needs and useful measures (if you don't have a need to quantify something, does that mean it can't be measured?").
In addition, even if it was a fact that something "can be measured" that doesn't imply that any particular individual or institution is capable of performing that measurement.
I think Gilb's law is primarily based on denial. Humans want to believe they are in charge of the universe and many can't accept the fact that they aren't.
Of course it does, even if it harms their relationship with their customers. The question is whether Apple should be allowed to stop Real from competing, which is very different question.
If Apple does attempt to fight this in court they'll probably lose more by damaging their reputation than they stand to lose by Real's actions.
If you develop software in exchange for money, that's a product, not a service. If you install software, perform training, provide technical support, etc., then you are providing a service. They are some cases where there is an overlap between a product and service, but merely redefining software development as a service doesn't change the economics involved.
Slashdot Mirror
Look at the chart showing Linux's market share. The highest percentage shown is 6% (its projected market share in 2006). If a chart of the full range of percentages were displayed at the same scale it couldn't be shown on a single page. You'd have to go to page 2 and scroll to the bottom to find Linux.
As for the projection of 6% in 2006, it doesn't seem to be supported by the trend in the actual data. It looks like growth slowed by about 90% in 2002-2003 as compared to 2001-2002.
If, as you claim, XP is a mess due to the hacks used for backward compatability, then the OSS community would have to support all those hacks no matter how much "choking" they would do.
It's the compatibility that is the major challenge of maintaining Windows. Anybody can "fix" XP if they're willing to forgo the #1 customer requirement. You might as well just as well rename Linux to Windows XP if compatability is not retained.
Perhaps Bruce should write it himself instead of "calling" for it.
Being a Guru means never having to do the actual work yourself.
I'd debate you on the facts, but you haven't presented any.
You have the right to believe that the OSS community would do a better job building XP, but you're going to have to present some evidence to convince me. It would probably take years for the OSS community just to read the code, let alone understand or improve it.
I think the problem is that people assume that if you have a few quarters of profit, you're a successful company. You're minimally successful when the amount of profit made exceeds the amount of investment that has been made over the life of the company. Of course this minimal requirement is still less profitable then a simple savings account would have been.
So I guess that's why the vast majority of profit comes from open source software, and companies like MS haven't been able to make any money. You know, due to having to hire a bunch of smart people, having competitors, etc.
Not all benefits are equal. If MS opened all their source code, do you seriously believe that would improve their competitive position?
He didn't say anything about usernames and passwords. He said that the reading the source code would reveal aspects of the business. Explain how you can implement business logic without some traceability to your business processes?
"However, all the tools I use are open source."
And of course nobody is paid to create closed-source tools.
"And no open source software will ever implement the kind of proprietary business logic I implement."
That's what everybody thinks, "it can't happen to me". Wake up and smell the exit interview.
I don't support it and I don't see how anything I've argued supports it either. I simply said that you can minimize some of the negative effects by having someone other than your programming staff enforce it.
I didn't say anything specific about an 80 character limit either. My point is that too much time energy and money is spent on non-functional "correctness".
You can take code from one organization and give it to another with different coding standards and suddenly that code is defective. This is a cultural issue and has nothing to do with engineering or science.
You need to go figure out whether you think bracing style is trivial or not. Apparently it is for the individual, but not for a group.
Well, we all have our personal preferences.
Often a coding convention can be quite a distraction from finding bugs because violations of it are usually the "low-hanging fruit" of a code review. Why slog through all that logic stuff when you can contribute to the meeting by pointing out that someone left off the sz prefix for a string variable?
If you're going to enforce a coding convention, perhaps the best way would be to have a knowledgeable administrative assistant go through the code looking for violations and report back to the team lead. Then after addressing those issues, conduct a code review with the programmers. In that review, only allow comments on logic issues and not on convention violations.
"If you want to get quantitative data on how source code organization may affect ease of perception, you're going to pay for the study yourself or wait for a very long while."
The fact that evidence is difficult or expensive to obtain doesn't negate the need for it to prove something. Anecdotal evidence isn't that illuminating, but in my 20+ years of software development experience I haven't found the consistency of names to correlate in any way with the difficulty of understanding code someone else has written.
"Strawman, and not a very good one."
After reviewing your entire original post I admit that you never said that consistency was all that mattered the way I "remembered" it. I believe the experiment I proposed was a good one for testing someone's commitment to that argument, but it wasn't exactly yours.
Well, it seems you're well informed about the conventional wisdom in this area. The problem is that this idea that consistency aids maintenance has never really been proven.
For an alternate view, try adopting a convention that everybody on the team hates. If consistency is all that matters, then it should work fine. The problem is that the alpha programmers won't get their way.
I'm not sure who started it, but Sun was talking about embedded Java long before MS was taking about embedded XP.
I think this issue is really about how geeks love to create rules for everything and think everyone should follow their lead. Don't we have enough functional bugs in our code to worry about without finding additional ways for code to be defective (layout, column limits, naming conventions, etc.).
Embedded != portable
I think what's happening is that the term embedded is being watered down.
A basic PDA that acts as an electronic address book and has no connectivity would qualify under the traditional definition, while something like a Pocket PC would not. The essential character of a traditional embedded system is that it is a special purpose device, like a washing machine or a basic calculator.
Under the new definition, a desktop PC could be considered "embedded" just as easily as most PDA's.
"He's not saying that *any* measurement is better than no measurement. He's saying that there exists a measurement that is better than no measurement."
Then he's really making a philosophical statement that probably has little value in a practical sense. Even if it were true, a measurement that you can't identify, is exactly the same as no measurement at all.
So we just have to go back to basics and say that any proposed measurement should be supported by evidence and we should reject those that aren't.
Gilb's law doesn't appear to be based on logic. It suggests a relationship between your needs and useful measures (if you don't have a need to quantify something, does that mean it can't be measured?").
In addition, even if it was a fact that something "can be measured" that doesn't imply that any particular individual or institution is capable of performing that measurement.
I think Gilb's law is primarily based on denial. Humans want to believe they are in charge of the universe and many can't accept the fact that they aren't.
"Every time they had come up with something innovative (technically or purely esthetically), they got ripped off by cheap knock-offs."
I'm sure the guys that designed the Xerox Alto and the Xerox Dandelion know exactly how that feels.
"Apple has every right to speak up"
Of course it does, even if it harms their relationship with their customers. The question is whether Apple should be allowed to stop Real from competing, which is very different question.
If Apple does attempt to fight this in court they'll probably lose more by damaging their reputation than they stand to lose by Real's actions.
I disagree with your fundemental assumption that providing custom software means you're providing a service. Custom software is a custom product.
If you develop software in exchange for money, that's a product, not a service. If you install software, perform training, provide technical support, etc., then you are providing a service. They are some cases where there is an overlap between a product and service, but merely redefining software development as a service doesn't change the economics involved.
"Information MUST BE FREE. Open it up. Publish yur article under the GPL. Allow others to edit it, improve it develop it."
I know when I state my opinion, I always look forward to having others "improve it".
An employee at McDonald's flipping burgers is performing a service rather than providing product, just like an accountant.
There are millions of service jobs, writing software isn't one of them.