Comment by rgoulter | Hacker News Reader

Comment by rgoulter | Hacker News Reader

Parent Full thread

Yeah, Nix is a tough tool to learn. It's probably never the right tool to pick for "I just want something that works right now" if you're unfamiliar with it.

> I thought one of the main reason for nixos's existence is reproducibilty

NixOS uses "reproducible" to mean "with the same Nix code, you get the same program behaviour". This is more/less what people hope Dockerfiles provide.

This is the level of reproducibility you want when you say "it works on my machine" or "it worked last time I tried it".

Whereas "reproducible build" aims for bit-for-bit equality for artifacts build on different machines. -- With this, there's a layer of security in that you can verify that code has been built from a particular set of sources.

> Finding a config was hard too

What search query were you using? Searching "nixos configuration" on https://github.com/search?q=nixos%20configuration&type=repos...

Or searching for hyprland specifically, there seem to be many using that https://github.com/search?q=wayland.windowManager.hyprland&t...

> NixOS uses "reproducible" to mean "with the same Nix code, you get the same program behaviour".

Note that ”Nix code” also includes the hashes of all non-Nix sources. One way to think of it is that Nix has reliable build cache invalidation.

> This is more/less what people hope Dockerfiles provide.

Indeed, but importantly they do not provide input-reproducibility (while Nix does) because, at least, there are no hashes for remote data.

PSA: you can build OCI images with nix, then they'll be a pure function of their input like we've all wished was the case with Dockerfiles.

(And Nix derivations compose, whereas Dockerfiles entirely do not.)

I don't remember, some of them needed some other tools installed(like flakes whatever it is), I looked for configs, that looked like they don't need a few more hours to learn and to setup some other tools for them to work.

I just wanted to take a quick look at hyprland, I imagined I just use an existing config, I never thought it would need hours of research. Later I installed an arch vm and managed to install hyprland with some basic components in less than an hour from the first guide I found.

Looks like I misunderstood, what nix was made for. I just want a system I can more or less set up with a simple config file.

I saw this os, didn't have time to try it yet, but I thought this is how nix works. https://blendos.co/

For example you just define gnome like this, the nix configs I found looked similar, they just didn't work.

>gnome:

> enabled: true

> style: light

> gtk-theme: 'adw-gtk3'

> icon-theme: 'Adwaita'

> titlebar:

> button-placement: 'right'

> double-click-action: 'toggle-maximize'

> middle-click-action: 'minimize'

> right-click-action: 'menu'

> I just wanted to take a quick look at hyprland, I imagined I just use an existing config, I never thought it would need hours of research.

It shouldn't.

You'd want a simple flake to start with that has home-manager (for higher chance of finding declarative vest practice configs and modules) and to add small things to that.

I imagine you tried grabbing someone's complex config, modifying it, and ran into issues?

Flakes will hopefully be that soon but I wouldn't recommend starting with flakes when learning Nix in 2023. They're experimental and you still need to learn most of flake-less Nix (except channels and NIX_PATH) anyways.

When I started learning/using NixOS about two years ago I found it useful to start out with just Nixpkgs (i.e. what you get out of the box) and only add libraries when I felt they would help me. My first configs where ugly as hell and full of bad practice but the cool thing about Nix is that it gives you a lot of safety nets to enable experimentation and refactoring.

> Flakes will hopefully be that soon but I wouldn't recommend starting with flakes when learning Nix in 2023.

That Flakes provide a consistent entrypoint (and a consistent schema for such) into a codebase would have deferred a significant amount of confusion I had when getting started with Nix.

> They're experimental

The functionality as-is hasn't been changed. The 'experimental' flag itself hasn't been a practical problem.

However, flakes still have some rough edges & design problems to them, and there's some disagreement in the community over how flakes were rolled out.

I'd say for an end user, the benefits far outweigh the costs.

> ... and you still need to learn most of flake-less Nix (except channels and NIX_PATH) anyways.

I think the phrase "flake-less Nix" paints the wrong idea. I'd instead put it: Most of what you need to learn about Nix is unrelated whether the Nix evaluation started from a Flake or not.

> Flakes will hopefully be that soon but I wouldn't recommend starting with flakes when learning Nix in 2023. They're experimental and you still need to learn most of flake-less Nix (except channels and NIX_PATH) anyways.

I've used Nix for a decade and wouldn't recommend the confusing and horrible user experience of Nix without flakes.

Additionally, if you are using github for code examples, you'll have far more success using flakes.

Many experienced people a new user would get help from, including myself, have long since washed their hands of prw-flakes issues and arcana like channels issues.

I am on a similar journey

I built https://github.com/mikadosoftware/workstation (hey nearly 500 stars!) as the idea of defining a reproducible laptop build.

I don't think docker is the right level - so my next project when i have free time (!) is to do a box build that then might compile to docker

I think there is a sensible point of being able to define via nix both developer workstations and servers

Except it's Docker, and like virtually all Dockerfiles, it immediately runs "apt-get update", tossing reproducibility out the window.

yes, hence the (planned) move to flake.nix and then compile to docker.

Music to my ears! God speed, good luck!

Reply on news.ycombinator.com