[RFC 0070] Merge nixos-hardware in to nixpkgs (#70)

[Mic92]

We are currently having a separate repository to providing NixOS profiles for hardware specific extensions at nixos-hardware. This RFC proposes to merge this repository (4000 LOCs/350 commits) and add support for detecting hardware in nixos-generate-config.

Rendered

[nh2]

People just don’t know about nixos-hardware (because it’s not discoverable by grepping through nixpkgs)

Yes, I'm for making it part of nixpkgs, and mentioning this functionality right up in the NixOS manual in the installation section.

[Ericson2314]

Yes since day 1 nixos-hardware has been hampered by this: especially given that the hardware compatibility deals with versioning/interface violations---subtle variations in software and hardware that have a far more disastrous consequences than intended---I don't think it's feasible to evolve or version nixos and nixos-hardware separately. A means to synchronize everything (as a single repo provides) is absolutely required.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/rfc-on-merging-nixos-hardware-into-nixpkgs/7775/1

[lukegb]

Yes, please: this would make adopting nixos-module much easier. Some of the hardware I use already has modules in nixos-hardware, but since I didn't know about it I ended up reinventing the wheel myself at first.

[grahamc]

One problem with the built-in profiles is I find they're good for a while, and then usually I want to override them in some way, sometimes in ways which are difficult to do without copying their code in to my repo. Is there a style guide or best practice we could come up with which makes this easier for users?

[grahamc]

I wonder about validating that they at least evaluate coherently? Understandably we can't actually assert they're sensible.

[Profpatsch]

Evaluation and probably also build of the images.

[Profpatsch]

One problem with the built-in profiles is I find they're good for a while, and then usually I want to override them in some way, sometimes in ways which are difficult to do without copying their code in to my repo.

They would slowly evolve into more composable modules definitions, as with everything.

[grahamc]

I wonder if this would also be a good place to put expressions like NixOS on:

• Packet
• AWS
• Hetzner
• DigitalOcean
• Vultr
• Oracle Cloud

etc.?

[grahamc]

This turns out to be a bit of a loaded question, and I didn't mean for it to be. The reason it is a bit loaded is because to generate the expression for Packet, you have to print out a good bit of information unique to each machine. If moving the packet expr into nixos-hardware is appropriate, then it opens a question for me if the generation should be moved in to nixos-generate-config, too.

[Ericson2314]

@grahamc Yeah I don't think we need to figure out every architectural decision up front. Combing the repos to me is just signalling "we can't meaningfully version these separately". Exactly how to integrate the two I rather figure out via experiment----we don't even have to integrate anything at all, and we still get the benefits of synchronous development. (For the record, I do think integrating, somehow, with nixos-generate-config would be good.)

[Ericson2314]

Also

One problem with the built-in profiles is I find they're good for a while, and then usually I want to override them in some way, sometimes in ways which are difficult to do without copying their code in to my repo.

I have the same problem with nixos-generated-config, already. On one hand, "Thou shalt not commit generated code", on the other hand wantonly re-running nixos-generated-config terrifies me.

Many things we could try. The most complex might be stratifying included/generated code by both "how sure we are about the auto-detection we are making our decision on", and "how essential vs merely recommended is the config item is".

[edolstra]

I'm strongly opposed to this. nixos-hardware is intended as a low-barrier, little reviewed dumping ground for configurations. It should not be merged into nixpkgs which is already way too bloated, is a PR bottleneck, and therefore shouldn't accrue even more functions.

[Ma27]

I think that this is actually a good idea, also because it would be possible to generate even more hardware-specific configuration using nixos-generate-config with nixos-hardware expressions as mentioned in the RFC. @edolstra in case we don't accept this, what would you suggest to do for such a feature? (I'm not opposed to e.g. flakes, but from what I've seen it will take some time until those are stabilized).

is a PR bottleneck

Hmm, nixos-hardware doesn't seem to be a high-traffic repository, so I'm not even sure if we would notice an actual increase of PRs/issues.

should not be merged into nixpkgs which is already way too bloated

I know that I'll probably be known as the guy who initially hijacked the discussion from now on, but whenever I read something like this when people want to add e.g. a new feature, I wonder if we should reach at least some basic consensus about the direction nixpkgs should go in the future first.

[bbigras]

Would we have some QA for those hardware profiles?

For example, I made one profile for my laptop and I'm afraid to open a PR since I have no idea if I choose the right stuff. tlp vs thermald, sssd sutff like trim or not.

[Ericson2314]

little reviewed dumping ground for configurations.

I think it's fine to merge alone as-is, but yes we should treat it as initially dubious, and carefully vet afresh any bit that gets included in nixos-generate-config.

I wonder if we should reach at least some basic consensus about the direction nixpkgs should go in the future first.

Yes, we really need to have that discussion! (but in a dedicated thread not here.)

flakes

I don't think flakes will work because the vagaries of comparability are inherently fast moving. A kernel update can change an interface breaking an obscure out-of-tree driver at any time. The version nightmare is a social problem caused mainly by sloppy hardware manufactures that no technical solution like flakes can fix---I don't fault flakes at all.

[samueldr]

This may need considerations for backporting hardware profile changes to "current stable".

The separate repository is good because it generally means the same expressions are used for both stable and unstable branches of Nixpkgs.

Folding this into Nixpkgs, I'm calling it, will make nixos-hardware as good as stale every six months.

While it is useful for older hardware too, I think many users are using it to get around issues with fresh new hardware. If it's getting stale every six months on stable, then it's going to lose most of its attraction.

[samueldr]

Another issue, comes with NixOS on ARM which I wanted to write a not-RFC about for the nixos-hardware project.

Right now, NixOS on ARM are guidelines on a wiki, sometimes without actual expressions that are easy to use.

I was interested into folding in SBC expressions into NixOS hardware.

That in itself is not an issue. It's only a couple options. But there is one option that is an issue, and is an issue even outside of ARM SBCs.

Do we want Nixpkgs to start hoarding more and more arbitrarily-sourced forks of the Linux kernel?

Many ARM SBCs end up needing patches on top of mainline, or an outright fork of the kernel to be usable.

This is not an SBC-specific issue, sometimes other class of all-purpose hardware are also better served with patches or forks of the kernel.

Let's say we add support for a Chromebook range that requires patches for something to work right, until it's part of mainline, or the pinebook pro, which requires some patches or fork of mainline. They're not SBCs, might not even be ARM, but add additional kernels that would be part of Nixpkgs.

In my opinion even the raspberry pi kernel fork shouldn't be in Nixpkgs proper. Other single-purpose (as in hardware support) kernel forks shouldn't either.

Though there is a good reason to get them in Nixpkgs, even if I don't like the idea: cached builds! That chromebook user, or even me and my Pinebook would be much better served if the single-purpose forks are built and cached!

• Is the added Hydra load okay? (probably)
• Is the added package maintenance workload okay? (probably not)
• Who updates those kernels? (nobody?)
• What happens when they get stuck on "bad" versions?

And this is before even considering Mobile NixOS, which is part of Future work. Mobile NixOS, because of vendors, basically has as many kernel forks as there are devices to support. Some of them are abandoned, EOL (but working). Some of them are updated downstream, or downstream~ish (e.g. LineageOS community), but are not bumped in the repository.

[samueldr]

One problem with the built-in profiles is I find they're good for a while, and then usually I want to override them in some way, sometimes in ways which are difficult to do without copying their code in to my repo. Is there a style guide or best practice we could come up with which makes this easier for users?

I hope there is a way to automatically mark anything part of <nixpkgs/nixos/hardware/> as a new default level for options, e.g. mkOpinionatedDefault or something of the like, so setting conflicting options in a user's configuration works out of the box, without having to pepper mkOpinionatedDefault all over the <nixpkgs/nixos/hardware/> expressions.

[Ericson2314]

@samueldr So just to understand your argument a bit better, you think that back porting changes to nixos/hardware (let's call it) from unstable like we do for other things will not be feasible? Is that because of the shear amount of stuff to backport / rate of change, or because some of them are breaking changes?

[Profpatsch]

Do we want Nixpkgs to start hoarding more and more arbitrarily-sourced forks of the Linux kernel?

We should make a distinction between “common hardware that people want to use and/or only needs a few defaults” and “support every crazy device under the sun including their kernel blobs”.

For reference, this RFC is about the first kind.

[Mic92]

I'm strongly opposed to this. nixos-hardware is intended as a low-barrier, little reviewed dumping ground for configurations. It should not be merged into nixpkgs which is already way too bloated, is a PR bottleneck, and therefore shouldn't accrue even more functions.

Actually our review standards for nixos-hardware are higher than for nixpkgs. We have branch protection and require at least one review before changes can get merged to it. I don't think nixpkgs is a PR bottleneck either. Only 3 % of all PRs are still open, for Nix it is 15 % and hydra for 16 %. I would say the average time a nixpkgs PR is open is significant lower than most open source projects.

[Mic92]

Do we want Nixpkgs to start hoarding more and more arbitrarily-sourced forks of the Linux kernel?

We should make a distinction between “common hardware that people want to use and/or only needs a few defaults” and “support every crazy device under the sun including their kernel blobs”.

For reference, this RFC is about the first kind.

Yes the cost of maintaining a non-mainline kernel is quite high we should not do it. But we also have not any custom kernel in nixos-hardware right now either.

[Mic92]

I wonder if this would also be a good place to put expressions like NixOS on:

* Packet

* AWS

* Hetzner

* DigitalOcean

* Vultr

* Oracle Cloud

etc.?

We already have Hypervisor specific profiles in nixpkgs (KVM/Xen etc). Most often they are not vendor specific.

[Mic92]

Would we have some QA for those hardware profiles?

For example, I made one profile for my laptop and I'm afraid to open a PR since I have no idea if I choose the right stuff. tlp vs thermald, sssd sutff like trim or not.

In nixos-hardware we often rely on other sources like the archlinux wiki. We also got in contact with the TLP maintainer if necessary.

[bbigras]

In nixos-hardware we often rely on other sources like the archlinux wiki. We also got in contact with the TLP maintainer if necessary.

Thank you very much @Mic92. I'll check the arch wiki and create a PR soon for my config.

[Mic92]

One problem with the built-in profiles is I find they're good for a while, and then usually I want to override them in some way, sometimes in ways which are difficult to do without copying their code in to my repo. Is there a style guide or best practice we could come up with which makes this easier for users?

If you have a look at the current code, it is actually quite modularized. Most laptop model profiles only consist of imports of other modules like common/pc/laptop or common/cpu/intel. Some profile even purely consists of imports. Still we encourage those files to be added so that people have an anchor point to get started with. Things like adding intel microcode updates is not something one would think about adding but is important for security updates.

[Mic92]

Ok. So we meet Tuesday, 2020-08-18 19:00 UTC at https://meet.petabyte.dev/nixos-rfc-70

[infinisil]

You can put it under nixpkgs/nixos/modules/profiles/hardware instead, then modulesPath + "/profiles/hardware/..." can be used to import them. This also makes sense for it to be under profiles because nixos-hardware modules are essentially profiles (modules that aren't imported by default).

[Mic92]

I hope I can do a writeup about the last meeting soonish. However I am in the process of moving places while having a paper deadline. I will resume to it in October.

[Mic92]

It's still in the back of mind and eventually I will get back to it.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/wild-idea-how-about-splitting-nixpkgs-and-nixos/11487/4

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/why-is-there-no-installer-for-nixos/16644/2

[roberth]

For module quality we can already use meta.maintainers in modules, just like we do with packages. This way hardware owners can review each other's changes.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/make-nixos-hardware-more-prominent/46657/6

[Mic92]

As cooperation between Numtide and Clan, we are making a new attempt to build a nixos hardware configuration tool. If we have fleshed out enough details, I will re-open the RFC.
The idea is that we make the tool generate more raw hardware information facts and that NixOS modules than can use to pull in the right configuration. This is also roughly what we discussed in the first and only meeting of this RFC.

[infinisil]

Looks like that was a success: https://discourse.nixos.org/t/better-hardware-detection-with-nixos-facter/49813 :D

[mexisme]

As cooperation between Numtide and Clan, we are making a new attempt to build a nixos hardware configuration tool. If we have fleshed out enough details, I will re-open the RFC.
The idea is that we make the tool generate more raw hardware information facts and that NixOS modules than can use to pull in the right configuration. This is also roughly what we discussed in the first and only meeting of this RFC.

Very cool!

Side note:

Would be especially keen to understand how "exceptions" are handled.
Things that come to mind incl. the multiple extra patches and config. needed for linux-surface or some of the unusual interim/temporary tricks required to help enable certain drivers.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/better-hardware-detection-with-nixos-facter/49813/14

[Mic92]

As cooperation between Numtide and Clan, we are making a new attempt to build a nixos hardware configuration tool. If we have fleshed out enough details, I will re-open the RFC.
The idea is that we make the tool generate more raw hardware information facts and that NixOS modules than can use to pull in the right configuration. This is also roughly what we discussed in the first and only meeting of this RFC.

Very cool!

Side note:

Would be especially keen to understand how "exceptions" are handled. Things that come to mind incl. the multiple extra patches and config. needed for linux-surface or some of the unusual interim/temporary tricks required to help enable certain drivers.

We don't want to deprecate nixos-hardware but simplify it. We can use nixos-facter to import modules from nixos-hardware as needed i.e. using sku names.

[roberth]

I like that a profile-like structure implements a minimal modules list for this area of configuration. nixos-hardware is a bit to hierarchical and arbitrary, but adding imports based on hardware is good for evaluation performance.