opened 01:11PM - 04 Apr 24 UTC
6.topic: hardware
5. scope: tracking
## Issue description
We have https://github.com/NixOS/nixos-hardware/ which i…s a repo where everyone dumps pieces of configurations they find to make their computer do better in their view.
In the past, that repo was merged _inside_ nixpkgs, then reverted, in the context of https://github.com/NixOS/nixpkgs/pull/91160.
Furthermore, `nixos-generate-config` is not always aware of potential hardware profiles to apply, see https://github.com/NixOS/nixos-hardware/issues/49 for ideas, which impedes the discoverability sometimes.
We discussed on Matrix at https://matrix.to/#/!kjdutkOsheZdjqYmqp:nixos.org/$2Tu2fydLwl5XTeuHQxOrqGa0TAn0F6ft4e6fdylQaAU?via=lossy.network&via=matrix.org&via=nixos.dev "what if we merged the repo again" and we came to the conclusion very quickly this was not an option.
Here's a summary of the discussion:
- Kernel maintainers in nixpkgs are not super comfortable with forked kernels _inside_ of nixpkgs: @alyssais, @K900 and I prefer a hard rule "no forked kernel" even if it had permitted hardware enablement.
- A code owner of `hardware/`, even multiples to ensure a high quality level, on par with Jovian or Asahi
- For something to be present in `hardware/`, the intention of their vendor/author is that it should be upstreamed as soon as possible
- Explicit traces of good maintenance from the midstream (Asahi/Collabora/Jovian) must be apparent
- We also mentioned that CI in nixos-hardware is lacking and a better separation of packages/modules would help
- @alyssais is against ideally any forked project for hardware enablement
- The previous points do not cover things like just tweaking a configuration with existing packages even if the configuration could be upstreamed and thus no tweak would be required
- Open questions are also how to reconcile diverging outcomes and whether we should have NixOS module code to handle things like "I want to optimize my HW for power", "I want to optimize my HW for performance", etc.
#### Raito's proposal
My proposal would be to formalize better a policy in Nixpkgs about the hardware enablement here, take ownership of that repo and start to look if some stuff makes sense to move over from nixos-hardware to here.
In parallel, we can help the nixos-hardware project to get CI and help with the structure.
Finally, I'd like to try to close the "auto generate" profile issue with `nixos-generate-config`, during the conversation: https://git.numtide.com/numtide/nixos-generate-facts was mentioned.
cc @samueldr @zimbatm