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

NixOS 21.05

nixos.org

Post reply on HN
Print view View original

81–90 of 234 posts

Re: NixOS 21.05

#81

Post by kevincox »

reasonabl_human wrote: post #77
kevincox wrote: post #57

Earlier quoted context omitted.

In general it is very nice. A common method is you create a `default.nix` file in the project you are working on and use tools that manage the deps for you. For example: Rust+Cargo: https://gitlab.com/kevincox/watchlog/-/blob/22c877065f763b3d... Node+NPM: https://gitlab.com/kevincox/kevincox-web-compiler/-/blob/9fa... My only Ruby project is private but I just rolled my own with: export "GEM_HOME=$out" bundle install…

Are you up for explaining these gists? We use nix extensively at work and yet I’m having trouble wrapping my head around these. Node dependencies have been a thorn in our nixification of some packages, C / C++ has come easily.

Sure. NPM is the easy case because the package-lock.json file can easily be read by Nix and contains hashes for all of the packages. This means that simply be importing the file into Nix you can have a reproducible build. No Nix-specific maintenance required.

In the linked case I use this library to manage that https://github.com/nmattia/napalm (in that example I use master but for production I would pin a version). It simply parses the package-lock.json, downloads the packages and uses npm to build the node_modules folder. It also provides some convenient functions for building packages with "bin" files or just linking node_modules inside a build.

Note that this is more for project development. It doesn't use the "system" packages (intentionally) for Node, it fetches whatever versions you have specified from NPM. Nix will only provide the "native" stuff like Node and NPM themselves and any native libraries.

Re: NixOS 21.05

#82

Post by ashtonkem »

rkangel wrote: post #19
nitsky wrote: post #4

I recently moved my laptop, desktop, and a few servers from Arch Linux to NixOS with flakes and home-manager. It is amazing! The complete configuration for all machines is in a single git repository, I can share configuration between them, and a `flake.lock` file guarantees all machines are using the same version of everything. No more trying to remember what command I need to run to install and configure software an…

Honestly - how painful was it to learn and get working? And what limitations/niggles are left when using as a workstation? I love the principles behind Nix, and I like to use it to provide development environments (through nix-shell locally and then using the same setup in CI). But some things can be moderately painful to get going.

My experience, a while ago I will admit, is that your experience will vary wildly based on what you’re doing with it.

Writing Haskell in it was a joy, but Ruby was pure pain. I actually never could get RoR to run (this might have changed), so I gave up and went to OSX for that stuff.

Re: NixOS 21.05

#83

Post by pimeys »

jpe90 wrote: post #64

What do experienced nix-ers tend to do when they need to use software that's not up to date or available in nixpkgs? Are you guys knowledgeable enough to package everything yourselves, or do you just use buildFHSUserEnv until someone else works out the kinks? I didn't get a chance to figure out how to do the latter, but I'm curious because I've struggled as a new user.

I fork the repo, update the package in my fork, add the fork as a flake to my inputs and test my changes. When I'm happy, I create a pull request to the main repo.

I started using NixOS in all my machines last winter, and slowly decided it is for me when I understood the basics. It was a rough start for me, but I have a few decades of linux knowledge, that helped me past the starting point.

You can read my config and see how to create overlays from different sources. E.g. if your fork updates vim, your overlay overwrites vim in the definition. Then referring to pkgs.vim points to your fork. See flake.nix in the repo.

https://github.com/pimeys/nixos

Re: NixOS 21.05

#84

Post by agumonkey »

kaba0 wrote: post #5
grumpyprole wrote: post #3

This excellent Linux distribution has the honour of not needing to recommend a clean install. It deserves to be far more popular. I've run it since 2014 with so few problems, that I can't really claim to "know" Linux anymore.

That’s my only problem with it, I will forget what this random file in /etc does or how to configure this and that because it is so simple to do decleratively and never breaks :D

Maybe it's like disk usage. You'll always find new stuff to brain on

Re: NixOS 21.05

#85

Post by chriswarbo »

mason55 wrote: post #44
gugagore wrote: post #27

Earlier quoted context omitted.

It sounds like nix provides an escape hatch [1] out of the declarative framework into something imperative, e.g. running `apt install $package`. And that seems like it would really ease adoption, since I would assume that it would allow a gradual adoption of the declarative mindset. [1] https://wiki.c2.com/?EscapeHatch

IMO the escape hatch doesn't get you any real benefits. It's not like you can install packages from apt/yum/aur so you don't get access to any new software (plus nixpkgs is bigger than all those). All it does is result in confusing tutorials that hide the benefits of declarative management and make it difficult for new users who just want to get things working.

> It's not like you can install packages from apt/yum/aur

Yes you can. Here's a Nix derivation which makes a Debian chroot and runs 'apt-get update; apt-get install -y chromium' https://github.com/Warbo/warbo-utilities/blob/7087c3b46a97f3...

Here a Nix derivation for a helper script that runs the above chromium: https://github.com/Warbo/warbo-utilities/blob/7087c3b46a97f3...

On a similar note, here's a Nix derivation for Mozilla's Firefox binary (in an FHS env), along with a warning if it's not the latest version: http://chriswarbo.net/git/warbo-packages/git/branches/master...

I wrote these once cache.nixos.org stopped providing "non-core" i686 binaries a few years ago, and I can't be bothered to build those large applications from source.

Re: NixOS 21.05

#86

Post by kevincox »

jpe90 wrote: post #64

What do experienced nix-ers tend to do when they need to use software that's not up to date or available in nixpkgs? Are you guys knowledgeable enough to package everything yourselves, or do you just use buildFHSUserEnv until someone else works out the kinks? I didn't get a chance to figure out how to do the latter, but I'm curious because I've struggled as a new user.

I typically try to package it and push it upstream. It usually isn't much work and it helps others. That being said it is rare that something I want isn't in nixpkgs. After all by some metrics nixpkgs-unstable is the most up to date package repository, and only slightly smaller than the AUR https://repology.org/repositories/graphs

In some cases I do settle for using `steam-run` or `buildFHSUserEnv` but I don't think I am using those for anything right now.

Re: NixOS 21.05

#87

Post by acgkmopvvgvmgv »

sph wrote: post #21
__jem wrote: post #7

I recently moved back to Arch from NixOS. I really love the idea, and the execution isn't necessarily bad, but it didn't make sense for me on the desktop. Straying off the beaten path quickly led to the sense that I was going to have to learn way more about Nix than I wanted to. I hope the documentation and community grows, because I definitely got the sense that it is the future arriving early!

The documentation and the nix language are the worst things about the project IMO. I really hope Guix succeeds because Scheme is, in my opinion, a better DSL and language than this weird, not very well documented, Haskell-like derivative. Unless you've drank the kool-aid, you have to learn a completely new operating system and way of doing things, a weird language that's lacking on documentation, and a ton of system…

Nix and similar projects are all going to be eaten alive by immutable distributions, Flatpak and new projects - that might work just like Nix but get the user experience right, and make packaging and maintenance easier. And no I'm not saying they do the exact same thing, have all the same features or target the same type of users.

For the developer tools side I like what Shopify did but I would never recommend that to my employer. Too many moving parts and not enough people using it that I would feel safe about it.

Re: NixOS 21.05

#88

Post by bemeurer »

lloeki wrote: post #62
rkangel wrote: post #19

Earlier quoted context omitted.

Honestly - how painful was it to learn and get working? And what limitations/niggles are left when using as a workstation? I love the principles behind Nix, and I like to use it to provide development environments (through nix-shell locally and then using the same setup in CI). But some things can be moderately painful to get going.

> how painful was it to learn and get working? nixpkgs (which you can use on macOS or any Linux distro), quite little, you can get up to speed in 15min as a Homebrew replacement: nix-env -qas ruby # 'q'uery 'a'vailable 'search' nix-env -I ruby. # install by package name (not recommended) nix-env -iA nixpkgs.ruby_3_0 # install by "attribute", recommended nix-env -q # 'q'uery (i.e list installed) nix-env -e ruby # unin…

Please don't recommend that people use nix-env. It's one of Nix's biggest footguns and a huge support burden for the maintainers.

We've been actively trying to remove mentions of it from the documentation.

If you want something "installed" use home-manager. If you just want something for quick dev use nix-shell.

Re: NixOS 21.05

#89

Post by kevincox »

candiddevmike wrote: post #13

If you currently use something like Ansible to orchestrate changes (such as failover of a PostgreSQL node), how would you do this with Nix? Do you still use Ansible, or can you use NixOps for this?

In general Nix is a huge step above Ansible for config management. They aren't even playing the same game. Ansible is an awkward syntax to generate a shell script, NixOps is a declarative deployment tool. (I wrote more about this in [1] if you are interested).

However one place that NixOps doesn't handle well is state. So for example if you want to run state mutating commands such as boot read-only, kill replication, then start replication on the other node it is a bit tedious. You could do this with multiple states. For example generate the "readonly" state and deploy it, then generate the "failed over" state. However there isn't great support sequencing these types of things as far as I am aware. But also a disclaimer that I haven't actually been in the situation where I needed to manage PostgreSQL with Nix so I haven't looked too closely at the options. I would love to hear someone with experience to share what they do.

[1] https://kevincox.ca/2015/12/13/nixos-managed-system/

Post reply on HN