commit 113060dbce153f38e99f5760ed3d77e701991761 parent dbc7ab8d7cd3267584d5a1cbf15099754edc1a3e Author: viznut_web <viznut_web@web> Date: Fri, 3 Jun 2022 11:46:30 +0200 Diffstat:
| M | software_rot.mdwn | | | 4 | +++- |
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/software_rot.mdwn b/software_rot.mdwn @@ -1,5 +1,7 @@ **Software rot** is generally thought of as degradation of the software due to a changing environment. For example, a program written a decade ago may no longer work with new versions of the libraries it depends on because some of them have changed without retaining backwards compatibility. This kind of thinking encourages a culture where software becomes [[obsolete|obsolescence]] unless it is constantly maintained. -A better approach might be to talk about the reliability of the environment it depends on. Would you build a house on a bog? +A better approach might be to talk about the reliability of the environment the software depends on. Would you build a house on a bog? It is often necessary to build on "bogs" (i.e. "actively developed" platforms), but it might be a good idea to also be compatible with a [[bedrock platform]] whose specifications are static and solid. + +Software rot is a big issue for cultures that constantly produce new programs (such as [[games]] or [[demos|demoscene]]) that are not supposed to be constantly maintained after release. Programs written for classical platforms (such as [[DOS]] or [[NES]]) usually need no post-release maintentance at all, while those written for e.g. [[Linux]] will likely cease working in a decade or two. Sometimes, serious [[media archeology]] work (such as finding specific versions of old libraries) is needed to get a program to run again.