Following the LOCO workshop, I have been exploring the intersection between frugal computing and computer systems. Frugal operating systems -- where the energy costs of system calls and other OS components are minimised -- provide a mechanism for improving frugalness throughout an entire system without requiring every application to be rewritten. On paper, this sounds promising, but in reality it is not so simple.
The Case for Extravagant System APIs
The existing incentives in operating system design do not generally favour frugal systems. In order to provide widespread use, an OS must support a wide array of hardware, and provide an expansive API to userspace (including legacy options that have fallen out of fashion, but have not been fully deprecated).
Supporting different hardware options (including "hot-swapping" components in live systems) requires the OS to have access to (and potentially always load) multiple drivers, even if only one (or even none) will actually be used. This ready-for-anything approach is good from a user perspective, as new peripherals "just work," but also requires an increase in the complexity of the OS and the size of the binary.
A similar problem appears when supporting standards. Compliance with standards documents offer a guarantee about the supported behaviour of an OS. On paper, this is very useful. However, many standards documents specify obscure behaviour that is not frequently used (such as extension headers for IPv6) or dangerous functionality that has not been deprecated (like strcpy
) -- supporting these features adds complexity and risk to the system.
The Case for Frugal System APIs
Received wisdom holds that offering support for obscure, rarely used, and outdated features is preferable to dependency-breaking updates. If, however, unused or dangerous features also have an environmental cost, the argument for removing them becomes significantly stronger. The case for frugal APIs is therefore formed of three components: environmental impact; security; and reliability. Unfortunately, each of these brings complications.
Environmental impact is a clear motive, not least because resource consumption also corresponds to increased operating costs. However, finding useful metrics for environmental impact is very difficult. Energy usage measurements are typically system-wide, so it is difficult to determine which components of an OS have the highest energy costs, and therefore should be modified.
Removing features from an API reduces potential attack surfaces. This is potentially valuable from a security perspective, as it reduces the possibility unknown vulnerabilities. However, changing an API from something familiar to something new could introduce risks, as developers and teams with expertise and institutional knowledge would need to adapt to a new environment. This migration is potentially risky, as they may be unfamiliar with the security requirements of the new API.
Simpler APIs should be easier to test, as there are fewer possible inputs, and fewer outputs. However, frugal APIs are only simpler locally -- while a particular machine need only support the drivers it requires, for example, the OS must still make other drivers available for other machines. As a result, the local configuration will be simpler and therefore easier to test, but the entire OS will be harder to test, as integration tests must cover scenarios where the various removable components are or are not included. This problem is acknowledged in FreeBSD's conditional compilation documentation: the default installation is heavily tested, but custom options -- while potentially useful -- are not all tested centrally.
Closing Thoughts
This is an interesting space to consider. Frugal APIs may be very valuable, but the above complications must first be solved. The significant risks and costs of rewriting much of an OS can only be justified if: good environmental metrics can ensure the work is targeted and effective; effective migration techniques can continue supporting legacy applications while aiding developers in migrating; and OS test frameworks must be updated to provide stronger assurances of reliability for custom kernels. Each of these is a non-trivial (and very interesting!) problem. So, perhaps we can dream of a frugal OS, but for now that dream is still a long way off.