http://brainstorm.ubuntu.com/item/7792/
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.

4) Availability. Each seed's data and each distributed copy of data from the peer collective combine to provide a level of redundancy that far exceeds even the most exhaustive list of HTTP and FTP mirrors. The ISOs and repositories would never be offline, even if Canonical's servers went down for weeks (many torrents retain availability after the trackers have gone offline).

Implementation Ideas and Challenges

1) Package/ISO Tracker Allocation. Due to the huge number of packages in the various Ubuntu repositories, special attention would have to be given to how the packages were allocated to Canonical's BitTorrent trackers. A logical relationship would need to be established between the existence of a tracker and the torrents and torrent data it was serving. I suggest that an algorithm be developed generate both trackers and torrent files programmatically, based on the current method of tracking packages and their dependencies. Synaptic, etc., will synchronize with this list.

2) Because a single torrent can contain multiple files, any of which can be downloaded by themselves or in groups, it would be logical to group multiple related packages in a single torrent. For instance, a package with 50 MB in 10 required dependencies could include these dependencies in the torrent. The torrent could point to a single copy of each package on Canonical's servers to eliminate storage redundancy. Synaptic, etc., would only download the packages in the torrent that weren't already installed, rather than downloading the entire torrent. This would also eliminate the need for a single app install to download hundreds of separate torrents.

3) Much like the popularity contest opt-in, Ubuntu users could choose to seed their installed packages as a way to contribute to Ubuntu. Users could schedule seeding and throttle the allocated bandwidth, and it could be performed as a silent background process. Even more, Canonical could award such seeders with Ubuntu store credit for each gigabyte seeded. This would result in more people with Ubuntu T-shirts, hats, etc., and a stronger community and public presence, while saving Canonical untold dollars in bandwidth expense.

4) Some smaller downloads would be slower to install, particularly if for whatever reason both multiple torrents and trackers needed to be connected to. Torrent downloads tend to start slow and speed up as more connections are gained. Generally there is a significant lag before any data is downloaded, proportionally greatly increasing the download time of a small download. This could be eliminated by allowing the traditional method of download for smaller packages/updates. The Update Manager or Synaptic could make this judgement.

5) Downloads of multiple applications from Add/Remove or Synaptic could be executed simultaneously rather than sequentially, greatly decreasing the total time spend downloading.

6) System updates and other packages could automatically be seeded by the system after download until a user-defined share ratio is attained.

7) Heavy use of trackers by Canonical's servers would migrate the expense from bandwidth to processing power, possibly requiring a retooling of their server hardware infrastructure.

That's all I got...

[2213 votes] Solution #1: Auto-generated solution of idea #7792


[6 votes] Solution #2: Make debtorrent active by default


[5 votes] Solution #3: Make debtorrent available at install


[4 votes] Solution #4: Stop seeding after reaching 1:1 ratio by default


[1 votes] Solution #5: Run Torrend and HTTP download mixed.


]]> en-us Mon, 28 Apr 2008 19:10:07 +0000 Thu, 29 Dec 2011 10:48:06 +0000 QAPoll module http://brainstorm.ubuntu.com/idea/7792/ Mon, 28 Apr 2008 21:00:02 +0000 Not to mention that "unlimited" access is indeed limited. Should you exceed their acceptable use limit, they will do one of two things:

1. Charge you the extra bandwidth consumption.
2. Cancel your service.

Not all companies do this, but Comcast has made it clear there is indeed a limit to their "unlimited" accounts.]]> Mon, 28 Apr 2008 21:05:06 +0000 Mon, 28 Apr 2008 22:31:41 +0000
8) Torrent should be default but OPTIONAL. There should still be the traditional method of mirroring and downloading directly from the servers. Torrent could be default, but there should be a checkbox or something in add/remove programs to enable/disable peer to peer updating.

9) By default, bittorrent should only offer a 1:1 ratio of uploading. This means once the download is complete and one full upload amount of bandwidth is used up, it should shut off automatically. This will prevent unsuspecting users from having their upload taxed 24/7 unwittingly. You shouldn't be silently punished for using Ubuntu. Likewise, there should be a setting for how large the download to upload ratio can get prior to shutting off, and a bandwidth cap and peer cap for uploads (default to 128kbps up and 1 upload to a peer at a time).

This would be a sane default for most users on cablemodem/DSL on the consumer end, an allow enthusiasts to "crank" their p2p ability up so to speak, and get more prizes from canonical. The primary idea here is that the users who "leech" (ie, don't offer up more bandwidth than default) will not be a net drain on the system, but those that want to contribute more should have that option in an advanced panel.]]> Tue, 29 Apr 2008 03:35:27 +0000 Tue, 29 Apr 2008 07:35:13 +0000 Tue, 29 Apr 2008 08:03:12 +0000 Tue, 29 Apr 2008 10:21:56 +0000 Tue, 29 Apr 2008 14:01:25 +0000 Tue, 29 Apr 2008 15:35:22 +0000 Tue, 29 Apr 2008 17:24:26 +0000
But it's important that
1. You can turn it off
2. It automatically fails over to normal http download (like the World of Warcraft updates do)]]> Tue, 29 Apr 2008 17:52:33 +0000
My Internet has very small upload speed, and it throttles download speed, so downloading is usually faster then torrenting. Also, in my experience, whenever there is the choice between downloading and torrenting, the provider provides very poor service and speed for the downloaders.]]> Wed, 30 Apr 2008 00:33:51 +0000
]]> Wed, 30 Apr 2008 01:31:43 +0000
DebTorrent work at http://wiki.debian.org/DebTorrent
DebTorrent on Launchpad (says "fix released"?) https://bugs.launchpad.net/ubuntu/+bug/106382
AptTorrent work (seized, it seems) at http://sianka.free.fr/?lang=en
AptTorrent request on Launchpad https://bugs.launchpad.net/ubuntu/+bug/153752

Needless to say, +1 :)
]]> Wed, 30 Apr 2008 08:54:51 +0000
keep a few mirrors up for non p2p users and limited bandwith users

in france no limit upload 24/7 for opensuse but definetely would prefer doing this ubuntu

nice idea about the credits gained for the shop if you upload a lot and therefore help ubuntu community

by the way http and ftp servers can be used to boost the slow torrents and there could be a dedicated page for willing uploaders to reference the torrents which need to have an upload boost

+1]]> Wed, 30 Apr 2008 10:18:53 +0000
1. BT should be recommended, but not default. Add a nice description and this will keep most users from being punished by their ISPs.

2. Allow max bandwidth option. This should included both the option to cap the up/down rate as well as a maximum total upload size.

3. Allow the option of only getting torrented packages through the local subnet. If not available, then download from public repository. This would be a beautiful thing for corporations with Internet connections that are near capacity. (or see #2)]]> Wed, 30 Apr 2008 13:46:48 +0000
-1]]> Thu, 01 May 2008 22:00:02 +0000
+1]]> Fri, 02 May 2008 03:32:04 +0000 Also, giving users store credit is strange: we save money by giving people stuff! Please, give us some numbers before you make claims like that.
Furthermore: giving users the choice to regulate bandwidth, times and whatnot for seeding adds quite a bit to setup complexity, and most users will see this as something they need to do to restrain their OS from doing bad things. We do not want that image.

Remember folks, this is supposed to be a mainstream OS. All this stuff appeals to some hardcore users and will likely scare away the rest ("It will use MY internet connection so that THEY can save money?!")

Sidenote: I am all for offering Ubuntu ISO downloads as BitTorrent. I know Canonical already does, I get mine that way, but they're buried deep in download pages most people never see. Put up links to the torrents front and center.]]> Fri, 02 May 2008 10:38:10 +0000
There are many packages on the install CDs which are currently being downloaded from ubuntu.com even if the CD version is the latest current.

Shameless plug: if you want to fix the download problem, the highest improvement for the required effort fix right now is probably http://brainstorm.ubuntu.com/idea/7959/.

Of course, if you have a 4x CDROM drive, and a 12Mb download speed, the current solution may work faster. I doubt most people have that kind of a situation, however.]]> Fri, 02 May 2008 11:42:35 +0000 Many universities and other institutes block torrenting. We need ubuntu to work out the box.]]> Fri, 02 May 2008 15:48:44 +0000
opensuse does it just do the same!:

http://software.opensuse.org/

it's obvious that credit idea isn't going to work cause their's no way you're going to make economies like that


anyway leaving ubuntu cause it's 10 time worse quality than any windows distros so changed for opensuse now. bye]]> Sun, 04 May 2008 00:25:37 +0000 Wed, 07 May 2008 15:49:00 +0000
- Except, HTTP sucks at validating files really.
- Some mirrors aren't kept up to date well, or have issues. Bittorrent is more "fuzzy", and doesn't suffer from bad mirrors really.
- Bittorrent also gets faster under more load. The download mirrors die every dist upgrade.. Bittorrent will get around that]]> Thu, 08 May 2008 01:34:48 +0000 Thu, 08 May 2008 07:02:51 +0000
To people mentioning Comcast: all ubuntu users are not American subscribers to Comcast. Please think of the overall quality to worldwide users.

I think it would be the best use of my unused bandwidth yet. Personnally, I would more than gladly seed packages.

Plus, I think it would really help during version releases: many people would get up to date before the release, and therefore be able to seed those who would use update-manager the day of the release, hence considerably lowering the strain on the official http servers. ]]> Sat, 10 May 2008 13:03:36 +0000 I for one don't use Bittorrent or any peer to peer programs
ISP's here in Australia are starting to reduce the bandwith available to peer to peer connections.
So I don't see any advantage in using Bittorrent.
As I said make it an option but not the default.
]]> Mon, 12 May 2008 12:34:50 +0000
Most of you know that P2P is a decentralized download protocol. You download the .Torrent file from a server, your respective Bittorrent program (transmission, uTorrent, BitTorrent, BitComment, Asurous (spelling?), W/e) will connect to the tracker and then download the file from Everyone connected to the tracker. So, instead of everyone downloading the packages directly from the official package repos mirrors (which, after a while, gets expensive in terms of server maintenance, bandwidth, employees to keep stuff working, etcetera etcetera) the mirror only has to send one single copy of the file into the swarm before the torrent can be distributed 100% to all downloaders, so long as there is at least one copy of every chunk of the file in the swarm at any given moment. this cuts the server load for the mirror operators down by a seriously significant amount.

torrent speeds might not be all that great sometimes, and sometimes any peer to peer at all is blocked by your ISP (college, work, w/e). thats why, the package manager would do a check first with the server "what speed can you give me today, mr server? do you know if the torrent swarm would be faster today, mr. server?" and, if you allow synaptic to use bittorrent to download the package, you cut the server load, and potentially get your package faster when using bittorrent.

there is significantly less chance of getting your download preempted with someone elses malicious file, considering that your download isnt coming from One Single place which might just happen to have a man-in-the-middle. if any particular piece of the package comes from a malicious host, BitTorrent would reject it, it wouldnt pass the checksum, and BitTorrent would re-download it, over and over and over until it did. (which would more than likely happen the first time). so out of the box implementing Bittorrent increases security slightly.

if for some reason the download is taking much longer than it really should (or if some some reason there is a failure during the download with Bittorrent, synaptic would default directly back to HTTP. potentially without the user even noticing that that happened.


for those of you who are afraid of being used and abused by your isp (and for those who are tracking the media fiasco with P2P being claimed to be used for nothing but illegal transfers (how can you copyright a number? seriously..) implementing package downloads in ubuntu will help to raise awareness in the general public about other open source projects being fully legal and in some cases better than their closed-source equivalent)


to sum up my points: the downloader could check which was faster (on average) (http, ftp, bittorrent, w/e other option), and download via the fastest route. optionally it could seed the file obtained by http or ftp to increase the swarm speed for other torrent users

there is a possibility of creating a max bandwidth / day setting, for those worried about overstepping caps. but if your downloading via http anyway, there doesnt seem much point to that.

bittorrent would be Optional.

bittorrent will decrease the server load on repos mirror hosts. i dont care HOW you calculate it, if you decrease server load, the cost of operation for the owner/operator for that server goes down. meaning more resources for other things. ]]> Tue, 13 May 2008 02:18:13 +0000

consider the situation where you have a household with multiple computers (for purposes of this thought, consider they are all running the same version of ubuntu)

if you want to update ALL of your computers at the same time, you will be downloading a copy of each package once for EACH computer. so if you have 5 computers, and want to download 20 1 megabyte packages for each of them. instead of downloading 20 megabytes, you have to download 100 megabytes.

but thats only for HTTP

potentially (best case, people, best case)

if you use the bittorrent download method for each of these stations, you might end up having the gateway computer (if you have one, go with me here) download the packages via bittorrent, and then instead of each other station downloading from the external wan, you would just bittorrent from your gateway. you just cut your bandwidth down by 1/5th of what it would have been for that update by using bittorrent. ]]> Tue, 13 May 2008 02:22:52 +0000
you wouldn't have to have your gateway run a bittorrent client. Each client on your local LAN would automatically find each other in the swarm (because they are close to each other, they would prefer each other) and then most of your download speed would come from your local systems, allowing the seed to spread automatically throughout your household (or business) LAN.

The end result is that you would download the updates and that comp would share it to your other systems automatically, and it would scale very very well on local LANs.]]> Wed, 14 May 2008 03:34:14 +0000 ISP's here in Australia are starting to reduce the bandwith available to peer to peer connections.
So I don't see any advantage in using Bittorrent."

It's insanely faster. I did my Hardy Heron upgrade by torrenting the CD very quickly on the release day when the regular servers weren't even responding. If your ISPs are reducing bandwidth, you should be finding a different ISP or fighting against them if they are a monopoly.]]> Wed, 14 May 2008 21:10:17 +0000
your absolutely right.

when i posting that i had in my mind a model that as soon as one system (in the example, the gateway system, but in reality any would qualify) downloaded a chunk, it would be the preferred source for that chunk among the rest of the local systems.
but the way you describe it is more accurate.]]> Wed, 14 May 2008 22:31:52 +0000 However, one problem is that currently many corporate networks don't allow p2p (such as bittorrent) traffic. This is the case where I work for example, where I had trouble with the admins for downloading the new Ubuntu .iso via torrent... So, +1, but there should be a way to turn it off...]]> Tue, 20 May 2008 14:32:03 +0000
]]> Wed, 21 May 2008 02:50:33 +0000 It should be implemented as soon as possible.

Those who want to vote against it,first understand what is being discussed.Just because YOU wont benefit from it does not mean millions of others wont.Please help to promote it for the sake of your brothers!]]> Fri, 23 May 2008 07:09:19 +0000
Then the network admins are stupid. This would BENEFIT corporate networks a lot because they would download the updates from each other instead of having to download it separately for each computer. This would be a great thing for corporations that use Ubuntu.]]> Tue, 27 May 2008 15:59:28 +0000 Sun, 01 Jun 2008 04:48:16 +0000 Sat, 21 Jun 2008 21:50:53 +0000

1. Not to download faster in usual conditions, but to lower the load on servers at a new release, major updates...

2. It should be first download option, and apt should give away if they are no peers, or if download is much too slow. Real widespread cooperation !!

debtorrent and apt-transport-torrent already did a part of the job.

(finally universities, ISPs would not confuse thepiratebay and bittorrent ;) )]]> Sun, 06 Jul 2008 09:13:29 +0000
http://debtorrent.alioth.debian.org/

theres the webpage (google "debtorrent")

i followed the install steps exactly and as a test of it, on an old crap system i have, i ran

for pkg in `dpkg --get-selections | awk 'print $1' | egrep -v '(dpkg|apt|mysql|mythtv)'` ; do apt-get -y --force-yes install --reinstall $pkg ; done

(grabbed from somewhere in the ubuntu forums)
everything works just dandy.


im not sure what issues debtorrent still has, as i didnt spend too much time looking at it, but id like to suggest looking into possibility of integrating debtorrent into APT

(for those who mention that some places dont allow p2p protocols, it should be noted that when debtorrent couldnt find a peer to download from (a few of the repos had no peers at the time) it reverted to http and proceeded as normal. all in all, i think i ended up with a net speed increase, and waiting to fall back to http happened with no noticeable overhead)

-Mishtal]]> Mon, 07 Jul 2008 02:56:53 +0000 Fri, 11 Jul 2008 15:51:37 +0000 Thu, 31 Jul 2008 19:02:24 +0000 While this is technically not the end of the network world, I can see it clearly from here.

When I use the following Bittorrent configuration:

$ btshowmetainfo ubuntu-8.04.1-desktop-i386.iso.torrent
btshowmetainfo 20021207 - decode BitTorrent metainfo files

metainfo file.: ubuntu-8.04.1-desktop-i386.iso.torrent
info hash.....: cdbfcd61f52525559d08514ba525e2d3189953b3
file name.....: ubuntu-8.04.1-desktop-i386.iso
file size.....: 728221696 (1388 * 524288 + 509952)
announce url..: http://torrent.ubuntu.com:6969/announce

I get really sucky speed:

| file: ubuntu-8.04.1-desktop-i386.iso |
| size: 728,221,696 (694.5 M) |
| dest: /svrland/isos/ubuntu/ubuntu-8.04.1-desktop-i386.iso |
| progress: ##________________________________________________________________ |
| status: connecting to peers (4.0%) |
| speed: 0 B/s down - 0 B/s up |
| totals: 0.0 M down - 0.0 M up |
| error(s):

Note that this is after two hours...

Anybody with any ideas?

Regards,

Flint
]]> Sun, 03 Aug 2008 18:31:39 +0000 Remove as soon as ratio is 1:1
Upload is really slow
It can fall back on http when a problem occured.

it should be optionnal, and not default (or if default, make it very easy to change it, say tright after install, the first time you see the update manager, it's an already checked checkbox, so it's easy to change).

But I promise I'd use it, with fast upload (I can easly give 40k/s for canonical ! ) and high ratio (5:1 at least) so to help the guys who made it possible.]]> Wed, 06 Aug 2008 09:05:48 +0000 Fri, 08 Aug 2008 15:30:50 +0000 Sun, 10 Aug 2008 18:58:52 +0000 Sun, 10 Aug 2008 18:59:25 +0000 2) Test which protocols (HTTP/Bittorrent/...) are available
3) Download a few packages with all available protocols and measure the speed
4) Remember which protocol was the fastest (if it's a near-tie, prefer P2P over HTTP)
5) If a P2P protocol was the 'winner', and *only in this case*, prompt to seed use this protocol and whether you want to seed downloaded files while not downloading yourself.

This way, people that don't need/can't use a P2P network aren't bugged with the question, and people with a data limit (like in Belgium, 25 GB *sigh*) can choose not to use this option.]]> Tue, 19 Aug 2008 19:16:13 +0000
That is already built into the bittorrent protocol. The .Torrent file has a hash for each "chunk" of the torrent, and then a hash for the entire file. Because we know that the publisher of the .Torrent file will be the server (or someone pretending to be the repo server, but that's an authentication issue), we know that if the chunk doesn't match with what the .Torrent file says it should be, we need to discard it. Most Bittorrent clients automatically stop downloading chunks from peers that continually send bad chunks.

Additionally, since half of a file might come from peer A, and a quarter might come from peer B, while the last quarter might come from peer C, even if peer A and peer B were both trying to seed the same malicious file, and even if they some how got past the .Torrent file's hashing checks, the last quarter (not necessarily a contiguous chunk of the file, i mean 25 % of the total file, potentially randomly distributed) came from peer C, who (since this is a made up situation) we know is seeding the correct, non-malicious, file. unless peer A, and peer B, were REALLY good at writing their malicious program, the chances of the file even (if it was executable, anyway) running without segfaulting and dieing right away are pretty slim.

so, yea, Bittorrent already has security in place. as far as i can see its not a concern. ]]> Wed, 20 Aug 2008 19:15:21 +0000 Fri, 22 Aug 2008 20:29:35 +0000 Sat, 04 Oct 2008 01:17:15 +0000 Fri, 17 Oct 2008 17:47:22 +0000 Fri, 17 Oct 2008 19:41:15 +0000 Wed, 29 Oct 2008 23:52:43 +0000 Thu, 30 Oct 2008 17:53:49 +0000 http://www.camrdale.org/apt-p2p/
]]> Mon, 03 Nov 2008 15:26:47 +0000
Canonical already hosts a torrent tracker for the .iso, which helps with upgrading, why not do something similar with the system distro upgrade? The people who already torrent the .isos when they upgrade would most certainly be happy with the convenience.

@all the folks who are worried about what the defaults would be

I say that we have the system ask the user on install. We present the pros and cons, and then let them choose. We say that if they don't know what the prompt is talking about that choosing "no" is a good idea.
Synaptic, or the update manager, or something could have an option in the properties menu. The default would be set to 1:1
Users could give per repository defaults for ratio and speed.
It would ALWAYS fall back to normal HTTP.
The user could even configure it on a #peers/swarm basis, a download speed basis, or by network (check with network manager?)
The user could give an availability time for how long they would allow the file to be downloaded form them after download
They could also specify the end ratio, and say which combination of the criteria would end seeding for the package in question.

Heck, maybe we can even set it to a per package basis, if we REALLY wanted to.

The only problem that I have with the current situation is that if ubuntu doesn't have this *option* in the distribution already configured and ready to go with a click, that cuts a large chunk of people out of the group that would otherwise participate. Humans are uninterested in how their computer works, so long as it works, for the most part. It's rare that a Human rips apart source code.

Even the set up for DebTorrent is far too complicated for someone like my dad to figure out, and he's no slouch to boot. he just has other stuff to deal with, and doesn't care.

-Mishtal]]> Tue, 04 Nov 2008 00:52:21 +0000


How many users were there in the swarm

whats your ISP (do they interfere with bittorrent traffic specifically)

what networking set up do you have? wireless? direct to modem? router?

what kind of line to you have?

what was the max upload speed set to on your application

any other network activity at the time?]]> Tue, 04 Nov 2008 00:55:12 +0000
Check these out

http://torrentfreak.com/use-bittorrent-to-upgrade-to-ubuntu-intrepid-ibex-081029/

https://blueprints.launchpad.net/ubuntu/+spec/torrent-distro-upgrade]]> Tue, 04 Nov 2008 17:28:31 +0000 ""However, one problem is that currently many corporate networks don't allow p2p (such as bittorrent) traffic."

Then the network admins are stupid. This would BENEFIT corporate networks a lot because they would download the updates from each other instead of having to download it separately for each computer. This would be a great thing for corporations that use Ubuntu."

Network admins aren't stupid in these cases, most of the time it's usually the decision of the higher authority in the organization to stop p2p/BT traffic. It costs money to have errant employees suck bandwidth in the background while they work. It either just costs for the bandwidth, or it costs + clogs the network. It's not like this in every environment, but it's in enough of them with such a gestapo crackdown that even the IT admins who would be running these servers/workstations that could benefit don't want to chance it.

This wouldn't bode well for 'regular' people who may not have the BT port open on their paranoid router, their router just sucks ass, their ISP filters and flags their account, etc. I could go on and on. Yes you and I could circumvent the filters and other issues, but the average person who simply uses the computer and wants to update is going to run into problems in a lot of network environments. And typically if someone discovers that using this software (Ubuntu) gets them in trouble, or what they perceive is trouble or unwanted attention, then it's a turn-off...the question is asked then 'why not just use windows, it's safer', even though that's oxymoronic in itself.

Yes be utilitarian and think about the greater good, but remember that in some respects this is only serving the greater population of people who KNOW how to use their Ubuntu system. People included in this group are NOT my family, or most of my friends, or any of my co-workers.

If ISPs and media companies would just STFU about BT being "evil", etc. I see this as a wonderful solution and would embrace it like none other. But I think until BT is cast in a better light, more people will have a problem with this than not if it were default. Make it an option, by all means, but don't make it Default.]]> Wed, 12 Nov 2008 00:42:37 +0000 Thu, 27 Nov 2008 13:17:16 +0000 The servers almost die at release times. This would lighten their load. Of course, HTTP/FTP should still be there as a backup protocol though...
@those arguing about bittorent being blocked, change your ISP. And when the next general election comes, get rid of the fascists who decided bittorent needs to be blocked and that free speech is unimportant.]]> Sun, 28 Dec 2008 19:07:39 +0000 If ISPs and media companies would just STFU about BT being "evil", etc. I see this as a wonderful solution and would embrace it like none other. But I think until BT is cast in a better light

Well it's certainly not going to be cast in a better light if people like you block it from being used for legitimate purposes...]]> Mon, 29 Dec 2008 21:52:17 +0000
Still: +1.]]> Tue, 30 Dec 2008 02:41:16 +0000
"I have an internet flatrate (16.000 kBit/s) and would like to support the ubuntu community when new Ubuntu releases are offered.

I would like to suggest to implement Ubuntu torrents into the Ubuntu system. Ubuntu updates should be made by Bittorrent. After the download I would like to offer the Ubuntu files to the community by Bittorrent.

You should implement such Bittorrent feature, especially for free software. Every time a new Ubuntu release comes out, the Ubuntu system should ask the user if the user would like to support Ubuntu by offering the updates via Bittorrent to other Ubuntu users.

The User should be able to decide, whether it wants to limit upload speed, or offer the updated files only for a limited time (e.g. 30 days), or online for limited upload volume (e.g. 10 x the download size, or 4 GB upload volume), etc."

User "arky" found an existing solution for debian ("debtorrent", check this out):

http://packages.debian.org/de/lenny/debtorrent

Would'nt it make sense to implement this in Ubuntu?]]> Thu, 03 Sep 2009 21:28:35 +0000 Sat, 05 Sep 2009 16:25:17 +0000 Fri, 02 Oct 2009 16:14:10 +0000 Sat, 03 Oct 2009 18:15:14 +0000 Sat, 19 Dec 2009 20:57:07 +0000 I am surprised people would rate this down, not because they could just use HTTP instead of Bittorrent, but because all the Bittorrent users wouldn't be using the main servers (at least nowhere near as heavily), thus freeing up bandwidth that can be given to everyone else in higher volumes.

My reason for wanting this (aka rationale): The date is 5/16/2011, a majority of the release stress should be gone, yet even after having it "Select Best Server" I am getting 94KiB/s. Generally when I torrent stuff I let it reach a ratio of 1.5 and continue until I delete the file (only intentionally did that to Nexuiz because of it's devs and the release of Xonotic). I generally upload at 20-50KiB/s when other people are connected to the router and, if I remember to do so, 100-300KiB/s when no one else is connected. (our max upload is about 400KiB/s)

I agree with the others that we should use debtorrent. It already exists, works (how well? I don't know yet), is pretty much seamless to use (I just tried it today), just "sudo gedit /etc/apt/sources.list" and replace "HTTP://" with "debtorrent://localhost:9988/" after installing debtorrent. If something doesn't work like getdeb.net/, just revert to HTTP.

I don't see the point in giving an option for using bittorrent or not since debtorrent also uses HTTP (not sure if its a backup plan if there aren't peers or if it supplements peers) and it downloads everything simultaneously which speeds things up if the files are from different servers, but to keep them happy, have the default option be HTTP when asked for the first time. As for share ratios, it should ask the user for a share ratio the first time bittorrent mode is used, for every piece downloaded it will add the size multiplied by the share ratio to a variable which is then decreased by the size of every piece you upload. It should also ask for an upload speed the first time it is in bittorrent mode (one for when share ratio is met and another for when it isn't). Since share ratio will be independent of the files now, the cache can be shrunk based on what needs to be seeded (need will be based on seed:peer ratio and size of file) rather than how much has been seeded, thus making you a far more useful seed and avoids a situation where you have a cache full of files that nobody wants.

The repositories should default to using SHA1 instead of MD5 since it is the default of bittorrent and is much stronger (160bits instead of 128bits, making it 4,294,967,296 times stronger based on bits, then again the algorithm could make that negligible or significant). This way when the package list is downloaded which contains hashes (MD5 currently), it doesn't have to ask for a torrent, it just uses the existing hash. This could be invalid since I don't completely understand the process, but I know that every package page lists an MD5 hash for each architecture.]]> Tue, 17 May 2011 06:54:42 +0000 .>

As for my last paragraph about repositories, apparently both MD5 and SHA1 are listed in the package lists (see for your self by finding one in /var/cache/debtorrent) here is a packages info, minus a bunch of stuff

Package: firefox
Installed-Size: 39324
Architecture: amd64
Version: 4.0+nobinonly-0ubuntu3
Filename: pool/main/f/firefox/firefox_4.0+nobinonly-0ubuntu3_amd64.deb
Size: 16241960
MD5sum: 6ebc1efd2311dbcc1c0b89de9251fb2f
SHA1: 17f3b291550fc4d8b6afa40621c58f24dd9965d7
SHA256: abc7d3699b70d7051a57e626595b2c661a494a57025eed48821af0afb0fc2bcb]]> Tue, 17 May 2011 10:06:21 +0000 $List=https://launchpad.net/ubuntu/+archivemirrors

To learn how the repositories work its probably most useful to explore one (like I'm doing right now :P), go to $Main, click on dists, pick one that looks familiar like "maverick" (contains all packages that it was released with) and look at it's "Release" file, it should only be a day old, now look inside it to find the various components and architectures of the repository, I'll go with restricted/binary-amd64/Packages.gz because I want to look at the package nvidia-current (We are currently at $Main/dists/maverick/restricted/binary-amd64/Packages.gz).
At this point we can use the information from Packages.gz to download "nvidia-current" version "260.19.06-0ubuntu1" through two ways:
1. Download "$Main/pool/restricted/n/nvidia-graphics-drivers/nvidia-current_260.19.06-0ubuntu1_amd64.deb" through HTTP (or as a webseed) 2. Bittorrent using its SHA1 hash "257de7496f7ca4b3e95047ec5cca449a193e90b3" which needs to be converted from base16 (hexadecimal) to base32 so it is "EV66OSLPPSSLH2KQI7WFZSSETIMT5EFT" (according to http://darkfader.net/toolbox/convert/), which can be appended to "magnet:?xt=urn:btih:" to create a magnet link. Unfortunately when I tried this DHT was disabled, so the hash probably needs some kind of modification, would someone mind sharing how debtorrent gets the correct hash?

I've tested a bit and it looks like webseeds can be used alongside other webseeds and peers. So if bittorrent were to be implemented we should have "Select Best Server" in Software Sources select the top 3 servers to be used as webseeds with one of them as a primary to get repository info from. Some repositories would be out of sync, so before attempting to download from a secondary repo the package should be verified to be the same version first. The primary of the three could be determined each time "apt-get update" is called by finding the one with the most up to date "Release" file.]]> Fri, 20 May 2011 20:08:22 +0000 In fact, imao. it's really not necessary that peers contribute and seed the torrents by default.
The advantage in mirror load balancing, mirror utilization (possible to download from all mirrors at once), mirror syncing (just download the torrents and seed them) IS ENOUGH REASONS. If some people can't actively contribute to the swarm because of firewalls, limited upload etc. that doesn’t matter. Its still better than HTTP/FTP.

Also about the small files problem, how about using one big torrent file for everything and then just disable downloading of the files we do not want? That way, small files would be less of a problem because we would be downloading all files at once instead of one at a time. So then, start-up time would become negligible unless one just want to install a single program. ]]> Sun, 29 May 2011 06:18:23 +0000
I think this is a very good idea. It should also be incorporated into Synaptic and Ubuntu Software Center.

This will definitely encourage users to install more software on their computer, which ties in nicely with Ubuntu encouraging users to download apps through their "apps available for install" section that is listed whenever you search for an application in the Unity Dash.

If implemented, this will be a unique advantage of Ubuntu over other operating systems that also offer software centers or app stores, such as Apple and, soon, Microsoft. ]]> Sat, 11 Jun 2011 05:23:31 +0000
i think it should be a feature automatically turned on but eaily (without uninstalling and installing another packet manager) should be turned off if wanted.

i also believe that getting launchpad with their ppa's and ubuntu's packet servers to be have torrent seeds of all their packages would be preferable. ]]> Mon, 01 Aug 2011 17:33:25 +0000 Fri, 30 Sep 2011 20:23:51 +0000 Thu, 29 Dec 2011 10:48:06 +0000