Going back to make progress

by Lester Caine
Sunday 01 of April, 2018
Posted to Lester Caine's Blog

Having been treading water for far too many years now, I've decided that enough is enough and it's time to drop using the 'new secure' software and return to software that actually works. I've been using OpenSUSE for many years although crib sheets on the website will show the attempts to switch to other 'recommendations' but which were not successful. Currently I'm using Leap 42.3 but still have 13.1 running a number of machines. It was trying to set up a more modern web server that flagged many of the problems, and the next step is to try and retire the older servers in favour of a stock 42.3 setup. It's not the latest versions of the major framework components, but it does work reliably.

Keeping my desktop operational over the last few years has been someing off a nightmare, and I do wish now I'd simply ignored the problem of SUSE13.1 not being supported and kept a perfectly functional 4 screen setup that did everything I needed. The 'improvements' to support for hardware lack some basic control such as being able to manually select setting of display outputs. Simply disabling 'unused' channels on the display card has caused problems with both windows and Linux based systems. Many of my systems use multiple graphic outputs, but the 'desktop' is only accessed via VNC. The 'improvement' to XP requiring that there is a monitor plugged in before a channel is enabled left many systems unusable since the client sites are not allowed to run un-patched systems. Before the dongle fix was found we were throwing dead monitors into the roof space simply to get the desktop channel back. That was prior to the need to replace XP, and the ITX boxes running these systems simply would not allow W7 or later to be installed, so these were replaced with individual RaspberryPi boxes on each monitor, something that multiple windows licenses had made uneconomic. Many of the systems have now been retired due to the way Microsoft forced the retirement of XP and took tighter control of my clients as part of the new licensing contracts, but that is another story.

On the Linux desktop, the home system has a number of machines out in the workshop with a KVM switch and extenders to the office. While newer computers are fairly quiet, moving these out of the office area gives a much improved working environment. The problem is that with the existing hardware, none of the EDID/DDC signals are available at the computers, and a change to the hardware was not guaranteed to fix the problem as many data-sheets did not actually indicate just how these are handled. A couple of attempts at new kit did not actually work, so the arrival of the Lindy EDID/DDC Emulator while expensive, solved the major problem and locking them into the computer means that manually switching monitor cables no longer results in the machines loosing their setup. While much of the time the spare KVM ports are used while configuring new machines, it's useful in the workshop to quickly re-patch cables to use the monitors mounted on the workshop wall. The switch from a stable desktop to one which 'reconfigures' itself when a monitor is unplugged may be practical for some, but is a right pain when working on live hardware. The main problem moving from SUSE13.1 to Leap 42.x however was simply getting it to install a set of drivers that retained the 4 screen setup, with four 1920 by 1200 monitors. Getting all four screens active involved a time running Tumbleweed until the back ported software regained a working setup. While 10 years ago I actually knew how the display system software worked, today I'm not convinced even the current developers know quite what they are doing?

Having actually got the hardware working, the current KDE/Plasma setup is another area where I have toggled between Gnome and KDE over the years since KDE3 was replaced with something which at the time was totally alien. KDE4 does at least now have a 'classic' feel but has a few areas where it would be nice to get back to older ways of working. Dolphin is one such area, and currently it's been uninstalled and while Nautilus has a strange window it does restore the one key requirement in that I can access both local and remote servers in parallel. Dolphin simply would not allow the remote machines to be authenticated, although it did work in the past. I've even managed to get Firefox to use Nautilus as it's open in containing folder ... just need to work out how to get it to actually open on top of the other desktop apps.

While there is a long list of jobs still to be completed, moving the remaining http websites over to https and running on a more up to date server is the current top of the list. Leap 43.3 provides a fairly up to date setup, although Linux itself is back at Ver 4.4. Having still got many websites that rely on PHP5.2 adds to the fun. Keeping things running takes time, but the main problem is there is little reason to spend the amount of time needed to make these sites work with PHP7.?. It's not really time I can justify charging for so it's only appropriate if it would result in some sort of saving. It has been worth moving content to our later bitweaver framework, and with some sites we took over being .asp rather than .php that is the easyier upgrade path anyway, but a few sites have custom built code which it's easier to keep working than re-write from scratch. I think we will loose the client before the need to upgrade it.