one benefit that doesn't get much lipservice in elevator pitches for nix, here included, is the experience of packaging. i think the average line count in my personal collection of obscure software is ~30, and that's including license/homepage metadata and other such junk -- it can make even bsd portfiles look tubby by comparison.
It's a running joke now. There hasn't been a "100 seconds" video shorter than 2 minutes in a long time. Most are around 3min.
Agreed on the packaging experience for nix. We've been talking about that for a while also on the Flox side when we're working with folks.
Docker has dockerfile and all but even in 2024 I still have to compile and build stuff inside docker and then run 'docker commit' because building package with Nvidia gpu checking during 'docker build' usually fail for me.
And maybe something free me from the curse of distro. Previously I tried to run omniverse with isaac lab in my pc. Fedora, ubuntu 24.04 all failed. Only ubuntu 22.04 works. Distrobox actually didn't solve that case for me. And Omniverse docker image from nvidia doesn't support GUI. So I have to reinstall ubuntu 22.04 to use it. But currently the gnome is glitching with ubuntu 22.04 and I have to alt+f2 and type r to reset it frequently. I am just too tired to do another reset so I am here venting and looking for something more flexible.
I'll look into nix.dev.
If you are trying to configure your system using NixOS, the available options are very well documented so I personally rarely get into trouble.
Packaging an application however can be very difficult.
I've tried and failed twice. I think I irreparably messed up my macOS installation with tons of crap by trying.
You might be too deeply scarred to come close to it, but we just wrote a blog post about deploying NixOS servers without installing nix locally or provisioning work here that feels relevant: https://garnix.io/blog/hosting-nixos
" You may quickly encounter Nix language expressions that look very complicated. As with any programming language, the required amount of Nix language code closely matches the complexity of the problem it is supposed to solve, and reflects how well the problem – and its solution – is understood. Building software is a complex undertaking, and Nix both exposes and allows managing this complexity with the Nix language. " https://nix.dev/tutorials/nix-language.html
My read of this is any other build system has random elements that are usually fine but sometimes cause issues. There are no random elements in a Nix expression.
i.e. Yarn has a lockfile, but does not guarantee the system underlying the Yarn process is "locked." Nix does this down to the fundamental Linux/Mac libraries.
The upside is this complex configuration is a one-time cost for your project. Using a project configured with Nix can be simple. For instance, a Nix Flake can be set up for your project which defines your project workflow commands in the shell. These commands are completely portable.
Nix is not a virtual machine. But it does guarantee the command will run the same way on equivalent systems (unless it does something that goes outside the Nix boundary).
