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.
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.
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.
They meant the SMART self-test, not SMART data readout. Those are not meant to be interpreted by laymen and often not even experts.
What are you going to do with it that requires multicore perf?
as an independent voter that feels continually ignored by the by the right and left
A party in the U.S. of any relevance that could be described as "left-wing" would be news to me.
You've got a corrupt conservative party and an extremely corrupt "pro"gressive(regressive?) anti-democratic party.
third parties can be an attractive choice for some
Third parties are never an attractive choice for anyone in a first-past-the-post voting systems with two extremely dominant parties, regardless of what any of those parties stand for. The only sensible choice is the (in your opinion) least bad option that still has a realistic chance of winning.
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?
Flatpaks are containers. They do have a lot of holes though.