Nix is a bit of a middle ground. Each package has a specific set of dependency version. It calculates the hash of each dependency and compares it to those that you have installed. If it is installed, it uses that, if it isn’t, it installs it. This means that packages can have different versions and dependency hell is impossible, whilst also reusing existing dependencies if they’re the exact same.

Well the issue for me is internet speed, yesterday night I had to leave my pc on for two hours to update my flatpaks, I don’t even have that many of them, but the updates were mostly drivers and runtimes.

I can reassure you that it does not encroach on anything the “host” distro package manager does and does not cause conflicts with it.

At runtime, it only ever touches things in `/nix; it’s self-contained.

The only time Nix needs to interact with the host distro in any way is during install where it must place a little glue in your system configuration for things like PATH, bash completions or the nix-daemon to work as expected.

deleted by creator

The nix package manager can be used on any os and doesn’t require usage of the nix programming language…

Note that Nix is not a full-blown programming language, it’s an expression language. The end result of an expression is always data and side-effects are not possible; you can’t do network requests or write to arbitrary files. There is no such thing as a variable in Nix either, only constants. You can think of it like JSON with (pure) functions and an additional data type (~package).

From a user perspective, it’s really not very different from any of the other 100s of weird configuration syntaxes you’ve surely come across in your Linux journey.

My nixos-config is a bit more complex because I like to reap the benefits that abstraction but here’s a simpler section that is representative of how a typical NixOS desktop config would look like:

https://github.com/Atemu/nixos-config/blob/ee2d85dc3665ae3cad463a3eb132f806651fe436/modules/desktop/module.nix#L16-L77

(Though note that even this is slightly more complex than what you’d do when starting out; ignore the LADSPA_PATH and tablet conditional for now.)

It is a whole ecosystem:

• Nix the package manager
• Nix the functional language used to declare packages and configurations
• NixOS that has the package manager and a system configuration in the functional language
• Home Manager, which provides a configuration on the user level and can be used on NixOS as well as other distros and MacOS

To start out it’s completely fine to just install Nix the package manager on a regular distro or on MacOS and use the nix-env command to install some packages. It will automatically use nixpkgs and use working dependencies for each package, whilst also checking if the depency is already installed to avoid installing the same one twice. This is pretty much the same thing as using Flatpak

Flakes explanation:

The Nix package manager has channels to manage package repos. It works like package managers on other distros where you simply have a list of urls to pull packages from, with Nix it would just be the nixpkgs release either a version number for stable or unstable for the unstable rolling release. Any time you install through the package manager or the config in NixOS, it will get the packages from the channel.

The problem is that the channels aren’t very reproducible. The repos get updates regularly, especially unstable which updates even faster than Arch. Channels don’t provide an easy way to specify a single commit of the repo, except for entering a url with the commit version in it. For stuff like a shell.nix, you’d need to either import nixpkgs from the system’s channel or import the url of nixpkgs with a specific commit ID.

Flakes is a feature that for some reason is still experimental after years, but many are already using it. It works like manifest.json and package.lock in a JavaScript project. You have a directory or git repo with a flake.nix file in which you specify your external dependencies like the nixpkgs release in the “inputs” section and your outputs in the “outputs” section, like a NixOS/Home Manager configuration, a shell or a package. Then when you use an output, Nix pulls the inputs and builds the output, it then generates a flake.lock file that contains all the inputs with their specific commit and hash. Now if you use an output again later with the same flake.lock, it will still use the exact same version as last time and should generate the exact same outputs. You just run nix flake update to generate a new flake.lock with new dependencies. You can’t use flakes with nix-env simply because installing packages imperatively without a config file defeats the point of reproducibility with flakes.

Flake example with Home Manager:

My Flake Repo/
├── flake.nix - nixpkgs input and home manager configuration output
├── flake.lock - generated by nix
└── home.nix - home manager config import from flake.nix

Here the home.nix file contains the config with the list of packages to install as well as configuration options for those programs. The flake.nix contains the nixpkgs input and a homeManagerConfigurations output that import the home.nix. You can run home manager switch --flake ./My Flake Repo to use that config from the flake. To update run nix flake update.

you have to set up the XDG_DATA_DIRS environment variable to take into account ~/.nix-profile/share the desktop icons will only appear after a relogin though.