[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Linux-Libre-LTS
From: |
Bengt Richter |
Subject: |
Re: Linux-Libre-LTS |
Date: |
Sun, 27 Dec 2020 14:27:38 +0100 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
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
- Re: Linux-Libre-LTS, Raghav Gururajan, 2020/12/23
- Re: Linux-Libre-LTS, Mark H Weaver, 2020/12/24
- Re: Linux-Libre-LTS, Raghav Gururajan, 2020/12/27
- Re: Linux-Libre-LTS, Leo Famulari, 2020/12/29
- Re: Linux-Libre-LTS, Raghav Gururajan, 2020/12/30
- Re: Linux-Libre-LTS, Raghav Gururajan, 2020/12/30
- Re: Linux-Libre-LTS, Leo Famulari, 2020/12/30
- Re: Linux-Libre-LTS, Leo Famulari, 2020/12/30
Re: Linux-Libre-LTS, Jonathan Brielmaier, 2020/12/30