yeah, thinking about it, probably the naming of those isn't the best, will make sure to change them and use doc comments

tho, I will probably keep the 2 Hz consts (while adding a _HZ in both their names) as they make it easier to understand imo [changed my mind: I guess it is easier if it is just the intervals]

thank u both for actually caring :)

Side-note: You don't have to denote the unit for Duration. You construct it from milliseconds, but then it's unitless and you decide where you use it in what unit you want the value. So, Duration is very cool and I would recommend using it for LRC_START_THRESHOLD as well.

Expanding on this further, but the best kind of documentation for what a value represents is its type. Since all of these are duration-related, I would even go as far as using only Duration types for these. The values in Hz (aka n/sec) can be inversed to turn them into Durations (which happens below them to create REFRESH_DURATION and METADATA_REFRESH_DURATION which, despite their names, are actually intervals from what I can tell).

Small nitpick that I noticed while skimming the code:

Where you define your constants, you can change those comments to be doc-comments instead, so that your editor can display them when you hover over constants.

And personally, I would go one step further with the units, by putting them at the end of the name of the constant, like you did with some variables in the code. That way, the unit shows up inline while reading code that uses the constant, which makes it easy to see that units match up (or not).

Side-note: You don't have to denote the unit for Duration. You construct it from milliseconds, but then it's unitless and you decide where you use it in what unit you want the value. So, Duration is very cool and I would recommend using it for LRC_START_THRESHOLD as well.

But yeah, back to the comments-thing: Plain comments are kind of inherently crappy, because they only show up in one place in the code, so you're less likely to see them and less likely to update them. By putting things into doc-comments, names, log statements, error messages etc., they show up in at least two places.
Plain comments only really make sense for explaining why the code does something. The what can generally be explained in other ways, at least in a sufficiently abstracted language like Rust.

Because most images from Chainguard are paid, apart from the base image, the way I use it is through multi-stage builds, where I simply copy what I need from other images into the wolfi base, unless of course it's just easier to install what I want using apk. If I could do that with plain Alpine, I would, but most stuff is compiled for glibc, so it's a no-go.

If security is the main factor for your, I'd recommend you scan the image with grype, so you can get a grasp of how many CVEs you're working with.

Those are great points! Thank you.

Hmm there are plenty of tools to do that without containers… though I do see your point that docker provides a unified way of doing that which is easier.

You're looking at it from the perspective of having coded a single application and wanting to deploy it. Try to think more like a sysadmin:

• You've got a whole bunch of applications to deploy. Some of them may use dynamic linking, too.
• You don't know any of them too intimately, so want to just prevent them from interfering with each other, unless you allow it.
• You want a uniform tool to manage all these different applications, and especially also when they're allowed to interact.

The result is deployment orchestration tools like Kubernetes, Docker Compose, Podman Compose etc.. And as a dev, you have to provide a container image, if you want to play along in those.

How would you manage the networking and monitoring at a cluster level?

That’s what I’m saying though - with statically linked binaries it’s just as easy to deploy the binary as it is the docker image.

What about nix2container?

Easier to deploy and manage for server use?

Why would you build docker images for Rust? I mean if you’re renting containers from data centers or just want to run in a sandbox - sure… but rust binaries are statically linked which negates almost all other benefits of containers.

Thanks, I hadn't heard of Wolfi, nor of Chainguard. They are by a for-profit company, which isn’t an automatic deal-breaker by any means—it could even be a positive—but I do have some more homework to do before jumping onboard.

Personally, I settled on wolfi-base, which feels a lot like Alpine, but is based on glibc, so there's fewer compatibility issues. I also considered debian-slim, but there's just too many CVEs in Debian, and I was fed up with it being so outdated all the time. What I really wanted was something like wolfi, but more open, i.e., not associated with paid images. We need a glibc-based Alpine!

I think you are right, but IMO the reason is just a difference in numbers. If crate.io ever gets as much users as npm the problems will become exactly the same.

As soon as there is a situation where one dependency can decide tomorrow to pull in another one everybody is screwed. You might be comfortable with understanding the code, but if you don't have the time to fix it you are screwed either way. The customer always says "it worked yesterday, what do you mean you need to fix something? Work on this new feature instead". One year of this any you cannot manage your dependencies anymore and you have hundreds, welcome to npm.

It's a fair question. Personally for me crates.io seems to exercise good taste in what it adds and unlike npm doesn't (yet) have a long history of exploits. Also npm seems more prone to dependency explosion (leftpad,is even etc). Also I feel as though I have a fighting chance understanding the rust source should I need to delve into it.

What are the differences between cargo and npm that make you approve of the former and disapprove the latter?

Broadly I agree but I think the cargo tooling is one of the strengths of rust. The dependency downloading probably had to exist while rust was establishing itself and maturing as an ecosystem.

FWIW I wouldn't touch npm with a barge pole.

Imo the package manager is one of the things in rust that it is holding back the most. Cargo, like npm is something that rapidly causes loss of control over dependency management, because your dependencies find it too easy to pull in more shit. That is an OS job, not a first class citizen of a language

Ah, you're right! Strange wording from the Rust team.

I mean that the article mentions a group based in the DPRK using stolen credit cards to fund their stuff. The rust article shortcuts this by saying it's the DPRK itself that are behind this style of attack.

They link 2 articles and the first one mentions it. I think they just assume the second one is related to this based on symptoms.

The article say the attack style is "known to be used by the DPRK" (emphasis on the "the") when the article cited mentions no government involvement whatsoever lol.

For sure. I've done it manually for years up until now, when I realized they make really easy to use libraries for rust.

I've done the share ratio only filter like you, but I realized that some torrents are heavily leeched, yet stay unpopular. IE my share ratio was > 100, yet I was still the only seeder. So this library makes sure that they're also popular before pausing them.

Sounds like a nice thing. Although I think I'll continue doing that manually. I have a habit of evaluating the content that I've got from torrents. I do it in my mind explicitly. And then I share longer proportionally to how good the thing was, and how rare I estimate it is. This is decided once and doesn't change after, with a built-in "share ratio" limit. Once a torrent reaches its ratio and becomes Paused, I know that it's done and can be removed.

In the beginning, all torrents stop as soon as they finished downloading, to let me evaluate the content. (Uninteresting stuff I intentionally don't share back at all.)