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

Nix is the ultimate DevOps toolkit

tech.channable.com

Post reply on HN
Print view View original

101–110 of 243 posts

Re: Nix is the ultimate DevOps toolkit

#101

Post by codethief »

A few days ago, I came across RobotNix[0] which uses Nix to deterministically build custom Android images. Since I really want to adapt Android to my needs but have always struggled with building it on my own (what a shitty and complicated build system), I'm now very inclined to learn Nix. I'm not sure I like the syntax but hopefully I'll get used to it.

Another reason I'm quite excited about Nix is that in my team we're currently using a whole bunch of tools like pip, Conda, npm all at the same time to manage our dependencies and it's starting to become really cumbersome to set up the dev and production environments correctly across different operating systems and architectures. For instance, Conda doesn't exist on arm64, lots of pip packages have to be compiled by hand on arm64 etc. etc. It's a mess that I'd love to get rid of.

[0]: https://github.com/danielfullmer/robotnix/

Re: Nix is the ultimate DevOps toolkit

#102

Post by nuker »

detaro wrote: post #70
nuker wrote: post #15

Nice, but this is as far from devops as knitting. They covered CI, but there is CD, all the cloud stuff, containers, security and so on.

"cloud stuff" and "containers" (which people also do manage using Nix) are not requirements for something to be DevOps.

Try telling it to any recruiter lol

Re: Nix is the ultimate DevOps toolkit

#103

Post by catern »

oblio wrote: post #95
domenkozar wrote: post #64

Earlier quoted context omitted.

That's another problem of documentation. The correct way is to search for packages as the following: https://nix.dev/tutorials/ad-hoc-developer-environments.html... And then install via: nix-env -iA attribute-name New Nix CLI as part of next release fixes that, but it's not out yet.

Now, don't get me wrong, I don't have a horse in this race. But as a complete outsider, this doesn't fill me with confidence. If Wikipedia is to be believed, NixOS was launched in 2003, so 18 (!) years ago, I assume that's when Nix was created. The issue mentioned seems quite basic and you're replying that it will be fixed in a new Nix CLI. This seems like a basic QA fail, I wouldn't want anything like this within 10…

nix-env (including nix-env -u) is purely a user-facing UI helper for new users. One would never use it in production, or even for development, even when it was first released; it's only ever been for new user onboarding. So it's a bit low priority, since it has no production impact and experienced users don't use it...

Re: Nix is the ultimate DevOps toolkit

#104

Post by chriswarbo »

georgyo wrote: post #40
supermatt wrote: post #9

I spend a few hours looking at nix about a year ago and found it impenetrable. I simply do not grok the syntax or what the functions do. I tried searching for the functions shown in the examples on the website to no avail. I searched packages, options, and even resorted to ctrl-f while clicking through the site "documentation"... It sounds awesome, but its in dire need of some better documentation if it wants to be a…

Having used nix for two years now for both work and personal purposes, I agree. Though I have also come to think nix is doing things in much better ways than AppImage, Docker, Snap, Flatpack, and others. I won't focus on the good parts, but focus on your comment. Nix has three things that I think are confusing and took me an embarrassing long time to grok, and I find other people confused by as well. 1. Where does th…

> Bonus 4. In nix it is really easy to build single language applications. However if you need to mix two, finding good docs or examples is really hard. IE, if you want to build the javascript front end of your web app as well as the python backend. These combinations need at least two derivations, and how to make it happen is bespoke every time.

For anything that doesn't fit a common nixpkgs function (like `buildPythonPackage`, etc.) then I always start with this:

    nixpkgs.runCommand "my-application"
      {
        dependencies go here
      }
      ''
        shell commands go here
      ''
This is certainly "bespoke every time", but it's literally just a shell script (with explicit dependencies). This approach doesn't need much documentation either: we just copy-paste whatever commands are in the normal, non-Nix documentation for whatever we're doing. We'll probably need to add a few dependencies to the `buildInputs`, and possibly disable the sandbox to allow network access (which we can factor out later, if we like).

Re: Nix is the ultimate DevOps toolkit

#105

Post by __jem »

bamboozled wrote: post #45
supermatt wrote: post #9

I spend a few hours looking at nix about a year ago and found it impenetrable. I simply do not grok the syntax or what the functions do. I tried searching for the functions shown in the examples on the website to no avail. I searched packages, options, and even resorted to ctrl-f while clicking through the site "documentation"... It sounds awesome, but its in dire need of some better documentation if it wants to be a…

I still don't understand the language syntax after using it for several years, I just make it work through trial an error. The documentation is pretty unhelpful too. It's ultra ambiguous. Recently my laptop died, and I just needed another one going in a hurry and I tried Xubuntu because it's the only distribution which had Wifi drivers that worked for a 12 year old Mac I had lying around without any trickery. It's fu…

I switched to NixOS after tripping over my laptop's power chord during an update, which broke Linux in such horrifying ways that I didn't dare attempt recovery.

I agree that I'm not sure the extra complexity is worth it for day to day use, but just the ability to avoid catastrophic failure and near instant setup on new machines is worth it I think.

Re: Nix is the ultimate DevOps toolkit

#106

Post by chriswarbo »

georgyo wrote: post #40
supermatt wrote: post #9

I spend a few hours looking at nix about a year ago and found it impenetrable. I simply do not grok the syntax or what the functions do. I tried searching for the functions shown in the examples on the website to no avail. I searched packages, options, and even resorted to ctrl-f while clicking through the site "documentation"... It sounds awesome, but its in dire need of some better documentation if it wants to be a…

Having used nix for two years now for both work and personal purposes, I agree. Though I have also come to think nix is doing things in much better ways than AppImage, Docker, Snap, Flatpack, and others. I won't focus on the good parts, but focus on your comment. Nix has three things that I think are confusing and took me an embarrassing long time to grok, and I find other people confused by as well. 1. Where does th…

Regarding point 2, yes it's definitely a pain to mentally switch back-and-forth when writing shell code in a Nix string.

Three things I find immensely helpful:

- Syntax highlighting (I use Emacs, which has a Nix mode)

- Syntax checking (again I use Emacs for this)

- Writing complicated scripts in a separate file. This makes it harder to splice in Nix values (there are ways to substitute in text, but I find them more trouble than they're worth). Setting some extra env vars in the build environment is usually the easiest approach.

Re: Nix is the ultimate DevOps toolkit

#107

Post by domenkozar »

mkingston wrote: post #34
domenkozar wrote: post #6

I've written a few tutorials at https://nix.dev/ , more to come in following months :)

Hey thanks for those. I hadn't noticed them as a whole, but I'd stumbled across a few of them from search results, and now I open the site and realise it looks quite familiar!

Thanks. I'm looking for feedback on the content - in terms of problems with it and what's missing!

Re: Nix is the ultimate DevOps toolkit

#108

Post by nonameiguess »

alrs wrote: post #11

The merges-straight-to-master give me the willies. https://botsin.space/@complainingaboutmastercommits

It's not fair at all that this is presently the most downvoted comment. Like it or not, this is a real concern, even if the count is illusory. It's not just about humans seeing this, but automated risk assessment tools use this kind of thing as a metric and showing a bunch of commits straight to master can prevent enterprise and government adoption due to policy. Maybe that doesn't matter for you, but innovators ignoring these gigantic market segments is part of why enterprise and government software development remains so far behind the innovation curve because they can't trust the security of the development models and the largest customers are all stuck with effectively no choice but Redhat.

Re: Nix is the ultimate DevOps toolkit

#109

Post by mikepurvis »

q3k wrote: post #47
mikepurvis wrote: post #41

A lot of this sounds familiar to me— I maintain a hodgepodge build tool/pipeline at my org whose current output is a monolithic mega-deb file which is becoming unwieldy on several fronts (storage, transfer, compression time). I'm really interested in the nix philosophy of separate paths and versioning by hash rather than number, but unfortunately my needs are quite specific, and not having actual experienced nix expe…

> What is the story in nix for packaging untagged branches of software, or reasoning about "snapshots" where pools of unreleased repos/packages are able to be treated as a single versionable unit? A Nix derivation (a.k.a. 'packaging unit') can be built from sources either fetched remotely, or from a local directory, or a combination of both; plus any other derivation that it depends on. Any version semantics come fro…

> By default, any change to any dependency will cause all dependent derivations to be rebuilt, and their hashes to also change. You can 'break' this by introducing stable ABI barriers preventing rebuilds and performing runtime loads of dependencies from .so (or whatever, executing some binaries from $PATH).

Does this imply full control over hash holding/breaking for derivation authors, or is it like a single field that's basically just meant to be used for the soname?

I would love to see more docs detailing how this works and what the user extension points are for it. Most of what I've found is pretty high level.

Re: Nix is the ultimate DevOps toolkit

#110

Post by __jem »

I've gotten into NixOS for my personal daily driver, but I'd love to see more resources about how to orchestrate CI/CD flows with Nix. It's not totally clear how I'd move from the simple single machine configuration I have now to packaging a large monorepo and deploying it.
Post reply on HN