Hi Marko, this thread comes across as needlessly confrontational.
Everybody can indeed re-configure OpenBSD or change parts of it however they like (because it is free software with respect to license permissions), even in ways that would be a very bad idea for most other people - like /var on MFS for the reasons Claudio explained, but you are welcome if it works for your use case. The more unusual the changes, the higher the probability that they have downsides, or that downsides appear at a later point, so users doing configuration changes should be prepared to fix those downsides on their systems - which they can because it is free software in the sense of open source. While we do sometimes include CAVEATS against *very* widespread, very dangerous programming or configuration errors in manual pages, we almost never document "don't do this unusual thing" because there are infinitely many things that people might do that cause problems. Instead, we document how the system works: both how it works by default, and what the various options do. It should not be a surpise that there are combinations of options that don't work well together out of the box - in this case using syspatch(8) (using it is optional!) together with /var on MFS. Neither should it come as a surprise that such incompatibilities evolve over time. Both syspatch(8) and hier(8) document that syspatch(8) stores information in /var/syspatch/, and it should be easy to deduct from the context that not being able to store that information persistently seriously obstructs the operation of syspatch(8). While OpenBSD is a general-purpose operating system, it doesn't come with warranty stickers in the first place but it is also a research project: we are always striving to make OpenBSD better in innovative ways, so change is inevitable and indeed desired. For example, much less than a decade ago, the syspatch(8) program that now clashed with your unusual configuration didn't even exist. Besides, many improvements to security require deprecating possibilities that are used rarely and entail risks - even if some people rely on them. It happens all the time, in all parts of the system. That said, specific suggestions to keep the manual pages up to date are always welcome, but please strive to suggest specific wording improvements better but still concisely explaining how things work, *not* in the style of "don't do this unusual thing". By the very definition of "unusual", people doing such things must figure out themselves which downsides those specific changes might have, using the positive information from the manuals. Yours, Ingo
