KDE Plasma likes, dislikes, and would be nice to haves

With each new release of Ubuntu, I’ve stuck with the default desktop environment. These have worked well for me over the years, but thought I should see what else there is.

The only way for me to do it justice is to run KDE Plasma as my only desktop environment for a minimum of 2 weeks. So both my work station and my personal laptop are use KDE Plasma installed alongside Gnome 3 Shell on Ubuntu 19.10.

If I’m unhappy after the 2 weeks, I can always go back to Gnome. Or maybe try something else, like lxde or xfce.

I started on Sunday evening, and it’s now Wednesday afternoon. The following are my findings.

This is likely to be updated as I find new things or ways to fix niggles.


  • When an application shows in the “Task Manager” bar, one can click it to minimise the active window.
  • All icons showing in the “Task Manager” bar (Autokey is a GTK application, but can’t show its icon in Gnome 3, but manages to in KDE Plasma?).
  • Simple music controls on lock screen.


  • Even at max mouse sensitivity, it feels slower than on Gnome 3 – not good for a 3 monitor set-up – this may be subjective and not be an issue in time.
  • No option to locate the mouse cursor by pressing [ctrl].
  • Some windows don’t respond to a mouse wheel scoll until the window is clicked – this may be an issue only with GTK applications running on KDE Plasma.
  • Being asked for my SSH key in the terminal for every action – is there a key manager like in Gnome that I need to enable? Manually resolved by running `ssh-add` against each key required. Gnome does handle this a lot better 😐
  • Scrolling in an application window does not respond while a OSN is displayed – example: Spotify changing tracks

Things I’d like to see ported from Gnome 3 Shell

  • The option to only switch the central monitor when changing between virtual desktops.
  • Change between virtual desktops using [ctrl]+[alt]+arrow keys.

Things I’d like to see in all desktop environments

  • Option to have the cursor colour to invert as it passes over other colours – Windows does this.
  • Automatic window scaling based upon the native resolution of the monitor in use. If a window is moved from one monitor to another, and the resolution changes, the scale should adapt to keep it readable – Windows does this.

Embiggen .desktop loaded applications on Ubuntu

I keep forgetting the steps required for this, so thought I should write them up in one easy to remember blog post for myself.

My desktop set-up consists of 2 x 1080 and 1 x 4k display. Making sure that applications are readable is a bit of a farce.

But as long as I ensure that certain applications only ever appear on the correct monitor, means that I can alter the launcher to set the correct DPI scaling.

Case in point is the “thunderbird.desktop” launcher. I only ever use it on the 4k display (central monitor), so I can alter the launcher to pre-set the scaling to two times normal. Making it readable without squinting (I’m nearly 40 you know).

Using “locate thunderbird.desktop” we find that it’s stored at “/usr/share/applications/thunderbird.desktop”. So raised privileges will be needed to edit it.

“sudo nano -w /usr/share/applications/thunderbird.desktop”

Using “ctrl+\” to replace text, search for “Exec=thunderbird” and replace it with “Exec=env GDK_SCALE=2 thunderbird”. Use “ctrl+x” to save and exit the editor.

Now when the Thunderbird launcher icon is clicked, the application will be rendered at twice the normal size. Making the working day a lot less squinty.


I used to use a 2 command 1 liner to update my system:

sudo apt-get update && sudo apt-get dist-upgrade

That was easy enough to type out now and then. But over time it grew to include removing and cleaning downloaded packages as well.

Then there’s the matter of knowing if an update requires a system restart.

The lazy me put it all into one bash script and made it globally accessible and executable:

Placed it in  /usr/local/bin/apt-upgrade  and made it executable with  sudo chmod +x /usr/local/bin/apt-upgrade .

Now I can run  sudo apt-upgrade on all of my servers and it’ll update things as well as letting me know if a reboot is required.

Most amusing spam received to date

Sent 5 days ago to my work address, no less.

Guess I got away with it!

Unable to install sass gem on CentOS 6.9 with Ruby 2.4

Something changed recently, preventing a VM from fully provisioning. Tracking it down was a bit of a PiTA.

OS: CentOS 6.9
Ruby: 2.4 – installed from source with the gearlingguy.ruby ansible role
Gems to be installed: sass

The issue is with the ffi ruby gem.

Looking at the releases in github, a recent release updated the required version of autoconf installed on the system. Fine for modern systems, not so much for CentOS 6.9.

The solution is to install the ffi ruby gem with the version prior to this recent change:

This then allows sass to be installed without complaint!

Setting up an On-Premise instance of Amon

NewRelic no longer offers server monitoring for free accounts, so what are the alternatives when you’re on a skin-flint budget?

There are lots, but I’m not going to review any of them. Instead, I’ve been tasked with getting Amon running on a DigitalOcean droplet so that it might be appraised.

Amon can either be used as a SAAS, hosted by Amon themselves. Or it can be run “On-Premise” by cloning the git repo to your own server.

The On-Premise instructions didn’t work for me as-is on a fresh Ubuntu 16.04 server. So I present to you here the result of getting it going!


  1. You know what you’re doing with Linux on a server.
  2. You can create your own VPS, or have dedicated hardware, that will only be used for server monitoring.
  3. MongoDB is installed from Mongo’s repo, not Ubuntu’s.
  4. Let’s Encrypt is used for the SSL certificate.
  5. The FQDN used for accessing the Amon instance matches the server’s full hostname (easy enough to change by altering FULL_HOSTNAME).
  6. Postfix is used on localhost as the MTA (alter the content of /etc/opt/amon/amon.yml if that’s not to be the case).

The following took the instructions of https://docs.amon.cx/onpremise/ and then extended/tweaked them to create a fully working server.

So the initial script I wrote turned out better suited to being a collection of scripts. And to keep them together, I’ve created a new GitHub repo to house them.

If you find it useful, great! If you would like to help make the installation provisioning system better, PRs are very welcome 🙂


Upgrading Jenkins war file the quick and dirty way

The above bash script will download a given version of the jenkins.war file and symlink it into place before restarting the jenkins service.

Assumptions made:

  • The jenkins.war file is installed to /usr/share/jenkins
  • The server is using upstart for running services
  • User input is sane – there is no validation or sanitisation

Vagrant: sudo access and the hostsupdater plugin

Bringing up a vagrant machine is as easy as vagrant up.

If you’re a web developer, it would be nice if it were to add the private network IP address to /etc/hosts of the host machine. Thus giving you instant access to http://my-awesome-site.dev/

This doesn’t happen by default, but it is possible with the use of a plugin. The one I like to use is vagrant-hostsupdater.

Install thus:

When you bring up the vagrant machine, it will now automatically add the VM’s name to /etc/hosts.

As /etc/hosts is owned by root (and I hope you aren’t running everything as root), you have to provide sudo access to edit /etc/hosts.

Either you manually enter your sudo password every time you run vagrant up, or you can add some rules to sudoers.

This will work on Ubuntu type systems. Paths to sh and sed may be different on your own system.

Copy/paste the following into /etc/sudoers.d/vagrant and chmod the file to 0440

A similar system can be used if you want to make use of nfs for the file sharing with the VM.

Again, this works for Ubuntu systems, you mileage may vary.

Copy/paste the following into /etc/sudoers.d/vagrant and chmod the file to 0440

You will now be able to use nfs without having to enter your sudo password on each vagrant up and vagrant halt.

Basic set-up of a 3com 4500 managed network switch

I’m a PHP developer by trade with a strong Linux background. One thing that has been lacking from my skill set is how networking really works.

In an effort to rectify this, I bought myself a 2nd hand managed network switch from ebay. A 26 port (24 x 10/100mb + 2 x 1gb) “3com SuperStack 3 Switch 4500”.

Flashing lights and noisy fans, I feel like I’m headed in the right direction.

First things first – can I plug it into my router (with DHCP), have it get an IP address and log into the web interface?

No 🙁

Using nmap to sweep the subnet, that the router manages, returned no results for the known MAC address of the switch.

Even checking the router for connected devices didn’t list the known MAC address of the switch.

If I wasn’t getting into the system via the network, I would have to use the console port instead.

As I didn’t have a null modem cable to hand, and I don’t have an active machine with a d9 serial port, I grabbed something from Amazon: http://www.amazon.co.uk/gp/product/B00HUZ6OMQ (NB: does not work with this switch, keep reading)

As I’m a Linux user, I would be playing with /dev/ttyUSB0. And to use that, my user has to be in the dialout group:

Connecting to the serial console should be easy with:

Hooked up the cable, ran the command to bring up the serial interface and switched on the switch.

This, annoyingly vertical, video shows that something happens (watch the green block skit around in the black window) but no text appears: https://www.youtube.com/watch?v=sXVYtClNDYU

Every different program I tried (screen, minicom, putty) to connect to the device all resulted in the same output.

Thanks to fellow 3com switch owner Intrbiz, I have been able to borrow a known working cable.

Hooked up between the PC and switch, ran the byobu-screen command and turned on the switch – It lives!

Now that I have a way of talking to the switch, I can configure it in a way so that I don’t need the console cable (as much).


Factory reset (this requires the console cable):

We need to factory reset for the following reasons:

  • remove any unknown users
  • restore the admin password to the factory default
  • remove any network configuration set-up by the previous owners
  • set-up our own network configuration

Start a console session and power on or reboot the switch.

  • Hit ctrl+b when prompted. Be quick, you don’t get long.
  • Now in the boot menu, tell the switch to ignore the saved configuration for the next reboot (option 7).
  • Reboot the switch (option 0).

Let it boot normally and wait until something like this appears:

  • Hitting enter will log you in as the admin user.

  • Hit enter again to put your cursor on a new line, not at the end of the debug output line. Enter “save” to save the default configuration over the configuration that was written by the previous owner.

It’s now safe to reboot or power cycle the switch as much as you like and it’ll have the factory default settings.


Assign a static IP address to the network switch (this requires the console cable):

  • Ensure that the switch has booted and then connect to the console

  • Enter the system view

  • Switch to vlan 1

  • Set an IP address followed by netmask

  • Set the default route for the switch

  • Return to the user view

  • Save the configuration


Enable SSH login (this requires the console cable):

  • Ensure that the switch has booted and then connect to the console

  • Enter the system view

  • Create the public SSH key

  • Configure the authentication mode

  • Enable the SSH protocol for inbound connections

  • Exit the interface configuration and return to the system-view

  • Create a new user for our SSH connections

  • Set the user’s password

  • Give the user SSH access

  • Exit back to the system view

  • Allow the user to login via SSH using their password

  • Exit back to the user view

  • Save the configuration

  • Check that the SSH login works


Enable Web login (this can be done with the console cable or an SSH session to the switch):

  • Connect to the switch via the console
  • Change to the system view

  • Switch to the admin user

  • Configuration stuff

  • Return to the user view

  • Save the config changes



Firmware: https://h10145.www1.hp.com/downloads/SoftwareReleases.aspx?ProductNumber=JE045A

Enabling SSH logins: http://h30499.www3.hp.com/t5/Comware-Wireless-Unified-Series/How-To-Enable-SSH-In-3com-4500-Switch/td-p/2318357#.VXLVtd9jPRY

Fixing the web login: http://brittadams.com/blog/2014/08/25/unable-to-log-into-web-interface-3com-4500-switch/