Improving the reliability of file system monitoring tools (Collabora blog)

> But then, if you're a desktop user, that's sysadmin details you don't want to worry about ...

If you're using Linux at home (I guess a lot are) then you're automatically a sysadmin as well. Despite maybe not wanting that role. I'd prefer that I don't need to worry too much and that the distribution takes care of most things. Obviously that doesn't work that easily in practice due to a distribution needing to handle different types of users.

> Well, I suspect the correct answer to that is that root is meant to be read-only under normal circumstances, and /var should be another volume.
> But then, if you're a desktop user, that's sysadmin details you don't want to worry about ...

In many scenarios, the user and the sysadmin are the same person, and installing new software is considered "normal circumstances".

Wol, how much of root should be r/o? Just the top level? I think there are bigger fish to fry. For starters, having root go r/o is an early sign of damage on a fs - I've abused enough VMs to be familiar with this. Then you'll need a lot more mounts for all the other bits and pieces, including /root which really ought to be available no matter what (for root) so that there is a local place to store stuff in extremis.

I've never seen a distro do a r/o / either. It's just too much of a fiddle. Start down that path and you'll be doing things like maintaining a set of hard links with immutable flags set on them to stop the baddies instead of tripwire type solutions and other mad ideas. You can always play with SE Linux and co instead to get the desired effect too.

That's for desk/lap tops. Your servers/containers/etc are a different kettle of bits.