Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What is Nix and why you should try it

yakking.branchable.com

Post reply on HN
Print view View original

91–100 of 201 posts

Re: What is Nix and why you should try it

#91

Post by sly010 »

pmoriarty wrote: post #31
nextos wrote: post #6

Earlier quoted context omitted.

I think biggest ones are i) nix command is a bit complex, but it's getting redesigned [1] & ii) nixpkg definitions sometimes contain a lot of cruft. I've found Guix and GuixSD, which are a GNU-blessed Guile Scheme-based reimplementation of Nix and NixOS, more aesthetically pleasing. Quite simple and elegant in fact. The major differences are that Guix DSLs are implemented on top of Scheme, whereas Nix uses a custom D…

One of the major turn-offs for me in regards to Nix was that it uses a ton of bash scripts. Guix's use of Scheme is a lot more elegant and powerful, and a lot less hacky than bash.

You could use nix the same way guix uses scheme. The lowest level operation in nix is not "run-this-bash-script" but "run- this-executable-with-these-arguments".

Re: What is Nix and why you should try it

#92

Post by taktoa »

zzzcpan wrote: post #28
philipov wrote: post #4

Earlier quoted context omitted.

Having never used Nix before, I would like to know what kind of usability issues it faces. For me, the biggest one is that I can't use it at clients running a Windows shop. That's a blocker.

Discoverability is a problem everywhere in Nix, from configuration options to documentation. Which makes it necessary to learn its weird poorly implemented functional programming language and read code. Then there is performance, it's very slow and uses a lot of memory making it impossible to use on a 512 MB vm, for example. If you just want a solution for your packaging management needs - Nix is definitely not it. N…

> Then there is performance, it's very slow and uses a lot of memory making it impossible to use on a 512 MB vm, for example.

No, this is just a side effect of the CLI user experience being garbage.

`nix-env -i ` is almost never what you want, because its semantics are to evaluate everything in nixpkgs, find the set of packages whose `name` attribute is matched by the given regex, and install all of the packages in that set modulo the equivalence relation generated by package `name` equality ignoring version numbers.

Instead, you should use `nix-env -iA .`, where `` is the name of a Nix channel (viewable via `nix-channel --list`, usually it is `nixos` or `nixpkgs`) and `` is a valid attribute path in the nixpkgs package set (these can be discovered by running `nix-repl ''` and tab-completing).

Re: What is Nix and why you should try it

#93

Post by ARussell »

rhn_mk1 wrote: post #33

My experience with Nix was a real pleasure, and a complete failure. I set out with the goal of building a development environment for a software I was working on. I thought - Nix sounds like a better Docker, where it's possible to choose package versions independently of the rest of the system. It's perfect for testing! I found the package description language refreshing - it was powerful without getting too complica…

This is very similar to my experience, as well. I tried Nix for over a year. It has excellent ideas and principles. In practice, though, I ran into so many bugs that were near impossible for me to figure out on my own. I personally didn't find the community all that helpful, either. YMMV.

Re: What is Nix and why you should try it

#94

Post by pfranz »

c3534l wrote: post #30

I'm gonna need a better reason to switch distros than that. I do think that is an improvement that needs to be adopted in the OS. But, I mean, it's not that much of a improvement over containers. I don't feel like it gives me, the user, that much more power over the OS and would be a feature that I would only use very rarely.

Well, you don't have to use NixOS, you can just use NixPkgs either as a way to familiarize yourself or to manage a project--personally, I'm hoping after a few things get fixed I can replace Homebrew with it.

Even though containers have had a lot of buzz and tooling built around them in the past few years, it's good to see how other approaches can solve similar problems with different pros and cons.

Re: What is Nix and why you should try it

#95

Post by joepie91_ »

georgewsinger wrote: post #48

We used Nix to vastly simplify the build process of Simula: https://github.com/SimulaVR/Simula Simula is a bleeding edge VR Desktop project for Linux; virtually all of its dependencies are highly novel and require building from source for almost any distro. Nix allowed us to reduce the effort to building our project from 1hr of sifting through build documentation to a single build command. Nix's only issue is that it…

So, OpenGL is a bit of a weird case.

Hardware is the one thing that actually varies between systems no matter how declarative your configuration is - this is normally not a problem, since the kernel abstracts it away.

The problem with OpenGL, then, is that every graphics driver provides its own set of OpenGL libraries that is subtly different from all the others. This means that applications need to be built against a specific set of OpenGL libraries from a specific graphics driver, and the kernel is of no help here.

That's fundamentally where the OpenGL issues come from; Nix packages typically expect the libraries to be semi-statefully provided in a `/run` directory. This gets especially hairy when targeting different distros.

EDIT: And because the package doesn't know what graphics drivers it'll be running against on non-NixOS, it can't automatically build against a copy of the correct drivers in nixpkgs either.

Re: What is Nix and why you should try it

#96

Post by taktoa »

bfrog wrote: post #76
taktoa wrote: post #12

Earlier quoted context omitted.

I strongly disagree. Creating a Nix package is significantly easier than creating, e.g.: an Arch package, from my experience. packageOverrides is really nice too.

Try packaging a postgres extension :-)

If you tell me which specific piece of software you tried to package, I can probably explain what is going on. I strongly suspect that it is either not Nix's fault, or an inherent tradeoff in packaging software (i.e.: not a design flaw, but simply a result of the correctness of package expressions being more tightly controlled in Nix than in other languages). The main exception to that statement that I've seen are cases where Nix works fine, but the Nix expression takes so long to build that iterating on it is very difficult. Luckily, there is a solution for that in the pipeline: "recursive Nix", which allows `nix-build` to be called _inside_ a Nix build sandbox, thus allowing safe memoization of things like `gcc`.

Re: What is Nix and why you should try it

#97

Post by taktoa »

xfer wrote: post #89
dhruvio wrote: post #19

I can vouch for the immense improvement Nix has made to my software development process. I use NixOS on my desktop and laptop. At the OS-level, it gets a lot of things right: reproducible, immutable system configs; lightweight containers; devops with declarative configs. At a software project level, nix-shell is an indispensible tool. Compilers and interpreters aren't even part of my system-wide config; instead each…

To me, when i look at new distro, i look for how well the repo covers binary packages, i have no time/resource to build compilers/big projects. Last time i checked nix, there aren't that many packages in repo to be usable on laptop. But the package manager itself might be a good idea for dev environments, but all the languages i use provide similar facility(not counting system-library dependencies).

I'm confused by this statement. `nixpkgs` contains tens of thousands of packages, the majority of which have binary substitutions via the NixOS Hydra build farm. Usually the only time I build things from source on my NixOS laptop are when I override some package to use a patch of my own design. Hell, when I was using Arch Linux I found myself building things from source _way_ more often than after switching to NixOS.

Re: What is Nix and why you should try it

#98

Post by roblabla »

ben0x539 wrote: post #77
vog wrote: post #57

Earlier quoted context omitted.

Naive question: Isn't all that also true for Guix? If so, why do your prefer Nix over Guix?

Why shouldn't one prefer the original over some rando's weakly motivated, niche NIH rehash, unless you're already victim to lisp-induced Stockholm syndrome?

> some rando's

This is a GNU-approved fork

> weakly motivated

Has lots of strong motivation, like a stricter stance on non-free software, the usage of a "real", more expressive language (Guile) instead of a niche, poorly undocumented DSL (Nix), use of GNU Shepherd instead of SystemD for the init system, among other

> niche NIH rehash

It shares most of the codebase with Nix, so to say it's NIH is missing the point. Nix improvements are shared with Guix, and Guix improvements are shared with Nix

> unless you're already victim to lisp-induced stockholm syndrome

Different lisp offer different syntaxes, features, and use-cases. That you cannot see it makes me think you didn't try too much, and are probably just trolling.

Re: What is Nix and why you should try it

#99

Post by georgewsinger »

joepie91_ wrote: post #95
georgewsinger wrote: post #48

We used Nix to vastly simplify the build process of Simula: https://github.com/SimulaVR/Simula Simula is a bleeding edge VR Desktop project for Linux; virtually all of its dependencies are highly novel and require building from source for almost any distro. Nix allowed us to reduce the effort to building our project from 1hr of sifting through build documentation to a single build command. Nix's only issue is that it…

So, OpenGL is a bit of a weird case. Hardware is the one thing that actually varies between systems no matter how declarative your configuration is - this is normally not a problem, since the kernel abstracts it away. The problem with OpenGL, then, is that every graphics driver provides its own set of OpenGL libraries that is subtly different from all the others. This means that applications need to be built against…

I agree that, given this description, it's a hard problem. But can Nix find a way to abstract away these difficulties?

There are also bugs. For example, non-NixOS users of Simula are forced to run this script: https://github.com/SimulaVR/Simula/blob/master/swrast.sh

This is because a nix package expects to find a driver in `/run/opengl-driver`, which isn't always present if you're not running NixOS.

Re: What is Nix and why you should try it

#100

Post by kccqzy »

k__ wrote: post #29
ldlework wrote: post #15

I have recently started looking into Nix to solve the problem of dotfile deployment to new OSX workstations. When you get a new laptop, you clone your dotfiles, maybe symlink them to your home directory -- and then what? Nix solves this problem for me by coupling my dotfile deployment with the installation of the related software. The learning curve has been absolutely tremendous, however. That said, the support on F…

Nice. I started using macOS 5 months ago and it felt a bit as a step back coming from Linux. Does Nix work good with macOS?

I should mention that on High Sierra there’s a bug with kill(-1, ...) that sometimes causes Nix builds to lock up the whole system.
Post reply on HN