Of the future? They’re a duplicate of what Apple was doing with software as far back as the mid 90s.

Every ounce of performance we squeeze out of our hardware is replaced with pounds of bloat like this.

It’s fine for a utility or something you’ll hardly ever need to use, but running every day software like this is a complete waste.

Nixpkgs can be used without knowing anything about nix. You can install almost anything by just running e.g.:

nix-shell -p cowsay

The requirement for that is the nix package manager but that should be easy to install. But yeah getting into Nixos with flakes and all that stuff can be hard.

the effort required to start seems significant to me, especially when we have other methods that just work.

It’s just a list of packages, and an optional flake to control the repositories (stable/unstable) and add packages from outside of the official ones.

To update everything nix related I just run:

cd ~/dotfiles/nix/ && nix flake update && home-manager switch

I’ve only included a few packages from the actual list, but you can see how simple everything is. It just took me days to get to that point because the docs are really bad.

most things I need are in the Debian repos and for other cases I get by pretty good with appimage s and flatpaks.

I use it to freshen up Debian packages. For example Debian docker is like 4 major versions behind the nix one, and it stopped being supported months ago.

Also, now that I’ve created the list from above, I can just run a single line to reinstall everything I need.

Why don’t you just install nix on debian and see

Dont know where you are getting this. Nixpkgs is a breeze to manage compared to apt repo. Also it does not matter if you are on nixos or non-nixos system, the only difference is that nix does not take care of services on its own. What kind of docs do you miss? Nix has its own extensive nix docs page, and for packaging you also have nixpkgs documentation page - also official and not much related to nixos itself. Also nix has quite good man pages.

As a largely non-technical linux enjoyer I have such a hard time understanding why people hate systemd so much. If I switched to a distro that uses another init system would my experience be better?

Like I get that the complaint is partially the philosophy, but it sounds like you also have problems with it in practice and I just can’t really relate to that. I dunno, maybe I just wouldn’t notice if there are problems happening with how my init system is working 🤷

Guix System can boot into a backup of the system before the last update, for example, but that advantage doesn’t exist on, say, Debian.

Yeah, why would I ever want to have bleeding edge userland packages on Debian? Nobody needs something like that or the option to rollback the entire update or pin specific versions of packages…

Also, can we agree to not recommend these systems to new users for the time being?

Did anyone do it in this thread? OP is literally just asking about a list of packages to home-manage. Beginners can most certainly handle it if they don’t need a gui to update their system.

You can do rollbacks if you’re using something like home-manager on a foreign distribution. It’s just a bit more janky admittedly.

Yeah, if it wasn’t for my niche needs and desires of using my SteamDeck without touching the system partition, I probably wouldn’t have messed with Nix because of how much of a confusing mess of modes and switches there are, and I’ve used terminal based package managers for years. It’s very far from the simple “it just works” of Flatpaks.

It’s cause you’re not actually supposed to use nix-env: https://stop-using-nix-env.privatevoid.net/

You’re actually supposed to be using nix search nixpkgs#packagename to search and nix profile install nixpkgs#packagename to install.

However, to use both of those, you need to have the “experimental” (not really though, most of the community uses them) features of nix-command and nix flakes enabled, which they aren’t by default.

And of course, nowhere on the main documentation did I find any if that, I only found it via the pain of using it wrong, and forum posts.

Nix’s documentation is horrific. I’ve had situations where I only got help via discord…

By not being a universal packaging format. It uses your system libraries, which completely eliminates the main reason devs are pushing for things like Flatpak, Snap, or Appimage.

From what I gather it goes something like this:

• every package is assigned a hash
• every package lists their dependencies through their hashes
• different versions of packages have different hashes
• when you launch an application it creates an environment with all its dependencies, this means that two applications that both use the same library at the same version share that library. However if they both require the same lib but not the same version of that lib they don’t share it.

Which solves DLL hell as far as i understand it.

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.

Inate complexity that keeps moving as they introduce things like flakes.

Flakes solve the problem of reproducibility for which nixpkgs (or other external input) revision to use (e.g. in a software project). The main thing they bring is a npm-like lock file and a predictable interface. You don’t have to use them if you don’t want that.

Its a declarative configuration management system as package manager.

No it isn’t. That’s NixOS, which is another thing built on top of Nix and nixpkgs. nixpkgs is first and foremost a package collection.

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.

Home Manager would like a word.

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

Did OP mention nixos at some point?

git clone --depth 1 will clone a git repo without older stuff. Without this, the nixpkgs git repo is like 13-14 GB, but with a depth of 1, it’s only 200 mb.

If you maintain upstream software and do not have an interest in learning and using Nix, please don’t put the burden of packaging software in Nix onto yourself. Nobody in their right mind would expect you to package anything for a dozen distros; that’s not how distros are supposed to work.

Leave it to someone who is interested to package your software in Nixpkgs. Your “job” is to make your software better and provide a sane way to build your software that packagers can rely on (i.e. no assumptions where things are or are supposed to go, document your dependencies and build processes).

If you do want to go the extra mile, offer your help in assisting packaging in the appropriate channels. You know the technical details of your software and Nix users how Nix packaging works but the reverse mostly isn’t true, so cross-pollination can be super helpful here.
Even just things like testing that your software works as you expect when the packaging is touched in some way (i.e. an update) is incredibly helpful. (If saw a package update PR with the upstream maintainer’s approval stating that it works as they expect, I’d merge immediately.)

If packaging for Nix is a burden for you, please just open an issue on Nixpkgs with links to your packaging/build documentation and let someone else do it for you.
As a Nixpkgs committer, I’d much rather have someone invested in Nix build and maintain a package than an upstream maintainer who somehow feels obligated to do so but has no experience or actual interest as the former is more likely to produce good code and keep maintaining the package.