It sounds like what you're asking for is very light style requirements which I don't disagree with. Variable names should be meanful, but I don't think it matters much if some programmers use functionToFixBugInLinux() while others use another_function_to_fix_bug_in_linux. Unfortunately, people are often more concerned with this issue than they are with obfuscated code.
As for program correctness, I didn't say that it should be proven but that it should be considered. That is, reviewers should look for problems the programmer may have missed. Obfuscated code will come to light and be discrouraged as part of this process since the programmer will have to expend considerable energy explaining what the code does.
The bigest problem I have with code reviews based on style is that they can provide the illusion the someting has been done to make the code better. Sometimes it's better to do nothing than to do something simply because it's easy.
"What code-review catches is the annoying things that the best developers tend to think don't matter so much. Style-differences from company practices. Naming conventions not being followed. Poorly chosen variable-names. Lack of documentation.
In short, code-review makes your code more maintainable."
Out of all the items you mention, only the lack of documentation seems really important. The rest smacks of xenophobia. I don't buy into the common myth that style and naming conventions are critical to maintainability. Anyone who can read a complicated C declaration isn't going to have any problem with non-politically-correct variable names or different styles. Style is arbitrary but functionality is not. If the code review process doesn't consider program correctness, it's a waste of time.
Are these percentages just for "paper bugs" (bugs that were found by examining the code but never encountered at run time). The reason I ask is that in order for bad error checking to result in an actual run-time problem, the bad data either has to come from a human or from a coding error. Assuming that not all of your 40% of bad error checking comes from a human there must be some percentage of errors that you haven't covered. Unless all of the bad data comes from "incorrectly using an undocumented function" or is a "specification issue". Just something you might want to consider.
One of the more interesting sources of bugs might be called "facts about the system you didn't know". For example, in the book "Digital Woes" by Lauren Ruth Wiener, the author describes how a British Rail signaling system (tracking system) was unable to track trains after they converted to disk brakes. It turns out the old clutch brakes had the side effect of scraping the wheels clean of wet leaves which allowed the sensors to work properly.
And yet I think that is exactly what Sun had intended all along. Sucker everyone into using Java for the "write-once-run-anywhere" dream, and then suddenly come up with hardware that had better performance. I wonder if there was a clause in Java licenses that prevented the licensee from developing Java hardware accelerators without Sun's permission. It's just speculation on my part but I wouldn't be surprised.
It depends on the nature of the UI and the nature of the hardware. Traditionally an embedded keyboard might just be a dumb matrix of keys that are scanned by the CPU and the "display" might consist of a handful of discrete LEDs. Desktop based OS's aren't likely to be very helpful for such a product.
On the other hand if you're talking about scaled-down PCs that are often mistakenly referred to as embedded systems, then yes, a desktop OS (Linux or whatever) is a slam-dunk.
I think it's a bit early to suggest that Mozilla 1.0 has few bugs than other browsers. The Mozilla team had the benefit of many lessons learned by earlier browser writers that were doing something brand new. A "Me too" product is always easier.
"Indirectly, they did. By not allowing OEM's to preload BeOS on their computers (That's an anti-trust violation!) they have not only prevented me from getting a quality OS from a quality OEM, but now I can't get BeOS at all!"
Nice theory, but you fail to account for why BeOs wasn't used by Apple. Or was that MS's fault too? Many people have bought Linux at retail even though they bought a PC with Windows preinstalled. BeOs used to be available at retail but apparently flopped. BeOs might be better than Linux, but it wouldn't be the first time that a better product failed.
"Joel says Sun made a mistake in releasing Java, which makes hardware a commodity."
I think Sun's intent was to try to get a majority of companies hooked on Java and then sell some specialized hardware that would accelerate it. They couldn't quite accomplish the first goal so they never could cash in on the second.
"I say the reason Sun released Java was to allow all the Windows app programmers to make apps that work on SPARC chips and Solaris as well as Windows."
I doubt that many Windows developers had a lot of interest in developing Solaris applications. If they did, they would be more interested in a ported version of the Win32 API than they would in learning how to do things the Java way. That's why the courts missed the point with J++. Java tweaked for Windows is exactly the correct approach for most Windows developers. The courts found that approach illegal, thus C#.
Well, if it's like most Farscape season-openers, the episode will start about a week after John ran out of fuel. In the course of the dialog we'll hear maybe one sentence about how he escaped. These gaps drive me crazy.
Actually, it depends on what part of the country you're in. Switzerland has three official languages: German, French, and Italian. Many Swiss speak English, but you'd be missing a good opportunity to learn a new language if you depend on that.
I suspect it is illegal for the OMB to adopt a policy that requires different rules for one company than for all the others. I know how much slashdotters like to argue "it's different, because MS has been found to be an illegal monopoly" but the OMB has no authority to enforce antitrust law.
On the other hand if the OMB required all their vendors to open all of their file formats, then that would be different.
Re:limits on granted rights, not copyrights
on
GPL's Strength
·
· Score: 1
OK, so tell me where in the copyright laws it says anything about having to publish source code. All I said was that that language is in the GPL. Isn't that where it is?
"So you look to copyright law to see if you have a derived work. If you do, you need permission from the original author to redistribute, and therefore that author gets to dictate terms. Those terms may be the GPL."
Or any other terms. Thus my orginal point that there's nothing special about the GPL.
I think the only disagreement we have is that I don't believe all of the GPL's restrictions are based on copyright law and I doubt that the GPL is more enforcable than a EULA.
Re:limits on granted rights, not copyrights
on
GPL's Strength
·
· Score: 1
"No, because under copyright law, you can't add code to my program in the first place!"
I didn't claim that I was allowed under copyright law to add source code, I said that the loss of privacy for that code came from the GPL and not from copyright law.
Re:limits on granted rights, not copyrights
on
GPL's Strength
·
· Score: 1
"All restrictions on your use of my code stem from copyright law, and copyright law alone."
All restrictions on my right to keep my added source code secret stem from the GPL and from the GPL alone.
"It would be a violation of the GPL if you have agreed to it. If you have not agreed to it, it would be a violation of the copyright laws."
For distributing the GPL'd part of the code without a license, yes. For distributing your part of the code, no. Thus the owner of the GPL'd code could sue you for copyright violations but couldn't compel you to release your source code on the basis of copyright law.
This is analogous to what happens with proprietary software. If you sign a EULA, you're typically restricted from reverse engineering the code. If you don't sign it, you're in violation of copyright law, but the owner couldn't compel you to share any developments derived from the reverse engineering on the basis of copyright law.
Re:Well beyond copyright law
on
GPL's Strength
·
· Score: 1
In both GPL'd and proprietary software you don't have the right to distribute copyrighted material without a license under copyright law.
Most EULA's for proprietary software add additional requirements that are not covered by copywrite laws such as a restriction against reverse engineering.
The GPL adds the requirement that you must license you source under the GPL which also not part of copyright law and in fact takes away a right (keeping your own source code private) that you would otherwise have were it not for the GPL.
I'm not sure how effective this entire burden of proof argument would be in court, but I don't think the GPL could meet the standard without deletion of the "viral" language.
Re:Well beyond copyright law
on
GPL's Strength
·
· Score: 1
"The law is already quite clear on what a licensee is authorized to do under the terms of vanilla copyright. If the license gets nullified, then the defendant no longer has ANY right to create deriviative works."
Courts are not restricted to an all-or-nothing nullification of a contract. It's possible that the "viral" language could be nullified alone if you could convince the court that it's illegal or unreasonable. I'm not aware of a convincing argument, but it's possible in principle.
"Also, "well beyond copyright law" is not relevant."
Perhaps not in court, but the author's argument (which I was commenting on) was that somehow the GPL is more enforcable because it is less restrictive. I suspect he really wouldn't make that argument in court.
"Nullifying the priciple would also be far more damaging to commercial interests than the FSF. Suddenly, an entire industry that already headed for a crisis regarding revenue has to worry about whether or not what constitutes "payment" under their licenses is unreasonable."
There are already restrictions on what form of payment is allowed by law (you can't require sex as payment for example), so if "viral" payments were outlawed, it's not a given that other commonly used payment forms would be in jeopardy.
Well beyond copyright law
on
GPL's Strength
·
· Score: 1
"Because the GPL (and presumably, other free/open software licenses) let the user do things that are otherwise illegal (copy and redistribute software), the GPL is in a stronger position to dictate terms."
The author doesn't offer any precedents that show that a court is more likely to enforce a license because it is less restrictive than other licenses.
In any case, the real issue for the GPL is the part that affects code that a licensee may add. Since the GPL requires that the source for new code must be distributed even though it was not created by the license holder, it goes well beyond copyright law.
Slashdot Mirror
It sounds like what you're asking for is very light style requirements which I don't disagree with. Variable names should be meanful, but I don't think it matters much if some programmers use functionToFixBugInLinux() while others use another_function_to_fix_bug_in_linux. Unfortunately, people are often more concerned with this issue than they are with obfuscated code.
As for program correctness, I didn't say that it should be proven but that it should be considered. That is, reviewers should look for problems the programmer may have missed. Obfuscated code will come to light and be discrouraged as part of this process since the programmer will have to expend considerable energy explaining what the code does.
The bigest problem I have with code reviews based on style is that they can provide the illusion the someting has been done to make the code better. Sometimes it's better to do nothing than to do something simply because it's easy.
"What code-review catches is the annoying things that the best developers tend to think don't matter so much. Style-differences from company practices. Naming conventions not being followed. Poorly chosen variable-names. Lack of documentation.
In short, code-review makes your code more maintainable."
Out of all the items you mention, only the lack of documentation seems really important. The rest smacks of xenophobia. I don't buy into the common myth that style and naming conventions are critical to maintainability. Anyone who can read a complicated C declaration isn't going to have any problem with non-politically-correct variable names or different styles. Style is arbitrary but functionality is not. If the code review process doesn't consider program correctness, it's a waste of time.
".. it is simply impossible to only hire expert programmers whose work never needs to be checked by anyone else and who don't need any supervision."
There are no such programmers.
How about "I don't see why anyone would want to use a word processor" - Scott McNealy a few years before getting into the office suite business.
Are these percentages just for "paper bugs" (bugs that were found by examining the code but never encountered at run time). The reason I ask is that in order for bad error checking to result in an actual run-time problem, the bad data either has to come from a human or from a coding error. Assuming that not all of your 40% of bad error checking comes from a human there must be some percentage of errors that you haven't covered. Unless all of the bad data comes from "incorrectly using an undocumented function" or is a "specification issue". Just something you might want to consider.
One of the more interesting sources of bugs might be called "facts about the system you didn't know". For example, in the book "Digital Woes" by Lauren Ruth Wiener, the author describes how a British Rail signaling system (tracking system) was unable to track trains after they converted to disk brakes. It turns out the old clutch brakes had the side effect of scraping the wheels clean of wet leaves which allowed the sensors to work properly.
And yet I think that is exactly what Sun had intended all along. Sucker everyone into using Java for the "write-once-run-anywhere" dream, and then suddenly come up with hardware that had better performance. I wonder if there was a clause in Java licenses that prevented the licensee from developing Java hardware accelerators without Sun's permission. It's just speculation on my part but I wouldn't be surprised.
It depends on the nature of the UI and the nature of the hardware. Traditionally an embedded keyboard might just be a dumb matrix of keys that are scanned by the CPU and the "display" might consist of a handful of discrete LEDs. Desktop based OS's aren't likely to be very helpful for such a product.
On the other hand if you're talking about scaled-down PCs that are often mistakenly referred to as embedded systems, then yes, a desktop OS (Linux or whatever) is a slam-dunk.
I think it's a bit early to suggest that Mozilla 1.0 has few bugs than other browsers. The Mozilla team had the benefit of many lessons learned by earlier browser writers that were doing something brand new. A "Me too" product is always easier.
"Indirectly, they did. By not allowing OEM's to preload BeOS on their computers (That's an anti-trust violation!) they have not only prevented me from getting a quality OS from a quality OEM, but now I can't get BeOS at all!"
Nice theory, but you fail to account for why BeOs wasn't used by Apple. Or was that MS's fault too? Many people have bought Linux at retail even though they bought a PC with Windows preinstalled. BeOs used to be available at retail but apparently flopped. BeOs might be better than Linux, but it wouldn't be the first time that a better product failed.
"Joel says Sun made a mistake in releasing Java, which makes hardware a commodity."
I think Sun's intent was to try to get a majority of companies hooked on Java and then sell some specialized hardware that would accelerate it. They couldn't quite accomplish the first goal so they never could cash in on the second.
"I say the reason Sun released Java was to allow all the Windows app programmers to make apps that work on SPARC chips and Solaris as well as Windows."
I doubt that many Windows developers had a lot of interest in developing Solaris applications. If they did, they would be more interested in a ported version of the Win32 API than they would in learning how to do things the Java way. That's why the courts missed the point with J++. Java tweaked for Windows is exactly the correct approach for most Windows developers. The courts found that approach illegal, thus C#.
"the ability to run most Microsoft programs"
They should be careful, this is a measurable feature. If it runs less than 51% of Microsoft programs, it's false advertising.
when buyers learn it won't run all the apps they expect it to.
Well, if it's like most Farscape season-openers, the episode will start about a week after John ran out of fuel. In the course of the dialog we'll hear maybe one sentence about how he escaped. These gaps drive me crazy.
"2) The language barrier. Can you speak French?"
Actually, it depends on what part of the country you're in. Switzerland has three official languages: German, French, and Italian. Many Swiss speak English, but you'd be missing a good opportunity to learn a new language if you depend on that.
I suspect it is illegal for the OMB to adopt a policy that requires different rules for one company than for all the others. I know how much slashdotters like to argue "it's different, because MS has been found to be an illegal monopoly" but the OMB has no authority to enforce antitrust law.
On the other hand if the OMB required all their vendors to open all of their file formats, then that would be different.
OK, so tell me where in the copyright laws it says anything about having to publish source code. All I said was that that language is in the GPL. Isn't that where it is?
"So you look to copyright law to see if you have a derived work. If you do, you need permission from the original author to redistribute, and therefore that author gets to dictate terms. Those terms may be the GPL."
Or any other terms. Thus my orginal point that there's nothing special about the GPL.
"And your reason for this doubt is...?"
The absence of any evidence to the contrary.
I think the only disagreement we have is that I don't believe all of the GPL's restrictions are based on copyright law and I doubt that the GPL is more enforcable than a EULA.
"No, because under copyright law, you can't add code to my program in the first place!"
I didn't claim that I was allowed under copyright law to add source code, I said that the loss of privacy for that code came from the GPL and not from copyright law.
"All restrictions on your use of my code stem from copyright law, and copyright law alone."
All restrictions on my right to keep my added source code secret stem from the GPL and from the GPL alone.
"It would be a violation of the GPL if you have agreed to it. If you have not agreed to it, it would be a violation of the copyright laws."
For distributing the GPL'd part of the code without a license, yes. For distributing your part of the code, no. Thus the owner of the GPL'd code could sue you for copyright violations but couldn't compel you to release your source code on the basis of copyright law.
This is analogous to what happens with proprietary software. If you sign a EULA, you're typically restricted from reverse engineering the code. If you don't sign it, you're in violation of copyright law, but the owner couldn't compel you to share any developments derived from the reverse engineering on the basis of copyright law.
In both GPL'd and proprietary software you don't have the right to distribute copyrighted material without a license under copyright law.
Most EULA's for proprietary software add additional requirements that are not covered by copywrite laws such as a restriction against reverse engineering.
The GPL adds the requirement that you must license you source under the GPL which also not part of copyright law and in fact takes away a right (keeping your own source code private) that you would otherwise have were it not for the GPL.
I'm not sure how effective this entire burden of proof argument would be in court, but I don't think the GPL could meet the standard without deletion of the "viral" language.
"The law is already quite clear on what a licensee is authorized to do under the terms of vanilla copyright. If the license gets nullified, then the defendant no longer has ANY right to create deriviative works."
Courts are not restricted to an all-or-nothing nullification of a contract. It's possible that the "viral" language could be nullified alone if you could convince the court that it's illegal or unreasonable. I'm not aware of a convincing argument, but it's possible in principle.
"Also, "well beyond copyright law" is not relevant."
Perhaps not in court, but the author's argument (which I was commenting on) was that somehow the GPL is more enforcable because it is less restrictive. I suspect he really wouldn't make that argument in court.
"Nullifying the priciple would also be far more damaging to commercial interests than the FSF. Suddenly, an entire industry that already headed for a crisis regarding revenue has to worry about whether or not what constitutes "payment" under their licenses is unreasonable."
There are already restrictions on what form of payment is allowed by law (you can't require sex as payment for example), so if "viral" payments were outlawed, it's not a given that other commonly used payment forms would be in jeopardy.
"Because the GPL (and presumably, other free/open software licenses) let the user do things that are otherwise illegal (copy and redistribute software), the GPL is in a stronger position to dictate terms."
The author doesn't offer any precedents that show that a court is more likely to enforce a license because it is less restrictive than other licenses.
In any case, the real issue for the GPL is the part that affects code that a licensee may add. Since the GPL requires that the source for new code must be distributed even though it was not created by the license holder, it goes well beyond copyright law.