[gregkh]

They feel like they know better and do not want all of the fixes that the LTS kernels provide for some crazy reason.

I suggest you contact them if you rely on a RHEL kernel to ask them why they do this, it's always seemed crazy.

Note, I'm the person who does the LTS kernel releases, maybe they just don't like me :)

[rwmj]

I'm certain that Red Hat and our kernel developers have no animosity towards you, in fact it's completely the opposite. You're well known in the community not just for this but for maintaining and writing countless drivers and loads of other great work in the kernel.

Fedora does use the LTS kernels.

[iforgotpassword]

> They feel like they know better and do not want all of the fixes that the LTS kernels provide for some crazy reason.

It's even crazier; they sometimes backport changes to their kernel that the LTS kernels don't get. We use a custom kernel module that contains a bunch of #if #endif blocks that check the kernel version for stuff that changed. Doesn't work on RedHat since you actually need the branch that's for more recent kernels in some places.

[orf]

Isn’t the whole autoconf stuff supposed to avoid the need for if macro soup, by using feature detection?

[iforgotpassword]

There would be cleaner ways to achieve this, maybe not specifically autoconf since I think that's more tailored towards "normal" (user space) stuff.

Macros are convenient to quickly check the version in your code without adding another layer of tooling... Until you end up with said macro soup of course.

It's actually a legacy module we're about to phase out for 5.x so don't worry too much. The new and shiny replacement will probably use git branches for whenever something changes.

[stonogo]

It could also be motivated by the fact that it's not entirely wise to base an entire multibillion dollar business around whatever text a non-employee happens to push to a repo you don't control.

[gregkh]

Android doesn't seem to mind, they require the LTS updates to be taken for their devices (well, "require" is a strong word, they are pushing harder now than they were in the past, "required" will be happening in the future, hopefully...)

As the number of systems running RHEL is really just a rounding error compared to the number of Android systems out there, maybe it doesn't really matter :)

[bonzini]

Android and RHEL are completely different scenarios.

The target of Android, which is who Google has to deal with, is multiple manufacturers creating kernels for custom hardware (often without upstream drivers), with very short product life, relatively little experience with upstream contribution and few needs for new features for a given major release of Android.

RHEL is developed by a single company with a 10 years life cycle, only 3-4 kernel versions to juggle but almost non-overlapping lifecycle (as far as the initial development-heavy phase is concerned). Development occurs upstream first and quite a few engineers are upstream developers or maintainers, so that the number of non-upstream features is very small and almost going down over time, see for example stuff like the secure boot lockdown patches that Matthew Garrett started when he was at Red Hat. And even though the product is not the kernel, we need to backport more features than what goes into LTS, because userspace needs them (user namespaces, driver updates, networking or virtualization optimizations, enablement for new processors, etc.)

So it's only natural that there are completely trade-offs to make.

[azinman2]

I would guess that RHEL has more stringent requirements than your average me-too Android manufacturer.

[radiator]

But do the devices running Android generally operate with the same requirements as the servers running RHEL?

[nordsieck]

> But do the devices running Android generally operate with the same requirements as the servers running RHEL?

I guess it depends on the device and the business.

How many days of downtime on Amazon.com is the cost of bricking 1M phones? Or 100M?

[stonogo]

Yes, that's why all the servers in the datacenter are running Android, which has a stellar security record.

This sort of myopia is yet another excellent reason for Red Hat to take their kernel process in-house.

[phh]

LTS' security record is definitely not to be proven. The example we're currently commenting on this thread is only one occurence. It is highly re-occuring.

RHEL fixes only CVEs. Linus Torvalds consider there is no such thing as a security bug, that actually every bug is a security bug. So RHEL's kernel can't be secure.

[zozbot234]

Debian also uses LTS-series kernels for their stable release - with their own patches on top. They don't actively backport features like RHEL does however.

[baggy_trough]

Why doesn't that argument apply to the mainline kernel?