Re: [Cerowrt-devel] Reaching out to Greg KH for 6 year LTS kernel versions

Re: [Cerowrt-devel] Reaching out to Greg KH for 6 year LTS kernel versions

[Dave Taht]

I am not on the openwrt-devel list from this acct... I tried to
resubscribe but its taking too long...

On Wed, Aug 10, 2022 at 1:29 PM Philip Prindeville
<philipp@redfish-solutions.com> wrote:
>
> Not to play the devil's advocate but... do we want old kernels hanging out that long?

People are still shipping 3.3 kernels.

> Besides not encouraging people to update to new releases that mitigate discovered CVE's, we'd also not pick up David Taht's excellent improvements in Buffer Bloat.

People keep giving me too much credit. There have been dozens of core
contributors to this effort, 1000s of others, and we have billions of
machines (not enough routers, tho!)  now doing more of the right
things. I haven't made a technical contribution in years. I( got a
couple new things that I'd like to work on, but no funding). What was
once a 5-7 lag in embedded from devel to distribution now seems closer
to 10.

I've gone political in search of finding ways to get bufferbloat fixes
out there. Somehow convincing the world that in addition to burning
billions on fiber buildouts ISPs should be supplying better routers
has been a big goal, and I'm low on ideas on how to move forward on
that.

Certainly finding some way to get openwrt shippers like starlink to at
least  plan to upgrade to a modern openwrt rather than continue to
ship LEDE is very desirable... 6 year old kernels at FCS.... noo...

I thought ooka's new speedtest (which measures responsiveness on
up/downloads now) would provide a tipping point. Certainly also
preseem and libreqos are making an impact in the smaller ISP
markets...

In the last 6 months of coping with a string of regressions in
openwrt's wifi[1], I've reflected on the waddington effect a lot. If
you haven't heard of it, it applies a string of criteria to how and
why you o prevenntative maintenence on airplanes:

https://resources.savvyaviation.com/wp-content/uploads/articles_eaa/EAA_2011-03_the-waddington-effect.pdf

As for 6 years on a LTS kernel, my instinct is NOOOOO! Progress MUST
be made! We must keep working towards making kernel upgrades
continuous and easy. But think deeply on the waddington effect.

The cold and bitter reality though is if someone is willing to pay
someone(s) to maintain a kernel for that long, and it keeps up with
major security issues, it's no skin off our backs. I would prefer cash
be injected into better review ( there are 1500 open issues and 300+
outstanding https://github.com/openwrt/openwrt/pulls right now), we
found ways to attract, train, and retain good developers in "the FOSS
way", and more companies and governments using openwrt found ways to
support those, and "sufficiently rapid" change in the ever more
fossilized FOSS ecosystem.


[1] https://www.linkedin.com/feed/update/urn:li:activity:6963337312596369408/


>
> > On Aug 8, 2022, at 5:15 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> >
> > Hi,
> >
> > Greg KH has communicated a few times before on his blog [1] that he is seeking the help of individuals and company to help him maintain the LTS kernels and allow them to be made 6 years instead of just the usual 2 years.
> >
> > 5.10 is a 6 year LTS, but 5.15 is not listed as such, although it certainly would make sense for it to be since we use 5.15 in OpenWrt.
> >
> > It would be good for the project to have a designated contact who can communicate the kernel version plan ahead of time, or once a LTS is picked up, we could sign up people to do regular testing of the stable release candidates?
> >
> > Thoughts?
> >
> > [1]: http://kroah.com/log/blog/2021/02/03/helping-out-with-lts-kernel-releases/
> > --
> > Florian
> >
> > _______________________________________________
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>


--
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC