I'm doing that with my books. O'Reilly does that for some of theirs, as well as other publishers. It really doesn't have that big of an impact on sales - it may even help them, in the same way that libraries help sales.
"The solutions were very elegant, but very difficult to debug and very difficult to reason about."
If you get the right mindset, recursive solutions as employed in scheme are very easy to reason about and get correct. The reason is that you can use formal proofs to _prove_ the correctness of your code. You can use the mathematic principles of induction to prove that your code is correct, but only in a purely functional atmosphere.
It takes a little getting used to if you are an imperative programmer, but its worthwhile.
However, I will say that the indentation practices of most Schemers is dreadful, and is one of the reasons why tab characters should not be directly equivalent with 8 characters. You see, if you make a tab equivalent to "arbitrary indentation of one level", then the user can set their own tab stops, and when a statement gets unwieldly and deep, you can just shorten the indentation to 1 or two spaces. But when you need some whitespace to view the algorithm better, you can expand it to 4 or 5, or even 8.
I bought this book about 6 months ago. I *love* it. The author did an excellent job showing many interesting algorithms. I did have to read it a few times to make sense of it, as I am not as engaged in the functional programming community as I would like. I still have trouble figuring out how to apply the banker's method and the physicist's method when determining the amortized performance of functional algorithms.
Anyway, the book was a great read. I was really surprised to learn how efficient some of the functional data structures could be.
Good discussion as well on the use of suspensions (lazy evaluation for specific blocks of code) in programming.
You forgot to mention fewer distractions. Green screen machines are entirely about GETTING WORK DONE, and not about feeling happy about yourself and playing solitaire.
It does not require them to distribute any part of the kernel for them to license their own portion of it for a fee.
Let's pretend that I wrote a proprietary program. Let's say that company X stole that code and put it into Linux. Let's then say that company X, company A, and company B all started redistributing Linux with my code, stolen by company X.
Instead of stopping distribution, I can say "I won't sue you if you instead buy a license from me". For this, it doesn't matter at all what license it was distributed under, because the license is not for the other people's part. The license is only for my part. And I can choose whatever terms I want.
Now, for this scenario to work, it would require valid, legitimate claims of copyright infringement. It would also require that the party who had their code stolen stop distributing said code the instant they found out about the theft. In addition, it would only affect distributors, not end-users, because the end-users aren't the ones copying the software (well, in the case of Linux, a lot of end-users copy the software, but you see what I mean - you can only violate copyright by making copies).
Wow! That is a very ingenious solution - one that I had not ever heard before. Noone likes giving money to the government, so this is almost self-limiting, too:)
There would definitely have to be some language dealing specifically with contingency cases and how those are dealt with, but yeah, this would be good.
The problem with "loser pays" is that it prevents people without money from getting justice, because the risk is too high.
What we really need are judges with the balls to throw more suits out of court and caps on punitive damages. Also, as a society, we need to understand, both socially and legally, that stuff just happens, and we need to get on in life.
"That would mean they couldn't sell any distributions of Linux"
Yes.
"and, subsequently, couldn't force people to buy licenses from them...right?"
No.
Let's assume, just for a second, that the justice system drinks the SCO kool-aid and believes that SCO code actually is present in Linux. SCO, although they cannot themselves redistribute Linux, can ask that others pay SCO to redistribute Linux if it contains their proprietary materials.
I think it's the statement that they have made publicly that the GPL is invalid. If they are redistributing nmap, and they don't believe the GPL is valid, then that means they haven't accepted the license and therefore cannot redistribute it.
Actually, I've found that employers are much easier to replace than employees. It takes 6-9 months to replace an employee, and that takes a LOT of time. In addition, they usually aren't up to full capacity for about 3 months, and in the first month they usually slow your operations down.
There are some jobs that aren't as hard to replace, but rarely in technology.
"But in practice an employe has to put up with whatever the employer decides. Unless he's got the support of a union."
Or decides to go into business for himself. Or decides to work for a more ethical company. Or decides to create a union.
I was specifically talking about uncollateralized debt, in which case, you can never know for sure if you can afford it.
There is no such thing as offset. Here is a true story (I forget the actual numbers, but the gist is true):
A man had an account into which he had put $90,000. He took out a loan for $50,000 from the same bank and put it into the account. This seems safe, right? Well, very soon afterwards the bank closed. His FDIC paid him $10,000 for the money in the account. However, he still owed the bank $50,000. There's no such thing as offset. The fact that he had more in the bank than he owed made no difference when they were settling accounts, and all of a sudden he went from having +$90,000 to -$40,000. Had he not borrowed, the worst he would have gone was $10,000.
The fact is, uncollateralized borrowing puts you into a different game - one which many win, in fact. However, it is always a burden, and it is always a controlling burden.
Hmmmmm.... free speech - gone if it sounds hateful. Freedom of religion - gone if it is done in public. Right to bear arms - gone.
Liberals tend to want to reinterpret the wording of the constitution to match modern ideas. However, that is circumventing the actual process for changing the constitution, which is the amendment process.
Look at the liberal judges on the supreme court - they are wanting to do a "dynamic interpretation" of the constitution - meaning that they don't like the way that it is written, so rather than wait for someone to go through the amendment process, they will just interpret it to match modern morals.
I don't call that defending the constitution, I call that corrupting the constitution. I think it was George Washington who said that anyone who tries to modify the constitution by any means other than the defined process is guilty of the greatest treason.
Or they could just be moving to Biblical values (that would be odd considering Steve Job's history, however).
Biblically, someone who takes on debt unless it is completely collateralized is considered a fool.
Oweing people money, even in business, has negative consequences. If life only existed on paper, then perhaps debt would not be such a bad thing. However, in real life, having debt limits your choices greatly, and makes you overly subject to the lender and to economic conditions surrounding you.
Relying on debt financing only works when interest rates are low. If your company is in a position where it relies on debt financing to generate profits, if interest rates rise sharply it can have a devastating effect on the company, while one which has been operating debt-free will be positively affected (if they can pay cash to their suppliers in times of high-interest, you can usually secure greatly better deals than those who always pay over time).
Anyway, all that to say that what works on paper is not necessarily what works out in real life, and having debt has more consequences than the pieces of paper show.
Apache was never GPL-compatible. The only shift _away_ from GPL was XFree86. Apache is actually shifting _towards_ GPL-compatibility, but the news story is that it still has terms that prevent that compatibility.
I think the problem is that if a third-party _adds_ documentation, they would also have to add the line. If you combined code from multiple sources, you would have to comb through each source file to find the appropriate references just to write documentation that you ship with the product. With the GPL, you only have to not mess with the existing copyright info to be okay.
Imagine you are a distributor who writes documnetation that ships as part of their distribution. With this new license, they would have to search out and find every attribution to include in their documentation.
You can mingle GPL and non-GPL code, as long as the non-GPL code is GPL-compatible. Therefore, you can mix BSD and GPL code, since BSD code can always be changed to GPL if someone wanted (hence it is GPL-compatible).
You're missing the point. They _know_ when the compromises took place. I had a project on Savannah, and when they discovered the backdoor, the had the CVS repository from backup from before the incident, and from after the incident. Each project leader was to compare the diffs between the two to make sure that there was no altered code.
'I don't recall any follow up determining, "Hey this happened X_TIME ago, therefore clean programs should be reinstalled on your machine."'
That's because the relevant teams _checked_ the code against known good code to see if there had been anything planted. If there were problems, you would have heard about them.
"Do OSS developers fix and test every permutation of a platform in a day or two? Because that's what Microsoft has to do."
They don't _have_ to. If they released source for their product, they could specify the source changes, and allow individual system administrators determine for themselves if the patch fixed their specific permutation of the problem.
That's the nature of open-source. We have the freedom to fix things ourselves when _we_ feel it needs to be fixed based on _our_ specific business needs and _our_ specific configurations. I don't have to wait for an external entity to give an official blessing for "all" permutations.
Please do not characterize all businesses with such a broad brush. At least distinguish publicly-held from privately-held companies, as privately-held companies often follow the morals of their owner, whatever they may be.
"It's bad to develop with real data, because you make assumptions about what kinda of data you have to process. You should unit test the code, by *trying* to break it by using known invalid formats or invalid data to ensure that your software handles such input inconsistancies gracefully."
That's not really what I'm talking about, though. For example, I've worked with databases where the CS department entered in all X's instead of physically deleting an address. Their programmers had simply coded to ignore records with all X's. If an outsourcer had been given a sample data set, it probably would not have indicated this odd fact.
There's lots of other examples. In most cases, it's easy to make something that fails gracefully or does something, but that's different than working correctly. For example, many datasets use "0" or "-1" instead of infinity. If your program treated -1's as invalid data or 0 or raised an error, it would cause real problems when run against real live data.
Also, when computerizing paper forms, there are lots of pieces of information that aren't listed on the form, but are required to be written in the margins anyway.
The HIPAA rules are nightmarish. I understand the need for basic privacy, but the requirements of HIPAA are rediculous. I have trouble getting the medical records to my four-year-old son! Plus the overhead involved in any sort of records transfer basically means that there is no point in using computers at all.
Actually, I've found that they don't. Fake databases usually are well-organized and thought out. The real deal usually has many, many inconsistencies that have to be dealt with. I always require real data to test any program I develop with, because otherwise it's just a nightmare at go-live time.
Slashdot Mirror
I'm doing that with my books. O'Reilly does that for some of theirs, as well as other publishers. It really doesn't have that big of an impact on sales - it may even help them, in the same way that libraries help sales.
Also, since this was this guy's thesis, it's also available online
See http://www-2.cs.cmu.edu/~rwh/theses/okasaki.pdf.
I suggest you get the book, however, as it's a great read.
"The solutions were very elegant, but very difficult to debug and very difficult to reason about."
If you get the right mindset, recursive solutions as employed in scheme are very easy to reason about and get correct. The reason is that you can use formal proofs to _prove_ the correctness of your code. You can use the mathematic principles of induction to prove that your code is correct, but only in a purely functional atmosphere.
It takes a little getting used to if you are an imperative programmer, but its worthwhile.
However, I will say that the indentation practices of most Schemers is dreadful, and is one of the reasons why tab characters should not be directly equivalent with 8 characters. You see, if you make a tab equivalent to "arbitrary indentation of one level", then the user can set their own tab stops, and when a statement gets unwieldly and deep, you can just shorten the indentation to 1 or two spaces. But when you need some whitespace to view the algorithm better, you can expand it to 4
or 5, or even 8.
I bought this book about 6 months ago. I *love* it. The author did an excellent job showing many interesting algorithms. I did have to read it a few times to make sense of it, as I am not as engaged in the functional programming community as I would like. I still have trouble figuring out how to apply the banker's method and the physicist's method when determining the amortized performance of functional algorithms.
Anyway, the book was a great read. I was really surprised to learn how efficient some of the functional data structures could be.
Good discussion as well on the use of suspensions (lazy evaluation for specific blocks of code) in programming.
You forgot to mention fewer distractions. Green screen machines are entirely about GETTING WORK DONE, and not about feeling happy about yourself and playing solitaire.
It does not require them to distribute any part of the kernel for them to license their own portion of it for a fee.
Let's pretend that I wrote a proprietary program. Let's say that company X stole that code and put it into Linux. Let's then say that company X, company A, and company B all started redistributing Linux with my code, stolen by company X.
Instead of stopping distribution, I can say "I won't sue you if you instead buy a license from me". For this, it doesn't matter at all what license it was distributed under, because the license is not for the other people's part. The license is only for my part. And I can choose whatever terms I want.
Now, for this scenario to work, it would require valid, legitimate claims of copyright infringement. It would also require that the party who had their code stolen stop distributing said code the instant they found out about the theft. In addition, it would only affect distributors, not end-users, because the end-users aren't the ones copying the software (well, in the case of Linux, a lot of end-users copy the software, but you see what I mean - you can only violate copyright by making copies).
Wow! That is a very ingenious solution - one that I had not ever heard before. Noone likes giving money to the government, so this is almost self-limiting, too :)
There would definitely have to be some language dealing specifically with contingency cases and how those are dealt with, but yeah, this would be good.
The problem with "loser pays" is that it prevents people without money from getting justice, because the risk is too high.
What we really need are judges with the balls to throw more suits out of court and caps on punitive damages. Also, as a society, we need to understand, both socially and legally, that stuff just happens, and we need to get on in life.
"That would mean they couldn't sell any distributions of Linux"
Yes.
"and, subsequently, couldn't force people to buy licenses from them...right?"
No.
Let's assume, just for a second, that the justice system drinks the SCO kool-aid and believes that SCO code actually is present in Linux. SCO, although they cannot themselves redistribute Linux, can ask that others pay SCO to redistribute Linux if it contains their proprietary materials.
I think it's the statement that they have made publicly that the GPL is invalid. If they are redistributing nmap, and they don't believe the GPL is valid, then that means they haven't accepted the license and therefore cannot redistribute it.
"Except that employees are easy to replace."
Actually, I've found that employers are much easier to replace than employees. It takes 6-9 months to replace an employee, and that takes a LOT of time. In addition, they usually aren't up to full capacity for about 3 months, and in the first month they usually slow your operations down.
There are some jobs that aren't as hard to replace, but rarely in technology.
"But in practice an employe has to put up with whatever the employer decides. Unless he's got the support of a union."
Or decides to go into business for himself. Or decides to work for a more ethical company. Or decides to create a union.
"If you can afford it, then it is positive."
I was specifically talking about uncollateralized debt, in which case, you can never know for sure if you can afford it.
There is no such thing as offset. Here is a true story (I forget the actual numbers, but the gist is true):
A man had an account into which he had put $90,000. He took out a loan for $50,000 from the same bank and put it into the account. This seems safe, right? Well, very soon afterwards the bank closed. His FDIC paid him $10,000 for the money in the account. However, he still owed the bank $50,000. There's no such thing as offset. The fact that he had more in the bank than he owed made no difference when they were settling accounts, and all of a sudden he went from having +$90,000 to -$40,000. Had he not borrowed, the worst he would have gone was $10,000.
The fact is, uncollateralized borrowing puts you into a different game - one which many win, in fact. However, it is always a burden, and it is always a controlling burden.
Defenders of the constitution?
Hmmmmm.... free speech - gone if it sounds hateful. Freedom of religion - gone if it is done in public. Right to bear arms - gone.
Liberals tend to want to reinterpret the wording of the constitution to match modern ideas. However, that is circumventing the actual process for changing the constitution, which is the amendment process.
Look at the liberal judges on the supreme court - they are wanting to do a "dynamic interpretation" of the constitution - meaning that they don't like the way that it is written, so rather than wait for someone to go through the amendment process, they will just interpret it to match modern morals.
I don't call that defending the constitution, I call that corrupting the constitution. I think it was George Washington who said that anyone who tries to modify the constitution by any means other than the defined process is guilty of the greatest treason.
Or they could just be moving to Biblical values (that would be odd considering Steve Job's history, however).
Biblically, someone who takes on debt unless it is completely collateralized is considered a fool.
Oweing people money, even in business, has negative consequences. If life only existed on paper, then perhaps debt would not be such a bad thing. However, in real life, having debt limits your choices greatly, and makes you overly subject to the lender and to economic conditions surrounding you.
Relying on debt financing only works when interest rates are low. If your company is in a position where it relies on debt financing to generate profits, if interest rates rise sharply it can have a devastating effect on the company, while one which has been operating debt-free will be positively affected (if they can pay cash to their suppliers in times of high-interest, you can usually secure greatly better deals than those who always pay over time).
Anyway, all that to say that what works on paper is not necessarily what works out in real life, and having debt has more consequences than the pieces of paper show.
Apache was never GPL-compatible. The only shift _away_ from GPL was XFree86. Apache is actually shifting _towards_ GPL-compatibility, but the news story is that it still has terms that prevent that compatibility.
I think the problem is that if a third-party _adds_ documentation, they would also have to add the line. If you combined code from multiple sources, you would have to comb through each source file to find the appropriate references just to write documentation that you ship with the product. With the GPL, you only have to not mess with the existing copyright info to be okay.
Imagine you are a distributor who writes documnetation that ships as part of their distribution. With this new license, they would have to search out and find every attribution to include in their documentation.
You can mingle GPL and non-GPL code, as long as the non-GPL code is GPL-compatible. Therefore, you can mix BSD and GPL code, since BSD code can always be changed to GPL if someone wanted (hence it is GPL-compatible).
You're missing the point. They _know_ when the compromises took place. I had a project on Savannah, and when they discovered the backdoor, the had the CVS repository from backup from before the incident, and from after the incident. Each project leader was to compare the diffs between the two to make sure that there was no altered code.
'I don't recall any follow up determining, "Hey this happened X_TIME ago, therefore clean programs should be reinstalled on your machine."'
That's because the relevant teams _checked_ the code against known good code to see if there had been anything planted. If there were problems, you would have heard about them.
Probably murdered by the record companies, who were pissed that an independent band got so popular.
"Do OSS developers fix and test every permutation of a platform in a day or two? Because that's what Microsoft has to do."
They don't _have_ to. If they released source for their product, they could specify the source changes, and allow individual system administrators determine for themselves if the patch fixed their specific permutation of the problem.
That's the nature of open-source. We have the freedom to fix things ourselves when _we_ feel it needs to be fixed based on _our_ specific business needs and _our_ specific configurations. I don't have to wait for an external entity to give an official blessing for "all" permutations.
Please do not characterize all businesses with such a broad brush. At least distinguish publicly-held from privately-held companies, as privately-held companies often follow the morals of their owner, whatever they may be.
"It's bad to develop with real data, because you make assumptions about what kinda of data you have to process. You should unit test the code, by *trying* to break it by using known invalid formats or invalid data to ensure that your software handles such input inconsistancies gracefully."
That's not really what I'm talking about, though. For example, I've worked with databases where the CS department entered in all X's instead of physically deleting an address. Their programmers had simply coded to ignore records with all X's. If an outsourcer had been given a sample data set, it probably would not have indicated this odd fact.
There's lots of other examples. In most cases, it's easy to make something that fails gracefully or does something, but that's different than working correctly. For example, many datasets use "0" or "-1" instead of infinity. If your program treated -1's as invalid data or 0 or raised an error, it would cause real problems when run against real live data.
Also, when computerizing paper forms, there are lots of pieces of information that aren't listed on the form, but are required to be written in the margins anyway.
NOOOOOOOO!!!!!!
The HIPAA rules are nightmarish. I understand the need for basic privacy, but the requirements of HIPAA are rediculous. I have trouble getting the medical records to my four-year-old son! Plus the overhead involved in any sort of records transfer basically means that there is no point in using computers at all.
Actually, I've found that they don't. Fake databases usually are well-organized and thought out. The real deal usually has many, many inconsistencies that have to be dealt with. I always require real data to test any program I develop with, because otherwise it's just a nightmare at go-live time.