> Those essentially solved the problems of environments, configuration, as well as backups for me. Most *nix distros have humiliatingly failed at having a single directory for everything an application needs to run, which horribly complicates figuring out where your data actually lives and how you could re-create everything from 0 in case of a failure or migration.

The Filesystem Hierarchy Standard actively militates against a single-directory setup. Instead it is designed so you can keep your static stuff on one read-only location, your interim application runtime stuff on another (/var), your user data on a third (/home)...

It's a high-end standard appropriate for serious computers where these directories can be on different disks, with different filesystems, security protections, performance implications, and backup strategies (no need to back up what you can simply reinstall!). As a small-time user it's only your choice because it's the standard choice.

I guess you can have /opt/xyz?

> As a small-time user it's only your choice because it's the standard choice.

Thanks to Docker i can mostly reject its conventions (for actually organizing my application data).

Instead, i might have something like the following file paths and container bind mounts:

  PATH ON FS --> PATH IN CONTAINER
  /docker/app_foo/data/container_x/var/www/html --> /var/www/html
  /docker/app_foo/data/container_y/var/lib/postgresql/data --> /var/lib/postgresql/data
  /docker/app_bar/data/container_w/app/data --> /app/data
  /docker/app_bar/data/container_z/var/lib/mysql --> /var/lib/mysql
  *the docker/app_X directories can contain deployment descriptors, instructions or other notes if need be

The containers can use FHS internally and not know about where or how things will actually be stored outside of the container (bind mount vs volume, local vs networked). Thankfully, usually there are 1 or 2 directories per container that i actually care about and want to persist, the rest is disposable (e.g. data vs runtime files and libs).

The hosts can have a non-standard folder at FS root under which all of the persistent data will live, thus backups become easy, and due to organizing stacks/apps in a tree structure, everything that's needed by a particular environment is also immediately obvious.

Furthermore, this doesn't get in the way of the actual OS operating, nor does the OS get in the way of my deployments - if anything ever goes wrong, i can just wipe and reinstall, setup with Ansible and carry over the /docker directory as necessary. Of course, depending on how everything is mounted, it might as well be just reconnecting another drive or a few drives and setting up fstab.

I think that treating your entire system as one large entity is a horrible idea - instead you should have a clear distinction between what's a part of "infrastructure software" and what's your "business software", those two should be kept as separate as possible. The former should be easy to wipe and update and even swap out altogether (within reason), the latter should be treated as critical and backed up thoroughly and often.

Edit: my point is that most existing software is really bad at this distinction and there are far too many opinions and as a consequence your Tomcat install is strewn across a dozen folders, same with many other pieces of software. So why should you live in fear of forgetting some important configuration file or some data directory?

Of course, YMMV, but things like Ansible and Docker (or Podman, or containerd) with the "infrastructure as code" and "cattle instead of pets" approaches is pretty serviceable.