You are not logged in.
just add this.
[truthe]
Server = http://reikop.farvista.net/truthe/
packages were taken from http://starcrow.starzinger.net/~vidvandre/arch/
but i dislike having to check the site periodically for updates which i'm sure some people will sympathize with, so i put together this repository.
in my opinion, the fastest, most efficient bittorrent client made.
Offline
The server seems to be down. Bummer, I was looking forward to getting my rtorrent on.
I always roll 20s on my disbelieve checks.
You better believe it.
Offline
is this a new stable version?
anyway its best to wait for aur to be updated
btw this is the AUR package request section..
There shouldn't be any reason to learn more editor types than emacs or vi -- mg (1)
[You learn that sarcasm does not often work well in international forums. That is why we avoid it. -- ewaller (arch linux forum moderator)
Offline
rtorrent is in [community], and has been for a while
we're on version 0.6.4 for rtorrent and 0.10.4 for libtorrent
Offline
rtorrent is in [community], and has been for a while
we're on version 0.6.4 for rtorrent and 0.10.4 for libtorrent
Awesome. Newer versions would be nice, but just getting it installed is marvelous.
I always roll 20s on my disbelieve checks.
You better believe it.
Offline
Uh, it's the most recent release. If you can find a newer one let me know.
Offline
yeah someone flagged it out of date but its still latest
There shouldn't be any reason to learn more editor types than emacs or vi -- mg (1)
[You learn that sarcasm does not often work well in international forums. That is why we avoid it. -- ewaller (arch linux forum moderator)
Offline
Uh, it's the most recent release. If you can find a newer one let me know.
Woops, my bad, you're right. This is awesome.
I always roll 20s on my disbelieve checks.
You better believe it.
Offline
its still marked as unstable. that doesnt count.
btw this issue with rtorrent & 2.6.19 kernel is very serious at least more serious than i ever suspected. it used to be only a few kbs found as bad. i just downloaded a 42mb torrent out of which 16mb (36%) was found bad. hope it gets fixed soon..
There shouldn't be any reason to learn more editor types than emacs or vi -- mg (1)
[You learn that sarcasm does not often work well in international forums. That is why we avoid it. -- ewaller (arch linux forum moderator)
Offline
its still marked as unstable. that doesnt count.
btw this issue with rtorrent & 2.6.19 kernel is very serious at least more serious than i ever suspected. it used to be only a few kbs found as bad. i just downloaded a 42mb torrent out of which 16mb (36%) was found bad. hope it gets fixed soon..
Mounting ext3 partitions with data=writeback seems to work for me. It is also said to be the fastest data option
Offline
This business with "bad chunks found on download completion blah blah" is a reported bug, right? It's not something wrong with my system?
I always roll 20s on my disbelieve checks.
You better believe it.
Offline
its a known issue
Failed chunks with kernel 2.6.19 ¶
Linux version 2.6.19 appears to have a bug in the synching of mmapped files, leading to large numbers of failed chunks when downloading a torrent. Using rTorrent with kernel 2.6.19 is not recommended, but if an earlier kernel version is not an option, make sure to enable the "check_hash" option and manually restart torrents until all chunks pass the hash check.
thx for the tip Leffe i'll try it
There shouldn't be any reason to learn more editor types than emacs or vi -- mg (1)
[You learn that sarcasm does not often work well in international forums. That is why we avoid it. -- ewaller (arch linux forum moderator)
Offline
So this isn't going to be fixed by upgrading rtorrent, but by getting a newer kernel? Damn.
I always roll 20s on my disbelieve checks.
You better believe it.
Offline
So this isn't going to be fixed by upgrading rtorrent, but by getting a newer kernel? Damn.
Yes, and it happens on all filesystems, not just ext3.
Only ext3 with data=writeback is not affected.
to live is to die
Offline
and data=writeback == fraggy filesystem! hurrah!
Offline
and data=writeback == fraggy filesystem! hurrah!
yeah, the safest way is ext3 with data=journal (of course starting from 2.6.20 when that corruption bug is fixed) - the only filesystem that does metadata and data journaling.
Though it seems obviously slower, but there are reports from kernel devs (IIRC, Andrew Morton too) that it is faster than data=ordered in some cases (mail spools etc).
Anyway the safest way is ext3 on RAID5 with data=journal and with journal on separate RAID0+1 8)
to live is to die
Offline
kamagurka wrote:So this isn't going to be fixed by upgrading rtorrent, but by getting a newer kernel? Damn.
Yes, and it happens on all filesystems, not just ext3.
Only ext3 with data=writeback is not affected.
It still happens, just not as often and as much.
Offline
Romashka wrote:Only ext3 with data=writeback is not affected.
It still happens, just not as often and as much.
Ah, yes, you are right. Thanks for correction.
to live is to die
Offline