On Tue, 20 Mar 2012 01:04:04 +0200, Alan McKinnon wrote: > - */bin vs */sbin is one. Nothing to do with security, but */sbin can > go in root's PATH and apps that only makes sense when run as root (eg > mkfs) go there. This avoids cluttering the display with useful crap > from tab-completion.
Agreed > - / vs /usr/local. I like this one, everything I build and install > myself without help from the package manager goes here. On FreeBSD it > means I used ports to install the stuff and it's not in world. I do > need this distinction in my world. Perl CPAN too for the same reasons. That too, or you can move all system stuff from /usr to / and put user stuff in a directory with an appropriate name, something that reflects its purpose, maybe something like /usr. > - /opt. Um yeah, OK. So we have these things called proprietary apps > where devs just want to make a directory specially for their app and > dump everything belong it. OK, as a scheme, it works. I don't like > it but I don't have a better idea. Yep. > / vs /usr is the only one I don't need myself, as /usr is not read-only > (a very valid use case) and I don't have thin clients on the network. Separating system and user-compiled/installed software makes sense. Separating root and general programs makes sense. Separating system programs and libraries based on fairly arbitrary, and moveable, criteria does not make sense to me. As for making /usr read-only; it is generally only writeable by root and anyone with the root password could remount rw anyway, so there's not much point there. -- Neil Bothwick Ninety-Ninety Rule Of Project Schedules - The first ninety percent of the task takes ninety percent of the time, and the last ten percent takes the other ninety percent of the time.
signature.asc
Description: PGP signature
