It is the 2146th of March 2020 (aka the 14th of January 2026)
You are 18.97.9.171,
pleased to meet you!
mailto:blog-at-heyrick-dot-eu
Today's blog post is a meandering ramble that pulls together several days worth of content, mostly because it's a lot easier to write than to sort out the images, so I kept putting the image editing off and then it was time to make something to eat and wind down for the night, rinse and repeat for a number of days and...I still didn't manage to pull it off. But, then, I guess it's better to split this stuff rather than fling a juggernaut at you all at once.
Dem brambuls
What would some time off be if it wasn't me against the rapidly growing prickly plants?
I went out and smashed 'em down a bit on Sunday evening, much to Anna's consternation. All of this was done by hand because Sunday.
Brute blunt force trauma and bludgeoning.
I went out for a while on Monday lunchtime to deal with them using little mower. I would need to put the blade on the strimmer to deal with the edges and tidy up, but it's too hot so stuff that. In the following days, by the time I had roused myself and inserted enough tea into me to want to go and do anything, the sun was blazing down and, well...
Now with added four stroke!
Later on on Tuesday it came over a bit hazy so I went and did the mowing. So that's that done... for now. ☺
Forecast
It looks like "pretty hot" for the remainder of this week and "good grief" for next week. In terms of numbers, it is forecast to be 28-32°C until Sunday, 36°C on Monday sliding slowly down to low 30s through the week, and only falling below 30°C when it rains next Monday.
I'm sure my cow-orkers will appreciate some decent weather on their days off; and I'm glad I don't have to be driving anywhere when it is near body temperature outside.
A more useful RISC OS via Linux
As an alternative to dealing with an emulated RiscPC and a version of RISC OS that is lacking all of the expected customisations, how about a version that is, well, the version I actually use?
It's possible.
I installed Jeffrey's updated vnc_serv on the Pi 3B+. In setting it up, I added the line swap_adjust_menu = true to the configuration file as this device only has two mouse buttons and it doesn't look as if there's any method to use the Menu key for this. I also removed the password as it's just me here.
I then installed the ssvnc client on Linux. There may have been better ones, but it seems that all of the "Flatpak" software reports that it's a 1,1GB download that requires 3.9GB of disc space (regardless of how much is actually needed). Since I don't have a lot of available space, I'm not about to pick one and see what happens.
The visual style of this software seems oddly reminiscent of Windows 3.
Connecting to RISC OS.
I then set it up to talk to the RISC OS machine, which was simply the IP address and the default port (5900) and telling it not to use any sort of encryption - after all, it's RISC OS we're talking about; as shown in the above picture.
I then clicked on Options... and at the bottom of that window Advanced... and at the bottom of that window on Unix ssvncviewer... and in there I ticked the Use X11 Cursor option. This means that you'll see the RISC OS pointer rather than an odd little rectangle.
Save that as a VNC profile to reload to save doing it over and over.
(in the first options window, you might like to set the fullscreen option?)
Finally click Connect to make magic happen and... while it's not especially fast because it is hurling uncompressed bitmaps around but it is functional.
When in the VNC client, the F8 key calls up a menu with various options, and the F9 key toggles fullscreen mode. If you need to actually send either, given that F8 is the Zap undo keypress, press F8 and there's an option in there to send F8 and F9 as necessary.
In the end, on the RISC OS side I chose to reduce my screen to 1280×720 so it would fit into my PC's display as the scrollbars are broken and sort-of-maybe work. I didn't bother reducing the colour depth as, oddly enough, there was not so much difference between 256 colours and 16M colours in terms of speed despite around four times as much data being sent; I think the bottleneck might be in the VNC server actually doing something (especially if it is hooked to the RISC OS centisecond ticker and/or needs to wait upon callbacks) rather than how much data is actually sent at any given time.
The main reason for doing all of this is that I have sftp set up on RISC OS to access my server and a copy of the files that make up the blog system. I didn't fancy trying to replicate this on the PC, and especially I'm not too keen on having multiple copies of the code floating around as that's how things get out of sync. Yes, I know source control deals with that, but it's a private system so I'm not going to dump it all on GitHub...
Anyway, I wanted to do a few things, so I was quite able to use Zap and transfer files to/from the live server using VNC, then switch to Firefox to check everything worked. The main issue was the lack of Adjust for navigating the filesystem, and just getting used to the lagginess which meant that sometimes the windows were not where I thought I'd put them. Neither problem is insurmountable. Given the simplicity of the RISC OS server, it actually worked pretty well.
Additionally, when I wanted to drop an emoji into the HTML, I could look it up under the Character Map and copy its XML decimal entity as shown in the character details tab, and then just ^Y it straight from the clipboard into Zap, as things copied to the Linux clipboard are available to RISC OS, and vice versa.
Editing my blog in Zap using VNC.
Of course, if it is an action that you perform frequently, you can always hijack what is going on to make a simple script file to perform the actions directly, yourself, like this:
Save that somewhere useful, make it executable, and then you can connect simply by running a file.
Blog changes
Nothing too big - one addition and a bugfix.
For a while now, if you called the index.php file and gave it the parameter "siba" the blog system would pull in a page listing the stories in the SIBA series.
For those who don't know/never read, it's a fictional (mostly!) series about a bunch of kids at a boarding school running a pirate TV station, which is sort of a MacGuffin to not only bring these particular characters together, but also grant them access to places and things that would be strictly out of bounds otherwise. If you're reading the desktop version, there's a link in the right-hand panel just a little ways under the calendar.
The blog system now does the exact same thing using the parameter "aisongs" to give a list of my AI generated songs, so you can find them in one place rather than scattered around various different blog posts. You know, if you fancy listening to them, that is. The URL is https://heyrick.eu/blog/index.php?aisongs should you wish to see and/or bookmark it.
The bug fix was the button to switch to the Desktop version on the SIBA (and by extension the AI songs) page(s) failed to work and instead landed you at the most recent blog entry.
This was because it used to take the base filename (index.php), paste on the modifier (?siba) and then append the force-mode parameter (&keitai=0) to generate a valid URL.
However, since the blog system now uses virtual URLs, that is to say, the articles look like ...blog/entry/20250806 rather than ...blog/index.php?diary=20250806, the system fails because that is back-converted into gibberish, namely ...blog/index.php?diary=?siba to which the blog system thinks "bollocks to that" and hands back the most recent article instead (as the diary value equates to zero).
So now the buttons are hardwired to call the index.php file directly, passing the expected parameter. I suppose I should make it virtual paths like /siba and /aisongs but, you know what? I can't be arsed. The stories link back to blog articles so they'll already be ingested by search engines and a billion AI scrapers even if this particular magic value is ignored because it's not a real URL...
Oh, and I think I fixed a typo, but I was concentrating more on my mug of tea so... ☺
Tidying up space on Linux
My main drive is a 32GB USB stick. Which means I have 27.8GiB of available space, and about 26GiB is used. Though, to be fair, this includes some videos that I downloaded and the entire Arduino IDE and the ESP32 suite (which appears to include about a gigabyte of rubbish for the Risc-V processor version, I wonder if I can just delete that as its not relevant?). Certainly, you get more for your disc space with Linux than with Windows.
But the disc space isn't infinite. Sometimes a bit of tidying up is necessary.
If you keep the kernel up to date, then there are some real savings to be made here. I had installed the original kernel this system had, the current latest, and three in between. I've booted the latest a number of times, it appears to work correctly, so I can trim down my kernels.
Now, this is the part where I should point out that when the Update Manager says that the Linux kernel is about 14MB, this is total bollocks.
Yes, the kernel itself is about that. But it needs modules (about 38MB), extra modules (about 110MB), tools (about 5MB) plus some other things. All of these need to be unpacked, and then repacked as a vmlinuz file (the kernel size) and an initrd.img file (something like 70MB) plus some other bits and pieces.
This is a report of my space consumption at the beginning.
Free space before deleting two old kernels.
This is an example of a programmer messing up signed and unsigned variables. I'm surprised nobody had caught this already.
Ummm... so deleting this stuff will use half a gigabyte? Okaaaaayyy......
Two kernels were carefully removed, the Update Manager said so with those exact words. Yes, Update Manager, I used the GUI not the command line.
And afterwards? Here's my space consumption now.
Free space after deleting two old kernels.
Yup. 3.7GB free to 4.4GB free (note, Linux appears to have a major problem in not knowing whether it should be speaking in Megabytes/Gigabytes (in the modern 1000-based definition) or Mebibytes/Gibibytes (in the expected 1024-based definition) so you'll see MB/GB here and MiB/GiB there and, honestly, it's utterly dumb. Files and the data within are all essentially binary (yes, even text files). A byte is eight bits, not 10. A Unicode character is one or more bytes. The processor data bus size is 32 bits (older processors) or 64 bits (newer ones, like this PC), this is known as the 'word' size. A series of bytes are read from media (maybe as words for speed) and pushed into byte or word sized bits of memory. At no point in any part of this process is base ten anything used or inferred, so I'm kind of annoyed that people have been so eager to switch over to SI-based mega/gigabytes, which is mostly a fantasy created by people selling storage media to make it seem larger than it really is. We should have renamed MB/GB to MiB/GiB and been done with it, rather than this bullshit of having different bits of software report entirely different sizes of things depending on what interpretation it is using.
Anyway, some 0.7 "G" freed. Whether giga or gibi that is quite a lot, really, just for removing two older kernels. I have left the current and the two prior "just in case".
Gimp fade-out transparency
This is mostly a note to myself after playing with Gimp for a while to get the fade-out as shown in the picture with the weird free space.
Import origin PNG
Crop as desired.
Add "Background" transparency layer, push it to the back.
Merge visible layers (do NOT flatten).
Add layer mask (black, full transparency).
Image vanishes, replaced by "transparent". This is correct.
Use gradient tool; foreground to transparent. Drag to place.
Image partially returns, controlled by where the gradient has been set.
Export as PNG.
Nemo's broken thumbnails?
Nemo, the Linux file manager and not the typographic celebrity known to us RISC OS users, has the ability to create thumbnails of various things. Images, videos, PDFs, album art in MP3s...
Unfortunately it appears as if Nemo may record a hash of the file name and ignore other metadata easily read from the directory catalogue such as modification date or file length.
Why? Well, let's imagine that I get an AI song. I load it into Audacity and edit it. It is saved as the filename with " (fixed)" added to the end. Then I do whatever to set up ID3 fields including album art. In my case this is a two-step process using puddletag to write the boring regular tags, and then the file is copied to my phone so I can pick up the song's lyrics (from the Suno app) along with wherever the album art came from.
Then the songs on the PC, the intermediate stage ones, are archived and deleted, and the final edits with lyrics and artwork are copied back from my phone onto the PC.
No album art. Nemo won't even try. Because despite being entirely different files, Nemo knows that it failed to find a thumbnail for this file at this location.
This is fixable. Fairly easily, but it was convoluted to work out how, so I'll tell you here.
Open the Terminal and enter:
nemo -q
What that does is forcibly kill the Nemo file manager. No, this won't cause the desktop to explode or all your icons to vanish, this is Linux not Windows. ☺
Then enter:
rm -r ~/.cache/thumbnails/fail
This takes the cache of what files failed to generate thumbnails and nukes it. Technically this means Nemo is going to need to retry for files it isn't going to be able to get results from, but doing that will take a lot less time than trying to work out which failure files relate to which actual file.
You can, if you want, pop this into a text file and save it (without an extension) and make it executable so you can run it if/when needed instead of typing in all of that stuff again.
Then, well, then all your thumbnails will be generated the next time you start Nemo and go to the relevant directory.
Album art in the directory viewer - and a sneak preview.
Linux boot failure
It seems that Linux is happier booting with the splash screen turned off, but this morning it failed to boot from cold. As I had something on the screen, this is what it said.
Oh, the irony. The. Irony.
Interestingly, looking for similar in the next (successful) boot, there was a lot of difference:
Aug 07 09:11:56 Rick-E200HA systemd[1]: Starting dbus.service - D-Bus System Message Bus...
Aug 07 09:11:56 Rick-E200HA kernel: input: Intel HDMI/DP LPE Audio HDMI/DP,pcm=1 as /devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card1/input12
Aug 07 09:11:56 Rick-E200HA kernel: input: Intel HDMI/DP LPE Audio HDMI/DP,pcm=2 as /devices/pci0000:00/0000:00:02.0/hdmi-lpe-audio/sound/card1/input13
Aug 07 09:11:56 Rick-E200HA (cron)[685]: cron.service: Referenced but unset environment variable evaluates to an empty string: EXTRA_OPTS
Aug 07 09:11:56 Rick-E200HA systemd[1]: Started dmesg.service - Save initial kernel messages after boot.
Aug 07 09:11:56 Rick-E200HA systemd[1]: Starting e2scrub_reap.service - Remove Stale Online ext4 Metadata Check Snapshots...
Aug 07 09:11:56 Rick-E200HA systemd[1]: getty-static.service - getty on tty2-tty6 if dbus and logind are not available was skipped because of an unmet
condition check (ConditionPathExists=!/usr/bin/dbus-daemon).
Aug 07 09:11:56 Rick-E200HA systemd[1]: Starting gpu-manager.service - Detect the available GPUs and deal with any system changes...
Aug 07 09:11:56 Rick-E200HA cron[685]: (CRON) INFO (pidfile fd = 3)
Aug 07 09:11:56 Rick-E200HA (uetoothd)[682]: bluetooth.service: ConfigurationDirectory 'bluetooth' already exists but the mode is different. (File syst
em: 755 ConfigurationDirectoryMode: 555)
Aug 07 09:11:56 Rick-E200HA systemd[1]: Starting grub-common.service - Record successful boot for GRUB...
The things in italics are what's different here. I wonder, is this cold boot problem due to Linux or is something just not coming up quickly enough and Linux gets confused? 🤷
There was supposed to be more and some AI songs, as hinted above, but, well, I got sidetracked. A lot. So I'll stop here and pick up on the rest maybe tomorrow...
Your comments:
Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺ As of February 2025, commenting is no longer available to UK residents, following the implementation of the vague and overly broad Online Safety Act. You must tick the box below to verify that you are not a UK resident, and you expressly agree if you are in fact a UK resident that you will indemnify me (Richard Murray), as well as the person maintaining my site (Rob O'Donnell), the hosting providers, and so on. It's a shitty law, complain to your MP. It's not that I don't want to hear from my British friends, it's because your country makes stupid laws.
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.
Rick, 7th August 2025, 22:40
Oh, and I also fixed the problem with the width of the right-hand panel being messed up...at long last...? 😉
Rick, 7th August 2025, 23:05
Additionally, regarding the VNC server, while it warns that using zlib compression takes a lot of CPU time, this was likely written in the days of the RiscPC. With modern hardware, such as a Pi running 1.2-1.4GHz, you can put in "zlib_level = 4" underneath the "swap_adjust_menu" entry, and this will provide a *significant* speed boost.
Just tried it now and, honestly, I don't know why I didn't try it earlier. 🤷
Rick, 7th August 2025, 23:08
Oh, and I've also figured out the VNC viewer scrollbar brokenness (by accident). Clicking the left mouse button will scroll down/right, while clicking the right mouse button will sort of go the other way in smaller jumps. It's a non-standard and, frankly bizarre, way to do scrollbars. But at least now I know I can move them in both senses.
jgh, 7th August 2025, 23:29
I forgot to take any "before" pictures, but I spent last weekend (yes, all weekend) doing my equivalent, clearing out all the weeds from my back lane: pics.mdfs.net/2025/08/
YEAH GOD! I was aching afterwards. Some of them were waist high, and to get them cleared properly required crawling along on hands and knees to properly pull and dig them out by the roots.
Zerosquare, 7th August 2025, 23:40
Using a USB stick as a root filesystem is unwise -- unlike SSDs, neither their hardware nor their firmware is designed to deal with those read/write patterns and the data integrity requirements. Besides poor performance, this can also cause eventual data loss with no warning.
Rick, 8th August 2025, 00:20
Yup, I'm going to have to sort out using my XP box to copy an image to a backup USB key.
The machine has a dinky little power supply so I'm not sure how well it would function with spinning rust, not to mention the fragility. And the internal SSD is only 32GB (non upgradable) and I'm not quite ready to kill Windows yet (though, getting close).
While there is a risk inherent in using a USB key, this is mostly a "I'm learning how to do this" setup. If I trash it hard, or it trashes itself, it'll be annoying but then I'll just put in the *other* USB key (the LiveCD one) and reinstall.
This web page is licenced for your personal, private, non-commercial use only. No automated processing by advertising systems is permitted.
RIPA notice: No consent is given for interception of page transmission.