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
    link
    English
    5
    edit-2
    3 months ago

    Not really software but, personally I think the FHS could do with replacing. It feels like its got a lot of historical baggage tacked on that it could really do with shedding.

      • @starman
        link
        English
        8
        edit-2
        3 months ago

        Filesystem Hierarchy Standard

        /bin, /dev, /home and all that stuff

          • @SleveMcDichael
            link
            English
            93 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.

        • @[email protected]
          link
          fedilink
          43 months ago

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

          Or more generally Very Small Disk baggage.

          • z3bra
            link
            fedilink
            23 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
                link
                fedilink
                13 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.

            • @[email protected]
              link
              fedilink
              1
              edit-2
              3 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.

              $PATH is very useful for wrapper scripts, without it there wouldn’t be an easy way to for fix the mess that steam does in my homedir that places a bunch of useless dotfiles in it. The trick is simply have a script with the same name as the steam binary in a location that is first in $PATH therefore it will always be called first before steam can start and murder my home again.

              About /var/tmp, I just have it symlinked to /tmp, technically /var/tmp still has a reason to exist, as that location is use for temporary files that you don’t want to lose on power loss, but I actually went over the list possible issues and iirc it was mostly some cache files of vim.

              EDIT: Also today several distros symlink /bin and /sbin to /usr/bin.

              • z3bra
                link
                fedilink
                13 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.

                • @[email protected]
                  link
                  fedilink
                  13 months ago

                  but we still have all the other locations, symlinked there. It just makes no sense.

                  Because a lot of shit would break if that wasn’t the case, starting with every shell script that has the typical #!/bin/sh or #!/bin/bash shebang.

                  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.

                  Does that need elevated privileges? Because with PATH what you do is export this environment variable with the order you want, like this:

                  export PATH="$HOME/.local/bin:$PATH" (And this location is part of the xdg base dir spec btw).

                  This means that my home bin directory will always be first in PATH, and for the steam example it means that I don’t have to worry about having to add/change the script every time the system updates, etc.

                  Also what do you mean by mounting a binary over? I cannot replace the steam binary in this example. What I’m doing is using a wrapper script that launches steam on a different location instead (and also passes some flags that makes steam launch silently).

                  • z3bra
                    link
                    fedilink
                    13 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
                    link
                    fedilink
                    1
                    edit-2
                    3 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.

        • @[email protected]
          link
          fedilink
          English
          2
          edit-2
          3 months ago

          (It was a joke about how OS X, despite being literally UNIX®, doesn’t follow the filesystem hierarchy standard because Apple decided they knew better and “shed historical baggage” by putting things in places like /Applications, /Users, /Library, and /System instead.)

          • @SleveMcDichael
            link
            English
            13 months ago

            Ah. I’ve only ever used a Mac like once ever, and that was over a decade ago. However that does sound pretty close to what I’d do, something like /programs, /libraires , /config, /data, and /users.