Google+ post
Tomasz Torcz
Originally shared by Lennart PoetteringThe other day I sat down and wrote a new man page to ship with +systemd that describes the assumptions and requirements systemd makes about the file hierarchy of the OS. It's a bit like a less-crufty, modernized version of the FHS or hier(5).
Note that while this document codifies a lot of how we think a Linux operating system should be laid out, this doesn't mean that systemd was incompatible with operating systems that don't follow this document. It simply means that some of the features might not work as expected or to their full extent. For example, on distributions which have not completed the /usr-merge the effect of ProtectSystem= (which makes the vendor supplied OS resources in /usr read-only for a service) will not be complete: the files in the root directory will not be covered. Similar, without the /usr-merge you don't get all the stateless logic working, since there's no way how the system could boot up with only /usr around.
Anyway, please have a look!
Note that while this document codifies a lot of how we think a Linux operating system should be laid out, this doesn't mean that systemd was incompatible with operating systems that don't follow this document. It simply means that some of the features might not work as expected or to their full extent. For example, on distributions which have not completed the /usr-merge the effect of ProtectSystem= (which makes the vendor supplied OS resources in /usr read-only for a service) will not be complete: the files in the root directory will not be covered. Similar, without the /usr-merge you don't get all the stateless logic working, since there's no way how the system could boot up with only /usr around.
Anyway, please have a look!
file-hierarchy
Shared with: Public
+1'd by: Lennart Poettering
Comments
Comments powered by Disqus