Re: Linux-Libre-LTS

[Mark H Weaver <mhw@netris.org>]

Hi Jonathan,

Jonathan Brielmaier <jonathan.brielmaier@web.de> writes:

> On 24.12.20 11:15, Mark H Weaver wrote:
>>> Thoughts?
>>
>> I have one concern.
>>
>> It seems to me that the main reason to specify an LTS kernel is to avoid
>> the unscheduled breakage that can occur when updating to a new kernel
>> release series (i.e. to a new major+minor version).  Using
>> "linux-libre-lts" would fail to avoid these unscheduled updates; it
>> would merely reduce their frequency.
>>
>> The only way to reliably avoid unscheduled major+minor kernel updates is
>> to specify "linux-libre-5.10" or similar.  The cost of this approach is
>> trivial: editing a few characters in the OS configuration when one
>> wishes to update to a newer LTS series.  The benefit is that the user
>> gains control over when these updates will happen, and thus when any
>> associated breakage will occur.
>>
>> To my mind, the benefit of this approach is so compelling, and its cost
>> so trivial, that I can hardly understand why anyone who wishes to use an
>> LTS kernel would choose otherwise.
>
> It sums up, the more systems you maintain the more sums up this trivial
> work. Defining "linux-libre-lts" is the same we do for Icecat or
> Icedove. Yes, there can be breakage when they got update from one ESR
> branch to the newer one.

Well, one key difference is that IceCat only supports one ESR branch at
a time, which essentially leaves the user with no choice about when to
upgrade to a new ESR branch (assuming they want security updates).  Even
upstream Mozilla only supports one ESR branch most of the time, except
for 3 months per ESR cycle when they briefly support two ESR branches.

The situation with LTS kernels is radically different, because each LTS
series is supported for about 5 years beyond when they are superceded by
a newer LTS, and therefore users have a 5-year window from which to
choose their preferred time to update.  Users of "linux-libre-5.10"
could update to the following LTS near the end of 2021, or they could
wait at late as 2026 if they prefer.

> So there are reasons to use always the newest LTS/ESR software version...

The thing is, if they can tolerate unscheduled breakage, then why are
they using an LTS kernel?  That's the part I don't quite understand.

> So I support this addition.

Okay.  If there are users who want the stability of LTS kernels, but
prefer to lose control over when the upgrades happen in order to save
themselves a few edits per year, then we can add the variable.  I don't
have a strong argument against the _existence_ of this variable.

However, I think we should add a comment near its definition, warning
that by using "linux-libre-lts" in their configuration, they will
effectively lose control over when the update to a new LTS series will
happen.  If, in the future, this variable is advertised in the manual,
that should include a warning as well.

Moreover, I would prefer for any relevant comments/documentation to
state that the recommended practice when using LTS kernels is to use a
variable like "linux-libre-5.10", and to explain the reasons why.

This is based on my expectation that Guix users who can tolerate
unscheduled breakage from kernel updates will probably just use our
default "linux-libre" kernel, and that users who would choose
"linux-libre-lts" are probably doing so because they wish to avoid being
caught off guard by unscheduled breakage.  Does that make sense?

What do you think?

      Thanks,
        Mark