On Sat, Jun 05, 2021 at 02:09:59PM -0400, Mark H Weaver wrote: > Hi Efraim, > > Efraim Flashner writes: > > I don't really understand why > > and how a newer kernel would make things stop working, > > Newer kernels _usually_ work fine, but occasionally things break, and > that's much more likely to happen when switching to a newer kernel > series. It happened to me quite recently, when a couple of us found > that early 5.12.x kernels would lock up a Thinkpad X200 within minutes > of booting. See . > > For those who can afford to deal with breakage like this at unscheduled > times, the 'linux-libre' variable is likely the best choice. For those > who prefer stability, I recommend 'linux-libre-X.YY' for some LTS series > X.YY. > > The 'linux-libre-lts' variable seems to me the worst of both worlds, and > likely to lead to some people getting burned from unexpected kernel > upgrades that they might not have been expecting. If 'linux-libre-lts' > is included as an option, I recommend adding text that makes it clear to > users that automatic upgrades to newer LTS series will happen without > warning, years before such upgrades are needed. > > What do you think? > > Regards, > Mark > I know if I were using the zfs kernel module I'd want to use the most recent lts release. I like the idea of labeling it something like: * linux-libre (tracks the latest kernel release) * linux-libre-lts (tracks most recent long-term support release, with upgrades to newer versions automatically) * linux-libre-5.10 (current long-term support release, supported until December 2026) I know upstream uses 'stable' to mean the current release, but I personally find the terminology confusing. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted