[inetknght]

> In reality, larger software projects like nginx and apache have their own opinions and usually serve out of different places.

It might make sense if the software is serving a domain from something installed with a package. Nginx is often installed with a package and long-lived data goes into /var. So it makes sense to serve /var/www for their examples. Then people just build on those examples, sadly being unaware of or unwilling to change to values that were preinstalled for demonstrations.

But for multi-homing a server (or even a single site on that server), I still end up putting stuff under /srv/<domain>/<site>, so example might be /srv/systemd.software/www [0]. Then `/srv/<domain>` might have its own fstab entry -- for example, it might be a bind-mount to somewhere else, or it might be its own disk/encryption, or it might be a network mount.

Any admin can do what they want on their own servers. I just figure it's best to follow documented standards.

[0]: https://github.com/inetknght/systemd.software/blob/0bf207d6f...

[k_roy]

It's a nice thought, but most distros poop all over FHS anyway.

When was the last time you hopped between distros Ubuntu->OpenSUSE->Fedora and had packages be in the same spot? Because I distro hop a LOT and they almost NEVER are.

Even if it's just /bin, /sbin, /usr/sbin, /usr/local/bin, where is the consistency, not to mention controlling access. Remember when Debian took the sbins out of the path and everybody claimed Debian sucked?

When was the last time you saw /usr mounted as read-only? Because it's supposed to be.

With tech like snaps and flatpaks, containers, NixOS, etc, to call FHS anything more than a suggestion in 2023 is extreme wishful thinking.