11 ms·

Software Rot

232 points by pabs3 1y ago

forgotmypw17 1y ago
This and Lindy Effect factors a lot into my choices for what to use for my projects. My choice for a project I want to be as maintenance-free as possible are special subsets of ASCII/txt, SQLite, Perl, Bash, PHP, HTML, JS, CSS. The subsets I choose are the parts of these languages which have persisted the longest. Using the Lindy Effect for guidance, I've built a stack/framework that works across 20 years of different versions of these languages, which increases the chances of it continuing to work without breaking changes for another 20 years.
- akkartik 1y ago
  For similar considerations + considerations of code size and hackability, I lately almost always prefer the Lua eco-system: https://akkartik.name/freewheeling https://akkartik.name/freewheeling
- eviks 1y ago
  This dogmatic approach means you lose out on ergonomics by using poorly designed tools like bash and perl, so you incur those costs all the time for little potential benefit far away in the future (after all, that effect is just a broad hypothesis)
  - argomo 1y ago
    It has to be weighed against all the time spent learning, evaluating, and struggling with new tools. Personally, I've probably wasted a lot of time learning /new/ that I should have spent learning /well/.
    - eviks 1y ago
      Right, nothing is free, but switching costs is a different argument.
      - deleted 1y ago
        [deleted]
  - forgotmypw17 1y ago
    Is it still dogmatic if I consider Perl to be well-designed and have already evaluated more popular tools?
    - eviks 1y ago
      If "This and Lindy Effect" do not "factors a lot", but instead the major factor is you believe perl is better designed, then no, dogmatism of vague future risk is replaced with pragmatism of the immediate usefulness
    - jwrallie 1y ago
      At the point being discussed, which is not breaking backward compatibility, it indeed is arguably better than more popular tools, and I believe perl has other advantages too.
  - zeta0134 1y ago
    Very helpfully, python has stuck around for just as long and is almost always a better choice against these two specific tools for anything complicated. It's not perfect, but I'm much more likely to open a random python script I wrote 6 years ago and at least recognize what the basic syntax is supposed to be doing. Bash beyond a certain complexity threshold is... hard to parse. Python's standard library is just fine for most tasks, I think. It's got loads of battle tested parsers for common formats. I use it for asset conversion pipelines in my game engines, and it has so far remained portable between windows, linux and mac systems with no maintenance on my part. The only unusual crate I depend on is Pillow, which is also decently well maintained. It becomes significantly less ideal the more pip packages you add to your requirements.txt, but I think that applies to almost anything really. Dependencies suffer their own software rot and thus vastly increase the "attack surface" for this sort of thing.
    - forgotmypw17 1y ago
      My main problem with python is that a script I wrote 6 years ago (or even 1 year ago) is not likely to run without requiring modifications. If it's me running it, that's fine. But if it's someone else that's trying to use installed software, that's not OK.
      - esseph 1y ago
        This is one of the problems that containers help solve - no OS, just the dependencies required to run your code.
        cjfd 1y ago
        It is also quite possible for old containers to no longer build.
        esseph 1y ago
        That's why your build pipeline alerts you when tests no longer work, and then you have a release of the previous build still available for download at any time. This is how containers are released!
  - oguz-ismail 1y ago
    > poorly designed tools like bash and perl Skill issue, plus what's the alternative? Python was close until the 3.x fiasco
    - eviks 1y ago
      Indeed, double skill issue: one with the designers and the other one with the users having poor tool evaluation skills
      - oguz-ismail 1y ago
        > poor tool evaluation skills Both tools in question are installed everywhere and get the job done. There isn't much to evaluate, and nothing to compare against
        eviks 1y ago
        > There isn't much to evaluate, and nothing to compare against These are exactly the skill issues I meant! Git gud in evaluating and you'll be able to come up with many more sophisticated evaluation criteria than the primitive "it's installed everywhere"
        legends2k 1y ago
        While there are other parameters I would consider like maintainability, ergonomics, mind share, ease of deployment, etc. The ubiquitous availability point triumphs most others though. Installation of new toolchain is usually a hassle when the same task can be done with existing tools. Also when I present it in a company setting installing new software and broadening the security attack surface is the first pushback I get.
        eviks 1y ago
        Do you advocate the use of Notepad on Windows to edit text because it already exists? What about the increase in the security attack surface from using languages that make it easy to make mistakes in something basic like quoting/escaping? Does it get in the top 10 of pushbacks?
  - blueflow 1y ago
    Its not "far away in the future". Every other IT job right now is supporting, maintaining and fixing legacy software. These are the software choices of the past and you pay them in manpower.
    - deleted 1y ago
      [deleted]
  - calvinmorrison 1y ago
    Calling perl poorly designed is absurd
- testthetest 1y ago
  It’s getting harder to make perfect choices as projects grow more complex. Even simple products often mean building for iOS, Android, web, backend, etc. You can only lean on html/js for parts of that, but in practice, the mobile apps will probably get rewritten every few years anyway. From my side I think it’s more useful to focus on surfacing issues early. We want to know about bugs, slowdowns, regressions before they hit users, so everything we write is written using TDD. But because unit tests are couple with the environment they "rot" together. So we usually set up monitoring, integration and black-box tests super early on and keep them running as long as the project is online.
- donatj 1y ago
  I love PHP, however since around 7.4 they have become pretty happy to make breaking changes to the language, including recently in ways where you cannot satisfy older and newer versions of the runtime simultaneously. I end up spending often a couple weeks of my life on and off fixing things after every major release.
  - hu3 1y ago
    Was it related to magic quotes or global variables created from user input? If so, the writing has been on the wall for over a decade for these.
bravesoul2 1y ago
JS is hated but if you compile to browser JS that code will run in 2100. If you mainly deal with files / blobs not databases you will have these things in 2100 too. I think a lot of apps can be JS plus Dropbox integration to sync files. Dropbox may rot but make that a plugin (seperate .js file) and offer local read/write too and I think you'd be pretty future proof.
- tekno45 1y ago
  postgres will be around in 2500 lol
  - Kinrany 1y ago
    Postgres will get disassembled into independent composable parts and some other "distribution" of it will be used for a more narrow set of use cases that actually require running the database as a standalone process
- jillesvangurp 1y ago
  Except of course software rot and javascript code bases go hand in hand. You seem to assume, browsers have stopped changing and will be more or less the same 75 years from now. I think you are right that that code might run. But probably in some kind of emulator. In the same way we deal with IBM mainframes right now. Hardware and OS have long since gone the way of the dodo. But you can get stuff running on generic linux machines via emulation. I think we'll start seeing a lot of AI driven code rot management pretty soon. As all the original software developers die off (they've long been retired); that might be the only way to keep these code bases alive. And it's also a potential path to migrating and modernizing code bases. Maybe that will salvage a few still relevant but rotten to the core Javascript code bases.
  - 8n4vidtmkvmk 1y ago
    If they want to introduce html6, they'll add a new doctype. If they want moderner JS they'll do another 'stricter' or file type or what have you. The fact that it will continue to run with zero changes is good enough.
deleted 1y ago
[deleted]
fuzzfactor 1y ago
There were companies not quite worth a $billion who would have never made it that far if they couldn't convince masses of people that platform rot was good for them.
Copenjin 1y ago
> Software rot is a big issue for cultures that constantly produce new programs Cough cough vibing cough cough
- alexshendi 1y ago
  Common Object File Format (COFF)?
  - Copenjin 1y ago
    onomatopoeia, fixed spelling :)
Daub 1y ago
As a software user and teacher, I think about software rot a lot. My concern is that it has a tendency to grow by addition rather than replacement. New features are added whilst the fundamental limits of the architecture are left unattended to. The reason that Blender grew from being an inside joke to a real contender is the painful re-factoring it underwent between 2009 and 2011. In contrast, I can feel the fact that the code in After Effects is now over 30 years old. Its native tracker is slow and ancient and not viable for anything but the most simple of tasks. Tracking was 'improved' by sub-contracting the task to a sub-licensed version of Mocha via a truly inelegant integration hack. There is so much to be said for throwing everything away and starting again, like Apple successfully did with OSX (and Steve Job did to his own career when he left Apple to start Next). However, I also remember how Blackberry tried something similar and in the process lost most of their voodoo.
b_e_n_t_o_n 1y ago
Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as a soap bubble?
- mmackh 1y ago
  Not if software is tied to infrastructure, buildings, etc.
  - tanduv 1y ago
    but even buildings need maintained
    - spauldo 1y ago
      Automation costs a lot. The projects I work on are almost always in the millions of dollars,band they're far from being considered "big" projects. The hardware manufacturers will sell you equipment that runs for thirty years. Companies are reluctant to replace working systems. I replaced a PLC a couple years ago. The software to program it wouldn't run on my laptop because it used the win16 API. It used LL-984 ladder logic, and most people who were experts in that have retired. It's got new shiny IEC-compliant code now, and next they're looking at replacing the Windows 2000 machines they control it with. Once that's done, it'll run with little to no change until probably 2050.
  - b_e_n_t_o_n 1y ago
    Perhaps software should be designed in such a way that despite it working on infrastructure, it can be swapped and discarded.
    - treyd 1y ago
      If it works and isn't broke then why swap or discard it?
    - 8n4vidtmkvmk 1y ago
      I don't want to reformat my fridge.
userbinator 1y ago
those written for e.g. Linux will likely cease working in a decade or two Have we already passed the era of DON'T BREAK USERSPACE when Linus would famously loudly berate anyone who did? I suspect Win32 is still a good target for stability; I have various tiny utilities written decades ago that still work on Win11. With the continued degradation of Microsoft, at least there is WINE.
- szundi 1y ago
  [dead]
- wolvesechoes 1y ago
  I would love ReactOS to succeed.
  - Imustaskforhelp 1y ago
    If I remember correctly, ReactOS just uses wine under the hood. Which can be used in linux and even mac or bsd too. Basically (compile to windows?) seems like a good enough tradeoff to run anywhere, right? But I prefer appimage or flatpak because of the overhead that wine might introduce I suppose
    - wolvesechoes 1y ago
      > If I remember correctly, ReactOS just uses wine under the hood Nah. I think they share some effort and ReactOS team adds patches to WINE codebase, it is a separate thing.
- atq2119 1y ago
  No, the issue in Linux is that userspace has traditionally had a tendency to break itself.
- cookiengineer 1y ago
  You can account for that by using Go, with CGO_ENABLED=0. Then you have a self contained binary that relies solely on the POSIX syscalls.
superkuh 1y ago
Unless explicitly addressed rot rate is proportional to popularity. Unpopular targets, platforms, languages, etc don't get changed and provide a much needed refuge. There are some interpreted languages like perl where a program written today could run on a perl from 2001 and a program from 2001 would run on perl today. And I'm not talking about in a container or with some special version. I'm talking about the system perl. Some popular languages these days can lose forwards compatibility (gain features, etc) within just a few months that every dev will use within a few more months. In these cultures sofware rot is really fast.
- wolvesechoes 1y ago
  > Unpopular targets, platforms, languages, etc don't get changed Ah yes, Windows, some niche OS for hipsters and base-dwellers.
  - superkuh 1y ago
    Windows was an amazing exception to this rule for 2 decades. It's incredibly impressive that win32 still works on modern Windows installs. But that's changing fast now.
icameron 1y ago
Nobody has a better ecosystem of “industrial marine grade code rot resistance” than Microsoft. That I can run the same .NET web app code compiled 20 years ago on a new Server 2025 is an easy experience unequaled by others. Or the same 30 year old VBA macros still doing their thing in Excel 365. There’s a company that knows how to do backwards compatibility.
- szundi 1y ago
  [dead]
- js8 1y ago
  As somebody who works on IBM mainframes, I disagree. IBM is probably the best at forward application compatibility. People will laugh, but they should really look.
  - mkesper 1y ago
    Yes, honestly, when you're talking about planning for 40 years and more of backwards compatibility probably nothing beats IBM systems, and not only the big mainframes but also the smaller systems like AS/400 (nowadays System i). https://en.wikipedia.org/wiki/IBM_i https://en.wikipedia.org/wiki/IBM_i
- mrkeen 1y ago
  I had the opposite experience. Tried out XNA one year for the Global Game Jam. Was somewhat pleased with it. It was gone the next year.
- Cthulhu_ 1y ago
  I suspect this is true for a lot of software; a modern-day JVM can still run Java from 20 years ago as long as you didn't do anything weird, Linux hasn't significantly changed since then, the web is one of the most widely supported and standardized platform out there with the 1996 Space Jam website still working and rendering today as it was back then (your screen just got bigger). Is software rot real? I'm sure, but it's not in the runtime. It's likely in the availability and compatibility of dependencies, and mainly the Node ecosystem.
alexshendi 1y ago
I think once you get rid of dynamic libraries and GUIs your software rot will be greatly reduced.
nektro 1y ago
lovely article aside from this bit: > while those written for e.g. Linux will likely cease working in a decade or two there's nothing to support this claim in practice. linux is incredibly stable
- ajuc 1y ago
  I also noticed this part of the article but for the oposite reason (I think 10-20 years is overly optimistic). I've written a small 2d game for Linux back in 00s. Using C++, SDL and a few other libraries (for example now-abandoned libparagui for GUI). Any time I tried to run it afterwards - I had to recompile it, and a few times I had to basically port it (because libparagui got abandoned and some stuff in libc changed so I couldn't just compile the old libparagui version with the new libc). It's surprisingly hard to make linux binaries that will work even 5 years from now, never mind 10-20 years from now. For comparison I still have games I've written for DOS and windows in 90s and the binaries still work (OK - I had to apply a patch for Turbo Pascal 7 200 MHz bug). The assumptions around linux software is that it will be maintained by infinite number of free programmers so you can change anything and people will sort it out.
  - count-delight 1y ago
    Something I've been pondering recently: It is sometimes said that Apple is notorious on deprecating APIs and breaking backwards-compatibility at a rapid pace, but is it not fundamentally the same that is shared with Linux? Old developers lamenting that they have developed something useful in 2015-2015 that doesn't work in any more in 2025. And if Linux distributions do it and it can be thought to be a form of opinionated design, can Apple be blamed for it? Unix/FreeBSD legacy and all. Of course with Apple ecosystem you need relatively recent hardware and have to pay the annual developer program fee, but the expectation is still the same: if you release something, you should keep it up-to-date and not just "fire and forget" like in Windows and expect it to work. Maybe Windows is the anomaly here.
    - ajuc 1y ago
      Dunno I just never used Apple. It's not very popular over here.
foxrider 1y ago
Python 2 situation opened my eyes to this. To this day I see a lot of py2 stuff floating around, especially around work environments. So much so, in fact, that I had to make scripts that automatically pull the sources of 2.7.18 and build them in the minimal configuration to run stuff.
- Ygg2 1y ago
  Python 2 is a warning about doing backwards compatibility changes too late. As soon as you have a few massive libraries, your backward compatibility risks grow exponentially. C# did just as big of a change by going from type-erased to reified generics. It broke the ecosystem in two (pre- and post- reified generics). No one talks about it, because the ecosystem was so, so tiny, no one encountered it.
  - saurik 1y ago
    It certainly didn't help that they were annoying about it; like, they actively dropped some of the forward compatibility they had added (a key one being if you had already carefully used u and b prefixes on strings) in Python 3.0, and only added it back years later after they struggled to get adoption. If they had started their war with Python 3.5 instead of 3.0 it would be a lot less infuriating.
    - flomo 1y ago
      Not being a python dev, there must have been some huge superficial 'ick'. Back when, I was talking to a python guy and mentioned that Python 3 was coming out. He said something like "we're just going to ignore that until they sober-up and fix it." Which it seems like a lot of people actually did. (or they really sobered-up and rewrote in Go or something.)
      - zahlman 1y ago
        > He said something like "we're just going to ignore that until they sober-up and fix it." Which it seems like a lot of people actually did. "It" was fixed long before the 2.7 official sunset date. Even before the original planned date before it got extended, frankly.
alexjurkiewicz 1y ago
It's hard to take this article seriously. We should write software for DOS because we won't need to maintain it post-release? Maybe software written in the age of DOS was relatively trivial compared to modern tools. Maybe there's a benefit to writing code in Rust rather than C89.
codeflo 1y ago
We as an industry need to seriously tackle the social and market dynamics that lead to this situation. When and why has "stable" become synonymous with "unmaintained"? Why is it that practically every attempt to build a stable abstraction layer has turned out to be significantly less stable than the layer it abstracts over?
- bloppe 1y ago
  At any given moment, there are 6 LTS versions of Ubuntu. Are you proposing that there should be more than that? The tradeoffs are pretty obvious. If you're maintaining a platform, and you want to innovate, you either have to deprecate old functionality or indefinitely increase your scope of responsibilities. On the other hand, if you refuse to innovate, you slide into obscurity as everyone eventually migrates to more innovative platforms. I don't want to change anything about these market and social dynamics. I like innovation
  - tracker1 1y ago
    They aren't still supporting 14.04. How do you get 6? There's one every other year, and they retire one shortly after a new one comes out. They're also pretty quick to shutter non-lts release support each lts generation.
- Ygg2 1y ago
  > When and why has "stable" become synonymous with "unmaintained"? Because the software ecosystem is not static. People want your software to have more features, be more secure, and be more performant. So you and every one of your competitors are on an update treadmill. If you ARE standing (aka being stable) on the treadmill, you'll fall off. If you are on the treadmill you are accumulating code, features, and bug fixes, until you either get too big to maintain or a faster competitor emerges, and people flock to it. Solving this is just as easy as proving all your code is exactly as people wanted AND making sure people don't want anything more ever.
  - codeflo 1y ago
    > People want your software to have more features, have fewer bugs, and not be exploited. So you and every one of your competitors are on an update treadmill. If you ARE stable, you'll probably fall off. If you are on the treadmill you are accumulating code, features, bug fixes, until you either get off or a faster competitor emerges. Runners on treadmills don't actually move forward.
joegibbs 1y ago
I think don’t worry too much about trying to avoid it. Think 5-10 years ahead max, rather than 20. In 20-30 years there’s a good chance that what you’ve written will be obsolete regardless - even if programs from 1995 ran perfectly on modern systems they’d have very few users because of changing tastes. A word processor wouldn’t have networked collaborative editing (fine for GRRM though), an image editor wouldn’t have PNG support, and they wouldn’t be optimised for modern hardware (who would foresee 4K screens and GPUs back then - who knows how we’ll use computers in 2055). There are also always containers if the system needs those old versions.
- whizzter 1y ago
  2005 is already 25 years ago, and what the author is hinting at is the difference in difficulty between keeping 1980s software running vs keeping 2005 software running is momentous. 1980s NES software is "easy" as in emulating a CPU and the associated hardware (naturally there are corner cases in emulation timing that makes it a lot harder, but it's still a limited system). I used to make demos as mentioned in the article, the ones I did for DOS probably all work under DosBox. My early Windows demos on the other hand relied on a "bad" way of doing things with early DirectDraw versions that mimicked how we did things under DOS (ie, write to the framebuffer ourselves). For whatever reason the changes in Vista to the display driver model has made all of them impossible to run in fullscreen (luckily I wrote a GDI variant for windowed mode that still makes it possible to run). Even worse is some stuff we handle at an enterprise customer, Crystal Reports was even endorsed by Microsoft and AFAIK included in Visual Studio installs. Nowadays abandoned by MS and almost by it's owner (SAP), we've tried to maintain an customized printing applications for a customer, relying on obscure DLL's (and even worse the SAP installer builder for some early 2000s install technology that hardly works with modern Visual Studio). Both these examples depend on libraries being installed in a full system, sure one could containerize needed ones but looking at the problem with an archivist eyes, building custom Windows containers for thousands of pieces of software isn't going to be pretty (or even feasible in a legal sense both with copyright and activation systems). Now you could complain about closed source software, but much of a tad more obscure *nix software has a tendency to exhibit a huge part of "works on my machine" mentality, configure scripts and Docker weren't invented in a vacuum.
TacticalCoder 1y ago
> 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. The rot is real but we have a way to run Linux (and any really) software in 40 years. For example: From alpine:3.14 ... Just as I can run thousands of games from the 80s on my vintage CRT arcade cab using a Pi and MAME (with a Pi2JAMMA adapter), I'll be able to run any OCI container in 30 years. The issue of running old software is solved: we've got emulators, VMs, containerization, etc. Sure they may lack security upgrades but we'll always be able to run them in isolation. The rot is not so much that the platform won't exist in the future or that old libs would mysteriously not be available anymore: the problem is that many software aren't islands. It's all the stuff many need to connect to that's often going to be the issue. For games that'd be, say, a game server not available anymore. Or some server validating a program to make sure its license has been paid. Or some centralized protocol that's been "upgraded" or fell into irrelevancy. Or some new file format that's now (legitimately or not) all the shit. Take VLC: there's not a world in which in 40 years I cannot run a VLC version from today. There's always going to be a VM or, heck, even just an old Linux version I can run on bare metal. But VLC ain't an island either: by then we'll have coolmovie-48bits.z277 where z277 is the latest shiny video encoding format. At least that's where I see the problem when running old software.
rgmerk 1y ago
You can't build permanent software in a world where a) everything is connected to everything else, and b) hackers will exploit anything and everything they can get their hands on.
- 8n4vidtmkvmk 1y ago
  Isn't that half the problem right there? Stop connecting everything to everything. Make your app work offline. And for anything that must connect, at least use a well defined API that can swap for some other service. E.g. S3 API is now defacto for block storage.
noduerme 1y ago
I wish I could write all the business logic I write on an NES and never have to worry about requirements going bad. I guess the thing is, if you're writing anything on top of a network layer of any kind, eventually it's going to require patches unless you literally own all the wires and all the nodes in the network, like a secure power plant or some money clearing system in a bank that's been running the same COBOL since the 1960s. And since you're probably not writing code that directly interfaces with the network layer, you're going to be reliant on all the libraries that do, which in turn will be subject to change at the whims of breaking changes in language specs and stuff like that, which in turn are subject to security patches, etc. In other words, if you need your software to live in the dirty world we live in, and not just in a pristine bubble, things are gonna rot. Picking tools and libraries and languages that will rot less quickly however seems like a good idea. Which to me means not chaining myself to anything that hasn't been around for a decade at least. I got royally screwed because 50-60% of my lifetime code output before 2018, and pretty much all the large libraries I had written, were in AS3. In a way, having so much code I would have maintained become forced abandonware was sort of liberating. But now, no more closed source and no more reliance on any libs I don't roll or branch and heavily modify myself.
- gr4vityWall 1y ago
  > 50-60% of my lifetime code output before 2018, and pretty much all the large libraries I had written, were in AS3 Out of curiosity, what kind of work did you do? Regarding our old AS3, did you have any luck with Haxe? I assume it would be a straightforward port.
  - noduerme 1y ago
    HaXe is great fun as a language, and I would definitely consider it now if I were writing a new game from scratch. But I never found anything to be a straightforward port from as3. There was too much unsupported particularly in networking. Too much of what I wrote relied on Adobe's NetConnection and socket implementations, plus other .fl packages that never made it over. Not looking at it right now, but that was pretty much the wall I hit at the time around 2019... there was no build target that wouldn't require rewriting the whole way a multiplayer game platform handled networking to get around the sandbox limitations that you could work inside of in AIR or Flash. Maybe I was just kinda dejected and could have solved it, but instead I moved over to TS and PixiJS, ported some necessary logic and started my whole stack over.
xenodium 1y ago
While Emacs itself is not entirely immune to software rot (external dependencies and all), it’s truly amazing how little to no rot is experienced by elisp software (packages). If you find an Emacs package written 15 years ago, the chances of successfully running out of the box are incredibly high.
- deafpolygon 1y ago
  That... has not been my experience.
- zkry 1y ago
  I was thinking the exact same thing. As long as you're not depending on any external packages things are very stable. Like, if you're package depends on adding advice to some other package's random internal function, then yeah, it could easily break. It's a great feeling knowing any tool I write in Elisp will likely work for the rest of my life as is.
Falkon1313 1y ago
Over the course of my learning and my career, I've kind of gone back and forth on this a bit. On the one hand, software is like a living thing. Once you bring it into this world, you need to nurture it and care for it, because its needs, and the environment around it, and the people who use it, are constantly changing and evolving. This is a beautiful sentiment. On the other hand, it's really nice to just be done with something. To have it completed, finished, move on to something else. And still be able to use the thing you built two or three decades later and have it work just fine. The sheer drudgery of maintenance and porting and constant updates and incompatibilities sucks my will to live. I could be creating something new, building something else, improving something, instead, I'm stuck here doing CPR on everything that I have to keep alive. I'm leaning more and more toward things that will stand on their own in the long-term. Stable. Done. Boring. Lasting. You can always come back and add or fix something if you want. But you don't have to lose sleep just keeping it alive. You can relax and go do other things. I feel like we've put ourselves in a weird predicament with that. I can't help but think of Super Star Trek, originally written in the 1970s on a mainframe, based on a late 1960s program (the original mainframe Star Trek), I think. It was ported to DOS in the 1990s and still runs fine today. There's not a new release every two weeks. Doesn't need to be. Just a typo or bugfix every few years. And they're not that big a deal. -- https://almy.us/sst.html https://almy.us/sst.html I think that's more what we should be striving for. If someone reports a rare bug after 50 years, sure, fix it and make a new release. The rest of your time, you can be doing other stuff.
account42 1y ago
The OS/libraries changing is one example of software rot but another one is requirements changing and you can't completely eliminate that.
cess11 1y ago
I like this one as well. https://how.complexsystems.fail/ https://how.complexsystems.fail/
pvtmert 1y ago
It is interesting that one of the most solid piece of software component that is relatively resistant to rotting is Shell/Bash scripts. (Including Makefiles) Python, Ruby, etc. constantly get obsolete over time, packages get removed from the central repositories, ceasing to work. Obviously shell scripts contain _many_ external dependencies, but overall the semantics are well-defined even if the actual definitions are loose against the shell script itself. P.S: I have written couple of Bash-script projects that are still running (mostly deployment automation scripts) meanwhile, some of which I was being "smart" and wrote them in Python 2.7, unfortunately ceased to function, requiring upgrades...
- benchly 1y ago
  What about C? Is there something to be said for the proximity of the language to the machine language? Maybe that sounds like a dumb question because I am a beginner at coding, so I apologize, but it's something I've recently gotten into via an interest in microcontrollers. A low(er)-level language like C seems to be pretty universally sound, running on just about anything, and seems to have not changed much in a long, long time. But when I was dabbling in both Python and Ruby (on Rails) and .NET framework, I noticed what you mean, as I scooped up some old projects on github thinking I'd add to them and realize that it would be a chore to get them updated.
- prmoustache 1y ago
  Frankly perl5 seems like one that is very resistant to rot. TCL and TK as well.
- 8n4vidtmkvmk 1y ago
  I recently discovered how many of my bash scripts run perfectly fine in git-bash on windows. I was pleased. I believe Bun (yes the js runtime) can run .sh scripts too. And of course under WSL too. So 3 different ways I can run them on Windows. File paths can get a little sketchy but with a couple helpers it's not hard to convert back and forth.
dusted 1y ago
Perfect little text, that article is. Same site has this article about "bedrock platforms" which resonate deeply with me https://permacomputing.net/bedrock_platform/ https://permacomputing.net/bedrock_platform/ Software does not rot, the environment around software, the very foundation which owes its existence: the singular task of enabling the software, is what rots. Let's look at any environment snapshot in time, the software keeps working like it always did.. Start updating the environment, and the software stops working, or rather, the software works fine, but the environment no longer works. I'm not saying never to update software, but, only do it if it increases speed, decreases memory usage, and broadens compatibility. I like things better the way they were. I like things better now than how they will be tomorrow. I can't remember the last time I saw a software update that didn't make it worse.
ManBeardPc 1y ago
Software rot is a big problem in many business tools. Everything not recently built from the tip of main is probably no longer working. APIs change, URLs change, Processes change, newer versions of dependencies no longer work because of version conflicts or deprecation without replacement. The amount of work just to fix the rot is constantly rising. No care is spent to keep things stable. Stable interfaces are really something I learnt to appreciate more and more, even if sometimes crusty and verbose. If it is reliably working don't replace it without a very good reason. I attribute these problems mostly to agile the way it is practiced in many companies. Only thinking in providing "value" per sprint and little to no planning ahead, prioritizing ease of change over everything else.
prinny_ 1y ago
I don’t get the comparison to building a house. Houses have a ton of maintenance. You can’t build a house on steady ground and leave it unattended for 20 years either. And sometimes what you need to do is not even construction type of maintenance, it’s bills, legal paperwork, replacing old furnitures just because you grew tired of that 15 year old sofa etc.
- deleted 1y ago
  [deleted]
- 9rx 1y ago
  Houses do require a ton of maintenance, but typically within a stable environment. Yeah, laws might change every once in a blue moon, and over hundreds of years climate change may alter the patterns of wear and tear, but for all intents and purposes what you know today is likely to still hold for tomorrow. But if you build on a bog, then you've unnecessarily introduced a whole lot of new variables to contend with.
conartist6 1y ago
If you're listening VSCode forkers, ya built on bog
- 8n4vidtmkvmk 1y ago
  I'm sitting on the sidelines, waiting for them to all sink. I guess I don't stand to gain anything, but I'll be happy to keep sipping my beer.
collinmcnulty 1y ago
In my experience, the most common type of rot is that the real world the software describes has changed. For instance, I wrote software that modeled electrical power contracts, and when those real world contracts’ structure changes, no amount of “bedrock platform” is going to prevent that rot.
- 8n4vidtmkvmk 1y ago
  I don't know anything about electrical power, but this reminds me about a story about making assumptions about human relationships. Like, you can legally be your own grandfather. Does your program account for that? Software needs to be flexible to account for new, weird scenarios. Sometimes we just can't predict everything, but we can try.
- Mr_Minderbinder 1y ago
  It can be as simple as a year change. A lot of old software rotted away once the year 2000 rolled around and more unmaintained software will in 2038.
9w389s98s9sjs 1y ago
javascript will run forever!
jongjong 1y ago
This is a good discussion to have. I spend a lot of effort on evaluating dependencies. I look for a number of things like how popular/widely used it is, who the author is (if I recognize them) and I also look at code quality and number of sub-dependencies. If I see a library which is solving a simple problem but it uses a lot of dependencies, I usually don't use that library. Every dependency and sub-dependency is a major risk... If a library author doesn't understand this, I simply cannot trust them. I want the authors of my dependencies to demonstrate some kind of wisdom and care in the way they wrote and packaged their library. I have several open source projects which have been going for over a decade and I rarely need to update them. I was careful about dependencies and also I was careful about what language features I used. Also, every time some dependency gave me too much trouble I replaced it... Now all my dependencies are highly stable and reliable. My open source projects became a kind of a Darwinian selection environment for the best libraries. I think it's why I started recognizing the names of good library authors. They're not always super popular but good devs tend to produce consistent quality and usually gets better with time. So if I see a new library and I recognize the author's name, it's a strong positive signal. It feels nice seeing familiar niche names come up when I'm searching for new libraries to use. It's a small secret club and we're in it.
- 8n4vidtmkvmk 1y ago
  Picking packages based on their author has become a big thing for me. Some authors are awful about backwards compatibility, some are fantabulous. There's a couple folks that have bitten me that I rather despise now and avoid like the plague.
  - jongjong 1y ago
    Haha yeah same here. There are a few authors, libraries and ecosystems I avoid entirely. Others I only use in certain contexts.
roda73 1y ago
This is one of the reasons I absolutely hate Linux based development and operating systems built with it. We all know it now as dependency hell, but what it is in fact is just a lazy shortcut for the current development that will bite you down the path. The corporate software is not a problem, because the corporate users don't care as long as it works now, in the future they will still rely on paid solutions that will continue working for them. For me, I run a local mirror of arch linux, because I don't want to connect to internet all the time to download a library that I might need or some software that I may require. I like it all here, but since I haven't updated in a while I might see some destructive update if I were to choose to update now. This should never happen, another thing that should never happen is if I were to compile an old version of some software. Time and time again, I will find a useful piece of software on github and I will naturally try compiling it, it's never easy, I will have to hunt the dependency it requires, then try compiling old versions of various libraries. It's just stupid, I wish it were easier and built smarter. Yes sometimes I want to run old software, that has no reason not to work. When you look at windows, it all works magically, well it's not magic it's just done smart. On GNU+Linux smart thinking like this is not welcome, it never has been. Instead they rely on huge amounts of people that develop this software, to perpetually update their programs for no reason, but to satisfy a meaningless number of a dependency.
- skydhash 1y ago
  It’s all volunteer work, not some corporation with trillions laying around. If you want something easy, use Debian (or ubuntu). They pretty much have everything under the sun. What you want to have (download software from the net and run it) is what most distro have been trying to avoid. Instead, they vet your code, build it, and add it to a reputable repo. Because no one wants to download postgres from some random sites.
  - gjsman-1000 1y ago
    Last time I checked, Ubuntu/Canonical is a multimillion dollar company, Red Hat is a multibillion dollar company, SuSE sold for $2.5B, and The Linux Foundation has over $250M in revenue to spend only 3% on development of Linux specifically. Enough of the BS of "we're just volunteers" - it's fundamentally broken and the powers that be don't care. If multiple multibillion dollar entities who already contribute don't see the Linux desktop as having a future, if Linus Torvalds himself doesn't care enough to push the Foundation on it; honestly, you probably shouldn't care either. From their perspective, it's a toy, that's only maintained, to make it easier to develop the good stuff.
perrygeo 1y ago
I don't like the term "rot" - your software isn't rotting, it's exactly the same as when you last edited it. The rest of the software ecosystem didn't "rot" either, it evolved. And your old code didn't. "Extinction" seems a much better fit.
- munchler 1y ago
  If we're just going by word meanings, "obsolescence" seems even more apt, but "rot" has an ironic charm that makes it memorable.
- 8n4vidtmkvmk 1y ago
  If the apple remains pristine, but the tree trunk dies, it doesn't much matter that the apple hasn't changed. It dies with the tree.
jgb1984 1y ago
Today we vibecode our software, so the rot is built in from day one!
phkahler 1y ago
I'm looking at GTK here. Don't get me wrong, I like GTK and think it should be the preferred choice of GUI toolkit for many reasons. However, I have the same complaints a lot of people do about constant change and API compatibility issues. In some cases things need to change, but why going form 3 to 4 have menus been removed and require using other constructs? Could you at least provide a wrapper? Don't use event struct members directly, OK use accessor functions... But then you change the names and other details of the functions. It's not a "window" any more, it's a "surface" just because what? Beause Wayland calls them that? API stability is an important feature but these guys are talking about regular (say every 5 years) major version bumps that break things.
- 8n4vidtmkvmk 1y ago
  I never understood those kinds of changes. If you really, really, really want to rename something, deprecate the old thing and make it an alias for the new thing. Don't delete it. Just add compatibility shims. Then after 5 or 10 years, take a pulse of the community. If they've mostly migrated off, go ahead and delete. If it's still actively used... Keep it, or even undeprecate it because clearly it's wanted.
asa400 1y ago
SQLite has an explicitly stated policy on this: "The intent of the developers is to support SQLite through the year 2050." https://www.sqlite.org/lts.html https://www.sqlite.org/lts.html People talk about SQLite's reliability but they should also mention its stability and longevity. It's first-class in both. This is what serious engineering looks like.
- azemetre 1y ago
  Does SQLite talk about how they plan to exist beyond 2050 across multiple lifetimes? Not trying to be chide but it seems like with such a young industry we need better social tools to make sure this effort is preserved for future devs. Churn has been endemic in our industry and it has probably held us back a good 20 years.
  - ectospheno 1y ago
    I’m trying and failing to think of another free software product I honestly expect to still work on my current data past 2050. And this isn’t good enough?
    - azemetre 1y ago
      It's good, but this also assume that the people taking care of this product in the future (which may not even born right now) will hold the same attitudes. How do we plan to make sure the lessons we've learned during development now will still be taught 300 years from now? I'm not putting the onus on sqlite to solve this but they are also the only organization I know of that is taking the idea seriously. Just more thinking in the open and seeing what other people are trying to solve similar problems (ensure teachings continue past their lives) outside the context of universities.
    - SoftTalker 1y ago
      Thinking like this is how we ended up with a panic about Y2K. Programmers in the 1970s and 80s could not conceive that their code would still be running in 2000.
BirAdam 1y ago
The most reliable targets I’ve seen recently are Win32 and CGI. They just work. Linux, Windows, macOS. Decade after decade.
biscuits1 1y ago
". . . whose specifications are static and solid." Well, thats the problem with software. There isn't agreement of such specifications. We aren't working with wood, nails nor forming a sill footing on bedrock.
sbrkYourMmap 1y ago
This is the side effect of open source. And open source philosophy is at fault but rather developers themselves. We heavily rely upon code written by strangers and maintained by individual or a community without any obligation to any guarantees, including comparability and maintainability. At work when we are working with vendors that provide proprietary software we have contractual obligations, that amongst other things requires stable interfaces for long periods of time, and could be held liable for damages. Something modern model of open source can't offer
Vegenoid 1y ago
This is why I put so much effort into working with POSIX shell code, despite its painful syntax. I can be pretty damn sure my knowledge will still be relevant in 30 years. LLMs have also made reading and writing shell code much easier.
kragen 1y ago
Konrad Hinsen calls this "software collapse": when the platform has been eroded out from underneath your software and it collapses. https://hal.science/hal-02117588/document https://hal.science/hal-02117588/document There's no reason such a "bedrock platform"♢ needs to be a shitty pain in the ass like the IBM PC or NES (the examples on https://permacomputing.net/bedrock_platform/ https://permacomputing.net/bedrock_platform/). Those platforms were pragmatic tradeoffs for the existing hardware and fabrication technology in the market at the time, based on then-current knowledge. We know how to do much better tradeoffs now. The 8088 in the IBM PC was 29000 transistors, but the ARM 2 was only 27000 transistors†. Both could run at 8 MHz (the 8088 in its later 8088-2 and 80C88 incarnations), but the ARM 2 was a 32-bit processor that delivered about 4 VAX MIPS at that speed (assuming about ½DMIPS/MHz like the ARM3‡) while the 8088 would only deliver about 0.3 VAX MIPS (it was 0.04DMIPS/MHz). And programming for the 8088's segmented memory model was a huge pain in the ass, and it was crippled by only having 20 address lines. 8088 assembly is full of special-purpose registers that certain instructions have to use; ARM assembly is orthogonal and almost as high-level as C. Same transistor count, same clock speed, dramatically better performance, dramatically better programming experience. Similarly, Unix and Smalltalk came out about the same time as Nova RDOS and RT-11, and for literally the same machines, but the power Unix and Smalltalk put in the hands of users far outstripped that of those worse-designed systems. So, let's put together a bedrock platform that we could actually use for our daily computing in practice. Unlike the NES. ______ ♢ Stanislav Datskovskiy's term: http://www.loper-os.org/?p=55 http://www.loper-os.org/?p=55 † https://en.wikipedia.org/wiki/Transistor_count https://en.wikipedia.org/wiki/Transistor_count ‡ https://netlib.org/performance/html/dhrystone.data.col0.html https://netlib.org/performance/html/dhrystone.data.col0.html but note that the ARM3 had a cache, so this depends on having RAM that can keep up with 8MHz. Both the ARM2 and ARM3 were mostly-1-instruction-per-clock pipelined RISCs with almost exactly the same instruction set. https://en.wikipedia.org/wiki/Acorn_Archimedes https://en.wikipedia.org/wiki/Acorn_Archimedes, https://www.onirom.fr/wiki/blog/21-04-2022_Acorn-Archimedes/ https://www.onirom.fr/wiki/blog/21-04-2022_Acorn-Archimedes/, and its twin https://wardrome.com/acorn-archimedes-the-worlds-first-risc-based-home-computer/ https://wardrome.com/acorn-archimedes-the-worlds-first-risc-... confirm the 8MHz and 4MIPS.
- WalterBright 1y ago
1970-01-01 1y ago
IMHO, you need to address how everyone is dating its superficially attractive cousin - free open source software - before you tackle the issue of it rotting away. When your entire castle rests upon the following language, perhaps it's somewhat your fault when it stops working tomorrow. 15. Disclaimer of Warranty. THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. Limitation of Liability. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
nektro 1y ago
posts like this need to mention capitalism if they want to be taken seriously
1vuio0pswjnm7 1y ago
"HTTP vs HTTPS It is possible to consult this wiki on port 80, that is to say using http:// http:// instead of https:// https://." https://permacomputing.net/about/ https://permacomputing.net/about/ "If you do not have access to git on your operating system, you can download a zip file that contains both the markdown source files and the generated HTML files, with the paths fixed. The zip file is generated once a week." https://permacomputing.net/cloning/ https://permacomputing.net/cloning/ http://permacomputing.net/permacomputing.net.zip http://permacomputing.net/permacomputing.net.zip Would it be appropriate to include a digital signature, as is commonly found on mirrors Thought experiment: If it was standard practice to offer a compressed archive then would websites still be hammered by unwanted crawlers If answer is yes, then what if remove/deny access to online pages and only allow access to the compressed archive

232 points by pabs3 1y ago

This and Lindy Effect factors a lot into my choices for what to use for my projects. My choice for a project I want to be as maintenance-free as possible are special subsets of ASCII/txt, SQLite, Perl, Bash, PHP, HTML, JS, CSS. The subsets I choose are the parts of these languages which have persisted the longest. Using the Lindy Effect for guidance, I've built a stack/framework that works across 20 years of different versions of these languages, which increases the chances of it continuing to work without breaking changes for another 20 years.

akkartik 1y ago
For similar considerations + considerations of code size and hackability, I lately almost always prefer the Lua eco-system: https://akkartik.name/freewheeling https://akkartik.name/freewheeling
eviks 1y ago
This dogmatic approach means you lose out on ergonomics by using poorly designed tools like bash and perl, so you incur those costs all the time for little potential benefit far away in the future (after all, that effect is just a broad hypothesis)
- argomo 1y ago
  It has to be weighed against all the time spent learning, evaluating, and struggling with new tools. Personally, I've probably wasted a lot of time learning /new/ that I should have spent learning /well/.
  - eviks 1y ago
    Right, nothing is free, but switching costs is a different argument.
    - deleted 1y ago
      [deleted]
- forgotmypw17 1y ago
  Is it still dogmatic if I consider Perl to be well-designed and have already evaluated more popular tools?
  - eviks 1y ago
    If "This and Lindy Effect" do not "factors a lot", but instead the major factor is you believe perl is better designed, then no, dogmatism of vague future risk is replaced with pragmatism of the immediate usefulness
  - jwrallie 1y ago
    At the point being discussed, which is not breaking backward compatibility, it indeed is arguably better than more popular tools, and I believe perl has other advantages too.
- zeta0134 1y ago
  Very helpfully, python has stuck around for just as long and is almost always a better choice against these two specific tools for anything complicated. It's not perfect, but I'm much more likely to open a random python script I wrote 6 years ago and at least recognize what the basic syntax is supposed to be doing. Bash beyond a certain complexity threshold is... hard to parse. Python's standard library is just fine for most tasks, I think. It's got loads of battle tested parsers for common formats. I use it for asset conversion pipelines in my game engines, and it has so far remained portable between windows, linux and mac systems with no maintenance on my part. The only unusual crate I depend on is Pillow, which is also decently well maintained. It becomes significantly less ideal the more pip packages you add to your requirements.txt, but I think that applies to almost anything really. Dependencies suffer their own software rot and thus vastly increase the "attack surface" for this sort of thing.
  - forgotmypw17 1y ago
    My main problem with python is that a script I wrote 6 years ago (or even 1 year ago) is not likely to run without requiring modifications. If it's me running it, that's fine. But if it's someone else that's trying to use installed software, that's not OK.
    - esseph 1y ago
      This is one of the problems that containers help solve - no OS, just the dependencies required to run your code.
      - cjfd 1y ago
        It is also quite possible for old containers to no longer build.
        esseph 1y ago
        That's why your build pipeline alerts you when tests no longer work, and then you have a release of the previous build still available for download at any time. This is how containers are released!
- oguz-ismail 1y ago
  > poorly designed tools like bash and perl Skill issue, plus what's the alternative? Python was close until the 3.x fiasco
  - eviks 1y ago
    Indeed, double skill issue: one with the designers and the other one with the users having poor tool evaluation skills
    - oguz-ismail 1y ago
      > poor tool evaluation skills Both tools in question are installed everywhere and get the job done. There isn't much to evaluate, and nothing to compare against
      - eviks 1y ago
        > There isn't much to evaluate, and nothing to compare against These are exactly the skill issues I meant! Git gud in evaluating and you'll be able to come up with many more sophisticated evaluation criteria than the primitive "it's installed everywhere"
        legends2k 1y ago
        While there are other parameters I would consider like maintainability, ergonomics, mind share, ease of deployment, etc. The ubiquitous availability point triumphs most others though. Installation of new toolchain is usually a hassle when the same task can be done with existing tools. Also when I present it in a company setting installing new software and broadening the security attack surface is the first pushback I get.
        eviks 1y ago
        Do you advocate the use of Notepad on Windows to edit text because it already exists? What about the increase in the security attack surface from using languages that make it easy to make mistakes in something basic like quoting/escaping? Does it get in the top 10 of pushbacks?
- blueflow 1y ago
  Its not "far away in the future". Every other IT job right now is supporting, maintaining and fixing legacy software. These are the software choices of the past and you pay them in manpower.
  - deleted 1y ago
    [deleted]
- calvinmorrison 1y ago
  Calling perl poorly designed is absurd
testthetest 1y ago
It’s getting harder to make perfect choices as projects grow more complex. Even simple products often mean building for iOS, Android, web, backend, etc. You can only lean on html/js for parts of that, but in practice, the mobile apps will probably get rewritten every few years anyway. From my side I think it’s more useful to focus on surfacing issues early. We want to know about bugs, slowdowns, regressions before they hit users, so everything we write is written using TDD. But because unit tests are couple with the environment they "rot" together. So we usually set up monitoring, integration and black-box tests super early on and keep them running as long as the project is online.
donatj 1y ago
I love PHP, however since around 7.4 they have become pretty happy to make breaking changes to the language, including recently in ways where you cannot satisfy older and newer versions of the runtime simultaneously. I end up spending often a couple weeks of my life on and off fixing things after every major release.
- hu3 1y ago
  Was it related to magic quotes or global variables created from user input? If so, the writing has been on the wall for over a decade for these.

bravesoul2 1y ago

JS is hated but if you compile to browser JS that code will run in 2100. If you mainly deal with files / blobs not databases you will have these things in 2100 too. I think a lot of apps can be JS plus Dropbox integration to sync files. Dropbox may rot but make that a plugin (seperate .js file) and offer local read/write too and I think you'd be pretty future proof.

tekno45 1y ago
postgres will be around in 2500 lol
- Kinrany 1y ago
  Postgres will get disassembled into independent composable parts and some other "distribution" of it will be used for a more narrow set of use cases that actually require running the database as a standalone process
jillesvangurp 1y ago
Except of course software rot and javascript code bases go hand in hand. You seem to assume, browsers have stopped changing and will be more or less the same 75 years from now. I think you are right that that code might run. But probably in some kind of emulator. In the same way we deal with IBM mainframes right now. Hardware and OS have long since gone the way of the dodo. But you can get stuff running on generic linux machines via emulation. I think we'll start seeing a lot of AI driven code rot management pretty soon. As all the original software developers die off (they've long been retired); that might be the only way to keep these code bases alive. And it's also a potential path to migrating and modernizing code bases. Maybe that will salvage a few still relevant but rotten to the core Javascript code bases.
- 8n4vidtmkvmk 1y ago
  If they want to introduce html6, they'll add a new doctype. If they want moderner JS they'll do another 'stricter' or file type or what have you. The fact that it will continue to run with zero changes is good enough.

deleted 1y ago

[deleted]

fuzzfactor 1y ago

There were companies not quite worth a $billion who would have never made it that far if they couldn't convince masses of people that platform rot was good for them.

Copenjin 1y ago

> Software rot is a big issue for cultures that constantly produce new programs Cough cough vibing cough cough

alexshendi 1y ago
Common Object File Format (COFF)?
- Copenjin 1y ago
  onomatopoeia, fixed spelling :)

Daub 1y ago

As a software user and teacher, I think about software rot a lot. My concern is that it has a tendency to grow by addition rather than replacement. New features are added whilst the fundamental limits of the architecture are left unattended to. The reason that Blender grew from being an inside joke to a real contender is the painful re-factoring it underwent between 2009 and 2011. In contrast, I can feel the fact that the code in After Effects is now over 30 years old. Its native tracker is slow and ancient and not viable for anything but the most simple of tasks. Tracking was 'improved' by sub-contracting the task to a sub-licensed version of Mocha via a truly inelegant integration hack. There is so much to be said for throwing everything away and starting again, like Apple successfully did with OSX (and Steve Job did to his own career when he left Apple to start Next). However, I also remember how Blackberry tried something similar and in the process lost most of their voodoo.

b_e_n_t_o_n 1y ago

Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as a soap bubble?

mmackh 1y ago
Not if software is tied to infrastructure, buildings, etc.
- tanduv 1y ago
  but even buildings need maintained
  - spauldo 1y ago
    Automation costs a lot. The projects I work on are almost always in the millions of dollars,band they're far from being considered "big" projects. The hardware manufacturers will sell you equipment that runs for thirty years. Companies are reluctant to replace working systems. I replaced a PLC a couple years ago. The software to program it wouldn't run on my laptop because it used the win16 API. It used LL-984 ladder logic, and most people who were experts in that have retired. It's got new shiny IEC-compliant code now, and next they're looking at replacing the Windows 2000 machines they control it with. Once that's done, it'll run with little to no change until probably 2050.
- b_e_n_t_o_n 1y ago
  Perhaps software should be designed in such a way that despite it working on infrastructure, it can be swapped and discarded.
  - treyd 1y ago
    If it works and isn't broke then why swap or discard it?
  - 8n4vidtmkvmk 1y ago
    I don't want to reformat my fridge.

userbinator 1y ago

those written for e.g. Linux will likely cease working in a decade or two Have we already passed the era of DON'T BREAK USERSPACE when Linus would famously loudly berate anyone who did? I suspect Win32 is still a good target for stability; I have various tiny utilities written decades ago that still work on Win11. With the continued degradation of Microsoft, at least there is WINE.

szundi 1y ago
[dead]
wolvesechoes 1y ago
I would love ReactOS to succeed.
- Imustaskforhelp 1y ago
  If I remember correctly, ReactOS just uses wine under the hood. Which can be used in linux and even mac or bsd too. Basically (compile to windows?) seems like a good enough tradeoff to run anywhere, right? But I prefer appimage or flatpak because of the overhead that wine might introduce I suppose
  - wolvesechoes 1y ago
    > If I remember correctly, ReactOS just uses wine under the hood Nah. I think they share some effort and ReactOS team adds patches to WINE codebase, it is a separate thing.
atq2119 1y ago
No, the issue in Linux is that userspace has traditionally had a tendency to break itself.
cookiengineer 1y ago
You can account for that by using Go, with CGO_ENABLED=0. Then you have a self contained binary that relies solely on the POSIX syscalls.

superkuh 1y ago

Unless explicitly addressed rot rate is proportional to popularity. Unpopular targets, platforms, languages, etc don't get changed and provide a much needed refuge. There are some interpreted languages like perl where a program written today could run on a perl from 2001 and a program from 2001 would run on perl today. And I'm not talking about in a container or with some special version. I'm talking about the system perl. Some popular languages these days can lose forwards compatibility (gain features, etc) within just a few months that every dev will use within a few more months. In these cultures sofware rot is really fast.

wolvesechoes 1y ago
> Unpopular targets, platforms, languages, etc don't get changed Ah yes, Windows, some niche OS for hipsters and base-dwellers.
- superkuh 1y ago
  Windows was an amazing exception to this rule for 2 decades. It's incredibly impressive that win32 still works on modern Windows installs. But that's changing fast now.

icameron 1y ago

Nobody has a better ecosystem of “industrial marine grade code rot resistance” than Microsoft. That I can run the same .NET web app code compiled 20 years ago on a new Server 2025 is an easy experience unequaled by others. Or the same 30 year old VBA macros still doing their thing in Excel 365. There’s a company that knows how to do backwards compatibility.

szundi 1y ago
[dead]
js8 1y ago
As somebody who works on IBM mainframes, I disagree. IBM is probably the best at forward application compatibility. People will laugh, but they should really look.
- mkesper 1y ago
  Yes, honestly, when you're talking about planning for 40 years and more of backwards compatibility probably nothing beats IBM systems, and not only the big mainframes but also the smaller systems like AS/400 (nowadays System i). https://en.wikipedia.org/wiki/IBM_i https://en.wikipedia.org/wiki/IBM_i
mrkeen 1y ago
I had the opposite experience. Tried out XNA one year for the Global Game Jam. Was somewhat pleased with it. It was gone the next year.
Cthulhu_ 1y ago
I suspect this is true for a lot of software; a modern-day JVM can still run Java from 20 years ago as long as you didn't do anything weird, Linux hasn't significantly changed since then, the web is one of the most widely supported and standardized platform out there with the 1996 Space Jam website still working and rendering today as it was back then (your screen just got bigger). Is software rot real? I'm sure, but it's not in the runtime. It's likely in the availability and compatibility of dependencies, and mainly the Node ecosystem.

alexshendi 1y ago

I think once you get rid of dynamic libraries and GUIs your software rot will be greatly reduced.

nektro 1y ago

lovely article aside from this bit: > while those written for e.g. Linux will likely cease working in a decade or two there's nothing to support this claim in practice. linux is incredibly stable

ajuc 1y ago
I also noticed this part of the article but for the oposite reason (I think 10-20 years is overly optimistic). I've written a small 2d game for Linux back in 00s. Using C++, SDL and a few other libraries (for example now-abandoned libparagui for GUI). Any time I tried to run it afterwards - I had to recompile it, and a few times I had to basically port it (because libparagui got abandoned and some stuff in libc changed so I couldn't just compile the old libparagui version with the new libc). It's surprisingly hard to make linux binaries that will work even 5 years from now, never mind 10-20 years from now. For comparison I still have games I've written for DOS and windows in 90s and the binaries still work (OK - I had to apply a patch for Turbo Pascal 7 200 MHz bug). The assumptions around linux software is that it will be maintained by infinite number of free programmers so you can change anything and people will sort it out.
- count-delight 1y ago
  Something I've been pondering recently: It is sometimes said that Apple is notorious on deprecating APIs and breaking backwards-compatibility at a rapid pace, but is it not fundamentally the same that is shared with Linux? Old developers lamenting that they have developed something useful in 2015-2015 that doesn't work in any more in 2025. And if Linux distributions do it and it can be thought to be a form of opinionated design, can Apple be blamed for it? Unix/FreeBSD legacy and all. Of course with Apple ecosystem you need relatively recent hardware and have to pay the annual developer program fee, but the expectation is still the same: if you release something, you should keep it up-to-date and not just "fire and forget" like in Windows and expect it to work. Maybe Windows is the anomaly here.
  - ajuc 1y ago
    Dunno I just never used Apple. It's not very popular over here.

foxrider 1y ago

Python 2 situation opened my eyes to this. To this day I see a lot of py2 stuff floating around, especially around work environments. So much so, in fact, that I had to make scripts that automatically pull the sources of 2.7.18 and build them in the minimal configuration to run stuff.

Ygg2 1y ago
Python 2 is a warning about doing backwards compatibility changes too late. As soon as you have a few massive libraries, your backward compatibility risks grow exponentially. C# did just as big of a change by going from type-erased to reified generics. It broke the ecosystem in two (pre- and post- reified generics). No one talks about it, because the ecosystem was so, so tiny, no one encountered it.
- saurik 1y ago
  It certainly didn't help that they were annoying about it; like, they actively dropped some of the forward compatibility they had added (a key one being if you had already carefully used u and b prefixes on strings) in Python 3.0, and only added it back years later after they struggled to get adoption. If they had started their war with Python 3.5 instead of 3.0 it would be a lot less infuriating.
  - flomo 1y ago
    Not being a python dev, there must have been some huge superficial 'ick'. Back when, I was talking to a python guy and mentioned that Python 3 was coming out. He said something like "we're just going to ignore that until they sober-up and fix it." Which it seems like a lot of people actually did. (or they really sobered-up and rewrote in Go or something.)
    - zahlman 1y ago
      > He said something like "we're just going to ignore that until they sober-up and fix it." Which it seems like a lot of people actually did. "It" was fixed long before the 2.7 official sunset date. Even before the original planned date before it got extended, frankly.

alexjurkiewicz 1y ago

It's hard to take this article seriously. We should write software for DOS because we won't need to maintain it post-release? Maybe software written in the age of DOS was relatively trivial compared to modern tools. Maybe there's a benefit to writing code in Rust rather than C89.

codeflo 1y ago

We as an industry need to seriously tackle the social and market dynamics that lead to this situation. When and why has "stable" become synonymous with "unmaintained"? Why is it that practically every attempt to build a stable abstraction layer has turned out to be significantly less stable than the layer it abstracts over?

bloppe 1y ago
At any given moment, there are 6 LTS versions of Ubuntu. Are you proposing that there should be more than that? The tradeoffs are pretty obvious. If you're maintaining a platform, and you want to innovate, you either have to deprecate old functionality or indefinitely increase your scope of responsibilities. On the other hand, if you refuse to innovate, you slide into obscurity as everyone eventually migrates to more innovative platforms. I don't want to change anything about these market and social dynamics. I like innovation
- tracker1 1y ago
  They aren't still supporting 14.04. How do you get 6? There's one every other year, and they retire one shortly after a new one comes out. They're also pretty quick to shutter non-lts release support each lts generation.
Ygg2 1y ago
> When and why has "stable" become synonymous with "unmaintained"? Because the software ecosystem is not static. People want your software to have more features, be more secure, and be more performant. So you and every one of your competitors are on an update treadmill. If you ARE standing (aka being stable) on the treadmill, you'll fall off. If you are on the treadmill you are accumulating code, features, and bug fixes, until you either get too big to maintain or a faster competitor emerges, and people flock to it. Solving this is just as easy as proving all your code is exactly as people wanted AND making sure people don't want anything more ever.
- codeflo 1y ago
  > People want your software to have more features, have fewer bugs, and not be exploited. So you and every one of your competitors are on an update treadmill. If you ARE stable, you'll probably fall off. If you are on the treadmill you are accumulating code, features, bug fixes, until you either get off or a faster competitor emerges. Runners on treadmills don't actually move forward.

joegibbs 1y ago

I think don’t worry too much about trying to avoid it. Think 5-10 years ahead max, rather than 20. In 20-30 years there’s a good chance that what you’ve written will be obsolete regardless - even if programs from 1995 ran perfectly on modern systems they’d have very few users because of changing tastes. A word processor wouldn’t have networked collaborative editing (fine for GRRM though), an image editor wouldn’t have PNG support, and they wouldn’t be optimised for modern hardware (who would foresee 4K screens and GPUs back then - who knows how we’ll use computers in 2055). There are also always containers if the system needs those old versions.

whizzter 1y ago
2005 is already 25 years ago, and what the author is hinting at is the difference in difficulty between keeping 1980s software running vs keeping 2005 software running is momentous. 1980s NES software is "easy" as in emulating a CPU and the associated hardware (naturally there are corner cases in emulation timing that makes it a lot harder, but it's still a limited system). I used to make demos as mentioned in the article, the ones I did for DOS probably all work under DosBox. My early Windows demos on the other hand relied on a "bad" way of doing things with early DirectDraw versions that mimicked how we did things under DOS (ie, write to the framebuffer ourselves). For whatever reason the changes in Vista to the display driver model has made all of them impossible to run in fullscreen (luckily I wrote a GDI variant for windowed mode that still makes it possible to run). Even worse is some stuff we handle at an enterprise customer, Crystal Reports was even endorsed by Microsoft and AFAIK included in Visual Studio installs. Nowadays abandoned by MS and almost by it's owner (SAP), we've tried to maintain an customized printing applications for a customer, relying on obscure DLL's (and even worse the SAP installer builder for some early 2000s install technology that hardly works with modern Visual Studio). Both these examples depend on libraries being installed in a full system, sure one could containerize needed ones but looking at the problem with an archivist eyes, building custom Windows containers for thousands of pieces of software isn't going to be pretty (or even feasible in a legal sense both with copyright and activation systems). Now you could complain about closed source software, but much of a tad more obscure *nix software has a tendency to exhibit a huge part of "works on my machine" mentality, configure scripts and Docker weren't invented in a vacuum.

TacticalCoder 1y ago

> 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. The rot is real but we have a way to run Linux (and any really) software in 40 years. For example: From alpine:3.14 ... Just as I can run thousands of games from the 80s on my vintage CRT arcade cab using a Pi and MAME (with a Pi2JAMMA adapter), I'll be able to run any OCI container in 30 years. The issue of running old software is solved: we've got emulators, VMs, containerization, etc. Sure they may lack security upgrades but we'll always be able to run them in isolation. The rot is not so much that the platform won't exist in the future or that old libs would mysteriously not be available anymore: the problem is that many software aren't islands. It's all the stuff many need to connect to that's often going to be the issue. For games that'd be, say, a game server not available anymore. Or some server validating a program to make sure its license has been paid. Or some centralized protocol that's been "upgraded" or fell into irrelevancy. Or some new file format that's now (legitimately or not) all the shit. Take VLC: there's not a world in which in 40 years I cannot run a VLC version from today. There's always going to be a VM or, heck, even just an old Linux version I can run on bare metal. But VLC ain't an island either: by then we'll have coolmovie-48bits.z277 where z277 is the latest shiny video encoding format. At least that's where I see the problem when running old software.

rgmerk 1y ago

You can't build permanent software in a world where a) everything is connected to everything else, and b) hackers will exploit anything and everything they can get their hands on.

8n4vidtmkvmk 1y ago
Isn't that half the problem right there? Stop connecting everything to everything. Make your app work offline. And for anything that must connect, at least use a well defined API that can swap for some other service. E.g. S3 API is now defacto for block storage.

noduerme 1y ago

I wish I could write all the business logic I write on an NES and never have to worry about requirements going bad. I guess the thing is, if you're writing anything on top of a network layer of any kind, eventually it's going to require patches unless you literally own all the wires and all the nodes in the network, like a secure power plant or some money clearing system in a bank that's been running the same COBOL since the 1960s. And since you're probably not writing code that directly interfaces with the network layer, you're going to be reliant on all the libraries that do, which in turn will be subject to change at the whims of breaking changes in language specs and stuff like that, which in turn are subject to security patches, etc. In other words, if you need your software to live in the dirty world we live in, and not just in a pristine bubble, things are gonna rot. Picking tools and libraries and languages that will rot less quickly however seems like a good idea. Which to me means not chaining myself to anything that hasn't been around for a decade at least. I got royally screwed because 50-60% of my lifetime code output before 2018, and pretty much all the large libraries I had written, were in AS3. In a way, having so much code I would have maintained become forced abandonware was sort of liberating. But now, no more closed source and no more reliance on any libs I don't roll or branch and heavily modify myself.

gr4vityWall 1y ago
> 50-60% of my lifetime code output before 2018, and pretty much all the large libraries I had written, were in AS3 Out of curiosity, what kind of work did you do? Regarding our old AS3, did you have any luck with Haxe? I assume it would be a straightforward port.
- noduerme 1y ago
  HaXe is great fun as a language, and I would definitely consider it now if I were writing a new game from scratch. But I never found anything to be a straightforward port from as3. There was too much unsupported particularly in networking. Too much of what I wrote relied on Adobe's NetConnection and socket implementations, plus other .fl packages that never made it over. Not looking at it right now, but that was pretty much the wall I hit at the time around 2019... there was no build target that wouldn't require rewriting the whole way a multiplayer game platform handled networking to get around the sandbox limitations that you could work inside of in AIR or Flash. Maybe I was just kinda dejected and could have solved it, but instead I moved over to TS and PixiJS, ported some necessary logic and started my whole stack over.

xenodium 1y ago

While Emacs itself is not entirely immune to software rot (external dependencies and all), it’s truly amazing how little to no rot is experienced by elisp software (packages). If you find an Emacs package written 15 years ago, the chances of successfully running out of the box are incredibly high.

deafpolygon 1y ago
That... has not been my experience.
zkry 1y ago
I was thinking the exact same thing. As long as you're not depending on any external packages things are very stable. Like, if you're package depends on adding advice to some other package's random internal function, then yeah, it could easily break. It's a great feeling knowing any tool I write in Elisp will likely work for the rest of my life as is.

Falkon1313 1y ago

Over the course of my learning and my career, I've kind of gone back and forth on this a bit. On the one hand, software is like a living thing. Once you bring it into this world, you need to nurture it and care for it, because its needs, and the environment around it, and the people who use it, are constantly changing and evolving. This is a beautiful sentiment. On the other hand, it's really nice to just be done with something. To have it completed, finished, move on to something else. And still be able to use the thing you built two or three decades later and have it work just fine. The sheer drudgery of maintenance and porting and constant updates and incompatibilities sucks my will to live. I could be creating something new, building something else, improving something, instead, I'm stuck here doing CPR on everything that I have to keep alive. I'm leaning more and more toward things that will stand on their own in the long-term. Stable. Done. Boring. Lasting. You can always come back and add or fix something if you want. But you don't have to lose sleep just keeping it alive. You can relax and go do other things. I feel like we've put ourselves in a weird predicament with that. I can't help but think of Super Star Trek, originally written in the 1970s on a mainframe, based on a late 1960s program (the original mainframe Star Trek), I think. It was ported to DOS in the 1990s and still runs fine today. There's not a new release every two weeks. Doesn't need to be. Just a typo or bugfix every few years. And they're not that big a deal. -- https://almy.us/sst.html https://almy.us/sst.html I think that's more what we should be striving for. If someone reports a rare bug after 50 years, sure, fix it and make a new release. The rest of your time, you can be doing other stuff.

account42 1y ago

The OS/libraries changing is one example of software rot but another one is requirements changing and you can't completely eliminate that.

cess11 1y ago

I like this one as well. https://how.complexsystems.fail/ https://how.complexsystems.fail/

pvtmert 1y ago

It is interesting that one of the most solid piece of software component that is relatively resistant to rotting is Shell/Bash scripts. (Including Makefiles) Python, Ruby, etc. constantly get obsolete over time, packages get removed from the central repositories, ceasing to work. Obviously shell scripts contain _many_ external dependencies, but overall the semantics are well-defined even if the actual definitions are loose against the shell script itself. P.S: I have written couple of Bash-script projects that are still running (mostly deployment automation scripts) meanwhile, some of which I was being "smart" and wrote them in Python 2.7, unfortunately ceased to function, requiring upgrades...

benchly 1y ago
What about C? Is there something to be said for the proximity of the language to the machine language? Maybe that sounds like a dumb question because I am a beginner at coding, so I apologize, but it's something I've recently gotten into via an interest in microcontrollers. A low(er)-level language like C seems to be pretty universally sound, running on just about anything, and seems to have not changed much in a long, long time. But when I was dabbling in both Python and Ruby (on Rails) and .NET framework, I noticed what you mean, as I scooped up some old projects on github thinking I'd add to them and realize that it would be a chore to get them updated.
prmoustache 1y ago
Frankly perl5 seems like one that is very resistant to rot. TCL and TK as well.
8n4vidtmkvmk 1y ago
I recently discovered how many of my bash scripts run perfectly fine in git-bash on windows. I was pleased. I believe Bun (yes the js runtime) can run .sh scripts too. And of course under WSL too. So 3 different ways I can run them on Windows. File paths can get a little sketchy but with a couple helpers it's not hard to convert back and forth.

dusted 1y ago

Perfect little text, that article is. Same site has this article about "bedrock platforms" which resonate deeply with me https://permacomputing.net/bedrock_platform/ https://permacomputing.net/bedrock_platform/ Software does not rot, the environment around software, the very foundation which owes its existence: the singular task of enabling the software, is what rots. Let's look at any environment snapshot in time, the software keeps working like it always did.. Start updating the environment, and the software stops working, or rather, the software works fine, but the environment no longer works. I'm not saying never to update software, but, only do it if it increases speed, decreases memory usage, and broadens compatibility. I like things better the way they were. I like things better now than how they will be tomorrow. I can't remember the last time I saw a software update that didn't make it worse.

ManBeardPc 1y ago

Software rot is a big problem in many business tools. Everything not recently built from the tip of main is probably no longer working. APIs change, URLs change, Processes change, newer versions of dependencies no longer work because of version conflicts or deprecation without replacement. The amount of work just to fix the rot is constantly rising. No care is spent to keep things stable. Stable interfaces are really something I learnt to appreciate more and more, even if sometimes crusty and verbose. If it is reliably working don't replace it without a very good reason. I attribute these problems mostly to agile the way it is practiced in many companies. Only thinking in providing "value" per sprint and little to no planning ahead, prioritizing ease of change over everything else.

prinny_ 1y ago

I don’t get the comparison to building a house. Houses have a ton of maintenance. You can’t build a house on steady ground and leave it unattended for 20 years either. And sometimes what you need to do is not even construction type of maintenance, it’s bills, legal paperwork, replacing old furnitures just because you grew tired of that 15 year old sofa etc.

deleted 1y ago
[deleted]
9rx 1y ago
Houses do require a ton of maintenance, but typically within a stable environment. Yeah, laws might change every once in a blue moon, and over hundreds of years climate change may alter the patterns of wear and tear, but for all intents and purposes what you know today is likely to still hold for tomorrow. But if you build on a bog, then you've unnecessarily introduced a whole lot of new variables to contend with.

conartist6 1y ago

If you're listening VSCode forkers, ya built on bog

8n4vidtmkvmk 1y ago
I'm sitting on the sidelines, waiting for them to all sink. I guess I don't stand to gain anything, but I'll be happy to keep sipping my beer.

collinmcnulty 1y ago

In my experience, the most common type of rot is that the real world the software describes has changed. For instance, I wrote software that modeled electrical power contracts, and when those real world contracts’ structure changes, no amount of “bedrock platform” is going to prevent that rot.

8n4vidtmkvmk 1y ago
I don't know anything about electrical power, but this reminds me about a story about making assumptions about human relationships. Like, you can legally be your own grandfather. Does your program account for that? Software needs to be flexible to account for new, weird scenarios. Sometimes we just can't predict everything, but we can try.
Mr_Minderbinder 1y ago
It can be as simple as a year change. A lot of old software rotted away once the year 2000 rolled around and more unmaintained software will in 2038.

9w389s98s9sjs 1y ago

javascript will run forever!

jongjong 1y ago

This is a good discussion to have. I spend a lot of effort on evaluating dependencies. I look for a number of things like how popular/widely used it is, who the author is (if I recognize them) and I also look at code quality and number of sub-dependencies. If I see a library which is solving a simple problem but it uses a lot of dependencies, I usually don't use that library. Every dependency and sub-dependency is a major risk... If a library author doesn't understand this, I simply cannot trust them. I want the authors of my dependencies to demonstrate some kind of wisdom and care in the way they wrote and packaged their library. I have several open source projects which have been going for over a decade and I rarely need to update them. I was careful about dependencies and also I was careful about what language features I used. Also, every time some dependency gave me too much trouble I replaced it... Now all my dependencies are highly stable and reliable. My open source projects became a kind of a Darwinian selection environment for the best libraries. I think it's why I started recognizing the names of good library authors. They're not always super popular but good devs tend to produce consistent quality and usually gets better with time. So if I see a new library and I recognize the author's name, it's a strong positive signal. It feels nice seeing familiar niche names come up when I'm searching for new libraries to use. It's a small secret club and we're in it.

8n4vidtmkvmk 1y ago
Picking packages based on their author has become a big thing for me. Some authors are awful about backwards compatibility, some are fantabulous. There's a couple folks that have bitten me that I rather despise now and avoid like the plague.
- jongjong 1y ago
  Haha yeah same here. There are a few authors, libraries and ecosystems I avoid entirely. Others I only use in certain contexts.

roda73 1y ago

This is one of the reasons I absolutely hate Linux based development and operating systems built with it. We all know it now as dependency hell, but what it is in fact is just a lazy shortcut for the current development that will bite you down the path. The corporate software is not a problem, because the corporate users don't care as long as it works now, in the future they will still rely on paid solutions that will continue working for them. For me, I run a local mirror of arch linux, because I don't want to connect to internet all the time to download a library that I might need or some software that I may require. I like it all here, but since I haven't updated in a while I might see some destructive update if I were to choose to update now. This should never happen, another thing that should never happen is if I were to compile an old version of some software. Time and time again, I will find a useful piece of software on github and I will naturally try compiling it, it's never easy, I will have to hunt the dependency it requires, then try compiling old versions of various libraries. It's just stupid, I wish it were easier and built smarter. Yes sometimes I want to run old software, that has no reason not to work. When you look at windows, it all works magically, well it's not magic it's just done smart. On GNU+Linux smart thinking like this is not welcome, it never has been. Instead they rely on huge amounts of people that develop this software, to perpetually update their programs for no reason, but to satisfy a meaningless number of a dependency.

skydhash 1y ago
It’s all volunteer work, not some corporation with trillions laying around. If you want something easy, use Debian (or ubuntu). They pretty much have everything under the sun. What you want to have (download software from the net and run it) is what most distro have been trying to avoid. Instead, they vet your code, build it, and add it to a reputable repo. Because no one wants to download postgres from some random sites.
- gjsman-1000 1y ago
  Last time I checked, Ubuntu/Canonical is a multimillion dollar company, Red Hat is a multibillion dollar company, SuSE sold for $2.5B, and The Linux Foundation has over $250M in revenue to spend only 3% on development of Linux specifically. Enough of the BS of "we're just volunteers" - it's fundamentally broken and the powers that be don't care. If multiple multibillion dollar entities who already contribute don't see the Linux desktop as having a future, if Linus Torvalds himself doesn't care enough to push the Foundation on it; honestly, you probably shouldn't care either. From their perspective, it's a toy, that's only maintained, to make it easier to develop the good stuff.

perrygeo 1y ago

I don't like the term "rot" - your software isn't rotting, it's exactly the same as when you last edited it. The rest of the software ecosystem didn't "rot" either, it evolved. And your old code didn't. "Extinction" seems a much better fit.

munchler 1y ago
If we're just going by word meanings, "obsolescence" seems even more apt, but "rot" has an ironic charm that makes it memorable.
8n4vidtmkvmk 1y ago
If the apple remains pristine, but the tree trunk dies, it doesn't much matter that the apple hasn't changed. It dies with the tree.

jgb1984 1y ago

Today we vibecode our software, so the rot is built in from day one!

phkahler 1y ago

I'm looking at GTK here. Don't get me wrong, I like GTK and think it should be the preferred choice of GUI toolkit for many reasons. However, I have the same complaints a lot of people do about constant change and API compatibility issues. In some cases things need to change, but why going form 3 to 4 have menus been removed and require using other constructs? Could you at least provide a wrapper? Don't use event struct members directly, OK use accessor functions... But then you change the names and other details of the functions. It's not a "window" any more, it's a "surface" just because what? Beause Wayland calls them that? API stability is an important feature but these guys are talking about regular (say every 5 years) major version bumps that break things.

8n4vidtmkvmk 1y ago
I never understood those kinds of changes. If you really, really, really want to rename something, deprecate the old thing and make it an alias for the new thing. Don't delete it. Just add compatibility shims. Then after 5 or 10 years, take a pulse of the community. If they've mostly migrated off, go ahead and delete. If it's still actively used... Keep it, or even undeprecate it because clearly it's wanted.

asa400 1y ago

SQLite has an explicitly stated policy on this: "The intent of the developers is to support SQLite through the year 2050." https://www.sqlite.org/lts.html https://www.sqlite.org/lts.html People talk about SQLite's reliability but they should also mention its stability and longevity. It's first-class in both. This is what serious engineering looks like.

azemetre 1y ago
Does SQLite talk about how they plan to exist beyond 2050 across multiple lifetimes? Not trying to be chide but it seems like with such a young industry we need better social tools to make sure this effort is preserved for future devs. Churn has been endemic in our industry and it has probably held us back a good 20 years.
- ectospheno 1y ago
  I’m trying and failing to think of another free software product I honestly expect to still work on my current data past 2050. And this isn’t good enough?
  - azemetre 1y ago
    It's good, but this also assume that the people taking care of this product in the future (which may not even born right now) will hold the same attitudes. How do we plan to make sure the lessons we've learned during development now will still be taught 300 years from now? I'm not putting the onus on sqlite to solve this but they are also the only organization I know of that is taking the idea seriously. Just more thinking in the open and seeing what other people are trying to solve similar problems (ensure teachings continue past their lives) outside the context of universities.
  - SoftTalker 1y ago
    Thinking like this is how we ended up with a panic about Y2K. Programmers in the 1970s and 80s could not conceive that their code would still be running in 2000.

BirAdam 1y ago

The most reliable targets I’ve seen recently are Win32 and CGI. They just work. Linux, Windows, macOS. Decade after decade.

biscuits1 1y ago

". . . whose specifications are static and solid." Well, thats the problem with software. There isn't agreement of such specifications. We aren't working with wood, nails nor forming a sill footing on bedrock.

sbrkYourMmap 1y ago

This is the side effect of open source. And open source philosophy is at fault but rather developers themselves. We heavily rely upon code written by strangers and maintained by individual or a community without any obligation to any guarantees, including comparability and maintainability. At work when we are working with vendors that provide proprietary software we have contractual obligations, that amongst other things requires stable interfaces for long periods of time, and could be held liable for damages. Something modern model of open source can't offer

Vegenoid 1y ago

This is why I put so much effort into working with POSIX shell code, despite its painful syntax. I can be pretty damn sure my knowledge will still be relevant in 30 years. LLMs have also made reading and writing shell code much easier.

kragen 1y ago

Konrad Hinsen calls this "software collapse": when the platform has been eroded out from underneath your software and it collapses. https://hal.science/hal-02117588/document https://hal.science/hal-02117588/document There's no reason such a "bedrock platform"♢ needs to be a shitty pain in the ass like the IBM PC or NES (the examples on https://permacomputing.net/bedrock_platform/ https://permacomputing.net/bedrock_platform/). Those platforms were pragmatic tradeoffs for the existing hardware and fabrication technology in the market at the time, based on then-current knowledge. We know how to do much better tradeoffs now. The 8088 in the IBM PC was 29000 transistors, but the ARM 2 was only 27000 transistors†. Both could run at 8 MHz (the 8088 in its later 8088-2 and 80C88 incarnations), but the ARM 2 was a 32-bit processor that delivered about 4 VAX MIPS at that speed (assuming about ½DMIPS/MHz like the ARM3‡) while the 8088 would only deliver about 0.3 VAX MIPS (it was 0.04DMIPS/MHz). And programming for the 8088's segmented memory model was a huge pain in the ass, and it was crippled by only having 20 address lines. 8088 assembly is full of special-purpose registers that certain instructions have to use; ARM assembly is orthogonal and almost as high-level as C. Same transistor count, same clock speed, dramatically better performance, dramatically better programming experience. Similarly, Unix and Smalltalk came out about the same time as Nova RDOS and RT-11, and for literally the same machines, but the power Unix and Smalltalk put in the hands of users far outstripped that of those worse-designed systems. So, let's put together a bedrock platform that we could actually use for our daily computing in practice. Unlike the NES. ______ ♢ Stanislav Datskovskiy's term: http://www.loper-os.org/?p=55 http://www.loper-os.org/?p=55 † https://en.wikipedia.org/wiki/Transistor_count https://en.wikipedia.org/wiki/Transistor_count ‡ https://netlib.org/performance/html/dhrystone.data.col0.html https://netlib.org/performance/html/dhrystone.data.col0.html but note that the ARM3 had a cache, so this depends on having RAM that can keep up with 8MHz. Both the ARM2 and ARM3 were mostly-1-instruction-per-clock pipelined RISCs with almost exactly the same instruction set. https://en.wikipedia.org/wiki/Acorn_Archimedes https://en.wikipedia.org/wiki/Acorn_Archimedes, https://www.onirom.fr/wiki/blog/21-04-2022_Acorn-Archimedes/ https://www.onirom.fr/wiki/blog/21-04-2022_Acorn-Archimedes/, and its twin https://wardrome.com/acorn-archimedes-the-worlds-first-risc-based-home-computer/ https://wardrome.com/acorn-archimedes-the-worlds-first-risc-... confirm the 8MHz and 4MIPS.

WalterBright 1y ago

1970-01-01 1y ago

IMHO, you need to address how everyone is dating its superficially attractive cousin - free open source software - before you tackle the issue of it rotting away. When your entire castle rests upon the following language, perhaps it's somewhat your fault when it stops working tomorrow. 15. Disclaimer of Warranty. THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. Limitation of Liability. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

nektro 1y ago

posts like this need to mention capitalism if they want to be taken seriously

1vuio0pswjnm7 1y ago

"HTTP vs HTTPS It is possible to consult this wiki on port 80, that is to say using http:// http:// instead of https:// https://." https://permacomputing.net/about/ https://permacomputing.net/about/ "If you do not have access to git on your operating system, you can download a zip file that contains both the markdown source files and the generated HTML files, with the paths fixed. The zip file is generated once a week." https://permacomputing.net/cloning/ https://permacomputing.net/cloning/ http://permacomputing.net/permacomputing.net.zip http://permacomputing.net/permacomputing.net.zip Would it be appropriate to include a digital signature, as is commonly found on mirrors Thought experiment: If it was standard practice to offer a compressed archive then would websites still be hammered by unwanted crawlers If answer is yes, then what if remove/deny access to online pages and only allow access to the compressed archive