Life with KDE [4]

There have been a few small hiccups in a couple of areas with KDE so far.

One is the MTP support appears to be not as good as on Thunar (XFCE). I have not been able to get a reliable connection to my Samsung Galaxy J2 phone. As a result I have put a cable onto the Windows 10 computer to enable me to use that to transfer files off the Galaxy J2.

On the other hand the KDE Connect setup seems to work very well and be a viable alternative to Bluetooth for transferring individual files, but it only seems to be able to handle one file at a time.

KDialog is another thing that could work better. Chrome needs this dialog in order to open files, but it is too much like Thunar in not being able to deal with network shares that are offline. I am looking at using another file manager other than Dophin as there are a few alternatives like PCManFM-Qt and possibly Nautilus or Nemo that don't freeze because they can't connect to a network share. Firefox Aurora browser doesn't need to use KDialog so I may end up switching browsers for day to day stuff.

Generally the experience is OK except that resuming from hibernation can be more likely to freeze up.

Life with KDE [3]

Since writing about the NUC's problems installing Debian and Kubuntu in UEFI mode, I discovered the computer has a legacy boot setting which is essentially BIOS boot so with that turned on and UEFI turned on there was no installation problem. Kubuntu was installed successfully first, then I overwrote the installation with Debian-KDE and then put the kde-full package on to complete the installation.

So I now have two computers running KDE. The others will follow in due course but not urgently, just whenever they are next reinstalled. Once again as previously described the settings were put into X11 to handle the screen's 1360x768 resolution and it has worked perfectly. Since I have two screens of this type on mediapc the issue is with the detection of the screen as 1920x1080 by default and 1360x768 not being one of the default resolutions provided in Xorg as implemented in many distros.

I can't really be bothered working on the obvious efibootmgr problem as it will probably take weeks due to the voluntary nature of much of the maintenance of much of these packages. It would be OK if I had a spare system and apparently this issue is not unknown. But right now I can just use the BIOS mode because I am never going to need UEFI on this computer. I don't use it now on the only other computer in the house that has its capability.

Life with KDE [2]

Things are getting back to normal with KDE on mainpc and I am getting on with work today.

I was planning to have the same configuration on bedroompc (the NUC) but have run into problems with the Linux implementation of EFI when this platform is set to boot UEFI and install Debian or Ubuntu in that mode. So far with numerous tests and tweaks we seem to have hit some kind of internal limitation in the efibootmgr module for the number of times a Linux operating system can be installed on the platform (in this case, the NUC6CAYH PC with the NUC6CAYB board installed). 

Since this is a fairly new NUC it is still under warranty, but since Intel doesn't really support Linux and as I have flashed it to the latest BIOS, AND it can install and run Windows 10 without any issue, it seems it falls down onto the Debian or Ubuntu maintainers to take a look at what is going on with efibootmgr which is unable to complete the setup task of installing and configuring grub-efi-amd64. Enough of grub does get installed for the hard disk to be recognised as bootable in the NUC's EFI bios and grub to start up to a command prompt, it seems the issue is the part of grub where it should be booting into the operating system is at fault.

Since I have tested the boot with both Debian and Kubuntu it must fall on the boot manager code and the fact of this apparent perception of a limitation to the number of installs. This computer has been successfully running other Linuxes since new, mostly Xubuntu and Debian, without problems. In fact I only recently installed the same version 9.5 of Debian with XFCE on it a few weeks ago. Given that the BIOS has been wiped and upgraded, that grub can boot to a shell, and that Win10 can run OK, it looks like I now have a process ahead of me of working with the Linux community to try and debug the problem in their EFI boot implementation.

Life with KDE [1]

Having jumped in boots and all into KDE on mainpc (having had to reinstall Debian and choosing KDE instead of XFCE) there are a few things to be aware of. At least we do get 5.8 version of KDE Plasma on Stretch, I would have half expected it to be 4.x because of Debian's reppo for older versions of stuff but having a 5.x release is good, of course I would want 5.13 but maybe Buster will have something like it when it comes out next year.

The standard KDE install task from Debian is only a minimal desktop that lacks some useful stuff and it also defaults to an ugly looking logon screen with Debian wallpapers. On my test config I installed extra packages for the breeze login theme. I had to install synaptic package manager to find them as the KDE software centre could not list them.

To make life easy you can install kde-full package which just puts all the KDE stuff in because Debian doesn't do this at install time. This will overcome numerous frustrations and trying to figure out why something doesn't work like it should (like the printer not being detected when you plug it in). Probably this situation is no different from other desktops like XFCE not being completely installed, the difference is there is so much more in KDE that you are going to be missing out on a lot probably, there something like 500 packages left out. OK you may not need them all but if you have a powerful system and are not too worried about bloat then it is probably easier just to install the whole lot at once.

After getting these extra packages installed the printer was straightforward to get going and print from. I  have spent much of the evening tweaking various KDE things and really getting up to speed on it which has been slow but tomorrow I will get some real work done as I have really lost a day but unfortunately it has been that kind of week of getting very little done overall.

KDE remote desktop sharing

One of the best things about KDE is the amount of apps they have available that are integrated into the shell. As XFCE lacks its own remote access integration you have to install x11vnc and muck around trying to get it to run as a service which I have yet to be able to complete. In KDE you have several apps available, I chose to use Krfb (RFB is the protocol that VNC uses) and it comes up as "Desktop Sharing" which is essentially the correct description of what I want to achieve.

With just a few clicks I was able to enable the desktop sharing and also enable it as unattended because I want to be able to connect to this desktop all the time without having to go to it to authorise a connection.

It will be interesting to see how Plasma develops in its latest high efficiency optimisation. It is quite possible some of my computers will be switched to KDE instead of XFCE but there is no huge rush as I just want to spend some time figuring out how everything works with KDE. Most of my PCs are fast enough to have few issues with the somewhat greater resource use in KDE and I will be keeping Debian as the base OS, no more Ubuntu for now. 

The only real thing with the Debian install of KDE is the clunky default logon theme which you'll want to change to the Breeze logon, for which you have to install additional packages. I last had a play with the Breeze logon when I had LXQt on one or two of my computers. Incidentally LXQt is now an option to install in the Buster alpha and the next release of Lubuntu will use it by default.

One of the reasons KDE looks good is because they are making steady progress towards integrating Wayland, something XFCE is falling further and further behind on. Pretty soon Wayland will replace X11 as the default display protocol and then some of the Linux desktop environments will not support it very well. Interestingly enough Ubuntu 17.10 installs Wayland by default (Xubuntu doesn't, so I won't have seen Wayland on anything yet). In Ubuntu 18.04 they reverted to Xorg after discovering Wayland still has some issues.

Mainpc at the moment is getting reinstalled with Debian and KDE because some sort of stupid crap bug resulted in an apt autoremove command removing a lot of core install packages including all of LibreOffice and some essential stuff, basically stuffing the system and making it unable to connect to the internet. So Debian 9.5 will be on it along with KDE and this will be only the second time I have tried KDE on one of my major computers that I use every day. This time hopefully I can make it stick (last time it was too hard to migrate from XFCE).

Computing resources optimisation [6]

Well computer no.4 is not going to be "ministrypc", it is going to be a computer for displaying pictures on with the maps project. I just decided this is the best way to do things, because its screen resolution of 1600x900 is higher than mediapc. But also, because I want to keep mediapc just for music playback and stuff and have a computer that does work just for the mapping specifically.

It had Buster running on it but I have had a few problems with this alpha release so last evening I rolled out Stretch 9.5 onto it because I couldn't get Synaptics Package Manager to run and some other updates wouldn't install. The other thing I am doing with it is testing other desktop environments because, although XFCE has been pretty good, I am just keeping my options open as their development seems to be slow. XFCE version 4 was released way way way back in 2003 and they don't seem to have any ambition to move to a version 5 any time soon. There is a 4.14 coming out soon but 15 years is an awfully long time to have software that hasn't had a major new release.

I am deciding to evaluate KDE on it even though this has a resource hog kind of reputation. The latest version of KDE Plasma (5.13) is being optimised to make it much leaner than previous releases, so it will be interesting to see how I get on with this.

For doing stuff that requires me to use the cellphone tethered, I already have another computer (bedroompc) that can do that and with x11vnc updates I can vnc to that computer quite easily and reliably when I need to do stuff like that and it doesn't require the separate wireless bridge because that computer has built in wireless.

Fix for x11vnc problems on Stretch

Following up to my last article, having tested x11vnc for a day on mediapc, it crashed with the "stack smashing detected" issue. Reported as a Debian bug here:

• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859213

This issue affects multiple distros, including ones unrelated to Debian, such as Red Hat, Arch and Fedora, as well as related such as Ubuntu.

The recommended solution for Debian Stretch is to install the x11vnc packages from the testing repository. I have now applied them to mediapc for further evaluation.

Hopefully this will make x11vnc reliable enough to be used for my purposes. This is about the first update to x11vnc in eight years.

HOWTO: Share a screen in Linux

Screen sharing is a generic name for allowing the screen on one computer to be accessed from another. It is similar to, but different from, Windows Remote Desktop. There are a number of options that are mostly based on VNC. I have a Windows 10 Home computer here that has TightVNC Server installed on it, and with Remmina running on one of my Linux computers, the user session running on the Windows 10 computer can be controlled through Remmina, and at the same time as being displayed on the Win10PC's screen. This is different from RDP which locks the screen when you log in to the remote computer, although you are connecting to the same session.

However the scenario where I want to control the current session that is running on a Linux computer, is a bit more difficult because most VNC programs work differently under Linux than they do under Windows, including TightVNC for example. Under Linux, the current session under X-Windows (the basis for most GUIs in Linux, although Wayland is starting to be adopted as a replacement) can't be shared in most of the common VNC implementations. So these programs generally create a new remote session which the user can run stuff in, but they can't share the default user session on the computer. This means that many of the FOSS VNC packages won't perform this function and so you can't expect to install some VNC system and it will just work.

Exceptions to this include the following packages:

• Vino is the screen sharing package for Gnome. It is provided with Ubuntu and variations. Standalone packages are also available for other distros and will work with XFCE, but it is more and more being integrated into Gnome these days which makes it difficult to use with other desktop environments. I have used Vino in the past with Xubuntu, but the impression I have now is it would be difficult to use in Debian/XFCE because the configuration is supposed to be done with a Gnome-only tool. There is a desktop sharing tool in Cinnamon which is probably Vino adapted to a non-Gnome environment. I haven't used Cinnamon since I used to have Linux Mint a couple of years ago, so I don't consider this to be an option.
• X11vnc is a package developed formerly by Karl Runge. It is in the repositories of major distros such as Debian. It is easy to set up and install, but has not been actively developed for several years, and my impression of it is that it is not very reliable, tending to crash a lot. I remember a year ago using it with Xubuntu and it seemed to have better performance than Vino. (I will take another look at X11vnc to see if I just need to change some configuration settings, but I was unable to make it run as a service on my computers)
• RealVNC is unlike most of the other VNCs in that by default it shares the current Linux user session. However it is commercial software although a limited free license is available. I haven't bothered to install it because of this licensing issue.
• Xpra is a package that among other things is supposed to be able to "shadow" the current user session on a computer. I tested it and it seems to be difficult to configure and make work successfully. The documentation for it is tricky to understand. It looks like it has some potential but is either very complex in operation, or needs a lot of work to make it as user friendly as some of the other packages.
• X2Go is another open source community supported package. I am currently testing this on mediapc to be able to control it from mainpc. There is a specific package with it called X2godesktopsharing that is specifically used for the screen sharing functionality. Unfortunately X2Go turns out, like Xpra, to be another poorly written and supported package.
• NX/NoMachine is the last option to consider. X2Go is based on it. NX uses its own protocols and NoMachine provides a limited free version of a commercial package. There used to be an open source part called FreeNX but it is well out of development.

So I have been looking into a lot of options this week. There is in theory another option which is the Linux RDP clone which I think is called rdesktop. I haven't looked into that one.

Right now I only have NoMachine left to test having gone down the list, or I could still consider RealVNC if I run out of options.

Computing resources optimisation [1E]

Got to thinking more about how to make the best use of resources with the computers. The biggest issue is ergonomics. You can only really practically use two keyboards at a time. So if using more than two computers you prefer to have more than two keyboards/mice, but it's hard to access them without moving your chair, unless you can use VNC. At the moment I have a love/hate relationship with VNC because I haven't been able to make it run as a service on any of my Linux computers and therefore work out of the box every time. Also X11vnc is less than reliable and crashes quite frequently.

In terms of the two computers that are most frequently used, the serverpc that only has 16 GB of RAM should be boosted to 32 GB at some point, probably with a new mainboard, and its existing mainboard gets moved into mediapc, which in turn its board gets moved into the 4th computer. The main issue with running lots of applications on a 32 GB computer is when one of them causes it to crash. I'm still looking at the optimum way to use the 3rd or 4th computer to run some stuff such as email and spread the load of map resources onto the 2nd computer so it isn't all the 1st computer, but it's a tricky process to try to work out the best way of making that happen. I think it will be necessary to focus mainly on the two computers with the keyboards that are easiest to reach that will run virtually everything, so mediapc will stay media and ministrypc will stay ministry.

Running the day to day stuff in a VM on mainpc is a possibility. We are looking at what is internet based and doesn't have issues with local resource access. It's possible I may put email onto mediapc and possibly some other resources because it isn't used for that much and occasional access via its own keyboard, which can also be switched onto one of the main keyboards, is viable. This is different from using it for image display, which is what I have already experimented with, which often runs into problems getting updates from mainpc over the network. Internet based stuff like email doesn't have that limitation.

So probably the next goal is to get serverpc up to 32 GB, there is quite a bit of cost to this so it would end up happening in stages. Of course, I presently have no budget for this, so really it is a dream for the present. We just keep working with our current resources for now. If I can make VNC work properly on mediapc then it will be easier to do stuff on that which I find hard to use it for at the moment. However doing the new board for serverpc and putting its board into mediapc would also help because mediapc would have enough resources to run more stuff and over VNC it would be very good because I am using VNC to control the screen, which is still being displayed, unlike RDP where the screen turns off. 

I will have another look at VNC support for Debian and do some testing with tightvnc as it seems I should be able to make this work and then mediapc in particular can be used for more things.

HOWTO: Add extra display settings permanently to Linux

I have a Veon TV that I use as a display for the bedroom pc and its major problem is that it is detected as a resolution of 1920x1080 but its native resolution is actually 1360x768.

With other computers the instructions I dug up were to use xrandr commands in some of the lightdm config settings so this command would be run each time the computer started. I actually did try that this time around (scaling down from a virtual screen of 1920x1080 to a physical of 1360x768) but couldn't get it to work reliably.

After some more digging I found out how to permanently add the display settings as a modeline. You can make a modeline using the cvt command and then use xrandr --addmode to add this then you can switch to it for testing. For a permanent change you just need to add something like the below to /etc/X11/xorg.conf file:

Section "Monitor"
    Identifier "DP-1"
    Modeline "1360x768_60.00"   84.75  1360 1432 1568 1776  768 771 781 798 -hsync +vsync  
    Option "PreferredMode" "1360x768_60.00"
EndSection

So there you also have your modeline for the correct display. DP-1 in this case is the display output name, which presumably is derived from DisplayPort, but is actually an HDMI output on this computer.

Once that was all set up I was able to force the screen to 1360x768 its native resolution and it has stayed there ever since. Thus bringing an end to horrible 1920x1080 being scaled which made everything on screen too small.

HOWTO: Connect a Nexus 5X to a PC

Previously on this blog I have bemoaned the apparent lack of support for the Nexus 5X on PCs. It turns out however that the connectivity is not well documented (not as far as I am aware with Android 8). Earlier efforts failed because I thought a driver was needed, of which no such thing actually exists.

If you are using Debian you generally need to install some extra packages to enable MTP support. However, it appears that MTP is installed by default in Debian 9.5, as my bedroom pc, which has been recently installed with Stretch 9.5, had no difficulty in connecting to the phone without any additional configuration steps needed.

Once the phone is connected to the USB-C cable, "Nexus 5X" will appear in a Thunar window (for Debian with XFCE) but there is still an additional step needed to make the file storage browsable on the phone, and annoyingly this option has to be selected every time you plug the phone in. Simply go to Settings, then open the Connected Devices section, and find the USB section. The options there are "Charge this device", "Supply Power", "Transfer Files", "Transfer Photos" and "Use Device as MIDI". It would be kind of nice if Transfer Files was the default instead of Charge this device, or if charge was able to be simultaneous with a choice of the other actions. On the other hand I find the other options interesting and might look into how they work. But given the limitations of the Nexus's battery capacity I don't expect to supply power to anything else anytime soon.

If you select "Transfer Files" then instantly the phone's file storage becomes browseable and this will be a great benefit, not only in order to extract photos, but also store my music collection which has been virtually impossible to achieve up to now.

I assume the same steps will work on Windows 10 but am not rushing to try it because I don't need the Windows 10 computer for much. I am planning to spend a bit of today finishing the incomplete reinstallation of the Windows 10 computer but I don't need it for many devices and won't bother putting any USB cables onto that computer, whereas I am connecting a full set of three device cables to mainpc because that is the most useful option.

Computing resources optimisation [1D]

Well a few posts back "pc4" was being set up with Debian 10 (buster) as an evaluation computer and that was purely for that purpose and it had my media collection installed in order to evaluate it as a media player. But it does struggle to achieve that role because the hardware is too old and slow to play back videos and so Kodi gives a choppy display in playback.

Since writing therefore a new purpose has arisen for a computer to be on my desk that will be permanently connected to a tethered phone for which purpose the requirement is to have access to the internet for times and reasons that would be outside of the scope of the school's internet connection which I can currently use for 10 hours per day. However it is still not a solution for times when I want to watch streamed church content from Australia or elsewhere because the volume would blow my data cap relatively quickly. But having that computer on my desktop instead of using the bedroom computer over VNC reflects that I would expect to be using the desktop computer more often and also that the VNC option has proved unreliable because of software crashes and problems getting the software to run as a service. I haven't seen these issues with VNC on the Win10 computer but I have spent a great deal of time trying to resolve these problems on Bedroompc to no avail.

So the computer will be renamed from "buster" or "pc4" to "ministrypc" as it is being used for ministry work and that work could, at times, run into problems with the school web filtering system and I want to keep this work separate from the use of the school wireless system because of that. This will also provide me with a more convenient option for general internet use outside of the hours that the school wireless is available. The computer will be plugged into the Ubiquiti bridge that I have and this bridge will in turn be able to automatically connect to one of my two phones that can be used in tethered mode to provide the required data connection.

On or about the 21st July I wrote a post highlighting that I had had problems with using a Vodem with various computers to gain access to the internet via my cellular data connection. I blamed the problems I was having at the time on the Vodem as it seemed to be possible to get a direct data connection on the Galaxy Tab Android tablet that I had and this seemed to show the Vodem must be the problem. Subsequently I was able to get the tablet to work which seemed to prove this was the issue. However while I have been able to use the tethered phone on a number of occasions, last evening it would not work at all while the tablet again worked (and is being used to write this post). The fact that this issue keeps occurring with either Vodems or tethered phones suggests rather strongly that Vodafone in actuality does have some kind of system that they use randomly and without notice and subject to their own whims to impose a total obstruction of tethering. This is obviously of considerable concern to me and is something I will have to keep evaluating in coming days to try and work out exactly what is going on as it imposes severe limitations on the work I was expecting to do with this computer that really depends on the tethered connection.

So a couple of days later Vodafone has still not resolved the blocking issue with tethering still being blocked so regrettably the idea I was going to be able to use this computer for ministry is under question at the moment. If I cannot get any sense out of Vodafone I will have to try to find an alternative solution.

At the moment I am still testing out VF but at least the network has been more reliable and ministrypc is able to get onto the internet much more readily. Interesting is that every Linux PC in the house is now running Debian (except for laptops which don't get used much). So mediapc and even bedroompc are running it now. It is just so much better set up than Xubuntu which is a bit nanny state in so many ways (like in regard to hibernation and using the root account). 

Backup software / recap

About eight years ago I thought I was building a really special PC with a Intel DG41RQ mainboard, Celeron E3300 CPU and 2 GB of RAM. The article series started here: https://enzedtech.blogspot.com/2010/10/rebuilding-my-pc-1.html

Unfortunately I outgrew that computer pretty quickly because it could only take 4 GB of RAM in total and therefore became pretty slow with later versions of Windows. However it would work fairly well under Linux. I often wondered why I bought a LGA775 system that was right at the end of that generation of CPU, and it looks like cost was an issue. The Celeron E3300 did support hardware virtualisation though (that was something that would have been useful if the computer had enough RAM, as 4 GB was barely enough just for Windows).

These days I try to do a better job but at times there can still be a price/performance tradeoff to consider, the main reason why I have a serverpc that only has 16 GB of RAM in it because the board only has two memory slots. Well we could put 16 GB DIMMs into the two slots but would have to throw away the existing RAM. Most of the time I try to buy something with four slots, and that's why the computer this is being written on has 32 GB in it.

Now to focus on good free backup software for Windows. I may have written about this before but that particular post isn't easy to find. I get asked this question from time to time so here is an answer. The two best free packages in my view are NCH FileFort and Cobian Backup. FileFort is a commercial package that has a free edition for home use, while Cobian is just free. I used to use Cobian to backup my systems when everything was running Windows, but of course now I don't have a need for it.

FileFort is perhaps a little more user friendly than Cobian however whereas Cobian will simply stop reporting error messages if there are too many, FileFort's problem is it will stop running if there are too many errors. This is annoying because you should be able to just check the errors later (they may happen for reasons like being in use as not all software packages can handle this well). Cobian also has the ability to use VSS which means it can copy in use files. So Cobian is probably the better of the two, however FileFort is probably more up to date (Cobian does work with Win10 so it's OK for a few more years, anyhow).

PulseAudio settings in Debian

As everyone knows, PulseAudio is pretty common in Linux for controlling audio levels. It was written by the same guy who wrote systemd. You can make up whatever politics you want around that.

PulseAudio has a configuration file called daemon.conf that is located either in ~/.config/pulse or in /etc/pulse . An important setting is flat-volumes = no

What's important to note is that Debian is, apparently, the only major distro where this setting is not set to no, which means it defaults to yes. The problem with this being at yes, is that it will cause problems with applications because changing the volume on an application like Kodi (which has its own volume control setting) will also change the system volume level and this can create issues when other applications play sound. As it happens, Kodi sets the volume level up when a new track starts playing and this causes problems when you want the volume to stay at a lower setting.

In the case of mediapc, with my reinstallation of Debian, this file already existed in my home drive with the right setting and there was no such issue. However it is useful to note that if Kodi is the active window, it will respond to keyboard volume control buttons the same way as if the Pulse Audio plugin is being used (when Kodi is not active). The difference is you are setting Kodi's internal volume control this way.

There is an active bug report open at the Debian Project (541538) which has been going for 9 years so far but may actually be getting some traction by now as all that is needed is a change in a script or something to make this setting be done properly in the default install.