Migrating Amateur Radio to Linux, Part One – Requirements

I’ve been a user, developer and system administrator for Linux based systems, and prior to that, Unix based systems, for years. I think my first contact was with a Unix Version 6 system at my second employer, ITT IDEC back in 1980. It was actually Interactive’s IS/1. Since that time, I’ve used just about every variant of Bell Labs’ most famous operating system. Oddly enough though, I haven’t tried to use it for my Amateur Radio hobby before.

This is the start of a short series on how I’m moving from a purely Windows based operating environment to one that is equally usable on Linux and Mac OS/X. I’m targeting OS/X as well because my own personal laptop is a beautiful, but aging, Macbook Air that goes with me everywhere. As I am likely to start doing a lot of business travelling very shortly, I want to be able to take my radios with me, and that means running my digital modes software on the Mac as well as on Linux. (I don’t use my Macbook in the shack as the shack PC is dedicated to amateur radio operating).

Objectives

So that I can monitor my progress, I’m starting by setting some objectives.

High Level

The main objective is to have the same capabilities on Linux and OS/X as I currently have on Windows.
The second, less obvious consequence is to be able to operate across both, or even all three, platforms and keep each platform in sync.
Given the growing penetration of mobile devices, I’m adding a third objective of being able to operate on Android and iOS devices with the same fidelity of information.

The need to maintain fidelity more or less imposes the need to integrate with some form of Cloud based services. I already use Dropbox to keep files in sync across my various Windows, Mac and Linux laptops and with my iPhone and iPad, so that’s an obvious one to use to keep some resources in sync. The other main integration point would be my Station Log.

All licensed amateur radio stations are required to keep a comprehensive log of all contacts made and all stations worked. If I could find a common logging program across all platforms that used a flat file for storage, then I could use Dropbox to sync this. However, there are a number of Cloud based logging platforms now and as I already use HRDLog on Windows and iOS, it makes sense to see if I can use this on Linux and OS/X.

Priority

The first priority is to migrate from Windows to Linux, so my first objective is:

To create a Linux operating environment that provides the same capabilities as my existing Windows environment, in a form that is portable (at a functional level at least) to OS/X and which keeps operating data synchronised across multiple devices

Required capabilities

My current Windows environment provides the following capabilities:

Local logging, using Ham Radio Deluxe version 5
Multiple digital modes using the same
multiple rig control (Icom IC-756ProII and Yaesu FT-817) integrated with the above, using HRD
DXCluster access with spotting and customisable filtering, using HRD
Integration of the local log with HRDLog, eQSL and LOTW
Propagation monitoring, using Afreet’s Ionoprobe
Accurate time synchronisation, using Dimension 4
WSPR and JT65A protocol support
Echolink support

As you can see, the main requirement is for a replacement for HRD. HRD is an amazing piece of software, but it ceased to be freeware a while ago and while I have no problem paying for good software, it has stimulated this re-appraisal.

Anybody who knows Linux, knows that the Unix approach is to construct small, single purpose tools and then use the operating system capabilities to string them together to form tool chains. This contrasts with the Windows and Mac approach of constructing full function software packages. I have seen the merits of both approaches in the appropriate circumstances, so I’m not going to argue that one approach is better; but I am assuming I will need to adopt the mix and match approach with Linux.

More to follow…

Automatic software updates can seriously damage your health

In this post, I’ll tell you the tale of how a software update nearly caused me serious damage, and why. I’ll also show you why you probably shouldn’t be one of Pavlov’s creatures and accept updates to mobile apps automatically.

Evernote is a great product

Since I first found it some years ago (I first registered back in 2008), Evernote has been an integral part of my daily workflow. I use it for just about everything related to the capture, generation and distribution of text.

I use Evernote to capture multi-media notes on multiple devices and and keep them in sync. I maintain a complex hierarchy of notebooks for all sorts of purposes. I have separate notebooks for each client and each project I’m working on.

I also have more notebooks for specific workflows such as writing blog posts. This one started as a collection of notes, before morphing into a Markdown document that can be uploaded to my WordPress blog.

I also maintain a complex hierarchy of Tags and make extensive use of smart searches. All in all, Evernote is one of my core productivity tools. All told, I’ve got thousands of notes in dozens of notebooks.

Evernote’s update policy

Being one of the new generation of Internet software companies, Evernote updates its products on a frequent but irregular basis. This never used to worry me. It does now.

The Problem

Evernote recently made a major change to the Mac client

As far as I was aware, there was no warning that this was going to happen. There was a “A new version of Evernote is available” alert, and yes it did give details of the changes, but I get loads of them, and anyway, who has time to read that stuff?

Again, as far as I am aware, there was no opportunity to evaluate the new release before installing it. No beta. So, my Pavlovian reflexes kicked in and I installed the update. I instantly regretted it.

The new UI was radically different in a number of areas and my carefully constructed workflows were totally disrupted. It pulverised my productivity.

Unfortunately, this happened at a moment when I was particularly busy and just didn’t have the time, or the inclination, to learn a new UI.

Luckily, I was able to revert to the earlier version. The Mac is very easy in that respect. Rename the newly installed Application and drag the old one out of the Trash Can. Peasy.

Changes also made to iPad version

Now came another shock. At some point, the iPad version had been updated as well. I hadn’t used this for a while, so I’m not sure when it happened.
Unfortunately, there is (effectively) no potential to revert to a previous version on the iPad. You could do a device restore, but that’s OTT.

Luckily, the changes were not quite so dramatic and I was able to live with them.

Then the Penny dropped

The mobile “Apps” world is different

All this opened my eyes to a previously hidden consequence of using mobile apps: the user has lost control of the software upgrade process. Yes, I know you have to explicitly update apps from iTunes, but there are so many updates each week that it’s impossible to vet them all before applying them. You just have to trust the developer.

Software update and release processes have changed fundamentally. I’ll cover this in more detail in another blog but essentially, the old mantra of alpha releases, beta releases, community evaluation and then explicit upgrade; has changed.

Be more circumspect

I’ve been taught a lesson, and in this case it was not too painful. The learning points are:

Don’t upgrade Apps automatically
Watch for user community feedback before committing
- i.e. don’t be an early adopter if your business depends on it

It’s a restatement of a previous mantra “never install release the .0 of a newly updated software product: wait for .0.1 or a service pack” The problem is that you are now no longer always able to predict when the next .0 is coming out.

Summary

Treat updates to mobile apps with caution
If the app is critical, don’t upgrade automatically

Next Step

Like I said, this change to software release processes could expose a business to additional risk.

So, take a close look at your mobile app inventory and consider whether you should be blindly hitting the “Update” button.

Oh, and why not let me know if you’ve had a bad experience in this area. I promise I’ll be sympathetic.

Update September 2013

Since writing this post last December, I’ve now successfully migrated to the latest version of Evernote. I had a couple of days downtime and took the plunge. Now that I’ve got used to the changed UI, I like it. However, that doesn’t diminish the need to evaluate changes before committing to them.

Picture by By Roger W. Barbour [Public domain], via Wikimedia Commons

At last – the missing Chrome addon appears

As everybody knows, I use a Macbook Air for most of my work and leisure. I love it. and I did love the built-in Safari browser until Chrome came along. The one feature I missed when moving from Sfari to Chrome was the “Reader” feature. The Reader …

The Reader feature allowed you to re-display a web page with just the main content displayed: i.e. sans all the trimmings that surround blog articles and the like.

Now, Evernote has produced an extension for Chrome that appears to deliver the same experience. Called Evernote Clearly the extension delivers the same functionality as Reader did in Safari, plus you can clip the page straight into Evernote if you wish. As a long time Evernote user, I can see this getting great use.

Try it out for yourself.