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

How Nix and NixOS get so close to perfect

christine.website

Post reply on HN
Print view View original

141–150 of 183 posts

Re: How Nix and NixOS get so close to perfect

#141

Post by ravi-delia »

GekkePrutser wrote: post #29
jordanbeiber wrote: post #24

Earlier quoted context omitted.

I probably appeals most to developers as sharing application development environments with shell nix files is totally awesome. I must say that using nix on my primary workstation makes it feel like an appliance. The system generation roll-back have saved me a lot of times when an application update brings a regression.

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.

Re: How Nix and NixOS get so close to perfect

#142

Post by infogulch »

xena wrote: post #55
atoav wrote: post #3

As someone who really would like to have something like nix the thing that scares me away every time is the fact that the people creating this aparently did not think a lot about how to onboard users. And I don't mean a lack of documentation — what I mean is that the obvious decisions that have been taken (naming everything "Nix", using Haskell as a base for the syntax, ...) don't really fill me with confidence that…

I've been working on things to help onboard people. If you wanted something to help onboard you with NixOS, what would you want to see?

Maybe nix needs to organize docs around the users intention:

https://documentation.divio.com/

The big idea is that it separates types of documentation by its usefulness to a particular user that is approaching the docs with a clear goal. Here the goals are loosely organized along two 'axes': working-studying and theoretical-practical. Personally I think the model is missing a user-developer axis (especially for a developer tool like nix), but overall it's a great lens to view any documentation project through.

Re: How Nix and NixOS get so close to perfect

#144

Post by _y5hn »

deltaonefour wrote: post #120
atoav wrote: post #3

As someone who really would like to have something like nix the thing that scares me away every time is the fact that the people creating this aparently did not think a lot about how to onboard users. And I don't mean a lack of documentation — what I mean is that the obvious decisions that have been taken (naming everything "Nix", using Haskell as a base for the syntax, ...) don't really fill me with confidence that…

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 .jar file. I saw no way to change that config anywhere. Things like that make it not worthwhile unless you're doing something that makes it worthwhile.

I think docker / K8s probably fits better in those usecases anyways, though I do use nix / guix at times for packages that work properly.

I think requirements and plain ol' luck (or never needing anything fancy) can play a bigger role, for those of us who sometimes distro-hop a bit.

Re: How Nix and NixOS get so close to perfect

#146

Post by n42 »

lab14 wrote: 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 lesson worth sharing about Nix.

Re: How Nix and NixOS get so close to perfect

#147

Post by sciurus »

xena wrote: post #53
tjoff wrote: post #48

Earlier quoted context omitted.

How does that have anything to do with it being imperative and not the fundamental design of the system? How nix is architectured is exactly why it achieves purity and reproducibility, not the configuration language. It isn't even a goal of ansible in the same sense, per design. The building blocks of nix is simple, of course it can be implemented in something imperative.

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 the current state to your desired end state.

You are right though that they can produce unexpected results since they do not describe the entire system from the ground up.

Re: How Nix and NixOS get so close to perfect

#148

Post by encryptluks2 »

viraptor wrote: post #72
encryptluks2 wrote: post #32

I'm starting to see more of a cult attitude with Nix. It is like the Arch Linux crowd (I use Arch) but much worse. I think is is great that Nix has provided something valuable to a lot of people, but so does a lot of software and tools. Nix fills a void in package management. It is like Ansible or Terraform for a semi-idempotent distro. It is probably quicker in most ways than building something similar with other co…

> It is like Ansible or Terraform for a semi-idempotent distro "Like" does a lot of work here. Those systems go one way: what if we applied this concept to managing existing systems. Nix goes the other: what if we built a system around this concept. I think that's a nice elevator pitch, but misses a lot otherwise.

> Nix goes the other: what if we built a system around this concept.

This is what I'm referring to. There isn't anything currently as far as I'm aware that takes it as far as Nix. Sure, Arch has archinstall and there is also cloud-init.

There are examples of using JSON to help manage that:

https://github.com/archlinux/archinstall/blob/master/example...

But, ultimately I believe a lightweight Go/Rust tool that takes a YAML file and does essentially the same thing will prevail.

Re: How Nix and NixOS get so close to perfect

#149

Post by senorsmile »

smasher164 wrote: post #132

I think Spack[1] might address some of the problems surrounding Nix. It uses python to configure packages, and the upcoming release will have Windows support too. The "Getting Started" information is pretty helpful, but package-level documentation still needs some work. [1]: https://spack.readthedocs.io/en/latest/

This is interesting. Thanks for the link.

Re: How Nix and NixOS get so close to perfect

#150

Post by mamcx »

I changed a mix of dockerkiles, shells, configs and others things to a SINGLE nix file.

Is truly great.

About complains:

- Nix as "language": Is stupid, that is true. As any other stupid language on this space, name it: bash (TERRIBLE), docker, yamls, pseudo-TOMLs, etc. So is not that worse than the median. I wanna know what other real option is here, except use a language as python instead.

- Documentation: Is not lack of it, is how spread and badly stitcher together. is like docs made by JavaDoc. But I remember Docker at first, and I waste as much googling as with nix. Docker is not intuitive at all, and worse, it change per distro!

The actual thing is easy, and the best thing is just look at the code. Most of it is not that hard to figure than docker files, yamls, etc.

What was very confusing is the idea of how each config are done. Exist many things that are not "together" like setup NGINX also need to touch the firewall, then maybe systemd.

Is not different to deal with unix, that is a mess, is that at first you think all is "just work" by default.

More exactly: Not exist a clear convention that is applied everywhere. Lack of uniformity is the main trouble. Still, same as other tools in this space.

Also: Very hard to debug things.

Also 2: The hack around "home manager" to manage user config is a hack. Make not sense: I use too much time trying to do it "natively". Do it manually in *nix is so simple "just cat/touch this file in this path", so is the main reason I almost drop it.

---

The whole migration for me take 1 week. That is not that much than before the first time I doit with custom docker files (One of the companies I work for before I use 2 weeks making it. This was when alpine/small containers were not as common as today).

So, YMMV but the end-results is very nice.

Post reply on HN