It turns out that nixVersions.latest is actually 2.23.3 now and this
version conveniently doesn't have the new homeModules attribute for
flake check backported yet, so we have to downgrade to 2.22.3 anyway.
See: 0a78a55d51
`networking.firewall.checkReversePath` was being set to "loose" from
Mullvad VPN, which was causing an issue with the kernel used by the
PinePhone with Mobile NixOS.
By changing this option to `false`, we get rid of the "This kernel does
not support rpfilter" error, which seems to be inaccurate due to the
result of `sysctl -a | grep \\.rp_filter` on the phone being consistent
with the result on the laptop.
Helps prevent issues where we accidentally use an import from derivation
and cause flakes with multiple platforms to fail when running things
like `nix flake check`.
This was causing a lot of issues unfortunately presumably due to things
not working with the aarch64 PinePhone system. Random errors like
"expected string 'D'" were common and I'd rather use a separate flake to
make things easier to debug and keep evaluation times to a minimum.
Necessary since we take advantage of newer hypridle and hyprlock
modules while sticking with an older version of nixpkgs to avoid issues
with newer versions of hyprland and ironbar.
Breakage may have been influenced by a dependency but seems to occur
with various combinations of hyprland and ironbar.
- hyprland v0.39.1 + ironbar v0.14.1
- hyprland v0.39.1 + ironbar master
- hyprland master + ironbar master
Not needed since we can just reference the background directly instead.
Note that the linking actually occurs in the modules for the DEs that
add backgrounds since it isn't part of the defaults.
Unfortunately command-not-found only works for channels and doesn't have
first-class support for flakes yet, and nix-index takes forever to build
the database on slower machines, so I'd rather just disable this by
default.
This makes it easier to ensure that the system has our network settings
such as random mac addresses. This makes sense since networking in
general is related to the system.
This isn't *perfect*, but it does make it possible to share files
between the guest and the host without having to imperatively create a
directory that may or may not exist on other systems.
It may be useful to add hashedPasswordFile in the future, although from
my testing it was possible to rebuild a VM that used a cached derivation
with the old password.
Ideally your main form of authentication is through LUKS encryption or
SSH keys anyway, and this password should solely be used for sudo
purposes.
