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

211–220 of 243 posts

Re: Nix is the ultimate DevOps toolkit

#211

Post by fishywang »

jpe90 wrote: post #51

I tried Nix a few days ago. I set it up on an existing Arch install. I installed a couple of packages with "nix-env -i [package] and then tried to update them with "nix-env -u" as instructed in the official documentation: https://nixos.org/manual/nix/stable/#ch-basic-package-mgmt This ended up breaking the entire install. After a few hours of troubleshooting I found that the reason it broke was that it updated itself…

I'm the one filing that bug :)

Before this bug I was running nixpkgs on top of all the Debian machines I'm using (including crostini vms on chromeos devices), mainly as a package manager to mange and keep up-to-date on things outside of debian's apt ecosystem (firefox, thunderbird, go, pipx, etc.). After this bug I removed nixpkgs from all of them.

While I agree that nixpkg is great for declarative use cases others mentioned, and also it's very useful to try something temporarily (e.g. `nix-env -i something`, do things, then `nix-env --rollback`), those are not my main use cases (while at least not for my debian machines), and my main use case of it is broken because of that bug.

I even recommended nixpkgs as a better alternative to homebrew to my friends using mac, I guess that's not really true any more.

Now I keep up-to-date to things not in apt-ecosystem by subscribing to releases on github :(

Re: Nix is the ultimate DevOps toolkit

#212

Post by takeda »

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…

It's not a bug, it bad UX, and new version of nix command line is meant to fix the UX. Or more correctly, it is a bug, but the proper fix is to remove that functionality.

Basically the nix repo unlike other package repos it isn't flat it is a tree of many different derivation. A lot of them even repeats. For example parent poster had problem because he installed version of nix that used musl instead of glibc. You can similarly reference packages that cross compile for different platforms. For example you can install Raspberry Pi version of a package. But if you're not running RPI that binary won't execute on your computer.

Now, nix-env by default tries to guess where in that package tree application with given name exists and then installs it.

This probably worked well early on when nixpkgs repository was small, but as it grew, they added cross compilation or other variants like installing packages with musl etc. It doesn't make a good guess. That's why now -i and -u should be followed with -A option, which disables the guessing and provides a path in the tree, so the command should be (besides being accurate it is also much faster since nix doesn't need to scan the whole tree):

    nix-env -uA nixpkgs.nix
Or actually the recommend way to update nix itself is:

    nix upgrade-nix
The nix-env command is also mostly used as a bridge since most new users will be familiar with that interaction. People who get past the learning curve no longer use nix-env, because it is not the "nix way" of doing things, which probably explains why the command is still the way it is, and the new cli command organization (which is using just single "nix" command kind of like you use git, doesn't have nix-env functionality)

Re: Nix is the ultimate DevOps toolkit

#213

Post by ben0x539 »

oblio wrote: post #177
__jem wrote: post #105

Earlier quoted context omitted.

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.

Or you could, you know, use any kind of backup/restore software, spend like 5 minutes to learn how to use it, and use those many hours invested in learning Nix to watch football and drink beer :-)

I feel like restoring a backup is a lot more disruptive than the update just not happening and you being back where you started automatically.

Re: Nix is the ultimate DevOps toolkit

#214

Post by camehere3saydis »

jonringer117 wrote: post #181
throwaway894345 wrote: post #135

Earlier quoted context omitted.

I think [Nickel][1] aims to add static types to Nix, but I don't know of any efforts to integrate Nickel into nixpkgs. [1]: https://github.com/tweag/nickel

It's still in development. But swapping a language is possible, as it's only needed for evaluation. Building the package (realization) just needs the derivation.

So does that mean I can just hack together my own derivations in, say, Python, and bypass the whole nix-shell vs. nix-env, overlays vs overrides, home-manager, flakes, etc. menagerie? And use only Nix only for its central artifact store and dependency resolution?

It kind of looks like they're trying out different interfaces to the same basic core functionality and seeing what catches.

My personal gripe is that wrappers for languages that have their own package managers are abysmal. But griping about Nix on HN is just extra publicity. Now we're just waiting for someone to explain it in a sufficiently succinct way for the crowd.

Come to think of it, that's kind of like Monads in Haskell a few years back. Anyone remember the series of watered down explanations that failed to address the actual problem people were having, which was that that people were confused by the notation, if I recall correctly.

Nix's roots are close to Haskell turf, so it comes as no surprise they're struggling with explaining their abstractions, resulting in the series of mutually overlapping "official" ways to do things (none of which, incidentally, is the "obvious" way if there is one). After all, Nix is a build tool and not a whole language, so they get to try different CLIs and config APIs within with less overhead than experimenting with a language's syntax.

Re: Nix is the ultimate DevOps toolkit

#215

Post by camehere3saydis »

Reading some of the comments here, it feels like one needs to lay out a lot of context before being able to describe their Nix experience.

(Is that Conway's law in reverse, or just Occam's beard? I can't help but wonder.)

And I gotta get back to trying to build Deno from Git with Mozilla's overlays. Thankfully, Nix pairs well with git submodules...

Re: Nix is the ultimate DevOps toolkit

#216

Post by [deleted] »

jonringer117 wrote: post #181
throwaway894345 wrote: post #135

Earlier quoted context omitted.

I think [Nickel][1] aims to add static types to Nix, but I don't know of any efforts to integrate Nickel into nixpkgs. [1]: https://github.com/tweag/nickel

It's still in development. But swapping a language is possible, as it's only needed for evaluation. Building the package (realization) just needs the derivation.

[deleted]

Re: Nix is the ultimate DevOps toolkit

#217

Post by Ericson2314 »

thomastjeffery wrote: post #196
Ericson2314 wrote: post #154

Earlier quoted context omitted.

There are some serious gotchas like nix-env in this read I would like to delete. But, that said, I don't think targeting "drive by usesr" is worth it. The benefits of Nix is that it dramatically organizes the absolute disgusting mess that is how most people manage their computer. I don't want to drive people trying things out away, but Nix will never be worth it unless you embrace it, and half-ways usage will deliver…

Organizing that mess should make every user a casual user, serious it not?

hmm? Genuinely unsure what you mean.

Re: Nix is the ultimate DevOps toolkit

#218

Post by Ericson2314 »

ben0x539 wrote: post #193
Ericson2314 wrote: post #154

Earlier quoted context omitted.

There are some serious gotchas like nix-env in this read I would like to delete. But, that said, I don't think targeting "drive by usesr" is worth it. The benefits of Nix is that it dramatically organizes the absolute disgusting mess that is how most people manage their computer. I don't want to drive people trying things out away, but Nix will never be worth it unless you embrace it, and half-ways usage will deliver…

I've used NixOS at home since like 2016. While I haven't used it professionally or for "serious" enthusiast deployments, I don't think I can claim to be a drive-by user. I still insist on using nix-env because it's what all the first-party manuals tell me to do and I don't want to get into a situation where I am experiencing huge pain and the first-party people all tell me "well, that's on you for doing things in a d…

Yeah people say the docs are unapproachable, but I agree the docs are too much "here is how to do a bunch of random things" and not enough systematically describing what Nix is.

Reference first, then tutorials.

Re: Nix is the ultimate DevOps toolkit

#219

Post by kaba0 »

Wazzymandias wrote: post #176

Nothing should be labeled as the ultimate devops toolkit when its documentation is as atrocious as nix People can commend it as much as they want, but the steep learning curve is largely self inflicted because of their resistance to writing clean, comprehensive, up to date docs It has also led to the community being filled with a lot of arrogance and pretentiousness I wouldn't run nix in production because of the lac…

Any concrete reason you call such a niche, but large community toxic?

Re: Nix is the ultimate DevOps toolkit

#220

Post by kaba0 »

lfam wrote: post #187
bfrog wrote: post #139

I use nix today for ci/cd to build a large C++ project for a variety of architectures using cross-compiles. While it could be done with adhoc scripts, some cross compiler tool environment tool + conan, or something else, I effectively wrote my nix expression once to package up everything, and simply changed the target arch and libc and got what I wanted. It's not perfect, but it works, its fast, and its better than t…

Hey, we're glad to hear you're interested in Guix :) I just wanted to say that Guix doesn't hate systemd, or think of itself as an anti-systemd project or anything like that. Systemd was not chosen because GNU already had a (quite simplistic) init system written in Guile Scheme, and we want to use Guile for the entire system. Eventually, our goal is to offer a fully integrated interface for managing the system, just…

Is it really wise to go against such important/widely-used part of the linux userspace? I do find Guix as cool as NixOS, but this decision seems like a self-inflicted wound.

Nonetheless, I should definitely get to know the project more, because it was some time ago I tried it last. So, Good luck with the project! :)

Post reply on HN