4 ms·

I'd like to point out that this is a good time to really test your connection. I've never downloaded anything faster than a torrent of a fresh ubuntu release.

beaumartinez 16y ago
BitTorrent download speed has a lot less to do with bandwidth than with how many peers you can connect to, and downloading these things fresh there is often a lack of them. I BitTorrented the 64-bit Desktop edition it as soon as OMGUbuntu broke the news on Twitter and it took me around half an hour (for 700 MiB).
- JonnieCache 16y ago
  Maybe not when its that fresh. By the time its top of HN and /. then there are gonna be a LOT of high bandwidth peers.
  - javanix 16y ago
    Yep. I usually find that most reasonably popular Linux distros will max out my down connection over torrents. Pretty nice way of telling whether my ISP is throttling or lying to me about my bandwidth.
javanix 16y ago
Though unfortunately upddate files are still distributed through centralized repositories. I wonder whether there'd be major security concerns if a torrent layer was stuck over the main centralized backbone? It could probably reduce bandwidth costs for hosting and provide better speeds to people, though keeping the "swarm" updated might be kind of tricky.
- eschulte 16y ago
  +1 for this idea, I think "eventually updated" should be largely sufficient for a generally one-way change like repository updates. I'm "live updating" right now, and the time estimates jump between 2 hours and four days depending (I believe, given the stability of my schools internet connection) on the load on the ubuntu repositories.
- ZoFreX 16y ago
  Security concerns can be dealt with via the pre-existing public/private key crypto that's going on in apt already. The problem with torrents is they don't work well for lots and lots of (relatively) small "file groups" where each user has a lot of the files, but each user has completely different files. Something based on tiger tree hashing or some other mechanism like that might be more suitable, perhaps?
  - javanix 16y ago
    True, in order to provide consistent benefit to users you'd need some sort of mechanism to determine whether it'd be faster to "grab from the swarm" or "grab from the repo". Perhaps even setting up each already-existing mirror as its own seed-center would help - there are plenty of them around, and by definition they all have the same data. Worst case you end up getting only one connection, and you have the same performance as now, but in the best case you can download from multiple locations at once and get some rudimentary load balancing.
minalecs 16y ago
as a reminder please seed : http://torrent.ubuntu.com/releases/natty/release/ http://torrent.ubuntu.com/releases/natty/release/

beaumartinez 16y ago

BitTorrent download speed has a lot less to do with bandwidth than with how many peers you can connect to, and downloading these things fresh there is often a lack of them. I BitTorrented the 64-bit Desktop edition it as soon as OMGUbuntu broke the news on Twitter and it took me around half an hour (for 700 MiB).

JonnieCache 16y ago
Maybe not when its that fresh. By the time its top of HN and /. then there are gonna be a LOT of high bandwidth peers.
- javanix 16y ago
  Yep. I usually find that most reasonably popular Linux distros will max out my down connection over torrents. Pretty nice way of telling whether my ISP is throttling or lying to me about my bandwidth.

javanix 16y ago

Though unfortunately upddate files are still distributed through centralized repositories. I wonder whether there'd be major security concerns if a torrent layer was stuck over the main centralized backbone? It could probably reduce bandwidth costs for hosting and provide better speeds to people, though keeping the "swarm" updated might be kind of tricky.

eschulte 16y ago
+1 for this idea, I think "eventually updated" should be largely sufficient for a generally one-way change like repository updates. I'm "live updating" right now, and the time estimates jump between 2 hours and four days depending (I believe, given the stability of my schools internet connection) on the load on the ubuntu repositories.
ZoFreX 16y ago
Security concerns can be dealt with via the pre-existing public/private key crypto that's going on in apt already. The problem with torrents is they don't work well for lots and lots of (relatively) small "file groups" where each user has a lot of the files, but each user has completely different files. Something based on tiger tree hashing or some other mechanism like that might be more suitable, perhaps?
- javanix 16y ago
  True, in order to provide consistent benefit to users you'd need some sort of mechanism to determine whether it'd be faster to "grab from the swarm" or "grab from the repo". Perhaps even setting up each already-existing mirror as its own seed-center would help - there are plenty of them around, and by definition they all have the same data. Worst case you end up getting only one connection, and you have the same performance as now, but in the best case you can download from multiple locations at once and get some rudimentary load balancing.

minalecs 16y ago

as a reminder please seed : http://torrent.ubuntu.com/releases/natty/release/ http://torrent.ubuntu.com/releases/natty/release/