A resent question here brings up something that's bugged me too.
Bittorrent is a great concept. It's community supported, and for files the size of installation iso's it's a better way to download.
So why hasn't it replaced ftp completely?
Because bittorrent doesn't work.
When it does work, it works great. It works so well and it's such a great idea that people for whom it works often abandon conventional means of distributing files, leaving their projects completely in limbo if the torrents dry up, or if one of the many other overriding reasons bittorrent doesn't work should take them down.
I don't want to get into a language war here. I know that there can be no growth without change. Part of the problem with bittorrent is that it's written in python, and python is an evolving language, so depending on what platform you're on, you may or may not have access ot a version of python that will run bittorrent. (I don't.)
Although bittorrent pierces firewalls pretty well, it's not clear that it does as well outbound as inbound. This appears to stall the process in some cases, as you are expected to share your resources if you're going to participate in a torrent .
The other problem, and one that I think has probably been what kept me from persuing bittorrent further, is that there are a lot of bad links to bad torrents out there - streams that won't launch, won't connect, for whatever reason.
So the problem is that if you have a project that has "discovered" bittorrent, but has yet to discover all the potential problems it has, you end up with a project that's inaccessible to a large portion of it's potential audience. The standard OSS community response is to blame the users, and belittle their skills and knowledge because they can't get bittorrent to run.
If anybody's listening, I have another idea. The traditional protocol for distributing software on the internet still works just fine. For a bittorrent project, it makes a great backup, and ensures that future torrents can be launched, even if there's a problem that takes down the original links.
</rant>
On Tue, 2004-10-05 at 10:21, Jonathan Hutchins wrote:
So the problem is that if you have a project that has "discovered" bittorrent, but has yet to discover all the potential problems it has, you end up with a project that's inaccessible to a large portion of it's potential audience. The standard OSS community response is to blame the users, and belittle their skills and knowledge because they can't get bittorrent to run.
BitTorrent has and always will be a method to handle high load for a lot of interest in something over a short period of time. I know of no projects that exclusively use BitTorrent to distribute software. If there is someone doing that, however, it's not a very good idea and they should probably reconsider.
The documentation for BitTorrent clearly states that you must poke a hole in your firewall in order to get the best performance from BitTorrent; any bad experience you've had after doing that should be directed to the author.
Jason Clinton wrote:
The documentation for BitTorrent clearly states that you must poke a hole in your firewall in order to get the best performance from BitTorrent; any bad experience you've had after doing that should be directed to the author.
Googling for "bittorrent upnp" turns up several clients that will do the hole-poking automagically, assuming your firewall supports UPnP NAT traversal. Most of them appear to be written in something other than Python, which may take care of one of Jonathan's other complaints.
So that's what UPnP is for!
BitTorrent is a step towards a universal distributed replicating proxying system
as it catches on it will catch on. I wonder when bittorrent proxies will start appearing or will start making sense. Check your local repository before ordering from the source. Check the library before ordering the book from Amazon.
Automatic proxy configuration protocol exists for web browsing, but there is no way to make mozilla go get the PAC file without operator intervention (at least there wasn't three years ago)
i think a bittorrent proxy library, perhaps operated by an upstream ISP, would make sense just like "web page acceleration" which means, the ISP has installed a proxy server makes sense. Technically. Businesswise, installing and supporting dedicated bittorrent servers for the benefit of your users will not make sense until there is demand. And Torrent protocol would need to get extended to support the repository-proxy concept.
I think the big boost to torrent adoption will be when web browsers start accepting files over torrents instead of from single servers, and web distribution links start using an extended syntax that offers the same file as port80 or torrent forms with the machine selecting. I believe HTTP offers such a facility already, torrents appear as urls that start "torrent:" -- no that's wrong, reading the bittorrent publication guide, torrents are magic tarballs that are served from web servers as application/torrent and they are expected to have file extensions of .torrent, and also the "origin" torrent server has to be kept going, and there does not seem to be a way to have the origin be a *TP server of some kind, which would make torrent an accellerant rather than an entirely separate deal.
So there is no way to set up a general purpose bittorrent proxy for use of your natted, firewalled LAN at this time. Allowing insiders to control a shared "downloader" that downloads to a directory that is network-shared would sort of work, and if this product came with bittorrent clients that would refer to it the use would be no less annoying than current bittorent.
I am describing two pieces of software, I haven't made up a name for the system, and I wold not be surprised if it already exists.
"bitGutter" (gutters catch a torrents) would be a torrent downloader that sits on the outside of the firewall or at least works with the firewall so it gets the torrent ports forwarded to it. "Gutter clients" are what you install in your web browser inside the guttered network rather than torrent clients, and the gutter client appears just like the torrent client in terms of user experience, except that you can only download into the shared gutter directory, and in there you can see (or maybe you can't -- privacy issue, resolvable) what your LANmates have already downloaded.
On Tue, 05 Oct 2004 12:58:30 -0500, Gerald Combs [email protected] wrote:
Jason Clinton wrote:
The documentation for BitTorrent clearly states that you must poke a hole in your firewall in order to get the best performance from BitTorrent; any bad experience you've had after doing that should be directed to the author.
Googling for "bittorrent upnp" turns up several clients that will do the hole-poking automagically, assuming your firewall supports UPnP NAT traversal. Most of them appear to be written in something other than Python, which may take care of one of Jonathan's other complaints.
David Nicol wrote:
So that's what UPnP is for!
Actually it's so that your toaster, PVR, printer, laptop, and refrigerator can auto-discover each other on the network. NAT traversal is just a small part of UPnP (but it's the part that will let a 12 year old in Kyrgyzstan shut off your freezer while you're on vacation).
You can see UPnP in "action" by listening on a LAN with Windows boxes present. Eventually you'll see them spit out SSDP packets. Other competing protocols include SLP (Service Location Protocol) and Jini.
i think a bittorrent proxy library, perhaps operated by an upstream ISP, would make sense just like "web page acceleration" which means, the ISP has installed a proxy server makes sense. Technically. Businesswise, installing and supporting dedicated bittorrent servers for the benefit of your users will not make sense until there is demand. And Torrent protocol would need to get extended to support the repository-proxy concept.
Why would you need to extend the Torrent protocol? Transparent proxies (whether they use direct intervention, WCCP, or something else) have existed for HTTP for a while now.
Gerald Combs wrote:
David Nicol wrote:
So that's what UPnP is for!
Actually it's so that your toaster, PVR, printer, laptop, and refrigerator can auto-discover each other on the network. NAT traversal is just a small part of UPnP (but it's the part that will let a 12 year old in Kyrgyzstan shut off your freezer while you're on vacation).
You can see UPnP in "action" by listening on a LAN with Windows boxes present. Eventually you'll see them spit out SSDP packets. Other competing protocols include SLP (Service Location Protocol) and Jini.
Dude, that is so funny. I have seen PCs w/ Win2k and XP not spit, but spew chunky packets all over a network. Thanks to a loser PC Tech that forgot to shut off the UPnP service on a Ghost image. Can you all say broadcast storm? Yeah, I knew you could. As if Master Browser elections weren't bad enough. VLANs, everywhere VLANs, just to break up the party.
I think a bittorrent proxy library, perhaps operated by an upstream ISP, would make sense just like "web page acceleration" which means, the ISP has installed a proxy server makes sense. Technically. Businesswise, installing and supporting dedicated bittorrent servers for the benefit of your users will not make sense until there is demand. And Torrent protocol would need to get extended to support the repository-proxy concept.
Why would you need to extend the Torrent protocol? Transparent proxies (whether they use direct intervention, WCCP, or something else) have existed for HTTP for a while now.
I agree. BitTorrent works. It is not that hard to open a few ports. If you are trying out ISOs of operating systems and you have a firewall, what is the big deal about learning a bit about how they work. That said, it would be cool if an FTP download could fail-over to a torrent.
On Tuesday 05 October 2004 10:05 pm, Brian Kelsay wrote:
I agree. BitTorrent works.
If you haven't had problems with it, you're not much help troubleshooting it.
My firewall's built from scratch, so I have a pretty good idea how it works. It does work.
Bittorrent doesn't.
Note that this is the problem: for the fortunate, bittorrent works. For the rest of us, it doesn't, and short of a major effort to troubleshoot it it won't. Most of us aren't going to put that effort in, especially if there's something available via ftp that will do the job we're actually trying to do.
All the "helpful" suggestions from people who've never had a problem with bittorrent notwithstanding, _ftp_ works.
Why isn't BitTorrent (or any other P2P software for that matter) used as an official, sanctioned, software distribution channel along with HTTP and FTP? Specifically, why aren't places like SourceForge, kernel.org, Gentoo, Mozilla, and OpenOffice using it?
On Wed, 06 Oct 2004 10:50:47 -0500 Gerald Combs [email protected] wrote:
Why isn't BitTorrent (or any other P2P software for that matter) used as an official, sanctioned, software distribution channel along with HTTP and FTP? Specifically, why aren't places like SourceForge, kernel.org, Gentoo, Mozilla, and OpenOffice using it?
Maybe I'm a weirdo, but if HTTP and FTP work and the projects can afford the bandwidth why would they? Just another service they would have to maintain.
The main reason someone uses BitTorrent is to avoid having to pay for all of the bandwidth costs associated with large projects. There is no other real reason to switch, other than being new/different/cool which IMHO is a horrible reason.
Out of curiosity why would you want them to support BitTorrent?
--------------------------------- Frank Wiles [email protected] http://www.wiles.org ---------------------------------
Frank Wiles wrote:
Maybe I'm a weirdo, but if HTTP and FTP work and the projects can afford the bandwidth why would they? Just another service they would have to maintain.
They _can't_ afford the bandwidth. SourceForge and Gentoo in particular rely heavily on mirrors. I wouldn't be surprised if the bandwidth for the other projects was donated or subsidized by a third party.
The main reason someone uses BitTorrent is to avoid having to pay for all of the bandwidth costs associated with large projects. There is no other real reason to switch, other than being new/different/cool which IMHO is a horrible reason.
Out of curiosity why would you want them to support BitTorrent?
I don't neccessarily want them to, I just want to know why they aren't. If you could save bandwidth costs or avoid the hassle of administering mirrors by setting up a BT feed, why wouldn't you? From Ethereal's perspective, doing this would be a no-brainer - even our modest-in-comparison bandwidth requirements cost a fair amount of money per month. I'm just wondering why it isn't common practice.
On Wed, 06 Oct 2004 11:20:21 -0500 Gerald Combs [email protected] wrote:
They _can't_ afford the bandwidth. SourceForge and Gentoo in particular rely heavily on mirrors. I wouldn't be surprised if the bandwidth for the other projects was donated or subsidized by a third party.
Every project of any size relies on mirrors. What I meant by afford was "what they are currently doing works", not that they were able to support all of their bandwidth costs financially.
I don't neccessarily want them to, I just want to know why they aren't. If you could save bandwidth costs or avoid the hassle of administering mirrors by setting up a BT feed, why wouldn't you? From Ethereal's perspective, doing this would be a no-brainer - even our modest-in-comparison bandwidth requirements cost a fair amount of money per month. I'm just wondering why it isn't common practice.
I think it's more of a marketshare deal. Not everyone has a BT client or is familiar/comfortable with it. Everyone who is going to download a open source project can use a browser and most likely an FTP client.
That and the "what we are currently doing works" so let's not put resources toward setting up a BT feed when that time could be better spent setting up another solid mirror, coding, documentation, etc.
--------------------------------- Frank Wiles [email protected] http://www.wiles.org ---------------------------------
On Wed, October 6, 2004 12:47 pm, Frank Wiles said:
I think it's more of a marketshare deal. Not everyone has a BT client or is familiar/comfortable with it. Everyone who is going to download a open source project can use a browser and most likely an FTP client.
The major browsers have some sort of FTP client included, at the very least for downloading purposes. Will the demand for BitTorrent drive inclusion of this technology into next-generation browsers? Maybe there'll be a plugin for Firefox. I couldn't find one on mozdev.org currently.
If you look at the Mozilla Releases page (http://www.mozilla.org/releases/#1.7) they do list a BitTorrent location for their downloads as http://bittorrent.mozilla.org:6969. Unfortunately, I keep getting a "Connection Refused" on the 6969 port.
That and the "what we are currently doing works" so let's not put resources toward setting up a BT feed when that time could be better spent setting up another solid mirror, coding, documentation, etc.
Sometimes the cost to impliment new technology is greater than the benefit of the use of that technology, even though we love the cool technologies.
Jeremy
On Wed, 2004-10-06 at 13:13 -0500, Jeremy Turner wrote:
On Wed, October 6, 2004 12:47 pm, Frank Wiles said:
I think it's more of a marketshare deal. Not everyone has a BT client or is familiar/comfortable with it. Everyone who is going to download a open source project can use a browser and most likely an FTP client.
The major browsers have some sort of FTP client included, at the very least for downloading purposes. Will the demand for BitTorrent drive inclusion of this technology into next-generation browsers? Maybe there'll be a plugin for Firefox. I couldn't find one on mozdev.org currently.
There was some talk about the possibility among developers but, IIRC, the outcome of that talk was that Mozilla is a strictly client-oriented piece of software. Doing a BitTorrent "client" would require incorporating all sorts of server oriented functions in to the gecko networking libraries.
Maybe some day (years from now) when the web is truly semantic, BitTorrent will 'fit' in with philosophy of a 'web browser'. That is: when everyone's browser is also their publishing system/server.
On Wed, October 6, 2004 1:13 pm, Jeremy Turner said:
The major browsers have some sort of FTP client included, at the very least for downloading purposes. Will the demand for BitTorrent drive inclusion of this technology into next-generation browsers?
As I understand it, this is how the current bittorrent scripts are supposed to work. You define the mime type of a torrent file as being handled by the script, and if you click on a torrent link in your browser it launches.
Again, I haven't gotten any of this to work on my own systems - largely because I haven't tried very hard - but this is the ONLY way I've seen to start a bittorrent download.
On Wed, 06 Oct 2004 10:50:47 -0500, Gerald Combs [email protected] wrote:
Why isn't BitTorrent (or any other P2P software for that matter) used as an official, sanctioned, software distribution channel along with HTTP and FTP? Specifically, why aren't places like SourceForge, kernel.org, Gentoo, Mozilla, and OpenOffice using it?
Not sure, But IMHO its doomed to a life of darkness like most p2p, hotline and, scour. They are/were all good things in concept, but end up otherwise. Mostly used for nefarious activities(pirating software and audio, distributing porn, etc..), rather than they good they were most likely designed for.
On Wednesday 06 October 2004 10:50 am, Gerald Combs wrote:
Why isn't BitTorrent (or any other P2P software for that matter) used as an official, sanctioned, software distribution channel along with HTTP and FTP? Specifically, why aren't places like SourceForge, kernel.org, Gentoo, Mozilla, and OpenOffice using it?
I think that's what we've answered here: because it doesn't work.
To be clear, while it works for some people and some torrents, in general it's too unreliable for a major distribution to rely on it.
If it gets to the point where it's reliable and conventional enough to be included in (or at least packaged for) the major distributions, that may change. Already it's made great progress, particularly in the level of documentation available.
Still, it's something that if it doesn't work requires considerable struggle to fix, and most peole will continue to do as I've done, look elsewhere.
debian offers torrent for ISO images.
After last night's discussion, I'll be hosting torrent origins as soon as I plug the new seagates into something that can see them and so on.
David Nicol wrote:
debian offers torrent for ISO images.
http://www.debian.org/CD/torrent-cd/
So there _is_ a project doing this after all. Thanks. They also offer something called "jigdo", which apparently assembles .iso images from their component files:
I know Gentoo, and as you say debain. Is doing bt for transfering of files. I really like using bt over http/ftp since not using the main site or mirrors other then the size of the torrent.
I think it would be really cool to have a "Portorrent or Portage w/BT capabilities" for Gentoo.
BT rules. =)
On Fri, 08 Oct 2004 16:06:22 -0500, Gerald Combs [email protected] wrote:
David Nicol wrote:
debian offers torrent for ISO images.
http://www.debian.org/CD/torrent-cd/So there _is_ a project doing this after all. Thanks. They also offer something called "jigdo", which apparently assembles .iso images from their component files:
http://www.debian.org/CD/jigdo-cd/
Kclug mailing list [email protected] http://kclug.org/mailman/listinfo/kclug
Ouch! I heard "Gentoo with BT" and thought, "week-long install". :)
--- djgoku [email protected] wrote:
I know Gentoo, and as you say debain. Is doing bt for transfering of files. I really like using bt over http/ftp since not using the main site or mirrors other then the size of the torrent.
I think it would be really cool to have a "Portorrent or Portage w/BT capabilities" for Gentoo.
BT rules. =)
On Fri, 08 Oct 2004 16:06:22 -0500, Gerald Combs [email protected] wrote:
David Nicol wrote:
debian offers torrent for ISO images.
http://www.debian.org/CD/torrent-cd/So there _is_ a project doing this after all.
Thanks. They also offer
something called "jigdo", which apparently
assembles .iso images from
their component files:
http://www.debian.org/CD/jigdo-cd/
Kclug mailing list [email protected] http://kclug.org/mailman/listinfo/kclug
-- dj_goku -www.djgoku.com- -www.tektronic.org- _______________________________________________ Kclug mailing list [email protected] http://kclug.org/mailman/listinfo/kclug
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Friday 08 October 2004 04:06 pm, Gerald Combs wrote:
[Debian] also offer something called "jigdo", which apparently assembles .iso images from their component files:
Then there's the ancient and venerable "RedHat-CD-HOWTO" ( http://tldp.org/HOWTO/RedHat-CD-HOWTO/index.html ) which tells you how to build a RedHat installation CD, complete with all the current updates. That one's been around since RedHat came on one CD.
A bit of study would proably allow you to generalize it for building SuSE install CD's (I think you can do that, you just can't share the images); or for maintaining Mandrake CD's that include current updates.
Jonathan Hutchins wrote:
On Tuesday 05 October 2004 10:05 pm, Brian Kelsay wrote:
I agree. BitTorrent works.
If you haven't had problems with it, you're not much help troubleshooting it.
My firewall's built from scratch, so I have a pretty good idea how it works. It does work.
Bittorrent doesn't.
Note that this is the problem: for the fortunate, bittorrent works. For the rest of us, it doesn't, and short of a major effort to troubleshoot it it won't. Most of us aren't going to put that effort in, especially if there's something available via ftp that will do the job we're actually trying to do.
All the "helpful" suggestions from people who've never had a problem with bittorrent notwithstanding, _ftp_ works.
The consensus so far agrees on 2 points - ftp works and bittorrent needs work . The logical next step to me is those who can- will do what's required to make bittorrent the usability peer to ftp , OR those committed to a slower evolution of bittorrent will be always a bit behind the curve as will be projects solely shared so . Which is depressing . There are a significant percentage of us handicapped by geography denying us bandwith . Forgetting the alleged leech /all take-no give ethics said to have your d/l proportional to your u/l at heart we can do better . Though the above is claimed to justify darker aspects by some paranoids we here hopefully are not that petty - this does not seem un fixable .
To my admittedly incomplete experience with torrents even if one does negotiate getting a stable client that plays nice with everything else in their install there's a bit more to it . Like renegotiation time after a cloud goes over my Starband dish . Or the unexplained mirage like nature of connections that should be rock solid . Let me be clear- * IF * we can get this to work it will be like going from zmodem up to 100mb Ethernet in terms of bandwith management but we don't have a grip on how to implement this .
Anyone have some constructive and CONCRETE how-to ?
Oren
Jonathan Hutchins wrote:
A resent question here brings up something that's bugged me too.
Bittorrent is a great concept. It's community supported, and for files the size of installation iso's it's a better way to download.
So why hasn't it replaced ftp completely?
Because bittorrent doesn't work.
When it does work, it works great. It works so well and it's such a great idea that people for whom it works often abandon conventional means of distributing files, leaving their projects completely in limbo if the torrents dry up, or if one of the many other overriding reasons bittorrent doesn't work should take them down.
I don't want to get into a language war here. I know that there can be no growth without change. Part of the problem with bittorrent is that it's written in python, and python is an evolving language, so depending on what platform you're on, you may or may not have access ot a version of python that will run bittorrent. (I don't.)
Although bittorrent pierces firewalls pretty well, it's not clear that it does as well outbound as inbound. This appears to stall the process in some cases, as you are expected to share your resources if you're going to participate in a torrent .
The other problem, and one that I think has probably been what kept me from persuing bittorrent further, is that there are a lot of bad links to bad torrents out there - streams that won't launch, won't connect, for whatever reason.
So the problem is that if you have a project that has "discovered" bittorrent, but has yet to discover all the potential problems it has, you end up with a project that's inaccessible to a large portion of it's potential audience. The standard OSS community response is to blame the users, and belittle their skills and knowledge because they can't get bittorrent to run.
If anybody's listening, I have another idea. The traditional protocol for distributing software on the internet still works just fine. For a bittorrent project, it makes a great backup, and ensures that future torrents can be launched, even if there's a problem that takes down the original links.
</rant>
Have had difficulties with the bittorrent client running with SUSE, and rather than to take the time to figure that one out, have copped out and used BitTornado with XP ... for the time being. I don't belittle my own skills and knowledge ... that's just to easy to do ... the point is, I really am just that lazy (and busy)! ;-)
And yes, some occasional sessions with a torrent are still hopelessly futile, but usually a mid-grade connection with Everest (= T1 +, in theory, by the benchmark ... yeah, right) is a speedy, fast food lane experience, and my laptop likes the Mandrake 10.1 that was fetched in record time. Hmmm ... did I just compare Mandrake to McDonald's? ... uh ... no, just the total download time.
Good to be getting the postings again to my new address ... even as a home / home office user (OOo rocks), I glean useful info from this list from time to time, though most of the info exchanged on this forum will never apply to my limited use of, and for, computers. Using mental bandwidth, such as it is, for other things.
Rick
PS Did your first line contain a Freudian slip that your spellchecker ... oh, nevermind ... http://www.haverford.edu/psych/ddavis/p109g/fslip.html
Jonathan Hutchins wrote:
A resent question here brings up something that's bugged me too.
Bittorrent is a great concept. It's community supported, and for files the size of installation iso's it's a better way to download.
So why hasn't it replaced ftp completely?
Because bittorrent doesn't work.
When it does work, it works great. It works so well and it's such a great idea that people for whom it works often abandon conventional means of distributing files, leaving their projects completely in limbo if the torrents dry up, or if one of the many other overriding reasons bittorrent doesn't work should take them down.
I don't want to get into a language war here. I know that there can be no growth without change. Part of the problem with bittorrent is that it's written in python, and python is an evolving language, so depending on what platform you're on, you may or may not have access ot a version of python that will run bittorrent. (I don't.)
Although bittorrent pierces firewalls pretty well, it's not clear that it does as well outbound as inbound. This appears to stall the process in some cases, as you are expected to share your resources if you're going to participate in a torrent .
The other problem, and one that I think has probably been what kept me from persuing bittorrent further, is that there are a lot of bad links to bad torrents out there - streams that won't launch, won't connect, for whatever reason.
So the problem is that if you have a project that has "discovered" bittorrent, but has yet to discover all the potential problems it has, you end up with a project that's inaccessible to a large portion of it's potential audience. The standard OSS community response is to blame the users, and belittle their skills and knowledge because they can't get bittorrent to run.
If anybody's listening, I have another idea. The traditional protocol for distributing software on the internet still works just fine. For a bittorrent project, it makes a great backup, and ensures that future torrents can be launched, even if there's a problem that takes down the original links.
</rant> _______________________________________________ Kclug mailing list [email protected] http://kclug.org/mailman/listinfo/kclug
.
Sadly the concept of blaming the user is easier than making things simply work . Making things work simply is the truly non-trivial part we often forget about .
Your idea of an alternate protocol is quite well advised . If no other reason than to allow the early adopters some way to GET the Torrent software itself .
Even then alternate protocols are smart due to some of us not easily adopting Torrent for several reasons . Forgetting * any* software issues being the problem what then of us on connections totally unfriendly to Torrent. For example Starband and other upload speed restricted users . The core concept of Torrent was never in doubt , it's the deploying that needs work .
What is very disturbing to me is that certain un-named players seem to be profiteering on the altar of Torrent ! Charging someone $ 10 for a HTTP download but free as Torrent seems quite extreme . Not mentioning those who as above are disadvantaged in access to Torrent for whatever reason .
I could even understand a priority launch of Torrent seeding to FTP or HTTP sites on day zero as Slashdot effect prevention by load balancing thru redundancy in mirrors -THAT seems a good Torrent use .
I do wonder as an open query - if downloads were limited to 2 protocols per project what wold they be and why ?
Oren
www.campdownunder.com
On Tue, Oct 05, 2004 at 10:21:52AM -0500, Jonathan Hutchins wrote:
Part of the problem with bittorrent is that it's written in python, and python is an evolving language, so depending on what platform you're on, you may or may not have access ot a version of python that will run bittorrent. (I don't.)
What platform are you using such that you don't have access to a useful version of Python?
I've felt some of the same frustrations you express, but generally I find the only productive thing to do (beyond clearing my chest of my concerns--sometimes a necessary step) is to get into serious troubleshooting mode. I don't know that the limitations you experience with Python will yield to some collective troubleshooting, but it might be worth a look, if you're willing.
As for comparing torrents to ftp, there are some difficulties in the way you talk about it. Transferring with bittorrent *always* involves at least 3 pieces of software, whereas ftp only needs two. In the case of ftp, you have your client and your server. If the server goes down, or the file is removed from the server, one experiences the *exact* same problems you describe torrent as having. I've experienced this with ftp, as I'm sure others have, so there's really no magic bullet here. With torrents, you need a *tracker* running, one or more *seeds* that collectively contain all of the parts of the indicated file, and then you need the client-equivalent who is trying to download the file and has none of it, or an incomplete copy. The downloader can be a full-bore seed, offering uploads in exchange for faster downloads, or can limp along in low-rate leech mode.
I agree that a file source that doesn't maintain a tracker and at least one complete seed is as bad as an ftp maintainer who takes a file off their repository.
But how bad is that, really? If it's a commercial service you are paying for (rarely the case) and the archive maintainer makes something unavailable, you've got a legitimate business-related beef with them, IMO. Otherwise, it's a case of casting aspersions on how someone chooses to make available their own server resources. It runs the risk of seeming downright ungrateful. "Free as in speech, not as in beer; TANSTAAFL;" blah blah blah.
In the end, I think it depends on your perspective: Glass half empty, or glass half full? I know I've made some redistributable files more locally available by running a torrent seed that I would never have made available via ftp. Someone who benefited from my running that seed but then later griped that it was no longer available would seem to be missing the point that, without torrent, I'd have not offered the resources to begin with.
I've also not been able to get through via ftp to heavily lagged sites, whereas the popularity of a recently-released ISO has *helped* my ability to grab that ISO soon after its release via torrent. Bittorrent is a ${DEITY}send in those cases. It rocks.
Its shortcoming, in my opinion, have more to do with its consumption of many ports, instead of multiplexing on a single port, which from what I'm given to understand also makes it a bit of a hassle for handling large collections of many small files, rather than in transferring very few large files. It could stand a little cross-breeding with rsync in this regard, maybe.
On Tuesday 05 October 2004 02:15 pm, D. Joe Anderson wrote:
I've felt some of the same frustrations you express, but generally I find the only productive thing to do (beyond clearing my chest of my concerns--sometimes a necessary step) is to get into serious troubleshooting mode.
Usually when I am looking for an iso download, I do not want to spend my time installing, configuring, and troubleshooting a new piece of software to download it. This has led me to choose distributions that were supported by good ftp mirrors over bittorrent several times recently.
-
Ben Kelley -
Brian Kelsay -
D. Joe Anderson -
David Nicol -
djgoku -
Frank Wiles -
Gerald Combs -
Jason Clinton -
Jeremy Turner -
Jonathan Hutchins -
Leo Mauler -
Oren Beck -
Richard Franklin