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.
the aur has everything I need
How does it solve the problem of dependencies without becoming bloated?
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.
Huh? as far as I know it has its own libraries and dependency system. What do you mean?
It doesn’t use the system libraries, unless the system on question is NixOS. It still provides its own dependencies. Arguably in a more elegant and less wasteful manner, but they are still distinct from the ones used by the rest of the system.
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.
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.
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.
deleted by creator
it’s the way Nix works too
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.
deleted by creator
I’m already using more than I would like to they are complete TRASH.
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.
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.
Say, did nix take inspiration from. npm? That would certainly explain a lot of things…
Nix is 7 years older than npm :P
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 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.
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.
Nix is the vim of package management but without good documentation. So it’s incredibly powerful and useful once you get into it, but imagine trying to learn vim without any docs or guidance. Vim has a steep learning curve with good documentation, YouTube tutorials, blog posts, and forum guides.
Nix doesn’t really have a wealth of that.
That’s nix package management and nixos in a nutshell.
Steam Deck is using Flatpaks so…
You can also use nixpkgs and AppImages on SteamOS.
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://... | sh
pattern.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.
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#yadadada
which 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
.desktop
files or install another tool likehome-manager
to 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,
nix
is 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 onFlakes 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.
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.
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.
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.
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.
TL:DR; they’re the package managers of the future, and I shill for them, but they’re still buggy in some areas.
Guix and Nix user here. For all I can shill about store-based file hierarchy, ephemeral environment isn’t perfect yet in both of these apps, at least from a GUI application perspective. It’s a bug that I’ve found in Nix, but that should also reflect in Guix. Basically, what’s happening here is that due to some impurity in the environment, it uses libraries from the system instead, and apps may stop working. This is a very serious issue, and is directly related to what you’re talking about. This problem hides itself when using GuixSD in Guix or NixOS in Nix, but in other foreign distro that have dated libraries, it is very much visible, and you’ll be forced to use outdated channels.
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.
What do you mean? Apple doesn’t have a package manager at all. Brew is a fucking mess that takes ages to do anything.
There’s no bloat, nix are system packages
Having every application load their own version of a library into memory is bloat.
They don’t, they share the same library version if they were built against it.
Lots of software won’t even work if the library version is different, so it’s a benefit, not a downside
Right. That’s why you build the software against a common library version.
In which case it’s shared in NixOS and there’s no bloat
If there’s no bloat why is there a garbage collector?
The garbage collector removes all packages/derivations that are not (transitively) used any more. So it is similar to apt-get autoremove. I don’t think that classifies as bloat. You could just regularly run the garbage collector.
Rollback, reproducibility, safety.
Would you call btrfs snapshots or some other backup system bloat?
It actually serves an important purpose for the user. Meanwhile apt is leaving around random libraries and man pages you need to autoremove.
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 🤷
I use NixOS on my personal machine and nixpkgs on my work Ubuntu (22.04 LTS). In the absence of NixOS I would not be using it: it somehow breaks all the file (open, save, etc.) windows, causing any app that tries to open one to crash (particularly annoying for browsers).
Not to mention the wrapGL issue.
It needs more polish on “genericlinux”. I did previously use it on MacOS, and it did make MacOS almost bearable - definitely years ahead of brew.
I’m going to go against the grain and say that the Nix and Guix package managers are very good, but they really belong in their respective distros where they’re a core part of the system. That’d be Guix System for Guix and NixOS for Nix.
They may have advantages for a foreign distro too, but they are lesser (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.
Also, can we agree to not recommend these systems to new users for the time being? While they’re very powerful, they’re absolutely designed for power users, and until they’re more polished and they have fancy GUIs and stuff for installation and package management, I think it’d be best to keep recommending normal distros like Debian for now.
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.
No, nobody did mention it, I was just making a side-point.
I also said there are advantages to Guix/Nix on foreign distros.
You can do rollbacks if you’re using something like home-manager on a foreign distribution. It’s just a bit more janky admittedly.
-
As you can see from the state of this thread, people see nix or nixpkgs but read nixos. There’s no momentum from the community to push it as an extra package manager, while every thread is spammed with nixos.
-
No gui integrations for casuals. For example Discover integrates flatpaks and snaps, but for nix you need to use the terminal.
-
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.
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.
Imagine this: a quickstart script to install nix and home-manager, and generate an example home.nix and it’s flake. If those files included a few comments on basic usage and what commands to run in order to install and update everything, I legit wouldn’t have had to google anything.
Literally: here’s a list, this is how you add packages to it, this is how you ensure everything on it is installed to the newest possible version, enjoy!
It’s not click flatpak in a GUI level of simplicity, but it would’ve saved me days of frustration.
The more ive learned to code and the better I’ve become at solving my own problems on Linux, the more I’ve been absolutely fucking bewildered about how so many people can spend so much time and effort into projects they care deeply about and fail to include even the most basic of necessary instructions. Like “this one simple step is crucial and you can’t do fuck all else if you don’t do it”, kind of necessary
I think they want people to use the things they built, right? And yet, here’you are in a Kafkaesque nightmare with no visible exit, seemingly alone as if you’re the only person to ever actually need the crucial but of instructions necessary to make this thing work.
You wonder: am I just an idiot? Iss everything else in on something that I just don’t get? So you spend hours pissing into the wind as Google tantalizingly dangles tangential words at you, having become the internet equivalent of a bully snatching away the toy you brought for show and tell while swearing THIS is the last time, and you soldier onwards for hours, determined that you’re going to get this fucking thing working even though you know that for the sake of your sanity and our limited time on earth the better choice would be to give up. You make a point to leave a comment about your struggle on GitHub, just in case someone else finds themselves in your position one day, feeling less like an accomplished problem solver and more like someone who’s had to pop their own dislocated shoulder into place after dropping a piping hot pizza and falling on black I d. You’ve learned something, you’re more self reliant, this will be less serious in the futurre, but you can’t shake this weird feeling growing ever more insistent, a question you just can’t seem to answer: why? You’ll never know, and though it bothers you, you set to work trying to get this new image generation model to make you some anime women with comically oversized tits and worryingly unnaturally thin waists.
https://linuxgamingcentral.com/posts/steamos-getting-nix-support/
Dunno if this ever came to fruition though.
-