Hello:

Indeed ...
I'll probably get screwed anyway.
That's what an unchecked monopoly/consortium/cartel of 'independent' telcos will get you.

Yes, I get the gist of it.

I already have traceroute installed, I will have to see about installing mtr, learn to use it and write up a script to run in a jiffy if needed.

Competition? 8^D !!!

Sure, it's been heard of by the public and and talked about quite a bit by all the neo-con DHs/AHs that abound around here.
But has anyone actually seen it at work and observed positive results?  8^¡

Interesting, congratulations for that.

Hoping not to be considered indiscrete, a question if I may: how much does that service cost you?

Let's see what the tests say once it has been installed, maybe by mid April.
It is advertised as a 300Mib synchronous all-fibre link direct from whatever is in the area to my apartment, but I have my doubts.

We'll see what happens when it is in place and working.

Thanks for your input.

Best,

A.

Hello:

Thanks for the info.

I'll give it a try when I get the fibre.

Best,

A.

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.