Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

We used Nix to vastly simplify the build process of Simula: https://github.com/SimulaVR/Simula

Simula is a bleeding edge VR Desktop project for Linux; virtually all of its dependencies are highly novel and require building from source for almost any distro. Nix allowed us to reduce the effort to building our project from 1hr of sifting through build documentation to a single build command.

Nix's only issue is that it so far can't handle OpenGL dependencies very well. I'm not sure if this is something in principle it cannot handle, or if it just hasn't been done yet. I'm praying it's the latter.



So, OpenGL is a bit of a weird case.

Hardware is the one thing that actually varies between systems no matter how declarative your configuration is - this is normally not a problem, since the kernel abstracts it away.

The problem with OpenGL, then, is that every graphics driver provides its own set of OpenGL libraries that is subtly different from all the others. This means that applications need to be built against a specific set of OpenGL libraries from a specific graphics driver, and the kernel is of no help here.

That's fundamentally where the OpenGL issues come from; Nix packages typically expect the libraries to be semi-statefully provided in a `/run` directory. This gets especially hairy when targeting different distros.

EDIT: And because the package doesn't know what graphics drivers it'll be running against on non-NixOS, it can't automatically build against a copy of the correct drivers in nixpkgs either.


I agree that, given this description, it's a hard problem. But can Nix find a way to abstract away these difficulties?

There are also bugs. For example, non-NixOS users of Simula are forced to run this script: https://github.com/SimulaVR/Simula/blob/master/swrast.sh

This is because a nix package expects to find a driver in `/run/opengl-driver`, which isn't always present if you're not running NixOS.


Does the Guix choice of a more expressive language for defining the packages help here?


No. I think both languages are equally expressive in the end (though one will be a bit uglier than the other). But the problem is probably less big in Guix because only a few graphics drivers are actually supported due to the fact that all the drivers needs to be Free and free of binary blobs.


> But the problem is probably less big in Guix because only a few graphics drivers are actually supported due to the fact that all the drivers needs to be Free and free of binary blobs.

This is a property of Linux libre, not of Guix per se.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: