Hi Mark, et al, On +2020-12-24 21:24:17 -0500, Mark H Weaver wrote: > Hi Jonathan, > > Jonathan Brielmaier <jonathan.brielma...@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