Distro agnostic packages like flatpaks and appimages have become extremely popular over the past few years, yet they seem to get a lot of dirt thrown on them because they are super bloated (since they bring all their dependencies with them).
NixPkgs are also distro agnostic, but they are about as light as regular system packages (.deb/.rpm/.PKG) all the while having an impressive 80 000 packages in their repos.
I don’t get why more people aren’t using them, sure they do need some tweaking but so do flatpaks, my main theory is that there are no graphical installer for them and the CLI installer is lacking (no progress bar, no ETA, strange syntax) I’m also scared that there is a downside to them I dont know about.
Inate complexity that keeps moving as they introduce things like flakes.
Its a declarative configuration management system as package manager. Thats a lot more to handle off the bat than normal linux + flatpak.
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.nixHere 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 Repoto use that config from the flake. To update runnix flake update.I appreciate the breakdown, but you’ve basically made my point for me.
The above, with its many advantages, versus:
Sudo apt install X Y Z G F P -y
Simple, clean, gets it done for near anyone.
Sudo apt install X Y Z G F P -y
Debian 12 came out last June. In December the version of docker that’s shipped by Debian stopped being supported, and is now like 4 major releases behind nix. Debian won’t update it for at least a year and a half unless there’s some major security patch.
Besides that, when Debian 13 gets released and I reinstall, I can just clone my dotfiles and use a single line to reinstall all of the packages I need. All of the packages are in a single list, and so there’s no more need to run health checks because I forgot to reinstall some random editor dependency for a language I use once a year. If I added it to the list it’s going to be on every machine running that list.
Like most complex things in life, if you devout time to it and engage with it deeply you gain an advantage over a simplier version of the same thing. The question we all have to ask ourselves is “is this worth it?”
I’d say in your specific “docker centric while using debain” use case, sure. Most people who use linux as a daily driver? Maybe not.
Like most complex things in life, if you devout time to it and engage with it deeply you gain an advantage over a simplier version of the same thing.
What are you talking about?
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 switchSure, it’s slightly more complex than clicking a button in Discover, but it’s not rocket science.
I’d say in your specific “docker centric while using debain” use case, sure. Most people who use linux as a daily driver? Maybe not.
I’d say you’ve never seriously used a stable distro if you don’t realize how common issues like that are.
I’m pretty certain the current hype for stable distros is fueled primarily by the growth of tools like flatpak. So, since linux users require an additional PM, the real question is: Are you using linux only for browsing and the occasional text editing?
Not to mention that the most common problems it solves can be solved by installing packages from source in a prefix like /opt or ~/.apps and symlinking them from a central place like /opt/.system or ~/.apps/.system or whatever.
I had a bash script 15 years ago that automated most of this. (Which gradually fell out of use when Arch and makepkg came along, but I digress.)
I can’t help but feel like nix is a solution looking for a problem and solving it in a way that appeals to a certain kind of hobbyist but not so much to any practical purposes. Otherwise it would have been adopted more widely by now.
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.
Was curious myself don’t like flatpaks & appimages much, but from a quick googling, they don’t seem to integrate with the desktop so you need to launch them from terminal? That is a deal breaker for me at least.
you have to set up the
XDG_DATA_DIRSenvironment variable to take into account~/.nix-profile/sharethe desktop icons will only appear after a relogin though.It’s automatically set up alongside PATH
I’m already using more than I would like to they are complete TRASH.
NixOS sounds amazing in some regards, but I’m not really interested in learning a whole programming language for it… I have enough to do already.
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?
No, but the top-level comment you’re replying to is a perfect response for the OP because of what it demonstrates.
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:
(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.)
Flatpaks are much better than AppImages because they don’t bring in all of their dependencies, they inherit them from a runtime.
It’s about Nixpkg, not Appimage.
it’s the way Nix works too
Yeah so I don’t know why OP is using that argument
Could you elaborate? I was under the impression that NixPkgs stored the hash of their dependencies and when launched create an environment to use them, this way two apps can share the same library when the version is the same.
Nix doesn’t do anything special when launched.
The way it works is very simple - instead of e.g. /usr/lib/libssl.so.3, binaries use /nix/store/openssl-…/lib/libssl.so.3. This is done at build time, not runtime.
Steam Deck is using Flatpaks so…
You can also use nixpkgs and AppImages on SteamOS.
Nix packages are a pain to manage on non-nix systems and basically all documentation exists for nixos, not nixpkgs.
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.
I’m not saying it’s not easy, I’m saying there’s not really any documentation about it.
I had to figure out for myself that I needed to do symlinks to get menu entries for nix packages
I had to figure out for myself that I needed to do symlinks to get menu entries for nix packages
Home-manager: I didn’t have to touch anything to get PATH and XDG working, it’s all automated.
And where in the documentation is that?
Nix docs are hot garbage, but I’m pretty sure it tells you to reboot when you finish installing either nix or home-manager. It didn’t appear to me in a dream.
to clarify, i was talking about home-manager
But you don’t get hardware graphics acceleration unless you use nixgl, and if you want to integrate it into home manager that breaks XDG entries, which I never figured out.
Also, you are illustrating the point of the commenter you replied to: nowhere on the official docs does it recommend home manager for non nixos systems, at least not when i was scrolling through them. I learned about home manager, nixgl, and the like via forum posts, either by finding them via a web search, or by asking myself.
For example, I only found code to integrate home manager with nixgl on the nixos discourse.
But you don’t get hardware graphics acceleration unless you use nixgl, and if you want to integrate it into home manager that breaks XDG entries, which I never figured out.
Thanks, I didn’t know that.
Also, you are illustrating the point of the commenter you replied to
Oh yeah, this is a part of my reply to the OP:
The documentation is abysmal. I spent days trying to figure out how to use nix as a declarative package manager before I accidentally came across home-manager. Even the manual leads you down the wrong path. A quick start guide with a few examples for home-manager and flakes, and a few basic commands, would’ve had me going in 5 minutes. That problem is made worse by the fact that almost all sources of info focus on nixos instead.
For example, I only found code to integrate home manager with nixgl on the nixos discourse.
Could you please share some examples? I tried searching the forum for it, but no luck.
Did some searching, also can’t find the original forum post lol.
https://github.com/nix-community/nixGL/issues/114#issuecomment-1585323281
and this: https://pmiddend.github.io/posts/nixgl-on-ubuntu/
The latter looks like what I originally used, but what I originally used broke the generated application menu entries.
Because nixPKGs have the same Single-Source of Truth wrecking problems as flatpaks and appimages and all that junk.
There’s only so much room in the ecosystem for best-practice-violating product, and systemd takes up a lot of that. And until systemd collapses under the weight of doing a thousand things poorly for all the wrong reasons and delivering on none of its brochure features, the other entrants have to wait outside.
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 🤷
Because it has abominable documentation. Some tools built on top of nix on the other hand have stellar documentation (devenv and jetbox come to mind). The tools even try hard to hide nix because they know it’s a goddamn nightmare for beginners to use it.
The CLI is a mess due to the indecisiveness of the nix maintainers whether they want flakes or not. So much so that the official manual doesn’t use flakes, but many guides on the internet immediately go into
nix dev#yadadadawhich leaves beginners and mid-term users alike very confused.Another point is that graphical applications can’t use OpenGL without dirty hacks like nixgl. Not only that, installing GUI applications using nix doesn’t make them show up in your desktop environment (start menu, finder, whatever). No, you need to either manually create
.desktopfiles or install another tool likehome-managerto have them show (and not work properly because of OpenGL).To top it off, unless you know better, it’s command-line only. SnowflakeOS is building GUI tools around nix, but they aren’t like say Discover or the Gnome Appstore: you can’t install the GUI and have everything working - no, you need to figure everything out.
In short,
nixis absolutely nowhere close for desktop user adoption, much less mainstream linux adoption (dev, sysadmin, tester, or whatever other technical role exists).Flakes confuse me.
Guides online say “oh yeah just do this, it’s easy” and don’t mention flakes at all.
So I try the thing and it says ARE YOU FUCKING SURE, YOU IDIOT, YOU ABSOLUTE MORON, YOU CAN’T DO ANYTHING WITHOUT ENABLING FLAKES AND YOU HAVEN’T DONE THAT SO YOU CLEARLY DON’T DESERVE NICE THINGS but like, is there just no non-flakes version of that thing, what’s the point of having an option that’s not enabled by default if you can’t do anything without it on@moonpiedumplings@programming.dev shares my pain and also explained what I was doing wrong:
https://programming.dev/comment/7537131Flakes is still experimental. NixOS devs takes a bunch of time to release that. So most experienced users have enabled Flakes since years. Two different systems are available, which does not help ease of learning.
Right but like “be able to do anything” requires you to have Flakes enabled
I maintain some software, and Nix is by far the hardest to deal with. To package config files are relatively complex, and to submit a package you have to download the entire Nix repo, which is huge. Getting a package to build correctly can be a challenge.
It’s a pretty large ask for software contributors, who may have to iteract with a half dozen different distros. Now, you could say, leave it to the distro people to do the packaging, but it remains a barrier for entry and is by nature exclusive.
I don’t use NixOS, so I have little motivation to stay conversant with Nix and, frankly, it’s so demanding I don’t bother anymore. I can make RPM, deb, and aur packages trivially, and without having to hold Gb of some package repo (which I otherwise don’t use) on my disk.
git clone --depth 1will 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.Sure. My point is that it’s trivial to make and test packages for many distributions; it is harder to do so for Nix. It tends to get your software out there and used faster if you bootstrap the packaging - immediately, if you have an AUR account.
IMHO, Nix is unreasonably harder. There are frequently small projects that don’t get packaged for most distros. When I encounter these, I have a couple of options:
- Submit a packaging request. Hope someone is willing to accept it. Wait until it is packaged.
- Install it from source and let it pollute the core system. Hope this causes no issues. Manually track and maintain the installation. If lucky, the software lets itself be installed somewhere non-standard, in which case I can use stow and keep things a bit cleaner.
- Throw together a package for it and let my distro manage the installation.
The third option is preferrable to the others, for a variety of reasons, and it’s easy on most distros. On Arch, I might submit the package to AUR, but I’ll often just make a -git package and install it locally.
It tends to get your software out there and used faster if you bootstrap the packaging
It’s fine to provide some sort of “official” binary package in some common format such as a Flatpak, Appimage or even just a plain old tarball but trying to package something for many different distros is insanity IMHO.
My point is that it’s trivial to make and test packages for many distributions; it is harder to do so for Nix.
it’s easy on most distros
It all depends on what you’re used to and how cursed the project’s build process is.
For sane build systems, I find it much easier to package for Nix now that I know its intricacies. I wouldn’t want to go back to weirdly sourced bash scripts without proper structured data types or any sort of abstractions or mechanism for extremely common patterns.On Arch, I might submit the package to AUR, but I’ll often just make a -git package and install it locally.
It’s the same for NixOS. When I encounter something that somehow isn’t packaged in Nixpkgs yet, I usually start out by simply packaging it in my local nixpkgs checkout.
There are handy tools to generate the little boilerplate there is and, if the package uses a reasonably standard build system, it usually only takes adding the dependencies and one or two tweaks to have a working package that is then also ready for submission to upstream Nixpkgs.
the aur has everything I need
For me personally, I just haven’t taken any steps into the nix environment. Seems rather complex, setting up those nix files and stuff.
I use Debian on servers and LMDE on my PC, most things I need are in the Debian repos and for other cases I get by pretty good with appimage s and flatpaks. Installing is just a simple command and me happy.
Nixpkgs are probably easy too, I assume. I know a lot of people really like nix, but the effort required to start seems significant to me, especially when we have other methods that just work.
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 switchI’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.
Nixpkgs can be used without knowing anything about nix. You can install almost anything by just running e.g.:
nix-shell -p cowsayThe 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.
So I can in theory just do
apt install nix-shell(or whatever), do something likenix-shell -p curland thencurljust works?Pretty much, yes. Although most of the guides install nix via curl. You can find the recommended installation procedure on the official nix website.
What I’m right now also realizing is that i switched things up.
nix-shell -p curlcreates a shell with the curl command temporarily available. If you exit this shell it’s gone. I use this all the time if if i don’t want to pollute my system with programs I only use once. If you want to permanently install something you have to usenix-env -iA nixpkgs.curl. But don’t take my words for granted, since I have never tested this on a non-nixos machine.Note: You can also see how to install something by clicking on the package title in the nixpkgs repo.
Why don’t you just install nix on debian and see
How does it solve the problem of dependencies without becoming bloated?
To be more clear, it uses a weird combination of your system libraries, installing its own libraries into your system on its own without informing your primary package manager, and using some specific library versions separate from your system libraries for some apps.
If you want to call that more “elegant” than other solutions… Well, I can’t tell you how to feel about something. It still doesn’t actually solve the problem that universal package formats are trying to solve unless the package dev explicitly requires so many specific library versions that the whole thing just ends up being an AppImage with extra steps though.
it uses a weird combination of your system libraries, installing its own libraries into your system on its own without informing your primary package manager, and using some specific library versions separate from your system libraries for some apps.
That is not at all true.
There is one explicit case where “system libraries” are used by Nix programs and that is graphics drivers. This is not done outside of NixOS as it does not trivially work there; it’s still an open problem. We can discuss about the reasons for this impurity’s existance and its intricacies but all that is important here that this impurity is the sole exception, not the norm.
Apart from that, Nix will never under any circumstances load (much less modify) libraries of any kind from any global path; system-controlled, user-controlled or otherwise. That’d be contrary to the fundamental principles of Nix.
It will always use “specific library versions separate from your system libraries” aka. the explicitly and exhaustively precisely declared dependencies in the Nix store. That’s the whole point of it.
I’d recommend you read up on Nix again and revise your opinion once you understand what it actually does because it’s clear that whatever source you had for information on Nix was entirely wrong.
The packager always should “explicitly require” what are the dependencies in a Nix package… it’s not like it’s a choice, if there are missing dependencies then that’d be a bug.
If the package is not declaring its dependencies properly then it might not run properly in NixOS, since there are no “system libraries” in that OS other than the ones that were installed from Nix packages.
And one of its advantages over AppImages is that instead of bundling everything together causing redundancies and inefficient use of resources, you actually have shared libraries with Nix (not the system ones, but Nix dependencies). If you have multiple AppImages that bundle the same libraries you can end up having the exact same version of the library installed multiple times (or loaded in memory, when running). Appimages do not scale, you would be wasting a lot of resources if you were to make heavy use of them, whereas with Nix you can run an entire OS built with Nix packages.
deleted by creator
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.
My guess would be that it’s because Flatpaks are easy. You have a handy GUI tool often pre installed that includes search and one-click install.
If you want something lower level, Arch users have the AUR, and others may actually do that horrifying
curl https://... | shpattern.Nix pancakes on the other hand… I have no idea how to use them and generally assume it’s the thing NixOS uses. Since I don’t use NixOS, I’ve never given them a second thought.
yeah, everybody should use them. I usually write my own kernel mods tailored for my hardware and certain needs, I don’t know why not everyone is doing that. admittedly is a bit janky maintaining a separate kernel fork, but you get used to it, everyone should do it
