Can we also address .bash_rc, .bash_profile, .profile, /etc/bash.bashrc, disambiguation. I get tired of instructions advising me to put PATH and other modifiers in .bash_profile when that only works for a login shell. Doesn't work, as needed, if you are actually using Linux as your desktop system.
I personally like the differentiation between /sbin (71 files) and /usr/sbin (195 files) on OpenBSD and /bin (42 files) and /usr/bin (336 files).<p>I don't know if it's still the case, but at one point, everything required to boot up a system, and get to a ksh prompt, was in /sbin and /bin, and the only purpose for commands in /usr was for user interaction.<p>When mentally modelling the purpose of the commands, it was nice to have that differentiation, particular the "Stuff in /usr is really for the user only, not needed to boot a system."<p>Of course, I have no idea whether that still holds true - but it's still a good starting point.
>I’m still waiting for /opt/local to show up...<p>Well, he doesn't have to wait anymore:<p><a href="https://trac.macports.org/wiki/FAQ#defaultprefix" rel="nofollow">https://trac.macports.org/wiki/FAQ#defaultprefix</a><p>>Why is /opt/local the default install location for MacPorts?
There are/were small Linux distro that fit on a 3.5" floppy diskette. I remember one that required just a single floppy disk to boot and a later version came with a second floppy with additional applications. So the bin /usr/bin split was still useful in the early Linux era (I used such a floppy Linux til 2002 for misc purposes). A starting point: <a href="http://superuser.com/questions/130457/what-linux-fits-on-a-floppy-disk" rel="nofollow">http://superuser.com/questions/130457/what-linux-fits-on-a-f...</a>
The reasons for the complexity are lame, but sometimes there are nice consequences. For instance, on FreeBSD you can pretty much just nuke <i>/usr/local/</i> and be left with a functional base-system (broken configs notwithstanding).
Interesting rant. Actually in 1990 people were complaining that SunOS took up too much disk space (well they always complained but whatever). And C (and unix) always had something of a naming / packaging problem.<p>Of course long after the size of disks were "big enough" to hold everything in / putting things on different drives gave you more disk I/O's to play with and improved overall system performance. If you could get small drives today you could play with that yourself but it seems silly to have a 500GB disk mounted on /var/log :-).<p>But more importantly for me over the years was putting the "OS" required user land stuff in one place and the "rest" of it in another place meant I could replace the kernel and userland code independently of restoring home directories and what not. These days I do that by mounting "my" stuff via NFS and making my servers basically completely replaceable with a re-imaging.
The original version:<p><a href="http://lists.busybox.net/pipermail/busybox/2010-December/074114.html" rel="nofollow">http://lists.busybox.net/pipermail/busybox/2010-December/074...</a><p>I make everyone I hire and/or work with read it.
It gets the /sbin part wrong.<p>/sbin and /usr/sbin/ did not exist in the 1970s at all, let alone in the early 1970s.<p>I'm not sure exactly which system it first appeared in, but on BSD, which originally was add-ons to the Bell Labs distribution, it was not present in the 1986 4.3 BSD but did appear in the 1993 4.4 BSD.<p>You can verify that, and search for it on other early Unixes, here, for instance:<p><a href="http://minnie.tuhs.org/cgi-bin/utree.pl" rel="nofollow">http://minnie.tuhs.org/cgi-bin/utree.pl</a>