There it is in its “enhanced” rendition, which apparently includes some improvements over the last release.
What is obviously different here is that ctorrent spills everything to the console, uses nested menus to manage its performance and apparently only handles a single torrent at a time.
It can fork to the background and become a daemon like bitflu … but there’s no way to reconnect to it, according to the user’s page.
No telnet interface, no web GUI. Not much in the way of an interface. Not quite same as bitflu, not quite like rtorrent.
So why use it? Well, from my perspective, it has a few strong points.
First, it’s written in C++, and in my experience applications like that tend to be very light and fast. cmus is another good example of that principle.
So on very low-end hardware, it might be preferable to have something as quick and deft as ctorrent, over something (relatively) bulky like rtorrent.
And just because it only handles one torrent at a time doesn’t mean you can’t set it up to watch a folder and download whatever it finds. It might take a little work, but it’s conceivable.
So imagine, if you will, something in the 100 to 150Mhz range sitting in a corner, managing your torrent downloads and perhaps playing music.
Stick with stuff like ctorrent (and cmus), and that’s a possibility.