I installed LibreWolf on my Linux Mint system after reading about it on a fellow blogger’s site (see link below). It installed easily, appeared highly performant, and even took the tab fix I’d written about for Firefox nearly two years ago (again, see link below). I wanted to try this alternative to Firefox because of all the recent drama about how Firefox will now handle personal data; it didn’t go down well at all with a lot of users, myself included. But long before all this happened, I frankly got tired of all the limitations I kept running into using Firefox, so I switched to Vivaldi and haven’t looked back. But hope springs eternal, and I still have a soft spot in my heart for Firefox when it was young and pure of heart. So I decided to install LibreWolf and see if it could rekindle a bit of the old Firefox magic.

After following the clear installation instructions for installing LibreWolf on my Linux Mint system, I tried to use LibreWolf to log into my GitHub account using my Yubico security key. That’s when I got the web page at the top of this post. My Yubico key works just fine with Vivaldi, Google Chrome, and original Firefox on my Linux Mint system. Why LibreWolf, which bills itself as a more secure rebuild of Firefox won’t support my Yubico key is beyond me. That lack of full support is a hard failure as far as I’m concerned. I won’t get rid of LibreWolf as I have more than enough disk space to let it sit on the “shelf” while it matures a bit more. I’ll check out any new versions that drop and see if this problem gets fixed. But if you’re like me and use Firefox with a hardware passkey to log into sites that support it, then I’d give a long hard thought about replacing Firefox with LibreWolf, no matter how you might feel about Firefox at the moment. You will not be happy with that decision, I assure you.

Links

Goodbye Firefox, hello Librewolf

LibreWolf — https://librewolf.net

what browser should i use on linux?

Firefox deletes promise to never sell personal data, asks users not to panic — https://arstechnica.com/tech-policy/2025/02/firefox-deletes-promise-to-never-sell-personal-data-asks-users-not-to-panic/

Yubico — https://www.yubico.com

I have had a need for a simple computer system monitoring tool that would only monitor the system attributes I cared about. I also wanted that monitoring tool to save its measurements to a log file over time, so that I could mine the logs for any trends. I looked at a number of the top utilities (top, atop, btop++, htop) and pretty much marked them off my list, primarily because they measured too much to suite me. I looked at fastfetch and other such tools and dropped them for the same reason, even though you can tailor them with a config file and/or command line switches to only print what I wanted.

I also had a need to bring my Go programming skills back up to some reasonable level of competency and sophistication. I’ve been coding in Go since I first came across it ten years ago, but I never stuck consistently with it. My involvement varied over time. I felt I needed to brush up on the latest version of Go (which as of this writing is at version 1.24.1) and then begin to write software that would motivate me to learn the breadth and depth of the language and all it had to offer. If nothing else I needed a break from my growing frustrations with Rust.

And so I wrote the utility pistat in Go.

The application is simple enough. It gathers the statistics that matter to me, formats them into an easy-to-read format, and then displays them on the terminal as well as writes them to a log file. Along the way I learned how to read and process certain Linux kernel statics as well as write colored text to the terminal (that was interesting) and to navigate my way into creating and using a log file. Every time pistats is run it appends those statistics to its log file in your home directory.

I originally wrote this for my Raspberry Pis, naively thinking that it would be applicable everywhere. Was I ever wrong about that. There are some “cheats” to get it to work with the AMD (Intel) chip-based system I use as my daily driver, specifically for the hardware platform and the core type. I’m not interested in supporting nearly every hardware platform out there, just the two I care about here at home.

I run it inside a terminal window with a single line of fish script: while true; clear && pistats; sleep 60; end. Then I shrink the terminal down to just large enough to hold the text without wrapping, then put it up in the upper right corner of my desktop and go on about my business.

Although the code is in a single nearly 400-line source file, it isn’t monolithic. Each statistic has a subroutine function that’s called to get the statistics. The report is generated in one function, and then separate functions are called to display in the terminal as well as write to the log file. Every function has a comment block explaining what it does, and there is further commenting as needed internal to each function. It may not be pure idiomatic Go code, but I’m a lot more comfortable with Go (again), and that’s a big win for me.

package mainimport ("bufio""errors""fmt""container/list""log""math""net""os""strconv""strings""syscall""time""github.com/logrusorgru/aurora/v4")// osRelease reads the file /etc/os-release and// filters out the PRETTY_NAME of the OS. It also// trims off any spaces and the double quotes around// the pretty OS name.// It returns the result as a string.func osRelease() string {osrelease, error := os.Open("/etc/os-release")if error != nil {log.Fatal(error)}defer osrelease.Close()scanner := bufio.NewScanner(osrelease)var osname = ""for scanner.Scan() {line := scanner.Text()if strings.Contains(line, "PRETTY_NAME=") {osname = strings.Split(line, "=")[1]osname = strings.Trim(osname, " \"")}}return osname}// kernelVersion reads the file /proc/version and// parses out the kernel version. It also trims// off any spaces.// It returns the result as a string.func kernelVersion() string {procversion, error := os.Open("/proc/version")if error != nil {log.Fatal(error)}defer procversion.Close()scanner := bufio.NewScanner(procversion)var version = ""for scanner.Scan() {version = scanner.Text()version = strings.Split(version, " ")[2]version = strings.TrimSpace(version)}return version}// diskUsage reads the full filesystem size and// the free amount of disk space on the filesystem.// It returns the full filesystem size and free filesystem// size as unsigned 64-bit integers.func diskUsage(path string) (uint64, uint64) {fileSystem := syscall.Statfs_t{}error := syscall.Statfs(path, &fileSystem)if error != nil {log.Fatal(error)}all := fileSystem.Blocks * uint64(fileSystem.Bsize)free := fileSystem.Bfree * uint64(fileSystem.Bsize)return all, free}// uptime reads the system up time at /proc/uptime.// It returns the up time as a formated string.// If the uptime is less than 24 hours, it returns just// the uptime in hours.// If the uptime is greater than or equal to 24 hours,// it returns both days and hours.func uptime() string {procUptime, error := os.Open("/proc/uptime")if error != nil {log.Fatal(error)}defer procUptime.Close()scanner := bufio.NewScanner(procUptime)var line = ""for scanner.Scan() {line = scanner.Text()}var secondsUptimeStr = strings.Split(line, " ")[0]secondsUptimeStr = strings.TrimSpace(secondsUptimeStr)var secondsUptime, _ = strconv.ParseFloat(secondsUptimeStr, 32)const SECONDS_IN_A_DAY float64 = 86400.0const SECONDS_IN_AN_HOUR float64 = 3600.0var daysUptime = math.Floor(secondsUptime / SECONDS_IN_A_DAY)secondsUptime -= daysUptime * SECONDS_IN_A_DAYvar hoursUptime = math.Round(secondsUptime / SECONDS_IN_AN_HOUR)if daysUptime > 0.0 {if daysUptime == 1.0 {return fmt.Sprintf("1 day, %.0f hours", hoursUptime)} else {return fmt.Sprintf("%.0f days, %.0f hours",daysUptime, hoursUptime)}} else {return fmt.Sprintf("%.0f hours", hoursUptime)}}// translateMeminfo translates the string parsed from a meminfo// value to an unsigned 64-bit integer.// Because the values in meminfo are already divided by 1024, or 1KiB,// the value returned is in thousands of bytes, not single bytes.func translateMeminfo(line string) uint64 {var meminfoValue = strings.Split(line, ":")[1]meminfoValue = strings.TrimSpace(meminfoValue)var memoryValue = strings.Split(meminfoValue, " ")[0]memoryValue = strings.TrimSpace(memoryValue)var value, _ = strconv.ParseUint(memoryValue, 10, 64)return value}// memInfo parses out MemTotal, MemAvailable, SwapTotal, and SwapFree// from /proc/meminfo.// Because the values in meminfo are already divided by 1024, or 1KiB,// the values returned are in thousands of bytes, not single bytes.func memInfo() (uint64, uint64, uint64, uint64) {meminfo, error := os.Open("/proc/meminfo")if error != nil {log.Fatal(error)}defer meminfo.Close()scanner := bufio.NewScanner(meminfo)var memoryTotal uint64 = 0var memoryFree uint64 = 0var swapTotal uint64 = 0var swapFree uint64 = 0for scanner.Scan() {line := scanner.Text()if strings.Contains(line, "MemTotal:") {memoryTotal = translateMeminfo(line)}if strings.Contains(line, "MemAvailable:") {memoryFree = translateMeminfo(line)}if strings.Contains(line, "SwapTotal:") {swapTotal = translateMeminfo(line)}if strings.Contains(line, "SwapFree:") {swapFree = translateMeminfo(line)}}return memoryTotal, memoryFree, swapTotal, swapFree}// decodeCorePartNumber decodes the CPU part number found in /proc/cpuinfo// and converts it into the human readable ARM core name.// Note this only works with a Raspberry Pi or equivalent.func decodeCorePartNumber(line string) string {var partNumber = strings.Split(line, ":")[1]partNumber = strings.TrimSpace(partNumber)partNumber = strings.ToUpper(partNumber)switch partNumber {case "0XD01":return "Cortex-A32"case "0XD02":return "Cortex-A34"case "0XD03":return "Cortex-A53"case "0XD04":return "Cortex-A35"case "0XD05":return "Cortex-A55"case "0XD06":return "Cortex-A65"case "0XD07":return "Cortex-A57"case "0XD08":return "Cortex-A72"case "0XD09":return "Cortex-A73"case "0XD0A":return "Cortex-A75"case "0XD0B":return "Cortex-A76"case "0XD0D":return "Cortex-A77"case "0XD0E":return "Cortex-A76AE"default:return "NO MATCH"}}// cpuInfo finds the hardware platform name, core type, and core count// from /proc/cpuinfo.//// The kernel file path /sys/devices/virtual/dmi/id/... is tested to see if// it exists, and if it does, then set the hardware platform name to// the string contents of /sys/devices/virtual/dmi/id/product_name.//// This is a personal test for running this application on an AMD-based// MinisForum tiny computer I own.// Return values are the hardware platform name as a string,// the core type as a string, and core count as an integer.func cpuInfo() (string, string, int) {var platform = ""productname, error :=os.ReadFile("/sys/devices/virtual/dmi/id/product_name")if !errors.Is(error, os.ErrNotExist) {platform = strings.TrimSpace(string(productname))}var coreType = ""var coreCount = 0cpuinfo, error := os.Open("/proc/cpuinfo")if error != nil {log.Fatal(error)}defer cpuinfo.Close()scanner := bufio.NewScanner(cpuinfo)for scanner.Scan() {line := scanner.Text()if strings.Contains(line, "Model") && len(platform) == 0 {platform = strings.Split(line, ":")[1]platform = strings.TrimSpace(platform)}if strings.Contains(line, "model name") && len(coreType) == 0 {coreType = strings.Split(line, ":")[1]coreType = strings.Split(coreType,"w/")[0]coreType = strings.TrimSpace(coreType)}if strings.Contains(line, "CPU part") && len(coreType) == 0 {coreType = decodeCorePartNumber(line)}if strings.Contains(line, "processor") {coreCount++}}if error := scanner.Err(); error != nil {log.Fatal(error)}return platform, coreType, coreCount}// hostIP4 returns the host's IP4 dotted address as a string.func hostIP4() string {connection, error := net.Dial("udp", "8.8.8.8:80")if error != nil {log.Fatal(error)}defer connection.Close()address := connection.LocalAddr().(*net.UDPAddr).String()// The address is a UDP address with a port on the end.// Trim that off along with the ':' character.return strings.Split(address,":")[0]}// generateReport generates a list of all the information we wish to// capture in text format.// Returns a list of text strings.func generateReport() *list.List {currentTime := time.Now()formattedTime := currentTime.Format(time.RFC1123)var hostname, error = os.Hostname()if error != nil {hostname = "UNKNOWN"}var platform, cType, cCount = cpuInfo()var memoryTotalK, memoryFreeK, swapTotalK, swapFreeK = memInfo()const GiBK float64 = 1024.0 * 1024.0var diskTotal, diskFree = diskUsage("/")const GiB float64 = 1024.0 * 1024.0 * 1024.0var rep = list.New()rep.PushBack(fmt.Sprintf("%+22s= %s\n", "Current time", formattedTime))rep.PushBack(fmt.Sprintf("%+22s= %s\n", "Host name", hostname))rep.PushBack(fmt.Sprintf("%+22s= %s\n", "Hardware platform", platform))rep.PushBack(fmt.Sprintf("%+22s= %s / %d\n", "Core type / count", cType, cCount))rep.PushBack(fmt.Sprintf("%+22s= %s\n", "Operating system", osRelease()))rep.PushBack(fmt.Sprintf("%+22s= %s\n", "Kernel version", kernelVersion()))rep.PushBack(fmt.Sprintf("%+22s= %.1f GiB / %.1f GiB\n","Memory total / free",float64(memoryTotalK)/GiBK, float64(memoryFreeK)/GiBK))rep.PushBack(fmt.Sprintf("%+22s= %.1f GiB / %.1f GiB\n","Swap total / free",float64(swapTotalK)/GiBK, float64(swapFreeK)/GiBK))rep.PushBack(fmt.Sprintf("%+22s= %.2f GiB\n","Filesystem capacity", float64(diskTotal)/GiB))rep.PushBack(fmt.Sprintf("%+22s= %.2f GiB\n","Filesystem available", float64(diskFree)/GiB))rep.PushBack(fmt.Sprintf("%+22s= %s\n", "Uptime", uptime()))rep.PushBack(fmt.Sprintf("%+22s= %s\n", "IP Address", hostIP4()))return rep}// displayReport takes a list of strings representing the report generated by// generateReport and reformats them into a format suitable for the terminal// screen, including the incorporation of color.func displayReport(report *list.List) {for line := report.Front(); line != nil; line = line.Next() {if str, ok := line.Value.(string); ok {parts := strings.Split(str, "=")fmt.Printf("%s%s", aurora.Red(parts[0]+":").Bold(), parts[1])}}}// logReport takes a list of strings representing the report generated by// generate report and appends them, unmodified and in the order create by// generateReport, at the end of the log file located in// $HOME/.local/share/pistats/pistats.logfunc logReport(report *list.List) {// We want to know our home directory so we can log our report.// Abort the application if we can't get our home directory.// If we can't get our home directory, then we've got Very Big Problems.userHomeDir, err0 := os.UserHomeDir()if err0 != nil {log.Fatal(err0)}// Check to see if we can create a log file for this application by checking// for $HOME/.local/share/pistat at a minimum. If there is a problem then// silently fail and return.logpath := userHomeDir + "/.local/share/pistat/"_, err1 := os.Stat(logpath)if err1 != nil && os.IsNotExist(err1) {if err2 := os.MkdirAll(logpath, 0770); err2 != nil {return}}// Now try to open the log file. The first time this application is run it// will not exist. If we fail to open the log file, then silently fail and// return.fullpath := logpath + "pistats.log"logfile, err3 :=os.OpenFile(fullpath, os.O_APPEND | os.O_WRONLY | os.O_CREATE, 0644)if err3 != nil {return}defer logfile.Close()// The full log file and path exist and it's open. Append the current report// to the log file. Write a blank line to the end to separate reports.for line := report.Front(); line != nil; line = line.Next() {//fmt.Print(line.Value)logfile.WriteString(line.Value.(string))}logfile.WriteString("\n")}func main() {report := generateReport()displayReport(report)logReport(report)}

I came across a post on Jeff Geerling’s blog about how to install Windows 11 as a VM on a Raspberry Pi. Being retired and with plenty of “leisure” time on my hands, I decided to follow along and see what it was like, so I set out to install the same tools using the same essential process he did. I got it to work (barely), but I wasn’t impressed with the results. It took me an entire day to get it all installed and running, only to eventually fail. In the end I deleted everything.

Installation and Setup

Before I get started, let me document my Raspberry Pi 5 setup, because it’s a little different than stock.

• Raspberry Pi 5 Model B Rev 1.0 with up-to-date firmware
• 8 GiB memory
• Raspberry Pi official active cooling fan
• Raspberry Pi M.2 HAT+
• Timetec 512GB M.2 2242 NVMe PCIe Gen3x4 SSD
• Ubuntu 24.04.2 for Raspberry Pi booting off the SSD

The Geerling post links to the creator and developer of the system for installing the ARM version of Windows 11, Botspot Virtual Machine, or BVM, on GitHub. While the directions for installing this is on GitHub, Geerling’s post links to a YouTube video he produced of him installing the software and getting Windows 11 running. I think that video is a bit deceptive concerning how much time it takes to get everything installed. In my case, just getting the ISO downloaded took over seven hours. Here’s a screenshot showing my desktop with System Monitor and a terminal with BVM doing its thing.

The amount of time to download Windows 11 ARM64 can be seen in the middle of the terminal, in the text section beneath “Downloading Windows 11…” There are four consecutive lines of text, with the time it took each operation timed on the far right. Totaled up, it took over seven hours to download the ISO. The download speeds are in the low hundreds of kilobytes. I’ve never seen anything that slow before, even on an old Raspberry Pi 2 or 3. Downloading the virtio drivers took another two hours. And then there was the step installing Windows 11 itself.

Even BVM warned “This will take several hours,” and it wasn’t wrong. It took several hours.

Operation

After a period of nearly 12 hours, from early in the morning until late in the evening, I managed to bring up a small Windows 11 640 x 480 window on the desktop.

I briefly tried to expand that resolution to something more useful, but this version of Windows wouldn’t allow me to change the screen resolution. You’ll note from System Monitor that I nearly exhausted swap. I closed the Windows VM at this point and increased local swap from 1 GiB to 4 GiB. One other notable difference, on Ubuntu at least you need to run bvm boot-gtk instead of bvm boot.

I did follow the BVM README and restarted the Windows 11 VM as headless in one terminal, then ran bvm connect in a second terminal. This produced the screen you see above. Desktop performance was greatly improved and the screen is a little bigger, but I don’t know what the resolution is. Unfortunately I can neither resize nor move it. That window is right smack in the middle of the desktop. I should note once again on System Monitor that swap usage is now at 1.4 GiB. It might be best to run this on a Raspberry Pi with 16 GB. I should also note that even with active cooling running (and the fan did kick in) the CPU temperatures hovered between 60° and 65° C.

Summary

I’m glad I gave this a try. But after these experiences I’m not so certain I’ll keep it on my Raspberry Pi.

Update

I let Windows 11 finish downloading its updates (see the last screenshot above), then I rebooted the Windows 11 VM. After that, headless operation no longer worked. Even bvm boot-gtk no longer worked. So the whole conglomeration was deleted from my Raspberry Pi and all used disk space (in the tens of gigabytes) was recovered. My advice: If you need to get Real Work done, instead of just “bragging rights,” then go shopping on Amazon and pick up one of the current micro PCs with Windows 11 Pro installed for around $300 and use that for your Windows 11 needs.

Links

Windows 11 Arm VMs on a Raspberry Pi, with BVM — https://www.jeffgeerling.com/blog/2025/windows-11-arm-vms-on-raspberry-pi-bvm

Botspot Virtual Machine – Windows 11 QEMU KVM on ARM Linux — https://github.com/Botspot/bvm

migrating to an nvme drive on a raspberry pi 5 — part 2

Once all that was done and the RPi 3 was booted, I did a bit of housekeeping to tweak things to my personal tastes. I was quite happy with the much snappier performance of the RPi 3 under the 32-bit bullseye-based version. I tried to install fastfetch, but it wasn’t in the legacy repo, so I fired up chromium and downloaded a version compiled for the arm7l architecture which the RPi 3 was running as.

I always create a bin directory in my home folder to hold tools I will only run when I’m logged in. I add that local bin to my path as well. That’s where I unpacked fastfetch to. You’ll note that we are indeed running under Raspbian based on Debian bullseye. This is far more advanced than the version on the board when I put it away years ago; Raspbian based on Debian stretch. You’ll also note I bumped the swap space from the default 100 MiB to 2 GiB. Here’s an image of why that’s so important.

With the system booted and running, with three open terminals of which one was running htop, and Chromium up with only one tab pointed at the Raspberry Pi Sense HAT documentation, swap had already hit 139 MiB. Exhausting swap is a guarantee to crashed applications and a system that is so sluggish as to be for all practical purposes locked up. I’ve already documented how to fix this in the first attempt to resurrect this board, link at the bottom. I decided to only expand swap to 2 GiB instead of 4, just to see if I actually needed to. Turns out I didn’t need 4 GiB, and I probably could have even defined even less, such as 1 GiB.

Once the RPi 3 was up and stable I added a few things to the environment to make it more to my liking. I added the Nerd Hack fonts, and set the shell to use them, then I installed the Rust compiler and tool chain. From there I used cargo to install eza, a more sophisticated ls, and bat, a much better cat alternative. The shell above shows the results of using the Nerd Font and eza via an alias for ls. I show this because one of the first major tasks was to get the Sense HAT operational, and for that I installed the sense-hat package.

I point this out because if you follow the instructions for the Sense HAT documentation, the instructions have you install the sense-hat package, then Octave, then go through the steps of calibrating the sense hat. This left me with the erroneous assumption that the calibration software was a part of Octave, which it is not. You do not have to install Octave to work with the Sense HAT. The instructional also state that the result of the calibration, the file RTIMULib.ini, is in two locations, one of which is under ~/.config/sense_hat. There is no ~/.config/sense_hat folder created.

The RPi 3 is now operational enough I can begin to seriously think about using it for headless and unattended operation somewhere around the house. I’ve yet to determine a specific task, but it’s ready for the next step. I intend to install Cockpit on it, as I have with several other Raspberry Pis in my household. If you want to see Cockpit in action, just a teensy bit, here’s two screen captures of it in operation using Chromium on my Raspberry Pi 5 to look at the remote Raspberry Pi 4.

I have a Raspberry Pi 4, 2 GiB, running unattended and headless running Pi-hole. Rather than have to ssh into the system, I installed Cockpit with its much better web-based interface. Most of the time I live in the console.

Right now I have disabled Pi-hole because an update came down the pipes and caused all sorts of screwy issues. That was sometime last year, and I haven’t felt the need to go in and sort it out, including (possibly) a complete re-installation of Pi-hole itself. Of note is the low memory footprint of bookworm, which is what you can get when you’re not running the graphical desktop. That is basically what I’ll do with the RPi 3, which is disable the graphical desktop and install Cockpit on it to manage it remotely.

The final question that needs to be asked is why? Because I have all this incredibly capable computing resources that are literally sitting in a corner doing nothing. I turned 71 last December, and I need to add as much automation to my household as I possibly can to help me and my wife live independent quality lives. I want a household automation system that I control and doesn’t depend on the “cloud.” I don’t want to wake up one day and read that my home devices will no longer work because the company that sold me those devices is going out of business and bricking all my expensive devices. I just won’t put up with that.

Links

Cockpit Project — https://cockpit-project.org/

Pi-hole — https://pi-hole.net/

Rust — https://www.rust-lang.org/

eza — https://github.com/eza-community/eza/

bat — https://github.com/sharkdp/bat/

attempting to restore an old raspberry pi

Here are the necessary steps:

1. sudo apt install flatpak
2. sudo apt install gnome-software-plugin-flatpak
3. flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
4. sudo reboot

Note in step 3 that flatpak will ask for your password in order to perform the equivalent of a sudo operation. Also note that if you don’t add the remote address to FlatHub that you won’t be able to install anything. After the system reboots flatpak will install applications from FlatHub.

There are some quirks with running flatpak on Ubuntu. First of all, you have to install from the command line. Ubuntu’s App Center will not show FlatPak app equivalents like Linux Mint’s Software Manager. So you have to query FlatHub directly, and filter the results. In this example we’ll install GNU Octave. First, we query/filter for the flatpak package.

$ flatpak remote-ls | grep -i octaveGNU Octaveorg.octave.Octave9.2.0stableaarch64

The full package we want to install is org.octave.Octave. Then we install the package.

flatpak install flathub org.octave.Octave

This will trigger a response showing not just the Octave package (or any package, really) to be installed, but a series of runtime and environment files that will also be installed. You have an opportunity to either accept them or not. If you do not accept their installation then the full installation will be aborted.

In the case of Ubuntu the new application is installed in the apps screen (Show Apps) complete with its icon. While this is welcome, it’s a bit frustrating that Canonical/Ubuntu refuse to fully support FlatHub the way they unequivocally support Snaps. Such is life. If you don’t have an easy icon to click on, you can start the application from the command line, like so:

flatpak run org.octave.Octave # command line only# orflatpak run org.octave.Octave --gui # for the desktop GUI

And finally, if you’re curious where everything gets stashed, it’s under /var/lib/flatpak.

Links

FlatPak — https://flatpak.org/

FlatHub — https://flathub.org/

GNU Octave — https://octave.org/

This particular Raspberry Pi is unique in that it’s also the one I first installed Arch Linux on, and then Raspian (well before it was renamed Raspberry Pi OS). It still had Raspian installed, and when I powered it up it still booted and ran. But I wanted to install the current Raspberry Pi OS on it and try to get everything working on top of an up-to-date software platform. And so I did, and that was an interesting “learning experience” that got me wrapped around the axle a bit, to the point I still haven’t done anything with the Sense HAT.

Note that this is the current release of Raspberry Pi OS at the time this post was written. Also note that this Raspberry Pi was limited to 907 MiB, a little less than the 1 GiB of memory soldered to the board. The reason for the memory haircut down to 907 MiB is because it’s being used as the graphics buffer for the video display.

I managed to get btop installed and to get it running so I could keep an eye on how the RPi 3 was behaving. You should now note that I have defined 4 GiB of swap space on the board (look in the disks box). When Raspberry Pi OS is installed “out of the box,” it’s configured with only 512 MiB of swap space total. It didn’t take much work with the default swap space to have applications crash out due to memory and swap exhaustion. Once again I had to edit /etc/dphs-swapfile to get my 4 MiB of swap.

# /etc/dphys-swapfile - user settings for dphys-swapfile package# author Neil Franklin, last modification 2010.05.05# copyright ETH Zuerich Physics Departement#   use under either modified/non-advertising BSD or GPL license# this file is sourced with . so full normal sh syntax applies# the default settings are added as commented out CONF_*=* lines# where we want the swapfile to be, this is the default#CONF_SWAPFILE=/var/swap# set size to absolute value, leaving empty (default) then uses computed value#   you most likely don't want this, unless you have an special disk situationCONF_SWAPSIZE=4096# set size to computed value, this times RAM size, dynamically adapts,#   guarantees that there is enough swap without wasting disk space on excessCONF_SWAPFACTOR=2# restrict size (computed and absolute!) to maximally this limit#   can be set to empty for no limit, but beware of filled partitions!#   this is/was a (outdated?) 32bit kernel limit (in MBytes), do not overrun it#   but is also sensible on 64bit to prevent filling /var or even / partitionCONF_MAXSWAP=4096

Lines 16, 20, and 26 are the lines I modified. So with those modifications I managed to keep more applications up and running, although not very many. As you can see in the btop capture, I’d already reached 658 MiB of swap used, and that was with a web browser (Chromium in this instance) and several terminal windows.

Speaking of web browsers, I tried three on that combination of hardware and software; Firefox, Chromium, and Gnome Web, a.k.a. Epiphany. Of the three I discovered that Gnome Web was the worst, consuming the largest amount of swap, and that it crashed far more than Firefox or Chromium. All I wanted was a web browser to be able to search for and read documentation for certain problems I was encountering while working with this setup. Gnome Web was the least helpful in this regard.

I also had to change from using Wayland to using X11 as the desktop engine. The primary reason for the change is that there are no working screen capture tools under Wayland, but more than a few for X11. After switching to X11 I installed gnome-screenshot (bit of irony there considering how bad Gnome Web was), which allowed me to capture specific application windows for documentation purposes.

After spending far more time than I should have tweaking the constrained environment, I tried to install GNU Octave, because that’s what the Raspberry Pi Sense Hat documentation calls for. There’s a tool in the installation for calibrating the various sensors on the Sense HAT. What I discovered is that the version of GNU Octave is still at 7.3.0, while the version you can get off the Octave website is 9.3.0. I managed to install a more up to date version of Octave via flathub, version 9.2.0;

I opened the application and discovered that it’s quite fast in that environment, amazingly so compared to either Chromium or Firefox. Since this is from the flatpak, I need to investigate how to get the calibration tools out of the flatpak. I have the Octave flatpak installed on my Linux Mint system so I’ll investigate there rather than on the Raspberry Pi 3.

And that’s about it for the moment. I am wondering if I should install the light weight 32-bit version of Raspberry Pi OS onto the Raspberry Pi 3. After all, Raspbian was 32-bit on RPi 3. Or maybe I should put the Sense HAT on a 1 GiB Raspberry Pi 4 I found in my collection and install 64-bit Raspberry Pi OS on that. Decisions, decisions…

Links

Raspberry Pi Sense Hat Documentation — https://www.raspberrypi.com/documentation/accessories/sense-hat.html

GNU Octave — https://octave.org/

I’ve been running Ubuntu on a Raspberry Pi 5 8GB for some time now. All things considered it’s probably the best Linux distribution I’ve run on this little board. I find it to be a well balanced and good looking work environment. I’ve been waiting for the distribution to automatically update to the latest release, 24.04.2. Sure enough it has, but I can’t say with certainty when that happened. What I can say with some surprise is that the kernel for this version on this Raspberry Pi is still at version 6.8.0. I say surprise because all the articles have been trumpeting that kernel version 6.11 would be the new kernel for this point release. But apparently not for Ubuntu 24.04.2 on the Raspberry Pi.

Or at least, not automatically, not right now. To be honest I’m not so sure that I want the current working kernel swapped out for the newer version. Earlier versions of this kernel had problems with the GPIO subsystem, but over time all of that was sorted and now everything works as expected. I’m not interested in performing an upgrade only to discover that working with external GPIO devices is broken again. As the old saying goes, be careful what you ask for, especially with Linux kernel upgrades.

To quiet that output, there is a file in the filesystem at /var/lib/ubuntu-advantage/apt-esm/etc/apt/sources.list.d named ubuntu-esm-apps.sources that you can edit with sudo vi (or whatever editor you prefer) to silence the blather. Here’s what the file looks like after the edit.

# Written by ubuntu-pro-client#Types: deb#URIs: https://esm.ubuntu.com/apps/ubuntu#Suites: noble-apps-security noble-apps-updates#Components: main#Signed-By: /usr/share/keyrings/ubuntu-pro-esm-apps.gpg

Note that every line has a # comment character at the beginning. Excluding line 1, which is a legitimate comment, that’s every line that follows. If I need to re-enable the messages, all I have to do it re-edit the file and remove the comment characters.

This is the Raspberry Pi 5 (hereafter just Pi5) that I’ve been working with since late 2024, with Ubuntu 24.04.1 LTS for the Pi5 installed. It’s been my ambition for some time to build a sophisticated robot around this type of platform (a Raspberry Pi running Linux), more so that what I’ve been tinkering with for some time. I had originally thought to use something based on the early nVidia Orin SBCs, but that fizzled in the late 2010s when I discovered the rough state of the software platform. I had begun to hear about Robot Operating System, or ROS, but did nothing substantive with it until very recently. I’ve now installed ROS 2 on my main system under Linux Mint 22.1 and on my Pi5. I wanted to be able to switch back and forth in case I ran into any issues on the Pi5, to see if the same issues were also on the Linux Mint system.

I also wanted to see if I could indeed install ROS on Linux Mint. ROS officially supports just a few Linux distributions, one of which is Ubuntu 24.04. Since Linux Mint is downstream from Ubuntu, meaning Linux Mint 22.1 is derived from Ubuntu 24.04.1, ROS theoretically should install without issue on my Linux Mint system. Sure enough, it did, and it appears to operate properly so far.

I have more tutorials to get through, and as I said above I’ve not run into any problems. Well, perhaps a little one, easily fixed. When you start rqt the first time, the services are not populated. Close rqt and then reopen it and the services will be properly populated. The tutorial instructions are more complicated than that, but I don’t think they’re necessary.

I’m hoping to reach a point where I can begin to integrate hardware into the software platform sometime in February, and later, a local LLM for autonomous control.

Links

ROS — Robot Operating System — https://www.ros.org/

Rust, the language, has been moving ever deeper into infrastructure development. Rust is being used to write new code (see the drama going on within the Linux kernel developer community as an example). Rust is also being used to replace existing infrastructure, a prime example being the Rust Coreutils being written to replace the GNU Coreutils. The biggest draw to use Rust is its promise of safer memory usage compared to either C or C++ (and yes, they are separate languages and should not be called C/C++). Another draw appears to be better performance between equivalent versions of the same tools, with the performance lead going to the Rust-based rewrites. The biggest draw is that it’s fired up the imaginations of a new generation (if you will) of software developers. It’s all good, even for a very old dog such as myself.

An important re-write in, or migration to, Rust is the fish shell. The fish development team announced in 2024 that they would be migrating to Rust with the version 4 release of fish in 2025. They’ve now reached the point where they announced their first beta release of the shell. I cloned their Github repository and quickly compiled a local copy of the beta release to experiment with. So far, based on my admittedly limited testing, they’ve done an excellent job. Being a beta release I’m sure there are obscure corner cases where this new and major port will have some bugs, but for day-to-day use, so far, the Rust-based beta is indistinguishable from the older C++-based release.

Links

fish — https://fishshell.com

fish on github — https://github.com/fish-shell/fish-shell/

It’s been several days since I stepped up to Linux Mint 22.1. No fuss, just a bit of exploring to tweak the desktop look to use the new Cinnamon styling. I was also pleased to be able to change the size of my menu and have it stick, once set. I’m still using the Papirus icon theme and Nerd Fonts for everything. Linux Mint is still based on Ubuntu 24.04, which is fine as far as I’m concerned. All the software tools I use are reasonably current but not bleeding edge; for example Python on Linux Mint 22.1 is version 3.12.3, while the absolute bleeding edge is version 3.13.1. Even Python 3.12 is at 3.12.8, which tends to irk me as to why the distribution can’t at least keep up with its latest Python baseline. I suspect it’s due to Ubuntu itself.

I do much prefer this release over anything I could get from Microsoft. Everything in my house is either macOS or Linux, split about 50/50. I spend the majority of my time on a Linux system, which explains why I won’t purchase a new Apple computer in the future. I’m going to run everything I have until it literally dies and can’t be upgraded or fixed. For example, my primary Linux system is a Minis Forum UM250 with an AMD Ryzen 5 PRO 2500U CPU. That AMD CPU was launched in 2019. I got the UM250 system in 2020 with Windows 10 Pro preinstalled. It ran for about a year with Windows 10 until I started to get indications that Microsoft wanted to upgrade to Windows 11, but wouldn’t allow the UM250 to upgrade because the little system didn’t have TPM 2.0 installed. It was at that point I purchased a new SSD for the system, swapped it in, and switched to Linux.

My transition to Linux Mint wasn’t straightforward. I tried Pop!_OS and Fedora before finally settling on Linux Mint. The biggest annoyance with both was their insistance of installing and activating brltty, a special Braille driver for the blind. I can certainly appreciate making computers available to the visually challenged, but I’m not one of those (yet), and there wasn’t any way to easily disable the feature for regular use. The brltty driver interfered with my ability to use my USB ports for embedded (IoT) development. I was able to uninstall it for Fedora, but Pop!_OS had it so deeply embedded in the OS that any attempt to remove it would cripple the desktop. In the end for Pop!_OS I had to use systemd to disable the service. Considering how much aggravation I went through for that one problem, I was quick to switch away to Linux Mint, and that’s where I’ve lived ever since.

I have a solid computer with a no-drama operating system that reliably does its job, day-in and day-out. I don’t want or need anything more than that.

For reasons that are a total mystery to me, the latest update to Firefox on Ubuntu 24.04.1 on my RPi 5 has turned into a complete performance hog. That is, every action is dog slow, from opening a page on a website to just navigating between open tabs. After putting up with that behavior for just about a day I installed Chromium and have been using it ever since, such as to write these last two posts.

I wish I could continue to use Firefox, because Firefox could use all the support it can muster right about now, but I think I’ve just about had enough. I only installed Firefox out of habit and inertia; I seldom use it anywhere anymore, choosing either Vivaldi, Chrome, or on rare occasions Safari on my Macs. Firefox is withering away to nothing more than an anachronistic historical footnote. On this RPi 5 system I’ve already purged Firefox, as it makes no sense to keep two browsers if all I’m going to use is Chromium.

I use powerline-shell to configure the shell prompt in my fish shell on all my Linux and macOS systems. It provides a colorized view into where I’m at within the file system, which I find very easy to read. In this post I’m showing how the fish shell is set up on my Raspberry Pi 5 running Ubuntu 24.04.1. To start, I have powerline-shell activated in ~/.config/fish/config.fish, like so:

The configuration for the shell prompt (fish_prompt) is lines 7 to 9 inclusive.

At this point you can stop and get on with your life. After using the initial configuration for a bit, I discovered that I needed to trim the number of segments that were shown in the prompt. In order to do this you need to create a JSON configuration file and then edit that. First you need to create a folder for this configuration file under ~/.config named powerline-shell:

Then you need to create an initial configuration file, like so:

I did the initial generation within the .config folder. These are all the segments, in the order they are displayed within the generated prompt. Of particular interest  to me is the git segment at line 8. When you enter a folder under git control, the prompt will indicate the state of the folder and the files within. I won’t go into any detail, as you can delve into those details at the GitHub location for powerline-shell. You can try it out if you want, and it may be fine for you, because it will give you a quite visual state of git at that location in the file system. The problem I have is how slow it can get with lots and lots of files in a big cloned project. Change directory, or hit return in such a directory, and it can get quite slow to return back to the prompt. So I elected to turn off that feature by deleting the git segment at line 8.

By the way, if you read the GitHub page you’ll discover that powerline-shell supports a number of shells, not just fish.

Links

powerline-shell on GitHub — https://github.com/b-ryan/powerline-shell

It’s not possible to boot from the SD card because the CM5 shipped with the development kit has a 32 GB eMMC drive. Documentation could have been a damn site clearer on this point.

Original Post

For combination birthday and Christmas I gifted myself with a Compute Module 5 Development Kit, which consisted of a Compute Module 5 (CM5), a case, an I/O board, power supply, and various cables and a passive heat sink. The CM5 in the kit came with 4 GiB of memory and 32 GiB of EMMC non-volatile storage. It took a while but I have it up and running with Raspberry Pi OS.

The output of fastfetch is produced without the logo (fastfetch --logo none). I have no desire to waste screen space with the ASCII logo. As you can see it’s based on Debian bookworm with the necessary tweaks to run on the CM5. As you will note in the top photo I have added a 1 TB Samsung 990 Evo Plus NVMe SSD. That was a another gift from another person (or to be more precise, I was given a monetary birthday gift at the company I do part time work for, so I spent that on the Samsung which was on sale at that time). I had wanted to add the SSD to make the CM5 self-hosted, but as I discovered, I needed the SSD to get it up and running. Allow me to explain…

My Tortured Path to a Running System

First and foremost, the SD card slot does not work. I tried multiple cards with the Raspberry Pi OS installed via the RPi Imager, and none of them were seen by the CM5.

In the end I flashed Raspberry Pi OS onto a 128 GB SanDisk Ultra USB 3.0 thumb drive I had in my collection. I have RPi Imager installed on my primary Linux Mint system for just such problems. A nice feature of RPi Imager is that it will allow you to set the host name, WiFi SSID and password, and login account before Raspberry Pi OS is written to the device. Once the OS was written to the thumb drive it would boot the CM5. And once it was booted with the thumb drive, I used RPi Imager on the thumb drive to install Raspberry Pi OS onto the Samsung SSD. It should be noted that RPi Imager is provided for Linux, Mac, and Windows. I would strongly suggest to just go ahead and install it on a working computer you have, just for issues such as this.

Once up and running, I switched the window manager to X11/Openbox. Wayland is crap on the Raspberry Pi for two significant reasons; (1) screen blanking doesn’t work, and (2) all the screen capture tools are either broken under Wayland (scrot) or don’t work as advertised (grim). Going to X11 cleared all this up, and gave me the added benefit of being able to use lxappearance. Raspberry Pi OS uses LXDE, which is still on X11 for all practical purposes. Thus it makes no sense to default to Wayland in spite of all the hype around Wayland.

Let me just say that these few paragraphs could have taken no more than 30 minutes, but to get here it took me days of trying this then that and visiting fora with highly opinionated participants who provided little in the way of practical solutions to the problems I was encountering. So for the future, allow me to summarize:

1. Install RPi-Imager on a support PC (Linux, Mac, or Windows)
2. Obtain a USB 3 minimum thumb drive with at least 32 GB of storage.
3. Install Raspberry Pi OS onto your thumb drive.
4. Install a blank NVMe SSD onto the I/O board.
5. Plug the thumb drive into one of the USB A ports, then power up the system.
6. Once booted into Raspberry Pi on the CM5, start RPi-Imager (rpi-imager at the command line) and install Raspberry Pi OS on the SSD.
7. When complete, power down the CM5, unplug the USB thumb drive, and then power up again.
8. You should now be in Raspberry Pi OS on the SSD.

Once you’re up and running after first boot, use sudo raspi-config to change from Wayland to X11 (X11/Openbox). That’s under 6 Advanced Options | A6 Wayland on the text menus. Reboot one more time and you’re back up under X11 where everything should work as you expect it to.

One other annoyance. Swap is still too small at 500 MB. You can, and should, increase your swap space to 4 GB. I have a link at the bottom to show you how.

Additional Setup

I’ve done a lot so far, but there were two tasks at the top of my punch list; installing nvim (NeoVim) and Python 3.13. There is no official nvim build for the Raspberry Pi OS, so you’re going to have to pull the source code and build it yourself. I did that because I like nvim, and because whomever is in charge of the distribution for the Raspberry Pi decided to build vim 9 without support for Python, which means I couldn’t have my powerline status at the bottom of the vim edit window. Fine. I’ll just use nvim.

I built and installed Python 3.13 side-by-side with the Python 3.11.2 (provided in the Debian 12.8 distribution) because I wanted to use it on the CM5. Python 3.13 is a watershed release and should be the baseline on every Linux distribution. Unfortunately it’s not so I have to build and install on my own.

I wanted to see how the CM5 handled the load with just its passive cooler attached, and based on what I’ve encountered so far (such as building Python 3.13.1), it’s worked just fine. I’m not That Guy to push the clocks or the system beyond its recommended clocks, and there will be projects of mine where the CM5 is enclosed and running unattended. So knowing that a good passive heatsink will help keep things reasonably cool is important to know, at least for me.

Other little tweaks on the system include switching to the fish shell, dropping the Hack Nerd Fonts on the system and using those everywhere, and installing the papirus-icon-theme to get decent icons everywhere (and you’ll need lxappearance to select that icon set).

Before you ask, no, you can’t seem to install Ubuntu on the CM5. Every time I tried it failed. And that’s using the Ubuntu provided by RPi-Imager.

More to come…

Update Building Python 3.13

I first ran into the following problem building Python 3.13 beta on Linux Mint 21.3, and now on this version of Raspberry Pi OS. It has to do with installing libmpdec-dev, which isn’t available any longer on distributions based on Debian 12. In order to provide the required files, you’ll need to find and download the following individual deb files:

sudo apt install ./libmpdec3_2.5.1-1_arm64.debsudo apt install ./libmpdec-dev_2.5.1-1_arm64.deb

There may be more up-to-date versions of those packages, but I didn’t find them.

Links

increasing swapfile space on the raspberry pi 4

building python 3.13.0 beta 1 on linux mint 21.3

What is this instruction, and why must it be tweaked to work with fish? Before I answer that let me say that too many Linux/Unix users try to be too clever by half, especially the official documentation and how-to instruction writers. But I digress…

What you want to do is to create a one-line text file at /etc/apt/sources.list.d/docker.list that contains this line for this version of Linux Mint:

deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu noble stable

You’re welcome.

And this is the bit of overly complicated fish script that will accomplish this:

echo \"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \$(string split = $(grep UBUNTU_CODENAME /etc/os-release) -f 2) stable" | \sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

All the fish specific magic is on line 3. It’s here we search for the line containing UBUNTU_CODENAME in /etc/os-release, split the line on the equals sign, and then use the second element returned in the string array. You can save yourself some aggravation by just copying the result line and then using sudo to echo that one line to /etc/apt/sources.list.d/docker.list. You still have to do some more work, which is at the official Docker documentation site, in the links below. What you want to focus on is “Install using the apt repository.”

Links

Install Docker Engine on Ubuntu — https://docs.docker.com/engine/install/ubuntu/

I’ve spent yesterday evening and today performing a clean installation of Linux Mint 22 and then moving my content over to it. I’ve been grumbling about abandoning Mint because of its atrocious update tool. I’d spoken about moving back to either Fedora (41) or Ubuntu (24.10). So I swapped a blank SSD into my system, downloaded an ISO of each distribution and installed them one by one onto my system to give them both a quick spin. They’re both excellent, but my personal preferences are still towards Linux Mint, regardless of its flaws. In the end I installed Mint 22 and I’ve been tuning it to my liking since late this morning.

Performing a clean install of any operating system allows you to start a-fresh with just the applications and setup you want. By the time I’d reached a point of operational parity with my older Mint installation, my SSD usage with Mint 22 was 10%, compared to 30% with Mint 21.3. And that Mint 22 usage includes all the tool and development folders I copied over from the older Mint system to new system. I don’t know where all the extra cruft came from on the older Mint 21 installation, except perhaps the applications I installed over the years left behind a lot of cache and configuration data when the application was uninstalled.

The newly installed system is performing much better than before. The desktop is snappier and it appears that running tasks finish faster as well. Desktop graphics, especially text, is clearer and cleaner. This is due in no small part to being based on Ubuntu 24.04 LTS and advances in the Cinnamon desktop, although the absolute latest Cinnamon desktop won’t show up until Mint 22.1 officially arrives with Cinnamon 6.4 in tow. It will be interesting to see if the next Mint release updates without any issues on my newish Mint system.

I’ve indulged myself with a new keyboard, the Cooler Master MK770 mechanical keyboard in shades of gray and black. It seems this keyboard has attracted quite a bit of on-line positive coverage. What finally sold me to make the purchase is that it’s a Black Friday sale item for $71. I figured for that price I could give it a try, and if I didn’t like it I could return it.

I ordered on Saturday and it was delivered by Sunday. I’ve spent the last few days learning how to use it and how to ‘program’ the back light colors. I must say I greatly appreciate the feel of the mechanical keys. I also appreciate how heavy and solid the keyboard is. I haven’t felt this kind of keyboard since the late 1970s and early 1980s. That’s when I used IBM keyboards in the IBM ‘moosehead’ terminals at the First National Bank of Atlanta, and the nearly identical keyboards on the original IBM PC and IBM XT personal computers. I’d forgotten how nice such keys were for long periods of typing.

So far I’ve managed to configure the colors using keyboard chording with the function key (the key at the bottom with the Cooler Master logo on it) and other regular keys. It’s a nice light green color.

I’m still getting used to how the arrow keys are positioned on the keyboard. I keep sending the cursor off in unintended directions.

One excellent feature of this keyboard is how it helps and enhances my touch typing. I thought I’d forgotten how, but within an hour of setting up the keyboard I’ve been touch typing like a maniac.

Finally, I’m using the USB-C cable to connect to my Linux system. The cable isn’t all that intrusive.

I never thought I’d get excited over a keyboard, but I am about the MK770. Highly recommended.

For this post I’ve written my devices listing application in Go, which I’ve previously written in Python, C++, and Rust. Here’s the Go listing.

package mainimport (  "errors"  "fmt"  "log"  "os"  "path/filepath"  "strings"  "encoding/json")func main() {  executable, error := os.Executable()  if error != nil {log.Fatal(error)  }  var annotations = make(map[string]string)  jsonPath := filepath.Dir(executable) + "/devices.json"  rawJSON, error := os.ReadFile(jsonPath)  if errors.Is(error, os.ErrNotExist) {fmt.Println("Annotations JSON file not found at:", jsonPath)  } else {json.Unmarshal(rawJSON, &annotations)  }  deviceById := "/dev/serial/by-id/"  files, error := os.ReadDir(deviceById)  if error != nil {log.Fatal(error)  }  for _, file := range files {symlink, _ := filepath.EvalSymlinks(deviceById + file.Name())device := filepath.Base(symlink)suffix := file.Name()[strings.LastIndex(file.Name(), "_")+1:]hexid := strings.Split(suffix, "-")[0]annotation, found := annotations[hexid]if found == true {  fmt.Println(device, "  ", annotation)} else {  fmt.Println(device, "  ", hexid)}  }}

Here’s a typical output. In this example I have three boards plugged into my Linux system, an ESP32-S3, an ESP32-C3, and a Raspberry Pi Pico 2:

ttyACM0Raspberry Pi Pico 2 - MicroPython 1.24.0 - RP2-EC93ttyUSB1ESP32-C3-DevKitC-1-N4 - ESP-IDF 5.3.1 DisplaysttyUSB0ESP32-S3-DevKitC-1.1-N32R8 - MicroPython-1.25.0-preview-xtensa-IDFv5.2.2 2024-11-08 - ESP32S3-7814

You can see the application’s found them all and their associated TTY port. This is quite useful when using command-line tools to communicated with them individually.

And finally, here’s a section of the JSON file the application reads in in order to match annotations with devices I have plugged in:

{  ...  "7a1c74c68740ec93": "Raspberry Pi Pico 2 - MicroPython 1.24.0 - RP2-EC93",  "7eab1642dbfaeb1198773ca4c6d924ec": "ESP32-C3-DevKitC-1-N4 - ESP-IDF 5.3.1 Displays",  "cc2ba0cbe2cfec11973d262686bdcd52": "ESP32-S3-DevKitC-1.1-N32R8 - MicroPython-1.25.0-preview-xtensa-IDFv5.2.2 2024-11-08 - ESP32S3-7814",  ...}

Quick Operational Description.

Here’s a bulleted list of what I’m trying to accomplish with the Go code.

1. When started, determine where in the file system we were started (lines 14 and 18).
2. With that file path, append our annotations file name to it so we can open it (lines 20 through 28). Note that the annotations file is in JSON.
3. If the annotations file exists, read it in and unmarshal it as a map. If the file doesn’t exist, emit a message saying it couldn’t be found and where it is supposed to be located.
4. Look for any devices plugged into the Linux system (line 31).
5. Assuming you find any devices, extract the hex ID from each device name found (lines 38 through 42). Those hex IDs are unique.
6. Try to look up the hex ID in the dictionary you loaded in step 3. If you find an entry, that’s your annotation. Print it out with the device you found in line 41. If there is no entry then print the device with the raw hex ID.

That’s basically it.

Final Thoughts

Life is way too short for me these days. I still like to write software, but now I want a language and supporting tools that make my efforts far more efficient. Go gives me all of that, and more. I started with Go over ten years ago (you can search for my entries in this blog) on very early Raspberry Pis, specifically the 3 and 4. Then I just sort of let it fade away while chasing other new and shiny languages like Rust. Now I’ve come back to Go for good, and will continue to use it for my purposes until I can no longer think in code, let alone write it.

I re-installed System 76’s Cosmic Desktop Alpha 2 into a virtual machine tonight. I know I was a little harsh about Alpha 1, and accused the system of not properly handling keyboard input. It turns out that the problem was actually with QEMU/KVM itself, because the keyboard input problem affected all the virtual machines I have installed on this system. That problem seems to have mysteriously fixed itself (probably with an update), so that keyboard input is acting normal again.

I’ve managed to install Hack Nerd Fonts and the PowerLine packages for both the bash shell as well as vim. I also grabbed and installed fastfetch from the fastfetch git repo. You’ll note that fastfetch shows the desktop is Cosmic under the Wayland graphics subsystem. The overall Cosmic desktop environment alpha 2 has shown solid improvement over alpha 1. I won’t go over any specifics as there’s already plenty written on this releases new and improved features. Rather this is a personal validation of the glowing praise I’ve read so far. It does live up to the praise it’s receiving right now.

Is it good enough to use as a daily driver? For me, not yet. For anyone else, that’s something they’re going to have to determine on a case-by-case basis. Even if it is an alpha, it’s good enough to begin that consideration for many.

In order to update from the command line I would type sudo apt update && sudo apt upgrade -y. The special characters being the ‘&&’ characters between the apt commands. This morning I could not type those characters. Those characters are on the ‘7’ numeric key, and are accessed with the shift key. In other words, Pop!_OS suddenly stopped handling the shift key. I don’t know how or why, but any shifted keyboard character was ignored, only showing the unshifted keyboard character in the terminal.

I though about that for a few minutes and then made the decision to delete the VM. I have no idea how long it will be before Pop!_OS hits a release candidate stage, but I won’t be holding my breath. There are already many excellent Linux distributions to choose from such that another entrant had better have a powerful reason to be noticed, let alone used. At this rate of progress I don’t ever see that happening with Pop!_OS.

Links

pop!_os and the cosmic desktop environment