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 hvvlEr9N5V8AQQAA0tVLHw (envelope-from ) for ; Fri, 25 Dec 2020 02:26:07 +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 yOQ1Dr9N5V+PLQAAB5/wlQ (envelope-from ) for ; Fri, 25 Dec 2020 02:26:07 +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 9A1659401CD for ; Fri, 25 Dec 2020 02:26:06 +0000 (UTC) Received: from localhost ([::1]:49878 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kscnt-0006ep-HV for larch@yhetil.org; Thu, 24 Dec 2020 21:26:05 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40064) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kscnT-0006eY-Ha for guix-devel@gnu.org; Thu, 24 Dec 2020 21:25:39 -0500 Received: from world.peace.net ([64.112.178.59]:56228) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kscnP-0003eQ-Mk for guix-devel@gnu.org; Thu, 24 Dec 2020 21:25:39 -0500 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kscnD-00082K-Ar; Thu, 24 Dec 2020 21:25:23 -0500 From: Mark H Weaver To: Jonathan Brielmaier , guix-devel@gnu.org Subject: Re: Linux-Libre-LTS In-Reply-To: <86bbed0c-3b57-f276-81a5-c0f1c1b6858e@web.de> References: <877dp7ik5v.fsf@netris.org> <86bbed0c-3b57-f276-81a5-c0f1c1b6858e@web.de> Date: Thu, 24 Dec 2020 21:24:17 -0500 Message-ID: <877dp6ipw3.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=64.112.178.59; envelope-from=mhw@netris.org; helo=world.peace.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.32 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: 9A1659401CD X-Spam-Score: -2.32 X-Migadu-Scanner: scn1.migadu.com X-TUID: lW0uV3a5Pogb Hi Jonathan, Jonathan Brielmaier 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