Also, it wasn't rewritten in Rust from some other language, it was written in Rust in the first place.
No, it's just a box dedicated to "seeding", a server whose purpose is bittorrent.
https://en.wikipedia.org/wiki/History_of_the_Opera_web_brows...
Looks like since version 9, released in 2006.
I suspect that in modern "we don't download anything, we watch/read/run this on the web" times in-browser downloading is bound to be second-class citizen that vendors would not pay any significant attention to beyond the simplest scenarios. Basically, the torrent support will be barely functional, just like the current HTTP downloads are. If they're split in a separate program (buzzword: microservice) they still have a chance, though.
An advantage of Rust however is that it's easy to expose a C api from it, so it can easily be integrated into a project done in a more comfortable language.
Don't forget to seed!
After that failed he designed BitTorrent to actually align the incentives of users, without any of the currency bullshit getting in the way
If it could offer a transmission-compatible API-layer, I bet it would receive much more interest.
Edit: apparently not written in python. My bad.
(Also, what great irony this proxy is written in python, eh?)
It's written by a different person (me). Also Transmission is written in C FYI
How is the memory usage of this one?
It says it is light-weight. What kind of light-weight is it and are there some metrics?
As far as memory usage goes, I don't think low-memory devices have been a use-case Luminarys has had in mind yet, but he's probably on board with tuning with that in mind. On my client right now I have 45 torrents, 3 seeding, and one is that huge one I mentioned before - and synapse is using 1.2G of RAM, and 41G of virtual memory.
I run Transmission (from the Debian repo) on it and never even thought about memory usage before now, it just works. Admittedly I don't really let a bunch of torrents run at once though.
https://github.com/Luminarys/synapse/issues/80
I should note that I'm stress testing it, however, I have some particularly large torrents going.
Most of these SBC's run ethernet over USB, so the performance is still going to be shit.
Anyone using a common English word shouldn't expect to own it exclusively, especially if it's a word that has something to do with computation.
Hopefully this will be better - please have a sane remote API.
One thing that Azeurus did really well, that transmission really did not -
You could can tell azeurus to re-check all the files that are there so it can find out how far it's got.
In Azeurus I used this to reconstruct a large torrent by adding files that I found, then telling it to re-check.
Transmission couldn't even tell if the files the torrent pointed at had been deleted from under it.
https://github.com/Luminarys/synapse/blob/master/doc/RPC
Pretty much all torrent clients can recheck the files.
Saying what language a program uses only describes its grammar and runtime. Saying what dialect a program uses also describes its idioms.
https://en.wikipedia.org/wiki/Programming_idiom
For (a simple) example, actix-web uses actix, a library that largely changes the nature of writing Rust code. This might be called Rust-a or Rust', or something.
https://github.com/actix/actix-web
My point is that Rust is a really cool language where "the(/some) (sub)community(ies)" are developing and coalescing around great libraries outside of core std, making a very* robust language, or rather robust language dialect.
My point wasn't so much about any one program, so much as it was about an invisible programming ethnology. I like when Show HNs say what language they speak; I would like even more if they say how they speak it.
Having name for program dialects would allow prospective users and contributors to gain deep insight about its intended structure, vision, scope, limits, etc, etc, etc, etc from a distance.
It may have seemed narrow focused, but I didn't want my point to be limited to one set of principles, patterns, and libraries, even though I like what actix adds to Rust-std(?), especially since any code spoken in it can itself make, or through some elements factored out be made into, other libraries that then build on or toward another powerful dialect / speaker communities.
#hashtag: ethnocodology(?) ..ethnokodikology?
