Re: Antw: [EXT] Re: [systemd‑devel] version bump of minimal kernel version supported by systemd?

[Neal Gompa <ngompa13@xxxxxxxxx>]

On Thu, Mar 24, 2022 at 8:15 AM Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Thu, Mar 24, 2022 at 10:23:21AM +0000, Luca Boccassi wrote:
> > On Thu, 2022-03-24 at 09:45 +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Mar 24, 2022 at 09:33:50AM +0100, Ulrich Windl wrote:
> > > > > > > Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> schrieb am 24.03.2022 um 08:12 in
> > > > Nachricht <YjwZ56FP4Qgx3cMC@xxxxxxxxx>:
> > > > > On Wed, Mar 23, 2022 at 10:34:00PM +0000, Dave Howorth wrote:
> > > > > > FWIW, I think Greg was a bit too outspoken calling long maintenance
> > > > > > attempts 'crazy'; that may have intimidated some. I'm thinking of
> > > > > > moving distro to one that provides longer term maintenance than my
> > > > > > present one. Although CIP is a completely different ball game; I hope
> > > > > > they succeed.
> > > > >
> > > > > It is not "crazy" it is "well documented".  As someone who has been
> > > > > doing this work for 20+ years now and sees all of the stable kernel
> > > > > patches flow by, it's obvious that a distro that does not keep up with
> > > > > them is insecure by design.
> > > >
> > > > If "newer is better" I'd agree. Sometimes "newer is actually worse".
> > > > Some new features intended to improve things sometimes actually make things worse.
> > >
> > > That's not the issue here.
> > >
> > > Do you want to run a kernel with known security problems, or one with
> > > "unknown potential problems."  The latter is always the case, so please
> > > don't pick the known-insecure one, that's just foolish.
> >
> > "security problems" are a dime a dozen, as they say. Speaking as a
> > (thankfully former) downstream integrator, you'd have much more success
> > if you stopped breaking backward compatibility with userspace all the
> > damn time. Upgrading major kernel version is like rolling a dice, you
> > never know what kind of extremely expensive and time consuming rabbit
> > hole you'll be dragged into because the kernel plays fast and loose
> > with its userspace interfaces, and each and every time there's a chance
> > one might end up having to do major reworks to deal with it.
>
> We should never be breaking working userspace programs when upgrading
> the kernel.  If so, please report it to the regressions mailing list.
>
> Of course there's always some corner cases, but for the most part, this
> should never happen.
>
> > So really it shouldn't be that surprising that users are averse to
> > following the "latest is greatest" mantra from kernel.org, given how
> > risky and expensive it is, and how little one gains in return. Rather
> > than changing the world, what about changing your own processes first?
> > A great starting point would be reverting backward incompatible changes
> > regardless of who's affected, instead of doing that only if they affect
> > the personal computer of a handful of maintainers (mainly Linus'), and
> > shrugging reports away with "deal with it" in other cases.
>
> We should never be "shrugging" away reports like this.  If you have
> specific incidents that you wish to discuss, I will be glad to do so on
> the regressions kernel mailing list.  Otherwise this is way off-topic
> for systemd-devel.
>