4 ms·

So we're saying that every Unix and Unix-like implementation in recent times that supports and indeed advocates [1] placing /usr, /tmp, /var, and so on on seper

So we're saying that every Unix and Unix-like implementation in recent times that supports and indeed advocates [1] placing /usr, /tmp, /var, and so on on seperate filesystems have done so because the developers are unskilled novices with no understanding or experience of the problem at hand? Sorry, I think it's entirely the wrong term. [1] http://www.openbsd.org/faq/faq4.html#Partitioning http://www.openbsd.org/faq/faq4.html#Partitioning

oofabz 14y ago
Yes, that is what I'm saying. Security: Adding a layer of security on a per-filesystem basis is not sufficient or necessary. It is only conceivably useful as a backup plan when the actual security system has failed, and at that point it is not sufficient to prevent compromise. Stability: Quotas are a superior solution. Speed: Not an issue for /usr, which is rarely written to. Integrity: We have journaled filesystems now. If you lose a filesystem it is almost certainly because the device has gone bad and needs to be replaced. For last-ditch system recovery, an initrd solution like Dracut works better, since it can solve problems involving the root partition. Size: Modern computers can boot from any size partition. fsck: Preventing fsck is no longer useful. It doesn't take an hour like it used to. If there was a power interruption I would prefer to fsck all my filesystems anyway.