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

Nix – Death by a Thousand Cuts

dgt.is

Post reply on HN
Print view View original

241–250 of 336 posts

Re: Nix – Death by a Thousand Cuts

#241

Post by exe34 »

rob_c wrote: post #72
azeirah wrote: post #69

Earlier quoted context omitted.

The more I use nix, the more I understand it's both. Nix is genuinely so fucking great, but the ecosystem and docs and language are a mess. It needs to be cleaned up, and things _are_ getting better. The core philosophy of Nix is so damn solid though, and that's the real innovation here. As long as its philosophy manage to stick around, then it's ok.

It's basically, I refuse to learn how to containerize. Just learn, use, promote best practices and stop forking the ecosystem _even_ further... There, I got that off my chest.

no thank you.

Re: Nix – Death by a Thousand Cuts

#242

Post by [deleted] »

hamandcheese wrote: post #222
SuperSandro2000 wrote: post #167

Earlier quoted context omitted.

Flakes bring you one interface to share common dependencies which is kot possible without an interface.

That interface could have been built in vanilla nix, though. Instead, a bunch of very useful features are bundled with flakes, like pure eval, eval caching, and git-awareness. But flakes still have some showstopping usability issues preventing users from benefiting from these great features. Issues like that it copies your repo root to the nix store on every evaluation, which scales terribly to bigger repos. Not to m…

[deleted]

Re: Nix – Death by a Thousand Cuts

#243

Post by otabdeveloper4 »

jcmfernandes wrote: post #61

I'm relatively new to nix, and this cut close: > At this point NixOS has been around for 2 decades, but it still feels like it has not settled on good recommended workflows for incoming users. Yes. This was a major pain point when I was getting started. The IRC community has been helpful in this regard. I also really don't like that nixpkgs serves as both a lib and a package set. Be one! I don't want "special" inputs…

> good recommended workflows for incoming users

Users of what exactly?

Workflows for configuring a desktop to play Steam games is vastly different from workflows for managing a cattle fleet of enterprisey servers.

Re: Nix – Death by a Thousand Cuts

#244

Post by nixosbestos »

sshine wrote: post #182
nixosbestos wrote: post #114

Earlier quoted context omitted.

Yeah, I am flabbergasted that anyone can claim flakes don't solve problems. And yet, every SINGLE WEEK some newcomer gets tripped up on channels, managing them, realizing the root's channels are different than users, realizing their channels are out of sync on their multiple machines, no posting their channel revision when they solicit help. Not to mention pure eval. Not to mention transitive dependency overriding.

> I am flabbergasted that anyone can claim flakes don't solve problems Yes, that would be an outrageous claim! That is, of course, not what I said. Arguing that channels lead to more problems than flakes is a good argument in favour of adoption of flakes. But you can also abandon channels without adopting flakes. Which is what I said: flakes don’t solve any problems that can’t be solved without flakes.

Which is why I mentioned transitive dependency management, and pure eval. Both of which are absolutely not solved by npins, etc.

Re: Nix – Death by a Thousand Cuts

#245

Post by jcmfernandes »

otabdeveloper4 wrote: post #243
jcmfernandes wrote: post #61

I'm relatively new to nix, and this cut close: > At this point NixOS has been around for 2 decades, but it still feels like it has not settled on good recommended workflows for incoming users. Yes. This was a major pain point when I was getting started. The IRC community has been helpful in this regard. I also really don't like that nixpkgs serves as both a lib and a package set. Be one! I don't want "special" inputs…

> good recommended workflows for incoming users Users of what exactly? Workflows for configuring a desktop to play Steam games is vastly different from workflows for managing a cattle fleet of enterprisey servers.

On how to assemble your config. Every config I open does things a little bit different, from the get-go, when using flakes. Add package sets as overlays to nixpkgs or pass inputs downstream? How to parametrize "system"? What's stuff like flake-parts and flake-utils for? Should I use them? All these came to my mind on the first day.

Re: Nix – Death by a Thousand Cuts

#246

Post by dgfitz »

nbbaier wrote: post #205
dgfitz wrote: post #128

Earlier quoted context omitted.

> I think we've gotten used to development environments being a shitty experience to the point where it seems part and parcel of programming… I have staunchly refused to allow this at my current employ, and I’ve been there long enough where I can steer this. This isn’t acceptable and all it does is help introduce inconsistency and regressions. I realize I am fortunate in that I can effect change at my job in this are…

What's been your strategy for doing this

Well the short answer is: I defined the workflow/process for our team, everyone bought in, and new people don't really have a choice but to follow along.

The longer answer is, earlier in my career I ended up spending a not-insignificant amount of time helping people debug things, and about 70% of the time the issue was their local build environment. Everyone did it differently and it was very messy.

I only made a few "rules" to follow. 1.) Your local folder structure must mirror exactly the structure in our central repo. 2.) Must use relative paths, which works when you follow rule 1. 3.) No ad-hoc "new shiny things" without team buy-in. If it can be used locally only and won't affect the team obviously I don't care.

Re: Nix – Death by a Thousand Cuts

#247

Post by pjmlp »

pkkm wrote: post #95
Baeocystin wrote: post #65

The older I get, the more I realize that so much of the divide in the tech field is simply between the two camps of "the tools are the interesting part" vs "getting things done with the tools is the interesting part".

Your veiled implication that Nix and NixOS aren't about "getting things done" is, I think, more than a little unfair. I'm using multiple programming languages at work. Each one of them has its own dependency manager that does basically the same job as the other ones. In Python it's Poetry, in Ruby it's Bundler, in JavaScript it's npm/yarn, in PHP it's Composer, etc. A lot of projects require extra setup steps outside…

Naturally the solution is to use a complete different OS stack. /s

Re: Nix – Death by a Thousand Cuts

#248

Post by ParticlesRWaves »

I recently tried NixOS 24.11 but quickly decided it’s not for me or something I’d recommend. While the system initially seemed promising, it was frustrating in practice.

My first hurdle was configuring the network in configuration.nix. The installed template implies network settings go there, but that’s misleading. Worse, "nixos-rebuild switch" requires a working network, so a broken config leaves the system unable to fix itself – a catch-22.

Next, I tried "nix search wget", as suggested in the manual, but hit errors about missing experimental features. I had to enable both nix-command and flakes manually to get this to work:

    nix --extra-experimental-features nix-command --extra-experimental-features flakes search nixpkgs wget
Even then, package search, like configuration, seems to depend on a network connection, which feels unnecessarily fragile.

(edit: formatting)

Re: Nix – Death by a Thousand Cuts

#249

Post by _emacsomancer_ »

nemoniac wrote: post #98
James_K wrote: post #86

I only wish Guix had a more robust nonfree packages I think it could really give Nix a run for its money.

If you're looking for robust, nonfree packages for Guix, you can find them here: https://github.com/nonguix/nonguix

Also, for a wider search for packages across non-official channels: https://toys.whereis.social/

Re: Nix – Death by a Thousand Cuts

#250

Post by Philpax »

denkmoon wrote: post #186
SuperSandro2000 wrote: post #155

Earlier quoted context omitted.

Most people don't realize that you can read the arch wiki and put the same settings into the nixos options. Where is the point in replicating that all again?

My one big question about nix is how the hell do I find out those options? Like cool, I know I need to set the config to some specific value based on arch wiki, but how do I read the nix package to find out what config "key" to use? I've never been able to work out where these are defined

I look at the Nix definition for the relevant module as you often need to see what it's actually doing in order to understand it (yes, it's one of those ecosystems).

For example, for the `steam` program (not package - the package is a dummy): https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/p... and then look for "lib.mk".

Post reply on HN