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.
Is it just me or the term LTS is somewhat losing its meaning when ever newer releases are failing ever shorter in their respectful lifetime expectancy?
For the kernel team "longterm" means: at least 2 years of updates and security patches.
Sometimes, because there is demand, it will be supported for longer (like the 4.4 kernel).
Greg Kroah-Hartman never used the term LTS for those releases.
And that some "longterm" releases are supported longer then others is nothing new:
even in the 2.6 era release 2.6.32 was maintained much longer (at least 2 years longer) then i.e. 2.6.35, which still was a longterm kernel:
Code:
from the directory /pub/linux/kernel/v2.6/longterm on kernel.org
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 -
you can see 2.6.34 was EOL 2 years before 2.6.32 with .31 and .35 even earlier, while 2.6.27 was maintained as long as .35
It was discussed a few pages back. It certainly raises some questions about what Pat will do for the 15.0 kernel. Two years is not long enough, and it's extremely doubtful that the Slackware team would maintain it themselves. Unless they focus more on -current.
Could Slackware use an Ubuntu LTS supported kernel? They are supported for 5 years.
Unless I'm missing a crucial point, would it really be such a big step to upgrade kernel major
versions even after a release has been done ?
I've been compiling kernels since I started slacking in the late nineties and I can't remember ever
having to go back to and older version because the newer would not work.
The linux kernel devs are very strict about not breaking userspace. Some of the options still present
in the configuration procedure (libc5 a.out support ...) became obsolete quite a while ago.
You're right, you can almost always upgrade your kernel on Slackware. I wouldn't go replacing the kernel-headers though, best to use the distro package for that unless you are going to recompile glibc and other parts of the system.
On an older distro (i.e. Slackware 14.2) you'd want to make sure that your system utilities are in order... e.g. e2fsprogs, udev etc. according to Documentation/Changes in the kernel source dir. I use slacwkare-current so I haven't checked that for 14.2.
I always use the latest stable from kernel.org done my way, currently Linux 5.3.1 on slackware-current, and if I couldn't, it would be the distro that would have to go. That's unlikely on Slackware, but I could see it being a potential problem on distros that use systemd. I've not personally had that problem though, not even on *buntu based distros.
I guess that's one of the really big issues I have with syst**d. Nothing is really easy anymore.
On Slackware you can try almost any radical kernel config and you probably will make it work anyway.
I guess that's one of the really big issues I have with syst**d. Nothing is really easy anymore.
On Slackware you can try almost any radical kernel config and you probably will make it work anyway.
Huh? Considering that the EUDEV used by Slackware is just that "systemd-udevd" chopped off from systemd, probably there are no essential differences between the kernel requirements from Slackware and whatever systemd based distribution. Of course, from this point of view, of interacting with the kernel.
So, let's do not infect also this honorable thread with anti-systemd venom...
Last edited by ZhaoLin1457; 09-26-2019 at 03:44 PM.
Is it just me or the term LTS is somewhat losing its meaning when ever newer releases are failing ever shorter in their respectful lifetime expectancy?
I, for one, never did expect any subsequent LTS release to EOL earlier than a previous.
LTS kernel releases have historically been active for about 2 years before hitting EOL. They came out with "extended LTS" 2 years ago and announced 4.4 would be supported for 6 years. When 4.9 came out, that also was blessed with the "extended LTS". When 4.14 was originally released, it only had 2 years of support, just like 4.19 and 5.4 show now, but it was later updated to 6 years of support (I never even noticed this happened).
So it is possible that the same will happen with 5.4. It may show that it will be supported for 2 years initially, but that may change further down the road.
From this article, LTS releases aren't guaranteed to be 6 year releases.
Quote:
Ryabitsev said: "Despite what various news sites out there may have told you, kernel 4.14 LTS is not planned to be supported for 6 years. Just because Greg Kroah-Hartman is doing it for 4.4 does not mean that all LTS kernels from now on are going to be maintained for that long."
I always use the latest stable from kernel.org done my way, currently Linux 5.3.1 on slackware-current [...]
This is my own practice, keeping the Slackware -current stock kernel updated and installed and running the latest stable as well. Latest stable is default...
Then, on the other hand, there is always the option of "micro releases":
The recent effort here on LQ to produce an initial root FS might be a foundation for future subreleases that would come in between major releases:
14.2.1: new 4.19 kernel, build the initial toolchain around it (glibc, gcc, headers) and if all "just works" (usually does) just ship it as update to the running systems (update for 14.2) while eventually rebuilding the whole tree for those chancing a clean install, while moving everything from /patches to the /slackware tree.
Emphasis on might as right now we both don't have an easy option and could use something not too complicated but if done the proper way.
Thanks everyone, your explanations confirm what I've seen in computing in general but wasn't sure if that applied to Linux. I have seen some small businesses still using DOS and I'm aware of some larger corporations still using XP. When the job one does changes only slightly and your hardware also rarely changes there is little value in major software "upgrades" and considerable cost.
Also I realize my use case blinds me a little to other's needs since I never use a stock kernel for longer than a day and kernels and graphics drivers are the few items I upgrade with regularity. Other than security patches or fulfilling some dependency I keep Slackware basically Full Install stock.
I mentioned recently that I'd like to play with the 5.3.x kernel and managed to get some time last weekend, compile and load 5.3.1 on a spare (old - 2008) Atom netbook test system running Slackware 14.2 x86. I didn't report this earlier because I wanted to keep it under observation and test a few things before posting my impressions.
I tested a few networking scenarios and did some ad-hoc performance/load benchmarks (routing & firewalling), multimedia (audio, webcam, DVB&SDR dongles), various USB external storage & NFS, and so far everything is working fine, no regression compared to stock. I'm happy with it and considering to build and use it also on my main Intel coreX x64 systems.
At least on this Atom system it loads faster than the stock 4.4.x - could be subjective or because I tuned it for the Atom CPU (stock is for Pentium-III/Celeron).
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,094
Original Poster
Rep:
The new 5.4 kernel has been delayed. Perhaps, it will be released today.
Quote:
Linux 5.4-rc1 didn't end up being released on Sunday night as is tradition but instead there were some last-minute critical patches that landed around the kernel's handling of the random number generator / entropy at boot-time......
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
