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.
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.
The way nix installs in my root directory in another distro is a no-go for me
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.
IIRC it puts a user owned directory inside the root. I have no clue what the total implications are in respect to privacy and security.
The last time I looked the NIX solution to secure boot keys was to disable secure boot, making the largest attack surface on modern computers completely unprotected by default. The idea of leaving it up to the user to figure out keys and self signing was a giant red flag for me. My current workstation requires a shim as the bootloader that came with the device rejects custom keys and I didn’t care to figure out Keytool on my own to boot into UEFI and try to change them by force. That knocked NIX off my list of complete distros to run. While I don’t know the implications for the NIX package manager on another distro, this is the combination of real factors that formed my chain of reasoning about using NIX in both respects.
I also ran arch for a few weeks once and am now extremely skeptical of any distro that presents anything that hints at “you figure it out yourself” complications for basic function. After Arch I went to Gentoo back when the Sakaki guide still worked and that was much more my style. I had something that just works, and made extra complications much more approachable. Specifically, I found documented entry points on things I didn’t understand, approached in ways I found useful. I don’t recall exactly what I was trying to do at this point, but with NIX I spent a couple of days trying to figure out stuff and went in circles. I think I had come across a NIX package for KoboldCPP and tried a bunch of stuff that didn’t work.
Anyways, I have nothing against NIX and might try it again one day. This is not bashing on NIX, or calling it inadequate. This was just my experience as a dumb user.
IIRC it puts a user owned directory inside the root. I have no clue what the total implications are in respect to privacy and security.
None.
The last time I looked the NIX solution to secure boot keys was to disable secure boot
Are we talking about Nix or NixOS here now? These are entirely different things.
Nix on non-NixOS does not care whether that OS can do secure boot or not.
As for NixOS: https://github.com/nix-community/lanzaboote
(Not sure what you’d actually want to achieve with “secure” boot as it doesn’t protect you against anything on its own.)
The idea of leaving it up to the user to figure out keys and self signing was a giant red flag for me.
The current support for secure boot in NixOS is rather experimental still. It’s the same as any other distro that hasn’t applied to RedHat to get their shim signed with a M$-trusted key, so I don’t really see your point here.
That aspect is also being worked on as we speak.
I didn’t care to figure out Keytool on my own to boot into UEFI and try to change them by force. That knocked NIX off my list of complete distros to run.
That’s your ignorance’s fault, not any distro’s. If you can’t be bothered to plug in your own keys, you limit yourself to the set of distros that are indirectly officially approved by M$.
I also ran arch for a few weeks once and am now extremely skeptical of any distro that presents anything that hints at “you figure it out yourself” complications for basic function. After Arch I went to Gentoo back when the Sakaki guide still worked and that was much more my style. I had something that just works, and made extra complications much more approachable. Specifically, I found documented entry points on things I didn’t understand, approached in ways I found useful.
If you need your hand held, the Nix ecosystem won’t be for you. It’s not really approachable by people who can’t research things in its current state.
Nothing wrong with that but Nix just isn’t at the point where mere mortals can reasonably be expected to be able to use it.
I can respect all of that.
That’s your ignorance’s fault, not any distro’s. If you can’t be bothered to plug in your own keys, you limit yourself to the set of distros that are indirectly officially approved by M$.
Harsh. I tried signing my own keys. I replaced them in the bootloader, but when I do the final step to lock them down, the TPM chip flushes the new keys and reissues fresh keys again. The only guide I have found for Keytool is on Gentoo. I love Gentoo’s documentation for a lot of things, but it assumes a high level of competence, and I haven’t seen anything visually showing exactly what to do and how Keytool works in practice. I don’t feel very confident taking that step for the first time on a machine I must keep working.
Indeed there are many times I “need my hand held” in order to take my first steps into a subject. I need an intellectually-intuitive foundation that is stable and I can build upon.
You say there is no security issue with a user owned directory in root, but intuitively, that shakes a lot of my understanding that is not grounded in formal CS as you likely seem to be. Like I don’t understand:
- why a user owned directory in root is needed
- What it means for NIX in reference to configuration files, dot files, and my mental model of mess that belongs in /home/$user. While unfounded, I immediately worry root will somehow get cluttered with junk too. It is probably wrong, but I think of $user being largely sandboxed in /home/$user/
- I don’t know what the SELinux context is for NIX, but I only have a limited grasp of SELinux from hacking around on Android to add things like busybox, and I know it is permissive but enabled in Fedora.
- I question how anything placed directly in the root directory of another distro will impact future updates from the packagers of the distro.
- Isn’t this against the Unix framework to place something directly in root?
I think those are all of the intuitive thoughts and questions that resonated in my mind when I saw /nix and noticed its user context.
When I am working on some other project, I don’t want my OS to force me into some peripheral rabbit hole in some large gap within my understanding just to run an update for a package I need, like what I experienced with pacman. My negative experiences with Arch many years ago makes me default skeptical. While I understand that NIX and NIXOS are different, I still associate them when it comes to developing trust.
Last thing worth mentioning since I have been thinking about it. I was motivated to try NIX, enough to install it, in order to try a preconfigured version of KoboldCpp, as I mentioned. However, I recall it was posted on a website somewhere and was described for a WSL NIX Flake. I was curious to try it because I have had trouble with Nvidia with a mainline kernel and kobold. I thought maybe the flake was just described for WSL and I could easily sort out a Linux version, but that didn’t happen. The flake was not in any native repo, and altering it to run in Linux did not feel very approachable in documentation as far as a first time experience with NIX. I don’t think kobold is compatible with a DKMS built Nvidia module anyways so that stopped my effort.
I tried signing my own keys. I replaced them in the bootloader, but when I do the final step to lock them down, the TPM chip flushes the new keys and reissues fresh keys again
It may just be that the firmware of your particular board is buggy to the point of being broken.
You could try updating it but sometimes it’s futile and the firmware is just the biggest pile of crap.
Indeed there are many times I “need my hand held” in order to take my first steps into a subject. I need an intellectually-intuitive foundation that is stable and I can build upon.
Absolutely reasonable expectation. I wish we had that.
why a user owned directory in root is needed
I initially glossed over the fact that you said “user-owned” here. It still shouldn’t affect anything because nothing uses /nix for anything security-critical at any point but it’d certainly be smelly.
User-owned
/nixis only the case in single-user installs which I believe have been deprecated for a while and certainly aren’t the way to go anymore.These days the preferred and default method is a multi-user install where
/nixis owned by root there and exclusively managed by the privileged nix-daemon.What it means for NIX in reference to configuration files, dot files, and my mental model of mess that belongs in /home/$user. While unfounded, I immediately worry root will somehow get cluttered with junk too. It is probably wrong, but I think of $user being largely sandboxed in /home/$user/
Nix (the package manager) itself does have some limited local state (cache, current profile link) that is put into the appropriate XDG user dirs. It will never touch anything outside of those specific state dirs, the TMPDIR and
/nix.Nix is designed to be fully contained in
/nix. This property enables you to even wipe their entire root on every boot under NixOS.Apps installed via Nix behave as they always do w.r.t. cluttering directories.
opensshwill still create and manage its~/.sshdirectory for instance, just like on other distros. If you ran some daemon that you installed via Nix with sufficient privileges, it may try to create its state directory in/varor whatever; just like the same daemon from any other distro’s package would.That is all to say: Nix does not do anything special here. Its packages largely behave the same as they do on any other distro and that behaviour includes state directory cluttering behaviour at runtime.
I don’t know what the SELinux context is for NIX, but I only have a limited grasp of SELinux from hacking around on Android to add things like busybox, and I know it is permissive but enabled in Fedora.
No SELinux support whatsoever.
There is somewhat explicit non-support even as Nix’ model of files and directories does not include xattrs; you cannot produce a Nix store path that has special xattrs for SELinux purposes.
Metadata like permissions, dates and owner information are all normalised in the Nix store. The only permitted metadata apart from the file name is whether regular files can be executed.If your system uses SELinux, you must add an explicit exception for the Nix store. (Installers may do that automatically these days, I haven’t kept up with that.)
question how anything placed directly in the root directory of another distro will impact future updates from the packagers of the distro.
Other distros simply do not touch
/nix; it’s not their domain.FHS distros control FHS directories such as
/usror/bindepending on what individual packages contain but no sane package of an FHS distro will try to control/nix/store/hugehash-whatever/.Isn’t this against the Unix framework to place something directly in root?
Nix does many things that go against original design principles of Unix and that’s a good thing. It’s not the 70s anymore and some aspects of Unix have not aged well.
https://economicsfromthetopdown.com/2024/02/17/nixing-technological-lock-in/
trouble with Nvidia with a mainline kernel and kobold.
Using Nix for applications that have userspace driver dependencies on non-NixOS requires a hack unfortunately: https://github.com/nix-community/nixGL
Thanks for taking the time to answer all of my questions. I’m much more likely to try NIX again now.
Home Manager would like a word.
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.
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.
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.
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.
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
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.
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.
The nix package manager can be used on any os and doesn’t require usage of the nix programming language…
One reason is probably that people don’t know about them.
because they are super bloated (since they bring all their dependencies with them).
I love they work like that and much prefer this approach. We aren’t in the 80’s using 10 MB storage devices. Please, for the love of God, bundle all your dependencies with your application and the exact version you need, isolate them from other programs. macOS and Windows apps have been doing this for ages.
If you use any accelerated graphics (GTK4 anyone?), you cannot and must not bundle all your dependencies.
Conceptually, graphics drivers have two parts: The part in the kernel (e.g. amdgpu), and the part loaded as a library from the system into the application (e.g. Mesa).
Mesa - or any other GL/Vulkan implementation - is loaded from the system into the application as a library. Mesa relies on system libc, system LLVM (!!!), a particular libc++, etc.
If you ship libGL (and LLVM etc), you must re-release your software with upgraded deps whenever new graphics cards are released (and should whenever bugs are fixed). Your software is literally incompatible with (some) newer computers.
For the proprietary Nvidia libGL - which, again relies on system glibc - you can’t legally include it.
Flatpak solves this by separating out ‘graphics driver libraries’ as a unique type of runtime, and having a shitload of special rules & custom hacks to check the system libGL, open source or proprietary, maybe substitute a Flatpak provided libGL, with all the deps that libGL needs, and make it compatible with whatever app & whatever app runtime.
Actually correctly solving the libGL debacle is half the value of Flatpak to me.
Windows apps have been doing this for ages with disasterous security results due to the lack of mandatory OS sandboxing. E.g. CVE for admin level RCE via Adobe Flash. This model works with third party apps only when sandboxed. This was done from the get go on Android and now with Snap and Flatpak (I assume). It’s absolutely the way to go once the security framework is in place.
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.
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.
You’ve just answered a question I didn’t realize I had.
I love it when every basic application is an entire operating system under the hood
Beats breaking the actual operating system due to a small dependency conflict because one developer couldn’t be arsed to update their requirements.
In terms of the memory usage, it’s a reasonable approach these days. It gets hairy when we consider security vulnerabilities. It’s far easier to patch one system-wide shared library than to hunt down every single application still bundling a vulnerable version.
The nice thing about Nix/Guix is that each version of a library only needs to be installed once and it wont really be “bundled” with the app itself. So it would be a lot easier to hunt down the packages that are depending on a bad library.
You’re not exactly comparing apples to apples here.
Flatpak and appimages tend to be used in any distro because they can just be downloaded in a one off manner and installed then you’re running the application (for the most part). They offer a manager of sorts but you don’t need it to use the packages.
For nixpkgs, whike I’m sure I can get a package from the sounds of the sizes the package covers only the application or the library, meaning I still need the dependencies.
So what exactly would make me the user trade my built in tools (apt/pacman/dnf) for nix? Keep in mind no matter how great you feel it is, you need to provide reasoning that motivates me to install and learn this new tool instead of the old ones I have.
For nixpkgs, whike I’m sure I can get a package from the sounds of the sizes the package covers only the application or the library, meaning I still need the dependencies.
When you download/build a nix package, nix will absolutely also download all necessary dependencies.
I often stumble on this example of nix usage - a one-off shell with a a specific package. This is such a niche and seemingly unimportant use case, that it’s really strange to have it mentioned so often.
Like literally what’s the point of having a shell with ffmpeg? Why not simply install it? Even if you need something just once, just install it and then uninstall it, takes like 10 seconds.
The other use case that is often brought up is for managing dev environments, but for a lot of popular languages (Python, Node, Java, Rust, etc. ) there are proven environment management options already (pyenv and poetry, nvm, jenv, rustup). Not to mention Docker. In the corporate setting I haven’t seen nix replacing any of these.
From my limited experience using home manager under Linux and macOS:
- GUI app shortcuts work in neither of the OSs
- error messages are about as readable as the ones you get for C++ templates
- a lot of troubleshooting searches to unsolved GitHub issues
All in all nix seems like a pretty concept but not too practical at the moment.
I often stumble on this example of nix usage - a one-off shell with a a specific package. This is such a niche and seemingly unimportant use case, that it’s really strange to have it mentioned so often.
It’s probably one of the simplest things you can do with it that isn’t really possible with other package managers and also doesn’t require explaining any internals, I guess that’s why.
I could also tell you about easily being able to build statically linked binaries or cross-compile (or both) with the same package definition without having to do any extra work, that might be more impressive.
The other use case that is often brought up is for managing dev environments, but for a lot of popular languages (Python, Node, Java, Rust, etc. ) there are proven environment management options already (pyenv and poetry, nvm, jenv, rustup).
Yeah, and neither of them considered that it might be important to deal with software written in other languages. Want to link against a C library in a Rust project? Run some tool as part of NPM build step? Screw you, install it manually from elsewhere or your build fails. The only one that I know does do this is OCaml’s OPAM, which does have a lot of non-OCaml software packaged. (Also at least the latter three seem to be only for setting up the language itself. What is this, a package manager for a single package?)
Not to mention Docker.
Meh, Docker is kind of a joke. Sure, it solves the problem of dependencies, but in possibly the stupidest way possible bar shipping a VirtualBox image. A lot of prebuilt images are x86_64 only. It needs to run a Linux VM on Mac and Windows (tbf Nix doesn’t have a native Windows version at the moment either, you need to run it in WSL, but people are working on that). So that means running at native performance on an ARM Mac, which are quite common for development I think, is out from the start. It also adds a lot of complexity to your environment due to wrapping everything in a container if you just want to have a couple tools. You don’t get your nicely configured shell, other system tools, anything else inside the container. I haven’t ever tried it but you probably also need special support from any IDE you want to use.
(And not to mention most Dockerfiles being absolutely not reproducible, but you can solve that… with Nix :^) )
- GUI app shortcuts work in neither of the OSs
On Linux I think you need to link ~/.local/share/applications to home-manager’s share/applications. Not sure about Mac, its GUI kind of hates symlinks and Nix uses a lot of symlinks. Spotlight doesn’t read anything behind symlinks at all, for example, and Launchpad resolves them so after a package update it will not pick up the new versions because it’s still looking at the old path.
- error messages are about as readable as the ones you get for C++ templates
Unfortunately true, yeah. I also think this isn’t really a problem that can be solved due to Nix being a dynamically typed language that has everything be an expression (so there’s no fixed structure whatsoever) and also using lazy evaluation everywhere. Three components that all decrease the capability for useful error messages and debugging, and together… yeah it can get pretty bad.
- a lot of troubleshooting searches to unsolved GitHub issues
Really? This hasn’t been my experience at all. There’s a couple like that, sure, like the build sandbox on Mac, but they’re rare. And usually people in the community channel know a workaround :^)
Like literally what’s the point of having a shell with ffmpeg? Why not simply install it? Even if you need something just once, just install it and then uninstall it, takes like 10 seconds.
The last time I used it, I needed arandr just to create a layout with a new monitor. Why would I install it, use it, remove it, and then auto remove the leftovers when I can just run a single line to use it once and forget about it? My old installs were littered with random crap like that that I’ve used once and forgot to remove.
The other use case that is often brought up is for managing dev environments, but for a lot of popular languages (Python, Node, Java, Rust, etc. ) there are proven environment management options already (pyenv and poetry, nvm, jenv, rustup).
Here’s the last time I used it: I needed to compile some rust binary but I don’t have rust or cargo installed. Since the repo has a nix flake, I was able to clone it, cd into the directory, run “nix develop”, and start compiling. Much easier than having to find and install all of the compile time dependencies, and then remove them a minute later.
Besides that, there’s a reason why python has different 20 venv packages: they’re all crap. Nix is a better alternative and leaves you with a single dependency for every OS.
Not to mention Docker. In the corporate setting I haven’t seen nix replacing any of these.
Declarative package management definitely has it’s benefits, and nix has been growing in that space ever since they’ve added the option to generate docker images from nixos configs. It’s not meant to replace docker, just to give you an option to create finely tuned base images.
GUI app shortcuts work in neither of the OSs
Home-manager on Debian: no manual set up was required.
error messages are about as readable as the ones you get for C++ templates
They can get overly long, but perfectly raadable if you start from the bottom.
All in all nix seems like a pretty concept but not too practical at the moment.
Nixos sure, but with nix I get the same bleeding edge userland packages on Debian and whatever else I’m running at the time. It’s just a list of packages, but it makes life so much easier.
Even if you need something just once, just install it and then uninstall it, takes like 10 seconds.
apt install foo && apt remove fooThat’s essentially what
nix-shell -pdoes. Not a special feature of nix, just nix’s way of doing the above.Actually using it though is pretty convenient; it disappears on its own when I exit the shell. I used it just the other day with
nix-shell -p ventoyto install ventoy onto an ssd, I may not need that program again for years. Just used it with audible-cli to download my library and strip the DRM with ffmpeg. Probably won’t be needing that for a while either.The other thing to keep in mind is that since Nix is meant to be declarative, everything goes in a config file, which screams semi-permenant. Having to do that with ventoy and audible-cli would just be pretty inconvenient. That’s why it exists; due to how Nix is, you need a subcommand for temporary one-off operations.
So it sounds like nixpkgs is more akin to virtualenvs in Python rather than a traditional package manager. Is that an accurate statement?
If so, I’d recommend that be your selling point because that’s some powerful security.
Virtualenvs for everything that don’t duplicate resources and are reproducible.
Nixpkgs: the official nix repository
Nix shell: only creates a venv with extra packages
Nix develop: full environment configuration on top of nix shell, so you can for example set up project specific envars
Besides that, nix can also work for regular userland packages as an:
-
imperative package manager (same style as apt install)
-
declarative package manager (you make a list of packages, nix/home-manager ensures they’re installed)
The selling point for me is that I can just write a list of packages, and have the bleeding edge versions installed on top of Debian. I can git that list and have all of my packages available on every device, no matter the os or distro.
Won’t lie I’m getting sold on this via this discussion
Here’s a part of my other comment because the docs are horrible:
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 switchIt took me days to get to that point simply because you need to trawl through outdated and nixos resources. Those examples + home-manager manual will get you going in 10 minutes.
-
For development, yeah you’re supposed to use it like that, as opposed to installing dependencies systemwide. I don’t think you can even really do that on NixOS.
However, it has nothing to do with security though, but rather dependency isolation, so you can use one version of library X for one project and another for the other without them conflicting.
I mean, security is an unintended outcome of it. Any kind of isolation of packages provides a level of security.
Ehhhh, security by obscurity if anything. Every downloaded or built nix package is in /nix/store and readable for every user.
Flatpak still depends on runtimes though, I have a few different runtimes I had to install just because of one or two flatpaks that required them (like for example I have both the gnome and kde flatpak runtimes, despite not running either of those desktop environments)… and they can depend on specific versions of runtimes too! I remember one time flatpak recommended me to uninstall one flatpak program I had because it depended on a deprecated runtime that was no longer supported.
Also, some flatpaks can depend on another flatpak, like how for Godot they are preparing a “parent” flatpak (I don’t remember the terminology) that godot games can depend on in order to reduce redundancies when having multiple godot games installed.
Because of those things, you are still likely to require a flatpak remote configured and an internet connection when you install a flatpak. It’s not really a fully self contained thing.
Appimages are more self contained… but even those might make assumptions on what libraries the system might have, which makes them not as universal as they might seem. That or the file needs to be really big, unnecessarily so. Usually, a combination or compromise between both problems, at the discretion of the dev doing the packaging.
The advantage with Nix is that it’s more efficient with the users space (because it makes sure you don’t get the exact same version of a library installed twice), while making it impossible to have a dependency conflict regardless of how old or new is what you wanna install (which is something the package manager from your typical distro can’t do).
All of these points are completely correct and paint an accurate picture of the inherent issues with both technologies.
My intent with my earlier comment was to show how flatpaks and appimages were different from traditional package managers at a high level so I could ask what made nixpkgs different from something I felt and still kinda feel is a more accurate comparison which are traditional package managers like apt etc.
The big selling point to me now is that nixpkgs seem to work similarly to virtualenvs from Python which is cool.
Learning curve? I’ve meant to get around to it but my to do list is pretty big so far.
Nix is on the destinations to visit but the configurations are still confusing at a glance.
If you use Nix the imperative way (
nix profile blah), you don’t need to learn the Nix language at all, or write config files. Installing/removing/upgrading packages is just a single command, similar to other package managers.Eg:
- To search for
baton nixpkgs:nix search nixpkgs bat - To install
bat:nix profile install nixpkgs#bat - To upgrade all packages:
nix profile upgrade '.*'
Ref: https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-profile
- To search for
Stop making a list and start with eg: Nix Pills
Steam Deck is using Flatpaks so…
You can also use nixpkgs and AppImages on SteamOS.
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.
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.
What do you mean? Apple doesn’t have a package manager at all. Brew is a fucking mess that takes ages to do anything.
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.
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.
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 🤷
Flatpaks are much better than AppImages because they don’t bring in all of their dependencies, they inherit them from a runtime.
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.
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.
You can do rollbacks if you’re using something like home-manager on a foreign distribution. It’s just a bit more janky admittedly.
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.
