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.
Seedboxes are mostly used on private torrent trackers, simply because the majority require users to maintain a high seed/leech ratio. In other words, users need to upload more than they download.
Or maybe not.
I'd be interested in hearing more about this, if you have the time. Rust is certainly incomplete, but I wonder if our perspectives line up here or not regarding how exactly it's not complete.
Specific pain points for me were:
- the lack of traits for numeric primitives/types without pulling in the num crate
- the difficulty working with floating point types
- the inconsistent type annotations in fn signatures
- the type annotations are a bit clunky no easy way to alias
- and auto deref mechanics especially via match statement
- having to fully specify a type in a match statement or use Self::Type
- the use mechanism makes no sense
- no optional/default arguments without macros leads to a lot of shimming/boilerplate
- having to split operations because the borrow checker can't do partials or non lexical lifetimes
- the clunky range syntax wich makes writing invertible/reversible functions really ugly and error prone due to lack of inclusive range and I really can't believe the committee decided to go ahead with ..= instead of ... It's really out of line compared to pretty much every other language is doing
- doesn't seem like there's a good way to nicely format long lines
Overall I still really like the language but I really don't see it taking off until these issues are fixed because it makes it so hard to start up.
It works fine for me even though my browser is configured to block third party traffic by default.
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.
Well, they used to be, but now they aren't anymore, so you'll probably want to start somewhere around there. In the early days of resumable HTTP downloads and simpler browsers, there were lots of download managers.
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
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.
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
The clients that use Python today are not slow because they all use rasterbar-libtorrent as a C Python module that performs all of the heavy lifting.
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.
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.
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.
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.
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?