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

111–120 of 243 posts

Re: Nix is the ultimate DevOps toolkit

#111

Post by snicker7 »

MayeulC wrote: post #81
vindarel wrote: post #19

Obligatory link to its cousin: https://guix.gnu.org/ A package manager or a full distro. I use the package manager on top of Debian, it's great, it allows me to get recent package versions the most straightforward way (like the latest Emacs), in exchange of disk space (easily some GB before a `guix gc` cleanup).

I've been running it on an older laptop to try it out. `guix pull` takes so much resources, it often takes a few hours to complete, even with binary substitutes. Documentation is a bit lacking, even though it has an excellent manual. How I am supposed to specify extra command line parameters to the kernel I boot in GRUB, for instance? Or specify multiboot targets? Get a "desktop" install without GDM? In the end, I we…

> I've been running it on an older laptop to try it out. `guix pull` takes so much resources, it often takes a few hours to complete, even with binary substitutes.

This is being actively worked on!

https://guix.gnu.org/en/blog/2021/getting-bytes-to-disk-more...

> I wish it didn't require root access, or allowed me to put it in an arbitrary directory

I believe `guix pack -RR guix` will do package a relocatable guix for you.

Re: Nix is the ultimate DevOps toolkit

#113

Post by AzzieElbab »

siraben wrote: post #72
AzzieElbab wrote: post #43

I like nix, but it is hard as hell to switch to from yaml driven world. If the path was more gradual nix would see more adoption

What systems are you referring to in the "YAML driven world"?

ansible, k8 - anything, circle, everting else

Re: Nix is the ultimate DevOps toolkit

#114

Post by q3k »

tnzm wrote: post #88
q3k wrote: post #44

Earlier quoted context omitted.

> How exactly, command by command, would nix solve the same problems? This might be problematic, because to understand these commands, you would have to understand Nix. It's not just a tool that replaces your existing tool, it's a total workflow change, and without understanding what's happening under the hood, you can't really appreciate how much it makes your life easier. I could show you a `nix-build -A deploy.som…

>This might be problematic, because to understand these commands, you would have to understand Nix. It's not just a tool that replaces your existing tool, it's a total workflow change, and without understanding what's happening under the hood, you can't really appreciate how much it makes your life easier. That's the entire point of a tutorial like GP describes. Yes, Nix works on a higher level of abstraction than ex…

Right, I do not disagree with a tutorial that outlines Nix in this way. Indeed, this is how I teach Nix to others, generally by starting with the repl and then adding things on top like derivations, callpackage, nixpkgs and stdenv, trivial nixpkgs builders, and finally NixOS.

I'm arguing only the one point that I cited - that Nix's advantages can be presented as a step-by-step 'write these commands' getting started guide for migrating, I don't know, some ansible based production into NixOS. Following some steps blindly and expecting immediate results will only result in frustration and disappointment.

The 'alien technology' is in my experience quite helpful in getting expectations straight when teaching people Nix. Driving the point that this is not like switching from npm to yarn, but that you will have to spend a serious chunk of time learning a whole new thing.

> The concrete details of the Nix paradigm really lie in the syntax itself so what you're saying about "same tools with different syntax" doesn't make much sense to me, as every programming tool is defined by its syntax.

There is more to programming languages than their syntax. But maybe I couldn't have been more clear. What I meant, is when you're comparing Prolog, Ruby and Python, Ruby and Python basically look like the same language. In the same vein, when you're comparing nix{,pkgs,os}, Ansible and Puppet, Ansible and Puppet basically look like the same tool. Switching from Ansible to Puppet is relatively easy, while switching from Ansible to Nix requires switching your mindset and approach considerably.

> What Nix needs is a single page specifying what goes in a Nix derivation. [...] [A] tutorial for generating a static HTML site with Nix, then deploying it, then incrementally adding dynamic backend services to it?

All of these are good ideas in my opinion. Nix needs better documentation, but the answer isn't more "build production on Nix in 5 minutes" guides, but more "go on an adventure to understand Nix thoroughly and make using it obvious" guides, IMO.

Re: Nix is the ultimate DevOps toolkit

#115

Post by grandinj »

Nix sounds like SELinux.

A great idea in theory, but in practice just too hard.

There is a great deal of genius in coming up with these ideas.

There is just as much genius in finding the 80-90% solution that incorporates most of the original, but in a workable way.

Looking forward to seeing where stuff like Nix ends up.

Re: Nix is the ultimate DevOps toolkit

#116

Post by salamander014 »

__jem wrote: post #105
bamboozled wrote: post #45

Earlier quoted context omitted.

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.

Many times repairing those kinds of situations in Linux is as simple as:

- boot linux livecd

- mount your broken filesystem

- bind mount the important bits from the live kernel (/proc)

- chroot

Like this:

    cd /

    mount -t ext2 /dev/sda1 /mnt #Here's your broken install

    mount -t proc proc /mnt/proc

    mount -t sysfs sys /mnt/sys

    mount -o bind /dev /mnt/dev



   chroot /mnt /bin/bash #boom you are in.
Now do whatever you can to repair the system. depends on what broke.

usually apt stuff for me(pulled power during a package upgrade)?

Re: Nix is the ultimate DevOps toolkit

#117

Post by takeda »

cazim wrote: post #73

This reminds me -> https://xkcd.com/927/

I don't think this is relevant. It's not a new standard is a complete paradigm shift.

Some tools might need to be used slightly different, others might no longer be needed.

Because it requires change the way you think about things is why so many people have problem with getting into it.

Re: Nix is the ultimate DevOps toolkit

#118

Post by arianvanp »

madjam002 wrote: post #30

Has anyone explored CD tooling with Nix? And I don't mean the deployment of NixOS machines themselves (NixOps, deploy-rs, etc), I mean actually using Nix for deployment tooling and orchestrating deployments using the Nix language. I am yet to find any posts about this or any tools, but have had great success with a small hand rolled tool that essentially lets me decoratively describe cloud resources, parts of my appl…

Maybe https://github.com/serokell/deploy-rs ?

It's a generic deployment tool for Nix that also supports NixOS machines but can target any nix profile

Re: Nix is the ultimate DevOps toolkit

#119

Post by tazjin »

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 wrote a language tutorial for only the language a while back, and have gotten the feedback that it has helped a lot of people - maybe it'd clear something up for you: https://github.com/tazjin/nix-1p

Re: Nix is the ultimate DevOps toolkit

#120

Post by q3k »

mikepurvis wrote: post #109
q3k wrote: post #47

Earlier quoted context omitted.

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

> 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'm only aware for how this is done for OpenGL on NixOS, which is done by some bespoke LD_LIBRARY_PATH modifications. See: nixos/modules/hardware/opengl.nix.

There might be some nixpkgs (non-NixOS) abstractions for this that I'm not aware of, or one would have to be written (which doesn't seem too hard to do).

Post reply on HN