Now that I have figured out how to get all the Windows applications I
previously used working under Wine (including those that didn't work in
the virtual machine after trying to manually install dependencies) there
is no reason for me to use vmware.
Using NixOS for Windows applications allows them to be used with
systemd-nspawn containers, thus achieving things like isolation, private
networks, impermanence, and more. All of this without having to maintain
a separate operating system install.
No ports need to be forwarded right now, however this is a good example
for when ports need to be forwarded from a container to the host in the
future.
Now I don't have to wait for anything to be included in nixos-unstable
and can simply merge whatever I want whenever I want. This also has the
advantage of not having to specify which input is needed to get a
package from.
Now that I am able to understand and read NixOS/nixpkgs source code, I
understand that the usage of the npm module isn't needed since I don't
configure npm at a global level.
Networks are a way to start multiple NixOS virtual machines at the same
time. Although cute, networks seem to be used more for "test scripts"
and ultimately don't support Nix flakes. This results in package
versions being outdated and the inability to use our existing
home-manager input and other flakes.
Multiple nixosConfigurations, on the other hand, enable us to setup
entire computers that don't *have* to be virtual machines, but can be
virtual machines if we want them to be. Additionally, it becomes trivial
to only run the configurations you want to run, without having to worry
about everything being tied to everything else. Finally, persistence is
optional and the resulting .qcow2 file is quite small.
Ultimately, Nix flakes are a more flexible solution to the older
nixos-build-vms command, and should be preferred over it in pretty much
all cases. To reiterate, if you're using flakes, there's no reason to
use the outdated nixos-build-vms command, which won't have the same
package versions as the ones in your flake.
This *works*, and it's possible to edit files in one virtual machine
while having those files instantly be updated in all other virtual
machines. Note that the host will also have access to the files, which
ultimately means that directory sharing is quite useful (and convenient).
This was a change to make networks somewhat usable, and it works to a
good extent, however I ultimately decided against using networks due to
their missing flake support.
This is a working example of using the modules in our existing
configuration to start a network of virtual machines with
nixos-build-vms. Note that VMs take longer to start up in this case than
nixos-rebuild build-vm, and that said VMs may lack certain functionality
(such as dynamic resolution in GNOME) that would otherwise be present
with build-vm.
Although networks are certainly cute (and I'm glad that I feel familiar
with them thanks to my better understanding of Nix), they do seem less
convenient than nixos-rebuild build-vm and don't appear to support Nix
flakes. Networks therefore seem more useful for running multiple one-off
services that couldn't otherwise be ran in a container.
Mainly a proof of concept. Eventually I'll devise an easy way to view
notes in a pretty way and edit them with neovim (likely through your
typical web framework tools).
This fixes an issue where some applications were using the default fonts
from nixpkgs instead of the fonts specified in the system configuration.
Notably, this led to the use of "TeX Gyre Heros" for body text, which
made distinguishing between i/I/l problematic at smaller font sizes.
This *works*, and the best part is I didn't have to do *anything* (besides
write this configuration file, that is).
Thanks to NixOS, it is possible to have GNOME, Plasma, Hyprland, and
whatever else you want installed on the same computer without those
desktop environments conflicting with each other. This configuration is
done in a fully reproducible and declarative setup with minimal code,
without having to modify any external files or run any imperative
commands.
This makes it possible to boot into either Hyprland (the default) or
GNOME. Having separate configurations implemented in combination with
home-manager and impermanence guarantees that desktop environments don't
conflict withe each other, so this could also be used to implement a
Plasma specialization in the future.
