It seems like all wine windows may be broken, although there doesn't
seem to be an easy way to allow the resizing of all wine windows without
affecting other windows. In practice this *shouldn't* matter much,
however.
wineWowPackages.stagingFull has better compatibility than waylandFull
and runs more applications without black screens. The difference between
stagingFull and wine-ge is that wine-ge doesn't crash when encountering
an error like ELFCLASS64 and usually opens windows larger and
fullscreen-like.
The reason stagingFull is preferred over wine-ge in this case is that
stagingFull is a part of nixpkgs and doesn't suffer from a black screen
bug when a hidden menu pushes the content in the window viewport down.
Additionally, although wine-ge avoids crashes in more cases, this
results in applications running that may or may not fully work, and
sometimes results in black screens where there should be graphics
instead.
This was a different wine version that let me achieve better
compatibility with Unity3D programs. Although it doesn't crash when
encountering a ELFCLASS64 error, for example, it does have other issues
like a black screen flash when opening a hidden menu (the kind that
become available with the alt key on a keyboard).
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.
