Those are "the systemd requirements for the filesystem", what systemd needs. It provides no clarity about what goes _in_ those directories, nor why,
Yes, those are the basics for systemd to work. Again, rather simple requirements. It doesn't state what goes into what, because this is something the distros dictate, not systemd. The systemd developers can merely suggest where to put things, but distros won't necessarily follow those suggestions.
systemd is designed with different distro policies in mind, so they provide "Presets" to help facilitate the different policies and needs of different distros:
Compare this checklist with the actual FHS documents, and you'll see the distinction. The result is confusion, such as the systemd migration of "/media" attachable storage to the individual user's owned subdiroectories in "/run".
The FHS is primarily concerned about directory layout, not so much the content of these. And there is nothing in FHS 3.0 that contradict the slightest that user attached storage is mounted in the /run hierarchy.
All such disc layout reorgs of the distro I have tried, have been discussed on mailing lists etc. before they are implemented. Again, this is something the distros dictate, not systemd.
Allow me to restate your comment:
> Systemd will continue to work for Linux distros that don't care for stateless boot etc
Rather, systemd will continue to re-arrange, and break, stable subsystems without warning to the user communities.
Come on. It is the distros that dictates exactly what features systemd have turned on, and how the FH layout is. There are no systemd developers sneaking into the distro repos at night and secretly turning on features without documenting them.
You may not follow the eg. development mailing list of your distro where such things are discussed, nor care about reading release notes. But Linux distros have always evolved this way, with new ways of doing things, often from release to release.
OTher examples abound. For example, the new replacement for /etc/resolv.conf says at http://www.tin.org/bin/man.cgi...
Note that /run/systemd/resolve/resolv.conf should not be used directly but only through a symlink from /etc/resolv.conf.
I fail to see how this in any way breaks any stable subsystem.
1. systemd-resolved is an entirely optional feature. If the distros don't want it, they can just turn it off.
2. Whatever its /etc /run requirements is, this is a new feature, not a change of something old and stable. So it doesn't break anything at all.
I really don't think you can give just a single non-contrieved example of how systemd are breaking stable subsystems for users without warning.
While more documentation is always better, I think the systemd project is way better documented than most other software projects, and certainly much better documented than many people think it is.
I'm not even going to mention what happens if you accidentally follow generations of sytem standard behavior and install NTP alongside an active systemd NTP daemon. It's not a pretty site, and the accumulated clock management confusion if they're not pointed to the same NTP servers can break Kerberos authentication in startlingly short order.
Running two NTP-clients at the same time was an amazingly stupid thing to do even pre-systemd. AFAIK, systemd per default tries to avoid this by using "conflict" statements in the service files, so if one NTP client or daemon is run, the others are suppressed.
I don't think eg. SysVinit or Upstart ever had such measurements against accidentally running two NTP daemons at once.
The bottom line; yes, systemd developers are working towards stateless boot and other similar optional features. Yes, this will require some reorgs of how especially config-files are kept. There are good technical reasons for this (crypto verification, factory reset etc), and the layout changes seem to benefit all user cases, including those that won't be using the new features. Even those who doesn't use systemd would probably benefit from a layout with a clear separation between user, system and distro default config files.
The basic requirements for these new features are sketched out here:
But remember, this is very much a work in progress for the future, when things are are starting to actually work somewhat, I am sure that a more "official" documentation will appear that spells out all the details.
And the there is no dictate to make these features work for either distros nor upstream projects. This work will only be done if people think it is beneficial to their distro/project. systemd will work without being able to perform a factory reset or a crypto verified /usr.