I installed current because of two closed source programs: Webex (needs newer glibc) and OB-Xd (same problem).

Without those programs I don't care. I am fine with 14.2. Webex seems broken. So I installed current only for my hobby (OB-Xd). Work (webex) is fine with chromium browser

Some web pages don't like the old firefox I use chromium-ungoogled or chromium, or google-chrome.

I use this script if I want newer firefox. In reality I used it for OLDER firefox for duolingo lessons, for debugging and to help a guy to enable java applets on old firefox.

My use cases are pretty run-of-mill...for browsing, IceCat, Brave & AlienBOB's Ungoogled Chromium get me by. Claws for downloading/storing emails. I've even installed Code::Blocks (off of Slackbuilds of course) recently to get me through a programming tutorial (fingers crossed). 4.4 kernel is patched/updated...looks like the last one was from last July...

My one pain point would be office-y type docs...Calligra just doesn't always cut it...might be time to try out LibreOffice too...better late than never!

So I'm good for the time being & very much looking forward to 15. I may even have to let you graybeards out there break it in a little more for me!

1 members found this post helpful.

I've been keeping an eye on the newer 4.4 series releases from kernel.org, and I can recall only one of the updates after 4.4.276 addressing a CVE--and that was for a blutooth issue.

Thanks for the clarification. A pox upon me for even implying that PV's 14.2 support could be less than world class! ;-)

That said, I'm relatively new to the Slack-train (2018) - can I/we assume that 14.2 support will end on the day that 15 appears?

1 members found this post helpful.

While I certainly can't speak for PV, I would seriously doubt that that would be how it goes down. After all, he's still providing updates for 14.0 and 14.1.

My hunch would be that when 15.0 goes official, a future EOL date for Slackware 14.x might also be announced--might. When that date might be would be anybody's guess...

Come to think of it, that could make for a good poll question/betting pool:My money would be on 365 days!

Depends, what kind of support do you expect? There's DIY support, works for some but not all.
According to changelogs, security patches are still shipped for 14.0 and above. Seen some users still hosting a 13.37, but there's plenty of work involved.
Did you mean Enterprise support, like rhel and similar? I don't think it's going to happen for free, but could be wrong.

The chest pounding and wailing that 15.0 is not released yet as "stable" is getting a bit tiresome. 14.2 is fine as-is, ships with a ton of software OOTB that just works. The SBo script repository is still useful, even if you have to update/patch a few scripts. Unless you have a particular piece of software updated for some critical security flaw (and not all of these are exploitable remotely), or some must-have killer feature or function, there is really no pressing need to upgrade anything. Is libreoffice 7.x really much better that 6.x? Did you upgrade the computer and so need newer hardware support? No?

In the "tech world" these past 40+ years the mantra has been NEW! NEW! NEW! DON'T BE LEFT BEHIND! GET IT NOW! FOMO! I MUST HAVE THE NEW VERSION! PEOPLE WILL LAUGH AT ME FOR BEING OLD! AARRGGHH!

EDIT: I switched to Current early 2020 for newer hardware support (AMDGPU, Mesa) and some library dependences. On 4 systems here it has been extremely stable with uptimes of weeks or longer, depending on whether I hop on a new kernel or not right away. At this point with RC2, I see no reason to not use Current.

2 members found this post helpful.

Yep, knowing now that 14.2 will most likely be supported (i.e. kernel/security patches) beyond 15's release makes me inclined to just...stay put & keep on learning.

I'm even ricing up my xfce desktop a bit but scurrying back to KDE for shelter when I break something (frequently).

Thanks for the helpful feedback...

1 members found this post helpful.

Before I switched all the way to -current,

I coped by:

1) compiling my own kernel to add hardware features missing from stock 14.2 kernel so it would run my now already rather old ideapad with these specs, using the inxi I just learned about from a recent thread:
Once I enabled new features for AMD graphics the ideapad worked under 14.2.

Compiling a kernel is not dark magic or all that difficult. It's basically a gigantic list of ingredients, and you check the ones you want in your recipe, and then build it, following Slackware's documentation!


2. When slackbuilds fail, or their source links are obsolete, I follow the link to the projects homepage, and find out from where to retrieve more recent source (usually some git source these days), and then I edit the slackbuild script and update the version to the new downloaded source, and try the slackbuild. Often it succeeds and that was all that was needed. Sometimes there's new features that must be added to the builds script and configured. Sometimes I just build it by hand, with ./configure , make, and make install. When I do this, though I first run ./configure --help to find out about all the available customizations, and I customize slackware stuff like --prefix=/usr and --sysconfdir=/etc and --libdir=/usr/lib64. I install it to a target directory and from that directory create a slackware package that can then be installed or removed with pkgtools.

More and more packages though are using other build systems, like cmake, or python, and the first few times, I have to ponder the new documentation and figure out how to do it. It always seems hard on the first time, and easy afterwards.

These days, I try to build scripts to do whatever I want to do, and then run the script. The script itself is like notes on what I did, so I can just go back to it and not have to figure out all the configuration options over again the next time I go to rebuilidng the same package for an updated version. I wish these days had come sooner: I spent many years compiling things by hand and relearning the same processes. Writing scripts to execute what you want to do is superior to manually running step after step. So now, if I follow some slackdocs tutorial, instead of entering the steps manually, I write all the steps into the script, and then run it... whew. It was like going from hiking to flying.

Peace.

3 members found this post helpful.

I'd like to second this part. Pat's kernel SlackBuild scripts make compiling your own kernel much less daunting than it might otherwise be. They work pretty flawlessly as is, and once one delves into the script itself, it becomes relatively easy to make any customizations.

Case in point: on -current, my proprietary nVidia drivers require the presence of a certain kernel module that is disabled by default in Slackware. Thus, if I want to keep this hardware running on modern (anything post-5.8) kernels, I'm compelled to compile a custom kernel every time.

I developed a kernel build-script--based largely on PV's original--that auto-modifies the stock kernel config to include the needed module, and can consecutively build the modified generic or huge versions, or both, plus the kernel-modules package, at the user's discretion.

As slac-in-the-box mentioned, Slackware has pretty thorough documentation on the procedure, as well.

1 members found this post helpful.

Do you mean as I understand that this driver is included in the source but not enabled in Slackware-current kernels config? Then, I suggest requesting it to be added in the thread Requests for -current so it benefit everyone using this hardware.

2 members found this post helpful.

How is it possible for kernel to be decompiled then?
It's engineered according to blueprint, not baked according to recipe.
Having a blueprint means one can unbuild ad rebuild it, while having a recipe does not mean one can uncook the chili.
Can't see how it's even relevant since the compiler's just logic and math rather than physics and chemistry.

That's it precisely.

I thought about doing so, but after considering it further, I decided that Pat is probably right to leave this module disabled. I'll explain.

These old nVidia-legacy kernel modules require access to the "native_write_cr4()" syscall, both at compile- and run-time. Pre-5.8 kernels apparently make this syscall available through multiple modules. (Never had a problem on 14.2.) Starting at 5.8, though, native_write_cr4() is exposed if and only if the kernel has been compiled withLKDTM = "Linux Kernel Dump Test Module" Its primary use is for intentionally provoking kernel crashes. (Mostly used by kernel devs themselves.) As such, enabling it when not necessary would be a security risk.

Seeing as how this hardware is so old that the total install-base world-wide probably measures only in the dozens, in my estimation, it would not be worth the risk to have this enabled by default.

Mind you, if PV decided to start including said module in stock Slackware kernels, I would gladly welcome it. Honestly, though, I feel it would be rather selfish of me to ask for this "dangerous" module to be enabled just so I could avoid compiling the kernel myself.

(Especially in light of the fact that this GPU was released over 15 years ago, and nVidia stopped providing updates for the driver circa 2017. nvidia-legacy304 at SBo.)

EDIT: Furthermore, the proprietary nVidia driver is incompatible with the xorg-server that comes with -current. Due to the incompatibility of legacy304 with the newer xorg ABI introduced in xorg-server 1.20, I had to downgrade xorg-server to 1.19. Neither Slackware 14.2 nor 15.0 use this version of xorg, so I'm compiling that myself, as well.

Therefore, anyone--like me--who dares to keep chugging along with this old-arse GPU is already taking on extra "responsibilities." In fact, working out the build script for the 1.19 version of xorg-server was much more of a challenge than simply changing one line in the kernel config to compile that!

EDIT #2: For the record, I have completed work on the xorg-server-legacy119 and updated nvidia-leagacy304 SlackBuild scripts. I plan to submit these to SBo as soon as submissions are re-opened. I've volunteered to take over as maintainer for legacy304 in order to, as you say, "benefit everyone using this hardware."

4 members found this post helpful.

One set of strategies I effectively use in regards to staying with 14.2 is to ...

• Keep 14.2 upgradepkg'd and installpkg'd with the latest respective security patches and kernel updates (see this year's Slackware Security Advisories
• Keep around and use Slackware 14.2's SBo's from the Slackbuilds.org 14.2 Repository that are useful and still build perfectly fine (note: took an unacceptably long time to build the ./libraries/webkitgtk SBo so gave up on other SBo's dependent upon that particular library )

While completely switching to a Slackware 15 RCx/-current might not suit FlinchX, this pair of alternate options might be okay for others...

• Install and use -current as a virtual machine guest within, for example, Oracle VirtualBox
• Install and use -current on top of Slackware 14.2 (can be managed with appropriate edits to the /boot folder and to LILO's /etc/lilo.conf if these two Slackware versions are the only two installed, see my previous similar LQ post on the topic )

On webkitgtk, maybe AlienBOB has a package available on its repo. It will save you lots of time with large packages.

https://slackware.uk/people/alien/slackbuilds/

If some SBo requires a large array of deps, you can always
try slackpkg-installing them first.
Having slackpkgplus+ and its repos are highly recommended.
I avoid the slackonly and slonly ones as they often conflict with SBo's.