devenv dedica unos 70 ms en cada prompt de shell a ejecutar un hook que solo detecta el proyecto, consulta la base de confianza e imprime una ruta. Casi todo ese tiempo no es culpa de devenv, sino de nixpkgs: el cargador dinámico de glibc realiza cientos de llamadas openat() fallidas para localizar las bibliotecas compartidas que el binario necesita. En lugar de usar un /usr/lib global con ld.so.cache, Nix reparte cada paquete en su propia carpeta dentro de /nix/store y registra cada dependencia en el campo DT_RUNPATH del ELF, así que resolver N bibliotecas contra M directorios cuesta aproximadamente N×M intentos, casi todos erróneos, más las pruebas extra de los subdirectorios glibc-hwcaps. El artículo lo ilustra con dos casos medidos: el binario devenv realiza unas 486 aperturas fallidas y magick --version de ImageMagick llega a 1225.
El texto repasa los compromisos de las soluciones propuestas a lo largo de los años. Reescribir DT_NEEDED con rutas absolutas (como hacen shrinkwrap de Farid Zakaria, el PR #357 de patchelf y el enlace "bind" de Spack) elimina la búsqueda pero pierde la inyección de LD_LIBRARY_PATH para los drivers gráficos y la selección de libGL. Una granja de symlinks en DT_RUNPATH reduce el número de directorios a uno, pero requiere mantenimiento. Por último, una caché de notas ELF consulta directamente las rutas resueltas en una sola operación. Para devenv, los autores exploran la opción radical de eliminar el cargador dinámico enlazando todo el programa en un único binario estático, viable para utilidades pequeñas aunque inviable como solución general para nixpkgs. El problema de fondo se sigue en el issue NixOS/nixpkgs#481620.