Yeah. The ArchLinux corporation must be losing money left and right because of this.

Are they stupid?!

The real news is that iroh hit v1.0.0.

noq is a fork of crate that implements QUIC which iroh uses. In other words, it's a minute implementation detail not immediately relevant at all to people who don't even know what iroh is (yet).

How did we get here? OP text is copied verbatim from the README, with the presumption that it's relevant, but it isn't.

How did that happen? I would assume no human was directly involved in doing that, which would be par for the course with that shit-reposting account.

Can you provide examples of what you're finding hard?
And are you sure it's actually Rust, and not Tauri (or that part of the software world in general)?

(Didn't read the article.)

It's not a secret approach or anything. thiserror gives you that with a simple #[from] attribute annotation on the relevant error variant on your Error enum (which is what your Error type should be).

In your case, this just works because you're not attaching custom context to your error. Usually, you would want to attach some context, and in that case, .map_err()would obviously still be needed, and that's fine. This idea of having to write as little code as possible is stupid.

Sometimes, attaching context once is sufficient, sometimes it's not. If it's the former, then you can still do From in your bigger error enums which have variants from your smaller error enums (e.g. crate-level Error type with variants trivially wrapping module-level Error types).

Enthusiasts will care because it could save them storage space for equivalent quality

That's the thing, even if you ignore that such scenarios involve lossy-to-lossy re-encodes (bad), and even when you ignore the general lack of psychovisual tuning in new encoders, the advertised so called objective "20%-30% improvement" is not universal, and only applies to bit-starved resolution-maxed encodes.

Your file is 1080p or 720p? you won't get that improvement, even in not-fit-for-purpose "objective" measures.

You want to encode at a higher bitrate than YouTube to actually get good quality? you won't get that improvement either.

So if you embark on such a futile journey, you could be wasting a lot of computing power for no, or even negative, gain.

now

Full-length encodes will take days to finish, and we are not talking single digits.

An almost, but not really, practical encoder will probably take at least a year of development before it's ready.

And anyway, do end-users still care about codecs (beyond decoding complexity/hardware support)?

Cool. Thanks for clarifying that up. I may check it out (if I ever have the time).

Congratulations.

I should probably look this up instead of asking, but how decoupled is the registry and backend code from the web frontend?

Is it possible for an external project to, for example, develop a fully functional alternative in Rust/WASM?

That's a scenario where looking up the slides is the right course of actions, or at worst, seeking informed coverage (e.g. from some LWN reporters, but not all).

It is not uncommon for info provided by tech journalists from sites like OP, or even worse, "e-celeb" baiters, to actually have negative worth.

(Disclaimer: I didn't specifically read OP, for the reason stated above.)

Anyone who's actually relevant is already aware of the technical details. Anyone with a non-gossipy interest in the topic has already watched the talk (which is available), or will watch it before opening their mouth.

What remains is the internet gantry, which is irrelevant.