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

I think it's time to give Nix a chance

maych.in

Post reply on HN
Print view View original

121–130 of 156 posts

Re: I think it's time to give Nix a chance

#121

Post by microtonal »

subsection1h wrote: post #84
elsjaako wrote: post #18

Earlier quoted context omitted.

The source code is retrieved from the official source of the package, and checked against a hash that is stored in the package definitions. All the package definitions are stored in a large github repository, and they are "code reviewed". For example, you can see where the xz sources get pulled from in the src section here: https://github.com/NixOS/nixpkgs/blob/nixos-25.05/pkgs/tools... As usual, wherever you get you…

> All the package definitions [...] are "code reviewed". [...] with maybe some reviewed patches to get it to work in Nix's environment. In order for people to review Nix package definitions and patches, do they need to have their keys signed by other Nix contributors they meet in person like Debian contributors do? https://www.debian.org/events/keysigning

No. People who have contributed a lot can get nominated and if no one raises objections, they typically get the commit bit.

It is less than ideal. On the other hand, self-reviews/merges are frowned upon, so there is normally an extra set of eyeballs that checks changes. Besides that, nixpkgs has a really large number of non-committer contributors. Packages often get touched by multiple if not tens of people. So, even though Linus' law typically doesn't hold up, I do think it holds up pretty well for nixpkgs.

Re: I think it's time to give Nix a chance

#122

Post by roydivision »

> More importantly, Docker containers themselves aren’t reproducible—running apt-get update or pip install requests at different times can yield different results, even with the same Dockerfile.

apt-get install =

> And frankly, no one really needs Kubernetes, they just have it because everyone and their grandma has it. I digress, that’s a topic for another day.

Oh grow up, ffs.

Re: I think it's time to give Nix a chance

#123

Post by exe34 »

sepositus wrote: post #48
exe34 wrote: post #44

Earlier quoted context omitted.

> Welcome to the honeymoon phase. Mine lasted about a year Mine has been going on since 2016, what am I doing wrong?

> they just don't try hard enough The answer was in my post. Nix isn't for everyone, and that's OK.

I've actually gone the other way - not everything is meant to be run. If it's not in the nix repos, I'll try the fhs, and if that doesn't work - well I probably don't care enough to beg it to run. For me the fact that my base installation can never break is not negotiable.

I definitely didn't learn much of nix(os|pkgs). I never bothered learning about flakes. I just have a configuration.nix and a user config.nix, and a "fhs" default.nix and that's it.

Re: I think it's time to give Nix a chance

#124

Post by Tractor8626 »

__MatrixMan__ wrote: post #107
Tractor8626 wrote: post #75

Wow. 1) you can python environment with dependencies! (can do that without nix) 2) you can pin dependencies by hash! (can be done with any tool mentioned in article: docker, pip, npm etc) If you can't make reproducible dev environment in 2025 - it is 100% skill issue.

Having to think about docker's hashing/caching scheme and also pip's and also npm's and to apply them each separately in CI and in a local environment and in dev/stage/prod... for a large repo that's a lot of work. Easy to overlook whichever one you're less concerned about at the time and put the repo in some kind of inconsistent state where something works here but not there. There's a lot to be said for having a si…

No. It is not nearly as hard as you make it sound.

If I had to work with such mess of a project - I wouldnt bother with package managers at all. I just download and commit all dependencies to repo.

If dependencies are not supposed to change anyway - what is the point of downloading them from all over internet each time?

Re: I think it's time to give Nix a chance

#125

Post by benreesman »

Nix is still waiting for its GitHub moment. It's possible to live a strictly better life (as an individual or company) via Nix and NixOS but there's still a ton of lore and inside baseball that requires a pressing need to justify learning it all. If there's a serious Nix person in your company or friend group it's time, otherwise be ready for a learning curve that's only worth it if you have one of the problems it solves (if Docker is starting to be a weird init system or devs are finding excuses to go around it). It's the choice of people who can't compromise on anything (Anduril, more and more trading shops, shit like that).

Nix is in a bit of a split/argument/fork-prone thing at the moment but it looks like this will settle into a practical/purist thing where everyone can be happy, so go in knowing which crowd is your people.

I'm not a purist so listen to one of them if you are. That said:

- flakes aren't optional or experimental, they're the default, its a small clique holding it up for years and its getting forked around by everyone serious

- flake parts is looking like a lock for the de facto flake standard, something else might come along but the leet stuff is congregating around it

- Cachix devenv is a good gateway drug: its better than Docker and easier to graduate from when it gets serious on that component

- nix-ld and FHS envs aren't a sin, they fix most all the friction bilugs and should be the default design, I overlay the shebang thing and all the unfree restrictions and all of it: the incompatible by design people are aging out, this will all work flawlessly in a year or two and you can do it today but its inside baseball

If you need to support Mac and Linux without the limitations of a strict all-OCI flow it's your best option, if you need a chance in hell against serious supply-chain attacks its your best starting point. If you need to run on a mix of metal and cloud and/or double-virtualizing is an issue its The Way.

The best super accessible resource to go from zero to "holy shit computers can do that" is vimjoyer's YouTube.

Use sops.nix and your secrets management is solved. Also by Mic92 is nixos-generators, that is basically infinitely portable to anything. juspay's GitHub, srid's GitHub, pretty much all the nixos-asia stuff is galaxy brain next level. It all works great on MacOS if you're not over it yet with the telemetry.

(sidebar: telemetry is your biggest computer problem now and your phone addiction is part of the telemetry deal. Linux and Graphene and NextDNS and Proton and stuff are worth it even for Grandma finally. I'm glad the purists do their thing, its an act of service).

Re: I think it's time to give Nix a chance

#126

Post by Tractor8626 »

corndoge wrote: post #118
Tractor8626 wrote: post #86

Earlier quoted context omitted.

In such cases I use either docker or mmdebstrap.

Nix would work too, and that fact touches on one of the main advantages of Nix - it solves the problem at a low enough level that it works in all cases.

There is hidden assumption what using one tool for everything makes things easier.

Does it though? If using one tool is harder than using several - there is no advantage here.

Re: I think it's time to give Nix a chance

#127

Post by codethief »

davidcox143 wrote: post #115
codethief wrote: post #103

Earlier quoted context omitted.

Do you have a link that explains what atoms are? This is the first time I'm hearing about them.

Sort of. There’s a summary by the author of atoms in the Twitter thread linked above. They also link this very lengthy blog post: https://nrd.sh/blog/atom-anatomy/ My understanding of atoms compared to flakes is that they 1) add toml 2) provide a more precise way to reference remote src. The author also claims performance benefits. I haven’t used them personally and can’t speak to their stability or ergonomics.

Thanks!

Re: I think it's time to give Nix a chance

#129

Post by pabs3 »

OscarCunningham wrote: post #54

I recently installed NixOS on my laptop after years of using Debian, and the main difference I noticed was that it's much easier to keep everything clean. For example with Debian I might do something like try to get my GPU to work by installing nouveau, try various configs, then uninstall nouveau and install the Nvidia proprietary drivers. But then when I finally got the GPU working, I'd worry. Are some of those conf…

The Debian cruft-ng package, plus package list diffs, can identify problematic state you have added to the system.

Re: I think it's time to give Nix a chance

#130

Post by pabs3 »

weinzierl wrote: post #64
__MatrixMan__ wrote: post #30

Earlier quoted context omitted.

As I see it there are three components of software supply chain security: - is this actually the binary that comes from that code? - is that code trustworthy? - is this binary trustworthy? Nix focuses on the first. If you can solve that problem, there's still nothing preventing bad guys from publishing malicious code, or from distributing malicious binaries which did not actually come from the code that they claim to…

Thanks for that detailed argument, especially for pointing out the three necessary components. I agree even with the following paragraph in principle: "If you're wondering whether whatever.sh is safe in the first place, and you want some council of elders to pinky promise that it's safe to run, then I don't think the nix ecosystem has much to offer you." For me it is not so much about what the council of elders says,…

These are the solutions to the three components:

> - is this actually the binary that comes from that code?

Reproducible Builds that are also Bootstrappable Builds, starting from a minimal auditable machine code seed.

https://reproducible-builds.org/ https://bootstrappable.org/ https://lwn.net/Articles/983340/ https://stagex.tools/

> - is that code trustworthy?

Socially distributed code auditing:

https://github.com/crev-dev/

> - is this binary trustworthy?

The other two combined should provide this.

Post reply on HN