Ubuntu QA:
BlogBrainstormPackage status
Log in
Ubuntu QA
The Ubuntu community has contributed 22700 ideas, 138270 comments, 2629576 votes
Idea sandbox Idea sandbox
Popular ideas Popular ideas
Ideas in development Ideas in development
Implemented ideas Implemented ideas

Contributor kevinfishburne

Use BitTorrent as primary protocol for apt-get  
Ubuntu

In :  
Priority : Undefined
Definition : New (Needs guidance)
Implementation : Unknown
Assignee :
spec
forum
Written by kevinfishburne the 28 Apr 08 at 19:10. Global category: Internet & Networking. New
This is an attempt at a unification of:

http://brainstorm.ubuntu.com/idea/7081/
http://brainstorm.ubuntu.com/idea/7390/
http://brainstorm.ubuntu.com/idea/7649/
http://brainstorm.ubuntu.com/idea/7725/

I can't think, nor have I heard, of any showstopper reason for why BitTorrent shouldn't be used as the primary download method of Ubuntu respository packages. Although the specifics of the implementation of this idea will be different for ISOs and repositories, I feel they should be unified in the brainstorm because the goal is to allow the rapid, efficient, reliable, and available download of Ubuntu software.

Implementation Benefits

1) Speed. All Ubuntu downloads (ISO downloads, dist upgrades, regular system updates, and new application installs) will as a whole be faster. Generally torrent download speeds benefit from higher numbers of downloaders that seed, which Ubuntu users have demonstrated they are prone to do. BitTorrent is better able to absorb (and eventually use as an asset) large numbers of users attempting to download data at the same time, such as with the recent mad rush of Hardy downloaders/upgraders.

2) Efficiency. The BitTorrent protocol has proven to be one of the most efficient methods of distributing data amongst a large number of clients. It will harness the collective upstream of tens of thousands of Ubuntu users, from DSL and cable connections to the fastest of corporate connections.

3) Reliability. Checksums guarantee the integrity of BitTorrent downloads, so data corruption is much less likely to occur. Only the pieces that fail checksum are redownloaded, contributing to points 1 and 2.


[....]
2220
votes
up equal down
Solution #1: Auto-generated solution of idea #7792
Written by kevinfishburne the 28 Apr 08 at 19:10.
Ubuntu Brainstorm was updated in January 2009. Since the idea #7792 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!
8
votes
up equal down
Solution #2: Make debtorrent active by default
Written by bukzor the 9 Apr 11 at 19:12.
There is already a system to do this: debtorrent (http://debtorrent.alioth.debian.org/)

The *main* problem with it is that there are so few users that have it installed. Making this installed and active in the default Ubuntu distribution solves this bug, as well as implementing Idea #7792 (and its 30 duplicates).

It seems fairly mature, but probably still needs some polishing for inclusion in the Ubuntu default. In particular, we need to ensure that the upload settings are very easily tweaked, both automatically and manually.

12
votes
up equal down
Solution #3: Make debtorrent available at install
Written by lengau the 25 May 11 at 20:32.
Rather than making debtorrent the default, which could be harmful to a large number of users (some ISPs block Bittorrent, as do many universities, etc.), we should allow users to choose debtorrent an option in the installer (as well as being able to enable/disable it in the software centre).

Including the debtorrent and apt-transport-debtorrent packages on the CD/DVD will add just short of 300 KiB to the disc images.
7
votes
up equal down
Solution #4: Stop seeding after reaching 1:1 ratio by default
Written by Lyfang the 24 Jun 11 at 08:01.
Make DebTorrent or Apt-P2P active by default and stop seeding after reaching 1:1 ratio by default.
6
votes
up equal down
Solution #5: Run Torrend and HTTP download mixed.
Written by AdlerHorst the 29 Dec 11 at 10:49.
Run Torrend and HTTP download mixed. If Torrend is slowed down, the http download stil do his job. If torrend is faster, the HTTP plays the role of one of many download streams.

See the 75 comments or propose a solution (latest comment the 29 Dec 11 at 10:48) >>

Canonical and the Community - Stabilize and Modernize all LTS Releases  
Written by kevinfishburne the 5 Mar 09 at 07:34. Global category: Usability. New
Currently deciding between an LTS and the latest (or any other) release is a crap shoot between user-estimated stability and user-estimated feature set, either of which may or may not result in a "well-taken-advantage-of" system.

While important, six-month release cycles need to be de-emphasized and LTS releases need be spoken of with confidence when concerning most unknown hardware and arbitrary user-space software configurations.
22
votes
up equal down
Solution #1: Devote More Resources to LTS Repositories
Written by kevinfishburne the 5 Mar 09 at 07:34.
I propose that the Canonical programming staff and their partners in the community split their attention 50/50 between (1) choosing and refining the packages for the next Ubuntu release and (2) maintaining and QA-testing all Ubuntu x.xx LTS backports repositories. The level of work admirably performed by the backports staff for LTS releases should receive equal attention to that performed by regular app maintainers and cherry-pickers of packages for future releases.

While this may sound drastic or like a waste of resources, it is imperative that Ubuntu become more than a six-month freak show of an OS that runs near perfectly on SOME hardware configurations. LTS releases should be -fully- supported, including bug-fix patches and kernel modifications that add support of newer hardware while attempting to avoid regressions, misconfigurations and other fashionable bugs.

(This calls for some programmers and programming teams to make more realistic distinctions between stable and developmental versions of applications.)

Granted, it is difficult to distinguish between a "stable" version and any other version, so how would one decide to include an allegedly stable version of an application into the backports repository? That question is what needs to be addressed by the backports community (you, I and Canonical) and dealt with by greater resources, imagination, and vigilance.

See the 2 comments or propose a solution (latest comment the 9 Mar 09 at 06:16) >>