You should scrub your data regularly with btrfs. That’s just a mean to verify the data is in-tact though; to detect corruption.

You cannot really do anything actively to keep the data in-tact. Failure can and will happen. To keep your data safe, you must plan for failure to happen:

Expect a power surge to fry all your disks at the same time.
Expect your house to burn down or flood.
Expect to run the wrong command and istantly hose your entire array.
Expect your backup server to get ransomware’d.
…

Only if you effectively mitigate these dangers will your data stay safe.

Stable distros can and will backport security fixes. Good ones that is.

Pretty cool!

Have you thought about whether this could also be used for limited write access? A common use-case for abusive image gallery services that you cannot ordinarily fulfil with Immich is shared albums where multiple people that e.g. attended the same event can collect pictures in without complex authentication (just a single shared secret or even just the link to the album).

Ahhhhh whyyyyy, you’ve got all of these standard response codes made for you, why would you blatantly ignore them like that?!

Gaming with VRR is finally viable in this version!

You’d think so but IIRC when Phoronix tested it, Coreboot would always significantly underperform compared to the regular firmware. It wasn’t much but the effect was measurable.

That would be a reasonable explanation if we didn’t get an admission this was done very much intentionally so, with only the inability to even build being an unintended side-effect from the founder and CTO himself.

I’d invite you to actually read the two comments they made in the thread I linked, I get the feeling that you didn’t.

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.

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.

If anyone reading has proof of M$ spying on the German government they could whistle about, right about now would be a great time to do it ;)

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.

Also, their client is still open

*is open again. The clients they distributed were not open source until they open sourced sdk-internal. The fact that you couldn’t even build it with only open code even if you wanted to was a bug but that’s a rather minor issue in comparison.

I also fully believe that they would not have GPL’d sdk-intenral without public pressure. Even when they were originally called out they were pretty clear that the integration of proprietary code was intentional and done with the knowledge that it would typically violate the GPL.

If you don’t see what’s ethically wrong with even attempting to subvert the GPL, I don’t think you’ve understood open source.

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.

One does not “accidentally” build a proprietary SDK for months and make the clients depend on it, intentionally violating the GPL.

They even publicly admitted to doing precisely that, defending their GPL violation with dubious claims how the GPL supposedly works.