> naming conventions for Nix are absolute shit across the board
No, not really. They are not consistent for every part and not every package is up to date with everything but if you get the gist you can easily guess things. If things are really weird we can always rename them.
> so long as the namespaces guarantee uniqueness in the package identity
There are existing issues from this not being the case. Uniqueness of names can only be guaranteed in a single repository and this causes many problems for people pulling from multiple enterprise repos (because everyone packages their own ruby for example). Then they start using omnibus packages instead with their own libraries up to libc, which... it's basically half of poor-mans nix-store.
> Many people like Nix, but many people also don't understand how it works, and thus it will work until it doesn't, and then you'll be stuck.
Considering git still uses sha1 and just about all of web cryptography uses sha1 or sha256 for signatures, block deduplication uses typically 128b hashes, etc., we'll have other problems way before this becomes a problem for nix.
Basically you're worried about a collision in nix, when the whole stack of 10 different things leading to you even reading an article about nix already relies on no collisions.
This will not be an accidental issue within multiples of our lifetimes, and malicious actors will not 0day some nix package in public.
> Another big thing, Nix has Flakes, which make it trivially to turn all your Git repositories into Nix packages.
I have no doubt that this is true, but I still feel dumb about it. I run a Plex server (among a few other workloads) on a NixOS box, and just figuring out how to update the Plex binaries off of the official master branch was a multi-hour back-and-forth endeavor between StackOverflow suggestions and compiler errors.
I really do love Nix though. And once I got it working I felt a LITTLE bit smarter, AND it's worked flawlessly for months.
> Huh. I think this is the first bad experience with NIX I've ever heard on HN.
Strictly speaking "Nix" may refer to two things, and I'm not sure which thing either of you are referring to, nor if you two are referring to the same thing.
Personally I found the nix package-manager a bit odd, but to me that was not a deal-breaker for trying out NixOS. The bigeset problem for me was lacking packages... I was however willing to help the community out by trying to package the things I needed which wasn't already provided for.
But then I had to use the Nix language. And that was a great displeasure, and I ended giving up NixOS all together because of this one pain point.
And to address your comment: I think I've seen similar comments on HN at regular intervals. It's definitely not a one-off comment.
If they had used another more standard language (like LISP!) I would probably still be on NixOS as my main OS.
In the long run, I really hope Guix manages to get something good going. My biggest concern for Guix is that they will restrict the available packages by being overly zealous about package-licensing (like everything the FSF does).
nix is a build tool, not a package manager. Misunderstanding nix as a package manager (and the dumb marketing on its website) is what leads to frustration (along with, of course, docs).
> Nix is one of those things that I explain and then have people telling me I'm wrong and/or an idiot because they can't believe that you can have a distribution based on building packages from source, backed by a binary cache.
Hehe, same here. The number of times I'e had people tell me "uh, no, your package-manager/OS can't do that because <reasons that assume FHS dumping ground of libs/headers and global, mutable config state>" -- too many to count :). I'm still trying to find a 30 second sales pitch that manages to get through people's preconceived notions. If I can get someone to look over my shoulder at my terminal for about 5 minutes, that usually blows them away, but that's not always an option (like here in the comments section, vs coworkers at the office).
Nix is a fantastic concept, and I hope it takes over the world. But the NixOS packages are a mess. I tried it for a few months last year before giving up after several packages and even whole collections of packages became unusable even in the stable repository. The repository needs some serious reworking before Nix can really shine.
> Most users of anything are drive-by, rather casual users.
On top of this, Nix could be extremely well suited to casual users. It inherently avoids most of the problems that plague casual users of traditional package management tools.
Unfortunately, most of the more serious Nix contributores I have interacted with are in too deep to see the usability problems. Even worse, usability issues get trivialized, and users who ask for basic improvements get talked down and told they just aren't getting the magic of Nix.
> Fixing other people's garbage is the bane of any package system maintainer, it's no different here.
I honestly think it's hard for "Nix to Nix" simply because by trying to make everything reproducible, it is dealing with more of upstream's garbage, and "reifying" the hoops people jump through doing sysadmin things in code looks scary.
I really want more upstream developers to use Nix, so they might loose their myopia, and start thinking of the the FOSS ecosystem as a whole, and not just their own packages within it. Nix is the best way to get the bird's eye view, I am sure. Just try not to gag at what you see!
[1] Though I still maintain that contributing to Nixpkgs is much easier than contributing to e.g. Debian or Fedora.
> I saw talk from one guy who wanted to make the Nix package manager use commands that were more like in other package managers.
Did any of this happen?
Yep, that happened, at least somewhat. Most things that you would want to do that used to be argument soup with `nix-env` now uses a program just called `nix`. For example, searching is now just `nix search <query>` instead of whatever the `nix-env` incantation was
> Did you see the Nix devs' proposal early on about requiring users to set the option `config.ambee.acceptThatThisPackageIsNotSupportedByUpstreamDevelopersAndIWillGoToNixpkgsToReportAnyIssues = true`
I did see that but it's somewhat irrelevant because the person that would know what that means would already know where to ask the right question. And the person that has no idea what they're doing would just type 'true' and not know why. I'm in the latter camp btw. Things have to be mostly idiot proof for me. When they're not I'm going to ask questions where I think the most experts are. If I have a problem with HA, I dont care where I got it from or what configs I had to do surgery on, I'm gonna post my question in the HA forums.
To be clear if I was trying to use HA on NixOs at this very moment, I would have no idea what questions are appropriate where except that my problem is with HA so thats where I'd ask it.
> That's likely not the impression people get from looking at any of the mentioned links
We're all different, but as a person ignorant of NixOs and HA, it's the impression I came away with.
That is absolutely not true. If you start to get the hang of it and follow the way things are supposed to be done then things get easier over time. You need to invest upfront more time into your configuration but on the long run it pays off and saves you from an entire error class.
> projects that use it have builds fail anyway
The point of Nix/NixOS is not to have no failing builds but that those are reproducible and deterministic as much as possible and that those failures are noticed early and before the point of no return. A system build is supposed to fail early and not mid way through a major update and prompting you to merge some config under /etc by hand.
> When you have to patch things at the level of ELF, your basic architecture needs work.
May I ask why? It might sound uncommon, but that doesn't mean it's wrong. Nix only patches pre-built binaries targeting other distros. It patches the expected path of shared libraries so that the patched binaries can use versions of libraries that work best.
This is not even a Nix thing. It's standard practice when packaging pre-built binaries. You can see this for yourself in Debian code search:
All Nix does is automate the process that other distros end up doing anyways.
> The project management of Nix feels like a disaster
That's not a fair take when the reason for that is a single issue you care about not being fixed fast enough. Nix has merged 41 PRs in the past month alone, so it's not like there hasn't been any progress. The devs are doing the best they can with the resources available.
> I still don't get why "first steps with Nix" has to include installing packages permanently.
Because if I don't know nix (which, you know, would be why I'd be reading introductory material) I'd be looking to use it, and my basis would be to do would be the way every other distro works.
And if I have to type `nix-shell -p python38` every time I want to run Python and `nix-shell -p vimMinimal` every time I want to edit a file, the experiment is not going to last long.
> So the website recommended you to read a page containing introductory examples. Not sure why you insist otherwise.
I'm not "insisting otherwise", I'm observing that it's confusing, utterly useless, and provides no real guidance towards improvement. And it's where the site told me to go as my second step into nix.
But apparently you're perfectly happy that this is what the "first steps with nix" should be (after having berated me for going there), so... proving the point I guess.
> What? The there are far more chapters in the Nix manual than just the three you mentioned.
Have you actually looked at them? ever?
1 is a quick overview of the entire thing, none of it actually helpful.
2 is a few basic commands expanded upon in (4)
3 is a lot of time spent on installation details
4 is where the meat starts, "You can upgrade package" is 4.1, "profiles are a thing" is 4.2, 4.3 is "nix will eat your disk space" (useless to a beginner), 4.4 is "channels" (even worse), 4.5 is "sharing packages between machines" which could not be less useful at this point./
5 is, as I said, "the nix language" covering the basics, with 5.4 mentioning derivations and going into plenty of details, none of them actually useful or telling a beginner why they should care
Following which we reach 6.1 "remote builds.
From a beginner's perspective, tits on a bull are at least funny, the nix manual doesn't even have that going for it.
>I totally agree that nix is the future of package management.
Perhaps, if they clean it up significantly, I think that nix's principles are very sound, but the implementation isn't: it's fine when you are using it as a simple package manager but as soon as you want to do something a bit complex (say building gcc with a different kernel version) you're on your own:
1) half of the documentation makes reference to configuration files which aren't in my version of nix??
2) there is no real mail/news forum for support/help: no IRC isn't enough.
> But the community does seem to be still tinkering focused.
Because Nix does NOT make packaging easier. Maintainers are the ones who create distros, and they can live a happy life with something as crude as PKGBUILD, since build instructions are almost always stable.
Even for users, most of them just don't need to juggle with package versions. Bleeding edge is mostly covered by Arch and package pinning works ridiculously well for daily uses.
So "make their stuff easy to use" doesn't apply here. Rather, Nix is harder to use in reality.
> I think DevBox make use of an index where it shows the nixpkgs version for different versions of different software
Correct.
> It's a reasonable tradeoff that nixpkgs provides the latest, and if you want anything other than what nixpkgs provides, you write some nix for that.
Reasonable for you, maybe. For me, I have dozens of Erlang projects on various versions that I don’t want to break to start using Nix, and Nix is significantly more effort to get a reproducible configuration than my current setup. Why bother? In what universe is it reasonable to make package consumers write software to consume different versions of a package? Tools are supposed to make our lives easier, not harder.
> In the last few years, Nix has gone from a place where I was sometimes uncomfortable recommending it to people to one where I feel like it would be unstrategic not to use it.
Super agree. Been using nix now for six(?) years and always been advocating for it but hesentiant to recommend companies adopt it (unless you can use it to attract talent as walmart did with nodejs back in the day) however with https://devenv.sh and https://nix.dev in the existence the time to amaze is now measured in < 5 minutes. nixpkgs also partially solves sbom topics, enables monkey patching any linux application/kernel/ffi dependency, has the freshest collection of packages (it's more fresh than archlinux by a major factor) whilst all being under CI/CD (shamefully rare in linux land)
> You have to learn a new OS because a lot of your prior Linux knowledge no longer applies.
This is what confused me the most.
Nix (CLI tools / language syntax)
NixOS (A Linux distro that has CLI tools, but also some CLI tools that are only available on this distro and not others, aka "nix" doesn't really work on Debian)
Flakes vs "configuration"
I just wanted to like "terraform apply" a system configuration on my Debian install.
People are obsessed with Nix because you can manage your config for their local system
Ok... Ansible has existed for 12 years? And you can use it on Debian/don't need a full OS/distro from the ground up (NixOS)
But people will come out of the woodworks to tell you how you don't understand, you're wrong, you're missing the point, Nix is the greatest.
> When I, like many other computer programmers, tell my friends who don’t write code that “it’s a miracle that modern technology even works”, Nix is one of those things that I’m referring to.
Interesting. Since I've started using Nix for managing my environment & projects, it's the only thing that I'm confident will work. I have no idea how the RPM & DEB ecosystems, among others, work when random dependency breakage can happen all the time. This is extra true when building Docker images whose Dockerfile's second line is almost always `apt-get update && apt-get install [list-of-packages]`. I've had so many problems with that process over the years that I've wondered how anything worked at all. Nix was like some heavenly realm where I could be 99.9% confident the build would work every time.
No, not really. They are not consistent for every part and not every package is up to date with everything but if you get the gist you can easily guess things. If things are really weird we can always rename them.
reply