I have for the past half year. I don’t have numbers, but rolling with the NVK vulkan driver (context for the unaware [1]) on mesa’s main branch gets me somewhere around half the proprietary driver’s performance on average, and can be accompanied with stutters if it is a heavy bottleneck (turning down the resolution is an easy way out). Most games I’ve tried are runnable now.

It sounds like you’re looking for more performance with this post though, so you’re likely not going to see improvements taking this route. I would still suggest giving it a try for people that are able and can tolerate the sacrifice. It’s good enough for me (and better in the wayland case) that I rarely swap to the proprietary driver anymore.

Mesa has a tracker issue for games on NVK [2] [3] with reports about game statuses and issues from the past 5 months. It includes playable and unplayable games for those interested in gauging its usability.

Also, for the record, NVK is no longer considered experimental as of mesa 24.1 (May of this year) [4].

[1] https://www.collabora.com/news-and-blog/news-and-events/nvk-has-landed.html

[2] https://docs.google.com/spreadsheets/d/1RuHD3Z_nBKCp618HHC5I9hOu0lqCoFYwQ4FM69M-Ajg/edit?gid=469568508#gid=469568508

[3] https://gitlab.freedesktop.org/mesa/mesa/-/issues/11066

[4] https://www.collabora.com/news-and-blog/news-and-events/nvk-is-now-ready-for-prime-time.html

You might be interested in git-annex (see the Bob use case).

It has file tracking so you can - for example - “ask” a repository at drive A where some file is, and git-annex can tell you it’s on drives C and D.

git-annex can also enforce rules like: “always have at least 3 copies of file X, and any drive will do”; “have one copy of every file at the drives in my house, and have another at the drives in my parents’ house”; or “if a file is really big, don’t store it on certain drives”.

A neat trick I use to figure out what apps belong to what packages is to run realpath $(which $app_name) - this outputs the full, canonicalized path to the store item, which should include the package name.

I would do a search (e.g. using grep) through a local copy of the Guix repository to figure out what services are providing the packages, then modify the service configurations (or use modified versions of services, if needed) to remove them. This might be a tedious solution, though.

I haven’t found a need to do it, but a (modify-services ... (delete pulseaudio-service-type)) in your operating-system declaration might do what you’re asking? I don’t think this is necessary though. As far as I’m aware, applications that attempt to use Pulseaudio will be transparently rerouted through pipewire-pulse, which is already configured by home-pipewire-service-type. I am also on GNOME, and I haven’t noticed any breakage in this aspect using it.

If you’re unsure that it works the way you want, you can always try the configuration out and see how it goes (note that I had to re-log in for the wireplumber service to start properly).

I’ve never tried putting it in the system configuration, but I imagine it wouldn’t work as it depends on Guix Home services.

If you haven’t used Guix Home before, the home-environment record doesn’t have required fields like operating-system does so it’s fairly easy to get started with.

(use-modules (gnu)
             (gnu home services desktop)
             (gnu home services sound))
(home-environment
 (services
  (list (service home-dbus-service-type) ;home-pipewire-service-type needs this
        (service home-pipewire-service-type))))

There is, actually! It’s available as a Guix Home service: home-pipewire-service-type was introduced around the end of December, and you can see documentation for setting it up in the manual.

When using this service, pipewire-pulse is used by default without any extra configuration.

I haven’t gotten around to trying the stable release out, but there’s one ProtonDB report - presumably for 6.0 given the post date - so far that says it works flawlessly.

I’m guessing the situation is the same as pre-6.0, though. I participated in some of the playtests, where I got the same performance issues that I got before with the game slowing to a crawl after some time. The user on ProtonDB also has pretty beefy specs, so I couldn’t say if the performance issues were fixed, either. I’m not sure if you’re asking if it’s playable or has gotten better, so I will say that (at least for pre-6.0) it technically works regardless as long as your computer is beefy enough.

The Proton GitHub issue for Squad might be nice to bookmark to make or check up on every once in a while; usually any issues, fixes, and updates end up there.