Slow/Laggy/Poor graphics performance: Linux Guest VirtualBox 6.0

I have spent many an hour trying to figure out why VirtualBox 6 has given me terrible graphical performance on Linux Guests. I’m going to give you a no-mess solution that just might save your sanity.

Within the Settings for Your Virtual Machine, navigate to the Display > Screen tab.
Under the Graphics Controller dropdown, select VMSVGA for your Linux guest.

Next, you will need to boot into the virtual machine and reinstall the VBOX Guest Additions for this to work (and cement it in with the obligatory reboot)

So you may be wondering why or when you might need to use this guide?
You may have upgraded to VB6 from VB5 or earlier and trying to use a pre-existing VM.
You may have installed VB6 for the first time, created and installed a new Linux guest VM and experienced graphical slowness.
You may have tried (mostly) every setting within VBOX and viewed every forum post on the internet regarding VB performance issues and have got no further.

Admittedly, I was incredibly close to giving up altogether with VBOX 6 and going back to VBOX 5 as I have been struggling with this since VBOX 6 release. Finally, I have my VM back =)

A New Home for the PC

Whilst moving from an FX-6350 to Ryzen 2600, I couldn’t help but notice how poorly designed my case was. Sure, there’s a great need for aesthetically pleasing units and there’s a wide selection available, but let’s have a reality check.

As do many, budgeting on the case and PSU (as did I in 2016) for better hardware could be problematic. With cheaper cases, the choice is limited and picking the best unit for your needs might take a bit more time than simply adding one to your basket that meets the budget.

Changes in modern case design are a lot more noticeable for those used to having a “drive rail” at the front of the case and is worth understanding what has changed from the “classic layout”. Let’s explore this further.


ODDs (optical disk drives) are less likely to make an appearance then maybe 10 years ago. This might be because flash media is smaller, less noisy, more efficient and can be supplied whilst buying Windows. Also, games aren’t bought on CD or DVD anymore and are usually downloaded straight from the source.
This conclusion has allowed the limitation or in some cases (no pun intended), the complete removal of ODDs completely in Mid-Towers.
Full towers still have plenty of bays.


Before SSDs became mainstream, the standard storage unit fell to hefty 3 ½” HDDs. SSDs are now considered to be mainstream and usually found in smaller sizes: 2 ½” and M.2 and of course the less-seen size in the form of a PCI-e card.
Like ODDs, the 3 ½” drives are just about hanging on with at most a couple of spaces dedicated for the larger HDD. There’s more room now dedicated for SATA 2 ½” SSDs because of their form factor in Mid-Towers.
Full Towers usually have plenty of space for HDDs and are worth considering if you need space for your RAID 5 array.


This may be a little odd but there are some points worth mentioning. Modern Mid-Towers tend to position the PSU on the bottom of the case. There are a few reasons for this which are helpful to understand.

  • The weight is closer to the ground, and this is important in the reduction of unit being “top-heavy”
  • A dedicated ventilation grill for the PSU that isolates the airflow through the PSU to the rest of the system.
  • Modular PSUs can be helpful in cable management by reducing unnecessary plugs or cables.

Cable Management

Cable Management is an aesthetic “nice to have” but can play an important role during maintenance and any more adding/removing hardware. I also realise that it can help to reduce dust settling on meters of cable. As I like to think of it, keeping your workspace clean and tidy allows you to work more efficiently. The same can be said whilst maintaining your system.
A well-managed case is heavily dependant on the design. This is achieved with:

  • Space behind the rear access panel for cables
  • Space around the PSU for tucking away lengthy cables
  • Access points around the motherboard for cables to connect from behind the motherboard tray, such as front I/O headers and SATA connectors.


GPUs have grown in size and is worth making sure that the card you are buying/have will fit. Usually, case manufacturers are good at letting you know the maximum length of the card that could house.

Also, think about future upgrades and expansions; it could be worth finding the size of the largest GPU and seeing if it will meet the specifications to be better suited for years to come.

CPU Coolers

Many budget coolers are quite tall and you’ll want to be sure it will fit. Again, most good case manufacturers will note the maximum height of the cooler for the case and could impact your buying decision.

Front I/O

USB-C is still quite a way off from being mainstream, but it could be worth looking into, even if your motherboard doesn’t currently have an I/O header for it. If you use USB frequently, having a nice choice of USB2 and USB3 interfaces on the front can be a deal maker. If you are into photography or use SD often, card readers integrated to the case isn’t too uncommon.

Everyone is different and has different needs and tastes. Doing the research properly will allow for a better-equipped case for your needs, and may help you decide about the cooler you buy!

A case can (and should) last longer than the original hardware that it originally intended to house and being clear on current hardware trends can future-proof your purchase, even if it is bought to a budget.

Buying correctly will not only cut down on e-waste but will save your future-self some money too.

“The War of the Worlds”: a 21st Century project

The map you see is notated with every place that features in the novel. This was a fun project that had different challenges to overcome.

During my first read-through, I wondered about the places that crop up in the book and was in awe at the level of detail.

I not only wanted to highlight this visually, but allow for past and future readers to grasp and understand the distances that doesn’t necessary get portrayed well in the book. This is simply another layer which fans might be interested in.

You can find the full writeups here:
“The War of the Worlds” : a 21st Century project (Pt. 1)
“The War of the Worlds” : a 21st Century project (Pt. 2)

AMD Drivers and Firmware

After wasting a large amount of time on a recent problem detailed on this extensive blog post, I am unhappy about the way AMD drops driver packages.

This post will try to highlight some of the peculiar issues that I have noticed during this endless battle to stop BSOD’s happening to my shiney new Ryzen system.

AMD Drivers -UI

If you have an Intel CPU and an AMD GPU, or an AMD Zen CPU and an Nvidia GPU, you can read on with a smug grin.
If you have both an AMD Zen CPU and AMD GPU, join the hair pulling club.

Trying to install AMD GPU and Chipset drivers to the same system can start to make you feel insane, as anyone in an infinite loop condition would do.

Effectively, they (the driver installers) fight for superiority; an AMD driver package you are trying to install checks the driver version against one that is already present on the system, regardless of the type of drivers that you are trying to install.

So for example:

You install AMD GPU driver 19.1.2. After the reboot, you say…

“Hey!, it’s now time to install the chipset drivers while I’m at it!”

…which is not a bad idea at all.

You go to the website and jump through all of AMD’s hoops to pick the right driver and download chipset driver version 18.10.1810.

You start the installer and are confronted with a screen that effectively tells you that you are installing an older driver version, comparing it with the 19.1.2 GPU driver.

This comes down to clarity; which is frankly laziness from AMD.
And it doesn’t end there; the GPU drivers have an interface which allows you to find the driver version, which the chipset drivers lack only adding further to the confusion.

Below are some screenshots taken from the AMD site, showing the revision numbers. Yes! they are different, as expected. They are two separate drivers after-all but the installation battle is determined here.

AMD Chipset Drivers version 18.10.1810
The current version of chipset drivers 25/01/2019
AMD GPU Drivers 19.1.2
The current version of GPU drivers 25/01/2019

Currently, the way to overcome this is to install the chipset drivers first. The UI will install version 18.10.1810.
Installing the GPU drivers after means you will be “upgrading” to 19.1.2 but it doesn’t contain any chipset drivers so the currently installed chipset drivers will be untouched..

Very confusing, AMD.

The BSOD Blame Game

Issues to my system started when the Windows 10 1809 update dropped on my PC.
When the problems appeared (many BSODs), I updated to the latest chipset drivers which (as it turned out) seemed to be incompatible with my “older” BIOS. Let’s explore this further.

Microsoft Updates

Windows 10 1809 was officially released November 13, 2018.
It wasn’t until late December that Windows Updates decided that it was time to install this hefty upgrade. The upgrade happened as usual and completed without issue.

But something had changed to make my system unstable (did I mention many BSODs?!). The only thing I can think of is a driver update with 1809 or a change relating to the kernel which meant that something isn’t working correctly. This forced me to look at updating to the latest drivers to be sure.

Alas, the latest drivers did not solve the problem and only made the issue worse. Windows 10 was the cause.

AMD – Drivers

For the time being, I’m ignoring AMD’s GPU driver roulette…

Upgrade from 19.1.1 to 19.1.1?!

… and concentrating on chipset drivers.
I think AMD likes to assume that you not only have the latest AGESA BIOS readily available for your motherboard, but also applied.

As it turns out, the latest chipset driver package doesn’t specify any patch notes, AGESA or pre-configuration requirements and it doesn’t specify exactly what is included in the package.

AMD Chipset details version 18.10.1810
AMD Chipset details 25/01/2019

This most recent version could be AMD’s response to the new W10 1809 version! How Ironic.

If only AMD could tell me that this was only compatible with the most recent AGESA BIOS and that if it wasn’t available, I could try an alternative driver.

Not afraid of getting my hands dirty, let’s check for a BIOS update!


Currently, the timeline is around 2.5 months since Windows 10 1809 was released. Had I decided to update on release day, I would have had to wait through 2 months worth of BSODs until I found a solution. I finally found the solution on Gigabyte’s website.

The new BIOS (F25) is just over a week into its’ release (currently 25/01/2019). As you can clearly see from the description, it requires the latest chipset drivers that AMD released 26/10/2018. That could mean that the chipset drivers relies heavily on the F25 BIOS. Maybe.

Gigabyte BIOS Downloads – 25/01/2019

After looking for information about AGESA, Google is littered by speculation as far back as May 2017. So I ask myself, how bad is Gigabytes’ hardware support? and the answer is obvious, it seems*.
So essentially, Gigabyte could have sat on AGESA as early as 2017.

It’s not as clear cut as this, though. There are different AGESA versions depending on the type of chip, ZEN, ZEN+ and ThreadRipper to name those that I dug up.

*not so much obvious, actually. AGESA is incredibly badly documented for the most part, and it seems only high level slithers of the contents dribble down to consumers such as “better memory support” etc.


I am happy to conclude that the issues (since the BIOS update) have been resolved and it was most definitely a software issue.

Although only a couple of weeks of constant BSOD’s interrupted my ability to use the computer, I feel it’s still wholly unfair that we have to deal with these issues at a time when updates to security are as important as it has ever been.

If indeed Gigabyte has been sitting on this update for a while, it is totally unacceptable that these things should be left beyond the last minute.

On the same note, AMD need to provide greater clarity about the contents and pre-requirements to their drivers and stop blanketing their customers with just another iteration of the version number. Incredibly unhelpful.

My theory now is: due to the sheer amount of different BSODs errors that all pointed to memory faults, it could only have been a collaborated effort from AMD and Microsoft to help mitigate against Spectre on the AMD platform. But since the BIOS didn’t know about the changes, the drivers threw up errors.

Python3: Getting Weather Conditions Through API

For a project, I wanted the current outside temperature for my local area. For different reasons, I decided on an external choice but mainly because it would be more accurate then dangling a temperature sensor out of the window!

I will walk you through the steps of building your own API calls in Python3.


There are many different API’s out there in the wild, some premium and some entirely free. I stumbled upon a site called which has free limited access or the option for a more powerful premium service.
Currently, the accounts have a limit of 60 per minute for their Current Weather API which is well within my needs (1 call per 15 minutes), so I chose this one.

After signing up for a free account, (you do not need to supply a payment method), you are able to create an API key for your app. There should be one already made by default, which I just changed the name of to my current project.


Once you have an API key for your project, you might need to wait for it to activate but it should be ready to use fairly quickly. You are now ready to start building your request!

To make the API request over http, I used the powerful requests library which makes this job more “pythonic” and easier to work with then the standard urllib.

Installing requests is easy with pip:

pip3 install requests

Now we can start building our API call. In a new .py file, add the following.

# requests docs :
import requests

def main():

    # define the GET string for the Http query
    payload = {
               'q': 'London,UK',  # q is the place name for your query
               'units': 'metric',  # units is the unit of measurement
               'APPID': 'YOUR_API_KEY_HERE',  # APPID is for your app's API key (keep secret)

    # The URL for the current weather API call
    # (full docs here:
    api_url = ''

    # make the API call with defined parameters
    query = requests.get(api_url, params=payload)

    # convert raw json response to a python dictionary with json()
    data = query.json()


if __name__ == "__main__":

In the payload dictionary, change the “APPID” to your newly created API key.
Requests will use the supplied payload dictionary to form a complete GET string at the end of the api_url and will automatically build websafe escaping for special characters where required!


If everything is succesful, the data from your API call will be parsed from a raw JSON object into a Python3 dictionary object. Your output will be like so:

  'coord': {
            'lon': -0.13,
            'lat': 51.51
  'weather': [
                'id': 741,
                'main': 'Fog',
                'description': 'fog',
                'icon': '50n'
                'id': 500,
                'main': 'Rain',
                'description': 'light rain',
                'icon': '10n'
                'id': 701,
                'main': 'Mist',
                'description': 'mist',
                'icon': '50n'
  'base': 'stations',
  'main': {
            'temp': -0.01,
            'pressure': 997,
            'humidity': 100,
            'temp_min': -1,
            'temp_max': 1
  'visibility': 8000,
  'wind': {
            'speed': 3.6,
            'deg': 300
  'clouds': {
              'all': 90
  'dt': 1548199200,
  'sys': {
           'type': 1,
           'id': 1414,
           'message': 0.0041,
           'country': 'GB',
           'sunrise': 1548143498,
           'sunset': 1548174807
  'id': 2643743,
  'name': 'London',
  'cod': 200

As you can see, it is mainly made up by a parent dictionary object containing inner lists and child dictionary objects.

You can now navigate the data through the usual way in Python. For example:


will return the wind speed value of “3.6” (m/s) in this example.

And to retreive the current recorded temperature, you will use they key values:


which will return a chilly value of “-0.01” (degrees)!


In just a few lines of Python code you have an endless pit of on-demand data at your fingertips. This is incredibly useful in many different situations, and not limited to the example seen here.

Though this code is simple, it was designed to show a working illustration of using APIs in Python. In a real project, it would be necessary to check the response status to make sure the data has been delivered correctly. Without this, a program can crash by another of exception errors.

Further Implementation

In order to properly use this code into a working application, you may need to think of corner cases to catch exeptions and stop it from crashing in the event of an unexpected circumstance.
For example:

  • What happens if the current device loses internet connection or the URL is unreachable?
  • What happens with a bad API request?
  • What happens if the API key expires or gets blocked?

These 2 cases are infact quite similar, but can lead to many different errors further down the line.

In my case, I will:

  • Check the requests status code first. If this fails, I will record the information as “NULL” and skip everything else.
  • If the status is good, I will use a Try Except clause to access the data through dictionary keys. If the data is somehow not there due to a bad request, I will avoid a ValueError exception and record the data as “NULL” instead.

There might be a few more cases that I havn’t mentioned, but that is down mainly to what YOU decide to do with the data and how important it is for your application.

Questions? Have I missed something?
Comment below!