Arech

Instead of confidence intervals, it's much more efficient to use proper parameter-free statistical tests like Brunner-Munzel, or Mann-Whittney U-test. Benchstats package helps doing that easily, handling report too.

Well, AMD open sources all its stack, making this possible.

Haha. People have already said what is Vulkan in practice - it's very convoluted low-level API, in which you have to write pretty complicated 200+LoC just to have simplest stuff running. Also doing compute on NVIDIA in Vulkan is fun if you believe the specs word for word. If you don't, you switch a purely compute pipeline into a graphical mode with a window and a swapchain, and instantly get roughly +20% of performance out of that. I don't know if this was a bug or an intended behavior (to protect CUDA), but this how it was a couple years ago.

That's what I thought of too. Given their task formulation (they basically said - "check these binaries with these tools at your disposal" - and that's it!) their results are already super impressive. With a proper guidance and professional oversight it's a tremendous force multiplier.

Thanks, this is a very interesting topic.

What I personally would like to see is some kind of quantization of how the biases that the author talks about (such as insufficient seed volume of a PRNG) affects computed p-values. Specifically, why there must no "cancellation of errors" happen? So far, IIUC, the author only shows theoretical possibility of errors, but what's more interesting is a real effect. When it all boils down to a p-value being less than a certain threshold (choosing which is another pita), it might not matter whether a true p-value is within, say, 2^-16 from the computed.

I had been Windows user since Windows3.1. More than 3 decades straight. After a few years of working with Linux, installed Debian on home PC about a year ago and couldn't be more happier since then.

Is it a normal mic, or bluetooth? I think, Trixie have some regressions in bluetooth stack of Cinnamon - it worked nicely in Bookworm, but I had weird issues on Trixie that just disappeared once I switched to KDE (didn't try Gnome).

and sometimes a total unbelievable junk...

My dog (Briard) isn't just addicted to play fetch with balls.. Since he knows that when another dog enters the dog park, the ball will be removed/hidden from him (to prevent the dogs clashing trying to get the ball), he becomes hostile to the dog entering the park, actively trying to prevent them from doing so! This happens only if we started to play with balls. If not, he'll be totally friendly... What an ass!

Your don't need noexcept on it, complier sees it on its own without a potential noexcept overhead... Other than that - agree.

Exactly this.

In most cases (and this was the case of Mozilla I referred to) it's only a matter of compiling code that already have all support necessary. They are using some upstream component that works perfectly fine on my architecture. They just decided to drop it, because they could.

Ah, com'on, spare me from these strawman arguments. Good enought is good enough. If F-Droid wasn't worried about that, you definitely have no reasons to do that for them.

"A tiny group is holding back everyone" is another silly strawman argument - all decent packaging/installation systems support providing different binaries for different architectures. It's just a matter of compiling just another binary and putting it into a package. Nobody is being hold back by anyone, you just can't make a more silly argument than that...

This is super annoying how SW vendors forcefully deprecate good enough hardware.

Genuinely hate that, as Mozilla has deprived me from Firefox's translation feature because of that.