On Mon, 19 Mar 2012 13:17:01 +0000 Neil Bothwick <n...@digimed.co.uk> wrote:
> On Sat, 17 Mar 2012 09:00:37 +0100, Andrea Conti wrote: > > > Personally I stopped bothering with a separate /usr ages ago, so I > > don't really care. > > Having given this some thought recently, I am coming round to the view > that the problem is /usr itself. It may have had a place when boot > disks were limited in size, but I really don't see the point it in at > all nowadays. This whole question of which bin directory does code > belong in should be "why do we need so many bin directories"? > > There are some separations that do make sense in a Unix context: - */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. - / 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. - /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. / 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. -- Alan McKinnnon alan.mckin...@gmail.com
