[Steltek]

Standards are a double edged sword though. They are great for getting everyone to agree to the "most correct" answer. But they also freeze evolution in place. What happens when your standard doesn't support contemporary use cases? What if it's at direct odds with, say, modern security practices?

FHS hasn't changed in years. Since then, sandboxing, containers, novel package schemes, and more are the zeitgeist. What does the FHS say about them?

[lukeschlather]

Looking at this specific use case, someone is saying /var/lock being world-writable is an unacceptable security risk, but that's very dependent on what your world/users look like. If anything it sounds to me like the maintainer is trying to make the FHS smaller and remove support for a lot of use cases. (Use cases that sound pretty valid to me, without digging in.)

[Hackbraten]

> What does the FHS say about them?

Nothing keeps you from following the FHS inside your container or sandbox.

Are you referring to the location where container images live? Then `/var/lib/containers/` and `/var/lib/containers/storage/` would be perfectly FHS compliant.

[Steltek]

The idea though is when you don't want to follow the FHS anymore, like systemd is doing.

Systemd frustrates and angers people with Poettering's complete disregard for bug reports, tradition, and basic common courtesy. At the same time, change needed to happen and change is gonna hurt. And big changes can't wait until they're just as stable as the old system: does anyone develop software like that in their own careers? I try not to ship complete crap but "just as stable as v1" is never a goal.