This email is clearly wrong. Anyone, who knows anything about Unix knows that the world didn't start till 1970, so all this stuff about things happening in 1969 is clearly impossible.
Understanding the bin, sbin, usr/bin , usr/sbin split
111–120 of 158 posts
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#112Wow. As someone who was there (I know dating my self here) reading this is kind of like that scene in Sleeper where the person from the future is trying to understand artifacts from the past. So during the BSD / System V merge (project Lulu at Sun) the /opt filesystem was introduced as a way to keep 'packages' separate from 'system'. The difference between /bin and /sbin was that sbin was 'static-bin' which is to say…
I also have no memory of /home even existing in roughly the first decade of Unix's existence.
Actually /home was the first automounter map. Brent Callahagn at Sun had built this thing that, in conjunction with NIS (YP) or NIS+, could locate which server your home directory was on, and automatically mount it, decided that the automount point should be '/home' this was distinct from /usr/xx since /usr/xx was xx's home directory on this machine whereas /home/xx was xx's network home directory that would follow them around.
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#113Earlier quoted context omitted.
Perhaps you have some misbehaving software, but I've never seen /usr/share/bin, or /usr/local/share/bin or a lib directory in either of those locations. I just checked FreeBSD boxes (which, admittedly, follow their own standards closely), and a Redhat box. var is a directory which may be found under /usr or /usr/local, but won't contain a local directory. Think of it as 3 roots: / is required for boot, /usr is stuff…
/usr is maintained by the OS, and contains stuff that isn't required for boot but to round out the system. /usr/local is where local modifications to the OS go, these can be site-wide (company wide) and can be hosted on NFS for example for network boots. User installed stuff belongs in /usr/home/ /*. Users shouldn't have root access to install stuff in /usr/local.
Side point: it really bothers me that on freebsd the ports system takes over /usr/local. I expect /usr/local to consist of things that I as admin have installed by hand, and nothing else.
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#114Earlier quoted context omitted.
Wouldn't that interfere with the core BSD system vs p ackage binaries/libs paradigm?
Packages/binaries/ports tree installs into /usr/local/. See man hier [1]. For example, on a FreeBSD install, it is perfectly safe to rm -rf /usr/local/. Your system will still boot without issues. [1] http://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&...
Which I find is actually quite problematic; "make install" by default puts things into /usr/local, and I would prefer to distinguish between things I've installed and things ports have installed. (Specifically, I need to build my own mplayer, but I also need the ports version installed as some other ports depend on it).
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#115As someone who comes from a Windows (and further-back, OS/2) background, the directory structure of -nix systems is baffling. It's really interesting to read the background on why it came to be structured a certain way, but I feel that the current structure doesn't jive with how we use computers in a modern way. The structure seems to be optimized for single-file command-line based applications and are not well suite…
"and a GUI is used to provide easy access to the application" How do you think the GUI finds the application? There is a PATH. Open up a cmd and type the name of any installed program.
1) Programs put themselves in various directories on my windows 7 machine, some are under \Program Files, some are under \Program filees (x86), some are \Programs and so on, variations and variations.
2) to locate a program you need to know its corporation, which people often dont know. There are setup.exe start.exe fireup.exe and run.exe and variations, which one should the user use to start the program?
3) all the applications components are not in a single place but are spread out over \Program-Files, \Windows\system, \windows\xx\xx and the registry at the least. Then they put stuff in \users\application data\ and \users\xx\applications or whatever.
You and many people dont understand where anything goes because unlike for Windows, GNU/Linux systems actually make sense and actually have a structure (that is different from windows) which you need to learn to operate the system, just as you learned to navigate the mess of windows.
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#116I've been liking the new location /srv, where you stick things that are custom to that machine. No more trying to guess where the previous admin thought files should go (/usr/share? /usr/local? /usr/foo?). http://www.linuxtopia.org/online_books/linux_beginner_books/...
You dont stick things that are custom to that machine in /srv, thats not what the article you linked to says.
Its for serving using various services, so you would have /srv/http /srv/ftp and so on, you dont put packages/programs into /srv
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#117Earlier quoted context omitted.
home directories iirc, lived in /u (/usr these days)
Depended completely on the site. The first UNIX machine I worked on (ca 1985-1986) still was putting them in /usr for instance. There were certainly sites that used /u for what is now commonly /home (or /export/home on Solaris, /Users on OS/X, ...) This was not something that predated "/usr" though: /usr was already added back in the early 1970s (the linked article was correct about that, although it got many other d…
Until its last breath, IRIX kept home directories under /usr.
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#118Everyone's talking about initramfs as if it would replace a self-contained /. Have you ever been there? Usually all the relevant repair tools are missing and the shell gives you a headache. Its the point where you usually give up, walk into office and boot a rescue disc.
So no, it does not replace a working /.
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#119Earlier quoted context omitted.
Because everyone's idea of what "makes sense" is different. Thus: /bin /usr/bin /usr/share/bin /usr/share/local/bin /usr/local/bin /usr/local/share/bin /opt/bin /opt/some/clever/path/system/bin Followed by hacky symlinks so that programs can find what they're looking for in /usr/local/share/lib/x, which really resides in /usr/share/lib/x or maybe /var/lib or maybe /var/local/lib or maybe just /lib because it's consid…
This is a little bit disingenuous. I can certainly see the point that all of this separation is unnecessary on a typical modern desktop system, but several of the paths you listed in support of your argument are not actually specified by the FHS, nor do they even make sense. Of the paths you mentioned, there is no such thing as: /usr/share/bin /usr/share/local/bin /usr/local/share/bin /usr/local/share/lib /usr/share/…
I put Java in /opt/java/, and embedded toolchains in /opt/[platform]/. Not exactly Windows ports, but they're the sort of thing that can get out of hand easily. :)
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#120As someone who comes from a Windows (and further-back, OS/2) background, the directory structure of -nix systems is baffling. It's really interesting to read the background on why it came to be structured a certain way, but I feel that the current structure doesn't jive with how we use computers in a modern way. The structure seems to be optimized for single-file command-line based applications and are not well suite…
While the system is, indeed, complicated, there is a reason changing it has not been Ubunutu's highest priority: almost all installation is done via the package manager. I haven't used Ubunut much, but at least on Fedora 95% of what I use is in the repositories and the rest is available as an rpm file which installs itself. I have never had to worry about where to put executable files. Of course, I have installed thi…
As a user, this may well be tolerable. As soon as you start developing for Ubuntu (or any other OS), these kinds of things will make you suffer.