Linux To Get "Extended LTS" Releases, Kernel Support For Six Years

[RelaxTrolls]

Longer LTS is the worst possible solution to outdated vendor kernels. If they build against the newest kernel, the set of vendor patches can be continually rebased, which WOULD hugely help them in the development of their next SoC

'Worst possible solution'? That seems a bit dramatic.

The current situation in android is getting a device that has a kernel that will reach/be EOL'd within a year or less and maybe get one OS upgrade... this solution will see devices potentially get 4 major OS upgrades and a kernel that has roughly 4yrs of support from release... it would seem to me that the current situation is much worse 😒

The vendors can't just continually target the latest kernel. Mainline and the android (common) kernel tree are not the same thing. (excluding Vendor patches).... linux development just rolls along, vendors need a stable target; that's why LTS exists to begin with....

I think vendors targetting every kernel release would be problematic and wouldn't help with development of their next soc, in the slightest... not only that; there is no android common tree for linux beyond linux-4.4... so I don't see how that would work at all.

Maybe you could explain the specifics and merits to your thinking?

[d4ddi0]

Longer LTS is the worst possible solution to outdated vendor kernels. If they build against the newest kernel, the set of vendor patches can be continually rebased, which WOULD hugely help them in the development of their next SoC

[RelaxTrolls]

The current LTS release is 4.9 not 4.4

In the context of the article and the extended LTS, what matters right now is linux 4.4 ... new devices with Oreo (and project treble) will be shipped running linux-4.4, so that's the target that matters, regardless of the current LTS.

[FireBurn]

The current LTS release is 4.9 not 4.4

[RelaxTrolls]

The six year kernel will probably come out one month after the five year distro and the new Xfce will come out one week after that... because there's absolutely no coordination between these projects and nobody seems to care. Would it really cause corporate anarchy and chaos to make the release 18.05 or 18.06 if it meant a decent kernel for the next half decade?

Derp. Derp.

This has little to do with linux distributions and nothing to do with Xfce... this has really come about because of android, afaict.

As far as coordination; This IS a coordinated effort between all of the parties involved (google, linaro, Silicon manufacturers, vendors, linux devs, etc.)...

Not sure what you are going on about...

[starshipeleven]

That's the level you're talking of: a bunch of registers, and values bouncing between them. You know what values are for, but it is very hard to make up the diagram from out there.

And let's also add to the mix that most hardware has some kind of microcodes that tell more generic-ish hardware blocks how to execute specific instructions, so to get at how the hardware blocks are you also need to decompile the microcode somehow and try to read how it works.

No... just no.

[starshipeleven]

Why wouldnt it? Seriouslt if you know what the registers fo you can easily go from there to design the required hardware.

This is obscene, and makes your whole post invalid.

[starshipeleven]

Intellectual Property.

In some imaginary world it probably doesn't exist and everyone is broke. In the real world inventors want to put bread in their mouths instead of starving to death.

And how is that related to the fact that hardware manufacturers make most of their money selling you hardware while drivers are usually free?

[starshipeleven]

As much as this list is hated in the Linux community, the community is little by little embracing the problems and solutions outlined in it. Kinda amazing.

That list isn't hated, it's just mostly flamebait bullshit because it blames Linux for things it should blame hardware manufacturers, and blows stuff out of proportion for the sake of throwing shit around.

[starshipeleven]

It would be better if Google would enforce open hardware drivers... I really cannot understand why these cheap devices need closed driver blobs at all. Unfortunately all the ARM devices are a big mess regarding drivers and firmware blobs.

Embedded hardware usually has a very fast development-release-EOL scheme.
They don't have time to make quality drivers at all, anything they make won't be upstreamable at all anyway.

But it's not impossible to move to open drivers, imho it's more of a mindset issue and inertia (switching over to making open drivers means usually rewriting from scratch because their blob isn't using any linux infrastructure like Mesa/Gallium and usually has third-party licenses in it).