Their success is relatively easy to measure objectively by their effectiveness at protecting communities from i.e. subtle trolls or troll enablers.

Though one’s opinion on topics can influence the ability to spot such scum in the moment, the “right” people/a good moderator will know how to do that despite their topical (dis)agreements.

You’d typically think the abuse that happens on a higher level than dumb spam which those platforms succumb to would be even worse, but I feel we’re somehow in a slightly better position to regulate that on Lemmy because of the delegation of moderation to users rather than instance admins.

We “just” need a relatively small amount of the “right” people to effectively counter that.

Two posts up from what I posted: https://github.com/bitwarden/clients/issues/11611#issuecomment-2424865225

Hi @brjsp, Thanks for sharing your concerns here. We have been progressing use of our SDK in more use cases for our clients. However, our goal is to make sure that the SDK is used in a way that maintains GPL compatibility.

1. the SDK and the client are two separate programs
2. code for each program is in separate repositories
3. the fact that the two programs communicate using standard protocols does not mean they are one program for purposes of GPLv3

Being able to build the app as you are trying to do here is an issue we plan to resolve and is merely a bug.

Nah it’s not news that their ethos has been fading away for a long time now and that Mozilla just really isn’t what it used to be a decade ago.

Right now, it’s definitely a good thing it’s not popular. We are not in any way shape or form ready for the spam that popular platforms receive.

“Oh, but there are no journalists!”

Good? I don’t want endless ragebait posted in my feeds.

I don’t think that’s the kind of “journalism” your strawman desires.

This is the Mozilla foundation, not the Mozilla corp. The latter has the deal with Google; the former couldn’t make that deal even if they wanted to.

the idea of putting people before profit feels increasingly radical

What. The. Fuck.

Hell seems to be freezing over at an alarming rate these days; climate change is getting pretty extreme down there too huh?

More likely is the device firmware and you likely can’t fix that.

If you have a reasonably up to date mesa and use a Proton version with a new enough DXVK, DXVK can utilise Graphics Pipeline Libraries to link shaders just like a d3d11 driver on Windows would, eliminating stutter.

I believe shader precomp is used for some video codec edge cases though, so YMMV depending on the game.

No, it wouldn’t make any sort of difference.

And also in any other filesystem’s code or the block layers below the filesystem. As I said, unlikely scenario.

Until the situation now, this was limited to the server, not the clients. You could replace the server with Vaultwarden and build it without enterprise features. Not ideal but fine because the server isn’t the critical part. It never handles your secrets in any way.

What they tried to do now was integrate proprietary code into the clients that everyone uses. This is a lot more critical as it can access the secrets in plain text.

This also wasn’t a “mistake” or “bug”, they openly admitted to doing this with the intention of subverting the client code’s GPL.

For ~$30 a month, that’s a complete and utter rip-off.

Even here in Neuland Germany you get at least decent internet with no caps for that price.

There aren’t any “extra access checks” to my knowledge. It’s just the same regular access checks applied to a different set of circumstances.

Flatpaks are containers. They do have a lot of holes though.

As long as the hardware functions as it should (e.g. respects barriers) and there is no software bug in the stack, no.

That’s a highly unlikely scenario though. Make backups.

Please stop trying to interpret the SMART data report. Even if you’re knowledgeable it can easily mislead you because this is vendor-specific data that follows no standard and is frequently misinterpreted by even the program displaying the data.

If the self-test passed, it’s likely the cable or the controller. Try a different cable.

If you want fast nix evals and docker builds, you absolutely do care about per-core performance.

I have little experience with Rust but, while I do know that it parallelises quite well, I also believe that there are still many single-threaded operations on the critical path though such as linking.

I think for your purposes, you’ll do well with any 8-core AMD Zen4 that can draw more than 45W or any 4+n core Zen5. The latter would be a bit more efficient but practically the same perf in code compilation.

Intel is not competitive currently and ARM is still not quite there yet.