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

[Luca Boccassi]

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.

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.

Just my 2c.

-- 
Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220324/e43eedba/attachment.sig>