zlib-rs in Firefox - Trifecta Tech Foundation
1d 6h ago by feddit.dk/u/SorteKanin in rust@programming.dev from trifectatech.org
That's a very... non-descriptive post?
What do you mean?
People usually include a summary or first few paragraphs in the text of their post along with the link.
I honestly don't think that is very usual. I would even say it's more usual to see bare links posted, at least if I look in my own feed. But maybe that's just the sort of stuff I follow.
People usually like at least some minimal context attached, in case they are not familiar with the topic at hand.
But as it happens, the title of this specific post is rather self-documenting. So I'm not sure what's "non-descriptive" about it.
Or perhaps we have automated complaining now, pushing against automated low quality (re-)posting. And we got caught in the middle as remnants of the genuine human interaction that used to take place online 🙂.
I can assure you it's not "automated" or anything like that. I usually prefer to see an excert of the post that caught the poster's attention, or any info in that realm really.
For me it's interesting because nowadays we have frequently too much information, not too little.
If the majority of the title (and body) is the name of a company or organization, I get cautious.
zlib-rs => crate replacing non-rust zlib
firefox => where the replacement is happening
trifecta => the foundation sponsored to develop the replacements
Maybe I'm influenced by the fact that I pre-knew all of the above. But as I wrote, it's quite ironic choosing this perfect title in particular to complain about 😉.
On the topic of low(ish) level dependencies getting incrementally replaced with Rust rewrites, a Google employee did a presentation on the same topic recently.
Makes sense now! Also, the post itself is good! (Pre-knowledge of the terms possibly helped you, yes.)
Posts usually show a summary through the website provided metadata, though, but this website doesn't.
Dunno if that's what the original commenter was thinking of, though.
Shouldn't compilers (in this case LLVM) cover such CPU bugs with flags? So users can commit to either evading CPU bugs or not.
It'd also be a good entry-point and overview of what CPU bugs are out there. Without it, how are you supposed to know about and evaluate them?
I was kinda surprised as well that you couldn't annotate the function or something. But then again, an attribute like "please don't use this instruction" sounds like something that's pretty hard to integrate in the code generation. What kind of flag would you use? I don't think you want to apply that flag to everything, just to that particular function.