291–300 of 344 posts
Earlier quoted context omitted.
The hours long build system appears to be attributed to Nix. Is Nix really that slow?
Dependencies can take awhile if you can’t used cached versions of the binaries. Building some Haskell tooling from scratch took ~3 hours on my MBP.
Earlier quoted context omitted.
I've had the (dis)pleasure of working with several projects that have been built by developers that have religion around Nix. These projects were contract work where the client paid a significant amount of money, and the final product was really poor quality. One of them is a financial application that has strict security requirements, so having a reproducible build system and some of the other qualities of Nix sound…
Woah, I didn't know there is an entire ecosystem of contract job and auditors for big projects. How do companies usually hire contract jobs (outsourced HR, upwork, Accenture)? And how do they hire auditors?
Earlier quoted context omitted.
Yes that's true. But some things remain difficult, for example installing the latest version of CUDA. https://discourse.nixos.org/t/cuda-setup-on-nixos/1118/9
Funny, I was able to install it (for use with pytorch) just a few days ago without a hitch.
Earlier quoted context omitted.
It's necessary to hardcode paths in order to ensure that the exact version of a dependency is linked into the executable. Without this mechanism, nix packages would not be reproducible and self-contained. Also, the path isn't really hardcoded. You can use a custom path, but that means you can't use binary caches.
I'm sure there are reasons for it, but it still sucks. It ought to be possible to use binary caches and still swap out the path. (Modifying a string in an ELF executable isn't that hard.)
Earlier quoted context omitted.
I do have to commend Docker for providing and managing an agreed upon VM for non-Linux users to host all their containers. It's the "killer-feature" that has made it as successful as it is. But underneath it requires a VM (libcontainer,LXC,virtualbox,hyperkit,etc) on non-Linux machines. This helps developers work together and quickly get small projects up and running. I'd contend that after a while, a mess of contain…
Have you checked out the official container system in NixOS?
Earlier quoted context omitted.
I mean, if you count the compiler/interpreter (which nix does), realistically that's a bare minimum of two.
Nix comes with its own glibc, so that's 3, although I guess while it is not the default you could compile statically.
Earlier quoted context omitted.
You do not understand correctly. Nix users use binary caches[0] instead of building everything from source. You can use the binary cache provided by NixOS, or Cachix[1], or something you set up and host yourself, or all of the above. [0]: https://nixos.wiki/wiki/Binary_Cache [1]: https://cachix.org/
Then why would a build take so long as GP describes?
Earlier quoted context omitted.
Considering that “difficult to audit” overlaps with: difficult to understand, difficult to deploy, difficult to onboard, and a bunch of other things that are also very important to non-auditors, that seems like an entirely reasonable and informative complaint. If you hire a financial auditor and their report was basically an nicer version of “‘books‘ were written in pencil on napkins, many food stained, some illegibl…
"books written in pencil on napkins" is analogous to how most web application projects are organised today. Nix would be the formalisation of this.
Or phrased differently: maybe the problem here wasn't nix, but the way developers chose their dependecies
Earlier quoted context omitted.
Nix guarantees reproducibility, which means anything can be rebuilt from scratch, but that's a very abnormal use case. If it didn't work out of the box, it's a problem with the package scripts (the "derivations"). That said, all of our software tends to bottom out in a bunch of shitty C libraries that are all delicately cobbled together with autotools and cmake, so anything that aspires to reproduce these things is g…
This comment is really, really confusing. If it builds once Nix, it will build again with Nix... If you can find a derivation that builds on one machine and not on the other there's usually a fundamental difference - either in CPU arch, your nixpkgs config differs (overlays), etc. Or I guess you could write a build script that non-deterministic ally fails, but that has nothing to do with Nix's maturity. Nix ensures t…
That's the aspiration, but it doesn't always pan out. The rate at which you run into problems depends a lot on the packages you use, how much attention is given to them, and how hard it is to reproducibly package them. I've noticed in particular that the Python ecosystem is really fragile.
> Do you have a specific example in mind that is less hand-wavy?
A specific example that comes to mind was the psycopg2 Python package, which would build on some developers' machines but not on others. This sort of thing happens all the time, usually on macOS, and usually with C packages (sadly, so much of the Python ecosystem is built on C and its shoddy build tooling). I've also found quite a few packages in nixpkgs that simply don't build on macOS, but which presumably build on Linux; however, I forget which ones specifically.