Are you just forgetting all the issues people were having with the 5.10 kernel when it was added to -current? My, your memory is short...

1 members found this post helpful.

No problems which they have encountered so far, using just those few applications they use in their own specific ways.

I get it, you're very happy building your own kernels which support your ever-churning hardware, and that's fine. You do what works for you. Nobody is trying deny you that.

Others of us don't need a cutting-edge kernel, and would rather have the peace of mind which comes from knowing there are thousands of others using exactly the same kernel that we do.

This means there are more use-cases exercising the kernel from more directions, which makes bugs more likely to surface, so they can be fixed (hopefully before I run into that bug).

Different strokes for different folks. We can all get what we want. There's no need for a one-size-fits-all solution.

5 members found this post helpful.

I'm one additional user who can NOT run 5.10 on my older Pentium D 950 CPU. It will stop processing, it will not return from sleep, it will require a hard restrart, it will pause when processing the initrd for minutes (longest was 5min 36 seconds) with absolutely no know reason. it will kernel fault when loading the initrd and after the initrd is done loading an attempting to switch to OS. I have done of these issues when using 4.4.261 official from Pat or my own rolled 4.4.261. I thought the issue was the config file modifications I was making, to eliminate modules not required in my setup, but even using Pat's kernel config the problems continued. I currently running 4.4.268 as my daily, but intend to try 5.12.4 now that Pat has indicated in is available in testing. I hope Pat doesn't keep 5.10 in final release of 15. Cheers, BrianA_MN

What's the alternative? Ship a kernel that will be EOL in a few months? Or use an older LTS that will be missing a lot of recent hardware support?

I appreciate Pat including the latest stable release in testing/, but I think it'd be a mistake to ship 15.0 with one of those kernels being the main kernel. It will either become EOL really quick, or it will require Pat to upgrade to each new stable release, which can then introduce potential problems like we saw/are seeing with 5.10.x.

I say stick with the the 5.10 kernel for the main tree and offer the latest stable in testing/ for those who want/need a newer kernel. (Not that my opinion will dictate what Pat does.)

Why did you spread misinformation? I am just curious...

The "latest stable kernel" will NEVER go EOL, and you know well this, because there will be always another kernel series ready to replace it and to take the stick of "latest stable kernel" again and again and again. Forever.

Yes, there's a very good alternative: to maintain forever updates on the latest stable kernel.

In fact, this would be just something like our BDFL stated that he intends with Firefox. Did you are aware that he intends to maintain Firefox on the Desktop Channel? That we will get forever the latest stable Firefox?

OK, at least until updating it will not require major changes on the stable releases of Slackware.

This is the prefect solution also for The Kernel. Because the World will not freeze for 8 years when Slackware 15 will be released.

In fact, the LTS kernels should be avoided like the cancer. Or COVID-19. Or Ebola.

We will miss exactly nothing if our BDFL will jump over them - they are the worst releases anyway, because the kernel developers put a lot on junk on them.

1 members found this post helpful.

Are you really that dense? I even explained it further in my post.

If you ship a stable (non-LTS kernel), it will be EOL in months (if not less). That means that 15.0 will either be stuck with an EOL kernel OR Pat would need to continue to update the main kernel to the latest stable. The second is not an automatic guarantee (since we're strictly talking hypotheticals, we need to discuss both sides).

As I've discussed with you what feels like hundreds of times, this introduces more chances for a problematic kernel .

Shipping the "latest stable kernel" means that the kernel included with the main install will be EOL very quickly.

Firefox is VASTLY different than the kernel. There's multiple browsers shipped that you can choose from and countless others you can install separately if Firefox isn't working for you.

Yeah, continue to pretend that every single major kernel has been a perfect upgrade from the previous one and never introduced new problems...

That's why hundreds of millions of Android phones are using them? And probably a decent number of distros? Can you start using logic?

We open ourselves up for possible new issues every 2-3 months. Read ttk's post again and actually understand it. Not everyone wants to constantly be on the bleeding edge.

They sometimes start out this way, but they stabilize after months and years of people using the same kernel. Bugs get found and fixed and the kernel improves. If you switch to the latest stables, you only have a max of 2-3 months for any issues to be worked out until they throw that kernel away and start working on the next one.

Have you seriously forgotten the issues that cropped up for some users with the 5.10 kernel? Do you wish to subject users to that potential instability every 2-3 months? Users should choose to be on the bleeding edge, not be forced onto it. Once a release is tagged as stable, it should no longer continue to receive bleeding edge updates. Bleeding edge updates should continue for the development release into the next stable release of Slackware. For those users that want to remain on the bleeding edge, they should stick with -current (or roll their own updates for the software they want to remain on the bleeding edge).

Did you forget what a stable Slackware is intended to be? I know it's been a while, but Pat has well over 20 years of history showing us what to expect with a stable release of Slackware, and what you propose goes against that.

4 members found this post helpful.

Did you write this with tongue in cheek, or were you just being too clever by half?

1 members found this post helpful.

I suspect he's never spent a single day working in software development, at least not for a "reputable" IT shop,
maybe QA is not in their dictionary

2 members found this post helpful.

This is an appeal to popularity. I could say:

"hundreds of millions are using systemd"
"hundreds of millions are using MS Windows 10"

You use Slackware and that's a niche operating system, not a "hundreds of millions" one. So already there is some faulty logic.

I think some of you really fail to understand why LTS aren't the best solution. I remember Debian Squeeze and the 2.6.32 kernel (the RHEL 6 kernel) and some of the issues with that. It's why "backports" kernels are so prevalent in Debian, as well as users having to run off their own. The danger with LTS is that it can land on a particular kernel release which could have some specific problems - which may primarily or only affect desktop users, or users of certain hardware - and those problems will never be fixed. The fix is to build the latest stable kernel.

LTS fall into the category of what I would call "predictable crap" ("polishing the turd"). i.e. you "freeze" a piece of software with known bugs and limitations, then provide only security patching as demanded by enterprise, to provide a "stable" platform for servers in an environment where there is usually paid support. Windows XP used to, and still does to an extent, fall into the same category. The demands of enterprise are - that they have some particular solution which needs to run for X number of years with no surprises. It's called RHEL - and unsurprisingly they are the main driving force behind it.

Android is actually not so different - it powers an embedded Linux based, "consumer appliance" and the demands are that it just works for X years - on that very static piece of hardware, which never has anything new added to it and which the end user has very little control over. Eventually the device, but usually the OS installed on it first, are obsolete.

5 members found this post helpful.

1) If a bug isn't biting you, then it's not a concern. Software is always full of them.
2) A LTS point release is just as likely to introduce a new bug, so that argument doesn't stand.

I was forced to abandon 5.4 LTS because of a bug introduced in a point release, whose fix was never backported to that branch. It may not have officially EOL'd, but to all intents and purposes 5.4 was EOL to me, and with no warning.

These guys also seem to be having an issue with a LTS point release. Maybe it'll get fixed, maybe it won't!

"LTS", or "stable" branch, or Linus' official mainline release, makes no odds. There's little to no QA from the kernel.org devs. That's why the big name distro' maintain their own in-house kernels.

It's all just "Suck it and see.", and the only way to avoid nasty surprises is to sit where you are.

4 members found this post helpful.

Have you considered that LuckyCyborg's goal with their posts in this forum is not to get Slackware to change but to get people to lash out?

It's worth noting that Slackware has only seemingly jumped on the LTS band wagon from 14.0 onward (3.2.29 kernel). Prior to that releases hit the odd LTS release, but with no real pattern evident. For example the 13.x releases, (13.0/13.1/13.37) released with 2.6.29, 2.6.33 and finally 2.6.37 (skipping over 2.6.32 - later to be LTS). I found that 2.6.37 in particular "ironed out" quite a few issues with Intel graphics which were plaguing some users' systems at the time, including one or two of my own running 2.6.32.

Hence why I do believe that it's a valid critique, in that releasing with an LTS kernel is not always in a typical desktop users best interests.

5 members found this post helpful.

You missed or ignored the context of the post. LuckyCyborg stated that LTS should be avoided like the plague. My remark had nothing to do with popularity, but with testing and usage.

I think you fail to understand the reason why a STABLE release of Slackware, which has major software almost always version locked unless it absolutely can't be, should contain an LTS kernel that will continue to receive security updates for 2-6 years after that kernel is released.

Proposing a stable kernel be the main kernel in Slackware is either asking for an EOL kernel almost immediately after release or for Pat to go against what he's done for decades and upgrade major software in a stable release.

And that is always a possibility even with the latest stable release. Nobody is saying that users can't/shouldn't upgrade their own kernel (or use a kernel from testing/), but sitting on the bleeding edge for the kernel in a stable release of Slackware flies against everything Slackware stands for with its stable releases.

And this is the case with every other piece of software that's included in a stable release of Slackware. They generally aren't updated after Slackware is release unless there's a patch for the bug or a security fix.

Have people seriously forgotten what a stable release in Slackware is intended to be?

I think *just as likely* is not accurate. It certainly is possible for an LTS point release to introduce a bug, but I imagine it is more likely for a new release to introduce bugs.

Out of curiosity, was this bug ever reported to the kernel devs?

Again, nobody is saying that the LTS kernels are perfect, but once released, they're more predictable than a new stable kernel release... this is why it belongs as the main kernel in a stable release of Slackware. If someone is seeing a bug, simply install a kernel from testing/.

I'll just quote a portion of a previous post I made on this subject. Long story short, once official LTS releases were announced and released by kernel devs, Slackware has used them.

1 members found this post helpful.

@bassmadrigal I respect your opinions and appreciate your help in many ways. I was really just pointing out that on my Pentium D 950 the 5.10 kernel has many issues that prevent the hardware from being stable when running it That's my issue, not Pat's. Pentium D is a very old technology. Since my last post an attempt to build 5.12 wouldn't even build, it erred at attempting to build the mellonox modules.

BTW - 14.1 shipped 3.10 kernel but ended with 4.4, was 4.4 a "Stable" release at that time? 14.2 shipped with 4.4 and is still on 4.4 so many years later. In my unique case I might have to build a LTS kernel, maybe even with Pat's slackbuilds, before upgrading just to keep the system stable. The hardware I choose to use is not Pat's issue, it is mine.

Now I'm going to go lurk on other threads about how to fix some of 5.10 LTS stability issues for 14.2, maybe some real solutions rather than opinions and whining are available over the fence.

Cheers, BrianA_MN

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... 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.

3 members found this post helpful.