On Mon, 24 Feb 2025 at 11:40, Neal Gompa <ngomp...@gmail.com> wrote: > On Mon, Feb 24, 2025 at 6:04 AM Simon Farnsworth via devel > <devel@lists.fedoraproject.org> 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.
I find generally that for those sorts of usecases copr is actually a great way to deal with kernels, maintaining a kernel in Fedora is a lot of work, dealing with CVEs and other such things to give users both a good experience on something like a RPi5 and the other half of the good experience like not getting hacked is a balancing act that would almost be more work than actually getting the support upstream. Like everything it's a balancing act.
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
