3 ms·

Agree, I think we need to speak of abandoned, versus maintained. No activity doesn't mean abandoned, it can just mean super stable and few bugs to fix. Abando

by b112 2y ago

Agree, I think we need to speak of abandoned, versus maintained. No activity doesn't mean abandoned, it can just mean super stable and few bugs to fix. Abandoned is a big worry though. I wonder if we need a canary file, but in the repo. An "I'm still here" file.

layer8 2y ago
If a library is stable with no major bugs, then I don’t see much of a difference between abandoned and maintained. The one thing I would look at instead is open issues.
- b112 2y ago
  Abandoned means no one around to deal with security issues, or impacting bugs. Maintained means they are. There may be no new features though. (these are my definitions, but I think there should be similar concepts in all dev's heads)
  - layer8 2y ago
    It changes nothing about the current version of the library though. It only impacts how quickly or easily one would be able to get a fix in case some issue does come up. But I’m questioning the expectation that such issues will come up, and the associated expectation that one will have to regularly update the library because new issues won’t ever stop coming up.
    - 3pt14159 2y ago
      It's about perception. When I look at a old page on GitHub and there haven't been any code changes in two years but it does look like the Issues page is addressed quickly then I can trust the old code. On the other hand if the Issues page isn't addressed I can assume that the code will cause me problems in the future and I'll look for a different library.
    - b112 2y ago
      There are endless examples of libraries being updated, due to bad code in the library. It's not a rare event, it's very, very common. If a library is abandoned, and no one is around updating the code for vulnerabilities, it's trouble. That's because one day you can use it, and the next you cannot. (Yes you can personally patch it, but that's an issue that's come up. And how will you know? Look at all the bugtrackers daily to see people yelling "HEY!"?)
travisjungroth 2y ago
I still question that. It's generally as good as the day it came out. Discovered vulnerabilities are going to be in the language, probably not in the library itself. As long as it's not dependent on a language that's so old it's not getting security fixes, it should be fine. Actually, a big exception is libraries that have external dependencies that change. A client library for an API, for example. Those can break quickly.
- actionfromafar 2y ago
  Hm, vulns are more common in libraries in general than in the compiler, I'd say. Or am I misunderstanding?
  - travisjungroth 2y ago
    By "discovered vulnerabilities", I mean a security issue that wasn't known when the library was first written but then came to be known. This is what's fixed when a library is maintained. This entirely depends on the library, but I just generally don't see a lot of security fixes in library updates. But for compiler updates, I do. I'm speaking super broadly, and this will be very different for a Python graphing library versus a C networking library.
- bluGill 2y ago
  The vulnerability is almost never in the compiler (not never - I have seen a case, but very rare). Most attacks are in the library itself. If your library has a buffer overflow you are vulnerable. If your library has a C style buffer length + size parameters and you mess them up is it the libraries fault for such a bad API?
ramses0 2y ago
Reading through, they're describing kindof "eras" of best practices. Like "hex" and "base64" might never change (so might never update), but those are kindof prime name tokens. It made me think: `std::hex,base64` vs `boost::hex,base64`, but then assuredly those would be incompatible because $REASONS. ...but what if it was like: `v2025::std::hex,base64` vs `boost::v2025::std::hex,base64` (ie: explicitly stating you're adhering to the v2025 guidelines w.r.t. memory management or parameter naming or whatnot). It's a roundabout way of saying: `tokio::async_foo`, `boost::async_bar`, `v2026::std::async::foo,bar`, where as the marketplace of ideas settles on "better" ways of dealing with async (or whatever) there can eventually be compatibility between different object "modalities" (ways of working). `std::hex,base64` should be quite stable, but having a path for `...::webapp::` and `...::database::` to eventually interop seems really useful for a language to encourage?

by b112 2y ago

layer8 2y ago

If a library is stable with no major bugs, then I don’t see much of a difference between abandoned and maintained. The one thing I would look at instead is open issues.

b112 2y ago
Abandoned means no one around to deal with security issues, or impacting bugs. Maintained means they are. There may be no new features though. (these are my definitions, but I think there should be similar concepts in all dev's heads)
- layer8 2y ago
  It changes nothing about the current version of the library though. It only impacts how quickly or easily one would be able to get a fix in case some issue does come up. But I’m questioning the expectation that such issues will come up, and the associated expectation that one will have to regularly update the library because new issues won’t ever stop coming up.
  - 3pt14159 2y ago
    It's about perception. When I look at a old page on GitHub and there haven't been any code changes in two years but it does look like the Issues page is addressed quickly then I can trust the old code. On the other hand if the Issues page isn't addressed I can assume that the code will cause me problems in the future and I'll look for a different library.
  - b112 2y ago
    There are endless examples of libraries being updated, due to bad code in the library. It's not a rare event, it's very, very common. If a library is abandoned, and no one is around updating the code for vulnerabilities, it's trouble. That's because one day you can use it, and the next you cannot. (Yes you can personally patch it, but that's an issue that's come up. And how will you know? Look at all the bugtrackers daily to see people yelling "HEY!"?)

travisjungroth 2y ago

I still question that. It's generally as good as the day it came out. Discovered vulnerabilities are going to be in the language, probably not in the library itself. As long as it's not dependent on a language that's so old it's not getting security fixes, it should be fine. Actually, a big exception is libraries that have external dependencies that change. A client library for an API, for example. Those can break quickly.

actionfromafar 2y ago
Hm, vulns are more common in libraries in general than in the compiler, I'd say. Or am I misunderstanding?
- travisjungroth 2y ago
  By "discovered vulnerabilities", I mean a security issue that wasn't known when the library was first written but then came to be known. This is what's fixed when a library is maintained. This entirely depends on the library, but I just generally don't see a lot of security fixes in library updates. But for compiler updates, I do. I'm speaking super broadly, and this will be very different for a Python graphing library versus a C networking library.
bluGill 2y ago
The vulnerability is almost never in the compiler (not never - I have seen a case, but very rare). Most attacks are in the library itself. If your library has a buffer overflow you are vulnerable. If your library has a C style buffer length + size parameters and you mess them up is it the libraries fault for such a bad API?

ramses0 2y ago

Reading through, they're describing kindof "eras" of best practices. Like "hex" and "base64" might never change (so might never update), but those are kindof prime name tokens. It made me think: `std::hex,base64` vs `boost::hex,base64`, but then assuredly those would be incompatible because $REASONS. ...but what if it was like: `v2025::std::hex,base64` vs `boost::v2025::std::hex,base64` (ie: explicitly stating you're adhering to the v2025 guidelines w.r.t. memory management or parameter naming or whatnot). It's a roundabout way of saying: `tokio::async_foo`, `boost::async_bar`, `v2026::std::async::foo,bar`, where as the marketplace of ideas settles on "better" ways of dealing with async (or whatever) there can eventually be compatibility between different object "modalities" (ways of working). `std::hex,base64` should be quite stable, but having a path for `...::webapp::` and `...::database::` to eventually interop seems really useful for a language to encourage?