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

[Greg Kroah-Hartman]

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 at linuxfoundation.org> schrieb am 24.03.2022 um 08:12 in
> > > Nachricht <YjwZ56FP4Qgx3cMC at kroah.com>:
> > > > 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.

thanks,

greg k-h