Getting off the software upgrade treadmill
 

I've been doing some thinking over the past months regarding system stability, and I've come to agree with the general consensus that newer is not always better. I got off the hardware upgrade treadmill some time ago (that means that my venerable FX-8370 processor will be in service for the foreseeable future), and am now also getting off the software upgrade treadmill. This involves mainly three factors:

1. Kernel series (4.20, 5.x,etc.)
2. KDE Plasma 5
3. NVIDIA drivers

Kernel series

A new kernel series always involves the risk of breakage due to new ABIs, APIs, and the like being introduced. While I am all for progress, the 4.19.x series seems to agree with my system, and because it falls under the 6 years of support for LTS, it will be the mainstay kernel for my system until support for it ends in 2024.

EDIT: drmozes pointed me to the kernel.org page which states that 4.19 support will be ending in December of 2020, so it looks like I'll be making a decision as to what kernel series I'll be moving to much sooner than I expected. But for the next year and some-odd months, I'll be staying put with 4.19.

KDE Plasma 5

Monthly updates are all good and proper, but the version I run (5.14.5 with Qt 11.3) functions well enough for the way I work, and it's blazingly fast. As far as I can tell, updates mainly involve new features being added and some performance improvements. KDE loads fast enough for me not to worry about any incremental increases in performance, and I don't need any new features. So until I see something in future updates that warrants a systematic upgrade, 5.14.5 stays put.

NVIDIA driver revisions

I've done some searching regarding driver updates (I have a MSI GTX 1070), and it looks like to me that driver updates mainly involve fixes to games, maybe a fix for window managers or DEs, and the like. My driver revision (418.43) works well with Plasma 5.14.5, and I see no need to change what works.


Summary and conclusions

As I've gotten older, I've come to prize a system that just works every day. Now, computers can be finicky, and I am not under the illusion that system administration will now just become a breeze. There will still be challenges to be overcome; my goal is to eliminate some major factors in possible system instability.

The point of this post isn't to incite a flamewar or anything; I'm stating this for the record. I hope that maybe someone will see this and follow suit, but this is mainly for my benefit.

Slackware is of itself a stable and performance-oriented distro, mainly because it relies on the user to manually administrate the system, instead of trusting some remote entity to do that for them, entities that don't necessarily have the user's best interests in mind, and I wish to add to that stability.

The only updates I will be performing on my system are updates to -current (yes, I am aware that -current is not necessarily the most stable, but software is a living, changing organism, and keeping up with the latest updates will keep my system from encountering nasty surprises in the future, as evidenced by posts in this forum about people having issues relating to stale old releases of software, and -current in Slackware is far more stable than the stable releases of other distros, some of which are well-known and established), and of course, the updates to the 4.19.x kernel series.

Again, this is a post for anyone that wants their system stable, and would like examples of how other people are doing that.

Happy Slacking!

Projected EOL - Dec, 2020

https://www.kernel.org/category/releases.html

Thanks for pointing me to that page! I stand corrected! :)

Well, I've gotten older too. Having retired from work a few months ago, I have more time for keeping the system up to date - but also more time to question the point of it.

I think your reasoning is perfectly sound. For myself I'm thinking of taking it a bit further: when Slackware15 is launched I'll probably switch from -current to -stable. Might have to reconsider that, of course, but right now it feels as the right choice for me, considering my needs and expectations.

Of course security issues may be an argument for kernel upgrades, but I'll address that when it happens.

I hope that both you and I will enjoy many more years of happy slacking, and I wish the same to all those who choose to upgrade to the very latest (thus helping us Luddites by wiping out the bugs in the early versions).

At the moment I'm running 5 laptops/desktops with Slackware64-current; they're all running well. When 15 is released I will move 3 units to the -stable branch. I will keep 2 -current boxes. :)

I just updated a computer I had sitting around Dell 3541 AMD. I put a Crucial SSD 500GB + 8GB crucial ram. I have never been a fan of AMD, after installing Slackware 64 + Mled dual boot with Win 7, computer is pretty responsive. I'm straying away from the latest as well.

I'd like to try KDE 5, but I'm still waiting for it to land in -current (I know I could run ktown, but it's my work system and running -current is already far enough for me). Glad to hear it's stable and fast though!

There are many of us on stable because of the same desire.. to avoid the software upgrades every week and occasional breakage. I run stable because it is, well ...stable! Yes I run Window Maker because it works well and is ...stable. I don't chase the latest version of KDE or XFCE. I use practically no KDE or XFCE applications (maybe K3B, or Thunar/Dolphin occasionally). It fits my work flow.

Th second week of each month system administration involves,
1. check of kernel.org log to find security,Specter, reverts that affect my platform (x86_64) or hardware (ath9K) and USB improvements. This PC runs 4.19 - because PV configs are standard configs and his kernel releases are not Slackware specific. Also, GKH recommends "latest" long term release and it seems to implement updates as quickly as stable branch.
2. Running the Slackware updates ie. "slackpkg update, slackpkg install-new, slackpkg upgrade-all, slackpkg clean-system"
3. Running the slackbuilds updates ie. "sbocheck updates" and then determining if the newer version have security issues or simply features. I might upgrade for feature every six months.
4. I'll also check java release security, since I build it locally with PV provided slackbuild in /extra.
5. Last step is to run an archive backup to a second computer on the LAN so that a hardware failure can be recovered with minimal loss of data.
All this activity will result in maybe 4 hours of time, not counting the build time of some apps or kernel.

Twice a year there is a cleaning of the hardware from dust bunnies and inspection of capacitors(this is a fourteen year old PC and leaking bad caps happen).
Once a year there is a review of software being used. For example the developments in browser, browser extensions, OpenOffice, PDF viewer, email features, GNUCash functions, slackpkg+, and sbotools. I check if I'm really using the extra slackbuilds software or can it be uninstalled and save time with updating. Since my graphics card is a GEForce 8400GS, the Nouveau driver works without having to track NVIDIA releases, that would add time to kernel build.

This schedule works for me. Thought I'd share it. Cheers.

I haven't as yet reached that point (I have around 20 years of work to accomplish before that happens), but in the past, I've had the inclination to upgrade just because it was there. But the trade-off is that instability often rears its ugly head at the most unexpected times. I'm not of a mind to deal with that because it has been my experience that it happens at the most inconvenient of times.

Thanks. -stable sounds at first like it would be a good choice for stability, given Slackware's track record, but I've heard many reports of how upgrades to the latest version can go wrong when you've decided to give it a go. Software changes much too quickly for me to be comfortable with a -stable system. I'll deal with the possibility of breakage (seldom as it is) with -current, just to be able to have a seamlessly working system when the new -stable comes out.

Security updates usually are backported to the LTS kernels, so I'm not worried about that.

I wish the same. :)

I am in strong agreement with the concept of being very cautious and judicious about upgrades. Since it doesn't require "either/or" to try new kernels, I try those at my leisure with no need for hurry especially since I rarely keep the default kernel of a new release for more than a few days. I build my own.

WM/DEs I don't worry about hardly at all since I am comfortable with CLI, Fluxbox, WMaker, Xfce, Enlightenment and KDE with any version of KDE other than the early 4x releases being my "go to" Desktop.

As for graphics drivers I have used nothing but nVidia since around 1990 on many operating systems and always choose the proprietary NVIDIA-foo.run installer for Linux and the analog for other OpSys. The only exception was a 2 year stint with Matrox before the nVidia driver became available for OS/2. That said I have always also been a gamer and multimedia worker so performance is very important to me and I'm pretty deep into hardware and hardware tweaking on very low levels.

It has been my experience that most graphics manufacturers, and certainly nVidia, start with beta drivers that are heavily biased for maximum performance. This is probably to post big numbers for new releases, a useful sales tool. Over time the performance usually gets dialed back in favor of compliance and stability with run-of-the-mill gear, especially onboard I/O chipsets and RAM. Once enough time passes that a newer core paradigm is released, driver updates involve, let alone improve, previous revisions less and less. So I strongly concur on reaching a somewhat ideal state for a given "orchestra" of hardware and stopping right there and then only upgrading with hardware upgrades.

I install security and other patches whenever they land. That having been said, I'm still on Slackware 14.2. I did Arch for 6 months and ran screaming back to Slackware, since I was spending most of my time trying to get things working after weekly patches that broke everything else. (Plus, the old adage of too many cooks spoiling the broth works for linux distros--when you have so many people compiling things and patching things, things break in unexpected ways. Slackware doesn't patch much, and it's more stable as a result, IMO. A lot of people love Arch because it's on a rolling distro, and good for them. It was a headache for me.)

Video card drivers I keep updated, but because I game. Otherwise...I probably wouldn't.

I've had few problems (some of the few due to my use of the Nvidia drivers) by keeping a released version of Slackware to date with slackpkg. I'll check several times during the week and I'll re-run my slackrepo box every Friday night and/or Saturday to pick up changes.

If I used fewer slackbuilds.org packages, I'd probably use -current. (That's not a slam on slackbuilds.org, btw.)

Yeah current breaks things if you have a lot of stuff installed. Not good for the main Linux box. Found that out the hard way :)

I can totally relate to the desire to get off the treadmill. As long as an OS does everything I need it to do, I'll apply security fixes but otherwise just use it, not administer it.

That having been said, I'm starting to chafe a little under Slackware 14.1 (running on this laptop I'm typing this on). I've been learning to program in D, and the DMD compiler runs great on 14.2 but not 14.1. I've also been learning CUDA kernel programming, and I haven't gotten the CUDA toolchain to work under 14.1 either, but again it jfw on my workstation, which is running 14.2. Occasionally I run into a video file that can't be played on 14.1 (not with xine nor mplayer).

14.1 works great for everything else I do, and I've been updating its kernel from the 14.2 kernel packages to stay abreast of security fixes, so rather than upgrading my laptop from 14.1 to 14.2 I'm going to stick with it until 15.0 comes out, and upgrade then. The new extra/pure-alsa-system subsystem appeals to me, and once I upgrade to 15.0 I shouldn't have to upgrade again for another five years or so.

Now if browser technology would just settle down, and hardware vendors would stop putting side-channel vulns into their products, life would be golden.

Please Slackware current is not remotely comparable to arch, I've run arch too and its a full time job to fix things other maintainers broke...

Fair enough, sorry! I'm leery of things that update frequently. ;^)

upgrade only if there is a reason
 

I was always looking for an optimal balance between stability and new or, at least, not outdated software.
In the past, i used to jump from Debian Stable to Testing or to Sid, and everytime i had the feeling that something was not right. After a few years i had my Arch era. A ton of updates every week. Sometimes, a manual intervention was required. The lesson was that "the latest and the greatest" 1)is more a hype than a need and 2)does not equals maximum productivity.
Now, i believe that Slackware offers a great solution to the equation "stability and software upgrades". I can run for example a 4.14 kernel or a 4.19 kernel, (my desktop is two years old) combined with a "new" vivaldi browser, lyx editor, the latest rawtherapee, libreoffice etc on a rock solid Slackware 14.2 installation.
A few days go, i did a full upgrade to current (btw, current looks great). In any case, the decision is mine and with Slackware as a base, it is much easier to adjust my system and to "upgrade" a specific piece of software if i want to.

PS: Regarding kernels or kde (if i switch to plasma), OP's plan seems quit logical for me too.

I confess to a very strong resolution to move away from -current when 14.2 came out, for many of the reasons expressed in this thread. However my addiction to the excitement of -current meant that my 'strong resolution' did not last that long :).

I don't understand why you assume you must make a choice. Why not install both?

I hear Steppenwolf's The Pusher playing in the background. :D

That would be sensible: stable as day-to-day and -current on VM...

My system has an AMD FX-8350 and 16 GB DDR3 RAM. It gets the job done when I test my SlackBuilds and when I create my own repository with slackrepo. True, QT5 takes 4 hours to build on all 8 cores...

It works great for me, although I use multiple partitions / installs rather than VMs. For me, stability through redundancy is easier and safer than freezing a system.

Except for the kernel I run 14.2 exactly for your reasons. Stability. I do download and build new kernels, always keeping a known working one just in case of problems, because I do have quite a bit of new hardware, but otherwise running 14.2 with some Slackbuild and Alien packages here and there is reliable.

I ran Gentoo for a while but I found that in an attempt to be "helpful" Portage often tried to install or even worse remove packages that I didn't want installed or removed, and updates just got to be absurdly frequent. I am quite happy running Slack stable and knowing that there won't be any nasty surprises coming at me.

That encapsulates exactly the reason I do what I do with my computer: I trust no one to know what's best for my computer except yours truly. Slackware allows me to do just that.

Both hardware and software upgrade treadmills are past to me those days. I see my box - and the software within - just as a tool that MUST work whenever I have work to do (I'm a full stack developer/devop) because it brings the bucks I need to pay for my motorcycle trips. I don't like the idea to hit the road at late because I had to deal with a computer glitch.

My current box is a second hand Lenovo Thinkpad X250 (model 20CLS4Q600, mnf. date 2016/07) i5-5300U, iHD Graphics 5500, 12.5" Full HD IPS display, 8GB DDR3L-1600 SODIMM, 500GB 7200RPM HD and 256GB M2 NGFF 2242 SSD. The one before this was an Asus X450C i3-2365M which was replaced after seven years of honorable services. Thanks to Slackware, both are pretty capable during their lifespan.

Just like some of you, I also enjoy an up-to-date system. -current sometimes breaks things. Broken things makes me hit the road later than sooner, which you know... I'd rather avoid.

To stay -current and avoid risks of breaking things, first I've read all the recommendations here, then I did it many, many times by hand to understand every single step, then I automated some stuff with functions here and there... voilà.

My workflow is something like:

• Regular -current upgrades (kernels-generic and kernel-modules are blacklisted):
  
  
  Code:

  ---

  slackpkg update
slackpkg upgrade slackpkg
slackpkg new-config
yes n | slackpkg update
slackpkg upgrade glibc-solibs
init 3
slackpkg install ktown
slackpkg install-new
slackpkg upgrade ktown
slackpkg upgrade-all
slackpkg clean-system
slackpkg check-updates
slackpkg new-config
reboot

  ---

• Kernel upgrades: when a kernel upgrade is released in -current, the actual working kernel becomes the previous one, install the new kernel (which includes a mkinitrd for hardware support+LUKS+LVM), Then delete the old previous kernel (the one behind the actual working one that was the main kernel until now). That way I ALWAYS have at least two kernel versions installed: the just installed one (which I don't know it's going to work until reboot) and the actual one (which I know is working because I've booted with it). If things goes wrong while rebooting, lilo just let me select the previous kernel and that's it... system is back on duty.

Using this method, which is made possible only by my personal day to day experience and requirements, I'm able to keep my box in pretty good pace with -current and also keep it rock solid when more sensitive stuff arrives, such as kernel, glibc-solibs and other deal breakers.

Of course this is all done by a bunch of functions I wrote myself. So all that I actually have to do is to call them and monitor their output.I always have the chance to act accordingly if things goes wrong. Never had to do so...

This is exactly how I approach kernels, and for exactly the same reasons. Also, that's why I like LILO so much; it is flexible. I know grub has its own approach to this, but I like simplicity and a conf file that's easy to understand, and since I have no need of (U)EFI, this is the approach I've chosen for the foreseeable future.

I know this is a Slackware thread but the topic is valid for me right now. When I used Linux, I lived for updates: there was a thrill when I ran (typically Arch) updates and got something (daily). This comes at a price, as others have mentioned.

I now use FreeBSD and no longer use Linux. FreeBSD has a relatively slow update cycle, in the RELEASE branch anyway, and I have trained myself to only update every couple of weeks. This is a tad different than the Linux world because the core OS is updated separately from user installed software, and also with a completely different set of tools.

My point to all of this is I agree with the topic of this thread: updates are a treadmill. If security patches are taken care of and everything is working, no need to update, regardless of the OS you use.

You will like UEFI an elilo even better in that case. You get a simple conf file you can edit just as with LILO AND you don't have to change the write boot loader every time you change it. Literally just change the conf file and boot.

I used to boot with elilo in the retired box. It's very simple to manage indeed.

But the new box came with a windows 10 (handy to deal with proprietary GPS and corporate stuff) which I decided to keep so I can boot it as bare metal or inside a VM in the same HDD partition. elilo cannot chainload boot loaders. Also it does not support password protected boot options, which I use to boot windows 10 in bare metal mode, Slackware recovery and memtest images.

elilo is simple, just a bit too simple.

Here's another who has been searching for just over two and a half years in order to find that promised land of being satisfied with the arrangement of installations.

As a Linux Newbie in October '16, my first project was getting Slackware 14.2 installed as I wanted it with KDE4 and such applications as I needed for my other personal projects.

Once that was done after about a year, a fair bit of distro-hopping ensued to satisfy my need to learn about Linux and to find an installation combo that worked for me.

Next step was hooking it all together so that each distro could see and, when needed, communicate with the other using shared data repositories.

Once this was all completed it became time to just enjoy the fruits of my labour.

Once we have everything we need, it does become time to just stop and leave our Installations in peace.

Here there be Slackware 14.2, Debian 8.10 and Kubuntu 18.04 and they each do what's required of them.

So I quite understand the need to say "Enough Already". I'm too old to run with the latest thing wolf-pack like I did 30 years ago, so I have settled at last. Slackware 15 has a partition ready for when 15 arrives but I can wait now.

There are other projects I want to do but they will get done when I'm ready.

Never were there wiser words spoken. I have done exactly that, and have indeed enjoyed everything I have accomplished "that just works". :D

Just my :twocents:

I'm also old; I'll be 62 in August. :)
I've used Linux since 2002, and Slackware since 2004. I love Slackware a lot. Debian 10 will be released on July 6th, in one week. I may give that a go on one of my 5 Slackware64-current machines, or in a VM. Curiosity keeps me young. I love free open source software!

I will prolly have a look at it too. When there are 2 300GB Sata disks begging to be used, it'd be rude not to try it!!

I'm not far behind at 56, so I fully agree with the need to faff around all the time.

Keeps us less old.....

:hattip:

I have Debian Testing installed, which already identifies itself as Debian 10 (“buster”). So, in a way, I’m already giving it a go.
Though, to be honest, I haven’t used it much lately. I’m mostly running Slackware on this laptop.

Agreed in entirety.

Slackware users have it pretty good. Last Friday, a Fedora-using friend had a conniption on chat, which is relevant:

I was surprised and saddened, because Fedora used to be one of the better-tested distributions.

You would think he would be very happy with Slackware, because things JFW, but I've suggested it to him in the past and he discarded the notion out of hand. Said something snide about software from the 1990's.

I guess he'd rather have a super-modern desktop which literally drives him to despair.

You should recommend Windows to him! :D

Give me "software from the 1990s" which works over a super-modern desktop any day of the week, thank you very much! :D

I can certainly understand getting off the software upgrade treadmill. I recently spend two days rebuilding, upgrading, adding, removing 119 perl module packages because I was getting the infamous "loadable library and perl binaries are mismatched". I couldn't work it down to the offending packages so I just wipe perl and reinstalled. The satisfaction comes at the end. Missed a few Slackware64-current updates while working this, all caught up now.

Always look forward to elusive kernel updates. I jump with joy when I see a boost or icu4c bump in ChangeLog.txt as eggciting times are ahead. ;)

I remember when I was 62... I was still too afraid of Slackware to try it out.

Keeps me playing with computers :)

Here's my take on things. I'm a relative newcomer compared to some of the Slackers here on LQ; I've used Slackware for 15 years. As a Slacker I suffer from what I like to call the Tyranny of Perfection. That is, when I get my Slackware systems set-up they_just_work. Always. At the moment I'm running 5 Slackware64-current desktops and laptops. They all work flawlessly(there is very rare breakage in -current which is usually fixed in days).
So all of my computers work, and they continue to work without hiccups. It's maddening I tell you, maddening! :)
So then on occasion I will look around the vast open source ecosystem and see if I can find something better. Recently I've farted around with Arch on a bare metal install and also on VMs. I'll probably try out Debian 10 on Saturday. Invariably I find an annoyance with other operating systems. So I come home to Slackware after a brief affair. Acceptance. Slackware just works, man.

I am beginning to see Slackware people like latter-day JFK-types.

"We don't choose Slackware because it is easy, but because it is hard."

Just a random thought to coincide with the 50 year anniversary of Apollo 11.

:hattip:

Edit:

To respond to TTTK, my posting was only due to having watched a programme on Channel 4 (UK) on the 1969 Moon Launch of Apollo 11. I'm not drunk but just in the mood for a bit of a trip down memory lane.

You are absolutely right about the GUI prevalence today. I started with Z80 Assembly on the ZX Spectrum in 1982 and a year of SysAdmin of Xenix 386 in '91, Over the decades things have got more Holdy-handy but Text stuff is a bit harder for those of us having spent decades in a GUI environment because it's necessary for us to mentally step back in time.

TBH, it was just an excuse to mention 1969.

:twocents:

It might be more accurate to say that GUI-laden distributions make a few common tasks extremely easy, but everything else hard, sometimes prohibitively so.

Slackware's structural simplicity makes everything fairly easy, but not as easy as those other distributions' specifically-targeted use-cases.

"Easy" here is also relative to the user's comfort level with such things as configuration via text files. To those of us who have been using computers for a while, working with text files is familiar enough to be easier than using a GUI. To users who think of GUIs as the normal case, there's an additional psychological hurdle.

We are as shaped by our tools as our tools are shaped by us.

Vi! :cool:

100% agreed. As surprising as it can seem, using Slint in console mode is frightening even for blind users coming from Ubuntu, although from an ergonomic stand point you'd think that a graphical environment is a lot more difficult to use if you can only read the screen using a screen reader like Orca (or NVDA for Windows) as you then need to learn the hierarchy of objects, while there's a lot less commands to learn to just review the screen with a console screen reader like espeakup or fenrir.

RANT ON !!!

Oh it isn't just software. That's bad enough. What's really ridiculous is hardware changes for no good reason. Examples you say? OK. In all fairness I do see the huge benefit from so much of hardware going Serial as opposed to Parallel. SATA is vastly superior to PATA, even if it was slower (which it decidedly is not) but just for the cabling and drive recognition. PcieX is superior to PCI and AGP BUT did manufacturers really need to stick us with DVI connections? and some boards with no other outputs so one had to buy adapters. Isn't it odd that most modern graphics cards have the typical old reliable PC D-Connector and also HDMI with a few including Display Port? What purpose did DVI ever amount to? Now for the biggie.... Power Adaptors aka "Wall Warts"!!! AAAaaarrrggghhh!!! I don't dare throw any of them away just in case and as a resulkt I have a closet full including massive beasts like the one that powers an old US Robotics external modem, but I can't find good matches for any gear not constantly in use.

Now back to software. OK I do realize that traditional BIOS was getting too old and too small to handle all that is needed and just doubling again wasn't going to be enough for long. I also realize there are benefits to a dedicated boot managing partition but I can't help but wonder if MS didn't bulldoze "features" through that were beneficial to "the Windows Way" and screw everybody else. Did they really have to incorporate full color, wifi, disk access, and mouse drivers that STILL an OpSys must override and install it's own drivers? Is that good use of precious real estate? ... and UEFI... Hey GPT is a nice improvement over MBR in many ways so why oh why is simple booting so much more a pita?

A friend of mine deep in the security business has a great demonstration regarding so-called "firmware".. The very name implies immutability. Hogwash! It's just software and it is more vulnerable now than it ever was and it's freakin' everywhere.

Now for the very worst offender. Software power switches. When I push the button for a CD/DVD door to open I want it to open right now, not maybe in 30 seconds or if it thinks it's OK. If it's not OK I will deal with the consequences. PCs, Laptops, Phones, TVs all of these things have software switches and the software as well as the chips can and do routinely fail. I want a simple electro-mechanical switch that Powers Up or Down when I SAY SO, not if and when software says OK or some programmer coded in planned obsolescence.

The upshot of all this is loss of freedom and control and generations of kids who just expect someone else to make it work.

Gawd I'm getting old. :D

RANT OFF.....

(1) The really frightening part is how many of those kids see it as a feature and not a bug (and here I'm quoting my son).

(2) The reason grumpy old people are grumpy isn't that they're old, but that they've had to put up with so much bovine excrement along the way that the meter's off the scale... and then they get offered more. :banghead:



Edit: Which is why a working Slackware keeps me sane.

Although it would work even better if I didn't keep playing "What does this button do?" :)

My observation of other users unfamiliar with the command line is when I open a terminal window and start typing commands, the users slowly move away from me and become utterly silent. They are afraid that I might ask them do the same thing. To really scare them sometimes I think I should just wear a hoodie and sunglasses when opening a terminal window. :D

Yup, one of my temper triggers too. :)

Old is good! :D

I couldn't say that any better!

Speaking of updates. There's a new kernel in -current today. :)

The 44th so far during 2019...
On the other hand, only two of them have found their way into the Slackware Security advisories so I've skipped the other 42.