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

I think it's time to give Nix a chance

maych.in

Post reply on HN
Print view View original

21–30 of 156 posts

Re: I think it's time to give Nix a chance

#21

Post by sepositus »

urlwolf wrote: post #2

I moved to nix around Nov last year and couldn't be happier, the motto 'nix fixes that' is true. First time I can say linux is trouble free. Upgrades are painless. Dev environments, reproducible. Largest repository of packages in the linux world. Next to zero time wasted configuring things. Foundation LLMs now know enough nix to get you out of trouble most of the time. It's perfect as a linux experience.

Welcome to the honeymoon phase. Mine lasted about a year. Eventually you will have to leave the comfortable area of "those who have done it before" and engage with some long, unwieldy, mostly undecipherable stack trace.

When I asked a long-time Nix vet why he thinks people leave, he provided the most insightful answer I've seen yet: they just don't try hard enough.

Re: I think it's time to give Nix a chance

#22

Post by bigyabai »

spenczar5 wrote: post #12

Something I have always wondered about is how Nix interacts with my editor and language servers. I use emacs. The emacs LSP mode starts up a language server process for a language like Python or Go. If I use Nix to manage development dependencies like my compiler, linting tools, and even language-specific dependencies, then how do I get the LSP and emacs to use the correct Nix-y set of dependencies? To make things ex…

The "correct way" is flakes, but I don't know if it would cover every edge case. I don't use emacs, but I'd assume you'd arrange it a bit like this:

- Install nixpkgs emacs or emacs distribution to your user profile so it links into every shell you open.

- Configure system-wide settings with the default emacs config, or with home-manager (https://mynixos.com/home-manager/options/programs.emacs)

- Each project (or group of projects) gets a Nix flake with a derivation specifying which dependencies or LSP packages are needed.

When a devshell is spun up, you should have the nixpkgs version of Emacs with your system-wide config and project-specific modifications, handled via version-control. It is a hassle, but in my experience the ROI is very worthwhile. YMMV.

Re: I think it's time to give Nix a chance

#23

Post by johnisgood »

mplanchard wrote: post #17
johnisgood wrote: post #6

Earlier quoted context omitted.

Which makes "next to zero time wasted configuring things" false, very much so. You will have to write your own derivation(s) using Nix[1]. In any case, from the article, what does not apply to Guix, too? I am leaning towards Guix because of its language (Scheme, i.e. Lisp-y), but I wonder about the differences between the two, today (besides userbase and hype). [1] https://nix.dev/tutorials/nix-language.html

Mainly the mindshare. Nix has a massive set of packages. You’ll have to build more derivations for guix.

I assumed that, but "only" that? I genuinely wonder. I did not get around to try Nix yet.

Re: I think it's time to give Nix a chance

#24

Post by i915 »

zachlatta wrote: post #3
urlwolf wrote: post #2

I moved to nix around Nov last year and couldn't be happier, the motto 'nix fixes that' is true. First time I can say linux is trouble free. Upgrades are painless. Dev environments, reproducible. Largest repository of packages in the linux world. Next to zero time wasted configuring things. Foundation LLMs now know enough nix to get you out of trouble most of the time. It's perfect as a linux experience.

Can you link your dotfiles? I’ve been having trouble figuring out a good way to structure mine

Try using https://github.com/numtide/blueprint

Re: I think it's time to give Nix a chance

#25

Post by bigyabai »

mplanchard wrote: post #20

An unexpected benefit of nix for me was CI caching. It’s easy to set up S3 as a binary cache, and then anything you can express as a nix derivation can be cached so that if nothing has changed, it avoids a build. One fun example is the test database: five years of accumulated migrations were relatively slow to run in various portions of the pipeline. I made a nix derivation that runs postgres, runs migrations, seeds…

My last gig was at a place where a guy basically wrote his own job security by reducing a 1hr 40min JS build pipeline down to 2 minutes with Nix caching.

Re: I think it's time to give Nix a chance

#26

Post by sepositus »

krapht wrote: post #7

I tried to give Nix a chance but I never figured out how to package dependencies that didn't already have a derivation written for them. Particularly since I do a lot of ML work - I never figured out how to handle mixed Python/C++ code with dependencies on CUDA. It's just way easier, even if not reproducible, to build an environment imperatively in Docker.

The most common answer I've seen is that Python packaging just "doesn't do it right" so it's impossible to get a clean Nix experience with them. Which, to some degree is true, but it also reveals the opinionated nature of Nix and why it often falls flat.

Re: I think it's time to give Nix a chance

#27

Post by ayrtondesozzla »

johnisgood wrote: post #6
TeeMassive wrote: post #4

Earlier quoted context omitted.

Until your use case hasn't been deciphered by a Nix scribe and then you have to fight the magic.

Which makes "next to zero time wasted configuring things" false, very much so. You will have to write your own derivation(s) using Nix[1]. In any case, from the article, what does not apply to Guix, too? I am leaning towards Guix because of its language (Scheme, i.e. Lisp-y), but I wonder about the differences between the two, today (besides userbase and hype). [1] https://nix.dev/tutorials/nix-language.html

Agreed on Guix. Used it for a few years, absolutely loved it, excited to go back (had to move off for unimportant and unrelated reasons).

Would love to hear from someone who has used both though.

I've never seen an excellent, detailed comparison actually, as conversation on the subject tends to devolve into a "discussion" on ethics. Meaning, people who dislike GNU or GPL or Lisps or something get testy and argue uncharitably (imho, please prove me wrong, not flaming here, etc).

This is ironic, to say the least, as one of the main points of the proponents of the "anti-GNU" side tends to be how Guix is too opinionated and pushy and hard-line etc. So we've a classic upside-down situation, which is a real shame, as Guix seems to be in reality a practical project with lovely people involved that's doing very interesting work.

Re: I think it's time to give Nix a chance

#28

Post by atrus »

blueflow wrote: post #9

Yes, but: du -sh /nix I specifically remember the glibc 2.26/ucontext desaster that triggered an rebuild of the nix world and exhausted all disk space that i had.

Yeah, if you only have nixos on a space constrained device (like my poor old chromebook), you're going to have a bad time.

The plus side though if you go all in is that you can build once on something more powerful and just copy the updates to the low powered stuff.

Re: I think it's time to give Nix a chance

#29

Post by dbalatero »

I recently had to switch back from Nix, as the way it operated clashed with the corporate IT security controls on my work laptop and prevented me from using it.

I just went back to Bash and it honestly works just fine, any rough edges probably don't outweigh how inscrutable Nix tends to be: https://github.com/dbalatero/dotfiles/blob/main/apply

Re: I think it's time to give Nix a chance

#30

Post by __MatrixMan__ »

weinzierl wrote: post #11

What is the supply chain security story with Nix packages? I stick mostly to reasonably popular Debian packages. My thinking is that if one of them has a serious vulnerability it will get fixed quickly or a lot of people have much bigger problems than me. I always worry about niche package systems, where it should be much easier to sneak in something malicious and it could linger there for a long time undetected.

As I see it there are three components of software supply chain security:

- is this actually the binary that comes from that code?

- is that code trustworthy?

- is this binary trustworthy?

Nix focuses on the first. If you can solve that problem, there's still nothing preventing bad guys from publishing malicious code, or from distributing malicious binaries which did not actually come from the code that they claim to, but it forces them to act in the open where they're more likely to get caught--anybody can verify that the correspondence between code and binary doesn't hold.

So if you're worried that one dark day, `curl whoever.com/whatever.sh | bash` will suddenly contain malware when it didn't before, using nix instead will protect you... until you manually approve the malicious update. It's up to you to come up with reasons why you should or shouldn't do that, but at least there will be a commit in your code where things went bad.

If you're wondering whether whatever.sh is safe in the first place, and you want some council of elders to pinky promise that it's safe to run, then I don't think the nix ecosystem has much to offer you.

Personally, I think that solving the latter problems without a robust solution to the first problem is sort of a band-aid solution. So I'm a big fan of the nix approach to supply chain security, but it's important to be aware of what you're not getting, which is a promise that any bits are trustworthy in the first place.

Post reply on HN