[sjburt]

It seems like every article about nix goes on and on about DLL hell. I've been using Debian/Ubuntu for 15+ years and never really experienced dependency hell. I guess maybe this is thanks to hard work by Debian maintainers and rarely needing to run a bleeding edge library, but also, why do we need to run bleeding edge versions of everything and then invent an incredibly complicated scheme to keep multiple copies of each library, most of which are completely compatible with each other?

And then when there's a security problem, who goes and checks that every version of every dependency of every application has actually been patched and updated? Why would I want to roll a system back to an (definitely insecure) state of a few months ago?

What problem does Nix solve that SO numbers (properly used) doesn't?

I have many of the same questions about Snap and even Docker.

[klodolph]

I’m using Nix for development and generally I agree.

The first catch is that I want to be able to update my system on a regular basis, and keep using exactly the same dependencies in my project after an update. Maybe I’m in the middle of working on a change.

The second catch is that sometimes my development environment is really weird, and the packages I need aren’t in Debian. At least, not the versions I want. Nix can handle cross-compilation environments and you can use it for embedded development. You stick your entire development toolchain (arm-none-eabi-gcc, whatever) inside your development environment.

> Why would I want to roll a system back to an (definitely insecure) state of a few months ago?

Periodically, I want to update everything in my development environment to the latest version of everything. Sometimes, something will break. Maybe a new version of GCC reveals previously undiscovered bugs in my code. Maybe a function gets removed from a library (I’ve seen it happen). In Nix, it’s pretty easy to pin my entire development environment to an old version, while I’m still updating the rest of my system. I can also get the same environment on either Linux or macOS with relatively minimal hassle (with the note that I’ve run into several packages that just don’t run on macOS, which required me to make “fixed” versions).

Also keep in mind when I say “Nix”, I’m talking about nixpkgs. I’m not using NixOS and I just don’t care about NixOS.

Nix also has its pain points. I think of it as being like a coarse-grained Bazel with a ton of packages.

[nyarlathotep_]

My Nix experience is limited, so forgive my ignorance here, but is it possible to create a development environment for an "older" project as well?

Say I need some 3.20 version of CMake and gcc 9/whatever or something--i assume such a thing is possible, but I've not seen a simple way to "pin versions" of things the way you would in say a language's package manager.

[klodolph]

My Nix experience is pretty limited, too. Nix is not great at pinning to specific versions.

If your older project was made in Nix, it’s no problem. You just check out the old copy of the project and you automatically get the old copy of the dependencies.

If your old project needs some specific major version of GCC, going back to like 4.8, there are specific packages in Nix. You just add “gcc48” to your dependencies and you get GCC 4.8. You still get newer versions of e.g. binutils.

If your old project needs a specific version of CMake, I know two ways to get that, but they’re a little ugly.

First method is to import an old <nixpkgs> containing the right version of CMake, and then import that into your environment. You search through Git history of the nixpkgs repository until you find one with the correct version. Yes, this sounds awful. It’s not that bad. I’m not sure how to do this with flakes.

You can also copy the CMake derivation into your project and modify it to compile & build the version of CMake you like. This is the approach I would normally use, most of the time.

There may be easier ways to do this. I’m not sure.

[nyarlathotep_]

Thanks, that clears up my understanding. I'd suspected it was something along those lines.

[lexlash]

https://www.nixhub.io/ - and I’ve seen others - make the searching easy. It’s odd to me that I rely so much on web based tools (like search.nixos.org!) to look up nixpkgs details for my commandline but eh.

For a flake, you’d specify an input of that specific revision of nixpkgs and then refer to your CMake dependency with respect to that input. You may end up with - by design - a lot of duplicated dependencies, but it’d work.

https://blog.mplanchard.com/posts/installing-a-specific-vers... is a nice writeup (not mine) with examples of a few different ways to do this in flakes and not-flakes.

[klodolph]

Yeah, relying on `search.nixos.org` is a little weird. Package discovery overall is a little weird… I think I usually do it through nix repl.

[HideousKojima]

I run into DLL hell any time I try to install some software that isn't in some sort of package repository or other happy path. Most recent example I can think of was about a year ago when I helped my father-in-law install Klipper on an RPi4 so that he could do input shaping on his 3d prints. All of the guides and documentation seemed to assume that you were using a specific version of Linux on the RPi, and if you weren't (like my FIL) then welcome to dependency hell. Took several hours of pulling my hair out to resolve them all, for a non-developer it would have been impossible.

[michaelmrose]

So the installation story for klipper is hilariously bad. Its a shell script that apt installs and pip installs things as root. It is the very definition of non-portable.

The distribution story for Python apps in general is fairly bad and the developer really takes it to the next level.

This isn't DLL hell as a function of leaving the happy path its DLL hell as a function of burning the happy path whilst dancing naked on the ashes of the greenery that once was the happy path.

See Calibre for willful disobedience vs instead of insanity. It eshews system libraries and uses a shell script to install but it dumps everything including Python libs in a directory.

[HideousKojima]

Well it's slightly comforting to know that my experience with Klipper wasn't unique, at least. I have an Ender 3 but don't really do anything beyond the basics with it so I hadn't heard of Klipper prior.

[lexlash]

You don't need to run bleeding edge versions unless you feel like it; there's a stable release with rolling security patches every 6 months (current is 24.05, next will be 24.11).

You don't need to keep multiple copies of each library - but you _can_ when you find out that an update broke something you care about while still updating everything else on your system. You aren't rolling back your entire system state, just the...light-cone of the one tool that has issues.

The problem with SO numbers is that your Python/Ruby/Java/NodeJS packaging and tooling doesn't respect that at all. If you can satisfy all of your dependencies using the Debian-maintained repositories great! When you can't, Nix provides a harm-reduction framework.

Nix also makes certain hard things trivial - like duplicating the exact system state that someone else used to build a thing some months/years ago, or undoing the equivalent of a `dist-upgrade` gone awry.

> And then when there's a security problem, who goes and checks that every version of every dependency of every application has actually been patched and updated?

The nixpkgs maintainers, same as the Debian maintainers. Repology's down right now but nixpkgs seems to do quite well on a CVE level.

> Why would I want to roll a system back to an (definitely insecure) state of a few months ago?

Insecure is sometimes preferable to down. Being able to inspect an older/insecure state with new/secure tools is neat.

> I have many of the same questions about Snap and even Docker.

Snap and Docker solve similar problems that most people don't have. Same with k8s. You might just not have these problems - I have a screwdriver on my desk that's specifically for opening up GameCube consoles (so it's longer than the one I use to open up N64 cartridges, even though it's the same shape); unless you have that specific need, it'd be completely pointless in your toolbox and cause you trouble every time you tried to use it.

[TacticalCoder]

> I've been using Debian/Ubuntu for 15+ years and never really experienced dependency hell.

Debian (or derivatives) too here and once in a very rare while I encounter some dependency hell.

IIRC the last problematic one was trying to add JPEG XL support to Emacs. Emacs uses ImageMagick under the hood to display pictures (for example from image-dired) if I'm not mistaken. But the version of ImageMagick shipped with the latest Debian stable (Bookworm) doesn't support JPEG XL yet.

Something like that.

It does happen but I do agree that it's highly uncommon.

> Why would I want to roll a system back to an (definitely insecure) state of a few months ago?

A just question!