Very good explanation. It's an often overlooked property of NixOS and why I often feel like Nix on other systems is an okay way to get packages but you're missing out on all the good stuff you get through the modules, like losing 95% of what makes the concept good.
I don't think NixOS is the best possible solution to the problem, but it's the only original distribution that even tries to tackle it instead of just working around it.
Another aspect I like about Nix compared to what I understand from Ansible (which I used a bit but not much) is that your configuration describes your system without any hidden state. Yes, you only get your dependencies through full evaluation, but what I mean is this: Let's say you install something on a system, i.e. you add it to your list of packages, which you later remove. To my knowledge, Ansible won't remove the package if not explicitly asked. However, if you explicitly tell Ansible to not have it installed, what happens if that package is later introduced as a dependency?
Ansible will always operate on a stateful system, which is kind of the combination of what others have already mentioned – it's (EDIT: it being Nix) idempotent and there's no hidden state that will break something down the way.
It's in the release notes, you add a Wayland driver to your prefix via registry entry and then unset DISPLAY before starting wine.
https://gitlab.winehq.org/wine/wine/-/releases/wine-9.0
The Wayland driver is not yet enabled by default. It can be enabled through the HKCU\Software\Wine\Drivers registry key by running:
wine reg.exe add HKCU\Software\Wine\Drivers /v Graphics /d x11,wayland
and then making sure that the DISPLAY environment variable is unset.
Note that the registry entry is per prefix.
I'm on 9.0 staging and can use wine with Wayland, but not everything works, window bars etc look somewhat off and some games don't start at all, like Stardew Valley. Other games I tried failed to hide the cursor. Others worked just fine.
You can even use cp of I recall correctly, dd allows to tune some parameters but it's not strictly necessary.
A rather tame and boring release, which is perfectly fine after the bomb that was 9.0
I meant that just because I don't know about it doesn't mean that it isn't possible.
They cover a few things -- most notably they replace channels, which are imperative.
True. I never considered channels imperative, but rather a purity issue. But I guess this is a matter of perspective.
Unless I'm way off, you can also install user software through flakes if you add them as inputs.
I don't know about this, but that doesn't mean anything.
You can also pull a repo and 'nix run .#software' from the command-line, without entering a shell.
True, though this by default only runs the default binary, and you're probably in a shell anyways, so it doesn't save that much. Also that output is, to my knowledge, not protected by garbage collection. But my knowledge of any imperative stuff is minimal, so I don't know if that's the case there.
I don't think flakes can do much more declarative than "legacy" nix, rather they increase reproducibility and purity. Also their tooling doesn't offer imperative stuff by default, but I'm not sure they cover use cases previously solved imperatively. E.g. I don't think you can install user software through a flake. Sure you can create shells with software available, but that is also possible without flakes.
Maybe my understanding here is wrong though.
NixOS itself by default isn't fully declarative anyways, nix-env for example is imperative and very comparable to flatpak regarding applications.
I welcome the efforts to move away from all imperative bits in NixOS though. My point was rather not to dismiss an article on NixOS for mentioning flatpaks.
They're not that different from the classic nix files. Their main difference is that their inputs are always well-defined (as opposed to a channels registry, i.e. you can get totally different systems by reapplying a configuration when you change channels which doesn't change your nix file at all). A configuration is always exactly described by a flake.nix and flake.lock.
I mean there is more to it, but this is the primary motivation. What you would normally put into use case specific nix files goes into a flake's output section. The stuff in your input sections is what you can use in there.
Or you can add specialisations, which to be fair might require a reboot (system accounts might change during specialisations switch which will confuse the script trying to reload services for the now non-existent user) but it is how I have multiple DEs installed without their applications flooding the other ones, each with their own login manager (SDDM for plasma, gdm for gnome, greetd for sway).