Backwards compatibility
Caveats
Most if not all pages are just rough notes, and these pages as a whole are far from complete. More notes will be added in time, eventually, maybe.
If, from reading these notes, you conclude that I am off my rocker, you won’t be the first, and you may even be right. These pages may simply position me as an acolyte to the late Gene Ray.
No doubt there are a dozen and one reasons why none of this would ever work, but perhaps somewhere deep down there is a tiny fragment that could be used for something.
Contents
Overview
Ideally, everyone would stay up-to-date with the latest version of the operating system. This is however not necessarily possible.
Concerns
Hardware support
With each passing year, the amount of hardware that must remain supported grows endlessly. This includes old hardware standards, old CPU generations etc. Adopting newer CPU targets can drastically reduce the execution speed of the system and built-in applications when run on older generations of CPU.
While there is the Gentoo Linux approach of compiling the system locally to optimise it for your own hardware, this is not a widely practical approach for consumer and business computers.
As such, depending on the decisions taken, users may find themselves trapped on an older version of the system with no recourse.
Application compatibility
Applications may stop working under newer versions of the OS. As widely noted by Microsoft’s Chief Apologist Raymond Chen, this is often due to third-party developer mistakes, which (and Microsoft avoid admitting this part) that exacerbate existing technical limitations, mistakes and design flaws in the language, framework and API. One example noted is the nuisance of having to tell a struct how big it is because the computer is too stupid to figure this out by itself; this development speed bump or pitfall contributes to bugs that may not become apparent until an OS upgrade where the behaviour changes.
Intelligent system engineering is needed to maximise forwards compatibility for application development (and thus backwards compatibility for the OS), to reduce the amount of pitfalls that may cause trouble later on.
Even so, there will be programs that stop working because of unforeseen situations, and the possibility that users are again trapped in an older version of the OS.
Upgrade difficulty
Not every OS has the same ability to be in-place upgraded. Debian Linux manages it fairly well (with various system and application software hiccups and gotchas, such as when Apache changed its security configuration model between Debian releases), while the Red Hat Linux family does not offer in-place upgrades. Microsoft Windows manages major upgrades fairly well considering the immense overcomplexity and fragility of the system.
Effortless and reliable in-place upgrades are critical for keeping computers fully up-to-date; if this fails, users become trapped in older versions of the OS.
Considerations
Application updates and backwards compatibility
Applications themselves may need to support older versions of the OS as well as the most recent version. One example of a situation where this causes trouble is enhancements to the controls library. By making the controls library its own package, multiple versions can co-exist, and newer controls library versions can be made available to older versions of the OS.