> And yet the FSF went to great lengths to permit it in some cases (the business use exception)
I don't see that the language of GPLv3 actually permits it. Since a number of people (myself included) believe that GPLv2 didn't permit tivoization of any devices whatsoever, GPLv3 is no different as far as products that don't qualify as "user products" are concerned.
It's good to see Canonical following our advice, even if in such a limited way and not necessarily for the right reasons... A step in the right direction nevertheless.
Interestingly, we didn't know about Tom Clancy's fifth freedom when we wrote the editorial in the URL above. That's too bad, because it fits. Oh well...
> What Tivo done so wrong? It is market, for fucking sake, go after some other such box who has a) Linux underneath and it b) allows hacking.
They're in violation of the spirit of the license, and some understand that it's also in violation of the letter of the license.
How is your argument any different from: `so that person created an unathorized copy a CD or DVD. Why doesn't Hollywood go after someone else who *is* willing to pay for the license, then, instead of persecuting the person who violated the license?'
> DRM is NOTHING, it is just copyright protection.
No, it is abuse of law provisions to remove rights that, by law, you're entitled to have. Go read on fair use and on how DRM stops you from exercising your rights.
Besides, GPLv3 is not about forbidding implementations of DRM, it's about the same spirit GPLv2 had: ensuring that anyone who modifies or distributes the software respects the 4 freedoms of anyone else who gets a copy of the software. One such freedom is the right to adapt the software to suit your needs. Which is to say that, if there's an implementation in there that gets in the way of something you can lawfully do, you're free to remove it, and the copyright holder won't get it the way.
There's no opposition to trusted computing technology. The opposition is to treacherous computing technology, that technology designed to take away from the users the control over their own machines.
How could you possibly do trusted computing research and development if you can't say replace the lower portions of the software that implements the trusted computing machinery because the trusted computing machinery in place won't permit you to do it because you're not one of the few authorized entities to do so?
> "but given that Ubuntu is already obligated to continue to distribute source code for as long as we distribute binaries, it's possible that we could offer that kind of assistance if it would help.'
So they're willing to take up the requirement of keeping the sources around for at least 3 years longer than they would otherwise have to, just for the benefit of derived distros? That's a pretty nice gesture! I hope they do realize what they're offering to do:-)
We had similar debates over the past year or so in Brazil, about creating a license in the spirit of the GNU GPL, but adapted to Brazilian law. Heck, there is even a license that was proposed to that end.
Anyhow... Creating new licenses to duplicate the spirit of the GPL is pointless. Either they're compatible with the GPL and can irreversibly decay to it, defeating the point of the license adapted to local legislation, or it's incompatible and you're stuck out of the worldwide Free Software community, having to reinvent it all from scratch.
If you must, work on a (semi-?)official translation, and/or work to get the legislation to support the concept of Free Software licenses that are valid worldwide.
Translations of the GPL will likely fit well into any legal system, since the GPL doesn't take any rights away. Changing legislation can be trickier, but as governments look into adopting Free Software, the need for making sure the software they use, developed by a worldwide community, has a clear legal status, can be used to help promote the legal changes.
In Brazil, we ended up with a legal translation of the GNU GPL, registered in Creative Commons, and, in spite of all the initial noise about fundamental incompatibilities of the GNU GPL with the local law, they all turned out to be misunderstandings of the original license. I'd strongly advise France and any other countries to follow this path, if at all possible.
> In contrast, the GPL boils down to: "Here's the source code. You can use it if you want but then you must make it and your derivatives based on it available to the public.
Not true. This is the sort of claim that proprietary software compaines like to make to confuse people away from free software. You don't have to make the source code and its derivatives available to the public. You have to make it available to those who get the binaries. If you don't distribute it, you don't make anything public. If you distribute it to someone, you give them the sources and it's done, or a written offer valid for at least 3 years that grants them or anyone else the rights to demand the sources from you, granting them the same rights to see, modify and distribute the code, modified or not, that you had, along with the same requirements.
It's been deprecated for several releases and, AFAIK, it was the only non-free package in the distribution. Non-free in that it didn't allow modified versions to be distributed, mind you. I'm happy to see it go.
> tripwire
You want it? Cool, make sure you get involved with the RHL project and volunteer to maintain the package! It's needed some nice defaults for the distro for a while. The configuration files that shipped weren't useful except for inspiration in creating your own.
> postgresql72
[aoliva@free aoliva]$ cat/etc/redhat-release Red Hat Linux release 9.0.93 (Severn) [aoliva@free aoliva]$ rpm -q postgresql postgresql-7.3.3-4
Wouldn't having ADV: as the first 4 characters of the subject like make it no longer a Subject: line, because you can't have it start with both Subject: and ADV:? It seems to me that this proposal actually makes any form of spam illegal, since it's impossible to meet this requirement. Wheee!
> democracy is one person, one vote, to elect a *ruling party* who then govern the country.
What you describe is representative democracy. Democracy, from its Greek roots, means `government by the people', and I'm told that's the way it used to work back then. Representative democracy came up much later.
Not entirely true. Some corner cases regarding alignment of bitfields or so have changed between 3.0 and 3.2. Most people don't run into such problems, but the kernel does.
My comments on `Is RPM Doomed'
on
Is RPM Doomed?
·
· Score: 1
I composed this as private feedback to the author of the article, but then thought I'd post it here. I realize it overlaps some of the other postings, but there are some ideas I didn't read elsewhere (especially at the end), so I decided to post it anyway.
Having recently turned from someone who disliked RPM and liked to build everything from source myself to an RPM-supported, I have some comments to make regarding your discussions about RPM.
First of all, I must say that I work for Red Hat, but in the group that was formerly Cygnus Solutions, that develops and offers support for software such as GNUPro. Our group is not focused on Red Hat Linux, and we seldom release software in the form of RPMS, so I don't think I can be qualified as having any bias.
First of all, I don't see what the problem with RPM upgrades is. I mean, it's nothing inherent to the RPM format: it's just that, unfortunately, not all RPM distributors are as careful about converting configuration files in case changes are necessary as Debian packagers are. Also, there's the issue that, as soon as you install packages from third parties that are not part of the distribution, and that therefore don't have an upgrade path at the time of the distro upgrade, introducing potential conflicts that are beyond the scope of what any distributor might be expected to be able to cope with. Unless, by `coping with it', you'd prefer the upgrade to refuse to proceed because of such conflicts, requesting you to remove the packages that are in the way before going ahead.
As for the variation between distributions that use RPM, that give headaches to RPM packagers, this is just a symptom of the large number of distributions that have adopted it. If there were several major.deb-based distros, you'd very likely see similar differences. Ditto for source-based distros, except for the download, build and install infrastructure, that could be easily built atop RPM. Except that having a package build from source on every client looks like a waste of time to me, if the resulting binary will likely be the same. If you want differences, you can get them and then build from sources, but if you don't, why bother? Admittedly, configure tests for present features may reduce dependencies (at the cost of limiting features of the resulting binary), but then, you can expect to get the same effect by downloading the SRPM of a package and building that.
I believe the RPM version issue is a legitimate complaint, even though I'm aware of only one major RPM upgrade that has introduced backward-compatibility issues. Admittedly, I may have failed to notice smaller issues for not keeping older versions of RPM-based distros running to the point of noticing problems with newer packages. However, the major RPM change I'm aware of is IMHO not too different from say a distro switching from say.rpm to.deb,.tgz, etc (or the other way round, if you prefer:-) The package formats are different, to address issues that the older format could not address. Surely keeping the same name for the package manager may be confusing and misleading, but given that it's still conceptually very similar, and fully backward-compatible in the source level (by source I mean spec files), it's reasonable to retain the same name. I wish the upgrade path had been smoother, but if you think about it, it's not really possible to get more than what was gotten. Letting older versions of rpm install packages that make use of features they know nothing about is definitely not a good idea.
WRT the issue of getting some piece of software to automatically locate dependencies, resolve them and install them, I have mixed feelings. I don't think having RPM do it is the right place: it goes against the Unix philosophy that every package should do something very well, instead of trying to solve all the world's problems, but doing this one thing in such a way that additional layers of software can be added to extend the set of problems that can be solved.
Dependency resolution is something alien (no pun intended:-) to RPM: RPM is about managing software installed on a machine ensuring that dependencies are fulfilled and conflicts do not arise. It is not about locating packages, selecting which version of a package to use based on some criteria, downloading them and then doing what RPM does today.
As you've mentioned in your article, there are other packages built atop RPM that take care of the issue of locating and downloading packages. Not only urpmi and apt*rpm, but also up2date (and current) and Red Carpet.
up2date is the only one of these I'm familiar with, but it does as much dependency resolution magic as I've ever wanted. If I tell it to install a given package, it will find out whether there are any dependencies that I'm missing in my distro, download them and install them along with the requested packages. No dependency hell.
Unless, of course, I'm trying to install packages that have conflicting dependencies, or packages whose dependencies are unknown to the up2date server. Surely, someone could come up with a world-wide infrastructure to locate RPMS that would enable an up2date client (or server?) to determine packages that could satisfy dependencies of an arbitrary package that I wish to install, then proceed to download and install them.
But the very notion of having software downloaded from arbitrary servers ``out there'' and `automatically' installed on my machines is scary. Why would I trust such software to the point of installing it on my machines? But then, as I limit the set of trusted servers/signatures I'm willing to have installed on my machines, the likelihood increases that I'll try to install a package whose dependencies cannot be fulfilled by packages in such a set.
This model works for Debian, as well as for Conectiva's RPM-based apt-get, because there *is* a set of trusted servers that very likely carry all dependencies you may need. If they don't, you're just as out of luck. It's a matter of coverage of dependencies on the servers.
Now, let's assume for a moment that someone comes up with a distributed RPM dependency solver. A P2P system thing to which people could upload/offer RPMs, and that would accept queries on RPM dependencies, returning sets of RPM headers that would fulfill such dependencies, and then accepting download requests of said RPMS.
Even if we got that far, I still see problems. One of them is that of trust, that I've already discussed. The other is that of choosing which of the packages that satisfy a dependency to download and install. If there is not a central authority to label packages as say stable, unstable, testing, who gets to make the decision? And, more importantly, how about alternatives? Say a package that requires a MTA: should sendmail, postfix or something else be installed? If so, which exact version?
The way I envision a client for such a P2P system, it should present the options to the user, resolving and presenting further dependencies, leaving it up to the user to decide what RPMS are to be installed. Hardly something that can (or should) be automated.
> If however you have 100 people all accessing different pieces of the disk, some reading some writing then IDE will just not cut the mustard.
You're probably talking about some network server in this case. The bottleneck is more likely to be the network than the disks.
> It requires too much CPU involvement. With SCSI the CPU just says here you handle this to the SCSI interface and gets on with something else instead.
Err... DMA anyone?:-)
> In addition, with SCSI I can have 15 devices on a single bus, with IDE, I can have 2.
With IDE, you can have one. The other is just in case you want neither of them to work as fast as they can:-)
With SCSI, if you attach 15 decides on a single bus and have 100 users doing random access on them, how many MB/s does each disk get? Guess I'd rather go with IDE disks in buses by themselves;-)
Doing software RAID on 4+ IDE disks is great; even if your motherboard doesn't have as many IDE controllers, there's always the option of buying PCI cards with additional controllers.
Oh, and if you really care that much about offloading the CPU and being able to connect dozens of disks to a machine, you can find boxes into which you can place lots of fast&cheap IDE disks that interfaces with the computer with a SCSI interface. Cool, eh?
> >Red Hat is (AFAIK) the only distribution with absolutely no closed source-software.
> Really? I had no idea Real Audio and XGalaga were open sourced now... (they're not)
They're not part of the distribution either. They're part of the extra CDs you get when you buy the boxed product. AFAIK, the only closed-source software in the distribution proper, the one that anyone can download from the net for free, is Netscape 4. Hopefully it won't last for too long:-)
That's why I added the disk to a friend's computer to the picture. Then, even if my whole office goes on fire, I'm still going to have a complete off-line copy of the data elsewhere. If you need a really cheap backup solution, running backups to a remote disk is probably the safest and cheapest method. Well, as long as you and your friend have a relatively fast and stable network connections, of course.
Slashdot Mirror
> And yet the FSF went to great lengths to permit it in some cases (the business use exception)
I don't see that the language of GPLv3 actually permits it. Since a number of people (myself included) believe that GPLv2 didn't permit tivoization of any devices whatsoever, GPLv3 is no different as far as products that don't qualify as "user products" are concerned.
http://www.fsfla.org/?q=en/node/139#1
It's good to see Canonical following our advice, even if in such a limited way and not necessarily for the right reasons... A step in the right direction nevertheless.
Interestingly, we didn't know about Tom Clancy's fifth freedom when we wrote the editorial in the URL above. That's too bad, because it fits. Oh well...
> What Tivo done so wrong? It is market, for fucking sake, go after some other such box who has a) Linux underneath and it b) allows hacking.
They're in violation of the spirit of the license, and some understand that it's also in violation of the letter of the license.
How is your argument any different from: `so that person created an unathorized copy a CD or DVD. Why doesn't Hollywood go after someone else who *is* willing to pay for the license, then, instead of persecuting the person who violated the license?'
> DRM is NOTHING, it is just copyright protection.
No, it is abuse of law provisions to remove rights that, by law, you're entitled to have. Go read on fair use and on how DRM stops you from exercising your rights.
Besides, GPLv3 is not about forbidding implementations of DRM, it's about the same spirit GPLv2 had: ensuring that anyone who modifies or distributes the software respects the 4 freedoms of anyone else who gets a copy of the software. One such freedom is the right to adapt the software to suit your needs. Which is to say that, if there's an implementation in there that gets in the way of something you can lawfully do, you're free to remove it, and the copyright holder won't get it the way.
There's no opposition to trusted computing technology. The opposition is to treacherous computing technology, that technology designed to take away from the users the control over their own machines.
How could you possibly do trusted computing research and development if you can't say replace the lower portions of the software that implements the trusted computing machinery because the trusted computing machinery in place won't permit you to do it because you're not one of the few authorized entities to do so?
> "but given that Ubuntu is already obligated to continue to distribute source code for as long as we distribute binaries, it's possible that we could offer that kind of assistance if it would help.'
:-)
So they're willing to take up the requirement of keeping the sources around for at least 3 years longer than they would otherwise have to, just for the benefit of derived distros? That's a pretty nice gesture! I hope they do realize what they're offering to do
We had similar debates over the past year or so in Brazil, about creating a license in the spirit of the GNU GPL, but adapted to Brazilian law. Heck, there is even a license that was proposed to that end.
Anyhow... Creating new licenses to duplicate the spirit of the GPL is pointless. Either they're compatible with the GPL and can irreversibly decay to it, defeating the point of the license adapted to local legislation, or it's incompatible and you're stuck out of the worldwide Free Software community, having to reinvent it all from scratch.
If you must, work on a (semi-?)official translation, and/or work to get the legislation to support the concept of Free Software licenses that are valid worldwide.
Translations of the GPL will likely fit well into any legal system, since the GPL doesn't take any rights away. Changing legislation can be trickier, but as governments look into adopting Free Software, the need for making sure the software they use, developed by a worldwide community, has a clear legal status, can be used to help promote the legal changes.
In Brazil, we ended up with a legal translation of the GNU GPL, registered in Creative Commons, and, in spite of all the initial noise about fundamental incompatibilities of the GNU GPL with the local law, they all turned out to be misunderstandings of the original license. I'd strongly advise France and any other countries to follow this path, if at all possible.
> In contrast, the GPL boils down to: "Here's the source code. You can use it if you want but then you must make it and your derivatives based on it available to the public.
Not true. This is the sort of claim that proprietary software compaines like to make to confuse people away from free software. You don't have to make the source code and its derivatives available to the public. You have to make it available to those who get the binaries. If you don't distribute it, you don't make anything public. If you distribute it to someone, you give them the sources and it's done, or a written offer valid for at least 3 years that grants them or anyone else the rights to demand the sources from you, granting them the same rights to see, modify and distribute the code, modified or not, that you had, along with the same requirements.
#include
Not only are bytes 2^3 bits, but also sectors are 2^9 bytes. Now why are they switching to powers of 10?
> Anyone remember paper?
Well, the word goes that they invented it. They ought to be able to do better now, after such a long time...
> pine
/etc/redhat-release
It's been deprecated for several releases and, AFAIK, it was the only non-free package in the distribution. Non-free in that it didn't allow modified versions to be distributed, mind you. I'm happy to see it go.
> tripwire
You want it? Cool, make sure you get involved with the RHL project and volunteer to maintain the package! It's needed some nice defaults for the distro for a while. The configuration files that shipped weren't useful except for inspiration in creating your own.
> postgresql72
[aoliva@free aoliva]$ cat
Red Hat Linux release 9.0.93 (Severn)
[aoliva@free aoliva]$ rpm -q postgresql
postgresql-7.3.3-4
It's the 7.2 compat package that is gone.
Wouldn't having ADV: as the first 4 characters of the subject like make it no longer a Subject: line, because you can't have it start with both Subject: and ADV:? It seems to me that this proposal actually makes any form of spam illegal, since it's impossible to meet this requirement. Wheee!
Heck, they don't mean CD as in Compact Disc, but rather as Crippled Disc. :-(
> democracy is one person, one vote, to elect a *ruling party* who then govern the country.
What you describe is representative democracy. Democracy, from its Greek roots, means `government by the people', and I'm told that's the way it used to work back then. Representative democracy came up much later.
Heck, then just bundle the source along with the binaries, just to be safe, and be done with it!
So, is the Mozilla project going to have to rename its rendering engine now? :-(
I often joke that I was rebooted when I was 6. All volatile memory from before that is gone.
Not entirely true. Some corner cases regarding alignment of bitfields or so have changed between 3.0 and 3.2. Most people don't run into such problems, but the kernel does.
Then you win... dows? I hope not :-)
I composed this as private feedback to the author of the article, but then thought I'd post it here. I realize it overlaps some of the other postings, but there are some ideas I didn't read elsewhere (especially at the end), so I decided to post it anyway.
.deb-based distros, you'd very likely see similar differences. Ditto for source-based distros, except for the download, build and install infrastructure, that could be easily built atop RPM. Except that having a package build from source on every client looks like a waste of time to me, if the resulting binary will likely be the same. If you want differences, you can get them and then build from sources, but if you don't, why bother? Admittedly, configure tests for present features may reduce dependencies (at the cost of limiting features of the resulting binary), but then, you can expect to get the same effect by downloading the SRPM of a package and building that.
.rpm to .deb, .tgz, etc (or the other way round, if you prefer :-) The package formats are different, to address issues that the older format could not address. Surely keeping the same name for the package manager may be confusing and misleading, but given that it's still conceptually very similar, and fully backward-compatible in the source level (by source I mean spec files), it's reasonable to retain the same name. I wish the upgrade path had been smoother, but if you think about it, it's not really possible to get more than what was gotten. Letting older versions of rpm install packages that make use of features they know nothing about is definitely not a good idea.
:-) to RPM: RPM is about managing software installed on a machine ensuring that dependencies are fulfilled and conflicts do not arise. It is not about locating packages, selecting which version of a package to use based on some criteria, downloading them and then doing what RPM does today.
Having recently turned from someone who disliked RPM and liked to build everything from source myself to an RPM-supported, I have some comments to make regarding your discussions about RPM.
First of all, I must say that I work for Red Hat, but in the group that was formerly Cygnus Solutions, that develops and offers support for software such as GNUPro. Our group is not focused on Red Hat Linux, and we seldom release software in the form of RPMS, so I don't think I can be qualified as having any bias.
First of all, I don't see what the problem with RPM upgrades is. I mean, it's nothing inherent to the RPM format: it's just that, unfortunately, not all RPM distributors are as careful about converting configuration files in case changes are necessary as Debian packagers are. Also, there's the issue that, as soon as you install packages from third parties that are not part of the distribution, and that therefore don't have an upgrade path at the time of the distro upgrade, introducing potential conflicts that are beyond the scope of what any distributor might be expected to be able to cope with. Unless, by `coping with it', you'd prefer the upgrade to refuse to proceed because of such conflicts, requesting you to remove the packages that are in the way before going ahead.
As for the variation between distributions that use RPM, that give headaches to RPM packagers, this is just a symptom of the large number of distributions that have adopted it. If there were several major
I believe the RPM version issue is a legitimate complaint, even though I'm aware of only one major RPM upgrade that has introduced backward-compatibility issues. Admittedly, I may have failed to notice smaller issues for not keeping older versions of RPM-based distros running to the point of noticing problems with newer packages. However, the major RPM change I'm aware of is IMHO not too different from say a distro switching from say
WRT the issue of getting some piece of software to automatically locate dependencies, resolve them and install them, I have mixed feelings. I don't think having RPM do it is the right place: it goes against the Unix philosophy that every package should do something very well, instead of trying to solve all the world's problems, but doing this one thing in such a way that additional layers of software can be added to extend the set of problems that can be solved.
Dependency resolution is something alien (no pun intended
As you've mentioned in your article, there are other packages built atop RPM that take care of the issue of locating and downloading packages. Not only urpmi and apt*rpm, but also up2date (and current) and Red Carpet.
up2date is the only one of these I'm familiar with, but it does as much dependency resolution magic as I've ever wanted. If I tell it to install a given package, it will find out whether there are any dependencies that I'm missing in my distro, download them and install them along with the requested packages. No dependency hell.
Unless, of course, I'm trying to install packages that have conflicting dependencies, or packages whose dependencies are unknown to the up2date server. Surely, someone could come up with a world-wide infrastructure to locate RPMS that would enable an up2date client (or server?) to determine packages that could satisfy dependencies of an arbitrary package that I wish to install, then proceed to download and install them.
But the very notion of having software downloaded from arbitrary servers ``out there'' and `automatically' installed on my machines is scary. Why would I trust such software to the point of installing it on my machines? But then, as I limit the set of trusted servers/signatures I'm willing to have installed on my machines, the likelihood increases that I'll try to install a package whose dependencies cannot be fulfilled by packages in such a set.
This model works for Debian, as well as for Conectiva's RPM-based apt-get, because there *is* a set of trusted servers that very likely carry all dependencies you may need. If they don't, you're just as out of luck. It's a matter of coverage of dependencies on the servers.
Now, let's assume for a moment that someone comes up with a distributed RPM dependency solver. A P2P system thing to which people could upload/offer RPMs, and that would accept queries on RPM dependencies, returning sets of RPM headers that would fulfill such dependencies, and then accepting download requests of said RPMS.
Even if we got that far, I still see problems. One of them is that of trust, that I've already discussed. The other is that of choosing which of the packages that satisfy a dependency to download and install. If there is not a central authority to label packages as say stable, unstable, testing, who gets to make the decision? And, more importantly, how about alternatives? Say a package that requires a MTA: should sendmail, postfix or something else be installed? If so, which exact version?
The way I envision a client for such a P2P system, it should present the options to the user, resolving and presenting further dependencies, leaving it up to the user to decide what RPMS are to be installed. Hardly something that can (or should) be automated.
> If however you have 100 people all accessing different pieces of the disk, some reading some writing then IDE will just not cut the mustard.
:-)
:-)
;-)
You're probably talking about some network server in this case. The bottleneck is more likely to be the network than the disks.
> It requires too much CPU involvement. With SCSI the CPU just says here you handle this to the SCSI interface and gets on with something else instead.
Err... DMA anyone?
> In addition, with SCSI I can have 15 devices on a single bus, with IDE, I can have 2.
With IDE, you can have one. The other is just in case you want neither of them to work as fast as they can
With SCSI, if you attach 15 decides on a single bus and have 100 users doing random access on them, how many MB/s does each disk get? Guess I'd rather go with IDE disks in buses by themselves
Doing software RAID on 4+ IDE disks is great; even if your motherboard doesn't have as many IDE controllers, there's always the option of buying PCI cards with additional controllers.
Oh, and if you really care that much about offloading the CPU and being able to connect dozens of disks to a machine, you can find boxes into which you can place lots of fast&cheap IDE disks that interfaces with the computer with a SCSI interface. Cool, eh?
Things start to get too complex after a certain point. For a large number of geeks, I guess the collective IQ would not be negative, but imaginary.
I thought it was Micro$oft who invented the ultimate device to see through walls. didn't Bill Gates call them Windows?
> >Red Hat is (AFAIK) the only distribution with absolutely no closed source-software.
:-)
> Really? I had no idea Real Audio and XGalaga were open sourced now... (they're not)
They're not part of the distribution either. They're part of the extra CDs you get when you buy the boxed product. AFAIK, the only closed-source software in the distribution proper, the one that anyone can download from the net for free, is Netscape 4. Hopefully it won't last for too long
Heh. Time to finally bite the bullet and trademark AOLinux: Alexandre Oliva's Linux. Yuck!
That's why I added the disk to a friend's computer to the picture. Then, even if my whole office goes on fire, I'm still going to have a complete off-line copy of the data elsewhere. If you need a really cheap backup solution, running backups to a remote disk is probably the safest and cheapest method. Well, as long as you and your friend have a relatively fast and stable network connections, of course.