5 ms·

I am convinced the world doesn't understand the concept of something being "complete." It's like part of their brain can't comprehend that something is function

I am convinced the world doesn't understand the concept of something being "complete." It's like part of their brain can't comprehend that something is functionally whole, and any changes would actually detract from what is there. Related: open source devs fret if a library hasn't been updated in the last month, even if it is feature complete with no bugs.

electroly 4y ago
For open source code, I think the concern is practical: bit rot is real, and libraries with no recent updates are more likely to have suffered bit rot. It's not that a library can't be finished, but that the world in which it lives never stops moving. It can be a bigger or smaller problem depending on the ecosystem. Old C89 libraries have a good chance of still working, because the ecosystem isn't moving so much any more. Old C# libraries almost definitely don't, because the ecosystem is moving quickly.
- forgotmypw17 4y ago
  Perhaps the solution is a monthly "NOOP" release?
  - twicetwice 4y ago
    maybe commit to a log indicating that the test suite has run correctly as of <today's date>?this assumes you have a useful test suite but also at least indicates that you're still paying attention & trying to ensure your library works
    - forgotmypw17 4y ago
      Great idea!
    - svieira 4y ago
      quid custos ipsos custodiet still applies. The fact that your test suite ran in Esolang v27.8 successfully doesn't mean what you-the-consumer want it to mean if the last supported version of Esolang is v96.2. It just means someone down-stack of you is committed to backwards compatibility.
      - travisjungroth 4y ago
        That future version won’t be on the supported versions list anyway.
        forgotmypw17 4y ago
        I think this varies by project. I personally support every version of my projects. My goal is not to minimize the effort to myself but to facilitate the use of my software.
        travisjungroth 4y ago
        I meant the new version of Esolang, v96.2, wouldn’t be explicitly supported by your project.
        forgotmypw17 4y ago
        Ah, also a good point.
  - budoso 4y ago
    Agreed but this definitely isn’t in the interest of library maintainers. If they did so it’d mean they are acknowledging all the currently open issues and deciding to do nothing, which would sometimes cause backlash.
    - bliteben 4y ago
      I mean most projects just auto close all issues now. Dunno where this desire to have 0 open issues came from. Seems like in the past projects would mark the issue as unconfirmed and ignore it, now they all want to close the thread and not allow further comments. Almost as if someone is going to judge their open source project negatively for having open issues, which if that has ever happened that person is more insane than the devs practicing this.
  - ep103 4y ago
    I would assume a noop is automated, and the library is no longer maintained. If, however, I saw a statement at the top of the README that said: "Update as of 2 months ago: We believe this project to be complete. We are not adding new features at this time, but if you see any issues, please open a ticket, as this project is still under active development as needed" then I would feel very confident.
    - forgotmypw17 4y ago
      Thanks, that's a good point.
- ryandrake 4y ago
  Bits don't rot--vendors break things. If my code built with yesterday's SDK and ran on yesterday's OS, and it doesn't for today's, that's not some supernatural phenomenon where digital media rots away--let's clearly blame who's causing it: SDK and OS vendors making changes that break backward compatibility and dump the maintenance burden on developers. The term "bit rot" is an attempt to shift the blame away from those who are causing the rot in the first place. Whether or not it's good to have a moving ecosystem is another story, but I request we not use the term "bit rot" when we mean "vendors breaking compatibility."
mey 4y ago
If a library is not updated in some capacity "recently" (coming from the Java land, "recent" is a different timescale than Javascript), then I have little confidence that a security issue can be resolved if discovered. Even if a library is complete, it may depend on libraries downstream that do have security issues that are no longer supported, which means it needs to swap to newer versions, etc.
bsaul 4y ago
About open source lib not being updated : The thing is, even if the lib is "feature complete", it's pretty rare to not have to update anything, since the ecosystem in which this lib evolves will undoubtely have changed. Programming language, hardware, OS, etc. everything evolves all the time.
- smt88 4y ago
  Security threats also evolve all the time. A library that hasn't been updated in months is very likely an insecure library.
  - FpUser 4y ago
    I use an ancient library to perform some math. It's been working just fine for more than 10 years without any need for update. Can someone explain why is it insecure and what updates are needed to complex algos to make them so? When looking at the code it is pure computation. I think what you are saying is simply FUD when taken as a blanket statement.
    - x3n0ph3n3 4y ago
      Are you passing user input into it? Does it interact with anything on the system? Poorly sanitized inputs present a very serious risk for RCE vulnerabilities.
      - FpUser 4y ago
        As already said it is pure computational lib. It does not interact with anything and I use it from my code. There are tons of libraries like this. They work just fine, do not pose a security risk and have no need for update. But thanks for trying anyways.
    - smt88 4y ago
      > I use an ancient library to perform some math. Anyone can cherry-pick examples to try to disprove a security principle. A pure, functional math library isn't representative of the vast, vast majority of libraries that are imported every day. The most-used libraries across languages are for things like database access, logging, package management, HTTP, and (de)serialization. All of those things need to be kept updated for security. > Can someone explain why is it insecure and what updates are needed to complex algos to make them so? When looking at the code it is pure computation. You didn't specify the language or library. Most libraries that people import are going to be JS, just because of the number of JS users and the minimal standard library in that language. Many are also going to operate on user input, which means they can have vulnerabilities. The mathjs package in NPM, for example, has had tons of vulnerabilities[1]. 1. https://security.snyk.io/package/npm/mathjs https://security.snyk.io/package/npm/mathjs
thenerdhead 4y ago
I mean a heartbeat is needed sometimes to make sure something is still alive and can address critical issues if they do happen. But I do agree that libraries and apps don't need to "update" to show that. Maybe some other way like "Hey, we're still here just the thing we're working on doesn't need an update" would suffice for most things.
aposm 4y ago
By "the world" I think you mean a specific subset of people: investors/execs/the business side. I don't particularly believe that average end users or competent engineers feel that way...
- naniwaduni 4y ago
  In fact, average end users infamously don't voluntarily update things that aren't visibly broken.
zeroonetwothree 4y ago
I would love to see this theoretical world in which libraries have no bugs. Thing is, even if there are no known bugs, having rare updates means if I do find a new bug it’s less likely to get addressed quickly.
- Gormo 4y ago
  I'm not sure I follow your logic. If you find a bug, wouldn't that provide a reason for updating your code? What is the utility of issuing superfluous updates when you don't have any new known bugs to fix? How does doing that shift your likelihood of fixing bugs when they are found, in any direction?
donatj 4y ago
A PHP library I use and used to help maintain had a bit of a fight break out in the Issues on GitHub a couple weeks ago. They were dropping support for older versions of PHP despite getting nothing from it and using none of the newer features. Just needlessly limiting the audience, and churn for churns sake.
- taftster 4y ago
  I hear you and I get what you're saying. However, to argue the other side, maybe it's a decision based on the possibility of long maintenance going forward. Keeping track of, in your example, PHP and all of its various versions is mentally daunting. What's wrong with a project just saying, "Hey look, we're not saying it won't work for you, but if you're running these older versions, we just don't give you any guarantees that it does. YMMV." e.g. say a bug comes up in the library, and say that it only affects older versions of PHP. Why can't the project just shrug its shoulders and be truthful that it doesn't have interest in maintenance/support against those old versions? It's better that the project declares this intention now, before the bug comes up, then later having to part ways with the old versions more abruptly. This is why OSS is great, as you can decide if, at the time said bug is found, that you want to provide legacy support for older PHP versions, maybe through a fork or other means. Have at it, it's your software too.
- shagie 4y ago
  I am reminded of the libressl - 30 days in report. https://youtu.be/oM6S7FEUfkU?t=1073 https://youtu.be/oM6S7FEUfkU?t=1073 Removing support for old versions is a simplification of what needs to be considered. It is a reduction of complexity. If someone is running a PHP version that has been EOLed, it is perfectly reasonable to discontinue support for it in a library - even if new features that weren't available in the EOL'ed version haven't been added yet.
  - unity1001 4y ago
    > If someone is running a PHP version that has been EOLed, it is perfectly reasonable to discontinue support for it in a library Its not. Large Linux distributions support those PHP versions for a long time in their LTS releases, and majority of web hosts and infra providers use those distros in their infra.
sodapopcan 4y ago
The Elixir ecosystem is quite good for this. I've found smaller libraries that haven't been update in a long time but still work just fine since Elixir itself hardly ever changes in a breaking way (the recurring phrase in the community being: "There will probably never be a version 2"). It's weird to get used to at first but it's actually quite refreshing.
- OkayPhysicist 4y ago
  I used an Erlang library in my Elixir project a while back that hadn't had an update in a decade. If a language's semantics don't change (and they really, really shouldn't change without either A) a very good reason or B) a really, really good backwards compatibility story) then there's really no reason for a library that does a job well to ever update.
hwbehrens 4y ago
> feature complete with no bugs I suppose for simple libraries this might be possible (e.g. left-pad) but how would you know in general that something is bug-free? `units` was introduced in 1979 and is still one of the canonical examples used in automated program repair research to show that new bugs can be found even in extremely well-studied codebases. I think people might be: 1. Implicitly assuming that all nontrivial code has bugs, and 2. Using recent commits as a signal that means, "If I ran into a bug, there is someone who might fix it (or at least accept a fix PR) to take away my immediate pain.
- dotancohen 4y ago
  I've never used or heard of the left-pad library, but I'm willing to bet that I could find an RTL bug in a library with that name.
- __turbobrew__ 4y ago
  That reminds me of the overflow bug in the JDK binary search that was present for quite a while.
sorisos 4y ago
I like that so many unix command tools (like cat, ls...) is rarely updated. Often comes with a man page written in 30 years ago. Same with a lot of C libraries.
Lutger 4y ago
One word: security updates. Ok that was two. Most software had dependencies, those tend to surface vulnerabilities over time.
musicale 4y ago
Other game platforms (game consoles, Windows) seem to have drastically better backward compatibility and API stability. If you look at the Nintendo DS/3DS (for example), the platform had many hardware revisions (about every other year) and dozens of firmware revisions, yet games from 2004 still worked on a brand new 3DS in 2020. On the Sony side, PS4 games from 2013 still work fine on a PS5 in 2022 (and probably through 2029.) Steam has tons of old games that work great on Windows (but the Mac side took a major hit with macOS Catalina's 32-bit apocalypse.)
- danhor 4y ago
  The 3DS physically included most parts of a DS, that often went unused in "normal" operations. In my experience old games often work better in proton/wine than in Win 11. My understanding is that the Steam Runtime also provides a stable base, that (or something close to it) unfortunately wasn't adopted in other ecosystems. Flatpak is great, but not used widely used for binaries yet.
- nerdix 4y ago
  And Playstation is way behind Xbox when it comes to backwards compatibility. Xbox backwards compatibility goes all the way back to the original Xbox released in 2001.
ako 4y ago
Everything you use continuously improves. What do you use that has seen improved versions since you bought it? Our knowledge, our abilities, our raw materials continuously improve, and everything is expected to advantage of this. Things that don't improve, are soon outdated and fall behind. Everything continuously improves: cars, bicycles, windows, houses, refridgerators, tv, etc, etc.
- userbinator 4y ago
  s/improves/churns/g We reached the peak of software usability a long time ago, probably around the turn of the century. Now it's all about trendchasing, change for the sake of change, dark patterns to squeeze the $$$ out of you, etc.
  - ako 4y ago
    I think there's still room for real improvement: once we have afforable displays that cover your entire wall, imagine what something like miro could bring you. Visual collaboration, pen drawings that turn into organizated information, architecture diagrams that can be turned into low-code models and running software, all whilst collaborating with others all over the world in front of their digital display walls. Last 2 years, the thing i miss most about working in the office, is the ability to collaborate with co-workers in front of a huge whiteboard. The brainstorming, ideation. Miro is nice, but it deserves a huge screen, it needs more interaction with your co-workers, and it needs to help you take your drawings into real value (running software, designs that can be fed into 3d printers, cnc machines, etc).
layer8 4y ago
Imagine TeX becoming unavailable because Knuth didn’t update it for three years.
- neerajk 4y ago
  From the Tex Tuneup of 2021: "The TEX family of programs seems to be nice and healthy as it continues to approach perfection. Chances are nil that any documents produced by previous versions of TEX or METAFONT will be affected by the changes in the new versions" This is how the Gods do programming :)

electroly 4y ago

For open source code, I think the concern is practical: bit rot is real, and libraries with no recent updates are more likely to have suffered bit rot. It's not that a library can't be finished, but that the world in which it lives never stops moving. It can be a bigger or smaller problem depending on the ecosystem. Old C89 libraries have a good chance of still working, because the ecosystem isn't moving so much any more. Old C# libraries almost definitely don't, because the ecosystem is moving quickly.

forgotmypw17 4y ago
Perhaps the solution is a monthly "NOOP" release?
- twicetwice 4y ago
  maybe commit to a log indicating that the test suite has run correctly as of <today's date>?this assumes you have a useful test suite but also at least indicates that you're still paying attention & trying to ensure your library works
  - forgotmypw17 4y ago
    Great idea!
  - svieira 4y ago
    quid custos ipsos custodiet still applies. The fact that your test suite ran in Esolang v27.8 successfully doesn't mean what you-the-consumer want it to mean if the last supported version of Esolang is v96.2. It just means someone down-stack of you is committed to backwards compatibility.
    - travisjungroth 4y ago
      That future version won’t be on the supported versions list anyway.
      - forgotmypw17 4y ago
        I think this varies by project. I personally support every version of my projects. My goal is not to minimize the effort to myself but to facilitate the use of my software.
        travisjungroth 4y ago
        I meant the new version of Esolang, v96.2, wouldn’t be explicitly supported by your project.
        forgotmypw17 4y ago
        Ah, also a good point.
- budoso 4y ago
  Agreed but this definitely isn’t in the interest of library maintainers. If they did so it’d mean they are acknowledging all the currently open issues and deciding to do nothing, which would sometimes cause backlash.
  - bliteben 4y ago
    I mean most projects just auto close all issues now. Dunno where this desire to have 0 open issues came from. Seems like in the past projects would mark the issue as unconfirmed and ignore it, now they all want to close the thread and not allow further comments. Almost as if someone is going to judge their open source project negatively for having open issues, which if that has ever happened that person is more insane than the devs practicing this.
- ep103 4y ago
  I would assume a noop is automated, and the library is no longer maintained. If, however, I saw a statement at the top of the README that said: "Update as of 2 months ago: We believe this project to be complete. We are not adding new features at this time, but if you see any issues, please open a ticket, as this project is still under active development as needed" then I would feel very confident.
  - forgotmypw17 4y ago
    Thanks, that's a good point.
ryandrake 4y ago
Bits don't rot--vendors break things. If my code built with yesterday's SDK and ran on yesterday's OS, and it doesn't for today's, that's not some supernatural phenomenon where digital media rots away--let's clearly blame who's causing it: SDK and OS vendors making changes that break backward compatibility and dump the maintenance burden on developers. The term "bit rot" is an attempt to shift the blame away from those who are causing the rot in the first place. Whether or not it's good to have a moving ecosystem is another story, but I request we not use the term "bit rot" when we mean "vendors breaking compatibility."

mey 4y ago

If a library is not updated in some capacity "recently" (coming from the Java land, "recent" is a different timescale than Javascript), then I have little confidence that a security issue can be resolved if discovered. Even if a library is complete, it may depend on libraries downstream that do have security issues that are no longer supported, which means it needs to swap to newer versions, etc.

bsaul 4y ago

About open source lib not being updated : The thing is, even if the lib is "feature complete", it's pretty rare to not have to update anything, since the ecosystem in which this lib evolves will undoubtely have changed. Programming language, hardware, OS, etc. everything evolves all the time.

smt88 4y ago
Security threats also evolve all the time. A library that hasn't been updated in months is very likely an insecure library.
- FpUser 4y ago
  I use an ancient library to perform some math. It's been working just fine for more than 10 years without any need for update. Can someone explain why is it insecure and what updates are needed to complex algos to make them so? When looking at the code it is pure computation. I think what you are saying is simply FUD when taken as a blanket statement.
  - x3n0ph3n3 4y ago
    Are you passing user input into it? Does it interact with anything on the system? Poorly sanitized inputs present a very serious risk for RCE vulnerabilities.
    - FpUser 4y ago
      As already said it is pure computational lib. It does not interact with anything and I use it from my code. There are tons of libraries like this. They work just fine, do not pose a security risk and have no need for update. But thanks for trying anyways.
  - smt88 4y ago
    > I use an ancient library to perform some math. Anyone can cherry-pick examples to try to disprove a security principle. A pure, functional math library isn't representative of the vast, vast majority of libraries that are imported every day. The most-used libraries across languages are for things like database access, logging, package management, HTTP, and (de)serialization. All of those things need to be kept updated for security. > Can someone explain why is it insecure and what updates are needed to complex algos to make them so? When looking at the code it is pure computation. You didn't specify the language or library. Most libraries that people import are going to be JS, just because of the number of JS users and the minimal standard library in that language. Many are also going to operate on user input, which means they can have vulnerabilities. The mathjs package in NPM, for example, has had tons of vulnerabilities[1]. 1. https://security.snyk.io/package/npm/mathjs https://security.snyk.io/package/npm/mathjs

thenerdhead 4y ago

I mean a heartbeat is needed sometimes to make sure something is still alive and can address critical issues if they do happen. But I do agree that libraries and apps don't need to "update" to show that. Maybe some other way like "Hey, we're still here just the thing we're working on doesn't need an update" would suffice for most things.

aposm 4y ago

By "the world" I think you mean a specific subset of people: investors/execs/the business side. I don't particularly believe that average end users or competent engineers feel that way...

naniwaduni 4y ago
In fact, average end users infamously don't voluntarily update things that aren't visibly broken.

zeroonetwothree 4y ago

I would love to see this theoretical world in which libraries have no bugs. Thing is, even if there are no known bugs, having rare updates means if I do find a new bug it’s less likely to get addressed quickly.

Gormo 4y ago
I'm not sure I follow your logic. If you find a bug, wouldn't that provide a reason for updating your code? What is the utility of issuing superfluous updates when you don't have any new known bugs to fix? How does doing that shift your likelihood of fixing bugs when they are found, in any direction?

donatj 4y ago

A PHP library I use and used to help maintain had a bit of a fight break out in the Issues on GitHub a couple weeks ago. They were dropping support for older versions of PHP despite getting nothing from it and using none of the newer features. Just needlessly limiting the audience, and churn for churns sake.

taftster 4y ago
I hear you and I get what you're saying. However, to argue the other side, maybe it's a decision based on the possibility of long maintenance going forward. Keeping track of, in your example, PHP and all of its various versions is mentally daunting. What's wrong with a project just saying, "Hey look, we're not saying it won't work for you, but if you're running these older versions, we just don't give you any guarantees that it does. YMMV." e.g. say a bug comes up in the library, and say that it only affects older versions of PHP. Why can't the project just shrug its shoulders and be truthful that it doesn't have interest in maintenance/support against those old versions? It's better that the project declares this intention now, before the bug comes up, then later having to part ways with the old versions more abruptly. This is why OSS is great, as you can decide if, at the time said bug is found, that you want to provide legacy support for older PHP versions, maybe through a fork or other means. Have at it, it's your software too.
shagie 4y ago
I am reminded of the libressl - 30 days in report. https://youtu.be/oM6S7FEUfkU?t=1073 https://youtu.be/oM6S7FEUfkU?t=1073 Removing support for old versions is a simplification of what needs to be considered. It is a reduction of complexity. If someone is running a PHP version that has been EOLed, it is perfectly reasonable to discontinue support for it in a library - even if new features that weren't available in the EOL'ed version haven't been added yet.
- unity1001 4y ago
  > If someone is running a PHP version that has been EOLed, it is perfectly reasonable to discontinue support for it in a library Its not. Large Linux distributions support those PHP versions for a long time in their LTS releases, and majority of web hosts and infra providers use those distros in their infra.

sodapopcan 4y ago

The Elixir ecosystem is quite good for this. I've found smaller libraries that haven't been update in a long time but still work just fine since Elixir itself hardly ever changes in a breaking way (the recurring phrase in the community being: "There will probably never be a version 2"). It's weird to get used to at first but it's actually quite refreshing.

OkayPhysicist 4y ago
I used an Erlang library in my Elixir project a while back that hadn't had an update in a decade. If a language's semantics don't change (and they really, really shouldn't change without either A) a very good reason or B) a really, really good backwards compatibility story) then there's really no reason for a library that does a job well to ever update.

hwbehrens 4y ago

> feature complete with no bugs I suppose for simple libraries this might be possible (e.g. left-pad) but how would you know in general that something is bug-free? `units` was introduced in 1979 and is still one of the canonical examples used in automated program repair research to show that new bugs can be found even in extremely well-studied codebases. I think people might be: 1. Implicitly assuming that all nontrivial code has bugs, and 2. Using recent commits as a signal that means, "If I ran into a bug, there is someone who might fix it (or at least accept a fix PR) to take away my immediate pain.

dotancohen 4y ago
I've never used or heard of the left-pad library, but I'm willing to bet that I could find an RTL bug in a library with that name.
__turbobrew__ 4y ago
That reminds me of the overflow bug in the JDK binary search that was present for quite a while.

sorisos 4y ago

I like that so many unix command tools (like cat, ls...) is rarely updated. Often comes with a man page written in 30 years ago. Same with a lot of C libraries.

Lutger 4y ago

One word: security updates. Ok that was two. Most software had dependencies, those tend to surface vulnerabilities over time.

musicale 4y ago

Other game platforms (game consoles, Windows) seem to have drastically better backward compatibility and API stability. If you look at the Nintendo DS/3DS (for example), the platform had many hardware revisions (about every other year) and dozens of firmware revisions, yet games from 2004 still worked on a brand new 3DS in 2020. On the Sony side, PS4 games from 2013 still work fine on a PS5 in 2022 (and probably through 2029.) Steam has tons of old games that work great on Windows (but the Mac side took a major hit with macOS Catalina's 32-bit apocalypse.)

danhor 4y ago
The 3DS physically included most parts of a DS, that often went unused in "normal" operations. In my experience old games often work better in proton/wine than in Win 11. My understanding is that the Steam Runtime also provides a stable base, that (or something close to it) unfortunately wasn't adopted in other ecosystems. Flatpak is great, but not used widely used for binaries yet.
nerdix 4y ago
And Playstation is way behind Xbox when it comes to backwards compatibility. Xbox backwards compatibility goes all the way back to the original Xbox released in 2001.

ako 4y ago

Everything you use continuously improves. What do you use that has seen improved versions since you bought it? Our knowledge, our abilities, our raw materials continuously improve, and everything is expected to advantage of this. Things that don't improve, are soon outdated and fall behind. Everything continuously improves: cars, bicycles, windows, houses, refridgerators, tv, etc, etc.

userbinator 4y ago
s/improves/churns/g We reached the peak of software usability a long time ago, probably around the turn of the century. Now it's all about trendchasing, change for the sake of change, dark patterns to squeeze the $$$ out of you, etc.
- ako 4y ago
  I think there's still room for real improvement: once we have afforable displays that cover your entire wall, imagine what something like miro could bring you. Visual collaboration, pen drawings that turn into organizated information, architecture diagrams that can be turned into low-code models and running software, all whilst collaborating with others all over the world in front of their digital display walls. Last 2 years, the thing i miss most about working in the office, is the ability to collaborate with co-workers in front of a huge whiteboard. The brainstorming, ideation. Miro is nice, but it deserves a huge screen, it needs more interaction with your co-workers, and it needs to help you take your drawings into real value (running software, designs that can be fed into 3d printers, cnc machines, etc).

layer8 4y ago

Imagine TeX becoming unavailable because Knuth didn’t update it for three years.

neerajk 4y ago
From the Tex Tuneup of 2021: "The TEX family of programs seems to be nice and healthy as it continues to approach perfection. Chances are nil that any documents produced by previous versions of TEX or METAFONT will be affected by the changes in the new versions" This is how the Gods do programming :)