I thought so too but learned recently that Guix system is nix under the hood, basically translates everything, so it's more than a conceptual fork though obviously some more work went into it than your average Ubuntu fork.
It uses low-level mechanisms from the Nix package manager, but packages are defined as native Guile modules, using extensions to the Scheme language—which makes it nicely hackable.
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).
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.
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.
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.
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.
I mean why would you be fully against flatpak? I use NixOS without it and always packaged natively on Arch, but especially when upstream offers flatpak, it makes sense to enable it. Keeps the user-facing programs up to date and somewhat sandboxed while you can have a stable release beneath it. Especially if the system's actual users aren't that tech-savvy.
Stuff on unstable tends to break, especially electron-dependent derivations. Stable doesn't always have the latest and greatest. Flatpak seems like a good compromise for desktop applications in some cases.
Depends on the case. A script operating on stuff in its subdirectories will probably be better with a relative path, especially if they get moved somewhere. Same logic goes for symbolic links.
This is called string manipulation. ## deletes the longest match from the beginning, so it deletes everything to the last slash, as the asterisk expands as far as possible. If you wanted the directory the file is in using this method, you'd use ${file%/*}. This deletes the shortest match from the end. You also have the dedicated commands basename and dirname for this.
Can't comment
I guess this works as long as you get exactly one match.
People switching nowadays have it so easy lol. When I switched, you'd still have to configure ALSA or OSS, tweak xorg.conf, use Nvidia because AMD was just not working (I did try and dual boot Linux before when ATI still existed but didn't fully switch), DXVK didn't exist, Vulkan didn't exist and WINE was still pre-1.0. And all this during a time when Microsoft had what some people consider the best version of Windows.
I don't really miss those times. And I know that it was even less convenient before. I also had a copy of SUSE Linux 9.0 or something from a family friend who ordered these from SUSE. And Mandrake I tried very briefly. But I wasn't really computer literate enough to teach me all that stuff myself so I consider my Linux journey starting in 2007 when I ordered a new PC and decided not to install Windows on it so that I wouldn't have that alternative in case something doesn't work.
Also lizard loses to both rock and scissors, so it was completely unviable until the invention of paper, and it's only balanced when Spock is born.