Well, in a lot companies unit testing by programmers is considered an important step. You don't really want to hand over your application to the test group and have them find a trival bug in the 1st hour of testing.
This is particularly true in companies where the hand-off is somewhat formal and may require paperwork. Of course, any bugs found have to be documented as well which takes more time.
So the bottom line is that the total cost involved for having only the testers test the code, is often higher than the cost of having the programmer do her own unit testing.
The problem is that surveys like this aren't scientific polls, so you can't take the results too seriously.
Of course, it would be far more interesting to measure what percentage of Windows developers have switched to Linux development, than what percentage of Linux developers switched from Windows.
Look, there are people all over the world who would like to come to the US and work. Why should the high tech companies and foreign engineers get special treatment over other businesses and other workers?
I have no problem if foreign engineers get in line with everyone else to get a green card or citizenship in the US. But it's not fair to US engineers to be singled-out for replacement because the high tech industry has bribed the government for special treatment.
"I agree with the analogy to the groundswell effect that brought the IBM PC into the corporate world in the early 1980s against the IT establishment , who were the last to climb on board in most cases."
Well, I think the opposition of the IT establishment to early PC use is somewhat exaggerated. In the early days the PC was replacing typewriters not corporate computers and most IT departments didn't offer any competing services such as word processing.
Of course a lot of the growth came from small companies that never had owned a computer before.
Well, I didn't mean to imply that all applications would fail.
On the other hand, it's quite clear that real mode code in Win9x that has no reason to exist except for backword compatibility is a major cause of instability.
It easy to say that MS should have been able to make NT run 99% of legacy apps without any stability problems, but saying is quite different than doing.
I guess you missed the part where I said that the 386 implementors weren't the first to do it. My point was that the credit belonged to Intel more than to OS implementors like Linus or MS.
"Linux, as we know it, could never have been created on an 8088."
Yes, that was exactly my point. "Linux, as we know it" requires hardware features that didn't exist in the 8088.
The only detail we may disagree on is who did the bulk of the designing that makes the stability possible. I think most of the credit should go to the 386 implementors (although they weren't the first to accomplish it) rather than to the OS implementors that took advantage of the hardware features.
A very imformative post. Most people forget the role that hardware plays in OS stability.
If Linux had been created back in the 8088 days, either today's Linux would be incompatible with its legacy apps, or its stability would be comparable to Win9x.
Well, I don't think "without access to existing UNIX source code" is a complete definition of indepedent in this context. If Linus had never read any material that discussed Unix internals or read any source code that was written by people who had access to Unix source code or access to Unix internal information, then Linux would be an independent recreation of Unix.
Since AT&T did a lousy job of protecting thier IP rights to Unix, this might not be legally relevant, but it is relevent to the truth.
Actually, in a way buffer overflows and predictable timing have a lot in common.
Why is a lack of length checks so common in legacy code? Because it's human nature not to spend additional time on things that are not critical. Prior to exposure to hackers, the majority of potential buffer overflows were harmless. Most would never occur under normal conditions.
Now predictable timing in encryption code can be exploited by hackers, so in a way it's just as much a bug as a potential buffer overrun. The trend is to create new classifications of bugs based on vulnerabilities.
You can certainly create major GUI applications for Windows with C++ and not deal with MFC at all. Like any framework or class library, MFC is not the answer to everything and requires effort to learn.
Well, you can't look at it as if the world started today. The original version of Windows had to be able to run on an 8088 with at most 640K of RAM and a 10MB hard drive (if that). It was critical that applications shared code and that code was loaded only when needed. DLLs are primarily used to optimize space.
As you correctly state, we now have a lot of resources on our PCs so we don't need to worry so much about space.
Now you can create a.NET application and set it up so you just copy the files that make up the assembly into a directory and you're done. You don't have to register Dlls or deal with the registry. Legacy applications will still require the registry for a long time, however.
Actually, Windows was originally designed to run on a Intel 8088 and Linux on a Intel 386 (or higher?). Since the 8088 has no hardware memory protection, Linux as we know it could never run on it.
Having to maintain backward compatibility with software written for pre-386 processors accounts for a lot of the stability problems of pre-NT/2000/XP Windows. This is an issue that Linux never had to contend with.
"A statistical correlation between race or ethnicity and scores isn't the same as a 'bias' in the common sense of the word."
True, but such a correlation certainly offers no proof that the test is unbaised either. In any case, the charge that such tests are biased is not based entirely on statistics but rather on the content of the tests.
It's easy to see how a test could be culturaly biased. Say there was a test designed to evaluate your understanding of computers that exclusively used MS Windows terms. Those who had a background only in Unix or Apple systems would be at a disadvantage even though their understanding of computers was the same.
You're right. I wish anyone who is tempted to say "RTFM", read the FAQ, or google it would just remain quiet and move on. Chances are they didn't know the answer anyway.
If it's like most SciFi channel programs they'll make about 14 shows a year and divide each year into 2 "seasons". Then if the show is really popular, they'll cancel it after two years.
"This isn't some upper middle class rant about how the poor should just shut up, go to work, and be happy, while I'm sitting by the pool waiting for Juanita to bring my Scotch."
So people laugh at those guys and then turn around and think somebody is guilty because they "failed" a polygraph test. The irony is that the copy machine works every bit as well as a polygraph and uses the same method - deception.
My apologies to e8johan. You asked for advice on how to implement your idea, not for comments on its value. I hate it when people do that to me, so I shouldn't do it myself.
It sounds like your potential customers want to use Windows. What benefits are they going to get by running Windows applications on Linux? Unless they are going to violate their license agreements, they're not going to be able to share copies of MS software anyway. On the other hand if they're going to pirate them, why not just copy the software illegally to each PC and forget about Linux?
The point is that Linux has to add value for the customer if it's going to displace Windows on the desktop. It will have to do that by providing superior applications (in the judgement of customers), not by being compatible with Windows.
Slashdot Mirror
Steal the CD from a store rather than downloading the 12 tracks.
Well, in a lot companies unit testing by programmers is considered an important step. You don't really want to hand over your application to the test group and have them find a trival bug in the 1st hour of testing.
This is particularly true in companies where the hand-off is somewhat formal and may require paperwork. Of course, any bugs found have to be documented as well which takes more time.
So the bottom line is that the total cost involved for having only the testers test the code, is often higher than the cost of having the programmer do her own unit testing.
For system testing, however, I agree with you.
The problem is that surveys like this aren't scientific polls, so you can't take the results too seriously.
Of course, it would be far more interesting to measure what percentage of Windows developers have switched to Linux development, than what percentage of Linux developers switched from Windows.
Look, there are people all over the world who would like to come to the US and work. Why should the high tech companies and foreign engineers get special treatment over other businesses and other workers?
I have no problem if foreign engineers get in line with everyone else to get a green card or citizenship in the US. But it's not fair to US engineers to be singled-out for replacement because the high tech industry has bribed the government for special treatment.
"I agree with the analogy to the groundswell effect that brought the IBM PC into the corporate world in the early 1980s against the IT establishment , who were the last to climb on board in most cases."
Well, I think the opposition of the IT establishment to early PC use is somewhat exaggerated. In the early days the PC was replacing typewriters not corporate computers and most IT departments didn't offer any competing services such as word processing.
Of course a lot of the growth came from small companies that never had owned a computer before.
Well, I didn't mean to imply that all applications would fail.
On the other hand, it's quite clear that real mode code in Win9x that has no reason to exist except for backword compatibility is a major cause of instability.
It easy to say that MS should have been able to make NT run 99% of legacy apps without any stability problems, but saying is quite different than doing.
I guess you missed the part where I said that the 386 implementors weren't the first to do it. My point was that the credit belonged to Intel more than to OS implementors like Linus or MS.
"Linux, as we know it, could never have been created on an 8088."
Yes, that was exactly my point. "Linux, as we know it" requires hardware features that didn't exist in the 8088.
The only detail we may disagree on is who did the bulk of the designing that makes the stability possible. I think most of the credit should go to the 386 implementors (although they weren't the first to accomplish it) rather than to the OS implementors that took advantage of the hardware features.
I assumed they agonized about the lighting over lattes.
A very imformative post. Most people forget the role that hardware plays in OS stability.
If Linux had been created back in the 8088 days, either today's Linux would be incompatible with its legacy apps, or its stability would be comparable to Win9x.
Well, I don't think "without access to existing UNIX source code" is a complete definition of indepedent in this context. If Linus had never read any material that discussed Unix internals or read any source code that was written by people who had access to Unix source code or access to Unix internal information, then Linux would be an independent recreation of Unix.
Since AT&T did a lousy job of protecting thier IP rights to Unix, this might not be legally relevant, but it is relevent to the truth.
Actually, in a way buffer overflows and predictable timing have a lot in common.
Why is a lack of length checks so common in legacy code? Because it's human nature not to spend additional time on things that are not critical. Prior to exposure to hackers, the majority of potential buffer overflows were harmless. Most would never occur under normal conditions.
Now predictable timing in encryption code can be exploited by hackers, so in a way it's just as much a bug as a potential buffer overrun. The trend is to create new classifications of bugs based on vulnerabilities.
You can certainly create major GUI applications for Windows with C++ and not deal with MFC at all. Like any framework or class library, MFC is not the answer to everything and requires effort to learn.
Well, you can't look at it as if the world started today. The original version of Windows had to be able to run on an 8088 with at most 640K of RAM and a 10MB hard drive (if that). It was critical that applications shared code and that code was loaded only when needed. DLLs are primarily used to optimize space.
.NET application and set it up so you just copy the files that make up the assembly into a directory and you're done. You don't have to register Dlls or deal with the registry. Legacy applications will still require the registry for a long time, however.
As you correctly state, we now have a lot of resources on our PCs so we don't need to worry so much about space.
Now you can create a
Actually, Windows was originally designed to run on a Intel 8088 and Linux on a Intel 386 (or higher?). Since the 8088 has no hardware memory protection, Linux as we know it could never run on it.
Having to maintain backward compatibility with software written for pre-386 processors accounts for a lot of the stability problems of pre-NT/2000/XP Windows. This is an issue that Linux never had to contend with.
"A statistical correlation between race or ethnicity and scores isn't the same as a 'bias' in the common sense of the word."
True, but such a correlation certainly offers no proof that the test is unbaised either. In any case, the charge that such tests are biased is not based entirely on statistics but rather on the content of the tests.
It's easy to see how a test could be culturaly biased. Say there was a test designed to evaluate your understanding of computers that exclusively used MS Windows terms. Those who had a background only in Unix or Apple systems would be at a disadvantage even though their understanding of computers was the same.
You're right. I wish anyone who is tempted to say "RTFM", read the FAQ, or google it would just remain quiet and move on. Chances are they didn't know the answer anyway.
So was there 12 years of proven value for CMM before you adopted it?
How many eyeball years did it take to find this problem?
If it's like most SciFi channel programs they'll make about 14 shows a year and divide each year into 2 "seasons". Then if the show is really popular, they'll cancel it after two years.
"This isn't some upper middle class rant about how the poor should just shut up, go to work, and be happy, while I'm sitting by the pool waiting for Juanita to bring my Scotch."
Of course not. Your housekeeper's name is Joan.
I love that story.
So people laugh at those guys and then turn around and think somebody is guilty because they "failed" a polygraph test. The irony is that the copy machine works every bit as well as a polygraph and uses the same method - deception.
Criminalization of speech debunking tarot cards, psychic phenomenon, tea reading and other practices in the same category as the polygraph?
My apologies to e8johan. You asked for advice on how to implement your idea, not for comments on its value. I hate it when people do that to me, so I shouldn't do it myself.
It sounds like your potential customers want to use Windows. What benefits are they going to get by running Windows applications on Linux? Unless they are going to violate their license agreements, they're not going to be able to share copies of MS software anyway. On the other hand if they're going to pirate them, why not just copy the software illegally to each PC and forget about Linux?
The point is that Linux has to add value for the customer if it's going to displace Windows on the desktop. It will have to do that by providing superior applications (in the judgement of customers), not by being compatible with Windows.