Hey Everybody -
Recent threads asking crazy questions like "Is Slackware Dying?" remind me, among other things, that all of us are infected with the New==Improved Disease to one degree or another. I've spent many hours playing with Rolling Releases like Arch trying to grasp how any up-to-the-hour Distro benefits me, or anyone for that matter. My take on that is that other than minor security issues and hardware support what once was assembled as a coordinated working system should still do what it always did before - function. I am utterly confidant that if I were to attempt to install, say, Slackware v12.2 on the same hardware that used to run it, it would work just as before with only a few likely exceptions like possibly web browsers.

Ok I get it that some, maybe most, software developers need current resources so their stuff runs on the most current systems since while backward compatibility is common, there's no way to be forwardly compatible but for most Desktop Users I have to ponder just how much new stuff do we do that we haven't been doing for years? So I began wondering if it was possible to use the model for upgrading a Slackware system (gcc and glibs first) and then ultimately substituting a newer Huge Kernel to effect an install on newer hardware? Couldn't we, at least, theoretically, effect updates on an earlier ISO image and have a fully functional modernized take on an old version? and what might we sacrifice if we did?

Anyway, like the Subject Line says, this is just idle curiosity since I am looking forward to Slackware v15 but I'm still really happy with 14.2 and it took me a very long time to upgrade from 14.0 (I totally skipped 14.1) so besides considering if such reworks are possible, I'm curious as to what members here feel are updates they actually need beyond "that new car smell".

Thread Update --- IT WORKS !

As someone who only updates for security purposes, and only then if they are official (from PV or Eric) or for Slackbuilds if severe/serious reasons, I find this very intriguing.

1 members found this post helpful.

As for updates being required...

Back in the day, there was better support for various pieces of hardware with newer kernels.

In the current day, you could argue that the various changes made in open source software are done so to incorporate changes that make said software more efficient or more stable or "more better".

As for why I look forward to them...

In my Day Job (TM), I'm a software weasel. I like this shit, even after learning FORTRAN 42 years ago. ALGOL (No, really!) 41 years ago. Pascal 40 years ago. (This is getting depressing, actually.) A new integrated kernel with supporting software is a new toy to play with.

As for why this releases are important...

Pat used to get money from subscribers like me when a new release came out.

FWIW, I'd be happy with a model that provides $$ between releases (since he is always providing updates) along with a bonus for a release.

EDIT: @ChuangTzu rarely updates. I update my Slackbuilds repo every weekend (rebuilding stuff as I write this on my build box). I'll also run slackpkg update a couple of times a week. Different strokes, etc.

Interesting. I, too, enjoy playing around with new stuff but a recent test run with a fresh 14.2 install with Trinity in place of Plasma reminded me I wouldn't miss very much with good ol' KDE v3x. As for Slackware income I wouldn't be at all unhappy to pay a yearly subscription fee. I wasn't unhappy to pay $0.10 a day and $0.25 on Sundays for newspapers back in the day and while "updated" daily, they were also mostly discarded daily. I have donated but it hasn't been regularly and I should implement that right away, as possibly should we all. I could survive without Slackware but I wouldn't like it at all. I know. I've tested dozens quite thoroughly and I always end up trying to make them be Slackware.

As anyone might guess I am perfectly happy with Slackware's release schedule. My only complaints have been very recent with certain "options" becoming hard "requirements".

PS: I do typically upgrade/fresh install for new Slackware point releases.

1 members found this post helpful.

I noticed this several years ago trying to keep 1990s hardware functional. Outside the web browser I had no problem keeping the old hardware going. Those damned web browsers killed any enthusiasm for such a project, especially when often the older hardware is limited to the amount of RAM that can be installed. The modern web site is seriously bloated, which means bloated web browsers.

For me, not a lot. I use the same software as I did five years ago. I am content being boring with respect to my computers.

I think a big speed bump is the hardware. The last I tried updating Slackware on those 1990 vintage systems was with 14.1 32-bit. With 14.1 the systems feel and act old. Sluggish. At one time I had 12.2 32-bit installed. That might have been the sweet spot for such old hardware, with last hurrah of KDE 3. Then again, perhaps 11.0 was the sugar daddy with the 2.4 kernel.

For me, not much. On my "production" systems I much prefer to leave things be. For example, I still run an old version of XBMC on the living room media player rather than the latest and probably not the greatest Kodi. Also an old version of Trinity Amarok. I treat that system as an appliance. Mostly I don't update that system beyond security patches because of the pain caused by moving to newer versions, which almost always means breakage in some form. Familiarity breeds contempt I suppose.

That said, occasionally I wander off to look at new toys. I do that on test systems though. I really loathe disrupting my daily work horses. I am the same way at work, sticking with LTS releases. Seems to me that even with LTS releases there is a regular amount of breakage. Computers are just too complex these days and one little change in a single package easily can have a ripple effect.

How often do I update Slackware (14.2 64-bit)? Other than the security and bug fix patches from Pat, seldom. Just today the slackbuilds.org change log came through on my RSS feeds. Just now I realized I clicked right through and paid no mind. Glancing at my local repo I see I updated only five slackbuilds.org packages since spring.

Sounds as though I might be more than content with Pat's "release when ready" development cycle.

1 members found this post helpful.

For me it's probably just the kernel, if you want example; using an official 4.4 kernel cost me 512M VRAM because of the driver bug, while in 4.14 the driver provides additional 512M VRAM.
So I guess you could say that I need that RAM, enough to deviate from official stable kernel. But I don't really need upgrades for the sake of upgrades, like rolling release systems and such.

That said, I package lots of stuff on 14.2 sometimes even 20-30 packages per week, sometimes from -current sources, sometimes upstream from svn/git.
Because I lack the time to keep up with -current, but I must personally test all the packages I depend on, it's better to test now than wait for point release.
So when it's time to upgrade stable systems (and there's 4 now under my watch) I'd just script and automate the migration, knowing I already had tested all the new stuff and it'll work fine.
Guess I don't exactly 'need' to upgrade packages at all, but am definitely better off testing them asap so that migration doesn't make a mess of all my plans later.

Caveat: sorry if this post is off-topic.

Speaking as distribution maintainer (and a beginner at that):

• Providing newer kernels for a "stable" release is something that I consider, not only to support newer hardware, but also because some fixes are not backported. As an example, I had to tell a blind Slint user how to upgrade to 2.4.19.x (kernel shipped in current) because otherwise he couldn't make his Apollo hard synthesizer work, although it be a very old device.
• I also consider providing a few new software not waiting for a distribution release, if requested, on a case by case basis.
• I also make occasional upgrades, if that doesn't imply upgrading dependencies that could put other software at risk. As an example, I refrain to update Mate from 1.18 to 1.20 because that'd need to upgrade Glib and GTK3, which I can't afford to take the risk. On the other hand I do upgrade Mate components individually if at the same major version, usually to fix bugs.

1 members found this post helpful.

Thanks to everyone so far. I find each post interesting and possibly noteworthy. FWIW I am not talking about trying to get by with old hardware, although I have a few boxen that fit that description. Very soon after any point release I custom build a new kernel. Within days of installing 14.2 MultiLib I built a 4.15.0 kernel that served me well until just a month ago when a new nVidia driver would not build. A simple "make oldconfig" et al had me on 4.16.18 in about an hour and everything is hunky dorey.

I'm specifically wondering about how to update to a newer kernel in the install image of older releases. I'm pretty sure gcc, glibs and pkgtools would have to be included in that process but I haven't gotten far enough along yet to suss out any other important changes.

Oh and just FTR I did LOVE 12.2 and 13.37 was quite snappy as well. I still have 2 boxen each running one instance of those releases but they don't feel at all sluggish to me but then I build all my PCs from carefully chosen components.

1 members found this post helpful.

I had a subscription, but, cancelled it when I learned that Pat was not receiving money from the Slackware Store.

Indeed. My model entails annual donations to Pat's paypal account along with a payment for each stable release.

For the most part, I am perfectly content leaving software versions where they're at. I don't remember any issues that I've run into due to the versions they're at in 14.2... except for video. Mesa is moving at breakneck speeds and my 14.2 system is missing some nice improvements with mesa and the kernel (although, I am running a 4.18.x kernel and intend to move 4.19.x once I decide to reboot my server). Especially with the AMDGPU DC code that was added in 4.15 and the corresponding changes in mesa.

I suppose those changes weren't as big for those who use intel and nvidia cards... and I haven't kept up with the changes for those cards.

If what you mean is replace the kernel in the installer itself (not the to be installed kernel):

lftp -c "mirror http://slackware.uk/slackware/slackw...rce/installer/ && cd installer"
Then have a look at build-installer.SlackBuild. I think that you just need to properly set SLACKROOT as the root of a local Slackware tree for 14.2 but replacing there the kernel, kernel-modules and kernel-firmware by those you want to include. No other change should be needed, I think.

Caveat: I didn't try yet to rebuild the installer from source (but that's in my TODO list).

If instead you mean the installed kernels, then you'd better to ship among the packages the glibc that was used to compile this kernel and the kernel headers at the same version, I think (but please more knowledgeable people confirm or infirm).

My every-day-use laptop (Lenovo T530) is running 14.1, as are most of my other systems. Mostly it's been fine.

Two things that have not been fine: (1) mplayer and xine are missing codecs for a lot of modern content, and (2) Pale Moon 28 needs 14.2 at least.

Neither of these are pressing. I don't watch many movies on my laptop, and I did upgrade my office workstation to 14.2 and installed PM 28.0.1 on it, but didn't find it compellingly better than PM 27.

That having been said, I have been updating my 14.1 systems with the 4.4.x kernels from 14.2, and have had very good experiences with them.

I know from experience that eventually a Slackware release will cease to be viable. By the time I upgraded from 13.1 to 14.1, a wide variety of third-party software was failing to build. It will eventually be so for 14.1, too.

I've installed 14.2 on a few systems now, and it's been fine, but I will likely wait for 15.0 to be released before considering upgrading my world from 14.1. If 15.0 seems good, I'll transition all of my 14.1 systems to 15.0. If it does not, I'll either wait for 15.1 or upgrade to 14.2, depending.

Ah, OK. I haven't manually updated kernels in a few years. I update kernels only when Pat pushes an update.

If I understand your point, I do struggle somewhat with stale versions of some software. Just yesterday I got tired of the broken clipboard in Remmina and I updated to a newer release, but that required installing or rebuilding five SBo packages. Somewhat a PITA and I still need to test.

I struggle with this at work too. There is a new feature in SSH that supports multiple user SSH config files using a new Include directive. The LTS versions at work support older versions of SSH and trying to maintain a new version of SSH is a bugger. So stuck at the older version and contemplating work-arounds.

If there is one thing true about all software, something is always broken somewhere for somebody.

2 members found this post helpful.

Well said. And some things aren't broken but can (and do) get a whole lot better.