Hello:

As far as I know, it is enough to keep your system up to date.

In the last nine years, have seen intel-microcode packages updated once every blue moon, probably because my box runs on a legacy (EOL 03/2013) Intel Yorkfield (Core™2 Quad Q9550) processor.

The intel-microcode package is/has been there as part of the installation/upgrades from the start:

~$ apt list | grep installed | grep -i microcode
--- snip ---
intel-microcode/oldoldstable-security,now 3.20231114.1~deb10u1 amd64 [installed]
~$ 

And then there is what you can see here.
Microcode for Intel and amd64 CPUs all the way from up Jesse down to Ceres.

So any time a microcode package gets upgraded, it is made available for you in the Devuan repositories.

You would have to take intentional steps to keep your system apt from actually downloading and installing it.

I may be missing something in your particular case, but in my opinion, keeping your system up-to-date is not an option to consider.
It is something you do.

Best,

A.

Hello:

I think grub-customizer probably uses it.
But I have not used that application in more a good long while, when I had another HDD with another version to test.

That said, when/if upgrading, the idea is to clone the system drive, set the box to boot from the clone and only then do any upgrade.
Then, if there are no issues, make an image of that drive to restore back to the system drive.

As this is a BIOS boot (no UEFI stuff) box, any other OS boot issues generated by the OS-prober can be easily fixed there.

If I decide to continue with attempting this upgrade, the system drive will be fully updated and cleaned of left over cruft/orphans before cloning it.

Thanks for reminding me.
Seems it was up to date because during the experiment (see part II, link below) there were no warnings in the terminal printout.

And I accepted all the default options when given the choice.
Not sure that was a good thing as I once had a severe problem with the default Devuan MTA, Exim4 by doing just that.
ie: accept default suggestions when updating/upgrading. 

TL;DR: I removed/purged it and in its place installed a lightweight and much better maintained one called procmail.
After all, I was only needing a local MTA, nothing too elaborate.

Just works and in three years' use it has never given me any grief, to the extent that I had to actually look up the package name.  8^°

Thanks for your input.

Best,

A.

Note: I will mark this as SOLVED to this thread will continue in part II here.

Hello:

Hmm ...
Not really.
Have a look here.

That is a WiCD package only by name.
It is a transitional package that works as a front end to install any one of its listed dependencies:
ie: network-manager-gnome | network-manager | connman-gtk | cmst | connman-ui

From the README.Devuan file:

* underline is mine.

Thanks for your input.

Best,

A.

Hello:

Thank you very much.
I'll have a look at all that.

Best,

A.

Hello:

I see.

FF 115.8.0esr (64-bit) on Devuan Beowulf here.

Don't think so.

My friendly local telco providing me with a landline since 1986 along with a pricey albeit low quality ADSL for the past five years decided manu militari to make good on their advertised improvements and deactivated it. With no previous notice.

I am now a 2.0 USB WiFi dongle, legitimately loaned by a neighbour two doors down the hallway so it is not that, the IP is always 192.168.1.29 and an old tin can antenna makes for a very decent 85/90% signal. A good temporary arrangement till the telco AHS deign themselves to come and see about a installing fibre connection.

But this also happened when my ADSL was working through a Pi-hole/Unbound rig running on a Chimaera VM inside my box, the IP also always 192.168.1.2 and the DNS 192.168.1.5. Worked quite well.

I think that the login credential is on a Dev1 cookie and probably has an expiration date.
eg: at this moment I have two Dev1 cookies in my browser but they show no expiration time/date which I recall could be seen in older browsers (long time ago).

Maybe if I change the setting from Allow for Session to Allow this will stop happening?
I always set any and all browsers I use to clear all history on shutdown.

Thanks for your input.

Best,

A.

Hello:

Always done that.
I started with Devuan Jesse in this box and from then on up to Beowulf (now with a backported kernel) was like that.
I opted out of Chimaera because of WiCD and SLiM, this last one having been revived.

But the 'Debian Way' ® is not what it was, between the bloat, the infamous usr/merge and who knows what else is lurking around there, I am rather wary.
Who knows what sending it may bring about.

I will probably clone my system 120Gb SSD drive to an empty 300Gb SAS I have in the slots.
Boot from there and see what happens when I send it and reboot.
Cannot wait to see my dmesg printout. 8^D

That said, I have noticed that what I see as the most important part of my screed has not gathered the much attention.
ie:

Thanks a lot for your input.

Best,

A.

Hello:

I assume you are using Nvidia drivers.
If so, RandR may/will not work along with Xinerama.

I use a pair of FX580 cards for three 19" monitors with the (now unsupported) Nvidia 340.108 drivers and an xorg.conf file I managed to put together after a very long trial and error process, obviously with Xinerama enabled.

At one point, on every boot my /var/log/Xorg.0.log file reads:

~$ cat /var/log/Xorg.0.log
--- snip ---
[    91.365] (WW) NVIDIA: The Composite and Xinerama extensions are both enabled, which
[    91.365] (WW) NVIDIA: is an unsupported configuration.  The driver will continue
[    91.365] (WW) NVIDIA: to load, but may behave strangely.
[    91.365] (WW) NVIDIA: Xinerama is enabled, so RandR has likely been disabled by the    # <----  !!!
[    91.365] (WW) NVIDIA: X server.
--- snip ---

I believe this is applicable to all Nvidia drivers (unsupported or not) but I am absolutely not sure about that.

That said, I have recently seen that the nouveau driver works quite well (daedalus-live desktop *.iso).

You may want to consider trying out the live daedalus *.iso and see for yourself.
I was quite surprised to see how well it worked and how easily I could make the monitors behave as I wanted.

Best,

A.

Hello:

Of course, you have not given me any reason to do so.

I can relate to that.
The coffee roasting software I use runs in my 32bit Asus 1000HE under Devuan Chimaera.
It is the last 32bit version (1.1 / ca. 2017) made available by the author works perfectly well with all the hardware involved.
All versions after that (v2.10) slowly acquired a huge amount of professional roasting machine bloat.

That same machine has an XPSP3 partiiton I use once in a blue moon.
It came in very handy when I needed to flash the last available OS on a Samsung G530M now unsupported by the local telco.
For whatever reason my local XP VM would not run the MS based software I needed to get the job done without screwing up half way through the process.

Yes, I can relate to that too.

Indeed ...
I foresee having bad dreams about that.
There's not really much to choose from if Devuan should fail.
A Devuan based Linux from Scratch may very well be waiting for us in our collective future.

Thanks a lot for your input.

Best,

A.

Hello:

I am afraid that I may not have explained myself properly, again.

The only thing bothering me is the idea that, given the reasons I tried to explain in my OP, an upgrade from Beowulf (with a backported kernel) to Chimaera and eventually Daedalus may not be worth the trouble and may even be counterproductive.

Goes without saying. 8^°

I beg to differ, strongly.
As always, YMMV.

I am not looking for a decision to be made for me.
What I am looking for are opinions/insight to be able to make a better and more informed decision.

I learned a (very) long time ago that new, latest, shiny and full of bling do not necessarily make for a better product.
The IT world (OSs, software and hardware) is up to the brim with examples.

Thanks for your input.

Best,

A.

Hello:

Aye, it is.
None of that UEFI stuff in my box or in my netbook.

I am afraid that I may not have explained myself properly.

The system SDD is just fine, no problems with that.
My issues are with the move from Beowulf to Chimaera and then (eventually) Daedalus.

@aluma
@Andre4freedom
@rolfie

Independent of the method used to make a back-up image of my system drive and for the reasons stated in my OP, the question remains:

Seeing that my hardware has not changed significantly since I first installed Devuan Jesse ca. 2017 and will most probably not change in the coming years, is a dist-upgrade necessary?

All I see around me these days is bloat, bloat and more bloat.
To what benefit?

Thanks in advance.

Best,

A.

Hello:

Indeed ...
That is exactly what I am trying to avoid, as well as a clean install.

As I noted above, I run Beowulf with a backported kernel.

~$ uname -a
Linux devuan 5.10.0-0.deb10.16-amd64 #1 SMP Debian 5.10.127-2~bpo10+1 (2022-07-28) x86_64 GNU/Linux
~$ 

I understand that I should not skip Chimaera before upgrading to Daedalus. 

Right.
Note taken.

Thanks for your input.

Best,

A.