12 ms·

People think if a project on github hasn't been updated since 3 months then it has been abandoned!! Like, why don't we just let projects be "done"? Things don'

• fiddlerwoaroof 5y ago
  This is one reason I really like Common Lisp and Clojure: both communities have developed a mindset that allows libraries to be done and, as a result, I notice a lot less churn than in other languages.
  • eigenhombre 5y ago
    I also like them for the same reason. The languages themselves evolve slowly (Clojure) or not at all (Common Lisp). A library that emphasizes simplicity and does One Thing Well can be stable and continue to be useful indefinitely. There are network effects too -- if my library uses stable libraries and is built on a stable language, it need not change at all. On the other hand, there are the big libraries that, for convenience, pull one or two small things from several others -- their surface area becomes so large they are practically guaranteed to generate more work in terms of security updates, dependency conflicts, and the like. I experience this at times developing in Clojure, whose hosted nature means issues can emerge from the Java ecosystem, which is obviously enormous and dynamic. We recently had a defect at work relating to a conflict between transitive (Java) dependencies from a third party library used to serialize exceptions prior to transmission to their service, and another tool used only for generating "literate"-style code documentation. While not a production defect, it cost us some time and could have been avoided (both by us and the libraries' authors) by more hard-headed evaluation of the tradeoffs involved in introducing certain dependencies in the first place.
  • cubano 5y ago
    I would use Occam's razor with this idea and posit that it is much more like that its a lack of overall mindshare with functional programming than with the nature of language abstractions. Don't tell me that Lisp ever achieved cool-kid status that a thousand different libs wouldn't pop up basically overnight.
    • strawhatguy 5y ago
      If the premise is that you limit your dependencies have low maintenance code, you'd probably not include many (any?) of said thousands of libs. Also it isn't about the number of libs, but how often they change.
    • fiddlerwoaroof 5y ago
      I don’t think this is entirely right: there are plenty of languages with similarish mindshare that don’t have this: just building a Haskell project, for example, can be a nightmare if they hasn’t been maintained. Scala also has this issue, despite having a similar marketshare as Clojure.
    • fulafel 5y ago
      The thing about allowing libraries being done is a bit more nuanced than not having lots of different libraries doing the same thing. There are lots of competing libraries even now and existing libraries do get surpassed in popularity. But they keep working and don't become unusable or problematic as often as in other cultures.
• amw-zero 5y ago
  I completely agree with you, but your last point is exactly why recent updates are a proxy for ‘well-maintained.’ Software is so complex that it _has_ to have dependencies, and even if you vendor them / compile to an executable, that doesn’t account for upstream bug or security fixes.
  • hsn915 5y ago
    1) If you buy into this concept, you would naturally limit your dependencies to the bare minimum. 2) Static linking does a good job of protecting against when upstream introduces new bugs or security holes.
    • chousuke 5y ago
      Static linking also protects you from security patches. I like writing low-dependency software, but what that means is that I pick a distribution to build on and use their packages. If a library is not packaged, it has to be really good for me to depend on it. Sure, it might break once in a blue moon depending on how stable the distribution you use is, and you'll need to refresh your stuff every 4-9 years when a new version of the base OS is released and the old one goes EOL, but most of the time the result will be extremely low-maintenance.
    • sixstringtheory 5y ago
      > limit your dependencies to the bare minimum I get this desire, but likely it guarantees more work for yourself and probably more undiscovered bugs, because with only one set of eyes, to invert Linus’ law, many bugs may lurk deep.
      • hsn915 5y ago
        Have you actually tried to reduce dependencies? I mean, are you speaking from experience, or just theorizing? Here's something to keep in mind: when you depend on a huge library that has 40 features, it's likely your program only needs 5 of them. So, while the huge library benefits from "many eyes", your particular program would benefit much more from not depending on a library with a lot more features than you need. Also I don't know if you've seen how open source works, but chances are the number of people actively looking at the source code for these libraries to uncover bugs or security holes is very small to non-existent.
• bArray 5y ago
  > Like, why don't we just let projects be "done"? Things don't need to be maintained and updated for eternity. This is generally why I opt for "single-file" libraries that do one simple task well. The smaller the library, the more likely it is "done". For example, do I want some insanely complex image library that handles every file format under the sun, or do I just want some basic one that allows me to output a simple JPEG? I often find myself referring to "single_file_libs" repository: https://github.com/nothings/single_file_libs https://github.com/nothings/single_file_libs Looking at the open issues, it doesn't appear to be actively maintained but it's still an incredibly good resource for "completed" projects.
  • bjterry 5y ago
    > Looking at the open issues, it doesn't appear to be actively maintained I'm not sure if this is intentionally ironic or not, but it does seem like if your small libraries aren't getting updated regularly because they are done, you at least want the meta library (in this case the single file libs repository) to be updated regularly with new small libraries.
    • bArray 5y ago
      > [..] you at least want the meta library (in this case the single file libs repository) to be updated regularly with new small libraries. It's the meta-library collection repository I was talking about, not the single-file libraries.
  • bmicraft 5y ago
    Funny you chose to say jpeg, because jpegxl is just on it's way to getting big. If you're dealing with a lot of images the savings are probably big enough to warrant an update. There really is nothing that can be considered completely stable.
• lr4444lr 5y ago
  Well, bugs do get found, and continual new demands from humans make more optimizations necessary. SemVer is the compromise between stability and continual improvement, and I think it works pretty well, all considered.
• z3t4 5y ago
  > and Windows is kind of known for bending over backwards to maintain compatibility with old programs Maybe they used to, but good luck running anything made for Windows XP on current version of Windows. But you will have a better luck if you run it with Wine on Linux.
  • mb_72 5y ago
    I have an application I developed for a client starting in 2005 using Delphi 7; my VM is based on Windows XP, and the app worked fine on Windows 7 and is now used on Windows 10. I had to update one setting in an external configuration file for slight differences in the ADO driver, but other than that I haven't rebuilt the executable for years. I was genuinely pleased for the client as they are nice people running an essential service on a budget that is always under threat, and this result means not needing to pay for a silly 'fresh' version of the application.
    • spockz 5y ago
      How many security features inherent to 64bit processes are they missing? Or is that not relevant for their deployment?
      • mb_72 5y ago
        No, no relevant in this case.
• derefr 5y ago
  Packaging your software into a container-image accomplishes almost exactly the same thing, without the need to be using a stack that can create standalone static binaries. I would point out, though, that even when you can just continue to use a single pinned version of a Docker image forever (because the program itself is stable, or is part of a stable system that only uses the program in precise ways), people still value regular releases, and see non-upgrading images as “rotting” — because they can contain vendored deps, and those deps can have security vulnerabilities discovered in them over time.
  • hsn915 5y ago
    I haven't worked a lot with Docker or similar containerization tools, but my impression is they require you to have an internet connection to download stuff. At least with Docker, when you write or download a docker file for the first time, it's just a description of stuff that needs to be downloaded and maybe commands that need to be executed. This kind of thing is qualitatively much worse than a statically linked executable binary in terms. > a stack that can create standalone static binaries. Yea, a language that has the notion of a compiler is a MUST if you actually care about this kind of thing.
    • 0xCMP 5y ago
      they're specifically talking about the resulting image built using whatever dockerfile you had. they can be exported to a file or pushed to repos to be reused elsewhere.
  • dehrmann 5y ago
    Docker is especially bad for this. A jar file that runs today will probably run fine in 10 years on future Java. The container might, but it almost certainly has a huge number of security vulnerabilities, and maybe no one uses AMD64 and ARM anymore.
• e3bc54b2 5y ago
  Anything that connects to or supports something that connects to the internet eventually gets used as some part of vulnerability, and hence needs to be updated. But, I agree with your sentiment. Endless feature bloat is not necessary for vast majority of software. The expectation that every software must remain updated forever is just not sustainable.
• amadeuspagel 5y ago
  > People think if a project on github hasn't been updated since 3 months then it has been abandoned!! This a heuristic that generally works. Most projects that don't have recent commits really are abandoned. And when you open a project on github, one of the first things you see is when every file was last updated. Maybe github should offer other heuristics, or of it already has them, display them more prominently.
  • hsn915 5y ago
    I don't necessarily disagree, but this is the cultural problem I'm sort of pointing the finger at.
• tjpnz 5y ago
  >People think if a project on github hasn't been updated since 3 months then it has been abandoned!! People are too quick to assume that all Github repos are meant for public consumption. Can only speak for myself really but most of what I've pushed there was designed with only me in mind. If others find it useful that's nice but don't expect me to accept pull requests.
  • TedDoesntTalk 5y ago
    This is precisely why I have a private git repo.
    • capableweb 5y ago
      It would be sad if people could only chose between "Public and I commit to maintain this for all of you" and "Private and it's just for me". What's wrong with "This is public but it's still for me, you're welcome to use it if you want to but don't expect anything from me". This is what open source is really about for me.
      • barnabee 5y ago
        Totally agree, open source is about sharing code, designs, solutions to problems, etc. not running, maintaining, and and promoting a project.
        • heurisko 5y ago
          Some open source efforts are geared towards running, maintaining, and promoting a project. Adoptopenjdk comes to mind. https://adoptopenjdk.net/ https://adoptopenjdk.net/
          • barnabee 5y ago
            This seems like a volunteer project _around_ open source rather than open source. It may seem pedantic but it feels useful (to me at least) to separate the act of sharing and collaboratively improving code from the projects and politics that often get built around that.
• Osiris 5y ago
  I have a side project that I haven't updated in years. I haven't needed to because Windows is fantastic at backwards compatibility. Also the website automatically handles payments and sending license keys. The only work I do is when PayPal integration breaks because they make some minor change on their end. Unfortunately, Windows 11 removed the IDeskBand interface I rely on so I might actually have to do some work.
  • strawhatguy 5y ago
    Curious, do you limit yourself to the C win32 api on Windows? I hear that low of level never really changes, and you can do all the stuff the newer windows gui libs can do.
• 3pt14159 5y ago
  Unless you're doing something mathematical, where you can exhaustively test every input and output and ship something that's essentially close to the platonic ideal of the thing, you're going to need to update. Protocols change, programming languages change, human languages change, boarders change, definitions of time change, laws change, sensors change, and on and on. It's like asking why a person can't be just done learning so they can live their life. Well, they can, but pretty soon the world is inaccessible to them. They can't use a computer or a phone because they stopped learning in 1995 and they're utterly dependant on others to do things for them. But I will say this, I've long been thinking that there should at least be a programming language and OS that does its best to not change. A sort of whole environment where every single piece that's out of beta commits to minimal interface changes over time. Fixing security bugs and supporting new emojis, fine. We have to do stuff like that. But everything else is just as frozen as can be. It would be useful for super long term software. If we have buildings still around from 100 years ago we should be able to build for 100 years from now without a team around for constant maintenance. Though I do not think it can ever be maintenance free.
  • estaseuropano 5y ago
    No building stands for 100 years without maintenance. 100 years ago heating and light by coal or gas were still common, so every single old building has had upgrades to electricity (or first gas, then electric). The roof leaked, the wood rotted, a bunch of people died in a fire and now all buildings in a similar style need to add a fire escape...
    • titzer 5y ago
      There are hundreds of churches in Europe who have stood for centuries without the "maintenance" you are talking about. You are talking about upgrades, not maintenance. Adding gas and electricity are modern (< 150 years ago) things, as are earthquake codes, fire escapes, etc. I'm not suggesting people go live in cathedrals, but there's a huge hole in your reasoning.
      • lexicality 5y ago
• nobody0 5y ago
  "Art is never finished only abandoned"
  • speed_spread 5y ago
    "Klingon software is not released, it escapes"
• oakfr 5y ago
  I evaluate the liveness of a github project based on the responses to questions (latest post, time to reply). Not by when the last change was made.
• nonoesp 5y ago
  It'd be useful to have a way to tell visitors this project still works without having to push commits to refresh the last updates timestamp.
  • Buttons840 5y ago
    I do this in the README. Include a "state of the project" section. Seeing no updates in 3 months is one thing. Seeing no updates on a project that describes itself as a work in progress is another thing.
  • nly 5y ago
    Isn't this why we have CI/CD and scheduled pipelines?
    • TeMPOraL 5y ago
      Seems like a waste if it's just doing the same work all over again just to update a timestamp. A waste that someone has to pay for.
      • OneWingedShark 5y ago
        You are right; it's because the "modern" CI/CD is ill-designed, thanks in part to being "generalized" to handle text and "generalized" tools like C compilers and makefiles... instead of, you know, working in the actual problem-space. See this: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.26.2533&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.26....
    • OneWingedShark 5y ago
      > Isn't this why we have CI/CD and scheduled pipelines? I mean, kind-of. One of the problems with CI/CD though is that they're poorly designed for the job they do; see this: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.26.2533&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.26.... The TL;DR here is that by structuring your code and storing it in a database structured hierarchically you can solve CI/CD in a MUCH nicer manner: your root node's history becoming a history of the project in a compilable state.
• randyrand 5y ago
  > Yes, to a certain degree it's impossible to design software that does not exist as a part of an ecosystem, which is why I put it in quotes. I’m doing a big embedded project and all the code is self contained! The only inputs are physical user inputs.
• 5faulker 5y ago
  "Evergreen" might be a word we can use here.
• paulddraper 5y ago
  But what doesn't change? Network protocols? No, HTTP/3 is here. OS? Kernel, sure, but everything else no. E.g. most Linux OSs recently changed their entire init system. CPU architectures? ARM was irrelevant a few years ago. Faster CPU instructions are arriving every year. You say, "okay, well just recompile." Which brings us to.... Build tools? These are a nightmare to make stable in the best of circumstances. It's all fiction. Code rot is real.
  • hsn915 5y ago
    http is not a networking protocol in the sense I meant. It's an application level protocol. Although you can still write a server that implements only http1.1 and it should still work fine. A lot of the things that you describe as changing don't really need to change. Operating Systems? Windows XP was probably the best windows, and it's from nearly 20 years ago. Looking at Windows 10, what exactly does it bring to the table? It's a much worse experience overall. Compilers don't need to change either.
  • remram 5y ago
    How often are changes in your web app directly warranted by a new init system or HTTP protocol? Does your code directly depend on what init system is running it, or somehow become unusable if it doesn't understand the latest HTTP version? If yes, just what the hell are you making?
    • paulddraper 5y ago
      Yes to the first question. My SystemD-based web server doesn't work in systemd. (Well the web server itself probably works, but the packaging needs to change.) As for the second, code can still work and yet be obsolete.
      • paulddraper 5y ago
        Typo: "my system v web server..."
• huijzer 5y ago
  The answer is in Lehman's laws of software evolution. Most systems "must be continually adapted or [they] becomes progressively less satisfactory". The argument is simple. The world changes all the time and most software interacts with the world. Therefore, software needs maintenance in order to keep up with the changing world.
  • jlundberg 5y ago
    Software close to the user have this need for adaption. However, my experience is that the building blocks for making even large software systems are increasingly more stable and Debian GNU/Linux is a prime example of this.
  • TeMPOraL 5y ago
    Yeah, but the rate of that change makes all the difference. Consider biological systems: they're constantly evolving, constantly in flux - and yet, all living things we can see with unarmed eyes are fixed in the scope of a human lifespan. Most of those don't show meaningful changes withing lifetime of a human society. Cooking recipes of our great grandparents are still valid today, because fruits and vegetables and meat didn't change that much[0] over the last century. Wood still works the same way it did 1000 years ago. Being able to change much faster is good - as long as the changes tend to lead in useful direction. Software seems to be changing way faster than it's needed, because it's changing for the wrong reasons - instead of improving the value it provides, it's usually about one-upping competition, or forcing recurring payments, or forcing competitors to waste money (e.g. by introducing incompatibility on purpose). Software industry resembles a rain forest, in terms of both diversity and frequency of senseless murder (er, "survival of the fittest"). But as humans, we've dominated this planet by being smarter than that, by being more efficient than natural evolution. -- [0] - Despite being optimized directly by our industrial processes.
  • buu700 5y ago
    That's a nice, succinct way to put it. Software that doesn't interact with the world can be finished. Software that does ends when the world does. I suppose then that a benefit of pure functional programming is that you can statically analyze whether a given piece of software is plausibly "done" or simply unmaintained, depending on whether and to what extent it uses monads.
• wpietri 5y ago
  > Like, why don't we just let projects be "done"? Things don't need to be maintained and updated for eternity. As the Buddha taught, desires are numberless. I don't think I've ever even heard of a piece of software that hit 1.0 and people were like, "Welp, it's perfect, never change a thing." I've certainly never worked on one. Indeed, the biggest sign of project success to me is releasing an initial version and people being shocked, shocked at the obvious features I missed. And I love it, as that's proof that they're really trying to use it for their real-world needs.
• dheera 5y ago
  > Like, why don't we just let projects be "done"? Things don't need to be maintained and updated for eternity. I agree with this but > native executable binary file This is hard because new architectures, instructions, optimizations show up every few years.
• 1vuio0pswjnm7 5y ago
  "In my mind, the best software engineering is where you solve a problem once and your solution just works and needs no configuration or maintenance or updates." https://cr.yp.to/software.html https://cr.yp.to/software.html
• TameAntelope 5y ago
  Can you elaborate about this mindset in the context of vulnerabilities and bugs?
• grimgrin 5y ago
  > What I'm advocating for here requires that your program be compiled into a native executable binary file, and it must embed all its library dependencies (aka static linking). the super example of this is justine's project https://github.com/jart/cosmopolitan https://github.com/jart/cosmopolitan it's pr fucking cool > Cosmopolitan Libc makes C a build-once run-anywhere language, like Java, except it doesn't need an interpreter or virtual machine. Instead, it reconfigures stock GCC and Clang to output a POSIX-approved polyglot format that runs natively on Linux + Mac + Windows + FreeBSD + OpenBSD + NetBSD + BIOS with the best possible performance and the tiniest footprint imaginable.