Also, if you downloaded the 1.4.0 installer, you might have to guix pull (so the current state of Guix's plasma is made available) before trying to do any reconfiguring.
I don't think the macro usage is 100% necessary; in the case of dynamic text, I'd specify a function in a group's :description slot (like this; function here) that builds the description from transient state.
Auto-building menus from e.g. makefiles is a feature I'd like Disproject to support in some capacity as well in the future. I came across the transient-compile package a while back while researching ideas; might be of interest to look at.
It's mentioned that using a newer gcc should fix the problem with more context about what's happening.
I actually wasn't aware there was breakage since I was using a custom steam package with gcc already updated for other reasons; thanks for posting about this.
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].
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).
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.
::: spoiler Here's a minimal working configuration, for example:
(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.
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:
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).
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.
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).
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.
#!/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):
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.
Curiously, I can reproduce this on my Guix System, but actually not on my Fedora system (where it is exported automatically), so I guess some distros choose to explicitly export the HOSTNAME variable?
You're reading the manual for Guix 1.4.0, which was released more than a few years ago! You might find the development version of the manual more helpful for documentation on plasma-desktop-service-type: https://guix.gnu.org/manual/devel/en/html_node/Desktop-Services.html#index-plasma_002ddesktop_002dservice_002dtype
I have Plasma configurations here, although it's been a while since I've used them (am on GNOME at the moment): https://github.com/aurtzy/guix-config/blob/master/modules/my-guix/mods/desktop-environment.scm#L110
Also, if you downloaded the 1.4.0 installer, you might have to guix pull (so the current state of Guix's plasma is made available) before trying to do any reconfiguring.
FWIW, the GNU Project makes an argument against LGPL if you believe your software "provides a significant unique capability": https://www.gnu.org/licenses/why-not-lgpl.html
I don't think the macro usage is 100% necessary; in the case of dynamic text, I'd specify a function in a group's
:descriptionslot (like this; function here) that builds the description from transient state.Auto-building menus from e.g. makefiles is a feature I'd like Disproject to support in some capacity as well in the future. I came across the transient-compile package a while back while researching ideas; might be of interest to look at.
Oops! I was wondering what you meant, but I think that might have been because I set my original comment's language to Spanish on accident...
This sounds like the issue you're running into: https://gitlab.com/nonguix/nonguix/-/issues/355
It's mentioned that using a newer gcc should fix the problem with more context about what's happening.
I actually wasn't aware there was breakage since I was using a custom steam package with gcc already updated for other reasons; thanks for posting about this.
Is this perhaps your issue? https://github.com/element-hq/element-android/issues/8881
I had a friend encounter this, and apparently it's been fixed in a recent release.
(CCing others that had the same problem: @ReversalHatchery@beehaw.org, @filibusterPerigrin@programming.dev)
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).
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 youroperating-systemdeclaration 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 throughpipewire-pulse, which is already configured byhome-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-environmentrecord doesn't have required fields likeoperating-systemdoes so it's fairly easy to get started with. ::: spoiler Here's a minimal working configuration, for example::::
There is, actually! It's available as a Guix Home service:
home-pipewire-service-typewas introduced around the end of December, and you can see documentation for setting it up in the manual.When using this service,
pipewire-pulseis used by default without any extra configuration.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
--userflag 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:
xdg-opensince that should be available to the Flatpak. I usedfirefox-readeras the protocol, so I putxdg-open firefox-reader://%uas the custom command (so a command Akregator would run might look likexdg-open firefox-reader://https://example.com).~/.local/share/applicationsis 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 withabout:reader?url=prefixed. The script can be anywhere in$PATH.xdg-mime default org.mozilla.firefox.reader.desktop x-scheme-handler/firefox-reader(org.mozilla.firefox.reader.desktopis the name of my desktop entry file).update-desktop-database ~/.local/share/applicationssoxdg-openwould find the "Firefox Reader" desktop entry.::: spoiler My Firefox Reader desktop entry
:::
::: spoiler open-firefox-reader.sh script
:::
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):
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:
nouveau.config=NvGspRm=1-Dvulkan-drivers=nouveau-experimentalflag.A few notes:
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.
It appears that this is actually a Bash thing rather than a Guile thing:
https://superuser.com/questions/132489/hostname-environment-variable-on-linux
For more information about why, see the comment in this other answer which mentions that
HOSTNAMEis not required for POSIX compliance:https://superuser.com/questions/132489/hostname-environment-variable-on-linux/132500#132500
https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html
Curiously, I can reproduce this on my Guix System, but actually not on my Fedora system (where it is exported automatically), so I guess some distros choose to explicitly export the
HOSTNAMEvariable?