Also, it wasn't rewritten in Rust from some other language, it was written in Rust in the first place.
https://en.wikipedia.org/wiki/History_of_the_Opera_web_brows...
Looks like since version 9, released in 2006.
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!
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?)
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.
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?
