LWN.net Logo

Advertisement

E-Commerce & credit card processing - the Open Source way!

Advertise here

Why not torrent

Why not torrent

Posted Jul 15, 2008 11:56 UTC (Tue) by job (subscriber, #670)
In reply to: How to fix it by epa
Parent article: Study: Attacks on package managers

I can think of a few reasons. Bittorrent is more complex (which would make the install program
larger, and might not fit on a netboot ram image). It is slower. (If it's faster for you,
switch mirror.) It uses uplink capacity for the end users (which some may have to pay for).
Distribution of torrent metadata is a single point of failure.

So in short, it's not robust, it's slow, and it's complicated.

You make it sound like more modern equals better, which should be obvious it is not true.
Otherwise we would not use a web browser when we have 3D games. Different uses, different
protocols.


(Log in to post comments)

Why not torrent

Posted Jul 16, 2008 14:43 UTC (Wed) by epa (subscriber, #39769) [Link]

I think you answered your own argument: "If it's faster for you, switch mirror."

The point is that users should not have to care about switching mirrors, and (with somewhat
less importance) administrators should not have to care about setting up mirrors and fixing
the various things that can go wrong with them.  Bittorrent is a more complex protocol, but it
is often simpler to use and maintain.  Let the computer do the hard work of figuring out which
site is the nearest and which site has which data.

(I have two Fedora machines on my local network; I could spend disk space and bandwidth
setting up a full mirror but it would be a hassle and download more than I need.  An
alternative is to set up a caching http proxy - but if Bittorrent were used, the machines
would just share the downloaded data automatically.)

It need not necessarily use uplink capacity for the end users.  A leeching Bittorrent client
would be fine for downloading package updates.  I proposed setting up Bittorrent servers
instead of traditional mirror sites - such a server would be a regular Bittorrent node
configured to participate in the package torrents.  Since the server is just there to provide
speeded-up downloads to the users, it can run in generous mode where it will happily provide
data to leeching clients.

Distribution of torrent metadata is indeed a single point of failure.  But so is distributing
a list of mirror sites.  Whatever update method you use, you must start with a single point
somewhere.

Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds