It's the only thing in there
Doing something specifically because no one else does violates plenty of general principles of system design. And it's annoying as fook.
--
Drew |
|
In all current Linux I know of right now...
man hierThat will give you the run down of everything. Including /opt and the reasoning for it. From that: /opt This directory should contain add-on packages that contain static files. |
|
/opt was BS prop sheeite from the get go
brought in by sun to differentiate
/var bullshit /opt bullshit a real OS had /bin for binaries /etc for config files /dev for drivers and devoces /tmp for swap /usr for anything a user might need or want that wasnt supplied by the OS vendor marketing crapaud all of it If we torture the data long enough, it will confess. (Ronald Coase, Nobel Prize for Economic Sciences, 1991)
|
|
BS...
/usr used to be for the *user's* home directories and was actually /u/<username>
When everyone started to use things (programs, scripts and such) out of everyone else's homedir... things changed and it became what it is today (a huge mess). I was working on a very old HP 900 series machine... (the initial series they bought Apollo for). All the home dirs for the machine were /u/(8char username) The damned thing booted off tape every time. The disks were not bootable. Though it had a CDROM it was 1X "HP-IB" SCSI and would only read it as a tape device only. /u became popular again as a replacement for /usr, because many admins and companies wanted to make /usr static/read-only. /home now supersedes /u for the user's homedirs, for obvious reasons. |
|
wrong /u/ was homedir /usr appdir
If we torture the data long enough, it will confess. (Ronald Coase, Nobel Prize for Economic Sciences, 1991)
|
|
sorry box
/usr/bin had a SHITLOAD of stuff that came with my default install.
/bin had the limited amount of stuff needed when booted single user for maintainance, but certainly not 90% of the system supplied text processing apps, or the compilers, or the nroff/troff stuff, or the (you get the point) (I hope). My stuff was late 70s early 80s gear. I was paying close attention to the Sys V/BSD differences since I had to port my code between them, and the bastardized Xenix systems. |
|
why sorry you are agreeing with me :-)
/bin had the limited amount of stuff needed when booted single user for maintainance, but certainly not 90% of the system supplied text processing apps, or the compilers, or the nroff/troff stuff, or the (you get the point) (I hope)./bin to run the system /usr (bin lib downstream) for applications users used If we torture the data long enough, it will confess. (Ronald Coase, Nobel Prize for Economic Sciences, 1991)
|
|
Definition problem
I listed tools, not applications.
But I see what you mean. Once the system is booted, your job is done. |
|
say: /usr
Go on... say it.
What does that sound like? /u was used for a "short" user. Then as slightly more memory became available, it was expanded to /usr. Initially /usr/<username>/program was being used heavily by many people and then as the idea of $PATH came into being... a blessed path was written in. This is where /usr/bin came from. to distinguish from /usr/<username>. Then a lot of people started griping that some systems things to boot where being written and put in /usr/bin. Eventually /bin and /sbin became the places for system starting programs and other initialization programs need to boot the machine were. So early crap was /u for homedirs. /u being cryptic, became less so with a pronounceable version "/usr" or user. Then when these things became where admins (out of being lazy and not want to compile/link everything on install) wanted to make /usr *read-only* and exportable and mounted from a central machine. /u became the user directory again and eventually /home. Sorry, you mind is playing tricks on you again. I've referenced some mimeo-graphed training manuals I have from 1984 that were given to me with that OLD 900 series machine. they intermixed /u and /usr because at that point /u was considered legacy. |
|
fair enough
maybe my memory isnt what it used to be. I have the first edition ATT unix prog manual written by Kernihan and Ritchie. I will take a look when I get home to see If there is any references one way or the other.
If we torture the data long enough, it will confess. (Ronald Coase, Nobel Prize for Economic Sciences, 1991)
|
|
For most users, that will be so, yes.
Why do you find /opt annoying? I actually think it's rather quaint, though it is one more thing to remember. But I much prefer Adobe to have corralled themselves in /opt rather than littering /usr/local (and by extension /var/local). The problem with /usr/local is that it mirrors the structure of /usr and separation by package or product is poor. /opt doesn't have that problem.
Chrome puts itself in /opt, too, though they add a symlink in /usr/bin. Interesting pages about using /opt: http://tldp.org/LDP/...chy/html/opt.html http://www.linuxjour...t-opt-vs-usrlocal http://serverfault.c...ons-in-var-or-opt Wade. Q:Is it proper to eat cheeseburgers with your fingers? A:No, the fingers should be eaten separately. |
|
You answered your own question: "one more thing to remember"
--
Drew |