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.
Note that we will continue to use nixpkgs-fmt for the time being here
since nixfmt-rfc-style breaks string syntax highlighting and comments
like `/* this */` get turned into `# this`.
The conversion from lisp-like formatting to something else in flake.nix
is a bit unfortunate, but I'd rather have a singular style for the
entire code base to make things easier.
This increases boot times quite a bit so I'd rather use tmpfs as /tmp
where possible. Note that this defaults to cleaning /tmp anyway since
I'd rather clean /tmp than not do so at all.
For future reference, the message that gets shown is the following:
"A start job is running for Create Volatile Files and Directories"
This change makes it possible to use this nix-config in all the
different ways imaginable (containers, bare metal, tests, and as a
separate flake input) *without* running into infinite recursion
issues with self.
It does this by using a trick similar to JavaScript in which
`var self = this;`, thus enabling the usage of "this" (or self, in
Nix's case) where it wouldn't otherwise be possible.
Note that this *only* works if the input for this repository is named
nix-config. This makes it impractical to combine with multiple
configurations that employ the same strategy.
Now it's possible to use whatever username you want for your system. The
default value of "user" is good if you're concerned about information
disclosure attacks through things like the username being visible in
logs or other output.
These options are pretty important so it'd be cool to be able to change
them. Current strategy is to assume that configuration through the
module is preferred over overriding the NixOS option directly.
This seems like it could fit with the hardware module as well, however
time will tell if we're able to keep this in system when importing it
into containers and virtual machines.
Note that boot.loader.efi.canTouchEfiVariables gets set to true during
the nixos-install process, so it should be okay to keep here.
Usually one would want to define all of these options at the same time,
so it doesn't make sense to require importing several different modules.
For values that aren't needed, users can either override the configuration
in their own module or use an option that has been written upstream for the
module.
