Re: Linux-Libre-LTS

[Bengt Richter <bokr@bokr.com>]

Hi Mark, et al,

On +2020-12-24 21:24:17 -0500, Mark H Weaver wrote:
> Hi Jonathan,
> 
> Jonathan Brielmaier <jonathan.brielmaier@web.de> writes:
> 
> > On 24.12.20 11:15, Mark H Weaver wrote:
> >>> Thoughts?
> >>
> >> I have one concern.
> >>
I have several :)
       1. Abuse of the english word "stable"
          ISTM the updating churn in internet-retrievable software 
	  is anything but "stable" and -- with exceptions -- as implemented
	  has pi**-poor quality control (which a complete transactional undo graph
	  does not solve by itself).
       2. The amount of breakage borders on arrogant disregard of users.
       3. The situation amounts to denial-of-service sabotage of FLOSS.
       
> >> 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.
> >>

How about a .guix-ask-first profile that guix would check for symlinks
and .gitignore- or .robot-like files saying how to treat designated objects
and operations?

There could be room in the .guix-ask-first profile for hints and warnings
and CVE references and schedules for periodic TTS nagging and or popup
notices. With guile it's only limited by your imagination and time :)

Anybody remember motd? :)

I actually like being reminded of important updates, but I want control of
initiating them. Also, I want the option to have the full CRUD-list of
what will happen when I do initiate it.

I want control because I despise having my preferences reset without my consent :)

> >> 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.
> >

I agree, so WDYT? Can we have the best of both worlds by designing
a .guix-ask-first profile and associated guix mods ?

> > 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.
>

To me, that is a measure of the quality control done on the newer one,
and the installation system :)

> 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.
>

.guix-ask-first ? (Please excuse the nagging :)

> > 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.
>

And let .guix-ask-first govern how to use it? :)

> 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.
>
I would like a .guix-ask-first profile with append-only installation default
for itself, and the rest defaulting to avoidance of breakage.

Another thing I would like is for .guix-ask-first to have access to
some kind of package score for trustability, reliability, and hackability.

I'm not sure how to define a scoring system, but I want it to tell me
the difference between enthusiastic hobby-hacking and professional quality.

But also about trusting motivations: there are pro saboteurs, and genius amateurs :)

I like the stackoverflow scoring of answers. I'd like something similar for packages.
 
> 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?
>
See above :)

>       Thanks,
>         Mark
> 
-- 
Regards,
Bengt Richter