Live data from Hacker News

I think it's time to give Nix a chance

maych.in

51–60 of 156 posts

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

#51

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

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 unch…

The Guix blog has really good and detailed discussions of things Guix has done differently than Nix! Posts on the choice of different abstractions for modeling services in Guix is probably a good starting point.

The UI differences are also striking right away. Guix has a more unified CLI, and the main Guix repo seems to more quickly absorb functionality that's split into various community projects in Nix.

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

#52

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.

Guix already has as many packages as Nixpkgs did back when I started using it, and like Nixpkgs, the package set is growing exponentially. What you say is true but it also seems to me like for many, Guix already provides a very useful starting point.

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

#53
It is possible to use nix simply as a better Homebrew—one where you can update packages without all of your system potentially breaking from package updates. That has happened to many people with brew and it no longer happens to me.

That means `nix-env -iA `.

Is this approach using the full power of nix? No. But in a “worse-is-better” kind of way, just doing this has given me a more stable system than I had with Homebrew. And that’s all I wanted from nix. Flakes and nix-shell are just additional things that I’ve gotten some benefit from over time.

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

#54
I recently installed NixOS on my laptop after years of using Debian, and the main difference I noticed was that it's much easier to keep everything clean.

For example with Debian I might do something like try to get my GPU to work by installing nouveau, try various configs, then uninstall nouveau and install the Nvidia proprietary drivers. But then when I finally got the GPU working, I'd worry. Are some of those config changes I tried for nouveau still affecting my system? Has all that mucking around left my GPU forever in a suboptimal state?

With Nix, it might take just as much tinkering to get the GPU to work. But once I'm done, I know that my system is exactly as I've defined it in configuration.nix. Anything else I tried along the way will just sit inertly in /nix/store until the garbage collector wipes it away.

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

#55
post #43

Earlier quoted context omitted.

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.

FYI by calling it "job security" you imply that this nix caching approach is unmaintainable.

He made himself useful by practicing an uncommon skill, so I understand why it was put that way.

But Nix is plenty learnable and Nix hires are possible, so I see what you mean.

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

#56
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.

     du -sh /nix
    187G /nix
This is with

    nix.gc = {
      automatic = true;
      dates = "weekly";
      options = "--delete-older-than 30d";
    };
Cleaning up some direnv versions and a `nix-collect-garbage --delete-older-than 5d` would bring it down to around 40G. For me this isn't _too much_ space, but it's easy for an update to download multiple gigs, so something to keep in mind I guess.

The size of the nix store has never really caused me issues, but ending up with a full `/boot` has. I now always set `boot.loader.systemd-boot.configurationLimit` to avoid these issues.

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

#57
post #35

For me it is another Gentoo. I had my time trying every new distro that would be popping up on Linux related magazines CD/DVDs up to the mid-2000's (they still do in some European countries), unless it comes on a laptop I can get at the mall computer store, or some customer imposes it on our delivery contract, not really something I want to give a chance to.

> I had my time trying every new distro that would be popping up on Linux related magazines CD/DVDs up to the mid-2000's

Me, too! That was a blessed part of my childhood and adolescence.

You're not entirely wrong about the comparison to Gentoo, but I do think NixOS is more practical than Gentoo.

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

#59
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.

I do a lot of ML work too and recently gave NixOS a try. It's actually not too hard to just use conda/miniconda/micromamba to manage python environments as you would on any other linux system with just a few lines of configuration. Pretty much just add micromamba to your configuration.nix plus a few lines of config for nix-ld. Many other python/ML projects are setup to use docker, and that's another easy option.

I don't have the time or desire to switch all my python/ML work to more conventional Nix, and haven't really had any issues so far.

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

#60
post #45

Earlier quoted context omitted.

> some customer imposes it on our delivery contract It's happening: Companies are adopting Nix [0] and you may see such requirement come up some time. [0]: https://github.com/ad-si/nix-companies

In the bubble I live on, classical VMs have become the exception nowadays, containers and serverless deployments are the rule now. I am yet to see any classical VM deployment isn't one variation of Debian, Ubuntu, Red-Hat, SuSE. Note how that list has a certain startup feeling to the company list, not boring big corp.

Even if classical VM deployment, I still see a ton of containers. Like our database servers Ansible playbook which run Ubuntu are "Setup OS, mount disks, install docker apt repos, install stable docker, run container.

So Nix would let us avoid the Ansible playbook by just installing the Nix file but Ansible playbook is extremely rock solid so it feels like a problem we don't have. Also, we do pay for support for Cassandra to someone and while they officially would support us running on Nix, it's clear their support technicians are much more comfortable with RH or Debian based systems.

Post reply on HN