Wayland on NixOS: Confusion, Conquest, Triumph(drakerossman.com)
drakerossman.com
Wayland on NixOS: Confusion, Conquest, Triumph
https://drakerossman.com/blog/wayland-on-nixos-confusion-conquest-triumph
69 comments
In case the author reads this: "use `sudo su`" - this is unnecessary. Sudo already gives you root here. You can use `sudo -i` to get a login shell directly.
That's a hyper specific nit you got there, and only referenced once in the middle of the article.
However sudo -i, sudo su, and sudo su - are all common ways to achieve the desired result, with very subtle differences. Sudo su - is my preferred method because it puts you into a root login shell rather than just a shell with root privileges.
But these are all pretty pandantic to call one way correct, and others incorrect.
However sudo -i, sudo su, and sudo su - are all common ways to achieve the desired result, with very subtle differences. Sudo su - is my preferred method because it puts you into a root login shell rather than just a shell with root privileges.
But these are all pretty pandantic to call one way correct, and others incorrect.
sudo -i specifically invokes login shell:
> Run the shell specified by the target user's password database entry as a login shell.
Contrast to -s option:
> Run the shell specified by the SHELL environment variable if it is set or the shell specified by the invoking user's password database entry
> Run the shell specified by the target user's password database entry as a login shell.
Contrast to -s option:
> Run the shell specified by the SHELL environment variable if it is set or the shell specified by the invoking user's password database entry
It's not that it's incorrect, it's just unnecessary, same as "sudo sudo". I keep seeing those in various places and when people learn that they trip up in environments where there's no "su" available.
Actually in this specific case I'm not sure why you wouldn't just run `sudo nixos-rebuild [...]`; there's no point in getting a root shell for a single command.
Props to those of you still slugging it out in the “Get my fav niche distro to work like a basic desktop OS” trenches. Did a lot of that in my twenties.
Props to those of you still at the mercy of your OS publishers (Windows, Ubuntu, Mac) who dictate your software, updates, how your hardware is used and general freedom. Did a lot of that in my teens.
I boot my pc, login, press win+p, type in "fir" which autocompletes to firefox and it starts firefox. And I don't think this process will change much for the rest of my life.
The alternative is a constantly changing menu UI, intrusive popups/notifications, deprecations, and a "oh wait sorry Firefox now has to be Certified from the app store", random telemetry data being sent over, strange unknown but necessary "computation" happening and what else have I missed?
I boot my pc, login, press win+p, type in "fir" which autocompletes to firefox and it starts firefox. And I don't think this process will change much for the rest of my life.
The alternative is a constantly changing menu UI, intrusive popups/notifications, deprecations, and a "oh wait sorry Firefox now has to be Certified from the app store", random telemetry data being sent over, strange unknown but necessary "computation" happening and what else have I missed?
> what else have I missed
You've missed the part where you can press win+r to launch Firefox immediately (or open if it's already launched, but inactive, or hide if it's active without any autocompletion) on any of those systems ignoring all of the menu UI nonsense, which is also workflow that can remain stable for the rest of your life (also, Firefox is also sending random telemetry data)
You've missed the part where you can press win+r to launch Firefox immediately (or open if it's already launched, but inactive, or hide if it's active without any autocompletion) on any of those systems ignoring all of the menu UI nonsense, which is also workflow that can remain stable for the rest of your life (also, Firefox is also sending random telemetry data)
All of that sounds a lot better than spending an entire afternoon getting basic graphics to work for a desktop environment
Thank you for your comment velcrovan, but I don't agree with this sentiment. I've been using Ubuntu for personal laptop for a decade, and whatever for a given corporate laptop, and was reluctant to dig into NixOS, until it clicked - the point is to have it done once, and you won't have to do it ever again! NixOS is the only one that allows so.
> the point is to have it done once, and you won't have to do it ever again! NixOS is the only one that allows so.
Until the tooling introduces a breaking change or new cooler way to do things appear and people stop supporting the old way because "everyone switched anyway". Been there, done that.
Until the tooling introduces a breaking change or new cooler way to do things appear and people stop supporting the old way because "everyone switched anyway". Been there, done that.
> Until the tooling introduces a breaking change or new cooler way to do things appear and people stop supporting the old way because "everyone switched anyway".
For those not familiar:
Nix tooling introduced flakes. The community generally likes this feature since it provides a couple of significant improvements on how nix gets used.
There was a breaking change between 2.3 and 2.4 for even the non-flake code; but, that was partly because 2.4 was a huge release. (2.3 released in 2019/09; 2.4 in 2021/11). Releases since then have been smaller and more frequent.
For those not familiar:
Nix tooling introduced flakes. The community generally likes this feature since it provides a couple of significant improvements on how nix gets used.
There was a breaking change between 2.3 and 2.4 for even the non-flake code; but, that was partly because 2.4 was a huge release. (2.3 released in 2019/09; 2.4 in 2021/11). Releases since then have been smaller and more frequent.
In that case NixOS rebuild will fail telling you exactly what to do. This is better than upgrading MacOS, where a system upgrade may break tools installed with homebrew and there is no way of knowing until _after_ the upgrade.
When you upgrade NixOS there are always warnings on anything deprecated telling you what to do.
I guessed so. So it’s not at all done once, never done again as the OP suggested but rather done once, now keep redoing something slightly different every fortnight and enjoy your constantly half-broken system. In a way, it’s reassuring to see that niche Linux distributions have changed so little in the decade since I last used one.
I only yet this once every 6 months. And the issues are resolved in minutes following the printed instructions (as opposed to crawling through arch wiki or whatever).
Most of the time the deprecations require no action on my part, I simply rather keep things tidy and make the warnings go away.
> In a way, it’s reassuring to see that niche Linux distributions have changed so little in the decade since I last used one.
You are misunderstanding what I am saying. The situation is very different. There are still Linux/Wayland/NVidia/Whatever issues, but configuring NixOS is not among them.
Most of the time the deprecations require no action on my part, I simply rather keep things tidy and make the warnings go away.
> In a way, it’s reassuring to see that niche Linux distributions have changed so little in the decade since I last used one.
You are misunderstanding what I am saying. The situation is very different. There are still Linux/Wayland/NVidia/Whatever issues, but configuring NixOS is not among them.
> Most of the time the deprecations require no action on my part, I simply rather keep things tidy and make the warnings go away.
Here to confirm that you can usually ignore those warnings for a year or more, hahaha.
Here to confirm that you can usually ignore those warnings for a year or more, hahaha.
What exactly is the point of this comment? You haven’t even tried the distro, was assumed something wrongly, and then double down on it?
> now keep redoing something slightly different every fortnight and enjoy your constantly half-broken system.
Yeah, if any of that is even remotely true then something is horribly wrong with your system.
Yeah, if any of that is even remotely true then something is horribly wrong with your system.
this is presumably why guix calls itself "an advanced packaging management system". if you don't want to futz around with that kind of thing theres always ubuntu which mostly just works and even comes prebaked with activedirectory support so you can argue with your IT department about it :)
I don't think NixOS is the only distro that has this property, what prevents someone from making a shell script that installs your applications and dotfiles? Blow away your OS install and get your set up back in one line is my experience and I don't run Nix or Guix for most of my applications
It's just impossible to have the same level of configuration with your own custom script, NixOS goes way beyond: its configuration capabilities goes from your bootloader to user-level Firefox add-ons, and you have niceties like reproductability and rollbacks.
what? none of that is impossible for me to configure with a shell script? i install my userChrome.css to firefox with it, and i havent tried the addons aspect because my firefox account syncs them for me. since i run zfs i should get rollbacks too without learning a new language and packaging theory for guix
It’s possible as in you have a Turing-complete set of tools. You would basically have to recreate something like Nix for it to properly work, and would only end up with a much worse version of it, without the huge amount of work that goes into it (both the core, but especially the “wide ranging software support” part).
a set of tools that wont fade away, its much harder to believe that
about nixlang than its for bash/dash/sh
i dont have to recreate nix to get easy customized installs, my installer script doesnt need to know or do anything about derivations, monads, flakes, etc. it just uses packages from my distro and pulls in my .config directory. what else does nix do that my script should do? the software my script installs is probably more supported than it would be on nix because its on ubuntu, one of the more commonly supported distros.
i dont have to recreate nix to get easy customized installs, my installer script doesnt need to know or do anything about derivations, monads, flakes, etc. it just uses packages from my distro and pulls in my .config directory. what else does nix do that my script should do? the software my script installs is probably more supported than it would be on nix because its on ubuntu, one of the more commonly supported distros.
> monads
Nixlang doesn't have a type system sufficient to encode monads, so you don't have to worry about it ;)
> tools that wont fade away, its much harder to believe that about nixlang than its for bash/dash/sh
Bash has been around for over 34 years, which is very respectable. But Nixlang has also already been here for more than 20.
> the software my script installs is probably more supported than it would be on nix because its on ubuntu, one of the more commonly supported distros
wat? Nix runs on Ubuntu just fine...
Nixlang doesn't have a type system sufficient to encode monads, so you don't have to worry about it ;)
> tools that wont fade away, its much harder to believe that about nixlang than its for bash/dash/sh
Bash has been around for over 34 years, which is very respectable. But Nixlang has also already been here for more than 20.
> the software my script installs is probably more supported than it would be on nix because its on ubuntu, one of the more commonly supported distros
wat? Nix runs on Ubuntu just fine...
It doesn’t have to go away when your alternative won’t work correctly in the first place and will collapse under its weight.
How do you install the userChrome.CSS automatically? As far as I know it needs to be placed in a folder containing a hash that's only generated at firefox first launch.
At some point if you want to configure everything with your own shell script it will be a nightmare to maintain, NixOS is easy to learn in comparison.
At some point if you want to configure everything with your own shell script it will be a nightmare to maintain, NixOS is easy to learn in comparison.
i just glob over *.default and *.default-release `mkdir -p chrome` and
move it there then check if my user.js has the setting that enables
legacy userchrome (via grep, (useless) cat, and pipe), and if not add
it. wouldnt guix do something similar if it managed my userChrome.css?
i am not sold on the maintainability delta between my script and a guix one, but i only use a text editor, a terminal emulator and two web browsers for 90% of my use, so maybe im just too small scale to run into the maintainability issue it's trying to solve. the main struggle i have is in making the config files, and guix would only add another layer to that.
easy to learn might be a valid consideration for me if i didn't already feel comfortable with scripts of the normal non guix variety, but the devil i know does fine.
i am not sold on the maintainability delta between my script and a guix one, but i only use a text editor, a terminal emulator and two web browsers for 90% of my use, so maybe im just too small scale to run into the maintainability issue it's trying to solve. the main struggle i have is in making the config files, and guix would only add another layer to that.
easy to learn might be a valid consideration for me if i didn't already feel comfortable with scripts of the normal non guix variety, but the devil i know does fine.
NixOS is overriding the profile name by using your username so the name is not auto-generated anymore (NixOS hates that) so it knows the user profile will always be at ~/.mozilla/firefox/USERNAME. It automatically creates a ~ /.mozilla/firefox/profiles.ini with a custom profile.
That's a nice small benefit that seems dwarfed by the increase of complexity, but maybe I am blind to my death of a million paper cuts that I've grown used to.
Maybe I'll update my script to use named instead of randomly generated profiles, though.
What does it do for multiple profiles?
Maybe I'll update my script to use named instead of randomly generated profiles, though.
What does it do for multiple profiles?
You can specify as many profiles as you want, you have a property called firefox.profiles that can be an array and you would declare as many settings you would want in it. They still need to be names though (either through a variable like an username or a name you would set yourself).
It’s increasine in complexity when you are writing shell scripts, it is not when you have a proper system in place that provides a sane abstraction/interface for defining such configurations.
Guix is a huge upfront increase of complexity for someone who already has a shell script to do the same thing.
You can generate the metadata in ~/.mozilla/firefox (installs.ini, profiles.ini) to have whatever profile dirs you want. Only if you let FF generate them itself will they have the unknown random names.
Writing a shell script to install packages, hoping it's idempotent, isn't to the level of "[do it] once, and you won't have to do it ever again!".
Installing a list of packages is relatively easy, sure.
A NixOS system configuration also takes care of settings for different services; which typically you'd edit files under /etc/ for.
The closest practical analogue to a NixOS system configuration that's popular is probably setting up your computer.
Installing a list of packages is relatively easy, sure.
A NixOS system configuration also takes care of settings for different services; which typically you'd edit files under /etc/ for.
The closest practical analogue to a NixOS system configuration that's popular is probably setting up your computer.
Copying files to /etc doesn't require Guix. Installing applications and copying their respective config files doesn't require Guix. Guix seems worse for this than a repo of config files and a shell script or makefile, because of the required extra complexity
It's possible to have a full system setup with shell scripts. The only things I'm aware of people doing are copy-pasting the "install these packages" when setting up a system.
When it comes to reliably getting a system to an expected state, shell scripts aren't a popular solution.
Nix and Guix are more complex than not using them. I'd compare that to Vim/Emacs being more complex than Notepad.
When it comes to reliably getting a system to an expected state, shell scripts aren't a popular solution.
Nix and Guix are more complex than not using them. I'd compare that to Vim/Emacs being more complex than Notepad.
My script installs configuration as well as packages. Guix is way more complex than my script, not only in part because I would need package a non zero amount of things to have it be feature complete with my shell script, and unlike your notepad vs emacs example, people don't seem to point to anything that Guix can do that my system can't, or the things they identify I do so rarely that it would be more efficient to do them manually instead of porting my system to Guix, like making containers.
Also not a popular way to configure a system? They are THE default way, that is being tried to displaced by various configuration management tooling and Guix, no?
If I wanted to sells emacs to someone on notepad I wouldn't have to resort to things as vague and hand wavy and dubious in value as reproducible'). I'd be listing features they lack. The Guix features I want I have, which is simple install of my applications and configs
You don't need Guix to copy files to /etc, you don't need it to install your applications and you can get a pretty reasonably easy custom install with a repo of config files and a script to clone and copy.
Also not a popular way to configure a system? They are THE default way, that is being tried to displaced by various configuration management tooling and Guix, no?
If I wanted to sells emacs to someone on notepad I wouldn't have to resort to things as vague and hand wavy and dubious in value as reproducible'). I'd be listing features they lack. The Guix features I want I have, which is simple install of my applications and configs
You don't need Guix to copy files to /etc, you don't need it to install your applications and you can get a pretty reasonably easy custom install with a repo of config files and a script to clone and copy.
With NixOS someone else has written that script and now I can use a DSL to configure my desktop
someone wrote a script to install only the applications I want and configure my .config files the way I do but for guix? this seems to be a conflation, i'm not producing packages for my distro which is what the equivalent guix script would be, no?
edit: and isnt shell a DSL too? one i already know in contrast with Nixlang.
edit2: and not just already know it, but also much much much less likely to fade into obscurity than nixlang... bash/dash/sh aren't ever going away
edit: and isnt shell a DSL too? one i already know in contrast with Nixlang.
edit2: and not just already know it, but also much much much less likely to fade into obscurity than nixlang... bash/dash/sh aren't ever going away
> what prevents someone from making a shell script that installs your applications and dotfiles
The reproducibility of that would not be nearly as high.
For example, if the source of those applications is apt the versions of packages would change over time.
The reproducibility of that would not be nearly as high.
For example, if the source of those applications is apt the versions of packages would change over time.
yes, i am fine with that personally and its hard for me to grok what benefits reproducibility in the guix sense would get me here
One example was "I want to run an old version of Hugo".
In the time since running the old version of hugo, enough about the system had changed:
- The OS had changed significantly (so re-running an old build didn't work). - The compiler had changed significantly (so compiling from source would have been difficult).
https://jvns.ca/blog/2023/02/28/some-notes-on-using-nix/
In the time since running the old version of hugo, enough about the system had changed:
- The OS had changed significantly (so re-running an old build didn't work). - The compiler had changed significantly (so compiling from source would have been difficult).
https://jvns.ca/blog/2023/02/28/some-notes-on-using-nix/
Great example! Managing old or multiple versions of software is actually a great usecase for Guix.
> i am fine with that personally and its hard for me to grok what benefits reproducibility in the guix sense would get me here
I read this as:
> i am fine with the lack of reproducibility of apt-update personally and its hard for me to grok what benefits reproducibility in the guix sense would get me here
To which my answer is:
Guix gets you the reproducibility benefit of not having the reproducibility harming apt-update.
Does this help answer your question or confuse things more?
I read this as:
> i am fine with the lack of reproducibility of apt-update personally and its hard for me to grok what benefits reproducibility in the guix sense would get me here
To which my answer is:
Guix gets you the reproducibility benefit of not having the reproducibility harming apt-update.
Does this help answer your question or confuse things more?
> … I don't agree with this sentiment.
Not the parent poster… I’m unclear what sentiment you’re disagreeing with: Are you inferring that velcrovan is against tinkering with niche distros?
Not the parent poster… I’m unclear what sentiment you’re disagreeing with: Are you inferring that velcrovan is against tinkering with niche distros?
I read it that way; it reads as "have fun playing with your broken, useless, toy OS". Traditionally followed by some comment about how they use a Real OS for Serious Work that definitely never breaks (conveniently skipping over the ways it breaks that they have to deal with).
Sorry, I should have included a /nosarcasm tag or something, that is definitely not how I meant it.
I still enjoy the level of sleuthing and tinkering shown in the original linked post, I just choose to spend my time/energy budget on other kinds of challenges, rather than on my personal machine’s operating system. If I had the level of free time I had in my twenties I’m sure I would still be on Linux.
I still enjoy the level of sleuthing and tinkering shown in the original linked post, I just choose to spend my time/energy budget on other kinds of challenges, rather than on my personal machine’s operating system. If I had the level of free time I had in my twenties I’m sure I would still be on Linux.
Okay, that does help to know. It's a weird position IMO (you really spend less time/energy on another OS's quirks?), but it's nice to know that it wasn't intended condescendingly.
Then the protocol changes from X to Wayland, python changes from 2 to 3, gtk changes from 2 to 4 and systemd replaces core services...
NixOS actually navigated a change from OpenRC to systemd many years ago. You didn't generally have to change your service configurations because NixOS puts a bit of abstraction between you and the service management system.
You don't actually have to switch to Wayland, you can keep using X like for the last couple decades. The python change was annoying, but it took like a decade and I'm not sure it was actually user impacting; most distros switched packages over invisibly. Same for GTK and systemd; they were annoying for tinkerers and maintainers, but would an end user actually notice?
End users can stay at old versions and old distros for as long as they like.
Most users can benefit from security updates, though. They might also (maybe) get better performance, new features and a smoother user experience.
Most users can benefit from security updates, though. They might also (maybe) get better performance, new features and a smoother user experience.
Okay? That has very little to do with anything I wrote. Xorg is maintained, python2 was maintained for a long time into 3's lifecycle, and GTK and systemd shouldn't have broken anything for users. None of this requires foregoing updates.
When I was a teenager, I guess I spent some time like that, wrangling the GNU userland into coherence on Gentoo. But after a couple years, I came out the other side, and that's why I chose to run niche distros as my main OS. I knew that whatever was disagreeable, I could swap out for something else. I knew that whatever was missing, I could package it myself.
And at some point, it really did stop being a problem. One of my biggest frustrations at work, where my only choices currently are macOS and Windows, is that they can't seem to provide me a workstation that functions reliably and predictably compared to what I've gotten used to on my 'fav niche distro'. It boggles my mind how unstable contemporary proprietary desktops are, especially when you tack on the meddling of corporate IT with obscure policy tweaks and a host of corporate spyware. I've even found hardware compatibility and integration pretty lacking on both systems compared to NixOS.
And at some point, it really did stop being a problem. One of my biggest frustrations at work, where my only choices currently are macOS and Windows, is that they can't seem to provide me a workstation that functions reliably and predictably compared to what I've gotten used to on my 'fav niche distro'. It boggles my mind how unstable contemporary proprietary desktops are, especially when you tack on the meddling of corporate IT with obscure policy tweaks and a host of corporate spyware. I've even found hardware compatibility and integration pretty lacking on both systems compared to NixOS.
One of the breaking of "what we thought for granted" things from core wayland is... there is no vblank.
This is because some modern hardware do not have such thing (in "mobile" land).
If the hardware provides the luxuary of "presentation" (~vblank) control, an application has to query the appropriate "presentation" wayland interface... namely the application must not expect this interface to be around.
You can see that in vulkan3d with its presentation queue: you post your pixels and forget about it (but there are extra presentation interface beyond the core interface like in wayland).
It through away everything many knew about rendering timing... for very good reasons, aka not planned obsolescence. This is why many are "wtf" about core wayland. Yes, we reached a point in software where innovation means removing and simplifying, not adding and complexifying.
The cherry on top: it makes the wayland core interfaces sooo much simpler, one dev can quickly have a working alternative implementation, and grow it step by step with luxuary extra interfaces.
I say that, I am still running good old native x11, because I game on elf/linux (#noproton), but the second the steam client drops its 32bits legacy code and have a working wayland backend, I start to code my own wayland compositor, probably based on the drm/vulkan one from valve deck, but in plain and simple C, or straight to x86_64 assembly (lurking on RISC-V ofc, since porting modern assembly ISAs is brutal but far from being hard).
If the hardware provides the luxuary of "presentation" (~vblank) control, an application has to query the appropriate "presentation" wayland interface... namely the application must not expect this interface to be around.
You can see that in vulkan3d with its presentation queue: you post your pixels and forget about it (but there are extra presentation interface beyond the core interface like in wayland).
It through away everything many knew about rendering timing... for very good reasons, aka not planned obsolescence. This is why many are "wtf" about core wayland. Yes, we reached a point in software where innovation means removing and simplifying, not adding and complexifying.
The cherry on top: it makes the wayland core interfaces sooo much simpler, one dev can quickly have a working alternative implementation, and grow it step by step with luxuary extra interfaces.
I say that, I am still running good old native x11, because I game on elf/linux (#noproton), but the second the steam client drops its 32bits legacy code and have a working wayland backend, I start to code my own wayland compositor, probably based on the drm/vulkan one from valve deck, but in plain and simple C, or straight to x86_64 assembly (lurking on RISC-V ofc, since porting modern assembly ISAs is brutal but far from being hard).
I game on wayland, using steam and proton/wine. Xwayland works, and wine-wayland fork is functional and in the process of being merged. What is holding you back?
None of the handful of different wayland implementations have managed to support any of the network based keyboard/mouse sharing programs like synergy/barrier/input-leap (and vice versa). This lack of functionality is a real dealbreaker for me.
Okay. I use hardware solution for that, so wasn’t aware of issues. is it related to issues with evdev?
(my hardware solution is logitech mx keys & their mouse, pair up to 3 machines at once)
(my hardware solution is logitech mx keys & their mouse, pair up to 3 machines at once)
Wait, does this work on Linux with wayland?
Why wouldn't it? It's hardware; it sends the inputs to the machine you tell it to, regardless of whether that machine is running X11 on Linux, Wayland on Linux, or Windows 3.11 on DOS (assume that someone wrote a USB mouse driver for DOS).
Wait, not even a Wayland version of x2vnc? (Since AIUI Wayland does have VNC servers.) That wouldn't take much, surely?
I have 4 computers and 7 monitors in my keyboard/mouse sharing span. Nothing vnc* is going to do it.
Well, I meant wayland-wayland, not wayland thru Xwayland. I'll keep Xwayland, and those horrible 748397438924 client libs (yeah wayland code is static/private to distributed binaries), for games still missing a wayland backend (with unity/unreal5.x/godot/etc and via libSDL[23], I wonder if that exists on modern elf/linux games unless a custom engine).
But it seems the really hard part for valve is dropping their 32bits legacy code which is hardcoded for x11 and opengl... they are adamant at keeping it.
But it seems the really hard part for valve is dropping their 32bits legacy code which is hardcoded for x11 and opengl... they are adamant at keeping it.
Pro-tip: use https://github.com/nix-community/nixpkgs-wayland if you want Nvidia support and more frequently updating versions over nixpkgs.
I've really enjoyed your articles so far.
This one took a bit of a turn - by the middle you mention that major DEs support Wayland then suddenly transition into disabling XFCE and installing Sway?
It would useful to clarify your audience at the start, and make mention that by default Gnome and KDE already automatically use Wayland if compatible (lady I checked).
This one took a bit of a turn - by the middle you mention that major DEs support Wayland then suddenly transition into disabling XFCE and installing Sway?
It would useful to clarify your audience at the start, and make mention that by default Gnome and KDE already automatically use Wayland if compatible (lady I checked).
Alas, Xfce doesn’t support Wayland yet… though it appears to be in progress: https://wiki.xfce.org/releng/wayland_roadmap
Just got around to working on my NixOS sway setup this week. Working better than I had expected!
If you want, there are dedicated HM options to use for your key bindings[1] and outputs[2] (ie for your background) instead of putting things in `extraConfig`.
[1]: https://nix-community.github.io/home-manager/options.html#op...
[2]: https://nix-community.github.io/home-manager/options.html#op...
If you want, there are dedicated HM options to use for your key bindings[1] and outputs[2] (ie for your background) instead of putting things in `extraConfig`.
[1]: https://nix-community.github.io/home-manager/options.html#op...
[2]: https://nix-community.github.io/home-manager/options.html#op...