On 13/08/2008, Dave Vasilevsky <[EMAIL PROTECTED]> wrote: > Yeah, it definitely requires infrastructure work. Debian has done some > work on torrents-for-apt, which would presumably be extensible to > torrents-for-tarballs: http://debtorrent.alioth.debian.org/ >
I think that Debian's torrents-for-apt would not help me personally much. Wherever I am the Debian infrastructure offers http mirrors with more bandwidth than my downlink. Still the high-speed mirror that is connected to the the same backbone as the high-speed connection I can use is somewhat unreliable but I doubt bittorrent would get ~100Mbit anytime soon to replace this unreliable local mirror. However, sf.net and upstream mirrors are a completely different story. The sf.net mirrors tend to have a long connect delay (probably due to redirects), and are quite unreliable. The quality and availability of upstream mirrors varies wildly. On the other hand, the problem with torrents is that the .torrent file has to be downloaded somewhere, and then the torrent has to start up, connect to peers, etc. So this is probably going to help speed-wise only for large files, and should not hurt too much for ~1MB+ files depending on the client used. Using torrents might help in the reliability department, though. If done right you reduce the data downloaded from the http server to a minimum which in turn should make it possible to afford enough highly responsive mirrors for the torrent files. You still need some permanent seeds to keep the torrents going but these need not be the same all the time, and torrents allow using multiple trackers and editing the tracker list dynamically with appropriate tools. So once you get the torrent and latest list of trackers the download should finish non-interactively in nearly 100% cases, unlike the annoying sf.net mirrors. The thing left to worry about is punching holes into firewalls in sufficiently user-friendly manner so that many people can seed the sources they have downloaded. It might be possible to communicate with some arbitrary BT GUI client but it might be easier to automate something like the original BT client or rtorrent and build some readline or dialog interaction script that punches the holes into the OS X firewall, verifies it worked, etc. I have no idea how the firewall is configured but it *is* possible to configure it ;-) If you want to go for something semi-automatic you could use the generic features present in most UI BT clients: 1) auto-start directory 2) completion-move The user sets up the BT client so that it starts any torrent dropped in one directory, and puts any finished files into another. Fink then puts torrents for all stuff in the first directory, optionally verifies that the BT client is running, and then waits for sources appearing in the second directory. Once sources for a package that can be built without additional dependencies appear the build can start. It is left to the user to verify the client is properly configured and the torrents are indeed downloading in this case. Thanks Michal ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Fink-devel mailing list [email protected] http://news.gmane.org/gmane.os.apple.fink.devel
