Software

It’s time to replace the Ubuntu Wiki. In fact it was probably time to replace it a few years ago, but we are where we are. It should be a reliable and useful resource for the Ubuntu community. It’s failing at that. We have failed here.

Aside: There are actually multiple wikis in use in the Ubuntu project. The primary one is wiki.ubuntu.com, which has been in use since forever (in Ubuntu terms). It’s the main topic of this post, but the others are certainly in need of some love too.

I appreciate many people already know how to do this, but I’m surprised how many don’t, or don’t realise what it does. Forgive me if you know about this feature of Google Chrome.

A little while back I managed to win two separate eBay auctions for 16GiB DDR3 SODIMMs to install in my ThinkPad T450. This took it from the previously installed 16GiB to the expansive 32GiB.

Then I opened Google Chrome.

I’ve said many times, I don’t consider myself a software developer. Much like I don’t consider myself a professional chef. I can write code, just as I can cook. What I make isn’t ground breaking, but it won’t poison anyone either, and I enjoy doing it.

Coding for me started on the ZX81 in BASIC then on to the Spectrum and other 8-bit microcomputers. I dabbled with Z80 and 6502 assembly language. At college I did COBOL, InfoBASIC and more Z80. When I eventually got a PC in 1990 I taught myself Pascal, via a free compiler for MS-DOS I got on a floppy disk in the post.

This post is more an aide-mémoire for myself, but may be useful to others.

I recently wrote a little story about bugs, the crash reporter and errors website in Ubuntu. Sometimes a user will want to look for their crash reports, and in fact that question came up today on the Ubuntu Discourse.

Back when we shipped Unity desktop as the default desktop environment in Ubuntu, there was a simple button to take a user to their previously uploaded crash reports. There was also an easy, graphical way to disable crash reporting.

This is a bit of a dayjob post, but as I maintain a bunch of snaps in my own time, I figured it’s not out of place here.

Typically when I (or indeed any developer) uses snapcraft to build a snap, a snapcraft.yaml drives the process. I’ll integrate some kind of CI or build system, and start publishing to the Snap Store. Usually, once created, the yaml doesn’t need much in the way of changes. Back when we first started building snaps, we were using Ubuntu 16.04 LTS systems. At runtime the snap would leverage the base of core. The core snap is a super minimal Ubuntu 16.04 LTS runtime environment.

On Thursday I mentioned we were restarting the Snapcraft Clinic. Basically we stand up a regular video call with engineers from the snap and snapcraft team & us from Snap Advocacy. Developers of applications and publishers of snaps are invited to join to troubleshoot.

There was nothing especially secret or private discussed, but as we don’t record or stream the calls, and I don’t have direct permission to mention the applications or people involved, so I’ll keep this a little vague. In future I think we should ask permission and record the outcomes of the calls.

At work we have a forum where developers can discuss packaging Linux applications, specifically as snaps. Sometimes developers just want to pair through a problem to get it either resolved for themselves, or for whatever is blocking to be handed off to the right people.

One strategy for supporting developers we found effective was via regular live video conference. So last year we started the Snapcraft Clinic. On a semi-regular basis we dedicate time to join with anyone who has technical issues with snapping, to help them.

Helping your users stay up to date on their workstation is something I believe OS vendors should endeavour to do, to the best of their ability. Some users aren’t able to find time to install updates, or are irritated by update dialogs. Others are skeptical of their contents, some even block updates completely.

No OS vendor wants to be “That Guy” featuring in the news as millions of their customers are found to be vulnerable on their watch. Equally, respecting the user, given it’s their computing device, is vital too. It’s a difficult balance to strike. Somewhere in between “That Linux distro which nags me constantly to do updates” and “That distro which is outdated and insecure” erring towards the former, is probably the sweet spot.

Before last week, I’d never heard of SonoBus. While on holiday I’d packaged up Spot - a Gtk Spotify client, which I wrote about recently. The next day I made a snap of SonoBus too! I did this because while there were binary builds for Windows and Mac, there was no binary release for Linux, other than in the Arch User Repository.

For those that, like me, didn’t know about SonoBus, it’s an “easy to use application for streaming high-quality, low-latency peer-to-peer audio between devices over the internet or a local network”.

“Printers are devices for causing pain and frustration. They also sometimes print stuff out.” - Me, many times over the years.

I have an HP LaserJet 100 MFP M175nw networked laser printer / scanner / copier. I’ve had it since 2013 where it’s generally worked okay most of the time. We don’t print a ton of things in this house, but when we do, it’s typically urgently required for work or school. It can drop off the network now and then, or just refuse to print sometimes. It’s always useful when it works, and frequently frustrating when it doesn’t.