Step two is not even necessary if you use zero-to-nix's installer. https://zero-to-nix.com/start/install

Yup, I just didn't wanna confuse the already pessimistic person by saying "use the unofficial installer" :)

You're omitting the entire thing about learning how to write nix. Which is nightmare fuel even for FP fans.

Unless you are attempting advanced things you don't need to know a lot about the language and how the more advanced things work.

Imo the harder part is learning bespoke build processes that you may not own in order to get software that assumes it can perform arbitrary network access or other naughtiness at build time to build successfully in a restricted sandbox.

The language is maybe a little strange at first but there's really not much to it.

Just find a project written in the same language that is already packaged and copy it, modify the name, version, source url, hash and that’s it.

It is one thing that is easier done from the top, instead from the bottom.

You don't have to know how to write Nix to write 95% of all Nix, it's just "JSON with functions" after all. There are definitely advanced things that the Nix and NixOS developers maintain for me.

Just like I don't know how to implement any crypto, or how to implement efficient 3D pathfinding I don't know how to implement NixOS. But I can write a derivation using the helper functions for the language I want to package, which aren't many these days since nixpkgs is huge already.

> Run the nix installer

Ok and this requires root access, sets up some global directories under root, and a new user. Me as the administrator: why the hell do I need a new user and what is the nix store and what are the conditions that mutate it? (I know the answers to this question, but it's a barrier for people who give a shit).

> Enable flakes

What the fuck is a flake? Reads a bit... what the fuck is a derivation? (again: I know the answers to these questions already, but the invention of jargon by nix devs is a massive barrier to entry that shouldn't be overlooked, it's extremely confusing)

> cd project

Ok now I'm comfortable doing things I know

> nix run

Fine, but what about auto envs and nix shell? I don't use these with make or cmake. I need to attach a debugger, where does it go? How do I set up my IDE that has no idea nix exists?

My point is, nix has a lot bigger of a barrier than these four lines, and it's really naive to think that's it.

Almost everything here is valid, but iirc the last time I ran the nix installer I thought it offered a home directory based install now that doesn't require root.

You can use in theory something other than /nix, but then you have to recompile everything yourself. So not many people do if, not sure about it’s state.

I just dipped my toe into the Nix pool a couple of weeks ago, and there are instructions to use root to create a /nix and grant ownership rw to your user account. No further admin required, but everything else seems to work as if using the Nix root user method.

The installer used to have an option for this, but nowadays it's discouraged. How come you wanted a single-user install so much? And j/w, are you on macOS?

Linux, but if there is ever an option to have one fewer services and/or root privileged things, I will take it.

Ok cool! The reason I asked is that the multi-user setup has more benefits on Linux than on macOS. That's because on Linux, the full build sandbox is actually available, and the store's immutability is enforced by default.

The tradeoffs are obviously yours to consider. But the normal Nix build sandboxing helps protect you from nasty things like crypto miners in setup.py or whatever, as well as improving reproducibility.

That's less relevant on macOS where the sandboxing story is not so great.

Personally, using Nix with a daemon seems like a better setup to me but adding another highly privileged process unnecessarily is obviously a real security concern. There is some ongoing work, btw, to reduce the level of privileges that the Nix daemon needs.

I think this is only true if your distro doesn't have user namespaces enabled, and many popular ones do not for security reasons.

It’s only a barrier if you want to be pedantic.

You have never asked the same detail of questions for any other os who can’t even provide grantees the answers won’t change next update, or when you install some random package.

Don’t pretend like you needed to know the user and mutability of directories when you have had a user for your printer dawmon and systemd and not once did this stop you from using a distro.

You're missing something important here.

Is Nix harder to learn for somebody who knows nothing about computers and OSes? Probably not. It might even be easier.

But that's not Nix's primary audience. It's targeted at people who already know a fair bit about the current paradigm and have plenty of skill with it. For those people, it's very different. Things that are easy for them will be hard until they learn the new paradigm.

I get that people who have already learned Nix and like it are in the new paradigm. Understanding it is not a problem for them. But pretending that work doesn't exist for others is unhelpful. And this sort of casual dismissal makes me suspect that even if I learned Nix, the experience still might be pretty bad. If Nix advocates can't take seriously the difficult noob experience, maybe the experience is painful all the way through.

I think the parent was focusing on the first point about the install. That particular argument against creating users and writing to directories would be a barrier to install any software.

> > Run the nix installer

> Ok and this requires root access

On a tangent: I wonder why this is still the default.

The nixStatic binary has, since quite a while, support to as a non-root user create a "${XDG_DATA_HOME:-${HOME}/.local/share}/nix/root/nix" -> "/nix" unshare chroot before running the rest of the command if "/nix" is missing.

It's only a real issue if you really need to run something as root, or something else that needs unshare chroot itself, but in that case, I guess you could just have a /nix store folder anyways.

Okay, so you're required to read some documentation ahead of time, that's where your problem lies.

What's a Terraform module? What is Terraform? What is a provider? Why don't I just build all my infrastructure with the AWS Console? Why is it it's own weird language? What is this state thingy that just ended up in my folder? Do i give it to the devs?

I think it's pretty much consensus that Terraform is great for provisioning anything with an API. Nix does the same for your packages, partitions, OS, containers, shells and many more things in the same functional manner.

In a company not everyone has to be a Nix wizard either, if a small team knows Nix they can build the Nix infra, then developers can reap the benefits of not having to mess with it at all.

Just because people are unable to comprehend the benefits doesn't mean they do not exist. And if you wanna reap great benefits you might need to spend an hour or two reading things.

Yes it's a novel way of doing things, but it's also one of the most actively developed projects with one of the highest amounts of contributors in the world.

https://discourse.nixos.org/uploads/default/original/2X/9/9b...

> Fine, but what about auto envs and nix shell? I don't use these with make or cmake. I need to attach a debugger, where does it go? How do I set up my IDE that has no idea nix exists?

The people that know Nix well enough will assist the ones that doesn't know, if you enter a nix shell and start vscode from there it'll be aware of $PATH which Nix sets, meaning it'll find all your dependencies.