From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id YC11EeiL6F91cwAA0tVLHw (envelope-from ) for ; Sun, 27 Dec 2020 13:28:08 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id wPZUDeiL6F+LTAAAB5/wlQ (envelope-from ) for ; Sun, 27 Dec 2020 13:28:08 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id E3C7F9404C4 for ; Sun, 27 Dec 2020 13:28:07 +0000 (UTC) Received: from localhost ([::1]:35488 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ktW5e-0003uQ-KX for larch@yhetil.org; Sun, 27 Dec 2020 08:28:06 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46106) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ktW5V-0003uF-LF for guix-devel@gnu.org; Sun, 27 Dec 2020 08:27:57 -0500 Received: from imta-37.everyone.net ([216.200.145.37]:50998 helo=imta-38.everyone.net) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ktW5T-0006AO-3V for guix-devel@gnu.org; Sun, 27 Dec 2020 08:27:57 -0500 Received: from pps.filterd (localhost.localdomain [127.0.0.1]) by imta-38.everyone.net (8.16.0.43/8.16.0.43) with SMTP id 0BRDO1qf005963; Sun, 27 Dec 2020 05:27:51 -0800 X-Eon-Originating-Account: VKnjGGsYl7eh9zf9Sz47IpXro8ze0xpdBA1Lxy07sMg X-Eon-Dm: m0116952.ppops.net Received: by m0116952.mta.everyone.net (EON-AUTHRELAY2 - 5a81d781) id m0116952.5f8a0279.f93fac; Sun, 27 Dec 2020 05:27:50 -0800 X-Eon-Sig: AQMHrIJf6IvWa9qtvgIAAAAD,a8fc9628dfc69191ecce89bb1590e2a6 X-Eip: LIXFMnFSGoksf7rBxr4ry_nREgVO61sKhThJ4wTst1c Date: Sun, 27 Dec 2020 14:27:38 +0100 From: Bengt Richter To: Mark H Weaver Subject: Re: Linux-Libre-LTS Message-ID: <20201227132738.GA21806@LionPure> References: <877dp7ik5v.fsf@netris.org> <86bbed0c-3b57-f276-81a5-c0f1c1b6858e@web.de> <877dp6ipw3.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <877dp6ipw3.fsf@netris.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-27_10:2020-12-24, 2020-12-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 spamscore=0 adultscore=0 phishscore=0 mlxscore=0 lowpriorityscore=0 mlxlogscore=999 bulkscore=0 impostorscore=0 suspectscore=0 clxscore=1034 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012270084 Received-SPF: pass client-ip=216.200.145.37; envelope-from=bokr@oz.net; helo=imta-38.everyone.net X-Spam_score_int: -23 X-Spam_score: -2.4 X-Spam_bar: -- X-Spam_report: (-2.4 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Bengt Richter Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -1.82 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: E3C7F9404C4 X-Spam-Score: -1.82 X-Migadu-Scanner: scn0.migadu.com X-TUID: YBvjf0xNm5ML Hi Mark, et al, On +2020-12-24 21:24:17 -0500, Mark H Weaver wrote: > Hi Jonathan, > > Jonathan Brielmaier 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