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".

Slight correction, it's available in Linux 6.7, and has to be enabled with the kernel parameter nouveau.config=NvGspRm=1. It may be enabled by default soon though (latest news I could find about that here).

NVK itself is not dependent on anything proprietary, but it's practically required to enable NVIDIA's GSP firmware blob if you want to see actual performance since it's what enables re-clocking (older post by Collabora here which touches on it).

Cheers, glad to hear you got it working. I don't think there's any problem on your end; all my flatpaks are user-installed as a Guix System user, so it didn't cross my mind that a habitually-placed --user flag would not work if something was installed system-wide!

Thanks for posting about this! I never thought to try this as an Akregator user, but it's a great idea... I spent the past day getting this to work since I also use the Flatpaks; hope it helps.

As suggested by @progandy@feddit.de, one solution is to define a custom protocol where the URL gets passed to a script that opens Firefox Reader with the URL; here's what I've done:

1. Decide on a protocol name, which the URL will be prefixed with and passed to xdg-open since that should be available to the Flatpak. I used firefox-reader as the protocol, so I put xdg-open firefox-reader://%u as the custom command (so a command Akregator would run might look like xdg-open firefox-reader://https://example.com).
2. Define a desktop entry to support the custom protocol (you can see mine below). ~/.local/share/applications is the standard place to put these, as far as I'm aware. Since the custom protocol needs to be removed from the URL, I wrote a script (also below) to do this and then call Firefox with about:reader?url= prefixed. The script can be anywhere in $PATH.
3. Add the desktop entry as a "default application" for opening URLs using this custom protocol. In my case, I ran xdg-mime default org.mozilla.firefox.reader.desktop x-scheme-handler/firefox-reader (org.mozilla.firefox.reader.desktop is the name of my desktop entry file).
4. You also might have to update some mime/xdg database stuff. I had to run update-desktop-database ~/.local/share/applications so xdg-open would find the "Firefox Reader" desktop entry.

[Desktop Entry]
Type=Application
Name=Firefox Reader
Exec=open-firefox-reader.sh %u
StartupNotify=false
MimeType=x-scheme-handler/firefox-reader;

#!/usr/bin/env bash

flatpak run --user org.mozilla.firefox about:reader?url="${1#firefox-reader://}"

If you have any other trouble or want to find more information about this since the desktop entry could probably be tweaked, here are the sources of note I used to figure this out (If I forgot a step or two writing this, they should also be present somewhere in there):

• https://unix.stackexchange.com/questions/497146/create-a-custom-url-protocol-handler
• https://wiki.archlinux.org/title/XDG_MIME_Applications
• https://wiki.archlinux.org/title/Desktop_entries#Update_database_of_desktop_entries

I've been having my own fun trying out NVK on Guix System so I can't give you specific instructions (assuming you're not using Guix), but I can tell you what you need and maybe someone else can chip in on how/if you need to do anything else on your distro:

• Linux kernel >= 6.7
• GSP firmware enabled via the kernel parameter nouveau.config=NvGspRm=1
• Mesa built with the -Dvulkan-drivers=nouveau-experimental flag.

A few notes:

• Performance and stability of games has been fairly hit-or-miss for me. Of the 10 Vulkan games I've tried so far: 3 run perfectly, 3 are playable with noticeable issues, and 4 are borked.
• NVK is Vulkan-only, but performance largely comes from the GSP firmware so you will still see a difference (huge for me) in games not using Vulkan.
• You can override flatpaks to use the host's Mesa version (set FLATPAK_GL_DRIVERS=host); however, there's a bug that causes the Steam Flatpak to not work when doing this. The mesa-git-extension Flatpak exists which can also be used to replace Mesa runtimes, but it had issues building with NVK so it's currently disabled.

The only package I'm aware of at the moment (other than my hacked-together Guix package) is available in the AUR.

I use git-annex and Guix (particularly Guix Home in this case) for managing all of my data, including dotfiles. git-annex handles syncing (and backups via delivery to a Borg repo) and version management as git does, while Guix takes care of installing programs and setting up configuration files.

I previously wrote a custom Guix service that utilized Stow as well for managing writable files, but have since replaced it with another custom Guix service that handles some cleanup processes better.

Depending on how much you want simplicity of restoration, this approach might be on the heavier side since it's concerned with a lot more than just dotfiles. You could replace git-annex with git to simplify the syncing part if you're only interested in managing configuration files, though. Here's what my Guix config looks like; the readme file shows how I would set up a system from scratch.

Was not aware of this, thanks! Looks like it does, with a notable difference being that Cryptomator has better cross-platform support in exchange for not having file size obfuscation.

The CryFS developers have a comparison page here that might help you decide what to use. There's a summary table at the bottom that gives a comparison of features between encryption filesystems if you don't feel like reading through it all.

I personally use and would recommend CryFS because it's the only one (that I'm aware of) that plays nice with data synchronization software (i.e. doesn't store the container as a single file) while keeping the directory structure encrypted.

They're talking about this Squad.

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.

Does Guix fit your criteria, perhaps? If you haven't heard of it, you can think of it as Nix with a Lisp frontend.

I unfortunately am not very experienced with containerizing packages so I can't say much, but I know you can do it; the Nonguix channel employs containers for some proprietary software.

Like Nix, Guix has all that building-from-source stuff you'd want from Gentoo. There's recently been work on making parameterized packages (the Guix equivalent of USE flags) a thing, but it's still work-in-progress.

Ignoring the steep upfront cost of learning it, I'd say Guix makes it incredibly easy to add your own packages. Here's the custom packages I currently have in my dotfiles repository. I can import one to my main config file, add the package, and it gets included in my environment the next time I reconfigure it.

As for patches, I can't make any comparisons since I'm not familiar with Gentoo, so I think a code snippet is probably better for you to judge if you'd like it.

(define-public custom-pkg
  (package
    (inherit pkg)
    (name "custom-pkg")
    (version (package-version pkg))
    (source (origin
              (inherit (package-source pkg))
              (patches
               (list (string-append (dirname (current-filename))
                                    "/fix-some-thing.patch")))))))

(define-public custom-pkg
  (package-with-patches
   pkg
   (list (string-append (dirname (current-filename))
                        "/fix-some-thing.patch"))))

Not sure if this addresses your concern about multi-architecture support, but the Foreign Architectures section of the manual discusses what you can build to.

EDIT: So I was curious after posting this because usually the CLI often has much less verbose options (like --with-input for replacing inputs), and I started wondering if there was any procedure that would make this simpler. Turns out there is :) I've included it under the example. Although, I suppose I should have mentioned you could write your own if you really wanted to.

I use git-annex for syncing and backing up all of my data; would highly recommend if you're looking for something that scales well, OP.

Could you elaborate on why you think Guix will attempt to pull systemd? As far as I'm aware, Guix doesn't impose any hard requirement on systemd when installing it on a foreign system; the manual (particularly 2.1 Binary Installation) simply provides instructions for setting it up on systemd and Upstart.

I just found this blog post about setting up Guix on Void Linux if it helps at all.

It's my pleasure :)

Just a note if you plan on installing Guix on top though, since I didn't realize you might be running NixOS: according to this discussion, you'd need to take a different route to get Guix working.

I do!

For starters, you're not required to install Guix System in order to use the Guix package manager itself; the manual provides instructions for installing it on top of your existing system here if you want to use it but not fully commit (you can do this with Nix too).

Guix allows for adding new sources to pull packages from using channels. The nonguix channel provides the Linux kernel - blobs and all - as well as other stuff that won't be upstreamed, like Steam and NVIDIA drivers.

I recommend this helpful series by System Crafters, which includes a few guides on installing Guix and Guix System with the full Linux kernel.

You might find The Full-Source Bootstrap: Building from source all the way down by some of the GNU Guix maintainers of interest to read, which discusses how Guix is attempting to solve the "trusting trust" attack some have mentioned here.

Although I haven't used it myself yet, Guix actually has a feature that lets you "challenge" the build servers to see if your builds match the pre-built binaries (the command being aptly named guix challenge).

I remember having this issue, albeit not as workflow-disrupting as you've had it so I never bothered actively searching for a solution. I can confirm however that there is definitely a solution; at some point in my migrations to different distros, the problem stopped showing up, and right now I actually can't reproduce the problem - labels are displayed correctly for me, both on my existing drives and new partitions that I create.

After some digging (and a sleep-deprived me smiting my boot partition during my investigation and having to fix that, LMAO - I never thought it'd happen, but Guix saved me from a reinstall), I found that LUKS1 has some kind of limitation that makes Dolphin not display the label as expected according to this and my own testing, which may be your problem if your drives are still using LUKS1. The Arch Wiki has a section on how to convert to LUKS2 here.

At the very least, if this is not the solution for you, I can say with certainty that it is fixable!