(Responding to both Javier Fernández Garcia and Brett Viren) (Security)
Bittorrent is similarly secure to the existing debian mirror system. In a Bittorrent system, you'd be distributing .torrent files from trusted debian mirrors - torrent files contain cryptographic hashes for each block of the data. The bittorrent protocol is already error correcting using the cryptographic hashes - any bad data injected would be recognized and discarded (and the recipient may decide to not accept data from that sender again for the current session). There's actually a potential security gain: the set of trusted mirrors could be much smaller. On the other hand, aren't debian packages gpg signed anyway - making the whole security discussion redundant? (Granularity) The granularity issue and the latency issue are linked pretty closely. If you tried to implement this with existing bittorrent clients you'd run into exactly the problem that you mention - needing to have a separate instance of the client open for each .deb involved. It would be possible with the current protocol to have one big .torrent file for the entire release, similar to the package list you download when you say "apt-get update", and then to only download the individual files that you need - the existing BitTornado client does this. I don't know if this would work for debian - it actually might. On Saturday 19 March 2005 06:54 pm, Javier Fernández Garcia wrote: > Hello. > > This thought looks pretty interesting. I wonder if I could trust p2p... > I'll explain myself: > > what would happen if someone changed the source code of a chunk of an > application, I mean, I trust the servers from where I download the > packages, but can I trust any user that offer me a chunk? On Saturday 19 March 2005 06:55 pm, Brett Viren wrote: > One more: > > Nat Tuck <[EMAIL PROTECTED]> writes: > > The biggest issues here are > > A.) unexpected bandwidth usage. > > B.) horrible latency > > C.) granularity > > Please correct me if this is wrong, but must not a torrent pre defined > to be a single file (or set of files)? If so, one would need to > decide at what granularity to build the torrents: one per .deb, one > per category, one per section. > > If the .torrents are fine grained it means leaving many BT clients > open. OTOH, if they are made more inclusive, it means using more > disk/bandwidth than really required. > > -Brett.