NixOS because it’s the only usable stab at sustainable system configuration.

I recommend borgbackup.

It has since taken away Gentoo’s raison d’être a bit in my head.

I wouldn’t say so. We currently don’t hold a candle to USE-flags. Many packages are already configurable but there’s no standard on anything w.r.t. that.

There’s no technical reason we couldn’t have such a standard but it hasn’t happened yet.

That’s Nix, not NixOS.

I also wouldn’t be too sure on that “explicit” part for Docker. It’s somewhat isolated, sure, but everything but explicit: you can download arbitrary data from wherever you like.

That isn’t going to help them one bit if they have a SteamVR HMD.

It recommends AMDVLK… meh

Great way to show off you haven’t actually read any of the article past its title.

You’re comparing apples to oranges. One is a declarative Linux system environment creation solution and the other a daemon that starts sub-system environments using Linux namespaces.

You could in theory use NixOS to define a system environment that you’d run inside of a docker container. It’s a bit harder to get systemd running inside of Docker which NixOS heavily relies on but that’s beside the point. Easier integrations exist for LXD and systemd-nspawn which actually fulfil an equivalent purpose to Docker. The single component that is most comparable to Docker in a typical NixOS deployment would arguably be its init process (systemd), though its use extends far beyond setting up the namespace (the root namespace in this case).

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

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.

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.

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.

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.