> 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).
> Main reason for leaving was that Nix package maintainers have to heavily patch all software.
Any widely used distros do this. Plus, the statement that you have to patch all packages is false. In many cases, all you have to do is set the right build flags and environment variables, which is handled by standard helpers in nixpkgs.
I'd also like to add that nixpkgs has the most extensive testing for packages compared to any other distros I've seen.
> Packaging for nix is more like porting software to another operating system.
Dramatic, but again, simply not the case.
> note that they have automated tools for patching the most common problems, so the problem is even worse.
This is a good thing. Manual patching for the most common problems isn't sustainable, especially if you maintain a large number of packages. Just ask packages maintainers of any major distros.
> I was able to merge some pretty large patches to nix-packages from an anonymous and sketchy-looking github account, and they weren't scrutinized much
All packages in nixpkgs has a mandatory review process as you should very well know. As scary as you make it sound, I'm pretty sure at least one committer have taken a look at your code to see if there was anything malicious in it.
> Moreover, Nix breaks the chain of trust for the language packages.
After a quick look, it seems like you can still use the unmodified erlang package manager? The patched version you've mentioned seems to be there for facilitating creation of Nix packages and it looks like the main intent was to remove the ability to download packages from the internet. If this is the case, it wouldn't be a security problem at all because the dependencies would have to be prefetched and their hashes precomputed.
> /nix directory is readable by all users, so you cannot use Nix to manage secrets
Why not store secrets in a private location, just like you would on any other distros??? What is it that other distros have that Nix is missing? I'm not seeing your point here.
With that being said, note that this feature is being worked on, and systemd very recently introduced a new feature for secrets management [1].
> You cannot install opam packages without dealing with incompatiblities, you cannot easily install games from Gog without dealing with incompatibilities
Matbe take a look at buildFHSEnv.
> do you really need such degree of reproducibility for your very own dev machine?
Yes, it saves me from having to do a clean install of my system every few months. I haven't done a clean install at all the last few years since I started using NixOS.
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.
> I don't know what software you were using, but it doesn't sound like Nix.
I love how the initial reaction by every Nix user is to imply I'm a liar or just titanically stupid. Like it's not possible that a relatively new linux distribution that has just undergone a major overhaul of its package management system might still have bugs or issues.
No. NixOS is perfect for everyone today. Just completely rewrite every deploy script you have from the ground up. Having trouble? Don't worry! The documentation is "getting better."
> Your scripts should be part of a package. I don't know about Nix, but in Guix we have a build step that patches shebangs to remove the nasty /usr/bin things and replace them with references to the right executables in the store.
Sorry, but I will not be writing an OS-integration package for every specific software deploy during development. It's unlikely to even imply that I should be doing this during development just to get off the ground. I tried to use NixOS as an environment for development for Golang and Java and found it frustratingly at odds with all existing tooling. The only languages I found that seemed well supported was haskell and C, and I don't ship code on either of those platforms anymore.
It was doubly unlikely early this year. The documentation was in utter disrepair and more than two Nix developers told me on twitter, "It is very difficult to do unless you are a contributor." It was also the case that many pre-existing packages were done incorrectly, still suffering these problems. Golang's package was one of them.
> but that has no bearing on whether or not you can run the resulting binaries on another machine.
Copying a closure to deploy software projects currently in development is an extremely intensive step, and many packages had outstanding bugs that don't do this.
Furthermore, existing deploy tools like Puppet, Salt and Ansible all have extreme difficulties managing this model, but Nix (at least at the time I examined it) didn't offer very good tools for actually distributing said closures in a cloud services environment.
> Container images are not reproducible. You and I can build an image from the same Dockerfile and I guarantee that the checksums would be different.
It's not the responsibility of the dockerfile to maintain this immutability. It's the responsibility of the environment the dockerfile is executed in.
Which is probably why Golang was specifically such a problem, it has a really miserable story for actually making reproducible builds with locked deps.
Given a specific git SHA for a project with locked dependencies, it is absolutely reproducible and will produce the same image SHAs every time.
P.S., at the time NixOS was going through a major update and it was possible to install a version of Nix onto NixOS that was not entirely compatible. This ruined the install while still using Nix commands. If that bug has been fixed, great, but it was a known issue and I was not the only person in IRC asking for help with it. You lost your ability to roll back.
> Now if we can just get the UX together, it will be incredible.
The crux of the NixOS issue right here. I tried NixOS a few times, even this past weekend, and it was such a pain that I gave up each time!
I am planning to integrate Nix (the package manager) into my recent fresh OS install if I have some time this week. I want to use Nix to have, at the very least, a controllable way to install and remove toolchains of different versions in a reproducible manner; if I can swing it I am going to use it to install pretty much anything that requires any sort of configuration care (the rest I'll just use apt). I also want to integrate more tools like asdf or pyenv which help with that, but I prefer if I could do it all through one package manager like Nix. I finally separated my /home into another drive this time, so that'll be nice for future re-installs.
>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.
> Nix has some great ideas but when the install of emacs took 10 times as long as homebrew, then didn't work correctly it didn't leave me wanting to use it for anything work related like my docker images.
I understand it's not fun to watch a long build process finish only to have the final product not work, but that assessment is not really fair. Nix itself is not the problem there; the problem is in the definition of that package. The same thing could just as easily occur in a package defined in homebrew. Saying that nix itself is at fault when an individual package (among hundreds of thousands) is faulty is sort of akin to encountering a buggy program and equating it to a bug in the language the program was written in.
I'd also add that due to the closed-source nature of OSX core libraries, it's hard to achieve the same degree of robust determinism in OSX that nix allows in other platforms. Fortunately things tend to be very solid on Linux. My company has been using Nix in production for about a year now and it has been a huge benefit to platform stability and speed of deployment.
> Nix is an idea which detracts from traditional package management by concluding that ranged dependency versions actually create more problems than they solve
That may be the right choice for the kinds of packages that Nix targets but not for other language's semantics. For example, I wrote the package manager for Dart and it specifically intentionally does use versions because forked shared dependencies don't play nice with the language's semantics.
> The solution is to provide a system wide daemon which facilitates native installs required for by the language, whereby the LSPM can query and request the installation of packages over a well defined protocol, and the daemon forwards those requests to a system-level PM.
That's a large ball of complexity and dependencies. It isn't clear that that's actually a more effective solution than just rolling a package manager for each language.
> The identity-based approach to dependencies means that when building a package, you're always going to be building against dependencies the developers intended - because they're the same ones he/she tested against.
That doesn't play very well with shared dependencies in many cases.
Ultimately, every package manager has a bunch of policies embedded in it. Things that it just decides are The Way Stuff Should Work. Those policies are heavily influenced by what how the programming language is used.
Trying to find the One True Package Semantics seems like a lost cause to me.
> I don't want a 'journey' to use my OS. I don't want to learn a whole new language and set of overengineered abstractions to solve what I see as, at most, 5% more of application installation problems that are already 75% solved by package managers[0]. If the Nix community wants more people using Nix, they'll have to make it more attractive for those of us who do not want to waste so much time needlessly learning new stuff to do the same things we're already doing.
This is fair, but keep in mind that package managing is only a small part that what Nix solves, and it is a much superior solution than anything else that I know (Docker for example is not really reproducible because you can't trace all dependencies; this seems like a philosophic issue but I saw some containers breaking because some dependency inside the container was updated without nobody knowing).
If we take NixOS, it also solves the issue with configuration, and with some auxiliary tools it also solves issues with deployment. You have alternatives for both of the issues too, but the fact that NixOS is much more integrated than any tooling (like Ansible, Puppet, etc) means you have much more flexibility. Also, don't forget atomic upgrades and fallback.
Eventually, instead of "wasting time", NixOS starts to save time by becoming the most reliable OS you ever used: you will never waste time anymore reinstalling your system from scratch, or if your hardware broke, you will never waste days trying to get your system to the same way it was. Also, because nixpkgs is enormous, you also tend to save time by not looking at "oh, this program seems cool, how can I install it on my computer since I never heard of this XYZ language?", and them installing the package manager from the language in 5 different ways because you have no clue. And even when you need to package the program yourself, nixpkgs has many abstractions that makes it much easier.
So instead of wasting time, Nix and NixOS is an investment. You may choose to invest your time right now to save later or not. Either way is fine.
Just to finish the topic, I fully concur yo you that we as a community needs to have better documentation.
>> ... and not have it installed globally is amazing.
Yah, the more I think about it this is the biggest selling point to me.
>> Of course, you can use the nix package manager on any Linux distro and even macOS if you want a gentler introduction.
I actually never thought deeply into nix NOT on nixos (I've probably been conflating the two). As an infra/devops-y person I can think of a lot of cool use cases off the bat in the server-space (theoretically anyways, I've a feeling the details would be quite the devil). But, except for the case of developing for such a system, I'm struggling to see a use case that warrants it in the desktop realm. (I need to meditate on this one..!)
> 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.
> Plus the entire thing is in flux right now between flakes, home-manager, and a desire to kill nix-env.
This is my big gripe with Nix. There are so many things that are almost ready, or almost integrated, and advanced users are typically already using them. It makes it feel like next year will always be a better time to recommend Nix to newbies.
And a lot of the more ambitious contributions to Nix and Nixpkgs that are really, really exciting as a user tend to sit in pull request limbo for a very long time, sometimes dying on the vine. Guix doesn't seem to have that problem yet, but I don't follow it as closely.
It's painful to feel sort of totally married to it but also like I can't whole-heartedly recommend picking it up to most people I know who might enjoy it once they got going.
> The gist is that NixOS has some weird dependency management that overrides Home Assistant's
In other words, NixOS does what every other distro do and package every dependency required to run the application beforehand. HA devs appear to be claiming in almost every single one of the linked discussions that the Nix package is broken, but I can't find them pointing to any concrete evidence or specifics. I doubt they have any, because they can't have tried it out in a matter of few hours.
> And NixOS is not done repackaging HA
HA devs appears to be making a whole point out of this too, but it's quite overblown considering that the example being listed is a dependency that was introduced only days prior [1].
> HA doesn't want to support that and was pretty clear about it.
Did you see the Nix devs' proposal early on about requiring users to set the option `config.ambee.acceptThatThisPackageIsNotSupportedByUpstreamDevelopersAndIWillGoToNixpkgsToReportAnyIssues = true` [2] in order to be able to use the package? That was met with immediate hostility from HA devs.
> Then this Jorg person got all up in arms and threw a hiss fit all over the internet and everybody got tense.
That's likely not the impression people get from looking at any of the mentioned links, which is presumably why the prior HN thread mentioned in GP seems to have blown up. If anything, it makes me think twice about using HA myself because I fear this is the standard response I'd get from HA devs if I ever dare file an issue.
> 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.
> I think the problem with Nix is that it is actually not a package manager but a build tool (that provides some package management utilities). People try Nix with the assumption that it should be as easy as apt-get (for example), but found tutorials with a block of code in a weird language...
Indeed, I've been using Nix for many years (on Ubuntu, NixOS and macOS), and I now find the apt-get style 'considered harmful'.
Instead, I define a single Nix derivation ("package") which provides everything I want in its 'bin/' directory, e.g.
with nixpkgs;
buildEnv {
name = "my-macbook-programs";
paths = [ bash gimp /* etc */ ];
}
The nix-build command creates a symlink called `result`, so I put `/path/to/my/git/repo/result/bin` in my $PATH.
> 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.
> It feels like you're being unnecessarily hostile, here. He didn't address your specific problem as stated, but he did add to the discussion.
You're right, sorry for the tone. The thing is, it sounded an awful lot like a blatant attempt at derailing the discussion by shoehorning span to promote a build tool. Nix does not solve anything, particularly as it was being proposed as a solution to a problem that plain old Debian packages do not have. So if Nix solves nothing and Nix adds nothing to the discussion then why waste everyone's time by adding noise by selling a tool that does and solves nothing wrt plain old Debian packaging?
> If people started using Nix recipies instead of Docker or janky bash scripts for deployment of Hadoop and other complex software, most of this article's complaints would disappear.
...or simply build a plain old Debian package?
Is it that hard to simply follow the happy path of packaging for Debian?
Why is suddenly Nix the only option on the table, specially as it brings absolutely nothing to it wrt what plain old Debian packages already provide for decades now?
> I've never really understood the use case for nix-env.
If that's the case, perhaps `nix-env` shouldn't be mentioned as the command to use to install packages on search.nixos.org?
I checked the NixOS manual right now but the last time I did, it instructed to use nix-env to install packages. The declarative package management using configuration.nix wasn't highlighted before as it is now.
This is exactly the kind of thing the parent comment mentioned. I'm not willing to go through these kinds of papercuts to get whatever NixOS has to offer with its radical changes.
Oh, and the nix package manager is still unbearably slow. It reminds me of my (unpleasant) time using dnf. Once you're used to package managers like apk and pacman, its an extremely jarring experience to stare at your screen and wait for a package to get installed.
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).
reply