Aaah ... We could certainly argue during hours about the best
technology to use to distribute jamendo's archives (50Mb files) ...
(and we do internally at jamendo ;) )
The main reason we promote both eMule/eDonkey and BitTorrent, is
popularity, demand ... Music lovers, teens and artists use the jamendo
service because they don't have to install another software, they
already have eMule, uTorrent, or azureus, no need to install another
eMule in Europe is by far the most popular P2P tool. And BitTorrent
traffic is supposed to be half of the P2P two third of world's traffic
So despite BitTorrent is best suited for big popular files, we propose
this option. Half of our download are BT, the other eMule/eDonkey.
We would like to add Gnutella support, but this require another set of
disks and server, and frankly, we do not receive that much demand for
Concerning seeding some jamendo ogg archives on some fedora servers
that would be very cool ! It's pretty simple to do we've developped a
jamseeder. Basically, it's a python bittorrent client. You assign it
an upload bandwidth, a disk space limit, and it does the job, asking
(xmlrpc) our servers which files needs more seeding.
The sources are here :
The documentation is minimalist, read config.py :(
if you want to look further hosting of eMule/eDonkey/KAD traffic, we
do that using aMule, don't know if it's in the extras of fedora.
don't know about quack, i'll have a look to it ...
On 8/18/06, Aaron Sherman <ajs(a)ajs.com> wrote:
On Fri, 2006-08-18 at 11:27 -0400, Greg DeKoenigsberg wrote:
> OK, looks like the list is quiet-ish, so let me say what I think. :)
> Issue #1, and what I think is most important for Fedora users: the number
> of torrent seeds available for Ogg users is quite low. I'd like to
> propose two mechanisms for dealing with this, in the fairly near future:
BT is actually the worst case scenario for large, low-interest files
(but it's perfect for large, high-interest files).
By way of comparison, a certain production house leaked a copy of the
pilot for a TV show because it had been canceled and they wanted to try
to drum up some grass-roots support. It didn't work, and the show never
saw the air.
A year later, I tried to pull down the torrent. After a day of waiting
for the download, I fired up gtk-gnutella. The search took an hour to
find the file, and the download finished before the torrent by about 12
hours. The torrent was mostly idle, waiting for a client who had the
missing bits of the file.
This has been my fairly repeatable result with old operating system
versions, strange platform ISOs, folk music that's been released, and so
My theory as to why is that bittorrent has a small chunk size and
randomizes access. Gnutella has a larger chunk size and while it
randomizes the first chunk from each available swarm source, it then
continues linearly through the file as long as the next chunk is not
already downloaded or being fetched from elsewhere; it then applies a
heuristic that I haven't fully looked into (and may be client-specific),
but the net result is that I almost never find a file on a Gnutella
network for which less than 100% of the original file is available.
> a. Offer some Fedora infrastucture to help seed Ogg files. I can put this
> question in front of the board. Strategic investment in a couple of
> servers could boost the availability of Ogg files significantly.
If you do so, it doesn't hurt to provide the same service for gnutella.
There's a server-only called quack out there that serves roughly the
same purpose as a tracker.
It's not in extras right now, but it could be with minimal effort.