SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
When the operating system grew too big to fit on the first RK05 disk pack (their root filesystem) they let it leak into the second one, which is where all the user home directories lived (which is why the mount was called /usr). They replicated all the OS directories under there (/bin, /sbin, /lib, /tmp...) and wrote files to those new directories because their original disk was out of space. When they got a third disk, they mounted it on /home and relocated all the user directories to there so the OS could consume all the space on both disks and grow to THREE WHOLE MEGABYTES (ooooh!).
In particular, in our own version of the system, there is a directory "/usr" which contains all user's directories, and which is stored on a relatively large, but slow moving head disk, while the othe files are on the fast but small fixed-head disk.
I also asked Pat about this once, here is a snipit of what he had to say:
Originally Posted by jeremy
LQ) What do you think about Fedora and Solaris 'simplifying' the filesystem by doing stuff like merging /usr/bin and /bin? Something you would ever consider? (ruario)
volkerdi) Sure, I could see doing that, but we'll see how it goes elsewhere and to what extent things start to expect it to be that way. On Slackware (and other systems) a lot of the binaries that would otherwise install to /usr/bin have to be moved to /bin because they are needed before /usr is available, if /usr is on a separate partition. Likewise, libraries have also had to move. This has led to a lot of symlinks pointing from /usr/bin to /bin, or from /usr/sbin to /sbin, and elsewhere around the system. Now, I'm not sure that I consider this to be a bad enough situation that it's worth the pain of changing it, but it's certainly under consideration. Really, the most painful requirement about /usr was the rule that it had to be possible to mount it as a network volume. That might have been a good idea at the time when hard drives were expensive and small, but it probably isn't done a whole lot today.
Many thanks for your contributions on this topic. Very enlightening quotes. I also appreciate the links to the sources. I've studied some on the history of unix, but usually from the viewpoint of the developement of the c language in relation to unix evolution. It's always a good day to learn something unexpected
Of course, here we have an embedded developer having to deal with Unix heritage, because he wants to use Linux (an Unix clone) as a kernel . But in a custom-built embedded installation you don't really need anything else than a /busybox.
Unlike BSD, Linux userland never had a well-designed /usr separation that made sense, so Rob is right in this respect. The classic question of intelligent design vs. evolution. As far as I understood, BSD separated single-user and multi-user into / and /usr and I know of no plans to change that. BSD's mechanism for in-place upgrades of the operating system depends on it. Also / played the role of /boot for a long time (kernel was just called /bsd and the bootloader could only read /) and /usr/local gets all the third party packages, a distinction Linux never made.
So yes, Linux' filesystem hierarchy is a chaotic mess, a result of chaotic evolution. But trying to design stuff retroactively only harms the ecosystem by breaking compatibility. I think we should keep software compatible, there are people out there, who depend on it. Just accept it and embrace it.
I don't see any real issues with the current tree based system personally. While having things like /programs, /system, etc. all seem more balanced and segregated, this stretches out another old question, "Why does GNU/Linux have to be like DOS/Windows?"
I think the tree based structure of /(root), /usr, /usr/local, /home, and other system partitions allow for easier resource structuring, network accessibility, and system control. It's far superior to anything Windows has in terms of modularity.
Distribution: Slackware 14 is Main OpSys on Main PC, 2ndary are OpenSuSe 13 and SolydK
Originally Posted by moisespedro
You only know "mnt" stands for "mount" once you learnt it. Just think about "/usr", for example, it is often misunderstood as "user" but it actually stands for "Unix System Resource". And, Gobo's way (lets call it this way) does not break anything. I am not saying I like it, I am just saying that it doesn't break compatibility.
The reason I mentioned Brazilian methods was that it really doesn't matter if anyone realizes "mnt" means "mount". In short order they know it's where non-root file systems go. Similarly, while I speak "/usr" phonetically as if it were "user", I really don't care what it was originally meant to be... only how it functions. In just a day or two of reading about and using Linux, I knew the basics of what is stored there. Same with "/var" etc.... I mean "/etc" etc :P
I find the current organisation a bit of a mess. Why is /usr/lib full of stuff that doesn't end with .so or .a? Why is /var/lib called 'lib' at all when it contains rw application data? Why in gods name did they deprecate /usr/libexec when there's clearly a role for it.
IMO the guy who decided "Hey, we don't need libexec, lets just dump everything in directories under /usr/lib" should be taken out back and shot! (ok, maybe that's a little harsh... given a good beating will suffice ).
The problem with Gobo is that they tried to be too radical. Would have been much easier to sell a scheme along the lines of:
/usr/data/... (instead of /usr/share, /usr/games, /usr/info and the like)
/var/data/... (rather than /var/lib etc...)
The continued use of traditional /usr/... and /var/.. and /opt/... prefixes would have made it seem more like a refinement/evolution of the existing scheme.
BTW, I'm all for the /bin /usr/bin merger. I don't think the split makes sense in the modern world.