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

291–300 of 354 posts

Re: My First Impressions of Nix

#291

Post by jkachmar »

mteigers wrote: post #38
lvncelot wrote: post #7

I'm a huge fan of Nix, and I'm glad to have stuck with the often times daunting process of getting into it - and I have to agree with the author's point regarding the documentation. That's not a fault of the people who actually did sit down and document their process, or distill their learning path into a tutorial - I myself understand it well enough to use it, but not well enough to really explain it without confusi…

I'm curious if you have any pointers for whole Mac config with nix-darwin. This is something I've just started looking at and at the moment don't have much more than a nix-shell with some nice-to-haves. Any tips / tricks / guides are greatly appreciated.

not sure how approachable it might be, but i like to think the documentation isn't too bad for my personal stuff.

definitely nothing so well thought out as a tutorial, but i try to describe the structure & implementation of my approach + cross-link to relevant tools that i incorporate.

lmk if you find it useful at all: https://github.com/jkachmar/termina

Re: My First Impressions of Nix

#292

Post by ParetoOptimal »

thumbuddy wrote: post #270
ElectricalUnion wrote: post #263

Earlier quoted context omitted.

In my experience those "others" that "just wrote docker files" are exatly the ones that don't know how to build the system in a reproducible manner if their ci environment gets reset for some reason as they find out that stuff that was "supposed to be there, pinned and configured" wasn't.

In my experience the months required to get a handle on Nix is not worth the benefit(which is shakey in my opinion) compared to competing technologies. We don't have to agree, but that's my take...

You might want to look at things like:

https://devenv.sh/

https://www.jetpack.io/devbox/

Re: My First Impressions of Nix

#293

Post by drdaeman »

stayfrosty420 wrote: post #91

Nix reminds me about that xkcd comic about standards. It seems to be to be solving a problem solved in a much better way by other alternatives with the mindset of IT from a bygone era. I may just not really be the target demo, or maybe am just a huge idiot, but I struggle to see the appeal, especially when you hear about the occasional horror stories about complex and/or broken environments, or the vim-like overhead…

> or the vim-like overhead to learn it properly.

In my opinion, it's somewhat simpler than learning how to do Debian packaging properly (with emphasis on "properly", following all the modern best practices).

Quite a lot of folks that run Nix or NixOS write themselves decent derivations that could be (and frequently are) contributed to nixpkgs (of course, there are a lot of quirks/hacks as well). But I think quite a few folks who run Debian make themselves high-quality packages - e.g. why bother setting up cowbuilder and do the proper repo for gbp with all the pristine-tar branch oddities, when checkinstall does the trick.

Re: My First Impressions of Nix

#294

Post by sanderjd »

crubier wrote: post #69
hamandcheese wrote: post #8

> Nix, on the other hand, does have a concept of state. If you make a one-line change to a 200-line Nix configuration, it doesn’t have to re-do all the work from the other 199 lines. It can evaluate the state of the system against the configuration file and recognize that it just has to apply the one-line change. And that change usually happens in a few seconds. The author seems to have some misguided ideas about Nix…

Memoization is state. As a functional programming maximalist myself, I know it hurts a little bit, but still, Caching/Memoization is statefulness. That said, you are right that as a user of the system, that statefulness is abstracted from you and you don't have to worry about it (until some subtle caching bugs forces you to dive deep in the rabbit hole)

Yeah I really bumped on this. A cache is absolutely state. It is sufficient to say "a referentially transparent cache is a technique to store state while avoiding most of the drawbacks typical to storing state". This is already a big accomplishment! No need to also redefine the word "state" to make the technique seem even more magical than it is.

Re: My First Impressions of Nix

#295

Post by 0x69420 »

drdaeman wrote: post #284
0x69420 wrote: post #234

> Nix optimizes for local configuration yes yes yes yes yes. nix makes deployment feel bottom-up, not top-down. you understand how a system is constructed locally before you (optionally, if it's in your job description) graduate to doing devops stuff with it. that was the singular thing that hooked me; the functional reproducible stateless referentially-transparent cacheable stuff was just what kept me on board.

I'm not sure. Well, I mean, there are weird folks out there who may start doing large-scale things without understanding what they're building upon (Kubernetes is not exactly an OS, but is a notorious example), but they could make the same mess with any technology. They're just unlikely to pick Nix, NixOS or NixOps (or any alternative to it), because mainstream tutorials won't cover it [yet]. The deployment and learn…

well, an anecdote for an anecdote: reading the definitions of nixos modules became a matter of course for me when i started doing strange stuff that didn't quite fit into the authors' expectations, and those module definitions contain the implementation, i.e. exactly where files are placed and what's written to them. i learned things about how a distro is put together that i never had any reason to look into in the past.

but i wasn't referring to how a system is put together at that level; i was referring to how a system is put together with the tool at hand, i.e. nix. and yes, you're right, that is top-down from the latter to the former

> What makes Nix/NixOS different are its fundamental principles, not how one approaches it.

you'll have no disagreement from me here; i was referring to what qualitatively hooked me, not making any statements about fundamental design

Re: My First Impressions of Nix

#296

Post by totallywrong »

colordrops wrote: post #277
totallywrong wrote: post #265

Earlier quoted context omitted.

There's the treefile [1] for declarative config, no need to learn RPM, just add package names and any extra config. As for managing home and multiple versions simultaneously, I think those are non-goals for this tool. [1] https://coreos.github.io/rpm-ostree/treefile

I meant creating an entirely new package from scratch. Regarding non-goals - I think that exposes the fundamental difference. rpm-ostree isn't "better". It's trying to solve different problems. The use case you described is a very small part of what Nix makes possible. Nix isn't just trying to fix or improve on existing systems - it present a fundamentally new abstraction that can be used for many purposes. Yes, you…

Yes you're right, better wasn't a good choice of words. My comment was in the context of replacing Ansible with Nix for making a reproducible system, as per the linked article. I wanted to point out that alternative which will be much more familiar to most people, who perhaps aren't ready to jump to an entirely new paradigm, but still want a declarative config. But undoubtedly Nix is much more powerful. I myself have been meaning to try out Nix on top of my rpm-ostree system, for dev environments.

Re: My First Impressions of Nix

#297

Post by totallywrong »

drdaeman wrote: post #288
totallywrong wrote: post #214

The problem Nix wants to solve is a valid one. But there are better alternatives imo, such as the newer distros based on rpm-ostree. You can do atomic upgrades, and easily rollback to a previous known good state if needed. No changes are allowed to a live system. And best of all, it's practically the same in terms of management, there's hardly any learning curve.

How about configuration management? Getting the packages is half the story.

The treefile allows you to define arbitrary config files to inject into the image.

Re: My First Impressions of Nix

#298

Post by mtlynch »

lloeki wrote: post #154

The problem the author hit with the Raspberry Pi is that the ARM image is meant for a standard environment (e.g UEFI ), like VMs. e.g it'll boot on Fusion or kvm because they provide UEFI, a well known device tree, and don't require any firmware at that stage. Pis (and many such ARM boards) don't have that so they won't be bootable. But there are Pi images built on Hydra. If one uses that then it boots right away. It…

Author here.

I'm working on a follow-up post specifically about NixOS on the Pi 4, but there are several gotchas to the process. The biggest issue I've run into is that the latest versions of the NixOS SD card images don't work on the Pi 4. You can boot to them, but when you run nixos-install, they fail with a message about hardware.raspberry-pi."4".fkms-3d.enable.

The link you shared declares itself to be out of date in several places, so it's not super helpful as a resource for newcomers.

Re: My First Impressions of Nix

#299

Post by lillecarl »

duped wrote: post #186
lillecarl wrote: post #146

Earlier quoted context omitted.

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

> Run the nix installer Ok and this requires root access, sets up some global directories under root, and a new user. Me as the administrator: why the hell do I need a new user and what is the nix store and what are the conditions that mutate it? (I know the answers to this question, but it's a barrier for people who give a shit). > Enable flakes What the fuck is a flake? Reads a bit... what the fuck is a derivation?…

Okay, so you're required to read some documentation ahead of time, that's where your problem lies.

What's a Terraform module? What is Terraform? What is a provider? Why don't I just build all my infrastructure with the AWS Console? Why is it it's own weird language? What is this state thingy that just ended up in my folder? Do i give it to the devs?

I think it's pretty much consensus that Terraform is great for provisioning anything with an API. Nix does the same for your packages, partitions, OS, containers, shells and many more things in the same functional manner.

In a company not everyone has to be a Nix wizard either, if a small team knows Nix they can build the Nix infra, then developers can reap the benefits of not having to mess with it at all.

Just because people are unable to comprehend the benefits doesn't mean they do not exist. And if you wanna reap great benefits you might need to spend an hour or two reading things.

Yes it's a novel way of doing things, but it's also one of the most actively developed projects with one of the highest amounts of contributors in the world.

https://discourse.nixos.org/uploads/default/original/2X/9/9b...

> Fine, but what about auto envs and nix shell? I don't use these with make or cmake. I need to attach a debugger, where does it go? How do I set up my IDE that has no idea nix exists?

The people that know Nix well enough will assist the ones that doesn't know, if you enter a nix shell and start vscode from there it'll be aware of $PATH which Nix sets, meaning it'll find all your dependencies.

Re: My First Impressions of Nix

#300

Post by lillecarl »

awelkie wrote: post #152
lillecarl wrote: post #146

Earlier quoted context omitted.

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

Step two is not even necessary if you use zero-to-nix's installer. https://zero-to-nix.com/start/install

Yup, I just didn't wanna confuse the already pessimistic person by saying "use the unofficial installer" :)
Post reply on HN