How do you feel about this article? Help us to provide better content for you.
Thank you! Your feedback has been received.
There was a problem submitting your feedback, please try again later.
What do you think of this article?
Designed by vectorjuice / Freepik.
Software is frequently critical to the operation of hardware and increasingly something which must be regularly updated in order to remain secure, or even continue functioning.
In previous articles, we took a look at right to repair and striking the suitability balance, and some of the tools for enabling right to repair. In this article, we now turn our attention to software, which is frequently critical to the operation of hardware and may run directly on this, as well as remotely as part of a cloud service which provides associated services. In either case, whether device updates cease to be made available or a cloud service is shut down, it can have serious implications.
As products become increasingly software-enabled — whether a mobile phone, television, bulb or even just a light switch — premature obsolescence will continue to be a growing problem. However, as is often the case, there are solutions to such problems and this starts with awareness of the issues.
Software and SaaS
Whether software runs locally on a device or is delivered as software-as-a-service (SaaS) as part of a cloud offering, it can be critical to the operation of hardware. Failure to update on-device software may result in reduced functionality if it connects to some other system or service which has been updated — else at the very least may present a security risk if newly discovered vulnerabilities are not fixed. In a sense, much software can be thought of as a living thing, which must be updated from time to time, with bugs patched and security fixes, and updates that enable it to continue to play well with other software and online services, which in turn will also evolve over time.
Software that is delivered as a service however can render a device completely useless if for whatever reason this is not available. Short-term outages can be a major inconvenience, while a platform permanently going offline may mean that hardware has to be completely replaced.
Internet of Things
Internet of Things (IoT) products frequently make the headlines when a start-up fails or a particular product is made end-of-life, perhaps following an acquisition and restructuring of priorities. And what once felt like a brilliant idea suddenly seems much less so, as a fleet of smart devices at best suffer drastically reduced functionality, and at worst are headed towards landfill.
However, it needn’t have to be this way.
Local device APIs — which is to say those which can be accessed via the local network and without an Internet connection — can be the saviour of smart devices which were otherwise destined for an untimely end, by providing them with a new lease of life when a cloud service and its associated APIs are no more. With these, instead of an application such as a smartphone app connecting to a cloud service, it simply connects over the local network to the device directly. Sure, so this may mean reduced functionality, but at least the device can still be operated.
However, local APIs don’t always have to mean reduced functionality and can in fact provide a gateway to increased functionality, enabling applications to be developed which integrate with multiple different vendor products — and without the need to ask them for permission.
An excellent example is the WeatherLink Live product from Davis Instruments, which is a networked receiver for their wireless weather stations, that provides both cloud integration and a local API. This is something that was covered in a previous article which looked at how the local API can be used together with a Raspberry Pi to build a weather station dashboard.
There are naturally both good and bad examples of local APIs. The less great ones may try to make it difficult for third-party applications to use them, by implementing various security schemes, which are sometimes overcome by enthusiasts who are keen to retake control of their devices.
At the very least it would not be reasonable to suggest that vendors have a Plan B, whereby device APIs can be opened up should they go out of business or a product be retired. This may at first seem like an unattractive proposition for them, but there is clear value to building consumer trust.
A TPM 2.0 security module.
It is remarkable how, despite the fact that most of us use computers today for the same things we did a decade or more ago, there still seems to be a constant upgrade churn. Of course, gamers and those who work in the creative industries and in technical roles can easily lay valid claim to needing to upgrade more often. However, for many people, it’s the same combination of surfing the web, authoring documents, sending e-mail and such like. Part of this is just wanting newer and better things, which is understandable, but there also feels to be a never-ending push to upgrade.
New O/S features and “eye candy” can make ever greater demands on the hardware and at times can seem a little gratuitous — is my life really made that much better or the job completed that much quicker by that very swish animation? But that is by no means where the story ends.
Apple computers are noted for support being dropped from their operating system after so many generations, thereby forcing an upgrade for new features or just security fixes. Windows 11 meanwhile was in the news with its mandatory requirement for TPM 2.0 security hardware, with those who had recently purchased new high-spec computers without this, understandably upset.
The issues here can be more complex, as it becomes a trade-off between developing new features that are only supported by more recent hardware vs. providing ongoing updates for older systems. However, more of an effort could be made to strike a balance and in the case of Windows 11, why not support systems without TPM 2.0, but perhaps provide a warning that certain security features are not available?
Of course, installing an alternative operating system such as Linux and in particular one of the numerous distributions tailored to older hardware with few resources is also one option. Also, more vendors are providing Linux pre-installed and as an officially supported option, with some niche vendors even specialising in this. However, Linux is far from being a viable option for everyone.
LineageOS Android distribution logo.
Fortunately, the situation is a little better with mobile phones, or at least those which are designed to run the Android operating system, as there are frequently custom “ROMs” (third-party O/S images) available. These attempt to pick up where vendors left off and provide extended support, sometimes for many years after official updates ceased. There are also versions available with a focus on particular features, such as improved security.
Some vendors have even gone so far as to help address the issue in a very proactive manner. Such as Fairphone, who for Fairphone 2 provide “the full open source code, all the tools and the binary blobs that will allow users to build their own Fairphone OS”. While Fairphone OS does not as yet support the Fairphone 4, an option for this is to instead install the open source /e/OS, which Fairphone go as far as providing installation instructions for.
With hardware and sustainability, a lot of the focus is often on physical durability and right to repair. However, with the ever-increasing number of software-defined and software-enabled products, where software plays a fundamental role, there needs to be more consideration given to this and its implications for overall sustainability. It is of little benefit to have hardware which is durable, lasts many years and may be easily serviced if it is rendered useless due to software issues.
If we are serious about sustainability, we need to re-examine various business practices and give consideration to this at the start of not just hardware, but also the software design process.