Live data from Hacker News

How Nix and NixOS get so close to perfect

christine.website

151–160 of 183 posts

Re: How Nix and NixOS get so close to perfect

#151
post #53

Earlier quoted context omitted.

Think about it like this: with Ansible you start from some unknown state of the system and then iteratively do actions to hopefully get what you want. With Nix you know what the base state of the system is, and the configuration language lets you describe your desired end state. Then the computer figures out what to do in the middle. The fundamental design of Ansible is that you do imperative steps to reach an end st…

> The fundamental design of Ansible is that you do imperative steps to reach an end state. No, the fundamental design of configuration management systems (Ansible, Puppet, Chef, Salt, CFEngine) is that they are declarative. You say "this software should be installed, this user should exist, these files should have these contents and permissions, etc" and they figure out the right steps to take on your OS to move from…

That's fair, though ansible has ordered steps, so it's not entirely declarative.

You are right that imperative definition is not a problem for reproduceability, but it does make things harder to reason about since you have to mentally keep track of state between steps.

Re: How Nix and NixOS get so close to perfect

#152
post #59
post #42

Earlier quoted context omitted.

What a bad analogy. Betamax was superior to vhs.

Yes and yet it failed. That's what GP is saying: Guix may well be better, but it is even less popular than Nix and thus at (greater) risk of dying.

I don’t think GUIX will ever die, it seems to be the GNU Foundation’s favorite. It’s the only GNU-approved distro whose website is a sub domain of gnu.org. GNU seems to be unofficially standardizing on GUIX.

https://www.gnu.org/distros/free-distros.html

https://guix.gnu.org/

Re: How Nix and NixOS get so close to perfect

#153
post #144

Earlier quoted context omitted.

Whether it's worth it or not depends on your skill as a programmer, your IQ, and/or the amount of time your willing to spend on learning it. Smarter people can pick it up quicker while stupider people will need to spend more time. For stupider people, it's not worth the investment. On average I would say it takes maybe a couple months of wrestling with it to fully pick it up and you'll still encounter problems on occ…

While Nix / NixOS is very clever, I think this video enumerates enough pain-points why you'd not want to dabble with it for your 1-2 hosts at home. Only the security point is enough to convince me it sadly do not belong to our production or office-LAN. For most of us, it's a benefit/cost analysis. I've no doubt I can figure it out, but last time I tried, a package came with defaults that differed from just running a…

> pain-points why you'd not want to dabble with it for your 1-2 hosts at home

I use NixOS on my 2 hosts at home. It took about 3-months of tinkering with it and testing different things until I was comfortable to do that. But the headaches it’s solved make that investment more than worth it. Declarative config and reproducible builds are just amazing, I could never go back to a regular linux now.

Re: How Nix and NixOS get so close to perfect

#154
post #36

Earlier quoted context omitted.

I don't see how you could maintain purity and reproduceability with something imperative. I used ansible for a while and it was a mess that broke half the time and was difficult to maintain.

Doesn't Bazel do exactly that with their Starlark language based on Python? https://bazel.build/rules/language#mutability

Key aspects of Bazel are not imperative. For example the “load” functions commands must not be computed.

Re: How Nix and NixOS get so close to perfect

#155

But the current NixOS approach is terrible for maintainers and developers, there are so many that get burnt out due to the constant churn and lack of regression prevention.

Can you elaborate on churn and regression prevention? Haven’t heard of those issues before, but I’m relatively new to Nix.

Re: How Nix and NixOS get so close to perfect

#156

Earlier quoted context omitted.

> I don’t really think this is a problem at all? I mean, at the particular design point the language occupies there are basically three possibilities: How so? Where's the Java/Python-like languages in this consideration, why wouldn't those work? Or something more like Ansible? I'm pretty sure that you can express the same concepts for the most part in something imperative as well.

You could make a package manager or distribution along the principles of Nix with any reasonable language, of course. Insisting on first-order data (i.e. not functions) exclusively would probably have the standard problems of trying to cram into a declarative configuration something that really wants to be a program (“YAML ops”, programs-as-SQL-tables disasters like Windows Installer, XML hells like Ant and XSLT, etc…

> the result would just be miserable to program in; the F# people tried but mostly gave up.

Huh?

Re: How Nix and NixOS get so close to perfect

#157
post #103

Earlier quoted context omitted.

> soundly rejected by the industry That same industry which embraced PHP and JavaScript? Is that an authority, on what? Also, the industry hasn't rejected Haskell, it has just been learning from it very slowly. My prediction is this trend will consistently continue at the same glacial speed.

> That same industry which embraced PHP and JavaScript? Is that an authority, on what? It's a reflection of what the programmers want. Apparently they wanted syntax with braces and semicolons. Someone else pointed out elsethread that maybe it's not the syntax, but the semantics, that is being rejected here.

Nix syntax has braces and semicolons... the only similarity to haskell is in using juxtaposition for function application (though this is technically optional; nothing is stopping you from typing f(x))

Re: How Nix and NixOS get so close to perfect

#158
post #146
post #143

I’m a Staff Software Engineer in a Fortune 500. I’ve delivered a multitude of complex projects to production. Trying to setup Nix made me feel dumb and incompetent.

So you found a concept that didn’t come naturally to you. If you are as successful at this field as you want us to believe, you would probably have learned by now that all technologies click differently for different people depending on the context they bring in when learning it. I can’t imagine taking myself so seriously that I would write a comment like this. This is an opportunity for self reflection more than a l…

This sort of attitude is what keeps Nix from reaching a wider audience.

Re: How Nix and NixOS get so close to perfect

#159

What is the Nix approach to config files? I understand it allows for stable binaries, without dependency hell, easily installable, possibly multiple versions of the same package; and for easy rollback of the installations. Because code modules are versioned by hashes of their full dependency tree and build options. But configuration files? I once installed the Nix package manager on my Ubuntu, and installed some apps…

Update: I recalled what didn't work - Firefox had very ugly fonts. So it's not exactly as I said "nothing worked", just the result of the Nix try was unusable for me.

Re: How Nix and NixOS get so close to perfect

#160

Earlier quoted context omitted.

That makes sense, I never need to share my config with anyone else. Also I love the ability to mix packages with source compiled software, which is one of the reasons I use FreeBSD on my primary desktop. It does that combo really well with its ports collection.

I feel like FreeBSD is almost this middle ground between a typical package managed (?) system and something like Nix. I didn't wind up needing that middle ground, but just the few months I spent with it made it clear how well-designed it is. Only on Nix have I written and modified my own packages that much, and that's partly out of necessity.

That's true actually, the rc.conf file is a little bit Nix-like. It's basically a single file for all your configuration. Never thought of it that way.

Many applications don't obey it though. Makes sense because they'd have to make code specifically for FreeBSD and its marketshare is tiny.

Post reply on HN