From 957bc5158a86e6433249966e1caeb902ecb5ac76 Mon Sep 17 00:00:00 2001 From: Lorenzo Cogotti Date: Wed, 11 May 2022 16:31:36 +0200 Subject: [PATCH] [blog/Kat-arena] Add "Not old but vintage" post. --- content/blog/not-old-but-vintage-kat-arena.md | 136 ++++++++++++++++++ 1 file changed, 136 insertions(+) create mode 100644 content/blog/not-old-but-vintage-kat-arena.md diff --git a/content/blog/not-old-but-vintage-kat-arena.md b/content/blog/not-old-but-vintage-kat-arena.md new file mode 100644 index 0000000..c952975 --- /dev/null +++ b/content/blog/not-old-but-vintage-kat-arena.md @@ -0,0 +1,136 @@ +--- +title: "Not old but vintage. Kat-arena" +mobile_menu_title: "Old or vintage. Kat-arena" +date: 2022-05-11 +Author: "Katerina" +description: "Kat-arena takes a glimpse of software aging, a topic ever more relevant today, for video games, for OSes and for numerous software technologies. Just how many ways a software can age?" +series: [ "Kat-arena" ] +categories: [ "software", "open source" ] +tags: [ "Kat-arena", "aging", "software", "open source", "obsolescence" , "feature-creep", "bloatware", "software bloat"] +--- + +# Not old, but vintage + +Recently, Sony announced the creation of a Game Preservation Team, +and the App Store seems to be removing apps that haven’t been +"updated in a significant amount of time". Nowadays, digital preservation +initiatives focus both on hardware and software components, +but it seems tricky. Surely, "Time destroys all things". +However, the software part is not exactly a *thing*, it is a set of +mathematical formulas. So, does it get old? + +The short answer: yes, it does. + +> "Just as we will all (if we are lucky) get old, software aging can, and will occur in all successful products." +> +> -- David Lorge Parnas, Software aging (1994) + +However, you are not here for short answers, aren't you? + +## The many ways to age + +Software ages, and does so in various ways. +Mostly, since software is always part of a complex environment that +sometimes includes other software or even humans. +Naturally, each part is affected by changes on other levels. +Whether they are planned or unintentional, desired or problematic - any change can lead to the software aging. +In fact, it is mostly a question of the aging environment surrounding the soft. +Still, the chain of interactions in time might become so perplexing that +separating software's local issues from external factors might become impossible. + +With this, scientists define *aging* as the accumulation of errors over time in long-running software. +While bugs in the code are the main bad guys, the list of antagonists includes data corruption, +wrong commands, faulty statements, and unexpected interactions +with other software - you know, life is a dangerous endeavor. + +On a basic user level, these issues are often solved by rebooting the entire system and cleaning the memory. +Yet, it is solving the issue in the same way as the "burning down the house to get rid of a scary insect" approach. + +Clearly, the best way to prevent this sort of aging and ensure the system's reliability +is to get rid of bugs in every single software. However, pretty much like in real life - all bugs can never be found... +plus, some of them are features, right? + +I promise I will dive deeper into bugs someday, meanwhile, you may want to check Garg's study (reference below) +to dig further into this subject. + +As the subject is extremely compound, an entire line of research dedicated to solving the issue of software +aging is yet to find a perfect solution. If you are looking for some good suggestions, see the software rejuvenation. + +However, aging may have a different interpretation that is way closer to actual users. +It is the trend for a certain technology. + +For developers, it implies a constant necessity to update their products. +Surely, some of them are vital and greatly improve efficiency, correct bugs, or affect core functions, +but other "new versions" and "cool features" have little to do with real issues. + +In other words, there are numerous perfectly functioning "old" technologies that can be used today and +sometimes are even easier to run and introduce, but they are just "not cool" anymore. + +For example, how many companies have introduced Augmented Reality features to their products +following the Pokémon Go boom? And how many users have activated it in the last year? +The poor result of a constant rush for new features is referred to as **Feature creep.** + +At the same time, new features make code bigger, thus creating more space for bugs. +Those new bugs, in turn, increase the aging process and the demand for new updates. +Curiously, this phenomenon has an amazingly accurate name - **Software bloat,** or **Bloatware.** + +Altogether, it seems like an eternal dev circle where instead of improving an existing product, +companies keep adding new features to stay cool. Fair to say, for many developers and companies, +it becomes so unbearable it is easier to abandon a project completely. + +Compatibility is another issue strongly connected with unbearable development. Software can be +labeled as *old* because it was agreed to be claimed so. This type of old may have +little to do with actual functionality or is often planned by *fundamental* soft +producers such as OS developers. + +It is arguable whether compatibility requirements are completely evil. +The *pro* argument is that *planned aging* encourages software rejuvenation, +so it is a direct way to fight degradation. So, these updates allow a soft to be +"Harder, Better, Faster, Stronger". +However, this improvement is often caused by the bare fact that the *system* is new +which brings back the "burning the house down" approach. + +Along with all the good it brings, it can also kill it completely, +or send the idea to development hell as it will be internally stuck in production unable +to catch the required schedule (think of Duke Nukem Forever or Diablo III). + +Video gamers usually learn about compatibility thanks to +"the game is not supported by the X.Y version or later" or +"this title will not be transported to the next-gen consoles". +Both messages can be translated as "this developer sees no point in updating +it to match new requirements anymore". + +## A mean to live again + +This painful question of whether devs should support their software by the end of time (rightfully) +causes a revolution in fandoms as fans go berserk. +Sometimes this rage brings changes by showing companies that the soft is more popular than it appears to be, +or by introducing an open-source practice. + +Opening a codebase to other developers and users allows the community to directly participate in the development +and provide essential updates to a soft when its original creators are unable to do so, for whatever reason. +With this, open-sourcing is a powerful tool to fight both fast-changing fashions and planned obsolescence. +The product will continue to live (or even grow) as long as there are people interested in it. +Moreover, it can be rediscovered later - just like Bach's music, Kafka's literary heritage, +and many other great works and ideas. + +That's why software supported by the community can receive a particular vintage or even antique charm. + +Yes, it can be argued whether the initial concept behind a soft matches the result of community development, +but isn't it the most amazing thing about ideas - it is stories and how they are changing over time. + +So, on a very poetic level, open sources allow software to fight the brutal degradation of living thing +and join the quasi-eternal existence of great ideas. +Quite an impressive answer to an initially lunatic question, I must say. + +Katerina + +## Sources + +* **S. Garg, A. van Moorsel, K. Vaidyanathan and K. S. Trivedi, *"A methodology for detection and estimation of software aging",* Proceedings Ninth International Symposium on Software Reliability Engineering (Cat. No.98TB100257), 1998, pp. 283-292, DOI: 10.1109/ISSRE.1998.730892.** + +* **David Parnas *"Software aging",* Invited Plenary Talk, Department of Electrical and Computer Engineering McMaster University, Hamilton, Ontario, Canada. 1994.** + +* **Kishor Trivedi *"Software Aging and Software Rejuvenation"*, a lecture for the Networking and Information Technology on 11/05/2022 (accessed on 04/05/2022, )** + +* **Michael Grottke, Rivalino Matias Jr, Kishor S. Trivedi *"The Fundamentals of Software Aging",* workshop at 19st International Symposium on Software Reliability Engineering, 2008 (accessed on 05/05/2022, URL )**