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

We want to make Nix better

determinate.systems

Post reply on HN
Print view View original

21–30 of 204 posts

Re: We want to make Nix better

#21

Post by rgoulter »

Jeaye wrote: post #15

Writing the packaging expressions should not be harder than writing the program, for the average developer. The average developer doesn't know FP, at this point. Nix needs: 1. Approachability for those not indoctrinated in lazy, declarative, functional programming (i.e. Haskell); nope, Nix Pills are not sufficient for the average dev 2. Editor tooling to help guide the writing of expressions (just as anyone learning…

> they haven't been able to focus on the UX. I also feel like folks for whom Haskell is comfortable may not realize just how absurd it feels to everyone else.

The majority of communication I've seen from Nix maintainers over the last few months has been about exactly this.

The submitted post is about exactly that while Nix powerful, they want more people to be able to use it without having to pay a steep penalty to learn it.

Re: We want to make Nix better

#22

Post by grhmc »

ridiculous_fish wrote: post #4

I installed nix on my Mac but quickly backed out due to the complexity. I assumed the nix store would just be an ordinary directory with a tool for managing it, similar to brew. I discovered it creates a new Unix group, adds a separate APFS volume, installs a daemon. This was too invasive for a tool I was unsure if I even wanted to use, so I uninstalled it. What is the reason for all this machinery? I went with the r…

Single-user Nix installs are lighter weight, but also have a major compromise: the store is writable by the user. This means it is pretty easy for software you're using to accidentally change the store underneath Nix, and create unpredictable and unreproducible behavior.

I think the multi-user install is a better Nix experience, even if the install process is spookier.

Like is mentioned elsewhere, Docker does similar contortions to install itself. I wonder if it would have been more palatable if the Nix installer was less forward about what it is doing?

Re: We want to make Nix better

#23

Post by tadfisher »

ridiculous_fish wrote: post #4

I installed nix on my Mac but quickly backed out due to the complexity. I assumed the nix store would just be an ordinary directory with a tool for managing it, similar to brew. I discovered it creates a new Unix group, adds a separate APFS volume, installs a daemon. This was too invasive for a tool I was unsure if I even wanted to use, so I uninstalled it. What is the reason for all this machinery? I went with the r…

> What is the reason for all this machinery?

> new Unix group

This is used for the daemon, so it doesn't run as root and expose your system to Nix build code.

> adds a separate APFS volume

I think this is required because of macOS security restrictions preventing direct modification of the root directory. The Nix store has to be housed in /nix because all references to runtime dependencies in the store are absolute paths in /nix, and that can't really change per system because it would break caching and reproducibility. The separate volume is added to /etc/synthetic.conf so it can live in /nix.

> installs a daemon

For multi-user installs, this allows non-privileged users to add build outputs to the Nix store, which ultimately allows these users to share build outputs. More info here: https://nixos.org/manual/nix/stable/installation/multi-user....

Re: We want to make Nix better

#24

Post by ParetoOptimal »

qudat wrote: post #9
edolstra wrote: post #5

Earlier quoted context omitted.

It's because Nix wants to install into /nix. Once upon a time doing "sudo mkdir /nix" wasn't a problem, but recent macOS releases have made that very hard. Nix could switch to an alternate location on macOS (e.g. /opt/nix) but that has a lot of downsides for interoperability with other systems.

Yikes, I had no idea. What a tough pill to swallow all because the directory nix runs out of is hardcoded.

> What a tough pill to swallow all because the directory nix runs out of is hardcoded.

Yikes? Well then... how would you solve remote binary caching with something like Nix on a platform such as OSX without userns remapping support?

Re: We want to make Nix better

#25

Post by Macha »

0x457 wrote: post #6
ridiculous_fish wrote: post #4

I installed nix on my Mac but quickly backed out due to the complexity. I assumed the nix store would just be an ordinary directory with a tool for managing it, similar to brew. I discovered it creates a new Unix group, adds a separate APFS volume, installs a daemon. This was too invasive for a tool I was unsure if I even wanted to use, so I uninstalled it. What is the reason for all this machinery? I went with the r…

APFS volume is required to have a read-only nix-store at /nix. The daemon is only required in multi-user installation, and you can opt out of it (by using a single-user install). New groups are for letting people submit jobs to builders in multi-user mode.

Note that the multi-user installation is these days the only suggested approach by the Nix team for new MacOS installations - the old instructions for single user installation on MacOS have been removed from their site.

Re: We want to make Nix better

#26

Post by zuzuleinen »

"But there’s a catch: to make that happen you need to write some Nix, use Nix tools, and probably consult several documentation sources."

You can use bob[1] if you want a build tool which uses Nix to install dependencies in an easy manner: just list the package names for a task and then they will be installed.

I'm looking forward for all the changes in Nix ecosystem and it's a good sign the fact that they also started working on an initiative to improve Nix documentation which was spread all over the places.

[1] https://bob.build/

Re: We want to make Nix better

#27

Post by shiryel »

I love nix, I've been using it for the last 2 years, I have a very stable setup from these 2 years of effort [0], and I just can't recommend Nix for Linux beginners, why?

It's not because of the nix language, It's not because of the CLI, it's because everything is scattered, you have to consult many places to find out how to do things with Nix, here is an example:

Usually, when I need a new complex program, like Steam, I first check the system-wide configuration [1], the wiki [2] and the package list [3], if I just want it on my user, I need to check if Home Manager has an option [4], if it doesn't, I can try using the "home.packages" option. Now, if I need to override something on the package, I need to remember how to do it with [5] [6] (while checking the source code for the package in parallel to find the options).

And then sometimes, on very rare occasions, I need to fine tune something with the nix language, so I need to check the builtins/lib docs [7], but some builtins are not there, so I need to either use nix-doc [8] or find the docs inside the code-bases [9] [10] (they are split between both repos)

For me, this is one of the main pain points of using Nix / NixOS that needs to be solved.

[0] - https://github.com/shiryel/nixos-dotfiles

[1] - https://search.nixos.org/options

[2] - https://nixos.wiki/wiki/Steam

[3] - https://search.nixos.org/packages

[4] - https://mipmip.github.io/home-manager-option-search/

[5] - https://nixos.org/manual/nixos/stable/#sec-customising-packa...

[6] - https://nixos.org/guides/nix-pills/nixpkgs-overriding-packag...

[7] - https://teu5us.github.io/nix-lib.html

[8] - https://github.com/lf-/nix-doc

[9] - https://github.com/NixOS/nix

[10] - https://github.com/NixOS/nixpkgs

Re: We want to make Nix better

#28

Post by rgoulter »

rrgok wrote: post #18

Beside being invasive on MacOS, as said by @ridiculous_fish, it took me more than 3 hours (and it didn't yet finish, I just quit all) to use QMK. I just cloned the Github repository of QMK and did `nix-shell` as they provide shell.nix file. 1. Does every nix-shell require building the whole world from ground-up? Seems impractical to me. 2. What is the right approach? This is not to bash Nixpkgs, because I installed N…

> 1. Does every nix-shell require building the whole world from ground-up? Seems impractical to me.

It's the same as homebrew:

If there's a cached binary already, it will download the cached binary. If not, it will fetch the source and build it.

The QMK nix shell needs different GCCs for different targets. For the QMK shell.nix specifically, you can disable the targets you don't need (e.g. if you don't use a teensy board).

Re: We want to make Nix better

#29

Post by ParetoOptimal »

grhmc wrote: post #22
ridiculous_fish wrote: post #4

I installed nix on my Mac but quickly backed out due to the complexity. I assumed the nix store would just be an ordinary directory with a tool for managing it, similar to brew. I discovered it creates a new Unix group, adds a separate APFS volume, installs a daemon. This was too invasive for a tool I was unsure if I even wanted to use, so I uninstalled it. What is the reason for all this machinery? I went with the r…

Single-user Nix installs are lighter weight, but also have a major compromise: the store is writable by the user. This means it is pretty easy for software you're using to accidentally change the store underneath Nix, and create unpredictable and unreproducible behavior. I think the multi-user install is a better Nix experience, even if the install process is spookier. Like is mentioned elsewhere, Docker does similar…

> I wonder if it would have been more palatable if the Nix installer was less forward about what it is doing?

I bet most wouldn't consider it spooky if the installer didn't print it out.

If docker started printing it, I bet lots of people would complain it seems similarly complex.

Re: We want to make Nix better

#30

Post by biggestlou »

zuzuleinen wrote: post #26

"But there’s a catch: to make that happen you need to write some Nix, use Nix tools, and probably consult several documentation sources." You can use bob[1] if you want a build tool which uses Nix to install dependencies in an easy manner: just list the package names for a task and then they will be installed. I'm looking forward for all the changes in Nix ecosystem and it's a good sign the fact that they also starte…

Bob is very cool and I think that there's room for lots of tools like this that build _on_ Nix but abstract away some of the trickier parts.

Suggestion: make Bob installable with Nix!

Post reply on HN