Is it correct, that system modifying tools, one is used to from other Linux operating systems won’t just work on NixOS?
For example, GRUB Customizer.
1 Like
If they modify config files which nixos expects to control, they won’t work. I’m not familiar with GRUB customizer, but just by the name, I’d bet it won’t work, since nixos expects full control of grub.
So, how can one adjust GRUB configuration as easily and thoroughly as with GRUB Customizer in NixOS?
NixOS documentation is extremely scarce.
Try a nixos option search or use man configuration.nix. There are many options to control grub, including options to add arbitrary text to the grub config.
1 Like
yes, most of them won’t just work. In addition to that most files are read only, the directory structure of NixOS is wastly different.
Isn’t that pretty much what is contained in the online documentation?
I’ve read major parts of the manuals several times over the years and it all seems thorough, until I boot up NixOS and notice how nothing is really explained, at all. Things are just mentioned, but not explained for people who try to get into NixOS. (Trying to get into it since 3+ years, but it does not work.)
Not bad, though I would wish for complete examples, instead of just reference like minimal “examples”.
I assumed so, though I was never sure about it. Thanks for the confirmation.
I mean, yes, if you want to configure GRUB manually, you can do it this way anywhere, that’s a given. But there is apparently no way of letting it be handled, through GRUB Customizer, for example. You have to do everything manually.
So, this isn’t a real “solution” for someone who uses GRUB Customizer, for example.
All that said, I am not trying to use GRUB Customizer, I just used it as an exemplary system modifying tool, which is very popular, to get the point of my question across.
So, the conclusion is, if something system modifying wants to work on NixOS, it must include specific NixOS support, which requires extra effort by the maintainer of that system modifying tool, correct?
This is man page style. If you are searching for a more complete manual take a look at NixOS 24.05 manual | Nix & NixOS
not really “support”. You most likely want to change the settings via nixos settings and the tool could just dump the file.
Yes, I mean I read the online documentation. For example, the one you linked (unstable), but also previous versions.
Doesn’t that necessarily require extra user interaction? Like, implementing the dumped configuration file into a configuration.nix, by hand.
To expand on that, if you, for example, don’t take grub customizer, which probably writes to some hairy paths and is therefore a bad example for this kind of thing, but e.g. emacs’ theme creation, it will produce some theme.el file.
Instead of letting emacs just write this to your ~/.emacs and keep it there, you can run the config generator once, and then take the produced file and feed it to NixOS to install instead (note you can use builtins.readFile to read files, so you don’t need to manually turn them into a string or anything, or you can just get nix to symlink paths directly).
The “support” required is just that the configuration generator must create some kind of file for this configuration. Which given we’re in unix land is pretty much a given. Everything else is just the user understanding the tools they use well enough to know where the configuration ended up, and how to copy it around - something that configuration generators can try to support more (by adding a note in the UI of where the configuration ended up, for example).
This is the best that can be done, though; Configuration generators are inherently impure, and cannot be captured by any declarative model of your system configuration. They need to produce some output that can be taken into the model. If you’d rather have random paths lying around and generate them every time you set up a system, NixOS is probably not the right choice.
2 Likes
Instead of focusing on the perceived solution to a given problem, why don’t you tell us exactly what it is you are trying to achieve and we can see how we can then best help you?
Wasn’t an XY Problem. I was generally interested in the topic.
Sure, but without a lot more details the only answer is going to be “it depends”.
Since then, I gathered more experience with NixOS and my answer to my question is:
No, they won’t just work. Nothing just works.
NixOS pretty much always needs a special build of something.
If you can’t run a generic binary just like that, then it’s not possible to run a tool like the one given as an example, without modification, re-compilation or whatever else needs to be done.
Except, there is a way for running a generic executable without modification on NixOS, that I am not aware of. So far, I have found none that would work.
No, they won’t just work. Nothing just works.
Most binaries that you pull off the internet will look for shared libraries in places where we don’t have any on NixOS. That has nothing to do with the type of tool (system or otherwise) that you are trying to run.
So if the question is “Can I directly run an arbitrary downloaded binary on NixOS”, then the answer is very much “no”.
We have 2 options to make it run:
- if we can compile the thing from source, we are in the vast majority of cases able to use the resulting binary on NixOS
- if it’s a binary-only distribution, we can use
patchelfto make it look for libraries in the right places, which is typically also not a problem.
To elaborate on item 2, we also have autoPatchelfHook, which automatically handles the patchelf invocation in most cases.
Something low level like GRUB Customizer is probably not going to work well (I don’t know that particular piece of software but I can guess what it does from the name) considering it would be fighting with the NixOS boot loader module over control of GRUB.
3 Likes
Flatpaks do 
NixOS modules also by definition “just work”, you might just not have found the ones you need yet.
For $randombinary there’s also always buildFHSUserEnv. Or if you want to be a heretic GitHub - Mic92/nix-ld: Run unpatched dynamic binaries on NixOS
But I persist that if your preferred mode of operation is imperative configuration with no control beyond what the filesystem gives you, NixOS misses the point for you.
If you are going to experiment, though, maybe at least try having an open mind, and maybe not directly running towards the things that are clearly unsupported. Did you even look at the grub configuration module? It’s pretty good.
If you really can’t bear the lack of perfect interoperability with traditional systems and familiar tools, but still want to try the declarative configuration thing to an extent, maybe you’d prefer running nix on ubuntu with home-manager or such?
I’m a bit unreasonable, you do have legitimate issues here, it’s unfortunate that your favorite tools don’t just work out of the box. But understand that it feels like you’re just complaining without even telling us enough to point you in the right direction. There are many ways to solve your problems, some of which might suit your tastes better than others.
1 Like
Not an option for me. They create a 100 problems and solve only a couple.
Yes. Documentation is one of the biggest & most glaring issues with NixOS. When just glancing at the manuals & official resources, it seems like plenty is there, but compared to the vast amount of configuration that needs to be done in NixOS, the actual amount of documentation is really minuscule. It barely touches the surface on most features.
Especially the recipes are pretty terse, too specific to a certain scenario & very reduced.
I really prefer to follow best practices. I do not like dirty workarounds.
Where is that mentioned in the NixOS documentation?
If that would be my goal, I wouldn’t have set up NixOS. I do everything by configuration. But that does not mean, I’m going to take the time to write a huge module for every single thing that exists out there. This would take loads more time than just reproducing an imperatively built generic operating system.
Not sure, what you mean. Also, in case you missed it, I don’t want to use Grub Customizer. It was just an example. I do my GRUB configuration manually.
When it comes to other things, there is sometimes no way to have an “open mind”, if there is only a single solution to a problem, like for example, when picking a CNI for a Kubernetes setup…
Again, not sure what you are talking about. I don’t care about this. It’s just that, when I need tool A and it doesn’t work on NixOS, then I have a problem. It’s not related to “perfect interoperability with traditional systems”. It’s about having something work. I don’t care if the thing needs a thousand symlinks to work on NixOS. I just want it to work on NixOS the Nix way.
Not unreasonable. You just create the impression that you feel offended about me having a problem on NixOS, although I wasn’t attacking anything or anyone, but just curious as to how things work on NixOS.
You repeatedly implied in your previous statements, that I am so attached to “traditional” systems & would like to have “perfect interoperability”, which is utterly wrong. I did never imply, that I expect this.
If I would’ve expected this, I wouldn’t even have touched NixOS.
Obviously, I touched it, because I want to use NixOS the Nix way.
Please, do not interpret stuff into my statements, which isn’t there.
It’s not about “my favourite tools”. You make it seem like, I am willing to install an innovative OS like this one, but not willing to accommodate to how it works. The whole point of me using this OS is that I use its best practices.
However, when a tool, that is absolutely necessary does not work, then no “open mind” helps.
It feels like that to you. Your feeling is wrong.
As you apparently have missed, I must emphasize, that I do not use Grub Customizer. I was just curious about the topic.
I have already said that previously.
You put a lot of words in my mouth without even reading what I actually said. That is unproductive behaviour.
Fair enough, my bad. That’s why I said I’m being unreasonable, I did feel offended because statements like
Belittle a lot of work people put into things. Clearly a lot of things do work, you just take them for granted. Probably because you’re frustrated, I’ve said things to that effect before myself.
But enough of that, i really do apologize for my reply. You wouldn’t still be here if you weren’t legitimately trying.
You are right about the documentation. The problem is that NixOS is just very different. With experience, things can work well, but most off-the-shelf things like your kubernetes cni (just noticed that topic) simply aren’t designed with this ecosystem in mind. Someone needs to do the dirty work, and if nobody else has tried before that’s you.
Couple that with a small userbase and you get the resulting minimal documentation and rough spin up experience (which is a kind of chicken-and-egg problem). This is a problem with all tech that hasn’t reached mainstream adoption, mind you. Compare it to people trying to run Microsoft Word through wine.
While I didn’t intend to suggest you’re clinging to traditional distros, there are two ways through this:
- Spend a lot of time learning and contribute the things you need so the next person only needs to complain about your documentation
- Choose a different CNI that someone else has done before, and fix their documentation if you can figure it out
The latter means you need to take a different approach to what you wanted. That’s what I mean by “open mind”, and you’re right, not always an option.
This isn’t awesome. But someone needs to do the work, and for as long as the CNI authors aren’t interested in writing NixOS modules this will have to be some poor soul downstream.
That’s ultimately probably the best solution to all these problems, become as mainstream as, say, ubuntu. Personally I hope this might happen if I help enough people out here, and being mean to them is probably not very productive to that goal, so again, sorry 
So, trying to help with actual concrete problems, I think I can answer two questions:
In the nixpkgs manual.
If I need documentation on anything for the nix ecosystem, this is my algorithm:
- Is this related to NixOS options? Some kind of system service I want to run and set some settings for?
- NixOS Search
- Not detailed enough? Check if the NixOS manual is more helpful.
- If not, search the nixpkgs source and read it. This gets easier with experience, enough so that often I probably fail to see why it’s hard for others nowadays.
- Do I need to write a package, build some software, figure out how to make something exotic run on NixOS, through nix?
- NixOS Search, just in case
- Nixpkgs 23.11 manual | Nix & NixOS otherwise. This is the best piece of documentation the ecosystem has, for a lot of things. Language-specific stuff, detailed explanations of the build process, you name it. The quality varies, but that’s normal.
- The nix pills are very helpful too
- Still stuck? Read source code for similar packages. Particularly helpful for language specific things, the helpers for those are rarely documented at all.
- Search through nixpkgs PRs, discourse, google. NixOS may have relatively few users, but they’re busy. I’ve rarely come across anything nobody else has ever tried.
- Is nix complaining at me? Some configuration I need to figure out? Do I need to double check how flakes work?
- Introduction - Nix Reference Manual
- This is the highest quality manual. It has incredibly useful information on nix, but only on nix. Very unhelpful for actually using nix to do anything specific. But it’s nice when I’m stuck on something like string escape syntax.
- Do I want a slightly higher level tutorial for something specific?
- https://nix.dev/
- Google (hoping for @solene or xe’s blog posts)
- This discourse!
And that’s pretty much it. I figure you’ve been doing this, but those are the most useful references I’ve found on the ecosystem. I think it helps pointing people at where to find what.
Is this perfect? Far from, I think the manuals need a facelift (the nix one looks much better, the other two are dumping grounds with no structure and hard to search). There needs to be a better index. Why are there three manuals anyway, and the distinction between nix/os/pkgs really needs to be communicated better. There need to be more tutorials. Beginner-intermediate docs, and tooling-specific docs (which you’re looking for) are practically absent. This will take time and effort to improve. It’s going to though, there are meetings about it nowadays!
Take a second look! That workaround is far less dirty than you’d think. It’s hardly a workaround, frankly. It’s a well-designed solution to the problem that everybody is hardcoding their LD path.
Typically it is preferred to just compile things from scratch, so that the hard-coded paths point to the right place and nix can do its dependency management. But if you’re choosing to use external binaries, this is probably as neat as it gets. It’s hardly worse than patchelf, at any rate.
If there are other concrete topics, and I’ve not completely put you off, this discourse is an incredibly nice place for the most part. It helps to come with concrete code examples and questions, but people will generally help with anything they have experience with.
7 Likes
@Akito Leaving the insightful discussion above as it is, here’s one addition (related to the FHSUserEnv mentioned above) that has given me a pretty good out-of the box experience for “generic” binaries: steam-run.
I was suprised how well it works, as an example the (complex) “game” X-Plane just works with it. So this is my go-to first method if I really need to run some odd binary that’s not in nixpkgs.
Usually though (as mentioned above), if it’s actually system related, really for most things there’s an idiomatic nix(os) way of doing things, which (once you’re actually aware and/or get used to it) is often “better” (IMHO) than the “traditional” way.
1 Like