746
votes
|
|
1168
0
422
|
|
|
|
|
Propose your solution
Attachments
Duplicates
Comments
|
clemdup
wrote on the 28 Feb 08 at 14:48
|
|
|
|
I wonder if p2p is suitable for small files' transfers, locating peers and enqueuing may be huge for 30kb language files...
|
|
|
I am in China, and it SUX beeing here far away. So bittorrent could be great here. Updates can be 2k/sec daytime, and up to 200k/sec night-time. So torrents could be so much nicer.
|
|
|
|
My ISP (comcast) illegally throttle's all my bittorrent traffic. It is unbearably slow. So as long as it is an option not to use the bittorrent apt system and I can still set it up to download from a mirror, I am in favor.
|
|
rgries
wrote on the 28 Feb 08 at 21:10
|
|
|
|
Here on my college campus using bit torrent is against the acceptable use policy so if ubuntu switched to bittorrent for apt updates I would not be able to use ubuntu. Please Don't ruin ubuntu with bittorrent because if it is implemented it would leave many users in the dark as far as updates go.
|
|
|
Bittorrent can be an interesting option but traditional FTP/HTTP update must stay. The ability to share the apt cache between every computer on the same lan can be interesting too.
I have two computer with ubuntu so every update is download twice.
|
|
drewtown
wrote on the 28 Feb 08 at 23:41
|
|
|
|
I think it could be an interesting experiment and it would have to be set up someway where users know how long they will be seeding for. I may opt-out if I'm forced to seed for x days or whatever.
|
|
djxhan
wrote on the 29 Feb 08 at 00:01
|
|
|
|
FTP/HTTP/Torrent updating would be ideal. Especially during new release periods.
|
|
Remmy
wrote on the 29 Feb 08 at 00:05
|
|
|
Some downfalls to using bittorrent would be:
Synchronizing updates across an unmanaged distributed network.
Not everyone's storage space is equal which could lead to serious problems if the disk should become too full.
It introduces the possibility of people using fake file to exploit systems in "untrusted" zones.
Bandwidth limitations set by ISPs could cause account suspensions.
|
|
dark
wrote on the 29 Feb 08 at 00:16
|
|
|
|
Bittorrent is great, however here in the US some ISPs have begun to (usually illegally) slow down all P2P traffic and also may lead to how much you have to upload and this can be bad if you upload to much and your ISP decides to suspend your account because you went over an invisible limit.
|
|
maltes
wrote on the 29 Feb 08 at 00:46
|
|
|
Debian/Ubuntu packages are supposed to be small individually. Large packages need to be broken up into smaller pieces. While I agree that a p2p system for distributing packages would be a nice idea, Bittorrent clearly is the wrong network for this kind of purpose.
Maybe Bittorrent could be modified to fit this one better.
|
|
wolfier
wrote on the 29 Feb 08 at 02:06
|
|
|
|
If BT is used for Apt then there must be a way to authenticate a package. MD5 is not a sufficient guard against hacked packages.
|
|
Jonnan
wrote on the 29 Feb 08 at 02:14
|
|
|
|
Obviously there are practical security considerations, but if file verification can be implemented properly, then yes, adding bittorrent as an additional option could hardly be a bad thing.
|
|
|
|
This would work really poorly for me in some locations, but it might be a good option to have, especially when upgrading several large packages.
|
|
|
I have 'apt-cacher' installed on the main system in my house. I then have all the other computers in the house setup to get updates through the main system. Therefore I only have to download updates once. It's amazing to install KDE proper from the default kubuntu install and have it complete the ~180MB download in minutes. Something like this would work well on campuses as well.
Mike
|
|
Nat_Tuck
wrote on the 29 Feb 08 at 03:22
|
|
|
This issue was considered for Debian five or six years ago, and it turns out to be really hard to implement in practice.
The one point that no-one has mentioned so far is this: Bittorrent is designed to distribute one specific large set of files, while apt tends to give a different set of small files to each user.
Basically, you'd either need to have one torrent for each package - which would be dog slow because each downloader would always be done before they got any upload credit - or, you could have one big torrent of every file in the repository, and that's wildly inefficient too.
|
|
hackel
wrote on the 29 Feb 08 at 05:07
|
|
|
I see no point to adding bittorrent support to apt. I very much like Debian's rsync capability for updating package lists, and this should be adopted by Ubuntu.
I also wish that Ubuntu would release an upgrade package "archive", available via bittorrent, so that we could pre-seed our apt cache prior to initiating a complete distribution upgrade. This would be very useful, and better than downloading the entire install CD just to extract the debs from.
|
|
afuchs
wrote on the 29 Feb 08 at 06:06
|
|
|
|
google 'apt-torrent'
|
|
|
|
I really like this idea, however I agree it would be a little overkill for small packages and should definitely be optional. Maybe have it so that the standard direct download method is used for any packages 1MB or smaller? Also there should probably be a user editable option for the threshold of when bitTorrent is used and when HTTP/FTP/Rsync is used. Not only could this make downloading large packages (like OpenOffice or games) quicker, but it could greatly help cut down on Canonical's bandwidth needs and would be ultra beneficial to Ubuntu derivative distros with smaller bandwidth abilities.
|
|
bawjaws
wrote on the 29 Feb 08 at 11:48
|
|
|
monte48lowes mentions apt-cache which makes more sense to me than bitorrent.
But surely with ahavi it should be possible for Ubuntu machines on the same LAN to organise amongst themselves and not needlessly download things twice without having to manually set them all to go through a single permanent machine.
|
|
|
Torrents are fine for media such as video and audio.
But for executable code, no thanks.
|
|
|
it appears hardy has a package apt-transport-debtorrent.
deb packages are signed so the transport used does not have any impact in security. They are verified and checked against the pgp key and will show a warning if the package is not signed or the signer is not known.
|
|
|
I would be in favor if
- it's not default
- files are cryptographically signed and verified.
|
|
adelie
wrote on the 29 Feb 08 at 22:11
|
|
|
|
BitTorrent needs to become another option, not something to replace http/ftp. Linix is about flexibility :)
|
|
Æshættr
wrote on the 29 Feb 08 at 23:44
|
|
|
I think that bittorrent should be an option (I would definitely use it to lighten the load on the repositories.)
If an ISP blocks bittorrent traffic, apt can use encryption.
Even if traffic shaping is used to detect bittorrent traffic, the software can still adjust the number of connections it has open to mimmic other types of traffic (speed wouldn't be as great, but it's something.)
As for fake data being distributed, apt can always do a checksum against what the repo says it should be.
However, FTP/HTTP will always have their place.
|
|
|
I think for normal day to day apt use, a torrent system would be both inefficient and overkill. But I do think that it has a niche on those first few days when a final version of ubuntu is released and all the servers slow to a crawl.
Why not implement a very low complexity torrent program right into the update script that ubuntu downloads when it is updating to the next version. All it would have to do is grab the alternate iso and set it as a source. It could also gracefully fall back, or the user could opt out. It could even display a message on completion of the upgrade requesting that the user seed for a day or two.
This would take a huge load off the servers, would most likely be far simpler to implement then then torrents in apt itself, and on release day, it could make hours difference in the download time. New versions of Ubuntu could take over the world!!
|
|
|
|
This has been discussed on Debian mailing lists several times - Torrents are good for large files, apt is lots of small files. The benefits are not worth the effort. There are plenty of mirrors anyway
|
|
rawler
wrote on the 1 Mar 08 at 11:38
|
|
|
I think people are missing the most fundamental point about bittorrent. Torrents usually don't live on unless someone is seeding. Sure, if the file is really big, you will be seeding while downloading, but unless users are willing to share upstream bandwidth when NOT updating, I think apt-torrent has few chances of success.
Instead, I would like to see better mirroring, more updated mirrors and such. Perhaps stop rsync:ing the mirrors and instead run reverse http-caches, such as Varnish?
|
|
grantek
wrote on the 3 Mar 08 at 09:32
|
|
|
|
Voted down on this - a hierarchy of mirrors is better for the multitude of small files. You'd practically need a torrent for each file (even if they were consolidated into one .torrent file, the topological view of the network is the same), so slow peers would be a bottleneck, and in general it'd be a waste of bandwidth where you can just stick a thumping big cache next to you on the network with cheap bandwidth to it.
|
|
ottk3
wrote on the 5 Mar 08 at 12:50
|
|
|
|
I would prefer an option to use torrent instead, if the package size is bigger than (maybe) 2-5MB, so small files can be downloaded quick from the server, while bigger files can be downloaded via torrent
|
|
|
|
As long as it's optional I'm fine with that.
|
Post your comment
|
Blueprint apt-torrent:
