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

181–190 of 336 posts

Re: Nix – Death by a Thousand Cuts

#181

Post by sshine »

SuperSandro2000 wrote: post #167
sshine wrote: post #64

Earlier quoted context omitted.

> I figure that the developers know what they're doing and haven't made them the blessed path yet for a reason. My take is: flakes don’t align with centralised nixpkgs and ultimately don’t solve any problems that can’t be solved without flakes. They’re just an interface for a decentralised module system. You can use them, they’re feature-complete, and they don’t align with nixpkgs: it doesn’t make sense for individua…

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

Yes, they bring an interface.

And lockfiles that are automatically maintained where digests are extracted into.

Unlike if you do builtins.fetch* and pin those, in which case the digests end up in your source code.

Re: Nix – Death by a Thousand Cuts

#182

Post by sshine »

nixosbestos wrote: post #114
0x457 wrote: post #108

Earlier quoted context omitted.

> My take is: flakes don’t align with centralised nixpkgs and ultimately don’t solve any problems that can’t be solved without flakes. I've turned to flakes to specifically solve some problems, and flaked solved them. To this day, flakes are still the only way to solve them. Flakes aren't default due to political reasons.

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.

Re: Nix – Death by a Thousand Cuts

#183

Post by sshine »

jmholla wrote: post #116
0x457 wrote: post #108

Earlier quoted context omitted.

> My take is: flakes don’t align with centralised nixpkgs and ultimately don’t solve any problems that can’t be solved without flakes. I've turned to flakes to specifically solve some problems, and flaked solved them. To this day, flakes are still the only way to solve them. Flakes aren't default due to political reasons.

> I've turned to flakes to specifically solve some problems, and flaked solved them. To this day, flakes are still the only way to solve them. Can you share some examples of such problems?

I can say what I use flakes for at work:

I have a repository with system configurations for some CI infrastructure: a build server, a test runner.

The test runner can either be generated as an SD-card image using nixos-generators or live-updated using a remote `nixos-rebuild switch`. The OS configuration contains stuff about purposing specific motherboard GPIO pins.

Both systems depend on custom software not in nixpkgs; these are just hosted in private git and have a flake that mainly provide a devShell, but also provide a cross-compiled binary.

Flakes handle all of that in a predictable way: OS images, cross-compiled binaries, devShells, cross-repo linking, convenient hash-pinning.

Re: Nix – Death by a Thousand Cuts

#184

Post by XorNot »

photonthug wrote: post #180
lmm wrote: post #166

Earlier quoted context omitted.

> Which will reproduce the environment exactly, it's just not a guidebook on how it was built. By that logic every binary artifact is a "reproducible build". The point of reproducibility isn't just to be able to reproduce the exact same artifact, it's to be able to make changes that have predictable effects. > The value of most reproducibility at the Dockerfile is that we're actually agnostic to getting a byte-exact…

I do get the theoretical annoyance of how it’s technically not reproducible, but in practice most containers are pulled and not built from scratch. If you’re really concerned about that apt-get then besides a container registry you’re going to host a private package repository too, or install a versioned tarball from a public URL, but check the hash of whatever you’re downloading and put that hash in the dockerfile.…

The issue is it's why are you trying to be reproducible. The best use case is proving authenticity: that the source code became the binary code as written, but we're so far away from that that it's not realistic.

My dream system would be CI which gives me a gigantic object graph and can sign the source code from the ground up for every single thing including the compiler, so when a change happens you can drill down to what changed, and what the diffs were.

Re: Nix – Death by a Thousand Cuts

#185

Post by bsimpson »

sunshine-o wrote: post #111

I really like Nix but recently I ended up in a very tricky situation: If you you are cut from the internet or end up with a very slow connection you can end up totally blocked. As a minor configuration change can require you to download a lot of data. I also found out there is not much you can do to protect you from this.

Easy keyboard access is also a baked in assumption.

I found my way to Nix because I wanted to try SteamOS on nicer hardware than the Steam Deck. Bazzite is the recommendation in that space now, but at the time, there were a lot of equally unknown options. There's a community called Jovian that has replicated the SteamOS setup atop NixOS, using Valve's own sources. Using official sources and taking the chance to learn a new functional programming language seemed like as good a place to start as any.

When it works, it's great; however, +1 to all the gripes.

_Everything_ in Nix is set by writing to a text file and calling a CLI to rebuild. If you don't have ready access to a keyboard, you might not be able to so much as change the timezone. You can end up on obsolete versions of evergreen software like Chrome too, because Nix wants to own everything, and nothing changes until you rebuild.

Re: Nix – Death by a Thousand Cuts

#186

Post by denkmoon »

SuperSandro2000 wrote: post #155
Philpax wrote: post #145

Earlier quoted context omitted.

My experience has been in complete agreement with yours: I love the theory, but the practice is so, so painful. And yes, I also had to settle for your NVIDIA fix. I suspect I would have had a marginally better time on Arch as there are more people beating their heads against it and documenting how they made it work. NixOS documentation is piss-poor in comparison.

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

Re: Nix – Death by a Thousand Cuts

#187

Post by yoyohello13 »

SuperSandro2000 wrote: post #170
yoyohello13 wrote: post #45

I courted making the switch to NixOS a couple times, but I just don't really see the value add to me right now. Yes, if you have a lot of machines then it maybe make sense. At this point I just use Nix home manager for my dotfiles/userspace programs on a normal distro and I feel like I get 90% of the benefit without any of the headaches.

I delete your entire system file system right now. How fucked are you? With NixOS: I don't care. You can recover from a half deleted root file system.

Lol, please don't. I do take regular snapshots so it probably wouldn't be too bad.

Re: Nix – Death by a Thousand Cuts

#188

Post by yoyohello13 »

emarthinsen wrote: post #119

I use NixOS as my daily driver. I concur. I wouldn't recommend it for most people (even for me, when I decided to give it a try). I'd probably just go Arch if I were to do it over again. The concept behind Nix/NixOS is amazing, but it needs to be polished. Flakes are the future, but they are languishing in this experimental status. Even simple things like installing packages from stable and unstable channels are too…

After spending some time on NixOS I basically decided to hold off until flakes become official and the docs are written with them in mind. In the mean time I just run Arch with Nix home-manager and I'm happy.

I've developed enough good habits over the years that I don't get breakages, and home-manager allows me to easily sync my dotfiles across machines..

Re: Nix – Death by a Thousand Cuts

#189

Post by postcert »

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

The key terms don’t change so I usually just grep Nixpkgs in nvim and usually have a lead on where to start. Obviously it’s a bit more work than copy/paste from the arch wiki but generally more popular config changes will have an nixos option available.

Re: Nix – Death by a Thousand Cuts

#190

Post by dingi »

whazor wrote: post #130
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".

Nix currently has the most packages of any distribution, see https://repology.org/ The model of having packages on Github with pull requests scales very well. Therefore, you could argue that people are getting things done with Nix.

> Nix currently has the most packages of any distribution, see https://repology.org/

This is a meaningless point. Different distros split packages differently.

Post reply on HN