LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 05-13-2021, 03:18 AM   #31
Nille_kungen
Member
 
Registered: Jul 2005
Distribution: Slackware64-current
Posts: 559

Rep: Reputation: 191Reputation: 191

Quote:
Originally Posted by LuckyCyborg View Post
For example, and just as example: my older than dirt Dell Radeon R5 240 graphics card got functional UVD (for VDPAU) on the AMDGPU driver only recently. And, still today there's room for VCE and power management.

So, even today I have to choose between having functional either OpenCL or VCE.
That card got UVD support in 2013 with Radeon (2014 if it was one of the few Oland that didn't work in 2013).
That card got VCE support in 2015 with Radeon.
I wonder what OpenCL you use for that card, both use cases and solution/stack since i can't imagine that Rocm is a viable option.
I always found Radeon to be the best driver for my Oland-based card.
I do think it's a bad example since there never really was a need to use AMDGPU for that card.
https://www.phoronix.com/vr.php?view=18602
https://www.phoronix.com/scan.php?pa...tem&px=MTU3Njg
https://www.phoronix.com/scan.php?pa...Source-VCE-1.0

That said newer hardware often means a kernel upgrade.
I do think many users use laptops or tablet/mobile today and their hardware are more or less fixed, i do think that desktop users are mostly gamers and workstation.

Last edited by Nille_kungen; 05-13-2021 at 03:32 AM.
 
Old 05-13-2021, 07:24 AM   #32
Tonus
Member
 
Registered: Jan 2007
Location: Paris, France
Distribution: Slackware-current
Posts: 923
Blog Entries: 3

Rep: Reputation: 250Reputation: 250Reputation: 250
My favorite would be 5.10 in main tree, last stable in testing or extra.
Or last stable in main tree and LTS in extra.

Would cover all cases. With some extra work maintaining both.
 
Old 05-13-2021, 12:05 PM   #33
cynwulf
Senior Member
 
Registered: Apr 2005
Location: Walsall, UK
Posts: 2,631
Blog Entries: 7

Rep: Reputation: 2150Reputation: 2150Reputation: 2150Reputation: 2150Reputation: 2150Reputation: 2150Reputation: 2150Reputation: 2150Reputation: 2150Reputation: 2150Reputation: 2150
LucyCyborg is actually quite correct. LTS is mainly targeted at enterprise server. I can't see any advantages in running an old kernel on a home desktop and losing the benefits of any advances and improvements made in, for example, the graphics stack.

Last edited by cynwulf; 05-13-2021 at 12:11 PM.
 
4 members found this post helpful.
Old 05-13-2021, 01:55 PM   #34
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 8,263

Rep: Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854
Quote:
Originally Posted by cynwulf View Post
LucyCyborg is actually quite correct. LTS is mainly targeted at enterprise server. I can't see any advantages in running an old kernel on a home desktop and losing the benefits of any advances and improvements made in, for example, the graphics stack.
This could be said for many pieces of software. Why not keep mesa, KDE, gstreamer, and more constantly up-to-date? You will also gain a lot of advances and improvements.

However, doing that introduces potential instability that might require extra effort to resolve. This is why not everyone is on -current. For many, those occasional times of instability introduced by new software is worth the advances and improvements offered by the newer software, but others are fine with the status quo and follow the "if it ain't broke, don't fix it" mentality.
 
3 members found this post helpful.
Old 05-13-2021, 02:07 PM   #35
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 1,370

Rep: Reputation: 1137Reputation: 1137Reputation: 1137Reputation: 1137Reputation: 1137Reputation: 1137Reputation: 1137Reputation: 1137Reputation: 1137
Quote:
Originally Posted by bassmadrigal View Post
This could be said for many pieces of software. Why not keep mesa, KDE, gstreamer, and more constantly up-to-date? You will also gain a lot of advances and improvements.

However, doing that introduces potential instability that might require extra effort to resolve. This is why not everyone is on -current. For many, those occasional times of instability introduced by new software is worth the advances and improvements offered by the newer software, but others are fine with the status quo and follow the "if it ain't broke, don't fix it" mentality.
There's still someone on Slackware 14.2 excluding a bunch of Gurus like you (who rebuilt half of system) and some businesses doing servers?

Isn't everybody else on -current, because this Slackware 14.2 is apparently so obsolete as hardware support?

YOU why do not use the stock kernel from Slackware 14.2, Comrade Bass?

Let me do a wild guess: because it's so old that it does not have support for your hardware?

And you still insist to sell a tool for enterprise servers to home users...

In my humble opinion, your beloved LTS kernels slowed down the Slackware development with at least two years, because many rookies jumped on -current, and our BDFL had to babysit them.

IF they had a modern kernel and a modern Mesa, and a modern graphics stack on Slackware 14.2, probably three quarters of them would have never jumped on -current.

Last edited by LuckyCyborg; 05-13-2021 at 02:14 PM.
 
2 members found this post helpful.
Old 05-13-2021, 02:34 PM   #36
cynwulf
Senior Member
 
Registered: Apr 2005
Location: Walsall, UK
Posts: 2,631
Blog Entries: 7

Rep: Reputation: 2150Reputation: 2150Reputation: 2150Reputation: 2150Reputation: 2150Reputation: 2150Reputation: 2150Reputation: 2150Reputation: 2150Reputation: 2150Reputation: 2150
Quote:
Originally Posted by bassmadrigal View Post
This could be said for many pieces of software. Why not keep mesa, KDE, gstreamer, and more constantly up-to-date? You will also gain a lot of advances and improvements.

However, doing that introduces potential instability that might require extra effort to resolve. This is why not everyone is on -current. For many, those occasional times of instability introduced by new software is worth the advances and improvements offered by the newer software, but others are fine with the status quo and follow the "if it ain't broke, don't fix it" mentality.
In my view there is a compromise. It lies somewhere between running an LTS kernel - which is designed around predictability and security - not introducing new hardware support, not even fixing bugs in existing drivers, but mainly in security patches - and the mainline kernel. The compromise is the stable kernel. And while running the stable kernel you have option of keeping the distribution's kernel around just in case.

There actually are cases where you might want to backport a more recent mesa and drm and possibly a DDX driver as well as installing a newer kernel- in order resolve issues for you specific hardware.
 
2 members found this post helpful.
Old 05-13-2021, 03:55 PM   #37
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 8,263

Rep: Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854
Quote:
Originally Posted by LuckyCyborg View Post
There's still someone on Slackware 14.2 excluding a bunch of Gurus like you (who rebuilt half of system) and some businesses doing servers?
Half the system? Try again. 4 packages... mesa, libdrm, llvm, and xf86-video-amdgpu (a few more if you want to include the kernel). But those 4 packages were just to add basic support for my newer GPU. I don't feel it is worth it *for me* to jump on the -current train for whatever benefits are included with even newer versions. It works, so I leave it alone.

Quote:
Originally Posted by LuckyCyborg View Post
Isn't everybody else on -current, because this Slackware 14.2 is apparently so obsolete as hardware support?
Yes, there are a lot of people on -current. It doesn't make my statement invalid. There are still people on 14.2 (and some on earlier versions of Slackware). We still see posts from people on the forum using 14.2 and I have several friends that are using 14.2.

Quote:
Originally Posted by LuckyCyborg View Post
YOU why do not use the stock kernel from Slackware 14.2, Comrade Bass?

Let me do a wild guess: because it's so old that it does not have support for your hardware?
As I said previously, my system will function fine with the 4.13 kernel. It is obviously a newer kernel than 4.4.x. I don't understand why you think this is some gotcha. I've repeatedly stated that sometimes people need to upgrade kernels for hardware support. That doesn't automatically mean they want to track kernel development and run the latest kernel for the rest of their life.

I kept upgrading the kernel on my main computer in the hopes that I could remove the rcu_nocbs=0-15 option from my kernel appends (but I still need it -- my motherboard doesn't offer any further updates as long as I use my current processor). I haven't noticed any other performance improvements over my course of upgrading the kernel (I'm currently on 5.10.x).

My htpc has remained untouched since I installed it (May 2019). I decided to use -current because the kodi version I wanted to run required newer libraries and my APU wasn't easily supported in 14.2. slackpkg has never been ran on the system. After installing the system, I installed the dependencies I wanted for kodi, then kodi itself. I did one version bump of kodi back in Feb 2020, and that's my last entry in the package database. I know that there are security issues with some of the software in the system, but I'm willing to accept those to ensure my kodi stays working. If I were to follow -current, every time an update breaks kodi, then I'll be frustrated at not being able to use my htpc while I recompile some or all of those dependencies. The box exists for 1 reason and only 1 reason... to be an htpc. If it can't do that because of a version bump of some package in -current, then it is not doing what I built it for.

Quote:
Originally Posted by LuckyCyborg View Post
And you still insist to sell a tool for enterprise servers to home users...
I'm not trying to sell you on using LTS kernels or a stable release of Slackware. I'm trying to make you aware of why some might want LTS kernels or stable releases. For others, there's -current. Both are valid and there's nothing wrong with you using your computer however you want to use your computer.

Quote:
Originally Posted by LuckyCyborg View Post
In my humble opinion, your beloved LTS kernels slowed down the Slackware development with at least two years, because many rookies jumped on -current, and our BDFL had to babysit them.

IF they had a modern kernel and a modern Mesa, and a modern graphics stack on Slackware 14.2, probably three quarters of them would have never jumped on -current.
Leave the modern stuff to -current. Leave the versions in stable releases "frozen" and upgrade when security issues or bugs dictate. This is exactly how the kernel is developed, so it's not like Slackware is doing some new concept. Once a kernel is released, it is feature frozen and typically only gets security/bug fixes. Sounds pretty similar to how Pat does Slackware releases, right? Should Slackware have released a 14.3 with updated hardware support? Looking back, probably, but I don't suspect Pat thought that the 15.0 release would've taken this long. He might've always felt he was only about 6 months away from a release, but continually had things that pushed that release out.

As a user, you choose what works best for you. I'm not trying to dictate how you run your computer. You can continue to use -current and update kernels, mesa, or any other software that tickles your fancy. I just am hoping you can understand why not all users want to do all that. I do not have time to manage a -current system. I don't have time to constantly update my kernel. I'll stick with whatever kernel I have running in my system until I need to reboot my machine. Then I'll update it (so I can somewhat keep up with security and bug fixes in the kernel version I'm using).

Quote:
Originally Posted by cynwulf View Post
In my view there is a compromise. It lies somewhere between running an LTS kernel - which is designed around predictability and security - not introducing new hardware support, not even fixing bugs in existing drivers, but mainly in security patches - and the mainline kernel. The compromise is the stable kernel. And while running the stable kernel you have option of keeping the distribution's kernel around just in case.
Not everyone wants to manage their kernel. I used to have a lot more time on my hands and I would build custom kernels all the time. I'd use RC kernels and tweak the .config heavily. I don't have the time for that anymore. I want to just use my computer and not think about what version of software I'm running on the machine. I've ran into very few issues with running 14.2, even now, almost 5 years after release. A lot of that is because I simply use software that is on SBo, so it might be out of date, but works fine with 14.2. Most of that software, I don't care if I'm running the latest version as long as the version I'm using works for what I need it for. There are a few packages on SBo that I was unable to update due to outdated libraries, but I didn't notice any new features that I felt was worthwhile to upgrade to -current.

Quote:
Originally Posted by cynwulf View Post
There actually are cases where you might want to backport a more recent mesa and drm and possibly a DDX driver as well as installing a newer kernel- in order resolve issues for you specific hardware.
I'm sure there are benefits of newer mesa or drm versions for my video card. However, I'm not aware of any issues with my current setup, so I feel no need to try and fix it... I'm definitely a follower of "if it ain't broke, don't fix it". And if I'm not aware of anything broken, then I'm not going to go out of my way to try and get some potential improvements. The improvements might not even be noticeable by me (which has been the case with the kernel).

Last edited by bassmadrigal; 05-13-2021 at 03:57 PM.
 
5 members found this post helpful.
Old 05-13-2021, 05:52 PM   #38
Jan K.
Member
 
Registered: Apr 2019
Location: Esbjerg
Distribution: slackware...
Posts: 258

Rep: Reputation: 176Reputation: 176
Red face Upcoming SlackWare 15 releases...

Slackware 15 Server Edition

Slackware 15 Work Station


There!
 
1 members found this post helpful.
Old 05-13-2021, 07:13 PM   #39
igadoter
Senior Member
 
Registered: Sep 2006
Location: wroclaw, poland
Distribution: many, primary Slackware
Posts: 2,238
Blog Entries: 1

Rep: Reputation: Disabled
I felt easier reading title but it does not change my (unjustified) opinion that 5.10.x is bad. Just call it superstitions.
 
2 members found this post helpful.
Old 05-13-2021, 11:28 PM   #40
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 8,263

Rep: Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854
Quote:
Originally Posted by Jan K. View Post
Slackware 15 Server Edition

Slackware 15 Work Station


There!
Please no! Just Slackware 15.0 and Slackware64 15.0 please

Quote:
Originally Posted by igadoter View Post
I felt easier reading title but it does not change my (unjustified) opinion that 5.10.x is bad. Just call it superstitions.
It was a rough start of a kernel, but so was 4.14 and it turned into a fine LTS release. However, luckily Pat is also including the latest stable kernel release in testing/ so those that don't want to run 5.10.x can run something else without needing to roll their own kernel.
 
Old 05-14-2021, 06:58 AM   #41
GazL
LQ Veteran
 
Registered: May 2008
Posts: 5,923

Rep: Reputation: 3899Reputation: 3899Reputation: 3899Reputation: 3899Reputation: 3899Reputation: 3899Reputation: 3899Reputation: 3899Reputation: 3899Reputation: 3899Reputation: 3899
Quote:
Originally Posted by bassmadrigal View Post
However, doing that introduces potential instability that might require extra effort to resolve.
Staying on a back-level stable kernel branch doesn't protect you from instability, it only protects you from a change in interfaces. Bad patches taken from release-candidates end up in older stable branches all the time.

What I've started doing is holding back on any stable branch releases made during the early mainline-RC stages that follow the merge-window.

I'll be sitting on 5.12.2 until things settle.
 
3 members found this post helpful.
Old 05-14-2021, 07:16 AM   #42
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 8,263

Rep: Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854Reputation: 5854
Quote:
Originally Posted by GazL View Post
Staying on a back-level stable kernel branch doesn't protect you from instability, it only protects you from a change in interfaces.
This is the stability I'm expecting by staying with the status quo. It's why I don't track -current. I don't want to deal with changing ABIs that sometimes require recompiling my 3rd party programs. If I was retired, I'd probably enjoy it, but I just don't have the time needed to manage the occasional broken package.

This is also why it is good for Slackware to provide an LTS kernel with its releases so that Pat can provide updates without worrying that some new feature in the kernel is going to break userspace (kernel devs are good, but not perfect). If users want newer kernels, all the tools are there to build them (and now that Pat is tracking the latest stable in testing/, you don't even need to worry about building your own .config).

My comments were spurred off LuckyCyborg's assertion that LTS kernels are obsolete. I think we can safely say that it is not true. It might be obsolete for some users, but certainly not industry wide.
 
1 members found this post helpful.
Old 05-14-2021, 07:30 AM   #43
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 1,370

Rep: Reputation: 1137Reputation: 1137Reputation: 1137Reputation: 1137Reputation: 1137Reputation: 1137Reputation: 1137Reputation: 1137Reputation: 1137
Quote:
Originally Posted by bassmadrigal View Post
This is the stability I'm expecting by staying with the status quo. It's why I don't track -current. I don't want to deal with changing ABIs that sometimes require recompiling my 3rd party programs. If I was retired, I'd probably enjoy it, but I just don't have the time needed to manage the occasional broken package.

This is also why it is good for Slackware to provide an LTS kernel with its releases so that Pat can provide updates without worrying that some new feature in the kernel is going to break userspace (kernel devs are good, but not perfect). If users want newer kernels, all the tools are there to build them (and now that Pat is tracking the latest stable in testing/, you don't even need to worry about building your own .config).

My comments were spurred off LuckyCyborg's assertion that LTS kernels are obsolete. I think we can safely say that it is not true. It might be obsolete for some users, but certainly not industry wide.
About what userspace breaks you talk?

The life experiences demonstrated that NO userspace will be broken even after those whooping 5 (FIVE!) years of Slackware 14.2.

There are peoples who runs the latest kernel 5.12.x on Slackware 14.2 without problems, and the kernel thread is full of them.

What will break often would be proprietary kernel drivers, like are the ones given by The Blob.

So, because those of The Blob worshipers, we should use everybody kernels made for enterprise servers?

How about instead our BDFL to give them a LTS kernel on /extra and to leave the rest of us to use always the best kernels available?
 
2 members found this post helpful.
Old 05-14-2021, 07:39 AM   #44
igadoter
Senior Member
 
Registered: Sep 2006
Location: wroclaw, poland
Distribution: many, primary Slackware
Posts: 2,238
Blog Entries: 1

Rep: Reputation: Disabled
Quote:
Originally Posted by LuckyCyborg View Post
How about instead our BDFL to give them a LTS kernel on /extra and to leave the rest of us to use always the best kernels available?
How we are to find which is the best kernel available? Should I test several kernel versions on my computer and pick the best one? Really not many are interested in fiddling with kernels.
 
2 members found this post helpful.
Old 05-14-2021, 07:50 AM   #45
GazL
LQ Veteran
 
Registered: May 2008
Posts: 5,923

Rep: Reputation: 3899Reputation: 3899Reputation: 3899Reputation: 3899Reputation: 3899Reputation: 3899Reputation: 3899Reputation: 3899Reputation: 3899Reputation: 3899Reputation: 3899
IMO it makes more sense to have the LTS in the maintree and glibc built against it, with the newest branch be the option. It just seems cleaner that way.
 
2 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: The LTS Linux Kernel 5.10 To Be Maintained For Only 2 Years If Companies Donít Help Support It LXer Syndicated Linux News 0 01-30-2021 08:26 PM
LXer: Upcoming Linux 5.10 release will love you longterm, pushing support out to 2026 LXer Syndicated Linux News 0 10-28-2020 01:30 AM
[SOLVED] How do I analyse a kernel segfault sh[2026] error ? bugrake Linux - Server 3 12-21-2014 12:31 AM
ERROR 2026 (HY000): SSL connection error: SSL_CTX_set_default_verify_paths failed prw8864 Linux - Software 1 11-15-2014 09:24 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 06:09 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration