Hacker News new | ask | show | jobs
by taosx 383 days ago
Nope, not yet. I tried that 3 times, once for my mac, then for my linux and once for a project. Every time I gave it a solid try found it lacking so I made a note to wait a few more years. The promise of reproducible systems is so hard to resist but nix brings crazy complexity (not all of it necessary), I'd prefer a system where their package repo has 4 packages but it makes it easy enough to me to bring other packages.

Writing nix is like writing functions but in order to remember the arguments and fields of those arguments in another file that you can only access through your browser. Look at any nix file, and tell me where each variable is coming from.

3 comments

I have tried NixOS and the out of the box experience isn't bad, neither on my main VM nor my notebook. Everybody points you to flakes and flakes point you do use the unstable branch of nixos and that is where I say no. Then you learn a bunch of things along the way like upgrading replaces your stuff and you have to start again.

I've moved to Atomic desktops and can't name anything I am missing. For dev stuff there are containers.

Flakes and the unstable branch of NixOS (the `nixos-unstable` branch of Nixpkgs) are unrelated.

Flakes is an "experimental feature" of Nix itself, but it has shipped in stable releases of Nix for years now. There was a time when you had to build an unreleased version of Nix to play with flakes but that was a long time ago.

Whether you use a rolling release for the package set, e.g., nixos-unstable or nixpkgs-unstable, is orthogonal to whether or not you use flakes.

Fwiw, I generally prefer to run the unstable branches of Nixpkgs. Occasionally you hit something you have an opportunity to fix yourself, but that's not very frequent these days, even on the unstable branches.

Yeah I think this is a big flaw of declarative systems. I see a Nix derivation that contains `foo: bar`. How do I know what this does? It's pretty much impossible to know without learning all of Nix, because anything can access it.

If it was a function call you could just go-to-definition.

Environment variables have a similar issue. It's often hard to know what they do because they could be used by basically anything at any time.

I find this to be a real issue with environment variables.

I am trying to create a tool to help see exactly where and by which program any environment variable was set/exported since boot.

This is still in the conceptual phase but I'm looking into linux' ftrace to achieve this. Any ideas or pointers are welcome.

Yeah I think you can definitely find which process sets environment variables (I think you just need to intercept execve or whatever). The real problem is finding which processes use the environment variables. That's extremely difficult, if not impossible.
Right. Iirc the environment is put on the stack of a new process shortly after. Though I'd want to do this from very early on and then track how the environment changes. I thought of ftrace because it can be enabled/configured in a kernel parameter and as such will already capture information shortly after boot. But maybe it would be easier to work with ebpf or ptrace.
Its not that practical. I cr#ated a nix file to roll a new jellyfinmediaplayer client in nix and it worked until s(me update broke it but the audio and a few other things needed finding obscure nonsense and specifying it to work passably. Its been replaced by fi e sentences remnding me what to click installing bazzite and it works rock solid for very mnimal additiobal setup time