There are many clients that have many features and can speak different protocols but I haven't seen a good UI yet. Most of the clients have a window for each user they are talking too and the text is presented awkwardly and you know all those bells and whistles. Changing skins. Mmmmm. couldn't care less. I like to chat in irssi. Clean interface that should be enough for ICQ as well. I currently use irssiq.pl which tries to integrate ICQ into irssi, and although it works it could be better. Does anyone know of a good ICQ/AIM/Whatever messaging client? Or are there any good IRCICQ gateway out there?
I suggest people who use Debian do it the Debian way.
apt-get install kernel-package
This will install make-kpkg which compiles the kernel into a debian package. Go to the source directory, configure it with make menuconfig or something of your choice. Then:
Bram said:My attempts to promote BitTorrent for any specific purpose basically failed.
Yeah, not even the porn crowd were interested. This is like VHS all over. Probably something crappy will take over and completely crush the much better BitTorrent.:)
Actually, it is the rate you are uploading that counts. A peer have a list of other peers. This peer list is sorted by how fast they serve you. You upload to the top three on this list. That's basically it.
But that doesn't mean your download rate is limited to your own upload rate. In simple statistics. Your download rate is the average of all the total current upstream divided by the number of people downloading. But of course nothing is average. It's above and it's below.:)
A great site to see just how popular BitTorrent has become is bstark's topten list. It doesn't list all trackers out there, most notibably the one that had the redhat 9 torrent, so the top list isn't all that accurate, but it is fun to see how popular some files are.
Re:short term - new clients are too configurable
on
BitTorrent Guide
·
· Score: 2, Insightful
The official client let's you tweak everything as well. There are command line parameters for everything that you can see in the experimental clients. Those clients just built a GUI on top of already existing functionality.
If there are no completes there still is a possibility your download will finish. If there are 2 users downloading, both can have 60% of the file, but different parts, so the whole file set is out and eventually someone will complete. If there is only 1 person that is complete and it downloads at 100KB/s for 100 seconds and the disconnects and the file is 100*100KB big, then in theory, the whole file is out there, even though nobody has it complete yet, because BitTorrent uses an algorithm called rarest first. It will try to pick the rarest pieces in the torrent. This will make it much more likely that the file is available even though the only one with the complete file disconnects.
You _can_ run BitTorrent on Redhat 7.x as well as you _can_ run BitTorrent on Debian without using packages from testing.
There is no bittorrent deb for debian stable though, so you have to unpack the source archive and run/install manually. That's very easy. Not sure how hard it is to install python 2 for redhat 7.x but it is definately possible.
This is a combined UI miss and a workaround for mozilla I think. A helper application in mozilla only takes one argument. So when btdownloadheadless.py btdownloadgui.py just have one argument that is a file. Otherwise, you have to say
btdownloadheadless.py --responsefile file.torrent
run btdownloadheadless.py without any arguments to see all the options.
You are true. The MD5 on the knoppix mirrors does not match with the iso mirrored with bittorrent. This is bad. BitTorrent has internal checking though, so nothing went wrong when you downloaded it. The copy distributed was corrupt.
The md5sums for the redhat isos match though.
I think your first paragraph is wrong and I think I have a very good understanding of how bittorrent works. If you check the amount of time it takes for 1000 persons to finish the download from the moment the torrent was created, it will go much quicker if you just release it at once, then do this internal seeding for a while first and then release it. It didn't take long for my download speed to come to 300KB/s and then later 600KB/s which I had until it finished.
The reason that you are suggestion the initial seeders is probably because many use an extreme assymetrical connection (they can download ten times as fast as they upload) and the average download speed of the torrent will be the average upload speed of all users (which the average guy on an average assymetrical connection will think is too slow). If you let the people with fast upstream get the torrent first, they can get it a little bit faster if they all have equally good bandwidth (which never happens), but only if you do extremely well coordinated (which never happens). It's just a few minutes anyway and this torrent is hopefully going to live for over a week.
There is a gui tool for making your own torrents, but you still need to use CLI for running a tracker.
I will try to describe as good as I can. BitTorrent uses a technique called tit-for-tat (or choking algorithm) as a dynamic download/upload ratio. The faster you upload, the faster you will can download.
Each peer has a list of other peer it's connected to. As of this moment, over 800 people are downloading redhat 9, but every single peer is connected to about 50 other peers. In the normal case, a peer has 4 upload slots, so it uploads to 4 other peers at any single time. But it downloads from as many peers as possible. It tries to give those 4 upload slots to the peers that currently is giving the fastest download speed. Since new peers can arrive which give even better download speed it has one optimistic upload slot which change peer every now and then to try out new peers.
When a download is complete, the 4 upload slot just try to give to the people who can download the fastest.
Here is a bittorrent link, even though I found the mirrors to be quite fast for knoppix. I'll look forward to tomorrow when redhat 9 is released with bittorrent. That will be fun.
The P2P program BitTorrent has survived slashdots before, this one should be no match:)
Someone should setup a tracker, and make a torrent of the files. I will, if no one beats me to it, which I rather hope. Downloading from slow mirrors at 5KB/s here.
That was BitTorrent, and although I am a big fan of it myself, it will suck at streaming audio, because you will most likely _not_ download the first part of the file first, which is really nice for that chronology correct streaming effect.
Not really. Their new approach is to sell music and we all know how well that goes, so perhaps they will die soon.
3. "Morpheus 2.0, BearShare and LimeWire were all huge resource hogs"
Morpheus 2.0 hasn't even been released yet (although the release date was the beginning of April), so I can't really defend it and I am not even sure if I want to. If you are refering to the current preview edition of Morpheus, I can agree, because it is basically an old version of Gnucleus with banners and bigger buttons.
Morpheus 2.0 will use Rebol IOS (in the same way they used the Fasttrack technology in previous versions) and I even sent a mail to Rebol, to confirm this, and got a reply:
Date: Thu, 14 Mar 2002 15:21:22 -0800 From: Carl Sassenrath To: Jon Åslund Subject: Re: Morpheus 2.0
Yes... preview edition was just something they did in order to deal with the Kazaa problem. It's not 2.0.
Yes, we think so too.
-Carl
At 3/14/02 10:35 PM +0100, you wrote:
>According to this press release: > > http://www.rebol.com/news1a31.html > >Morpheus will base it's next version (2.0) on REBOL IOS. I was very >surprised to see the morpheus preview edition to be based on >gnucleus. Are you still working with Morpheus on this? It would be >great to see REBOL out on the Internet on a big scale, which clearly >will happen if Morpheus is to build their new version on REBOL IOS. > >-- >___\ Jon Åslund
Although I haven't tested Rebol IOS, Rebol itself is not a resource hog, and it is available for a large number of platforms. I am not sure if it will ever be as popular as the old Fasttrack network was with Kazaa and the old Morpheus, but I am looking forward to the new version. They have a clear policy against spyware, the client may work with other operating systems than Windows (at least the Rebol technology allows it), and oh, did I mention they are going to use Rebol?:)
Great idea. Google caches every page it finds, slashdot doesn't even cache the few linked pages of the articles it has. I don't read slashdot very often, or at all actually, but from the reactions on this page and from some e-mail I have received, this seems the happen a lot.
We didn't expect the slashdot effect (well, not so soon anyway;-), and our WikiWiki certainly didn't, so the web server died.
So, we set up some temporary, but not complete mirrors. The source, documentation and examples are here, but it lacks the lively and lovely Wiki discussion.
Slashdot Mirror
There are many clients that have many features and can speak different protocols but I haven't seen a good UI yet. Most of the clients have a window for each user they are talking too and the text is presented awkwardly and you know all those bells and whistles. Changing skins. Mmmmm. couldn't care less. I like to chat in irssi. Clean interface that should be enough for ICQ as well. I currently use irssiq.pl which tries to integrate ICQ into irssi, and although it works it could be better. Does anyone know of a good ICQ/AIM/Whatever messaging client? Or are there any good IRCICQ gateway out there?
I suggest people who use Debian do it the Debian way.
apt-get install kernel-package
This will install make-kpkg which compiles the kernel into a debian package. Go to the source directory, configure it with make menuconfig or something of your choice. Then:
make-kpkg --revision custom1 kernel_image
then after it is finished:
dpkg -i kernel-image-2.4.21_custom1_i386.deb
Thanks, very fast. Much more people on this one than the gametab torrent.
But that doesn't mean your download rate is limited to your own upload rate. In simple statistics. Your download rate is the average of all the total current upstream divided by the number of people downloading. But of course nothing is average. It's above and it's below. :)
A great site to see just how popular BitTorrent has become is bstark's topten list. It doesn't list all trackers out there, most notibably the one that had the redhat 9 torrent, so the top list isn't all that accurate, but it is fun to see how popular some files are.
The official client let's you tweak everything as well. There are command line parameters for everything that you can see in the experimental clients. Those clients just built a GUI on top of already existing functionality.
If there are no completes there still is a possibility your download will finish. If there are 2 users downloading, both can have 60% of the file, but different parts, so the whole file set is out and eventually someone will complete. If there is only 1 person that is complete and it downloads at 100KB/s for 100 seconds and the disconnects and the file is 100*100KB big, then in theory, the whole file is out there, even though nobody has it complete yet, because BitTorrent uses an algorithm called rarest first. It will try to pick the rarest pieces in the torrent. This will make it much more likely that the file is available even though the only one with the complete file disconnects.
You _can_ run BitTorrent on Redhat 7.x as well as you _can_ run BitTorrent on Debian without using packages from testing.
There is no bittorrent deb for debian stable though, so you have to unpack the source archive and run/install manually. That's very easy. Not sure how hard it is to install python 2 for redhat 7.x but it is definately possible.
I have downloaded them all and they all passed md5 check.
Are you sure that you _downloaded_ them and that it wasn't just the file allocation phase that was finished?
This is a combined UI miss and a workaround for mozilla I think. A helper application in mozilla only takes one argument. So when btdownloadheadless.py btdownloadgui.py just have one argument that is a file. Otherwise, you have to say
btdownloadheadless.py --responsefile file.torrent
run btdownloadheadless.py without any arguments to see all the options.
You are true. The MD5 on the knoppix mirrors does not match with the iso mirrored with bittorrent. This is bad. BitTorrent has internal checking though, so nothing went wrong when you downloaded it. The copy distributed was corrupt. The md5sums for the redhat isos match though.
I think freenet can do that pretty well. All we need is a freenet:// in our browsers :)
I think your first paragraph is wrong and I think I have a very good understanding of how bittorrent works. If you check the amount of time it takes for 1000 persons to finish the download from the moment the torrent was created, it will go much quicker if you just release it at once, then do this internal seeding for a while first and then release it. It didn't take long for my download speed to come to 300KB/s and then later 600KB/s which I had until it finished.
The reason that you are suggestion the initial seeders is probably because many use an extreme assymetrical connection (they can download ten times as fast as they upload) and the average download speed of the torrent will be the average upload speed of all users (which the average guy on an average assymetrical connection will think is too slow). If you let the people with fast upstream get the torrent first, they can get it a little bit faster if they all have equally good bandwidth (which never happens), but only if you do extremely well coordinated (which never happens). It's just a few minutes anyway and this torrent is hopefully going to live for over a week.
There is a gui tool for making your own torrents, but you still need to use CLI for running a tracker.
md5sums are included in the torrent and they correspond with the one on the ftp server
I will try to describe as good as I can. BitTorrent uses a technique called tit-for-tat (or choking algorithm) as a dynamic download/upload ratio. The faster you upload, the faster you will can download.
Each peer has a list of other peer it's connected to. As of this moment, over 800 people are downloading redhat 9, but every single peer is connected to about 50 other peers. In the normal case, a peer has 4 upload slots, so it uploads to 4 other peers at any single time. But it downloads from as many peers as possible. It tries to give those 4 upload slots to the peers that currently is giving the fastest download speed. Since new peers can arrive which give even better download speed it has one optimistic upload slot which change peer every now and then to try out new peers.
When a download is complete, the 4 upload slot just try to give to the people who can download the fastest.
More about the protocol
Here is a bittorrent link, even though I found the mirrors to be quite fast for knoppix. I'll look forward to tomorrow when redhat 9 is released with bittorrent. That will be fun.
Download Bittorrent
Download Knoppix 3.2
The P2P program BitTorrent has survived slashdots before, this one should be no match :)
Someone should setup a tracker, and make a torrent of the files. I will, if no one beats me to it, which I rather hope. Downloading from slow mirrors at 5KB/s here.
A 3d embeddable Gecko control, anyone? :) (Wish that code was cleaner...)
You mean like something taken out of a David Cronenberg film?
That was BitTorrent, and although I am a big fan of it myself, it will suck at streaming audio, because you will most likely _not_ download the first part of the file first, which is really nice for that chronology correct streaming effect.
For those of you who really don't want to read through the license, here it is in haiku form:
Macromedia: Just like IBM / but this baby has our name / Macromedia Inc
and of course IBM's
IBM: You really wish that/ Our licenses would fit in/ merely three short lines.
More:
http://www.aaronsw.com/weblog/000360
http://www.quicktopic.com/boing/H/xk9pNnpwmwRdU
I must comment on point 1 and 3.
1. "Morpheus is dead"
Not really. Their new approach is to sell music and we all know how well that goes, so perhaps they will die soon.
3. "Morpheus 2.0, BearShare and LimeWire were all huge resource hogs"
Morpheus 2.0 hasn't even been released yet (although the release date was the beginning of April), so I can't really defend it and I am not even sure if I want to. If you are refering to the current preview edition of Morpheus, I can agree, because it is basically an old version of Gnucleus with banners and bigger buttons.
Morpheus 2.0 will use Rebol IOS (in the same way they used the Fasttrack technology in previous versions) and I even sent a mail to Rebol, to confirm this, and got a reply:
Although I haven't tested Rebol IOS, Rebol itself is not a resource hog, and it is available for a large number of platforms. I am not sure if it will ever be as popular as the old Fasttrack network was with Kazaa and the old Morpheus, but I am looking forward to the new version. They have a clear policy against spyware, the client may work with other operating systems than Windows (at least the Rebol technology allows it), and oh, did I mention they are going to use Rebol? :)
> (Another reason /. should cache...)
Great idea. Google caches every page it finds, slashdot doesn't even cache the few linked pages of the articles it has. I don't read slashdot very often, or at all actually, but from the reactions on this page and from some e-mail I have received, this seems the happen a lot.
--
Jon Åslund
We didn't expect the slashdot effect (well, not so soon anyway ;-), and our WikiWiki certainly didn't, so the web server died.
So, we set up some temporary, but not complete mirrors. The source, documentation and examples are here, but it lacks the lively and lovely Wiki discussion.
http://spl.pu240.com
http://cgi.student.nada.kth.se/~d98-jas/shakespear e/
--Jon Åslund (one of the authors)