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.
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?
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.
+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.
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.