SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
re the issue I referred to: yes, dev's were aware and even provided fixes in a private branch, but for whatever reason, chose not to merge them into 5.4 LTS. Anyway, it was just one example to make the point that *stuff* happens, and LTS aren't immune.
Quote:
Originally Posted by bassmadrigal
Again, nobody is saying that the LTS kernels are perfect, but once released, they're more predictable than a new stable kernel release...
And that is the point on which you and I fundamentally disagree. My view is that they're all pretty much a crapshoot.
They're only predictable on the server hardware / vms on which they were tested... for any other user they're a complete unknown. You be one version of the driver version which fixes you particular problem and that may never make it as a backport to the LTS.
bassmadrigal: My point is that before the LTS kernels, Slackware managed to thrive and survive without them. With the LTS kernel, the distribution maintainer still has to rebuild binary packages every patch...
But in that golden time before LTS kernels "dirtied" Slackware, Slackware never pushed a new major kernel release into a stable release of Slackware since 9.1 (and that was a 2.4.x kernel). So, if you stick with the status quo there, then we would be stuck with a kernel with no updates beyond what was shipped within months of a stable release and it would be EOL within months. Slackware also had much more frequent releases, so sticking with a single kernel for less than a year was not nearly as big of a deal as it is compared to now when releases are multiple years apart.
Quote:
Originally Posted by cynwulf
I personally think a known working good stable kernel is the best starting point then moving up to an LTS only once it's established to be a good release. As it stands I recall LTS kernels which were not good releases (unless perhaps you were Red Hat), gave users a lot of grief with hardware support, etc.
If you started with a stable release and then "moved up" to an LTS release once established as good, then you'd either be sitting on an EOL kernel for up to a year until the next LTS kernel is released and verified stable or backtracking to a previous LTS kernel and would lose hardware support.
Determining stability is something that -current is used for. 5.10 started off rough (just like 4.14), but it has stabilized for most users (just like 4.14 did before -current moved to 4.19). The 4.4 kernel was introduced into 14.2's -current 3 days after release. It stayed in -current for the next 5 months until 14.2 was released. 14.2's -current was used to determine the stability of that kernel before releasing 14.2 stable.
Programming for 43 years has taught me that the number of bugs introduced by code changes are proportional to the size of a change times its complexity, but I don't expect that to change anyone's mind.
At the end of the day, it's like what Jan K said -- we can use what Pat provides, or roll our own.
I expect to be using Pat's kernels for my use-cases, but to each their own. My priorities and yours don't have to align.
My 2 cents: I tend to view a Slackware "release" as comparable to RHEL, and "current" as comparable to Fedora. Slackware of course being superior on both account of course. Anyway, I prefer maximum stability/predictability in a Slackware release. I can then tweak it as I require, including replacing the kernel. If I need something more current out of the box, then I use Current.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.