I’m curious how software can be created and evolve over time. I’m afraid that at some point, we’ll realize there are issues with the software we’re using that can only be remedied by massive changes or a complete rewrite.

Are there any instances of this happening? Where something is designed with a flaw that doesn’t get realized until much later, necessitating scrapping the whole thing and starting from scratch?

        • SleveMcDichael@programming.devEnglish
          9·
          10 months ago

          Definitely. As nice as it would be, I don’t think it will significantly change any time soon, for several reasons. Not least of which is because several programs would likely just flatly refuse to implement such a change, judging by some of them refusing to even consider patches to implement the XDG Base Directory Specification.

      • deadbeef79000@lemmy.nz
        51·
        10 months ago

        So much of that is PDP-11 baggage or derived from it.

        Or more generally Very Small Disk baggage.

        • z3bra@lemmy.sdf.org
          31·
          10 months ago

          $PATH shouldn’t even be a thing, as today disk space is cheap so there is no need to scatter binaries all over the place.

          Historically, /usr was created so that you could mount a new disk here and have more binaries installed on your system when the disk with /bin was full.

          And there are just so many other stuff like that which doesn’t make sense anymore (/var/tmp comes to mind, /opt, /home which was supposed to be /usr but name was already taken, etc …).

            • z3bra@lemmy.sdf.org
              1·
              10 months ago

              Today’s software would probably break, but my point is that $PATH is a relic from ancient times that solved a problem we don’t have anymore.

            • z3bra@lemmy.sdf.org
              1·
              10 months ago

              You missed my point. The reason $PATH exists in the first place is because binaries were too large to fit on a single disk, so they were scattered around multiple partitions (/bin, /sbin, /usr/bin, etc…). Now, all your binaries can easily fit on a single partition (weirdly enough, /usr/bin was chosen as the “best candidate” for it), but we still have all the other locations, symlinked there. It just makes no sense.

              As for the override mechanism you mention, there are much better tools nowadays to do that (overlayfs for example).

              This is what plan9 does for example. There is no need for $PATH because all binaries are in /bin anyways. And to override a binary, you simply “mount” it over the existing one in place.

                • z3bra@lemmy.sdf.org
                  1·
                  10 months ago

                  I’m not saying we should get rid of $PATH right now. My point is that it was created to solve a problem we don’t have anymore (not enough disk capacity), but we still keep it out of habit.

                  As a reminder, the discussion is about what should be rewritten from scratch in linux. And IMO, we should get rid of $PATH as there are better options.

                • z3bra@lemmy.sdf.org
                  1·
                  10 months ago

                  By mounting the binary over, I mean something like a bind mount. But in your case of a wrapper script, it doesn’t apply indeed. Though in this case I would simply name the script steam-launcher and call it a day 🙂

                  Having multiple executables with the same name and relying on $PATH and absolute paths feels hackish to me, but that’s only a matter of preference at this point.