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.
deleted by creator
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.
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.
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.
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.
I love it when every basic application is an entire operating system under the hood
deleted by creator
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.
One reason is probably that people don’t know about them.
-
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.
Edit:
if anyone’s interested in trying it out, here’s a part of my other comment in this thread
It’s just a list of packages, and an optional flake to control the repositories (stable/unstable) and add packages from outside of the official ones.
To update everything nix related I just run:
cd ~/dotfiles/nix/ && nix flake update && home-manager switch
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.
They added the Nix directory in SteamOS 3.5 and linked it to the User partition, so now Nix survives SteamOS updates without any workarounds, which is part of why I tried using it.
I’m glad it’s not just me.
-
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 on@moonpiedumplings@programming.dev shares my pain and also explained what I was doing wrong:
https://programming.dev/comment/7537131Flakes is still experimental. NixOS devs takes a bunch of time to release that. So most experienced users have enabled Flakes since years. Two different systems are available, which does not help ease of learning.
Right but like “be able to do anything” requires you to have Flakes enabled
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
bat
on 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
Or just home-manager with a list of packages, and you avoid all of the issues imperative PMs have.
- To search for
Stop making a list and start with eg: Nix Pills
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.
deleted by creator
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.
But you don’t get hardware graphics acceleration unless you use nixgl, and if you want to integrate it into home manager that breaks XDG entries, which I never figured out.
Thanks, I didn’t know that.
Also, you are illustrating the point of the commenter you replied to
Oh yeah, this is a part of my reply to the OP:
The documentation is abysmal. I spent days trying to figure out how to use nix as a declarative package manager before I accidentally came across home-manager. Even the manual leads you down the wrong path. A quick start guide with a few examples for home-manager and flakes, and a few basic commands, would’ve had me going in 5 minutes. That problem is made worse by the fact that almost all sources of info focus on nixos instead.
And where in the documentation is that?
Nix docs are hot garbage, but I’m pretty sure it tells you to reboot when you finish installing either nix or home-manager. It didn’t appear to me in a dream.
to clarify, i was talking about home-manager
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.
It’s about Nixpkg, not Appimage.
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 1
will clone a git repo without older stuff. Without this, the nixpkgs git repo is like 13-14 GB, but with a depth of 1, it’s only 200 mb.If you maintain upstream software and do not have an interest in learning and using Nix, please don’t put the burden of packaging software in Nix onto yourself. Nobody in their right mind would expect you to package anything for a dozen distros; that’s not how distros are supposed to work.
Leave it to someone who is interested to package your software in Nixpkgs. Your “job” is to make your software better and provide a sane way to build your software that packagers can rely on (i.e. no assumptions where things are or are supposed to go, document your dependencies and build processes).
If you do want to go the extra mile, offer your help in assisting packaging in the appropriate channels. You know the technical details of your software and Nix users how Nix packaging works but the reverse mostly isn’t true, so cross-pollination can be super helpful here.
Even just things like testing that your software works as you expect when the packaging is touched in some way (i.e. an update) is incredibly helpful. (If saw a package update PR with the upstream maintainer’s approval stating that it works as they expect, I’d merge immediately.)If packaging for Nix is a burden for you, please just open an issue on Nixpkgs with links to your packaging/build documentation and let someone else do it for you.
As a Nixpkgs committer, I’d much rather have someone invested in Nix build and maintain a package than an upstream maintainer who somehow feels obligated to do so but has no experience or actual interest as the former is more likely to produce good code and keep maintaining the package.Sure. My point is that it’s trivial to make and test packages for many distributions; it is harder to do so for Nix. It tends to get your software out there and used faster if you bootstrap the packaging - immediately, if you have an AUR account.
IMHO, Nix is unreasonably harder. There are frequently small projects that don’t get packaged for most distros. When I encounter these, I have a couple of options:
- Submit a packaging request. Hope someone is willing to accept it. Wait until it is packaged.
- Install it from source and let it pollute the core system. Hope this causes no issues. Manually track and maintain the installation. If lucky, the software lets itself be installed somewhere non-standard, in which case I can use stow and keep things a bit cleaner.
- Throw together a package for it and let my distro manage the installation.
The third option is preferrable to the others, for a variety of reasons, and it’s easy on most distros. On Arch, I might submit the package to AUR, but I’ll often just make a -git package and install it locally.
It tends to get your software out there and used faster if you bootstrap the packaging
It’s fine to provide some sort of “official” binary package in some common format such as a Flatpak, Appimage or even just a plain old tarball but trying to package something for many different distros is insanity IMHO.
My point is that it’s trivial to make and test packages for many distributions; it is harder to do so for Nix.
it’s easy on most distros
It all depends on what you’re used to and how cursed the project’s build process is.
For sane build systems, I find it much easier to package for Nix now that I know its intricacies. I wouldn’t want to go back to weirdly sourced bash scripts without proper structured data types or any sort of abstractions or mechanism for extremely common patterns.On Arch, I might submit the package to AUR, but I’ll often just make a -git package and install it locally.
It’s the same for NixOS. When I encounter something that somehow isn’t packaged in Nixpkgs yet, I usually start out by simply packaging it in my local nixpkgs checkout.
There are handy tools to generate the little boilerplate there is and, if the package uses a reasonably standard build system, it usually only takes adding the dependencies and one or two tweaks to have a working package that is then also ready for submission to upstream Nixpkgs.
the aur has everything I need
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#packagename
to search andnix profile install nixpkgs#packagename
to install.However, to use both of those, you need to have the “experimental” (not really though, most of the community uses them) features of nix-command and nix flakes enabled, which they aren’t by default.
And of course, nowhere on the main documentation did I find any if that, I only found it via the pain of using it wrong, and forum posts.
Nix’s documentation is horrific. I’ve had situations where I only got help via discord…
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
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.
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
What do you mean? Apple doesn’t have a package manager at all. Brew is a fucking mess that takes ages to do anything.
The applications have binaries and libraries bundled for multiple arches. I wasn’t speaking to the package manager.
For me personally, I just haven’t taken any steps into the nix environment. Seems rather complex, setting up those nix files and stuff.
I use Debian on servers and LMDE on my PC, most things I need are in the Debian repos and for other cases I get by pretty good with appimage s and flatpaks. Installing is just a simple command and me happy.
Nixpkgs are probably easy too, I assume. I know a lot of people really like nix, but the effort required to start seems significant to me, especially when we have other methods that just work.
Nixpkgs can be used without knowing anything about nix. You can install almost anything by just running e.g.:
nix-shell -p cowsay
The requirement for that is the nix package manager but that should be easy to install. But yeah getting into Nixos with flakes and all that stuff can be hard.
So I can in theory just do
apt install nix-shell
(or whatever), do something likenix-shell -p curl
and thencurl
just works?Pretty much, yes. Although most of the guides install nix via curl. You can find the recommended installation procedure on the official nix website.
What I’m right now also realizing is that i switched things up.
nix-shell -p curl
creates a shell with the curl command temporarily available. If you exit this shell it’s gone. I use this all the time if if i don’t want to pollute my system with programs I only use once. If you want to permanently install something you have to usenix-env -iA nixpkgs.curl
. But don’t take my words for granted, since I have never tested this on a non-nixos machine.Note: You can also see how to install something by clicking on the package title in the nixpkgs repo.
the effort required to start seems significant to me, especially when we have other methods that just work.
It’s just a list of packages, and an optional flake to control the repositories (stable/unstable) and add packages from outside of the official ones.
To update everything nix related I just run:
cd ~/dotfiles/nix/ && nix flake update && home-manager switch
I’ve only included a few packages from the actual list, but you can see how simple everything is. It just took me days to get to that point because the docs are really bad.
most things I need are in the Debian repos and for other cases I get by pretty good with appimage s and flatpaks.
I use it to freshen up Debian packages. For example Debian docker is like 4 major versions behind the nix one, and it stopped being supported months ago.
Also, now that I’ve created the list from above, I can just run a single line to reinstall everything I need.
Why don’t you just install nix on debian and see
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
/nix
is 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
/nix
is 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.
openssh
will still create and manage its~/.ssh
directory 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/var
or 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
/usr
or/bin
depending 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.
deleted by creator
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.
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.
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.
So what exactly would make me the user trade my built in tools (apt/pacman/dnf) for nix?
Getting a shell with a specific package as a one off. Want ffmpeg?
nix-shell -p ffmpeg
opens a shell with ffmpeg in its path, and only that shell has it.Along with that, that means users can install packages for themselves. Limited use for single-user systems, but nonetheless it’s possible.
Per-project dependencies. Pretty much the same as above, but the dependencies are declared in a file which is part of the project. In many cases that same file can also be used as a nix package itself, like any other in nixpkgs. Very useful if you write software yourself. Here’s an example.
Being a source-based package manager with a cache means that you get all the benefits of prebuilt packages but can easily patch or use other versions of a package, with no difference in use (other than that it will build it locally instead of downloading from the cache).
On a distro with a different main package manager I would probably mainly use it for per-project dependencies though.
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 foo
That’s essentially what
nix-shell -p
does. 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 ventoy
to 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 switch
It 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.
docker run --rm -ti -v "${PWD}:${PWD}" -w "${PWD}" ffmpeg
gets me most of the way there. I alias commands like this all the time.