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

NixOS: Declarative Builds and Deployments

nixos.org

Post reply on HN
Print view View original

41–50 of 83 posts

Re: NixOS: Declarative Builds and Deployments

#41

Post by jljljl »

thatxliner wrote: post #2

Honestly, I don’t really understand the advantages (or the point of) NixOS over something like Docker.

We switched to using Nix at our startup because the rebuild time, reproducibility, and performance of Docker (especially on MacOS) were really slowing us down. Building and starting our dev container could take several minutes if we busted Docker's layer cache, but with Nix we never had to worry about that.

We open sourced our Nix dev environment tool (Devbox), and wrote a bit about why we switched here: https://www.jetpack.io/blog/devbox-turn-a-1000-container-scr...

Re: NixOS: Declarative Builds and Deployments

#42

Post by from-nibly »

bmitc wrote: post #37
baby wrote: post #22

I think the idea is good but execution is poor to reach mass adoption because: 1. It tries to replace ALL package managers due its extreme philosophy. I had a lot of issues when it tries to replace Cargo for example 2. It uses a functional language, which will lose 95% of users 3. It never had a great user experience especially if you’re new and trying to learn or if you’re not using linux or if you bring your own to…

I need to do some reading up on Nix, because I don't think I understand it. I thought NixOS was an operating system and Nix an operating system-level package manager, so why is it trying to replace Cargo, a package manager for a specific programming language in Rust?

Because nix is also the build tool that the packages are built with.

Re: NixOS: Declarative Builds and Deployments

#43

Post by fnordlord »

orbital-decay wrote: post #17
fnordlord wrote: post #8

Earlier quoted context omitted.

NixOS is also a declarative build of the entire machine as opposed to just a container also, so it's totally normal to have a NixOS build with multimedia apps, games, etc. To me, Docker is for building an entire environment for a single app to run in, whereas NixOS is for building an environment that runs multiple apps. Like a microservice vs a desktop machine.

> so it's totally normal to have a NixOS build with multimedia apps, games, etc Every time I try NixOS on a desktop with anything more complex than setting a couple flags (writing some derivations to work around the broken software, managing my dotfiles etc), my configuration ends up as an unholy mix of weird Nix trickery, FHS paths in a non-FHS environment, and foreign config includes. It's like writing ( programmin…

That actually makes me feel little better. I spent a few weekends trying to get a little raspberry pi SNES emulationstation on NixOS going and it turned out to be a total waste. I quickly found myself deep into scripting custom configs and questioning whether the packages I was using actually work. Reproducible != Just works

I assumed I was just a dummy for not getting it to work because there are tons of peoples' flakes on Github with their entire desktop environment declared. That's what gave me the impression that this was totally normal. It's super cool and impressive but I just haven't grokked reading Nix yet.

Re: NixOS: Declarative Builds and Deployments

#44

Post by [deleted] »

gcommer wrote: post #39
tkz1312 wrote: post #35

Earlier quoted context omitted.

nix is so powerful precisely because it takes a pure functional approach. You don’t get that level of reproducibility if you allow side effects.

Avoiding side effects does not require inventing a brand new purely functional language programming language.

[deleted]

Re: NixOS: Declarative Builds and Deployments

#46

Post by aliasxneo »

tomberek wrote: post #36

I work on Nix and think this paradigm has already impacted and will continue to influence software devopment in general. I want to make it easier for organizations/companies/groups to adopt it. Ideas and questions are welcome.

I'd start with getting some sort of working governance structure going. The sheer number of duplicate libraries all competing with each other has to be hurting Nix. Trying to figure out a TS/NodeJS build was an utter nightmare a year ago as I ended up going through five different projects, including the new "internal" solution, none of which worked reliably.

I contributed to the community for about a year and have since left for a number of reasons, but this is near the top.

Re: NixOS: Declarative Builds and Deployments

#47

Post by UniqueUsername0 »

drowsspa wrote: post #33
domenkozar wrote: post #7

Earlier quoted context omitted.

Better composability and abstraction, see for example how you can configure a process in https://devenv.sh/services/ that has first-class support for development environments using Nix. No need to use containers too, which bring cognitive/workflow overhead.

And Nix doesn't? At least with Docker you can get something useful within 2 minutes

But is it pure?

Re: NixOS: Declarative Builds and Deployments

#48

Post by sshine »

tomberek wrote: post #36

I work on Nix and think this paradigm has already impacted and will continue to influence software devopment in general. I want to make it easier for organizations/companies/groups to adopt it. Ideas and questions are welcome.

I run NixOS on a VPS at work. It currently hosts a noVNC dashboard for monitoring. I didn’t nixify the app yet.

I allocated a Debian and ran nixos-infect on it and started from scratch, even though I have done this for two other machines, because I’m still experimenting with the basic setup.

I do commit changes to git and fork it on company git. But I don’t redeploy remotely: https://discourse.nixos.org/t/deploy-nixos-configurations-on...

I’ll need to make noVNC a part of the deployment (not just its dependencies, like python3).

I should deploy using AWS AMIs, and make a config for the dashboard.

But the NixOS on Hetzner docs are not nearly as easy to guess the best path through. Can you recommend a way to boot NixOS on a Hetzner VPS that is better than nixos-infect?

https://nixos.wiki/wiki/Install_NixOS_on_Amazon_EC2

http://jackkelly.name/blog/archives/2020/08/30/building_and_...

Re: NixOS: Declarative Builds and Deployments

#49

Post by UniqueUsername0 »

candiddevmike wrote: post #25
Asdrubalini wrote: post #3

Earlier quoted context omitted.

Docker is not reproducible, you just apt-get install what you want hoping that the RUN commands get you a version that is still compatible with your software and doesn't break anything. With NixOS, you can pin the specific hash of every software, and you don't need the entire Ubuntu 20.04 in a container to deploy a webapp.

You can pin versions with apt-get install...

What's the model of the pinning? Is it an arbitrary semver? Is it a sha256 calculated by the content of the package (Content Addressed)? Is it a checksum calculated from all the inputs that were used to create the package install spec (Input Addressed)?

Re: NixOS: Declarative Builds and Deployments

#50

Post by tkz1312 »

gcommer wrote: post #39
tkz1312 wrote: post #35

Earlier quoted context omitted.

nix is so powerful precisely because it takes a pure functional approach. You don’t get that level of reproducibility if you allow side effects.

Avoiding side effects does not require inventing a brand new purely functional language programming language.

That’s true to an extent. It’s possible to define nix packages in impure languages, but those languages are still compiling down to package definitions (.drv files) that are purely declarative and are executed in an environment that forbids any side effects.

So it’s more a question of whether it’s a nicer experience to wrap up a pure core in some impure outer layer, or just make the whole thing pure.

Nix the language is imo pretty nice for what it does, and lots of other config languages seem to have ended up in similar kind of “json with functions” part of the design space (e.g. dhall, jsonnet). My personal view is that purity in the nix language helps more than it hurts, and that the big design fuckup wasn’t writing a custom DSL, but writing a custom DSL without static types.

Post reply on HN