Regarding Cargo.lock, the recommendation always was to include it in version control for application/binary crates, but not library ones. But tendencies changed over time to include it even for libraries. If a rust-toolchain file is tracked by version control, and is pinned to a specific stable release, then Cargo.lock should definitely be tracked too [1][2].

It’s strictly more information tracked, so there is no logical reason not to include it. There was this concern about people not being aware of --locked not being the default behaviour of cargo install, giving a false sense of security/reliability/reproducibility. But “false sense” is never a good technical argument in my book.

Anyway, your crate is an application/binary one. And if you were to not change the "*" dependency version requirement, then it is almost guaranteed that building your crate will break in the future without tracking Cargo.lock ;)

• Don’t use "*" dep version requirements.
• Add Cargo.lock to version control.
• Why read to string if you’re going to base64-encode and use Vec<u8> later anyway?

Here is an originally random list (using cargo tree --prefix=depth) with some very loose logical grouping. Wide-scoped and well-known crates removed (some remaining are probably still known by most).

mime data-encoding percent-encoding textwrap unescape unicode-width scraper
arrayvec bimap bstr enum-iterator os_str_bytes pretty_assertions paste
clap_complete console indicatif shlex
lz4_flex mpeg2ts roxmltree speedy
aes base64 hex cbc sha1 sha2 rsa
reverse_geocoder trust-dns-resolver
signal-hook signal-hook-tokio
blocking
fs2
semver
snmalloc-rs

My quick notes which are tailored to beginners:

Use Option::ok_or_else() and Result::map_err() instead of let .. else.

• let .. else didn’t always exist. And you might find that some old timers are slightly triggered by it.
• Functional style is generally preferred, as long as it doesn’t effectively become a code obfuscater, like over-using Options as iterators (yes Options are iterators).
• Familiarize yourself with the ? operator and the Try trait

Type inference and generic params

let headers: HashMap = header_pairs
        .iter()
        .map(|line| line.split_once(":").unwrap())
        .map(|(k, v)| (k.trim().to_string(), v.trim().to_string()))
        .collect();

(Borken sanitization will probably butcher this code, good thing the problem will be gone in Lemmy 0.19)

Three tips here:

1. You don’t need to annotate the type here because it can be inferred since headers will be returned as a struct field, the type of which is already known.
2. In this pattern, you should know that you can provide the collected type as a generic param to collect() itself. That may prove useful in other scenarios.
3. You should know that you can collect to a Result/Option if the iterator items are Results/Options. So that .unwrap() is not an ergonomic necessity 😉

Minor point

• Use .into() or .to_owned() for &str => String conversions.
  • Again, some pre-specialization old timers may get slightly triggered by it.

make good use of the crate echo system

• It’s important to make good use of the crate echo system, and talking to people is important in doing that correctly and efficiently.
  • This post is a good start.
  • More specifically, the http crate is the compatibility layer used HTTP rust implementations. Check it out and maybe incorporate it into your experimental/educational code.

Alright, I will stop myself here.

Blog announcement.

https://github.com/LemmyNet/lemmy/pull/4024

Broken input sanitization probably.

Issue will thankfully no longer exist in the next lemmy release.

https://github.com/LemmyNet/lemmy/issues/3827

Because the audiophile is broke, and will have to listen to some music on a lowly device, but the craving for some placebo is still there.

EDIT: btw, the bitrate is missing a k in your command 😉

Not audiophilic enough.

ffmpeg -i in.flac -ar 48000 \
            -af aresample=resampler=soxr:precision=28:cheby=1:dither_method=shibata \
            -c:a libopus -b:a 224k out.opus

There is no need to talk about an imaginary version of IPFS. GNUnet already exists. You can add that to the list of actually superior technologies that long predates IPFS.

As I mentioned, IPFS is nothing but very basic tech that got overhyped to junior/uninformed developers, and crypto scam victims.

Besides being overhyped basic tech where way more useful and practical solutions existed for decades (Freenet existed since year 2000 btw, and Tahoe-LAFS since 2007), there is nothing private about IPFS. This is a dangerous message to purport.

IPFS is as practically useful as NFTs. No wonder the two crowds connected well!

iroh is an attempt to create a useful and practical IPFS. But none of the bigger practical features is implemented yet. And the design itself doesn’t appear to be finalized. I’m willing to give iroh a chance, although the close proximity to the IPFS crowd doesn’t fill one with confidence.

Sort by “best” is coming to Lemmy, in case you didn’t know.

Your aggressive tone is predictably inappropriate considering your failure at applying simple logic. You would only have a partial excuse if you’re 11y/o or something.

There is f-droid the app store, and f-droid.org’s main repo. See, it’s not that hard.

just because they have an app that allows you to add other repos doesn’t mean those other repos are a part of f-droid

And that app is called… get it?

Because those other repos are not f-droid repos

Repos made to work in the f-droid app are not f-droid repos… wow

Is the f-droid.org’s archive repo not an f-droid repo, too. lol.

Please tell me you’re not an adult!

The thing is, you started on the right track:

Sync is not open source and Fdroid only allows open source.

Here, you are on the right. And you could have followed up later by simply pointing out that “Will it be released to F-Droid” usually means “Will it be on f-droid.org’s FOSS-only main repo”, but you decided to rant some weird incoherent shit, and insisted on dying on a hell of straws instead!

The codec is basic, uses decades-old tech, and was trivially REed.

Lemmy instance choice does not check out ;)

and for testing you get a wackload of SBCs and Bluetooth chips and test that

I asked because I wasn’t aware of any consumer buds supporting Opus. I wasn’t aware of PineBuds, thank you for mentioning them.

keep in mind that it’s hard to get real numbers on LDAC because decoding is proprietary

I used to think the same. But as it turns out, a decoder exists. Maybe some people don’t want anyone to know about it to keep the myths alive ;)

EDIT: Also, as a golden rule, whenever anyone sees the words High-Res in an audio context, they should immediately realize that they are being bullshitted.

After testing LC3Plus, Opus, and AAC personally for bluetooth, LDAC claims are BS

How did you test Opus for bluetooth?

latency is significantly better then AAC (tested against libfdk) and marginally better then opus

In case you didn’t know, you can use 10ms (or even 5ms) frames with Opus instead of the default (20ms). 10ms should roughly match LC3plus’s default latency while still retaining high quality.

LDAC claims are completely bullshit.

LC3plus is worse than AAC quality wise (to be expected). Lower latency is the only thing going for it. And that’s just because AAC is a very high-latency codec. Opus (as a format) would win on both fronts, although there could be issues with creating a high-quality encoder for it that is not too complex, and power-efficient.