Hacker News Reader

Comment by j-bos | Hacker News Reader

Why aren't packages based on torrents? Most distros come with a torrent client.

Torrents tank when there is lack of popularity. Linux can be configured for a wide variety of purposes, from IoT driver to gaming workstation, so not all packages are equally popular with all people, and just because a package is unpopular doesn't mean it isn't important. If I'm the one person in the world running a service that everyone else relies on, then the packages which support that service are important even if no one else uses them.

Therefore to use torrents requires one of two choices, neither of which are really viable when you think about it. Either:

* Require everyone who uses the distribution to torrent releases of the full set of packages for the distribution. (And remember that packages regularly get updated even in LTS releases, due to backporting security fixes etc.) It means everyone using the distro really needs to be running dozens or hundreds of torrents.

* Everyone torrents only the packages they need, so access to packages becomes up to popular vote instead of actual importance.

Torrents are fine for isos but intractible for ongoing package management.

Right, it wouldn't eliminate the need for mirrors (or seeds in the torenting case). But it would greatly reduce the bandwidth needed for those mirrors.

It shouldn't be any worse than hosting old versions of packages on an HTTP file server.

A couple thoughts:

* You can mitigate the popularity thing by using webseeds; if it's popular then it's p2p, and if not then it just falls back to HTTP

* Alternatively, you can 80/20 it; only torrent the 10 biggest and 10 most popular packages (changing 10 to taste), which is a relatively small number of torrents to run while minimizing load on mirrors

If every torrent includes a webseed, then you're still left with the problem of needing to build a full HTTP CDN, and now have to also maintain the largest tracker infrastructure ever deployed for Bittorrent.

Under normal conditions with well behaved clients, raw bandwidth for the large packages is essentially never the issue. Misbehaving clients, cache thrashing, IOPS are the sort of issues that cause pain for mirrors.

Does torrent have addition overhead that regular hosting does not ?

Some ISPs try to block traffic that looks torrent like.

I would love my package manager to support a simple fetch helper protocol to plug-in distributed caches from torrents (with webseeds), to mDNS, heck just a Redis service tracking which systems should have which packages cached per site, to something not much more complex than an old fashioned HTTP caching proxy.

Well if you use apt you might be in luck. There's a bunch of apt transports. I don't know the maturity of them but you can google apt-transport-debtorrent, apt-transport-s3, and one for ipfs.

https://github.com/JaquerEspeis/apt-transport-ipfs

Torrents don't handle frequent updates very well. You'd have tons of outdated torrent floating around. They work well for archives and installation media though that doesn't change that often.

Honestly, default behavior should be to at least share package files on the local network. But sharing to the wider internet should be fairly trivial in <current year>, we have no shortage of technologies that accomplish this.

I wish more systems had this kind of feature. I have a fat fiber connection, I'd be thrilled to pop up an unofficial mirror for something like a Linux distro. I've tried mirroring Linux ISO torrents, but it seems almost nobody ever downloads from a torrent, so I end up never actually uploading any of these images.

Reply on news.ycombinator.com