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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Perhaps. We don't know what Pat is thinking. The kernel numbering system is rather arbitrary anyway. Pat will pick a well-supported kernel for 15.0.
Interesting times ahead.
For all of you who don't want to put in the effort of keeping your -current install up to date, you do have the option of just installing it and not applying updates (ever, or only once a month, or once a year, or whatever you're comfortable with).
This is pretty much my mindset as well. In the last 3 years I used 14.2 for the first year and switched to current for the last two years. I've gotten pretty lax about updating current and have gone over 4 months at the longest between updates. The only issues I've had with Pats current have been my own fault when I forgot to update my initrd and did a reboot. The other debugging I've had to do is with Plasma 5 but it's been running pretty stable for the last year or so.
Of course the one caveat is that I don't have too many SBo packages or self packaged software and none that have extensive dependency lists. Most of the updating I do outside of current is via slackpkgplus with alienBOB's repositories and I'm grateful for the work he puts into maintaining software. If you use more third party software then I understand the reservations with tracking current.
It's a matter of using a LTS kernel release. 4.19.x will fall out of support too soon to be suitable for Slackware 15.0, so Slackware 15.0 will need to be based on a more recent LTS kernel, but there isn't one yet, per https://www.kernel.org/
No, not larger than from 4.14 to 4.19, which has already happened in -current (on Oct 23 2018). But I do not expect 5.3 to be more stable then say 5.1 or so, especially in the first year, to look at the number of patches 4.14 and even 4.9 are still getting.
The kernel for 14.2, 4.4.x seems to stabilizing a bit more now, but still already has a lot more patches then say the 3.x ones (3.18 ended up at .109, 3.16 is still being maintained, but is only at .69).
So waiting FOR 5.3 would probably postpone Slackware 15's release to at least 2020, for that kernel to stabilize a bit more.
So waiting FOR 5.3 would probably postpone Slackware 15's release to at least 2020, for that kernel to stabilize a bit more.
I think a lot of these patches are due to Spectre/Meltdown/etc. We are at an unprecedented place in regards to security with computer hardware.
But then I'm not a kernel developer and don't know how many of the patches are for stabilization/bug fixes vs mitigation for new security issues with processors.
That being said, 4.19 is scheduled to be EOL by DEC 2020, which is 1.5 years away. This would limit the length of time Pat can provide kernel security updates for the next release. (I don't understand why the kernel devs gave back-to-back kernel releases 6 years of support... they really should spread that out to every other or every third release.)
I don't understand why the kernel devs gave back-to-back kernel releases 6 years of support...
I do not know which releases you mean.
Lately they've made every 5th a LTS one (4.4, 4.9, 4.14 and 4.19) so the next one should normally be (what would have been) 4.24, which will now be versioned as 5.3, seeing that 5.0 could have been 4.21.
In the 2.6 era the LTS ones were much closer together:
Code:
Index of /pub/linux/kernel/v2.6/longterm/
v2.6.27/ 18-Mar-2012 15:17
v2.6.32/ 12-Mar-2016 16:10
v2.6.33/ 15-Dec-2011 00:18
v2.6.34/ 11-Feb-2014 16:34
v2.6.35/ 14-Mar-2012 15:56
(from kernel.org)
Kernel 2.6.40 became 3.0 to flatten the version number scheme and then 3.20 became 4.0
There is no real significance in the .0 releases anymore, other that "the minor version became too large".
don't know how many of the patches are for stabilization/bug fixes
A lot of them are for newer hardware too, like all kinds of SSD's that aren't connected through S-ATA connections anymore. Hardware development is going very fast at the moment too, that's one of the reasons 14.2 now feels old, there's too much hardware out there that especially the installer doesn't support.
I'd sort of like to see a Slackware 14.3 release using the 4.19.x kernel series. If the 5.3.x kernel series is a LTS release and once it stabilizes (whatever that means), a fairly "quick-turn" Slackware 15.0 utilizing the 5.3.x kernel series could be released. Best of both worlds for me!
Of course, this ship belongs to and is being steered by PV and I defer to his expertise.
I do not know which releases you mean.
Lately they've made every 5th a LTS one (4.4, 4.9, 4.14 and 4.19) so the next one should normally be (what would have been) 4.24, which will now be versioned as 5.3, seeing that 5.0 could have been 4.21.
In the 2.6 era the LTS ones were much closer together:
Code:
Index of /pub/linux/kernel/v2.6/longterm/
v2.6.27/ 18-Mar-2012 15:17
v2.6.32/ 12-Mar-2016 16:10
v2.6.33/ 15-Dec-2011 00:18
v2.6.34/ 11-Feb-2014 16:34
v2.6.35/ 14-Mar-2012 15:56
(from kernel.org)
Kernel 2.6.40 became 3.0 to flatten the version number scheme and then 3.20 became 4.0
There is no real significance in the .0 releases anymore, other that "the minor version became too large".
I'm strictly talking about their extended LTS, which is for 6 years rather than the standard of 2 years. Almost all LTS kernels get around 2 years of updates, but the powers that be decided that the 4.4 and 4.9 kernels will get 6 years of support, so the 4.4 will be supported until 2022 and the 4.9 will be supported to 2023.
In my opinion, it would've been better to space the extended LTS support to every 2nd or 3rd kernel. That could've left the 4.4 until 2022 and then the 4.14 or 4.19 for much longer support times. Hopefully the new 5.x LTS will be extended support, but I've thought that for 4.14 and 4.19, so I won't hold my breath.
Last edited by bassmadrigal; 07-05-2019 at 02:36 PM.
the powers that be decided that the 4.4 and 4.9 kernels will get 6 years of support, so the 4.4 will be supported until 2022 and the 4.9 will be supported to 2023.
That could be because some major distro's LTS releases (NOT RHEL, they do their own kernel maintenance and do not even use LTS kernels, i.e. the latest RHEL 8 uses 4.18, which was already EOL at the time OF the release) are using those kernel versions.
I haven't tried to find out which ones, but in the past that has been the reason of extended longterm kernel support.
In the end it's Greg Kroah-Hartman's decision as it's mainly him supporting the LTS kernels and backporting new patches TO them.
Distribution: Slackware, Xubuntu, OpenBSD, elementary, Raspberry Pi OS, Puppy, TinyCore
Posts: 247
Rep:
Quote:
Originally Posted by ttk
For all of you who don't want to put in the effort of keeping your -current install up to date, you do have the option of just installing it and not applying updates (ever, or only once a month, or once a year, or whatever you're comfortable with).
Interesting. I've toyed with the idea of installing -current alongside 14.2 to get an idea of what's coming in 15.0, because, yeah, I'm excited about 15.0 coming. But I must not be a very demanding user, because 14.2 does everything I want Slackware to do, so installing -current has been of lower importance to me than other things like learning OpenBSD and dabbling in programming languages and SBCs. I can wait for when 15.0 is ready.
Besides -current being low priority for me, another thing holding me back from installing -current has been the admin burden I thought I would have to take on. But I update 14.2 when security fixes come out for the software I'm actually using, or 1x week, whichever comes first, but not when bugfixes or any other updates come out. So far, that has caused me no problems.
It hadn't occurred to me to update -current on the same basis. So on that suggestion, I checked how many days in May and June security fixes came: 14.2 had 8, -current had 10, some days with more than one security fix, but not all of those were for software I use.
While in -current many more *things* would update, amd each updating session would run longer, since I'm using Slackpkg+ (and Alien Bob's packages would also update), I doubt I would spend any more man-hours per year updating. I would spend a bit more time reading changelogs, and maybe generate new initrd's more often, but I would also probably get more choosy about when I ran updates.
The one thing I'm not sure about is the few Slackbuilds I have on 14.2. That might be a deal killer for using -current for now. I'm not experienced in compiling packages, so I would have to get proficient at that to get the same packages in -current, no? I would probably not keep both 14.2 (or 15.0) and -current on a machine long term.
The one thing I'm not sure about is the few Slackbuilds I have on 14.2. That might be a deal killer for using -current for now. I'm not experienced in compiling packages, so I would have to get proficient at that to get the same packages in -current, no? I would probably not keep both 14.2 (or 15.0) and -current on a machine long term.
TKS
What is it you need? I've got a few installed with current. Ponce has a repository of updated slackbuilds for current. (They are what the new archive will be.) There's also a lot of clever people here, if you're having problems, but do check Ponce's stickied thread first before building anything.
Lilypond and OBS are the two I built. OBS just had a lot of dependencies, while Lilypond did have an issue that's got a workaround. (I still don't know what the deal is with 2.8, but 2.9.13 is going to be the next stable release of lilypond. Does make sense that newer code works better on current than a source tree that's 4+ years old.)
Distribution: Slackware, Xubuntu, OpenBSD, elementary, Raspberry Pi OS, Puppy, TinyCore
Posts: 247
Rep:
Quote:
Originally Posted by garpu
What is it you need? I've got a few installed with current. Ponce has a repository of updated slackbuilds for current. (They are what the new archive will be.) There's also a lot of clever people here, if you're having problems, but do check Ponce's stickied thread first before building anything.
Lilypond and OBS are the two I built. OBS just had a lot of dependencies, while Lilypond did have an issue that's got a workaround. (I still don't know what the deal is with 2.8, but 2.9.13 is going to be the next stable release of lilypond. Does make sense that newer code works better on current than a source tree that's 4+ years old.)
garpu, thanks, I'd forgotten about Ponce's repo.
I use three slackbuilds, one of those being a dependency for another, and I just checked that all three are in Ponce's repo. I once installed another two, but don't use them anymore.
So with that Slackbuilds on -current question answered, -current is looking like a candidate for the next installation on my machine, if 15.0 doesn't come out first.
That could be because some major distro's LTS releases (NOT RHEL, they do their own kernel maintenance and do not even use LTS kernels, i.e. the latest RHEL 8 uses 4.18, which was already EOL at the time OF the release) are using those kernel versions.
I haven't tried to find out which ones, but in the past that has been the reason of extended longterm kernel support.
In the end it's Greg Kroah-Hartman's decision as it's mainly him supporting the LTS kernels and backporting new patches TO them.
When it was announced, it sounded like it was going to be all kernels from 4.4 and on, but nothing has been extended after 4.9.
EDIT: After doing a bit more searching, it sounds like they're waiting to see if people are actually using extended LTS releases. The below quote is directly from Greg Kroah-Hartman
Quote:
Normally I say I will support LTS releases for only 2 years, but if Google and Linaro and others give me the proper testing infrastructure and support, I am willing to support them for longer, ONLY IF people actually use the updated kernels in their devices. It is no good if I keep doing kernel updates and no one ever actually picks them up in their devices
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.