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

121–130 of 234 posts

Re: NixOS 21.05

#121

Post by takeda »

bemeurer wrote: post #88
lloeki wrote: post #62

Earlier quoted context omitted.

> 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.

I don't think removing it is a good idea. Nix is a paradigm shift and things are done completely different, nix-env though is still one piece that might be somewhat similar to what people are used to.

Re: NixOS 21.05

#122

Post by kaba0 »

deckard1 wrote: post #102

I must admit, I'm curious about the idea but I don't yet "get" it. Reproducible builds sound like a great idea at first, but this has the same problem as Docker containers: you inadvertently become a package/distro maintainer. How does one update the system regularly with security updates? Are we locking by semver somehow (like node, etc.)? And who decides which version ranges to lock to, etc. etc.? Honestly, I'd pro…

Usually you have a declarative package/system config file that is seldom changes and you point it to a nixpkgs repository, which has definitions for other packages. So an update is as easy as changing that repo to a newer/modified branch. Of course you can even depend on multiple such repos, or override them in any way so you can use a specific lib with an older shared library while use everything else with the latest.

As for versioning, it is hash-based. Packages specify a source (eg github repo and a specific commit) and the hash of the downloaded source files, and build instructions inside the nixpkgs repo. The resulting program will depend on each listed property. And since they are referenced by hash, a program can use any possible version of another program. Hope it answers your questions!

Re: NixOS 21.05

#123

Post by takeda »

ashtonkem wrote: post #82
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.

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.

I haven't used Ruby, but Python also was a huge pain and there were many attempts at fixing it, but all had some issues for me. That is until I found poetry2nix.

Re: NixOS 21.05

#124

Post by kaba0 »

pimeys wrote: post #83
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…

I would just add that more often than not it is as easy as changing the version string in the somePackage/default.nix file and changing the corresponding hash of the source. Of course if the build changes in the new version or it depends on some new lib it can become a bit more difficult, but with a bit of experience it is not that hard to solve.

Re: NixOS 21.05

#125

Post by pxc »

bemeurer wrote: post #88
lloeki wrote: post #62

Earlier quoted context omitted.

> 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.

I like to use nix-env (or more often, now, `nix profile`) for a persistence level in between nix-shell and really adding something to my home-manager or NixOS config. I let my profile build up 10-20 things installed, then every few weeks I decide what belongs in my declared config and uninstall everything in the profile.

Imo entirely removing imperative package management would be a mistake, although imperatively managing a file that gets sourced in your declarative config (a bit like /var/dpkg/selections on ol' Debian) instead of putting the whole profile manifest in the Nix store and leaving it at that would be better.

Re: NixOS 21.05

#126

Post by pxc »

open-paren wrote: post #112
bemeurer wrote: post #88

Earlier quoted context omitted.

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.

If nix-env is a big ol' footgun, are there any plans to make home-manager a part of the OS itself, instead of just a community project?

My hope is that when Sander van der Burg finishes drafting his RFC for mainlining his process management framework [1], which abstracts over ways to manage local services from systemd to supervisord to Docker, we can actually unify the module collection in Nixpkgs with its clones in nix-darwin and home-manager, and offer a more complete Nix experience as a configuration/service manager rather than just a package manager on non-NixOS.

Fwiw, you can already have nixos-rebuild read the home-manager configs for all of your users and deploy them as part of the normal NixOS config update process using the included NixOS module.

——

1: https://github.com/svanderburg/nix-processmgmt

Re: NixOS 21.05

#127

Post by pxc »

kaba0 wrote: post #110
toastal wrote: post #100

Earlier quoted context omitted.

I tried this on my previous laptop and ran into a number of issues once I tried to install anything with a GUI. It's fine for shells and CLI tools though. I migrated some configs over to a Nix configs under Arch, and while it was a pain to initially set up NixOS (unfamilarity), it's a lot easier doing everything else now.

Yeah, I’m not sure how up-to-date my knowledge is, but opengl and the like are exceptions to the usual deterministic handling of dependencies on non-NixOS distros (not because it is unable to do so, I think it is mainly to avoid storing everything n-times with nvidia/amd), and one has to specify them. It was quite a time I ran nix on a non-nixos distro but there is this tool https://github.com/guibou/nixGL that meant…

nixGL works without issue on my laptop's Ubuntu install, and the project also includes an equivalent wrapper for Vulkan rather than OpenGL.

Re: NixOS 21.05

#128

Post by takeda »

SkyMarshal wrote: post #91
e3bc54b2 wrote: post #26

Earlier quoted context omitted.

Alternative to what others have said, you can use your config to build a custom bootable ISO and use it to setup your new system. Comes very handy if you can't guarantee nice network for setup.

Last time I tried this, the NixOS Live USB still requires network connectivity to install. Is there some way to create an ISO or Live USB that installs completely offline?

Nix kind of expects to be always connected.

It is possible though, if you have the same config and use channels at the same revision (or use flakes) nix will know all packages it needs. You could fetch them and then either provide that machine as a cache, or use nix copy to copy the packages.

Re: NixOS 21.05

#129

Post by kaba0 »

earksiinni wrote: post #96

Ahhhh, Nix/NixOS. The package manager/OS that I so desperately wanted to love. I stuck with Nix for about six months. I even became a package maintainer. In the end, I gave up for three reasons: 1. Documentation is really bad. It's often confusing, incomplete or just plain wrong. What drove me crazy is the extreme imprecision with which certain fundamental concepts are referred to. For example, "derivations" are amon…

> never appreciated how much package management is intertwined with individual ecosystems' cultures until I tried using a "universal" package manager like Nix.

Unfortunately it is not a problem for nix to solve, they can’t really mandate upstream projects to not include hardcoded executables.

Also, the problem with npm/pip etc is that they are themselves package managers more or less trying to solve the same thing. So I would even wager that without some language-specific help nix can’t really work seamlessly across other dependency managers. Also, it is probably not even the best idea to replicate npm’s every dep inside nixpkgs (there are third-party nix repos).

Also, as an example Haskell has it sort of solved with a specific program that can translate a haskell specific dependency specification (analogous to package.json) to a .nix build file. There may very well be something similar for npm as well.

Re: NixOS 21.05

#130

Post by [deleted] »

mason55 wrote: post #108
bemeurer wrote: post #88

Earlier quoted context omitted.

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.

I'm so glad this is the official line now. People giving examples using nix-env -I is, IMO, one of the major reasons it's so hard to get up and running. It's like... here are all the amazing reasons to do declarative config... and here's how you do everything using nix-env -I. Good luck figuring out how to translate it into a NixOS config so you can get all the benefits of declarative config that we just described!

[deleted]
Post reply on HN