Hey, I’ve recently designed a Poster about the FHS since I often forget where I should place or find things. Do you have any feedback how to make it better?

I updated the poster: https://whimsical.com/fhs-L6iL5t8kBtCFzAQywZyP4X use the link to see online.

Dark mode

Old version

  • @netwren
    link
    91 year ago

    I don’t understand the ambiguity of where to put your projects.

    I’ve typically always put things under /opt/ TIL /etc/opt was where the config should go.

    • @callccOP
      link
      21 year ago

      Depends on the scope of your project. But if they are services for example or you want them to be run by different users on the system, you could either use /opt or /usr/local. There is some discussion about which is better or how to choose: eg. https://www.linuxjournal.com/magazine/pointcounterpoint-opt-vs-usrlocal . The FHS is mostly relevant when packaging your software though.

      • @netwren
        link
        21 year ago

        Less relevant with Docker or FlatPaks though right?

        • @callccOP
          link
          21 year ago

          I’m not into those since they just shift the complexity. People should learn how to package things and just do it. Ok, documentation on making dpkgs is pretty tough to understand and confusing.

          But yeah, I guess with docker it’s complete anarchy ( the bad kind of)

          • @[email protected]
            link
            fedilink
            21 year ago

            But yeah, I guess with docker it’s complete anarchy ( the bad kind of)

            Not really, usually stuff will be all self contained (no pun intended), container volumes inside docker’s own directory and mounts of folders that will most often all reside under the same repository, then you don’t have to worry about breaking stuff by touching the root, even better if you do that with Podman.

            Flatpak is similar in the way that it also has its own standards and apps are pretty much obligated to follow them. Now the fact that data lives under .var/app/ completely disregarding the XDG spec, while both things are part of Freedesktop… Well that’s just ironic lol

            • @callccOP
              link
              11 year ago

              But who knows what’s inside?

              • @netwren
                link
                21 year ago

                Not at all true. Go inspect the Dockerfile. If done correctly you should be able to inspect the full container build.

                • @callccOP
                  link
                  01 year ago

                  Of course you can, but few people care and do it. There is a saying about docker: “Docker images are like smoothies, you immediately know if you like it but you don’t know what’s inside”. The idea being that there is no good quality control and transparency. People just install random blobs, like in the old days where you would install a cracked game from eMule.

                  If you care about security, docker is not what you want, they are not reproducible nor transparent nor is it possible to easily update broken shared libraries (eg openssl).

                  But then again people have different requirements. Some just wanna have things running quickly without the hassle. That’s where docker shines. But it leads us to a world where we hide ugly stuff under the carpet instead of fixing things.

                  • @netwren
                    link
                    2
                    edit-2
                    1 year ago

                    Agreed but can’t the same be said about pre-compiled binaries?

                    At least with a Dockerfile I can download the repo and make them image for myself.

                    Sure you could’ve downloaded the repo and compiled the binary for yourself but you still had to have all of the libraries setup correctly. It’s more about a codified build process that’s reproducible vs a “supposedly” working documentation on a git repo of make scripts.