I don't doubt it. MATLAB has always been available on multiple platforms. My point is that using Windows doesn't lock you into using only MS applications.
"escaping reliance on a single vendor to supply any and all software products."
Sure because nobody ever has run Turbo Tax, Quicken, iTunes, Photoshop, AutoCAD, Google Desktop, Lotus Notes, MATLAB, non-MS games, (10,000 other non-MS apps) on Windows.
"Get yourself a software engineering text book, there are many well documented metrics for assessing programmers."
Reading a text book is a good idea because you won't find any serious measurement being done in the real world. Of course that also means that these metrics haven't really been "road-tested" either.
Well, the constructing of structures goes back a very long time and we have been using electricity for more than 100 years, but mechanical and particularly electrical engineering don't go back all that far. So I think the idea that software is "immature" relative to these other disiplines is overstated in my opinion. My prediction is that we will have better tools and languages in 100 years, but we will still be having the same kind of problems.
Ironically, much of the invovation in electrical and mechanical engineering in the last 30 years are the direct result of software tools for analysis and design.
You're free to believe whatever you want, of course.
Let's look at this another way. This issue has been discussed for decades long before the usual suspects of Visual Basic programmers, MCSEs, and dot-com-I'm-only-in-it-for-the-money types came along. After 50+ years of collective experience developing software, is it more resonable to assume that most software developers are idiots compared to mechanical and electrical engineers and our methods crude compared to those of other disiplines or is it more reasonable to assume that nature of the work is fundementally different?
"What does the fact that two bytes having 65,536 states have to do with complexity? That's irrelevnat to the complexity of the system; any software system can (and should) be broken down into smaller functional modules that can be further broken down into smaller chunks etc"
Sure, there is decomposition, but the number of correct states remains high compared to physical systems. However, since nearly all software has bugs, there are other states the software can assume that are totally unknown. So the number of theoretically possible states (65,536 states in the case of 2 bytes) determines the worst-case complexity (based on one of several accepted meanings of the word "complexity").
"If we are going to have a pissing contest with number of variables, the fact that the real world is not discrete like logic leads to a much greater number of possible positions for physical things.."
Actually the fact that a physical system at the macro level isn't discrete is why it's not as complex as software. Two positions that are close together in the physical world are nearly indistinguishable in their effect on a system. In software, however, changing a single bit can result in radically different effects. So while the number of states of objects within a physical system might be quite large, the number of states that result in different system behavior are much smaller. So the number of system states of a physical system are typically less than the number of system states in software.
I think there are a lot of organizations that would love to take your money and it might be good PR to join one, but I don't think it proves anything about your abilities.
I don't have any inside information, just the belief based on years of experience that just because you haven't found a bug yet, doesn't mean there isn't one there. In addition, if one wants to talk about the shuttle as an example of "real" software engineering the spec should be on the table too, not just the implementation.
"There is no software that is so complex that it trumps the complexity of an orbital spacecraft."
There's a difference being complex and being hard. With a mere two bytes having 65,536 states, I'd say software has the potential to be far more complex than an orbital spacecraft (assuming you're not counting the complexity of the software in the spacecraft.).
As far as the shuttle software is concerned, it's very small in size and given that there have been numerous computer problems on the shuttle, it's not a foregone conclusion that none of these errors are due to software bugs - signed off or not.
"Way off-topic, but programming desperately needs the kind of accountability and professionalism that 'real' engineering has. "
'Real' engineering as you call it, is really based on the application of science to solve a problem and generally you can't build anything useful that falls outside of that direct application.
In computer science or software engineering it's different: what is the science of word processing or web servers? Yes, there are scientific principles involved, but most of the design is about artifically created environments that are not limited by real science and not easily evaluated by applying scientific laws.
Now, there was a time when most of what is done today in software was done by EEs using digital logic, but when the complexity started getting too high and microprocessors became available, it shifted to software. So in a way, the electrical engineers solved a potential "professionalism" issue by kicking the most complex problems out of their domain.
Well, as others have stated, it's rare for someone with CS degree to be a PE. I suspect that the average MSCE is more qualified in computer science than the average PE is.
"If Microsoft decides to revoke that license because of something Pete Pirate did, who is at fault for Microsoft's actions - Pete or Microsoft ?"
Pete, of course. Pete knows that his actions will deny a legitimate user's use of the OS but goes ahead anyway.
"Or to put it another way: If you steal from me, and that makes me so angry that I kill a random bystander, does that make you a murderer ?"
Or to put it yet another way: If you implement a way to protect your IP and some random guy steals your customer's key, does that make you responsible for your customer's inability to run the software?
"Violating software's copyright may or may not be immoral, but in either case it in no way makes the violator responsible for the actions of the party who's copyrights were violated."
I can say something similiar: Protecting your IP may or may not be immoral, but in either case in no way makes the vendor responsible for the actions of an individual who is pirating software.
See these analogies or restatements or our opinions prove nothing.
"The person who brute force discovers and uses someone else's code is not the one causing their Copy of Windows to be invalidated. Microsoft is doing that."
These guys are making the choice to cheat other people for their own benefit. They are soley responsible. It's very likely that these same individuals are guilty of other crimes like phishing, identity theft, etc. They probably get a big laugh over the idea that people actually think they're doing it as blow for freedom or somesuch.
Ah, another well-reasoned and eloquent argument on Slashdot. Perhaps someday I could return to school as you suggest and my only hope is that a can achieve a small fraction of your brilliance. But, alas, I'm sure you have forgotten more about dipshit then I'll ever know.
Well, in this particular case, stealing a key so you can run an illegal copy when you know it prevents someone from running the OS they've purchased a license to is plain old fashion theft. So the typical "it doesn't deny the owner use" excuse doesn't apply.
Couldn't Ballmer change his tune and say "We've seen the light and believe in F/OSS but alas our legal and ethical responsibilty to our shareholders prevent us from actually contributing to any projects"? Perhaps they could contribute the source for Microsoft Bob without getting into trouble.
"Claiming that IBM contributes nothing of value to open source is an outright lie."
Which is why I made no such claim. I said they didn't contribute anything they were making a significant profit from. For example, eclipse has been very valuable to IBM for undermining Sun.
"Most companies hold onto the source of their software far after it's making them any profits. Most companies don't even release their source even after they stop distributing it."
That's exactly what IBM did with Rational's Visual Test after they bought Rational. Not only won't they release the source, they won't even let you buy a EULA for it. Why? Because it competes with other testing tools they sell that are a lot more expensive.
Slashdot Mirror
I don't doubt it. MATLAB has always been available on multiple platforms. My point is that using Windows doesn't lock you into using only MS applications.
I've heard that if you took the money spent making Deep Impact and Armageddon, you'd have enough money to do the search.
"escaping reliance on a single vendor to supply any and all software products."
Sure because nobody ever has run Turbo Tax, Quicken, iTunes, Photoshop, AutoCAD, Google Desktop, Lotus Notes, MATLAB, non-MS games, (10,000 other non-MS apps) on Windows.
"Get yourself a software engineering text book, there are many well documented metrics for assessing programmers."
Reading a text book is a good idea because you won't find any serious measurement being done in the real world. Of course that also means that these metrics haven't really been "road-tested" either.
Does the IEE or ACM periodically audit their members for honesty and competence? Or were you thinking of another organization that does?
Well, the constructing of structures goes back a very long time and we have been using electricity for more than 100 years, but mechanical and particularly electrical engineering don't go back all that far. So I think the idea that software is "immature" relative to these other disiplines is overstated in my opinion. My prediction is that we will have better tools and languages in 100 years, but we will still be having the same kind of problems.
Ironically, much of the invovation in electrical and mechanical engineering in the last 30 years are the direct result of software tools for analysis and design.
You're free to believe whatever you want, of course.
Let's look at this another way. This issue has been discussed for decades long before the usual suspects of Visual Basic programmers, MCSEs, and dot-com-I'm-only-in-it-for-the-money types came along. After 50+ years of collective experience developing software, is it more resonable to assume that most software developers are idiots compared to mechanical and electrical engineers and our methods crude compared to those of other disiplines or is it more reasonable to assume that nature of the work is fundementally different?
"What does the fact that two bytes having 65,536 states have to do with complexity? That's irrelevnat to the complexity of the system; any software system can (and should) be broken down into smaller functional modules that can be further broken down into smaller chunks etc"
Sure, there is decomposition, but the number of correct states remains high compared to physical systems. However, since nearly all software has bugs, there are other states the software can assume that are totally unknown. So the number of theoretically possible states (65,536 states in the case of 2 bytes) determines the worst-case complexity (based on one of several accepted meanings of the word "complexity").
"If we are going to have a pissing contest with number of variables, the fact that the real world is not discrete like logic leads to a much greater number of possible positions for physical things.."
Actually the fact that a physical system at the macro level isn't discrete is why it's not as complex as software. Two positions that are close together in the physical world are nearly indistinguishable in their effect on a system. In software, however, changing a single bit can result in radically different effects. So while the number of states of objects within a physical system might be quite large, the number of states that result in different system behavior are much smaller. So the number of system states of a physical system are typically less than the number of system states in software.
I think there are a lot of organizations that would love to take your money and it might be good PR to join one, but I don't think it proves anything about your abilities.
I don't have any inside information, just the belief based on years of experience that just because you haven't found a bug yet, doesn't mean there isn't one there. In addition, if one wants to talk about the shuttle as an example of "real" software engineering the spec should be on the table too, not just the implementation.
"There is no software that is so complex that it trumps the complexity of an orbital spacecraft."
There's a difference being complex and being hard. With a mere two bytes having 65,536 states, I'd say software has the potential to be far more complex than an orbital spacecraft (assuming you're not counting the complexity of the software in the spacecraft.).
As far as the shuttle software is concerned, it's very small in size and given that there have been numerous computer problems on the shuttle, it's not a foregone conclusion that none of these errors are due to software bugs - signed off or not.
"Way off-topic, but programming desperately needs the kind of accountability and professionalism that 'real' engineering has. "
'Real' engineering as you call it, is really based on the application of science to solve a problem and generally you can't build anything useful that falls outside of that direct application.
In computer science or software engineering it's different: what is the science of word processing or web servers? Yes, there are scientific principles involved, but most of the design is about artifically created environments that are not limited by real science and not easily evaluated by applying scientific laws.
Now, there was a time when most of what is done today in software was done by EEs using digital logic, but when the complexity started getting too high and microprocessors became available, it shifted to software. So in a way, the electrical engineers solved a potential "professionalism" issue by kicking the most complex problems out of their domain.
Well, as others have stated, it's rare for someone with CS degree to be a PE. I suspect that the average MSCE is more qualified in computer science than the average PE is.
He wouldn't live long enough to guess the key. He's using a program to steal it.
The relevent criminal behavior of Pete isn't violating copyright, it's stealing the key.
"If Microsoft decides to revoke that license because of something Pete Pirate did, who is at fault for Microsoft's actions - Pete or Microsoft ?"
Pete, of course. Pete knows that his actions will deny a legitimate user's use of the OS but goes ahead anyway.
"Or to put it another way: If you steal from me, and that makes me so angry that I kill a random bystander, does that make you a murderer ?"
Or to put it yet another way: If you implement a way to protect your IP and some random guy steals your customer's key, does that make you responsible for your customer's inability to run the software?
"Violating software's copyright may or may not be immoral, but in either case it in no way makes the violator responsible for the actions of the party who's copyrights were violated."
I can say something similiar: Protecting your IP may or may not be immoral, but in either case in no way makes the vendor responsible for the actions of an individual who is pirating software.
See these analogies or restatements or our opinions prove nothing.
"The person who brute force discovers and uses someone else's code is not the one causing their Copy of Windows to be invalidated. Microsoft is doing that."
These guys are making the choice to cheat other people for their own benefit. They are soley responsible. It's very likely that these same individuals are guilty of other crimes like phishing, identity theft, etc. They probably get a big laugh over the idea that people actually think they're doing it as blow for freedom or somesuch.
Ah, another well-reasoned and eloquent argument on Slashdot. Perhaps someday I could return to school as you suggest and my only hope is that a can achieve a small fraction of your brilliance. But, alas, I'm sure you have forgotten more about dipshit then I'll ever know.
Well, in this particular case, stealing a key so you can run an illegal copy when you know it prevents someone from running the OS they've purchased a license to is plain old fashion theft. So the typical "it doesn't deny the owner use" excuse doesn't apply.
Your just making excuses for them now.
Couldn't Ballmer change his tune and say "We've seen the light and believe in F/OSS but alas our legal and ethical responsibilty to our shareholders prevent us from actually contributing to any projects"? Perhaps they could contribute the source for Microsoft Bob without getting into trouble.
"Claiming that IBM contributes nothing of value to open source is an outright lie."
Which is why I made no such claim. I said they didn't contribute anything they were making a significant profit from. For example, eclipse has been very valuable to IBM for undermining Sun.
Absolutely no reason unless they believed in F/OSS. They don't - that's my point.
Yes, it's really been a case of 20 questions.
"Most companies hold onto the source of their software far after it's making them any profits. Most companies don't even release their source even after they stop distributing it."
That's exactly what IBM did with Rational's Visual Test after they bought Rational. Not only won't they release the source, they won't even let you buy a EULA for it. Why? Because it competes with other testing tools they sell that are a lot more expensive.
I haven't contributed any free software.
My point is that you should beware of large corporations bearing gifts.