Rhetorical question: If they don't trust the project why would they trust binaries through a package manager.
I am sure the authors provide those shell scripts to ease the burden of installation for users so dragging them down into being "dodgy" is really really unfriendly.
> Two long-time developers of the Vuze BitTorrent client, formerly known as Azureus, have launched a new client. BiglyBT emerges at a time when Vuze development has stalled. The developers promise to take the project forward while removing all advertising and other annoyances.
I'd like to know this, too. What sets it apart? I'm especially curious about performance, because both Deluge and qBittorrent chug a little bit on my machine when I have too many torrents listed.
Qbittorrent recently introduced sql based resume file it is advanced option in beta I see an improvement with about 1000 torrent. Though for 1000+ torrents most people recommend rtorrent.
> I don't think there's any way to handle spam/moderation in a fully anonymous decentralised network.
Surely you could have small bayesian engines running in each client, and coordinate ratings through DHT. It would still have the issue of somebody potentially abusing such engine to effectively DDOS certain types of messages (e.g. mentioning a certain party), but you could try and fight that with modern consensus techniques from the cryptocurrency world.
The lack of filter availability doesn't stop spammers bypassing even Google's uber-filters, so it's not much of an argument really. The arm race is what it is. The point is having a system that can react fast enough to remove the spam from most systems once it is identified.
> The point is having a system that can react fast enough to remove the spam from most systems once it is identified.
Then you need a system for distributing filter updates, and preventing the spammers from distributing bogus filter updates. Isn't this basically just the same problem as before?
It is nice to have some competition and so thank you to the developer, but I see no reason to use this compared to qBittorrent, Transmission, aria2, etc.
This one seems to be a lightweight Vuze fork. The differential is that it should have most of the Vuze features, which are not necessarily available for the programs you mentioned. Swarm Merging, for example, seems to be exclusive to Vuze. I've never used it though, so I don't know how appealing that is.
BiglyBT is the new name for Azureus. It’s older than qBittorrent and Transmission. The reason people use it over those alternatives is that those alternatives didn’t even exist when they started using it, and they haven’t offered any features since to make switching worthwhile.
> they haven’t offered any features since to make switching worthwhile.
Ish. The main advantage of newer clients were simplicity and nimbleness: Azureus/Vuze was a bit heavy on memory, at a time when this mattered more than today. After the Vuze renaming, it also went down a dark ad-filled path that did it no favours, to be honest. So a lot of people moved away.
Can I tell it to always "Download in sequential order" and "Download first and last pieces first"? I can set it in qBittorrent, but theres no option to remember for next torrents, forcing me to select those manually everytime. The issue has been brought up but was rejected with reasoning "If everyone would do that, the health of torrents, especially fresh ones, would degrade drastically", completely ignoring that some people usually download torrents where seed/peer ratio is above 100, and it doesnt affect the health of the torrent in the slightest.
The way they work is better for the network, because it asks only for the N next MB from current position to be available ASAP, but the rest can be downloaded randomly to help the network like a standard client would do.
This is excellent implementation. Just today, when I was waiting to download 500 MB zip to extract 16 MB exe I needed I was thinking why all files aren't streamed everywhere.
One feature I really liked in BiglyBT is the ability to download the same file from 2 or more "forked" torrents. For example some pirate groups "pirate" the releases of other pirate groups by just renaming their files, adding some meta info and publishing a new torrent. This causes a split in the seeders and peers as these different torrents form separate torrent swarms, while all are downloading the same file(s). BiglyBT can "merge" these torrent swarms to download the common files from 2 or more torrents.
Wish it wasn't based on Java though - seems so 90's to have to install a framework first (JRE) to run something (and then having to worry about keeping it updated for security).
New BitTorrent 2 protocol supports this nativly if I recall correctly the standard was recently confirmed now trackers and uploaders need to implement it
> Please don't complain about tangential annoyances—things like article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
It's mostly Java, GitHub reports 99.1% of the source is Java, with tiny sprinkles of C++ (0.5%), C (0.2%), Objective-C++ (0.1%) and Objective-C (0.1%).
You're missing the second half of your reasoning here. Why would Java applications be unsuitable for something CPU intensive? It matters more how you build your program than what technology you use, as long as you use the right data structures and algorithms, Java is as suitable for CPU intensive tasks as any other language.
For what it's worth, a BitTorrent client will (usually) be more limited by network and disk I/O than by your CPU, as those tend to be the bottleneck when it comes to transferring large amount of data/large amount of small packets (DHT).
I remember back in Kazaa/LimeWire/WinMX day, Azureus was a powerful beastly BT client. It is a massive beast that took my computer to fully load Azureus in 10 minutes. And that was the only powerful BT client at the time and people hate it because it is powerful but it is CPU intensive. BitComet, BitLord, FlashGet couldn't hold a candle against Azureus. Until qBittorrent, uTorrent and Transmission popped up few years after Azureus initial release. What a time to be alive back then.
I've been using f-droid for a long time. Does the play store advertises when an app has advertisements? Is it possible to search the play store for ad-free apps? Is is possible to search the play store and filter the results by license?
BiglyBT is awesome, it supports Bittorrent v2, stream merging and also includes its own media server so you can stream videos while they are downloading.
The interface is a little slowish but extremely customisable.
It's a real power-users client with every feature imaginable.
74 comments
[ 4.7 ms ] story [ 145 ms ] thread> Requires GTK and java-headless
I don't feel like I should have to be telepathic to understand what commenters are trying to say.
I am sure the authors provide those shell scripts to ease the burden of installation for users so dragging them down into being "dodgy" is really really unfriendly.
I'm forcing it to use between 75 and 125MB and it doesn't complain.
Note: I'm using "nox" variant as a user service and control via a web browser.
* Tag Discovery to discover what other users have tagged content with. This can be very helpful before deciding to download the content.
* Decentralized ratings and comments. You can view them before the torrent is added to BiglyBT.
* Decentralized public and anonymous chats with default channels for individual torrents, tags, subscriptions, and trackers
* Media Playback
* Media Conversion (Transcoding)
* UPnP Media Server and DLNA support, allowing devices to connect and browse your content, and allowing BiglyBT to send content directly to devices.
https://www.biglybt.com/features.php
Such a scheme seems open to spam by design. I don't think there's any way to handle spam/moderation in a fully anonymous decentralised network.
Surely you could have small bayesian engines running in each client, and coordinate ratings through DHT. It would still have the issue of somebody potentially abusing such engine to effectively DDOS certain types of messages (e.g. mentioning a certain party), but you could try and fight that with modern consensus techniques from the cryptocurrency world.
If each client has a copy of the filter, then so does the spammer. The spammer can use that to craft spam the filter doesn't catch.
Then you need a system for distributing filter updates, and preventing the spammers from distributing bogus filter updates. Isn't this basically just the same problem as before?
BiglyBT, Torrent-Downloader (ad free, open source torrenting for phones, tablets, Chromebooks & Android TV) - https://f-droid.org/packages/com.biglybt.android.client
Ish. The main advantage of newer clients were simplicity and nimbleness: Azureus/Vuze was a bit heavy on memory, at a time when this mattered more than today. After the Vuze renaming, it also went down a dark ad-filled path that did it no favours, to be honest. So a lot of people moved away.
https://github.com/proninyaroslav/libretorrent
It frustrates me how indifferent some authors are to the user, though I guess I can't complain too much for a free product. I usually just fork them.
For instance on Android, NOVA Video Player supports torrent streaming. Or btplay from https://github.com/johang/btfs .
The way they work is better for the network, because it asks only for the N next MB from current position to be available ASAP, but the rest can be downloaded randomly to help the network like a standard client would do.
https://github.com/webtorrent/webtorrent/issues/1654#issueco...
Wish it wasn't based on Java though - seems so 90's to have to install a framework first (JRE) to run something (and then having to worry about keeping it updated for security).
https://news.ycombinator.com/newsguidelines.html
For what it's worth, a BitTorrent client will (usually) be more limited by network and disk I/O than by your CPU, as those tend to be the bottleneck when it comes to transferring large amount of data/large amount of small packets (DHT).
This was quite handy for a big torrent of music videos back in the day with not enough seeders.
It's fast, and has all the features needed
* webclient with separation of LAN/WAN password requirements
* interface kill switch
* handle hundreds of torrents (more than that I would go for rtorrent)
* Updated often
* built in search plugins.
* not bloated
* primarily written in c++
The interface is a little slowish but extremely customisable.
It's a real power-users client with every feature imaginable.