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.
Pacman (and paru and the AUR) and chezmoi works fine, I don’t see any reason to switch.
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.
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.
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.
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.
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.
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.
Steam Deck is using Flatpaks so…
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
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.
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.
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.
-
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.
-
Part of the reason is that people are still finding out about it, Project has no marketing so it grows organically, in the last year the number of contributors grew by 25 percent.
Another problem is that it still needs polish in term of ease of use, for example it takes me forever to search for packages using the nix-env command but using the website it takes less then a second, That’s a basic feature that still does not work correct, Plus their documentation is still not great in my opinion, I actually helped improved it and the improvement they made is still not really good IMO.
It’s cause you’re not actually supposed to use nix-env: https://stop-using-nix-env.privatevoid.net/
You’re actually supposed to be using
nix search nixpkgs#packagenameto search andnix profile install nixpkgs#packagenameto install.However, to use both of those, you need to have the “experimental” (not really though, most of the community uses them) features of nix-command and nix flakes enabled, which they aren’t by default.
And of course, nowhere on the main documentation did I find any if that, I only found it via the pain of using it wrong, and forum posts.
Nix’s documentation is horrific. I’ve had situations where I only got help via discord…
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).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.
