Unfortunately, Nix breaks my CUDA/NVidia support.
NixOS? I've had a good experience with Nvidia on NixOS. But my experience is a laptop w/optimus.
The problem is that I need guaranteed future support.
Nix solves the package manager ejection problem
41–50 of 50 posts
Re: Nix solves the package manager ejection problem
#42That works for the kernel. But if you have to patch, say, glibc, under Nix doesn't that mean you can no longer use precompiled binaries, and have to recompile every single package that uses libc, from source? Sure, it still works. And in the off-chance that you need to make a patch that changes the ABI, recompiling the world is exactly what you want. But usually you don't need to change the ABI (at least not in a bac…
Another way to address this concern. Nix allows you to specify what you want to do in this case. You can either:
1) Decide you want that patch to be applied to everything, resulting in recompiling the world.
2) Apply the patch for only the specific project you are working on/testing/etc. Thus only that thing is recompiled.
3) You can cheat in various ways if your project truly requires being updated by only changing the glibc and no recompilation is feasible. Some options: the way OpenGL and graphics is currently done in NixOS, nix-rewrite (https://github.com/timjrd/nixrewrite), and LD_PRELOAD. Breaking the abstraction in this way may have practical benefits, but you also lose the reproducibility and excellent bookkeeping of all the details that Nix provides.
4) specify a container/project/VM that uses your patched glibc, so only those things are rebuilt that matter in your use-case.
The crux of the matter is that we need to be more precise in the names of things. Most of the time "glibc" refers to whatever is on your system on the same path. Nix has taken the other extreme where you can't just say "glibc", you really mean "this particular source, compiled with this particular set of flags and build script". If you want something more powerful\and between those extremes, there is some work currently on a system called Nomia that attempts to provide a far richer naming semantics, but it is still experimental. https://github.com/scarf-sh/nomia It would allow something like "glibc means anything ABI compatible with this particular thing, plus some other requirements...."
Re: Nix solves the package manager ejection problem
#43Ah I didn't know about boot.kernelPatches. This is so much easier than my complicated nixpkgs kernel override.
Re: Nix solves the package manager ejection problem
#44Read the NPM doc but I still don't understand what "ejection" is. What are we ejecting? Can someone explain this please?
> What are we ejecting? Ourselves, it seems. A Javascript framework is like a jet, and we are the human payload. You can stay in the jet, zooming over the constantly changing landscape. But if you get tired of this zooming around (or if you get scared of hitting a mountain), then you can activate the ejection seat ( https://en.wikipedia.org/wiki/Ejection_seat ). Of course, now you're a mile high without a plane, but…
I tried this and landed in a field of debris from the jet.
Re: Nix solves the package manager ejection problem
#45Ah I didn't know about boot.kernelPatches. This is so much easier than my complicated nixpkgs kernel override.
this is a very Nixian kind of oversight and it makes me laugh
I don't think I've ever actually used boot.kernelPatches, either, and I could see myself overriding the whole kernel package instead
Re: Nix solves the package manager ejection problem
#46I think the issues with traditional packages all boil down to the fact that packages are not files . Packages are some transformed instance of some code, operating over a computer's resources in some way. Sure, eventually you get down to the fundamental file abstraction, but it can take a bit: all the variations of building from a single code base. What I like about Nix is that it stops representing packages as files…
You might be interested in Nomia, a project recently started by a veteran Nix hacker at some startup. The idea is to generalize the store layer from Nix's model (package management) to a more universal one (resource management)
https://discourse.nixos.org/t/announcing-nomia-a-general-res...
Re: Nix solves the package manager ejection problem
#47How do NixOS users typically manage software that is not a Nix package, like a source code tarball where you would traditionally run configure && make && make install?
You write some Nix code to download said tarball and build it as you said. In fact, the ever present `mkDerivation` often Just Works for autotools and cmake projects.
You can also specify paths to local sources, of course! Instead of src = fetchgit... or whatever, you can just write
src = ./some-source-dir;
src = ./.;
Re: Nix solves the package manager ejection problem
#48That works for the kernel. But if you have to patch, say, glibc, under Nix doesn't that mean you can no longer use precompiled binaries, and have to recompile every single package that uses libc, from source? Sure, it still works. And in the off-chance that you need to make a patch that changes the ABI, recompiling the world is exactly what you want. But usually you don't need to change the ABI (at least not in a bac…
Nix has a facility for patching libraries without recompiling the world (the intended use case was for novel zero-days where waiting for hydra to rebuild the world was unacceptable). All I know about it is that I've heard it exists though.
Guix has this, and they call it grafts. I'm not aware of Nix having anything similar just yet
Re: Nix solves the package manager ejection problem
#49Earlier quoted context omitted.
I believe the confusing bit is that it's not an NPM thing, it's a create-react-app thing. create-react-app is a helper tool for, as the name says, creating React applications and doing a bunch of things out of the box. Occasionally you reach the point where you need to do something more complex than create-react-app can handle for you. In that case, you run the "eject" script in the generated app (using "npm run" as…
> I don't think it's a perfect analogy, but I see what the author is getting at - you need to break the abstraction of some packaging tool, but you want the functionality it provided to still work as well as possible. You got it. I don't think it's the best analogy either but it is pithy and works if you squint. The essence is: 1. create-react-app is a monolithic transformation of a bunch of disparate tools into a ma…
The Open Build Service and its version control tool, osc, offer some ability to fork a package from an upstream repo and still track upstream changes. It's not as elegant or convenient as Nix, but it is pretty cool. OBS supports packages for a ton of distros. It's essentially patch based, but targeting different distros (of the same package type) and different architectures can sometimes be without changing the source packages at all.
It might be fun to compare their approaches to solving this ejection problem. Nix's is much nicer to use and requires basically no infrastructure, of course.