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

My First Impressions of Nix

mtlynch.io

Post reply on HN
Print view View original

141–150 of 354 posts

Re: My First Impressions of Nix

#141

Post by SuperSandro2000 »

throwaway6835-8 wrote: post #12
nittanymount wrote: post #6

planning to learn/use ansible, wonder if Nix is ready to use ? have most functions/features ?

Go with Ansible unless you want to fully dedicate into Nix ecosystem and spend a lot of time learning it (and it's not easy, for example because of lacking documentation). Also Ansible is something you more often find in actual projects/workplace.

well, yes true, but ansible sucks and especially for small and chaotic projects where people just change things on the machines without reflecting it in ansible it is a nightmare

Re: My First Impressions of Nix

#142

Post by the_gipsy »

SuperSandro2000 wrote: post #130
the_gipsy wrote: post #78

Earlier quoted context omitted.

You can package simple python projects, but as soon as there are too many huge deoendecies that use CPython and whatnot, it becomes impossible to generate the nix derivation. I just use imperative python-venv + pip install on those.

> I just use imperative python-venv + pip install on those. The whole point of NixOS is to manage this and to get rid of those manual steps that are error prone.

I only do this on some work project that I don't touch often, as an escape hatch. Everything else is managed by nix.

Re: My First Impressions of Nix

#143

Post by SuperSandro2000 »

FpUser wrote: post #21

I have shell script with bunch of common functions to simplify particular tasks and then main script that when ran installs all needed packages, creates / copies various config files, pulls my C++ code from repo and builds my servers and installs those as daemons. It also installs cron jobs that execute backups / replication. It is smart enough to skip already performed steps and can safely run multiple times. It can…

Let me interrupt that in the middle and undo some steps by hand and it will probably fall on its nose. Nix can handle interruption in the middle of all build steps and can cleanly recover from them.

Re: My First Impressions of Nix

#144

Post by lillecarl »

gonehome wrote: post #125
thumbuddy wrote: post #107

Earlier quoted context omitted.

The biggest barrier to adoption unfortunately is not people's inability to explain what the tool is in my opinion. It's that the tool is incredibly complicated, extremely hard to walk someone through compared to alternative projects, and honestly... In my opinion the problem it attempts to solve doesn't really exist. I'll take an "impure" os or package manager over a pure one any day if complexity is a thousand fold…

This matches my experience with it so far. Extremely complicated and hard to understand, projects that use it have builds fail anyway except now with very hard to debug errors.

When a nix build fails it'll fail with errors from the build system the package uses. The upside is that your failure is now reproducible.

Re: My First Impressions of Nix

#145

Post by lolinder »

hamandcheese wrote: post #41
scandinavian wrote: post #37

Now that we have another Nix post, maybe someone can enlighten me about something I've been wondering about. I'm one of the maintainers of a popular django application. Someone made a nix package of the project, but we've now twice gotten invalid bug reports from people using the package because the package depends on "django_4" and whenever someone updates that nix package, the package for our project breaks. Of cou…

It seems like Nixpkgs aims to minimize the number of package versions in use at one time. Not just nix, most package managers do, it seems (i.e. you wouldn't expect to find different minor versions of Nginx in Debian, would you?) So by that same logic, there is only one version of Django 4. It is definitely possible with Nix to use the precise versions of what's in your requirements.txt, but I'm not sure if the Nixpk…

Doesn't this auto-upgrade behavior punch straight through the reproducibility Nix is supposed to be giving you? It's not exactly a functional build system if the results you get depend on when you download the dependencies.

(I mean, I guess you could say that time is an input to the function, but that seems to miss the point.)

Re: My First Impressions of Nix

#146

Post by lillecarl »

thumbuddy wrote: post #107
adamgordonbell wrote: post #92

Earlier quoted context omitted.

Explaining what Nix is seems like one of its biggest barriers to adoption. Part of the difficulty is it means different things to different people. My colleague spent a whole lot of time trying to answer this question and ended up with this: My main take away after spending some time learning about Nix is that it embraces the functional programming concept of a pure function. If I give a function a certain set of inp…

The biggest barrier to adoption unfortunately is not people's inability to explain what the tool is in my opinion. It's that the tool is incredibly complicated, extremely hard to walk someone through compared to alternative projects, and honestly... In my opinion the problem it attempts to solve doesn't really exist. I'll take an "impure" os or package manager over a pure one any day if complexity is a thousand fold…

You don't have to manage your system with NixOS to reap the benefits of Nix. It solves very real problems that very much exist, it might not exist if you're a one-man show deploying WordPress to GoDaddy though.

Barrier to entry:

1. Run the nix installer

2. Enable flakes

3. cd project

4. nix run

This ensures you run the package with every dependency except the kernel pinned to a hashed version. If dependency hell is not a problem for you, be happy!

Re: My First Impressions of Nix

#147

Post by SuperSandro2000 »

thumbuddy wrote: post #107
adamgordonbell wrote: post #92

Earlier quoted context omitted.

Explaining what Nix is seems like one of its biggest barriers to adoption. Part of the difficulty is it means different things to different people. My colleague spent a whole lot of time trying to answer this question and ended up with this: My main take away after spending some time learning about Nix is that it embraces the functional programming concept of a pure function. If I give a function a certain set of inp…

The biggest barrier to adoption unfortunately is not people's inability to explain what the tool is in my opinion. It's that the tool is incredibly complicated, extremely hard to walk someone through compared to alternative projects, and honestly... In my opinion the problem it attempts to solve doesn't really exist. I'll take an "impure" os or package manager over a pure one any day if complexity is a thousand fold…

> The biggest barrier to adoption unfortunately is not people's inability to explain what the tool is in my opinion.

That's simple: nix is a package manager and the language used by the package manager, NixOS is a Linux distro.

> It's that the tool is incredibly complicated, extremely hard to walk someone through compared to alternative projects, and honestly... In my opinion the problem it attempts to solve doesn't really exist.

From someone who is working as a DevOps Engineer for some years and managing Linux servers for a few years longer that thought is incredible naive. The problem of undefined and undocumented system state is a fundamental problem I encounter everywhere especially bad with legacy systems. I often do things on them blind and just pray for the best outcome, realising months later that some system was broken by one change I did and no one realised that for months.

> I'll take an "impure" os or package manager over a pure one any day if complexity is a thousand fold less and the learning curve doesn't require half a decade. Got stuff to do!

I thought the same first but unwedging Debian once a week on a different system is also not fun and a waste of time and having servers in some undefined state and no one who how the config is supposed to be and why or when it got changed, too.

The result in the end is that every system is different and unique and your Ansible playbook to run a common and good thought out task succeeds on 15 VMs and sometimes completely blows up the 16th because no one could have thought that the state of configuration there is so widely different.

Re: My First Impressions of Nix

#148

Post by superkuh »

p-e-w wrote: post #13

I've occasionally encountered projects using Nix, and I've casually browsed the Nix and NixOS websites, but I still don't have a clear idea of what Nix is. Is it a package manager? A build system? An operating system? A container platform? A sandbox? An automation tool? Which widely used, existing software tools is it analogous to?

Nix is a distro that admits defeat against dependency management and entirely gives up on the idea of having system libraries. Instead every application you want to run has to have all of it's dependencies explicitly stated and provided custom in nix style configs for each program. Usually this means someone else has done all this packaging work for you. They hate it when people call it containerization but it's effectively taking containerization to the extreme for every single bit of software on your system with no ability to not use containers.

But if, say, you want to compile a random C program you found on the web then it is up to your to now set up the build environment and provide all the libraries and deps to be able to compile and then run the program. Just running make or ./configure or cmake . isn't going to do it because those configuration setups won't have a system lib environment to check against. It seems like a really weird distro to chose as your desktop but makes fine sense in commercial enterprises we're you're going to re-build the world for all your software anyway.

Re: My First Impressions of Nix

#149

Post by ParetoOptimal »

thumbuddy wrote: post #107
adamgordonbell wrote: post #92

Earlier quoted context omitted.

Explaining what Nix is seems like one of its biggest barriers to adoption. Part of the difficulty is it means different things to different people. My colleague spent a whole lot of time trying to answer this question and ended up with this: My main take away after spending some time learning about Nix is that it embraces the functional programming concept of a pure function. If I give a function a certain set of inp…

The biggest barrier to adoption unfortunately is not people's inability to explain what the tool is in my opinion. It's that the tool is incredibly complicated, extremely hard to walk someone through compared to alternative projects, and honestly... In my opinion the problem it attempts to solve doesn't really exist. I'll take an "impure" os or package manager over a pure one any day if complexity is a thousand fold…

> In my opinion the problem it attempts to solve doesn't really exist.

It does, but some people are good at numbing themselves to it.

So they block losing a day or half day from lack of reproducibility out of their memory or recall it as "no big deal".

Re: My First Impressions of Nix

#150

Post by SuperSandro2000 »

gonehome wrote: post #125
thumbuddy wrote: post #107

Earlier quoted context omitted.

The biggest barrier to adoption unfortunately is not people's inability to explain what the tool is in my opinion. It's that the tool is incredibly complicated, extremely hard to walk someone through compared to alternative projects, and honestly... In my opinion the problem it attempts to solve doesn't really exist. I'll take an "impure" os or package manager over a pure one any day if complexity is a thousand fold…

This matches my experience with it so far. Extremely complicated and hard to understand, projects that use it have builds fail anyway except now with very hard to debug errors.

> Extremely complicated and hard to understand

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.

Post reply on HN