On Mon, Feb 24, 2025 at 6:04 AM Simon Farnsworth via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > On Sunday, 23 February 2025 18:14:21 Greenwich Mean Time Benson Muite wrote: > > On Sun, Feb 23, 2025, at 9:55 AM, Samuel Sieb wrote: > > > > > On 2/22/25 6:50 PM, Benson Muite wrote: > > > > > >> > > >> Fedora has a policy to support only one kernel. Projects such as > > >> OpenHarmony support multiple kernels to enable reuse of components on > > >> devices with a wide range of compute capabilities - in particular mobile > > >> and edge devices. Is this something Fedora would consider doing? This > > >> would potentially benefit spins aimed for mobile and desktop use. > > > > > > > > > > > What do you mean by multiple kernels? > > > > > > Envisage some of the following options: > > a) Enabling use of the mainline linux kernel but tuned for different > > operating expectations - desktop, mobile or server > > For this use case, the Fedora experience is that we've been better served by > working upstream to make the tuning options you need to change things that can > be changed at boot time (or ideally, but not always reasonable, runtime). For > example, preemption model is something that you want to tune, and can be > selected at boot time; my desktop boots with "preempt=full", my throughput- > oriented server with "preempt=none". > > What tuning options do you see need to be different between Fedora Workstation > and Fedora Server, and what blocks them from being boot time or runtime > tunables set by the Editions? > > > b) Options for > > integrating other existing kernels such as GNU/Hurd or LinuxLibre > > > > There's a lot more to this than just "supporting more than one kernel"; > there's plenty that needs to be done to other RPMs than just the kernel to > support a big change, unless the kernel is binary-compatible with all Linux > userspace. > > And if it's binary-compatible with all Linux userspace (like the LinuxLibre > project aims to be), then it's a trivial thing to have a separate repo for the > kernel, and not impossible to fork the entirety of Fedora to make it happen. > > It also runs into a deeper philosophical question; what is the benefit to > Fedora and its users of demanding that they make this particular choice, > rather than having Fedora make it for them? There's a strong argument for > saying that Fedora should ask users to only make decisions that the user can > reasonably answer (like "do you prefer the look and feel of GNOME, KDE or > Xfce?" or "do you want your server to be a traditional 'pet' or a host for a > fleet of 'cattle' containers"), and that people who want "choice in every > aspect" should look elsewhere (e.g. to Debian). > > Don't get me wrong - I fully understand the "fun appeal" of being able to > switch out more bits of the distro; but that has to be balanced against a > distro having a cohesive aim, and spending the limited volunteer time it gets > on things that matter. > > This means that for an extra kernel choice to be worthwhile, it needs to bring > in more volunteer effort improving the distro for everyone (including those who > are happy with today's kernel as the only kernel) than it costs supporting it, > including triaging bugs that are specific to your choice of kernel as well as > the up-front costs. If you can get that much volunteer support, though, you > can start out with a fork or secondary repo, and make the case for merging > with Fedora once you've demonstrated that the support is there for the extra > kernel. To me, it's not about "fun" of swapping out bits of the distribution (trust me, fun it ain't). And it's not about shipping "longterm" stale kernels. It's about the fact that we have no resources to have the kernel package support the hardware people want to use Fedora on. From the Raspberry Pi 5 to the new RISC-V stuff, the "mainline-only" approach only works if there's folks supporting that effort with engineering resources. And we don't have that. As a concrete example, Fedora Mobility has struggled to figure out a reference device because of the lack of options in the mainline kernel. Justin Forbes does great work maintaining the Fedora kernel, but he's the only one. In 2018, we had three kernel engineers. We briefly had four in 2019, but today, we're down to one. And because of the way the kernel package is maintained (with CKI and secure boot and such), it seems like only Red Hatters are able to maintain that package. So where's the community opportunity to enable the things that they want to use Fedora on? So far, it seems by creating custom kernel builds in COPR for remixes. This is a point where I feel we have some misalignment of interests. I think it's fair to say we *want* to remain tracking mainline and there are a lot of benefits to doing so. But we're sacrificing a lot for it, including first-mover advantage and opportunities that follow from that. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
