Why aren't more people using NixPKGs?

kadu, 3 months ago

deleted_by_author

unwantedpamphlet, 3 months ago

@kadu @clemdemort I agree but I think every Linux user goes through the “all bloat is evil!” phase and sadly they are some of the loudest voices in the community.

MilkLover, 3 months ago

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.

littlewonder, 3 months ago

You’ve just answered a question I didn’t realize I had.

clemdemort, 3 months ago

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.

caseyweederman, 3 months ago

I love it when every basic application is an entire operating system under the hood

TheEntity, 3 months ago

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.

Ferk, 3 months ago

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.

cai, 3 months ago

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.

avidamoeba, 3 months ago (edited 3 months ago)

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.

cybersandwich, 3 months ago

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.

onlinepersona, 3 months ago

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 like home-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).

CC BY-NC-SA 4.0

caseyweederman, 3 months ago (edited 3 months ago)

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 shares my pain and also explained what I was doing wrong:
https://programming.dev/comment/7537131

Drito, 3 months ago

Flakes 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.

caseyweederman, 3 months ago

Right but like “be able to do anything” requires you to have Flakes enabled

excitingburp, 3 months ago

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.

Shareni, 3 months ago (edited 3 months ago)

1. 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.
2. No gui integrations for casuals. For example Discover integrates flatpaks and snaps, but for nix you need to use the terminal.
3. 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

jayandp, 3 months ago

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.

moonpiedumplings, 3 months ago

linuxgamingcentral.com/…/steamos-getting-nix-supp…

Dunno if this ever came to fruition though.

jayandp, 3 months ago

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.

Shareni, 3 months ago

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.

Fungah, 3 months ago

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.

neo, 3 months ago

I’m glad it’s not just me.

PureTryOut, 3 months ago

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.

Euphoma, 3 months ago

The nix package manager can be used on any os and doesn’t require usage of the nix programming language…

Shareni, 3 months ago

Did OP mention nixos at some point?

Telodzrum, 3 months ago

No, but the top-level comment you’re replying to is a perfect response for the OP because of what it demonstrates.

Atemu, 2 months ago

Note that Nix is not a full-blown programming language, it’s an expression language. The end result of an expression is always data and side-effects are not possible; you can’t do network requests or write to arbitrary files. There is no such thing as a variable in Nix either, only constants. You can think of it like JSON with (pure) functions and an additional data type (~package).

From a user perspective, it’s really not very different from any of the other 100s of weird configuration syntaxes you’ve surely come across in your Linux journey.

My nixos-config is a bit more complex because I like to reap the benefits that abstraction but here’s a simpler section that is representative of how a typical NixOS desktop config would look like:

github.com/Atemu/nixos-config/blob/…/module.nix#L…

(Though note that even this is slightly more complex than what you’d do when starting out; ignore the LADSPA_PATH and tablet conditional for now.)

wiki_me, 3 months ago

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.

moonpiedumplings, 3 months ago

It’s cause you’re not actually supposed to use nix-env: stop-using-nix-env.privatevoid.net

You’re actually supposed to be using nix search nixpkgs#packagename to search and nix 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…

sxan, 3 months ago

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.

moonpiedumplings, 3 months ago

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.

Atemu, 2 months ago

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.

sxan, 2 months ago

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.

Atemu, 2 months ago

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.

SomeBoyo, 3 months ago

the aur has everything I need

ChonkaLoo, 3 months ago

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.

clemdemort, 3 months ago

you have to set up the XDG_DATA_DIRS environment variable to take into account ~/.nix-profile/sharethe desktop icons will only appear after a relogin though.

Shareni, 3 months ago

It’s automatically set up alongside PATH

LinusWorks4Mo, 3 months ago

yeah, everybody should use them. I usually write my own kernel mods tailored for my hardware and certain needs, I don't know why not everyone is doing that. admittedly is a bit janky maintaining a separate kernel fork, but you get used to it, everyone should do it

nivenkos, 3 months ago

Pacman (and paru and the AUR) and chezmoi works fine, I don’t see any reason to switch.

Adanisi, 3 months ago

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.

IAm_A_Complete_Idiot, 3 months ago

You can do rollbacks if you’re using something like home-manager on a foreign distribution. It’s just a bit more janky admittedly.

Shareni, 3 months ago (edited 3 months ago)

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.

Adanisi, 3 months ago

No, nobody did mention it, I was just making a side-point.

I also said there are advantages to Guix/Nix on foreign distros.

PlexSheep, 3 months ago

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.

ghoscht, 3 months ago

Nixpkgs can be used without knowing anything about nix. You can install almost anything by just running e.g.:

<span style="color:#323232;">nix-shell -p cowsay
</span>

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.

PlexSheep, 3 months ago

So I can in theory just do apt install nix-shell (or whatever), do something like nix-shell -p curl and then curl just works?

ghoscht, 3 months ago

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 use nix-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.

Shareni, 3 months ago

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.

unionagainstdhmo, 3 months ago

Flatpaks are much better than AppImages because they don’t bring in all of their dependencies, they inherit them from a runtime.

MonkderZweite, 3 months ago

It’s about Nixpkg, not Appimage.

chayleaf, 3 months ago

it’s the way Nix works too

unionagainstdhmo, 3 months ago

Yeah so I don’t know why OP is using that argument

clemdemort, 3 months ago

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.

chayleaf, 3 months ago

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.