| 30 Jun 2022 |
 matthewcroughan - nix.how | In reply to @qyliss:fairydust.space
you could provide a flake that works! I mean, that is fair enough. But it's definitely more complex code, and it's more to think about, and less abstracted by nixpkgs. | 08:38:34 |
 Linux Hackerman | What's so special about the kernel that it can only come from nixpkgs? | 08:38:43 |
| matthewcroughan - nix.how | In reply to @linus:schreibt.jetzt
What's so special about the kernel that it can only come from nixpkgs? Nothing. It's just better without the policy, from the perspective of someone using the code. | 08:39:05 |
| matthewcroughan - nix.how | If you just forget nixpkgs policy for a moment, and think about the user, this is a superior setup as is. | 08:39:16 |
| matthewcroughan - nix.how | But, introducing the nixos-hardware separation, means that the user now has to add more inputs and a library called nixos-hardware. | 08:39:47 |
 Alyssa Ross | it's a superior setup for a little bit until kernels in nixpkgs become an unmaintainable mess due to hundreds of vendor kernels :P | 08:39:57 |
| matthewcroughan - nix.how | That's fair enough, and it only looks pretty now because it's the first such case. | 08:40:10 |
| Linux Hackerman | yeah, and likewise for images | 08:40:40 |
| matthewcroughan - nix.how | Or is it the first such case? Are there not already a few cases like this in Nixpkgs? | 08:40:50 |
| Alyssa Ross | we do have a few vendor kernels currently in nixpkgs, but only for historical reasons | 08:40:55 |
| Alyssa Ross | the raspberry pi ones for example | 08:41:03 |
| matthewcroughan - nix.how | If there are a few cases like this in Nixpkgs, I'd rather merge this, then make an RFC to move things to nixos-hardware. | 08:41:06 |
| Alyssa Ross | that experience has taught us that accepting more is a bad idea | 08:41:22 |
| matthewcroughan - nix.how | Right, but do you see how this makes a uniquely bad setup for the visionfive, whereas there is a good one for the pi? | 08:41:40 |
| Alyssa Ross | no, it's a uniquely good setup for the pi | 08:41:52 |
| Alyssa Ross | visionfive is on the same playing field as everything else | 08:42:03 |
| Linux Hackerman | pi and good, lol | 08:42:15 |
| Alyssa Ross | i would like to stop the pi having a privileged position, but the solution to that is not to add to the problem | 08:42:21 |
 dramforever | I think the message should be that VisionFive isn't a very supported board in nixpkgs because it requires way too many vendor-specific tweaks | 08:42:59 |
| dramforever | Not that we should make it very supported | 08:43:10 |
| matthewcroughan - nix.how | I think this problem is big enough for an RFC, and to add to the problem until the total problem has been resolved, but this is semantic since I can continue to have my flake provide a working image no matter what the separation is | 08:43:10 |
| Linux Hackerman | huh, there's also a hardkernel kernel... which was last updated in 2020 | 08:43:19 |
| Linux Hackerman | Maybe we should throw that out. | 08:43:26 |
| Alyssa Ross | the more we add to the problem, the harder it is to resolve | 08:43:32 |
| matthewcroughan - nix.how | The policy of nixpkgs needs to change, because there is no policy that states we shouldn't have vendor kernels. | 08:43:38 |
| matthewcroughan - nix.how | But this is now just ad-hoc policy that we're making up, so technically that needs an RFC doesn't it? | 08:43:55 |
| Alyssa Ross | no | 08:44:01 |
| dramforever | Especially considering that VisionFive either
- Eventually upstreams its stuff, or
- Just disappears into oblivion because JH7110 came out
| 08:44:06 |
| dramforever | and/or, really | 08:44:20 |
| matthewcroughan - nix.how | So there already exists written somewhere, something that explains that we shouldn't add vendor kernels to nixpkgs? | 08:44:24 |
