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

281–290 of 336 posts

Re: Nix – Death by a Thousand Cuts

#281

Post by hamandcheese »

SuperSandro2000 wrote: post #269
hamandcheese wrote: post #222

Earlier quoted context omitted.

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…

Everyone has some opinion. There are the people that say that flakes do to much and others are saying they do to little. No matter in which direction you go, someone is always unhappy. Eval caching depends on pure eval and pure eval was previously not possible because channels are by design the most impure and cursed thing and are just a bandaid that lasted way to long. The scaling with big repos gets worse as some u…

> Flakes are still unstable because everyone wants something

Yeah, that is definitely true (as evidenced my complaints). I firmly believe the original sin of flakes was how many things it bundled together.

Re: Nix – Death by a Thousand Cuts

#282

Post by Cyph0n »

knoopx wrote: post #219
Cyph0n wrote: post #123

Earlier quoted context omitted.

Nix handles containerization better than Docker does. Here is a flake that builds a Go app and a Docker image for it (based on headless Chrome): https://github.com/aksiksi/ncdmv/blob/aa108a1c1e2c14a13dfbc0... And here is how the image is built in CI: https://github.com/aksiksi/ncdmv/blob/aa108a1c1e2c14a13dfbc0...

here is a derivation that fetches https://www.usememos.com/ from source, changes the color palette, builds a docker image out of it and spins up a container that traefik exposes automatically: https://gist.github.com/knoopx/afde5e01389e3b8446f469c056e59...

Very cool! I actually considered implementing the Compose Build spec this way for compose2nix, but instead opted to just use Docker/Podman directly.

Re: Nix – Death by a Thousand Cuts

#283

Post by edude03 »

cge wrote: post #280
edude03 wrote: post #77

Earlier quoted context omitted.

As a heavy container user myself - I've been using containers since I needed to build my own 3.x kernel to test them - docker doesn't solve the reproducibility problem nix solves - IE, I can make a Dockerfile that does `RUN curl foo.com/install.sh` and who knows if that'll work ever again. Nix on the other hand doesn't allow you to do IO during builds[^0] only describe the effect of doing the IO. [0]: Though apparent…

>who knows if that'll work ever again Unless you restrict your nix files to specific channel revisions, which when I had to deal with it was poorly documented, and involved searching through specific channel commit hashes in a particularly opaque way, you also can't know that your nix derivations will ever work again. A number of people on my field used nix as a way to make their research code repositories reproducib…

Yeah that's a ux papercut - pre flakes nixpkgs was always the nixpkgs on your machine. There is docs but if you're not expecting that to happen you wouldn't think to look up the docs.

Re: Nix – Death by a Thousand Cuts

#284

Post by choobacker »

zie wrote: post #267
choobacker wrote: post #227

Earlier quoted context omitted.

To mitigate breakages we should be aiming for better test coverage, at various build levels: class, package, program, system. Our industry's story for system-level testing, for Linux distributions, is poor. NixOS tests are decent, but need more coverage, and something similar needs to be available to upstream so issues are caught during development. Meanwhile, LTS releases have downsides: * Alienating you from upstre…

If your software is in such heavy development that you need changes all the time, it should never be in a stable distro to begin with, it's not stable code. Overall(last I checked), the testing is roughly equal between the stable distro's(Debian/Ubuntu/etc) and NixOS. The difference is stable distro's back-port bug-fixes. NixOS rarely does, since their release cycle is only 6 months long. > * Alienating you from upst…

> If your software is in such heavy development that you need changes all the time, it should never be in a stable distro to begin with, it's not stable code.

Stable code by this definition experiences some stagnation. But the cost of stagnation is worth it for the stability. That's LTS.

Slowly, we'll build enough checks that we can achieve frequent change and still be stable. This is partially here, and "unevenly distributed".

> Overall(last I checked), the testing is roughly equal between the stable distro's(Debian/Ubuntu/etc) and NixOS. The difference is stable distro's back-port bug-fixes. NixOS rarely does, since their release cycle is only 6 months long.

NixOS has system-wide tests that run on PRs, and go green if they pass. E.g. upgrade OpenSSH will trigger a suite of VMs to start, each running OpenSSH in different configurations, and checking they work as expected. These run automatically, are visible to contributors/reviewers, and take O(minutes) to complete. They run on automated backport PRs too.

> contribute upstream, regardless of if I'm running NixOS, Debian Stable or Windows. It makes no difference to me which OS I'm running when a bug shows up. If I find a bug in X package, I go fix X package. Sure I also fix it locally in my running instance(s), but that's my problem, regardless of which OS I'm running.

Bravo. But I don't think it's controversial to suggest that, on average, the closer a person is to upstream version, the more likely they will be to have the motivation and success in making a contribution that meets theirs and and upstream's needs.

Re: Nix – Death by a Thousand Cuts

#285

Post by vendiddy »

azeirah wrote: post #69
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".

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.

This is how I feel about Nix.

I've given it a try and it's quite incredible how easy certain things are.

The problem is the Nix language and the developer experience are really rough.

There's a chance that Nix could figure this out or a competitor with Nix-like ideas could become mainstream. That's my hope anyway.

It would be a shame if the ideas behind Nix got dismissed because of the current issues with Nix.

Re: Nix – Death by a Thousand Cuts

#286

Post by indrora »

choobacker wrote: post #211

I'm a NixOS user and contributor. This post is fair. Nix is very flexible, and it hasn't yet stabilised on a firm set of recommendations for a happy path. Going on a whim: * Use nixos-unstable. It's defacto stable, and gets much more attention than nixos-stable. * Use flakes. * Don't use multiple versions of nixpkgs. In the rare case a package is failing to build, then raise an issue, or wait, or rollback. * On NixOS…

I attended NixconfNA last year as part of SCaLE.

I spent quite a while trying to understand what Nix was actually trying to accomplish and how one would actually go about using it. Granted I was trying to do it on a Chromebook, but the idea stands: I should be able to get at least the nix environment set up and the silly gnu hello world built and running, right?

Turns out nah. The ergonomics are just that of a hiltless double bladed sword.

I'm glad I'm not the only one, but i also was aware of pushcx trying years ago and still failing [1] and he's a smart dude unlike me. I didn't feel so dumb.

[1] https://push.cx/nixos

Re: Nix – Death by a Thousand Cuts

#287

Post by choobacker »

indrora wrote: post #286
choobacker wrote: post #211

I'm a NixOS user and contributor. This post is fair. Nix is very flexible, and it hasn't yet stabilised on a firm set of recommendations for a happy path. Going on a whim: * Use nixos-unstable. It's defacto stable, and gets much more attention than nixos-stable. * Use flakes. * Don't use multiple versions of nixpkgs. In the rare case a package is failing to build, then raise an issue, or wait, or rollback. * On NixOS…

I attended NixconfNA last year as part of SCaLE. I spent quite a while trying to understand what Nix was actually trying to accomplish and how one would actually go about using it. Granted I was trying to do it on a Chromebook, but the idea stands: I should be able to get at least the nix environment set up and the silly gnu hello world built and running, right? Turns out nah. The ergonomics are just that of a hiltle…

Yes, the ergonomics are poor. I endure them for the results, but the ergonomics should be better.

Guix has better ergonomics, but it's own set of downsides.

I expect the underlying idea of holistic declarative systems is sound, and we're awaiting a polished alternative. Maybe it'll reuse nixpkgs under the hood , but replace the name, the tooling, and the language exposed to the user.

Re: Nix – Death by a Thousand Cuts

#289

Post by Macha »

bsimpson wrote: post #185
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…

Possibly helpful: You can rebuild a remote system with the --target-host option of nixos-rebuild

Re: Nix – Death by a Thousand Cuts

#290

Post by bsimpson »

Macha wrote: post #289
bsimpson wrote: post #185

Earlier quoted context omitted.

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…

Possibly helpful: You can rebuild a remote system with the --target-host option of nixos-rebuild

Thanks. I didn't know that, but I only rebuild via SSH anyway (so it's basically the same thing).
Post reply on HN