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.

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.

A driver manager will not make the problems inherent to Nvidia’s crappy proprietary drivers that need workarounds go away.

If you don’t want to tinker a whole lot, buy a GPU from a vendor that hasn’t been actively hostile to its users for decades and is well supported by Linux and the freedesktop such as AMD.

No AMD GPU user has a need for anything resembling a “driver manager”.

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.

They meant the SMART self-test, not SMART data readout. Those are not meant to be interpreted by laymen and often not even experts.

I know that part.

The other fork has existed for a long while.

I don’t know what the heck you’re talking about.

I see overwhelming evidence that they have intentionally made parts of the clients’ code proprietary. You can check the client code yourself (for now anyways) and convince yourself of the fact that the bw SDK code is in indeed integrated into the bitwarden clients’ code base.

This is the license text of the sdk-internal used in 2024.10.1 (0.1.3): https://github.com/bitwarden/sdk/blob/16a8496bfb62d78c9692a44515f63e73248e7aab/LICENSE

You can read that license text to convince yourself of the fact that it is absolutely proprietary.

Here is also the CTO and founder of Bitwarden admitting that they have done it and are also attempting to subvert the GPL in using sdk-internal:

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.

• the SDK and the client are two separate programs
• code for each program is in separate repositories
• 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.

(Emphasis mine.)

The fluff about the ability to even build the app is secondary, the primary issue is that the Bitwarden clients are no longer free software. That fact is irrefutable.

Is this your personal phone? If your work were to dictate what you are allowed to install on your personal phone, that’d be a serious overstepping of bounds.

Perhaps you can sneak in f-droid via adb install and give it app installation permissions via ADB though.

What’s the history behind this? Why could the changes be done upstream, necessitating a fork?

https://lemmy.ndlug.org/post/1268531

How different is this to gitlab’s open core model?

That’s a really good question that I don’t immediately have a satisfying answer to.

There are some differences I can point out though:

• Gitlab has demonstrated its commitment to keep the core of their product, though limited in features, free and open source. As of now, BW’s clients cannot even be compiled without the proprietary SDK anymore.
• Gitlab was always a permissive license (MIT) and never attempted to subvert its original license terms
• Gitlab-EE’s “closed” core is actually quite open (go read the source code) but still squarely in the proprietary camp because it requires you to have a valid subscription to exercise your freedoms.

Is this a permanent change?

It’d be quite trivial for them to do in technical terms: Either license the SDK as GPL or stop using it in the clients.

I don’t see a reason for them to roll it back though. This was decided long ago and they explicitly decided to stray away from the status quo and make it closed source.

The only thing I could see making them revert this would be public pressure. If they lose a sufficient amount of subscribers over this, that might make them reconsider. Honestly though by that time, the cat’s out of the bag and all the public goodwill and trust is gone.
It’s honestly a bafflingly bad decision from even just a business perspective. I predict they’ll lose at least 20% but likely 30-50% of their subscribers to this.

Is the involvement of investors the root of this?

I find that likely. If it stinks, it’s usually something stinky’s fault.

Are we overreacting as it doesn’t meet our strict definition of foss?

They are attempting to subvert one of the FOSS licenses held in the highest regard. You cannot really be much more anti than this.

An “honest” switch to completely proprietary licenses with a public announcement months prior would have been easier to accept.

As with all of their services, the back-end is closed-source.

For the purposes of user freedom, it’s not that critical as the back-end merely facilitates the storage and synchronisation of encrypted data. This is different from the bitwarden case where they’re now including freedom disrespecting code into the most critical part of their software: the clients which handle the unencrypted data.
Fact of the matter remains however that Proton Pass restricts your freedom by not allowing you to self-host it.

If you are fine with not being able to self-host, I’d say it’s a good option though. Doubly so if you are already a customer of their other services.
Proton has demonstrated time and time again to act for the benefit of its users in the past decade and I see no incentive for them to stop doing so. I’d estimate a low risk of enshittification for Proton which is high praise for a company of their size.