[0] https://docs.determinate.systems/determinate-nix

https://github.com/snowfallorg/nix-software-center https://github.com/nix-gui/nix-gui

These might be interesting for you :)

I went from not having written a single line of Nix to a full fledged repo with multiple mac’s, multiple NixOS hosts with impermanence, the whole lot in a couple months with remarkable speed with claude code.

Mind you I had decades of infra and dev experience behind me as well as experience with claude code and LLMs in general.

I think that in the right experienced hands they’re a great tool for becoming up to speed and productive.

https://flox.dev/blog/the-flox-catalog-now-contains-nvidia-c...

So they can use the host driver in nix based services with Jetson

My biggest concern here is not feature parity with the latest in AI; but in usability, or maybe irrelevance (what happened to thin clients?). My hope is that what stopped thin client adoption was just paying cloud providers forever, and that the average consumer that has a home computer can use that computer as a NAS to actually be their own iCloud / OneDrive, with the ability to deploy their 'home machine' on any laptop.

I thought the big barrier was the custom kernel they distribute. It was a pain to use the old Jetsons before Nvidia finally enabled modern c group support for containerization with docker. Perhaps building a kennel for their ended platforms is simpler now?

What have your successes in using LLMs to write Nix code looked like?

AI makes this even easier, but you can usually find a similar package on nixpkgs and just modify it to suit the needs of that particular application.

I'll say this. Recently I reinstalled arch to see if I liked the freedom of it more. Within a week I reinstalled NixOS (which thanks to version control meant I was able to reinitialize it to be back in the exact state it was in beforehand).

You can setup an FHS environment, this is often the strategy used when packaging closed-source binary packages. An example in nixpkgs is steam-run [0], I also used a similar approach to package Xilinx ISE [1] in a flake.

[0] - https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/by...

[1] - https://github.com/benpye/nix-fpga-tools

Obviously the ideal is built from source. This has a lot of benefits. It allows you to overlay the package very easily - modify its source to be a fork, change compile options, etc. It allows you to expose its dependencies. Stuff like that.

More packages than any other package manager you're likely to encounter.

If something isn't packaged for nix, it's often simple to package yourself. Even when this isn't simple, it's often simple to use nix to bring the build dependencies into your environment and then follow the usual (non-nix) build instructions.

I'm a lowly self-taught hobbyist who works in an entirely unrelated industry. If I can do it, you can.