There are many people in the community who are happy to help if you decide to try. However, NixOS will always work best for those who have experienced the pain points that it is trying to solve. It offers configuration as code combined with deterministic build guarantees that try very hard to also be reproducible. If the benefits don’t seem clear to you, or worth the effort, don’t be peer pressured or FOMO’d by the bandwagon.
Having said that, easy ways to trynix are
nix-shell(and family) on any distribution you are already running to get temporary access to programs- writing a
shell.nixto create a reproducible toolchain that archives/pins the software used to create some project (think art file, analysis pipeline, etc)
- writing a
- install NixOS on a VM
- use home-manager on any distribution you are already running
This is the most annoying and prevalent myth. Flakes are not opposite to channels. Flakes are a conventional schema that defines inputs (which often are channels) and outputs (which may be a nixosConfiguration defining a system), combined with a lockfile for pinning those inputs. It also comes with some tooling changeover, lock-in to git for source code management and pure evaluation by default which involves copying the project using flakes into the /nix/store before evaluation.
There are a ton of tutorials for flakes; they all work and you can just google one. In the context of a NixOS configuration, a flake configuration basically just involves adding a flake.nix file that ultimately wraps and imports the same configuration.nix that is used in the non-flakes workflow. You have to learn the same NixOS options to configure your system either way.
sidenote: there are many, many pinning methods such as npins, nixtamal, calling fetchTarball directly, etc
Yes, but your inferences from that fact don’t really hold up. NixOS is essentially a library of options that can be set to produce a bootable system image. Within a stable release, that library interface for setting options is supposed to not change. The NixOS “library” itself has a dependency on the nixpkgs “library”/package set which defines the actual software packages. These are de-facto tightly integrated as both are defined by branches within the github:NixOS/nixpkgs repo. Some packages and security backports still come into the stable channel and these can be pulled before 6 months.
Regardless of pinning strategy, if you don’t update your lockfile/path for fetchTarball, then no, nothing will update.
It isn’t clear to me what #3 is asking.
This is not a useful question to really answer because flakes can define so many different types of outputs. There is a follows mechanism for the inputs that may address some of your concerns.