But chances are, you are seeding to many, many individual copies of the same song, sometimes as many as thousands over the course of a download.
You think file sharers upload thousands of times as much as they download? That makes absolutely no sense.
Who are they uploading to... and which thousand people do those recipients upload to? On average (and this is very simple to prove), each sharer uploads about one copy for each copy they download. Slightly less than one copy, actually.
That's a full copy, of course, and since uploads and downloads are done in smaller segments, it's certainly possible that an individual has uploaded chunks of a given file to more people. Perhaps as many as 20 or 30 (could be more for video files, which are much larger, but given the relatively small size of music files, it doesn't make sense to break them up that much). So, even if you valued each chunk as much as the whole song, you're still only talking about damages of 20-30 dollars. Call it willful infringement and treble the damages, and you're *still* less than $100 per song.
There's just no realistic justification for damages on the level the RIAA is demanding. Of course, the problem is that the law authorizes those insane damages, because the law was written to address high-volume, commercial pirates where those damages do make sense. But they're unjust for non-commercial file sharing, and the courts should address that unfairness. And that *is* a legitimate role of the courts.
I won't even get into the thoughts of being stuck with the same chick for the rest of my life....[shudder]
IMO, that is absolutely, without question, the BEST part of "settling down". Maybe you just haven't met the right woman. Or maybe you're the unusual one who really isn't cut out for a long-term relationship. I obviously don't know you from Adam:-)
As for the rest of it, having a family doesn't preclude travel, or working in a large variety of areas, or really any of the rest of what you mentioned. I'll bet I've traveled significantly more than you have, for example.
Think you'll be able to find a USB port in 70 years? SATA or PATA?
Why would that matter? I don't have an 8" floppy drive (or a 5.25", or a 3.5") but I still have all my old files from when I used 8" floppies (including a lot of files I can't read because they were in proprietary formats).
You don't need copyright protection at all in that case, since you're the only person who can possibly be you playing your music.
Whaaat? That would imply that no band does a cover of another band's song.
You're confusing "performance" with "composition". When band A covers band B's song, A is doing their own performance, and they own the copyright on it, of band B's composition, which B owns the copyright on.
The GP was pointing out that there's little value in performance copyright, because no one else can play your performance.
statistics show that married people (men and women) are happier, healthier, have more sex (in spite of the stereotype) and live longer than single people
What do the statistics say about married people with children versus those without children?
I haven't seen any. They would be interesting.
My theory is that any premature aging caused by having children is more than counteracted by having grandchildren:-)
Your proposed scheme is insufficient because it can be circumvented by truncating the document up to the point where a page is to be inserted, removed or altered, performing the insertion, removal or alteration, then re-inserting the contents for each subsequent page with new hashes.
There are numerous ways to address this. I mentioned a few in another post in this thread, and I'm sure you can come up with many more.
Theoretically, there could be a vulnerability where data spans more than one logbook, but the practical limits on the speed of manual data entry and the availability of forensic methods for inspecting physical logs mitigates the risk of undetected tampering.
It mitigates the risk if the attacker isn't willing to work hard.
Now consider that you might not have access to a computer, or even a calculator. Have fun doing THAT all by hand.
Why in the world would you not have access to a computer?
But under the existing method, anyone of even moderate intelligence could still verify the material had not been tampered with.
No, they could verify that no one who wasn't willing to go to a great deal of effort had tampered with it. Someone who's willing to rewrite the whole log book can replace it.
Teenage girls blossom earlier for one reason: calories.
Menses is largely dependant on having sufficient calories, both intake and stored(approaching 20% bodyfat), and estrogen. Fat also emits estrogen, so fat kids means earlier menarche.
Very interesting. This explanation that has a ring of truth to it. Among other things, it's elegantly simple (Occam's Razor), and it explains so many different observations. Also, it makes a great deal of sense in evolutionary terms: Selection for early childbearing among females who are well-fed makes sense, as does selection for later childbearing among those who aren't.
On the other hand, the average age of menarche has only changed by maybe 3 or 4 months in the last 30 years.
The median hasn't changed much, but I wonder about the variance. As the article mentions, the older data didn't include enough information to characterize more than the change in the median.
I don't look down on your for your choices, but, to say one must have that 'traditional' home with wife and kids to be a complete person is just plain nonsense. Different strokes for different folks...
I don't look down on you for your choices, but you should consider that a man who is married and has children has seen both sides of that question from the "inside", as it were, and has a more informed perspective than you do. More compellingly, statistics show that married people (men and women) are happier, healthier, have more sex (in spite of the stereotype) and live longer than single people. It's certainly possible that you are just wired differently from most, and are one of those who is better off single.
It's also possible that you're just missing out. In fact, I think it's more likely.
Unfortunately, there's really no way for you to know for sure without acquiring a "millstone" or two. And the thing that sucks about that is that if you're right you're then going to have to be unhappy for a long time, or else you're going to have to get a divorce. That's not too bad if you don't have kids, but if you do it's really unfortunate.
I'm not suggesting that a log not be kept. Just that there are better methods than writing it longhand in a bound book. Methods that would better satisfy a legal requirement for integrity assurance. Of course, they wouldn't satisfy a legal requirement for a bound, handwritten log book, if that's how the legal requirement is stated.
The whole document can still be altered, unless timestamps are included. But then you have to rely on some external service to stay in business.
A whole log book can be replaced, also.
But the hash-based approach can be secured against that, and timestamps are only one option. Another is to periodically take the current hash and "fix" it. You can use any of various mechanisms to fix it -- you can publish it somewhere non-modifiable, get it signed by a timestamping service, put it in a letter and mail it to yourself (to get the postmark timestamp), etc. The sky's really the limit. Perhaps the best approach is to periodically send the hash to the regulator who cares.
You could even write the hash in a bound log book.
You can also use any of those methods to fix the hashes of a whole department or company. Take every log's current hash, put them all in a list, hash the list and fix that hash.
Technology provides much better solutions with higher survivability, better accessiblity, easier production and much, much higher integrity verification.
26 year old people are just old enough to have learned to write before computers. If they can't, it's the school, not the keyboard.
Huh? I just turned 40 and I first used a computer in 5th grade, at age 10. By age 15 (when your 26 year-old was having his first birthday), I did nearly all of my school assignments on a computer, and was taking word processing and programming (using Turbo Pascal!).
I should note that what poor handwriting skills I had upon graduation from public schools has deteriorated to almost nil. My signature held out for a while, but once the volume of required signatures reached a certain point, I stopped trying for anything but a relatively consistent illegible scrawl there as well.
Nope, I can't use a printer. Good thinking, but it just won't suit legal criteria.
I am required to use a bound book. That means that pages cannot be added or removed without making it obvious.
Is the legal requirement that you use a bound book, or ensure that pages cannot be added or removed without it being obvious?
If the latter, then one-way hashes are a MUCH more reliable indicator. On the bottom of each page, print the hash of the previous page, the hash of that page and the hash of the hashes. This will ensure that not only can no page be added or removed, but no page can be altered, either.
To make it even better, use a secure timestamping service and include the timestamp.
Also, I strongly dispute your original assertion that no computer format will be readable in 70+ years. Plain ASCII text will. HTML will (ASCII encoding). Also, basically any format with an open standard and open source implementations will.
Finally, your log book is far too easy to lose, damage or destroy. It's not feasible to copy it (not without losing the integrity features provided by the bound book), so it can't be backed up. It's also bulky.
Your logging problem is solved by the log book, barely. Technology provides much better solutions with higher survivability, better accessiblity, easier production and much, much higher integrity verification.
This solution could include registering source code but it might be better to protect a "program" or "solution" than to try to protect source code as if it is some kind of literary work, and then extend that to the compiled version of that source code
My preferred solution to exactly the issue you mention (thanks for bringing it up, BTW, too few people understand it) is to require publication of source in order to receive copyright protection. That may seem a little radical, but only because it's not what we're used to.
Given the tools we have today for cross-checking of code, if every company publishing software also published the source, tracking down copyright infringement would be trivial. Some companies already use such tools to verify that their software doesn't contain any Free Software, or at least any from a large corpus gleaned from sourceforge and the like.
In addition, the fact is that source code really isn't as valuable as it's often thought to be. If source were all you need, Red Hat wouldn't be in business. A group within IBM has recently begun to pilot an "open source commercial software" approach: The new Rational Team Concert and related tools are all available as source code -- but the software is still commercial and you may not legally use it without buying a license. And yet the products are expensive and highly profitable, and the publication of the source does not appear to impact sales in the slightest -- except perhaps to improve sales because customers appreciate the openness.
In a world where companies had to publish source in order to acquire copyright protection, those rare cases where the code actually is so innovative and so unique that it has to be kept secret could be handled as trade secrets, forgoing copyright protection in favor of contractual protections.
About the only case where this might really break down is if a company "borrowed" another's code, incorporated it into their own and published it as a trade secret. But just as misusers of GPL code today often get caught, these folks would also often get caught, whether through telltale traces left in the binary or through the actions of a whistleblower. If the law provided legal protections for whistleblowers and perhaps a nice percentage of any damages assessed the infringer, enough to make whistleblowing very lucrative, I think such cases would be kept to a minimum.
Some might think that the system would break down in cases where company B studies company A's source to learn how A accomplished some clever thing but, in fact, that's not a breakdown, that's the system working as intended. Authors improve their skills by reading others' books, and programmers should be able to improve their skills by reading others' code. That's how copyright is supposed to work -- to foster the spread of ideas and knowledge.
Trust is neither required nor desired in business. Much more reliable to trust persuit of self-interest. Business is not family life. There are no bonds of affection. Delusional to pretend there are.
That's crap. Trust is essential in smooth business dealings. You can do business with a business partner you can't trust, but it's a hundred times harder. The contracts get horrendously long and complicated, the oversight creates huge overhead and the experience ends up being really unpleasant for all of the people involved. And if you end up in court... that's a huge time and money sink.
So businesses like to establish long-term, amicable relationships with business partners exactly so that they can rely on trust, to loosen up the contracts, smooth out the communication and be able to have confidence that the other party will make good on their promises. Good businessmen understand the limits of trust, but they also understand its advantages. Why do you think business partners eat together, play golf together, etc.? It's precisely to build personal human-to-human relationships to build the trust that's necessary to doing business together effectively. Even better is the experience of doing business together for years, with a joint understanding that both sides will benefit if the relationship continues to be healthy.
This notion is taken to an extreme in the Japanese "Keiretsu", but it's a common feature of nearly all businesses that are successful in the long term. Partnerships matter, and they're built on trust.
...Sued by who? You see, the main problem with open source and people suing over the GPL is because a lot of the things that are GPL'd come from people like you and me. I know for a fact that if my code was taken by MS or any other large company the most I could probably do is write them a stern letter.
You have more options than that. The FSF will in many cases step in to help, with their resources. You may want to consider assigning your copyrights to the FSF so that they have legal standing to intervene directly. They won't always be interested in helping, because their resources are limited, but I guarantee that if a high-profile company like MS was violating the GPL, they'd be all over it.
You might consider adding the ability to distinguish nearline storage. That way you could add computers around the home as devices that could be backed up to and restored from quickly, but that there would still be remote computers will full copies of the backup.
That is part of my longer-term plans, though not exactly for the reasons you suggest. My main reason for adding a nearline storage layer is to address the fact that most people use laptops these days, and although my solution does a very good job of allowing backups to be interruptible, backing laptops up directly to the grid would require leaving them turned on and connected for large amounts of time.
Also, fairness requires that you provide as much storage to the grid as what you're consuming from the grid. But you can't use an intermittently connected laptop as a storage node. Or, at least, it's would be a pretty unreliable storage node.
My solution to that is to back laptops up to nearline, always-on storage at LAN/WLAN speeds and then have that trickle the data up to the grid at ADSL/Cable speeds. In particular I want to take OpenWrt or similar and add a Tahoe client node, so that you can attach, say, a 1 TB USB drive to your wireless router and use it as nearline backup plus give it responsibility for getting the data pushed out to the grid. And it will also act as a storage node in the grid.
Using the default parameters, a 1 TB drive would give you about 230 GB of nearline backup, plus would provide your contribution to the grid for online backup of that much data (storing 770 GB of others' encoded data). So for the default encoding parameters, you'd need 4.33x as much nearline storage as what you're going to back up and that would effectively give you 4.33 backups of every file, one of them nearline and the others offsite. Less conservative parameters would reduce that amount.
I'm curious how you are doing rsync diffs for encrypted Reed-Solomon fragments.
I do the diffs on the files before encryption and FEC (Forward Error Correction) encoding. Because the storage servers cannot decrypt the files, there's obviously no way to "patch" the backed-up files, so the diffs have to be stored as a chain of forward deltas. Forward deltas suck for many reasons, but particularly they damage reliability, since the loss of any delta in the chain means that all subsequent versions are lost as well. I'm currently addressing this by limiting the length of the delta chain before uploading a new full version, but my plan eventually is to make those decisions statistically.
I have written an incomplete paper describing how to calculate loss probabilities in a distributed, FEC-based grid, and I eventually plan to offer GridBackup users the option to set their desired reliability level, with some description of the impact it will have on upload times, storage used, etc. I'll then use that reliability figure to automatically select FEC encoding parameters, and to choose when to break delta chains, so that the user's reliability requirement is met.
The other major downside of forward deltas is that if the chain is long enough, it can take much more time to download the chain than it would to download a final version. Because of the ADSL/Cable asymmetry, my design focuses on optimizing upload performance, but when I move to using statistical criteria for chain-breaking decisions, I'll also do some size calculations. The Mercurial developers (Mercurial also uses forward deltas) have found that a good rule of thumb is that when the size of the delta chain exceeds twice the size of the full version, it's time to break the chain.
Oh, you may also have been asking about how I create the diffs efficiently. I store local copies of the rsync file "signatures" for files that have been backed up into t
Slashdot Mirror
But chances are, you are seeding to many, many individual copies of the same song, sometimes as many as thousands over the course of a download.
You think file sharers upload thousands of times as much as they download? That makes absolutely no sense.
Who are they uploading to... and which thousand people do those recipients upload to? On average (and this is very simple to prove), each sharer uploads about one copy for each copy they download. Slightly less than one copy, actually.
That's a full copy, of course, and since uploads and downloads are done in smaller segments, it's certainly possible that an individual has uploaded chunks of a given file to more people. Perhaps as many as 20 or 30 (could be more for video files, which are much larger, but given the relatively small size of music files, it doesn't make sense to break them up that much). So, even if you valued each chunk as much as the whole song, you're still only talking about damages of 20-30 dollars. Call it willful infringement and treble the damages, and you're *still* less than $100 per song.
There's just no realistic justification for damages on the level the RIAA is demanding. Of course, the problem is that the law authorizes those insane damages, because the law was written to address high-volume, commercial pirates where those damages do make sense. But they're unjust for non-commercial file sharing, and the courts should address that unfairness. And that *is* a legitimate role of the courts.
I won't even get into the thoughts of being stuck with the same chick for the rest of my life....[shudder]
IMO, that is absolutely, without question, the BEST part of "settling down". Maybe you just haven't met the right woman. Or maybe you're the unusual one who really isn't cut out for a long-term relationship. I obviously don't know you from Adam :-)
As for the rest of it, having a family doesn't preclude travel, or working in a large variety of areas, or really any of the rest of what you mentioned. I'll bet I've traveled significantly more than you have, for example.
Think you'll be able to find a USB port in 70 years? SATA or PATA?
Why would that matter? I don't have an 8" floppy drive (or a 5.25", or a 3.5") but I still have all my old files from when I used 8" floppies (including a lot of files I can't read because they were in proprietary formats).
You don't need copyright protection at all in that case, since you're the only person who can possibly be you playing your music.
Whaaat? That would imply that no band does a cover of another band's song.
You're confusing "performance" with "composition". When band A covers band B's song, A is doing their own performance, and they own the copyright on it, of band B's composition, which B owns the copyright on.
The GP was pointing out that there's little value in performance copyright, because no one else can play your performance.
statistics show that married people (men and women) are happier, healthier, have more sex (in spite of the stereotype) and live longer than single people What do the statistics say about married people with children versus those without children?
I haven't seen any. They would be interesting.
My theory is that any premature aging caused by having children is more than counteracted by having grandchildren :-)
Your proposed scheme is insufficient because it can be circumvented by truncating the document up to the point where a page is to be inserted, removed or altered, performing the insertion, removal or alteration, then re-inserting the contents for each subsequent page with new hashes.
There are numerous ways to address this. I mentioned a few in another post in this thread, and I'm sure you can come up with many more.
Theoretically, there could be a vulnerability where data spans more than one logbook, but the practical limits on the speed of manual data entry and the availability of forensic methods for inspecting physical logs mitigates the risk of undetected tampering.
It mitigates the risk if the attacker isn't willing to work hard.
Now consider that you might not have access to a computer, or even a calculator. Have fun doing THAT all by hand.
Why in the world would you not have access to a computer?
But under the existing method, anyone of even moderate intelligence could still verify the material had not been tampered with.
No, they could verify that no one who wasn't willing to go to a great deal of effort had tampered with it. Someone who's willing to rewrite the whole log book can replace it.
Teenage girls blossom earlier for one reason: calories.
Menses is largely dependant on having sufficient calories, both intake and stored(approaching 20% bodyfat), and estrogen. Fat also emits estrogen, so fat kids means earlier menarche.
Very interesting. This explanation that has a ring of truth to it. Among other things, it's elegantly simple (Occam's Razor), and it explains so many different observations. Also, it makes a great deal of sense in evolutionary terms: Selection for early childbearing among females who are well-fed makes sense, as does selection for later childbearing among those who aren't.
On the other hand, the average age of menarche has only changed by maybe 3 or 4 months in the last 30 years.
The median hasn't changed much, but I wonder about the variance. As the article mentions, the older data didn't include enough information to characterize more than the change in the median.
I don't look down on your for your choices, but, to say one must have that 'traditional' home with wife and kids to be a complete person is just plain nonsense. Different strokes for different folks...
I don't look down on you for your choices, but you should consider that a man who is married and has children has seen both sides of that question from the "inside", as it were, and has a more informed perspective than you do. More compellingly, statistics show that married people (men and women) are happier, healthier, have more sex (in spite of the stereotype) and live longer than single people. It's certainly possible that you are just wired differently from most, and are one of those who is better off single.
It's also possible that you're just missing out. In fact, I think it's more likely.
Unfortunately, there's really no way for you to know for sure without acquiring a "millstone" or two. And the thing that sucks about that is that if you're right you're then going to have to be unhappy for a long time, or else you're going to have to get a divorce. That's not too bad if you don't have kids, but if you do it's really unfortunate.
Big gamble.
Just because it's all in someone's head doesn't mean they aren't suffering from it.
No, but it does mean that you don't need to get rid of WiFi to eliminate their suffering -- you need to fix their head.
I'm not suggesting that a log not be kept. Just that there are better methods than writing it longhand in a bound book. Methods that would better satisfy a legal requirement for integrity assurance. Of course, they wouldn't satisfy a legal requirement for a bound, handwritten log book, if that's how the legal requirement is stated.
The whole document can still be altered, unless timestamps are included. But then you have to rely on some external service to stay in business.
A whole log book can be replaced, also.
But the hash-based approach can be secured against that, and timestamps are only one option. Another is to periodically take the current hash and "fix" it. You can use any of various mechanisms to fix it -- you can publish it somewhere non-modifiable, get it signed by a timestamping service, put it in a letter and mail it to yourself (to get the postmark timestamp), etc. The sky's really the limit. Perhaps the best approach is to periodically send the hash to the regulator who cares.
You could even write the hash in a bound log book.
You can also use any of those methods to fix the hashes of a whole department or company. Take every log's current hash, put them all in a list, hash the list and fix that hash.
Technology provides much better solutions with higher survivability, better accessiblity, easier production and much, much higher integrity verification.
Technically, yes. But really?
Technically and really.
26 year old people are just old enough to have learned to write before computers. If they can't, it's the school, not the keyboard.
Huh? I just turned 40 and I first used a computer in 5th grade, at age 10. By age 15 (when your 26 year-old was having his first birthday), I did nearly all of my school assignments on a computer, and was taking word processing and programming (using Turbo Pascal!).
I should note that what poor handwriting skills I had upon graduation from public schools has deteriorated to almost nil. My signature held out for a while, but once the volume of required signatures reached a certain point, I stopped trying for anything but a relatively consistent illegible scrawl there as well.
Nope, I can't use a printer. Good thinking, but it just won't suit legal criteria.
I am required to use a bound book. That means that pages cannot be added or removed without making it obvious.
Is the legal requirement that you use a bound book, or ensure that pages cannot be added or removed without it being obvious?
If the latter, then one-way hashes are a MUCH more reliable indicator. On the bottom of each page, print the hash of the previous page, the hash of that page and the hash of the hashes. This will ensure that not only can no page be added or removed, but no page can be altered, either.
To make it even better, use a secure timestamping service and include the timestamp.
Also, I strongly dispute your original assertion that no computer format will be readable in 70+ years. Plain ASCII text will. HTML will (ASCII encoding). Also, basically any format with an open standard and open source implementations will.
Finally, your log book is far too easy to lose, damage or destroy. It's not feasible to copy it (not without losing the integrity features provided by the bound book), so it can't be backed up. It's also bulky.
Your logging problem is solved by the log book, barely. Technology provides much better solutions with higher survivability, better accessiblity, easier production and much, much higher integrity verification.
Forcing release of source would destroy the entire PC gaming market in one fell swoop.
How so?
This solution could include registering source code but it might be better to protect a "program" or "solution" than to try to protect source code as if it is some kind of literary work, and then extend that to the compiled version of that source code
My preferred solution to exactly the issue you mention (thanks for bringing it up, BTW, too few people understand it) is to require publication of source in order to receive copyright protection. That may seem a little radical, but only because it's not what we're used to.
Given the tools we have today for cross-checking of code, if every company publishing software also published the source, tracking down copyright infringement would be trivial. Some companies already use such tools to verify that their software doesn't contain any Free Software, or at least any from a large corpus gleaned from sourceforge and the like.
In addition, the fact is that source code really isn't as valuable as it's often thought to be. If source were all you need, Red Hat wouldn't be in business. A group within IBM has recently begun to pilot an "open source commercial software" approach: The new Rational Team Concert and related tools are all available as source code -- but the software is still commercial and you may not legally use it without buying a license. And yet the products are expensive and highly profitable, and the publication of the source does not appear to impact sales in the slightest -- except perhaps to improve sales because customers appreciate the openness.
In a world where companies had to publish source in order to acquire copyright protection, those rare cases where the code actually is so innovative and so unique that it has to be kept secret could be handled as trade secrets, forgoing copyright protection in favor of contractual protections.
About the only case where this might really break down is if a company "borrowed" another's code, incorporated it into their own and published it as a trade secret. But just as misusers of GPL code today often get caught, these folks would also often get caught, whether through telltale traces left in the binary or through the actions of a whistleblower. If the law provided legal protections for whistleblowers and perhaps a nice percentage of any damages assessed the infringer, enough to make whistleblowing very lucrative, I think such cases would be kept to a minimum.
Some might think that the system would break down in cases where company B studies company A's source to learn how A accomplished some clever thing but, in fact, that's not a breakdown, that's the system working as intended. Authors improve their skills by reading others' books, and programmers should be able to improve their skills by reading others' code. That's how copyright is supposed to work -- to foster the spread of ideas and knowledge.
I'm not touching anyone.
And we appreciate that.
Bah. Who cares about petty ego issues? And the EFF has no interest in defending the GPL, so assigning to them would do no good.
It doesn't prevent a third (non-contributing) party from claiming infringement on a given patent.
Of course not. How could it bind a third party who never accepted the license terms?
I don't think that v3 has had the intended effect, and will in the end not be very widely popular.
I find lots and lots of projects going to v3.
Trust is built on well defined business contracts and agreements.
Those are necessary, but not sufficient. There's always a way to weasel out of your obligations to some extent, if you really want to.
Trust is neither required nor desired in business. Much more reliable to trust persuit of self-interest. Business is not family life. There are no bonds of affection. Delusional to pretend there are.
That's crap. Trust is essential in smooth business dealings. You can do business with a business partner you can't trust, but it's a hundred times harder. The contracts get horrendously long and complicated, the oversight creates huge overhead and the experience ends up being really unpleasant for all of the people involved. And if you end up in court... that's a huge time and money sink.
So businesses like to establish long-term, amicable relationships with business partners exactly so that they can rely on trust, to loosen up the contracts, smooth out the communication and be able to have confidence that the other party will make good on their promises. Good businessmen understand the limits of trust, but they also understand its advantages. Why do you think business partners eat together, play golf together, etc.? It's precisely to build personal human-to-human relationships to build the trust that's necessary to doing business together effectively. Even better is the experience of doing business together for years, with a joint understanding that both sides will benefit if the relationship continues to be healthy.
This notion is taken to an extreme in the Japanese "Keiretsu", but it's a common feature of nearly all businesses that are successful in the long term. Partnerships matter, and they're built on trust.
Don't give up hope — I hear they are working on a GNU vaccine.
They were: patents. But the virus has evolved and the v3 strain is resistant.
... on slashdot than post-menopausal women, I don't know what it would be.
...Sued by who? You see, the main problem with open source and people suing over the GPL is because a lot of the things that are GPL'd come from people like you and me. I know for a fact that if my code was taken by MS or any other large company the most I could probably do is write them a stern letter.
You have more options than that. The FSF will in many cases step in to help, with their resources. You may want to consider assigning your copyrights to the FSF so that they have legal standing to intervene directly. They won't always be interested in helping, because their resources are limited, but I guarantee that if a high-profile company like MS was violating the GPL, they'd be all over it.
You might consider adding the ability to distinguish nearline storage. That way you could add computers around the home as devices that could be backed up to and restored from quickly, but that there would still be remote computers will full copies of the backup.
That is part of my longer-term plans, though not exactly for the reasons you suggest. My main reason for adding a nearline storage layer is to address the fact that most people use laptops these days, and although my solution does a very good job of allowing backups to be interruptible, backing laptops up directly to the grid would require leaving them turned on and connected for large amounts of time.
Also, fairness requires that you provide as much storage to the grid as what you're consuming from the grid. But you can't use an intermittently connected laptop as a storage node. Or, at least, it's would be a pretty unreliable storage node.
My solution to that is to back laptops up to nearline, always-on storage at LAN/WLAN speeds and then have that trickle the data up to the grid at ADSL/Cable speeds. In particular I want to take OpenWrt or similar and add a Tahoe client node, so that you can attach, say, a 1 TB USB drive to your wireless router and use it as nearline backup plus give it responsibility for getting the data pushed out to the grid. And it will also act as a storage node in the grid.
Using the default parameters, a 1 TB drive would give you about 230 GB of nearline backup, plus would provide your contribution to the grid for online backup of that much data (storing 770 GB of others' encoded data). So for the default encoding parameters, you'd need 4.33x as much nearline storage as what you're going to back up and that would effectively give you 4.33 backups of every file, one of them nearline and the others offsite. Less conservative parameters would reduce that amount.
I'm curious how you are doing rsync diffs for encrypted Reed-Solomon fragments.
I do the diffs on the files before encryption and FEC (Forward Error Correction) encoding. Because the storage servers cannot decrypt the files, there's obviously no way to "patch" the backed-up files, so the diffs have to be stored as a chain of forward deltas. Forward deltas suck for many reasons, but particularly they damage reliability, since the loss of any delta in the chain means that all subsequent versions are lost as well. I'm currently addressing this by limiting the length of the delta chain before uploading a new full version, but my plan eventually is to make those decisions statistically.
I have written an incomplete paper describing how to calculate loss probabilities in a distributed, FEC-based grid, and I eventually plan to offer GridBackup users the option to set their desired reliability level, with some description of the impact it will have on upload times, storage used, etc. I'll then use that reliability figure to automatically select FEC encoding parameters, and to choose when to break delta chains, so that the user's reliability requirement is met.
The other major downside of forward deltas is that if the chain is long enough, it can take much more time to download the chain than it would to download a final version. Because of the ADSL/Cable asymmetry, my design focuses on optimizing upload performance, but when I move to using statistical criteria for chain-breaking decisions, I'll also do some size calculations. The Mercurial developers (Mercurial also uses forward deltas) have found that a good rule of thumb is that when the size of the delta chain exceeds twice the size of the full version, it's time to break the chain.
Oh, you may also have been asking about how I create the diffs efficiently. I store local copies of the rsync file "signatures" for files that have been backed up into t