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.
Docker feels a bit too old school after being spoiled by the Nix
language and all the features that NixOS provides. Dockerfiles are not
as cool to write as Nix files and docker-compose.yml lacks many of the
reproducible benefits one gets from sticking with Nix.
Now that I have more experience with Nix, it should be possible for me
to build and run the services I want to run with Nix instead of Docker.
This should additionally reduce my personal machine's startup time,
which was already quite low with Hyprland.
As a final closing, expertise in Nix seems more useful than Docker for
my personal goals. I'd rather be able to control entire Linux systems
and their full environments with containers, virtual machines, and other
goodies than be restricted to the simplistic model that is Docker.
Specializations basically double the build time for each one added, so
requiring users to explicitly enable it means quicker build times for
those that prefer Hyprland (which is easier to configure declaratively).
Now that I've figured out how to dynamically import modules and use
those modules as outputs, the next step is to ensure that these modules
work as intended when being used by end users.
NixOS offers a built-in testing solution that enables us to conveniently
spin up virtual machines with a given configuration, then verify their
correctness through python scripting.
The lib.nix file in particular is based on Jörg Thalheim's very useful
blog post that explains how to use the built-in testing functionality
with Nix flakes, which isn't covered in official documentation.
See: https://blog.thalheim.io/2023/01/08/how-to-use-nixos-testing-framework-with-flakes/
Rainbow parentheses were traditionally buggy with the plugins I used but
nowadays there are newer plugins available that use more flexible
technologies like treesitter.
See: https://github.com/hiphish/rainbow-delimiters.nvim
Useful when wanting to have a little fun with screenshots. Seems to
affect performance of fullscreen applications since those receive some
sort of priority when there are no other visible layers on the screen.
This makes the code base more portable by *only* depending on Nix as a
dependency.
Note that the code base hasn't been migrated to nixfmt-rfc-style yet.
Having a default.nix doesn't *really* make sense now that we're dealing
with multiple nixosConfigurations, some of which might not even be in
the same flake.
Now it's possible to use the specializations in arbitrary configs. Note
that specializations do slow things down a bit so they may be disabled
by default in the future.
Fixes an issue where the base16-schemes overlay wasn't being applied
presumably due to the separate nixosModule usage.
This removes Qt theming support, so it may be better to simply overlay
base16-schemes inside the module instead.
From a pragmatic perspective this never made sense since it would be
unlikely that we'd ever want to import multiple hardware configurations
at the same time.
An alternative solution would be to let users generate their own
hardware-configuration.nix that they can use with this nix-config, or
simply have them create their own nix-config that imports this flake and
uses the outputs they want.
