Date: Fri, 25 Jan 2002 13:43:06 -0800 (PST) From: "Duane H. Hesser" <dhh@androcles.com> To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: arch@FreeBSD.ORG, Nathan Arun <nathan_arun@hotmail.com> Subject: Re: a suggestion Message-ID: <200201252143.g0PLh6W90454@androcles.com> In-Reply-To: <20020125071750.F72285@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
This thread offers me an opportunity to ask a question of this august group, which question has been on my mind for a year or two, and surfaces every time filesystem structure threads appear in these lists. The question has to do with a UC Berkeley posting to USENET in the late eighties, but I will ask it (more or less in context) toward the end of this reply. Peter, please forgive me if I slice up your replies too mercilessly; I just have a couple of things to add. On 24-Jan-02 Peter Jeremy wrote: > On Thu, Jan 24, 2002 at 12:18:02AM +0000, Nathan Arun wrote: >>Section 3.3 of the handbook outlines the directory structure. How about >>changing the structure to something akin to windows? > > The Unix filesystem layout predates the Windows layout and is more > logical so I'd suggest you write to Microsoft and get them to change > the Windows filesystem layout :-). > I tend to agree that the current basic directory hierarchy layout is logical and fundamentally useful; it is certainly not the result of arbitrary, random decisions. There are likely an infinite number of layouts which might serve as well, but please (Nathan) don't assume that the current design was arrived at by a thousand monkeys pounding on keyboards (it's more like tens of thousands :-). Regardless the number of monkeys, there is a method to the madness. It wasn't clear to me from your original posting how long you (Nathan) have spent attempting to understand the current method (or madness), but I'm willing to bet that it's much less than you've spent with "Windows". I have often thought that folks who talk about the "intuitive" nature of windows simply don't realize the investment of time they have in learning what they know about it. A common problem for new Unix users is the problem of "finding things" in a hierarchy which may contain tens of thousands of files. If this is a factor in your displeasure, I will suggest what I would suggest to all new Unix users...scout out the 'locate' command (/usr/bin/locate) and 'locate.updatedb' (in /usr/libexec) and learn to use them effectively. (At a minimum, they will allow you to find where you *don't* want a file to be :=). [snip] >>So there will be only 4 file systems: /, /sys, /apps, /usr. Don't confuse "filesystems" with the namespace represented by the directory hierarchy. That just muddys the waters. The association of disks/partitions with branches of the directory tree is a separate issue, and one which should be considered carefully (and *designed* carefully) for each and every platform to which an OS is installed. >>I'm suggesting this because it is confusing to have so many bin & sbin >>directories. It need not be. Learn to set up your PATH in your chosen shell, and forget about it. Put as many (or as few) 'bin', 'sbin', or 'etc' directories in your PATH as you need. If you don't want to forget about it, use 'which'. > > The distinction between /bin and /usr/bin (& /sbin and /usr/sbin) is > now fairly arbitrary. Originally, the root filesystem was fairly > small due to physical disk sizes. This was continued after disk sizes > grew because a small (and mostly static) filesystem was less likely to > be damaged by a crash. The root file system (including /bin and > /sbin) included the utilities necessary to validate and recover the > system. On many modern Unices, /bin is a symbolic link to /usr/bin. > If you look back through the archives, you will find that this has > been discussed fairly recently. > > As for the distinction between /bin and /sbin: /sbin (and /usr/sbin) > is for commands that are only needed for system administration. > Normal users shouldn't need to access any of these files. (In a > tightly secured environment you might prevent normal users accessing > them). > What he said. Although I think there's a bit more to it. ... >> This may sound trivial to experienced UNIX users like you, but >>if you want to grow your user base, you should target the OS at more naive >>developers like me. Many developers feel that windows is easy >>and want to try something more challenging, but UNIX is too difficult. > If you want to have, or want your users to have, a more familiar "Windows-like" experience, try KDE. It's huge, and needs extraordinary resources (much like Windows), but the FreeBSD "ports" or "packages" systems will install it for you, and it will allow Windows users to feel at home rather rapidly, I think. The major difference is that they will have far more power at their fingertips. Unix isn't just for us (OLD) command-line users anymore! Of course nothing stops US from having a dozen or so 'xterms' running on six or eight KDE desktops. Nothing would stop *you* either (once you figure out where 'xterm' is :-). Some would suggest Gnome rather than KDE; or you can make disk suppliers happy, and install both. Some, of course, would say I'm crazy to suggest either... > The Window's filesystem structure is definitely not intuitively > obvious. You must have expended significant time and effort in > learning the Windows structure, I fail to see why you expect that you > should be able to migrate to Unix without expending any effort. > Yeah, that's what I meant... .... > > One final point: FreeBSD is mostly a volunteer project. If you want > something done, the best person to do it is yourself. If you > seriously want to re-arrange the filesystem, provide the necessary > patches - a complete list of all the changes that would be necessary > to implement your approach. If you want to get other people on-board, > you will need to provide a more detailed proposal that defines the new > location for every object in the FreeBSD filesystem (and doesn't gloss > over things like /usr/share and /var) and justifies the change (better > than "because Windows does it that way"). > > Peter > That brings me to the QUESTION I threatened at the beginning to ask. Many of you on these lists are aware that, up until at least the "late eighties" most Unix distributions presented a file hierarchy largely based upon the Version 7 filesystem, save for "cultural differences" (e.g a '/usr/ucb' here, or an '/etc/init' there) between the BSD and Sys V camps. Somewhere in that timeframe, just after BSD 4.3, a posting to USENET by UC Berkeley (Mr. McKusick, was that you?) presented a new filesystem layout. The posting included postscript graphics of the filesystem tree, and included consise descriptions of the intended use and rationale for all features of the new layout. In short, they did just what peter said..."provide a more detailed proposal". It was, as I recall, pretty much the layout you see before you on FreeBSD (and the other BSDs), and the layout to which Nathan Arun is objecting. It is also in use (in one bastardized form or another) on many commercial Unix systems. I still have, somewhere in my piles...ummm..*files*, printouts of the graphics, but I have long since lost the accompanying text. So my question is...does anyone out there have a copy of the original posting? If so, I would love to have a copy; it would be interesting to measure current usage against original intent. I have often felt that there has been some "drift", possibly due to the absence of the original design rationales (and other effects). It might be nice to compare it to the Filesystem Hierarchy Standard currently touted at http://www.pathname.com/fhs/, and to the 'hier' (7) man page. It might even be nice to place a copy in /usr/share/doc/history... Mostly, though, I'd just like to do a refresh cycle on my memory, which seems to be coming up with a lot of hard errors these days. -------------- Duane H. Hesser dhh@androcles.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201252143.g0PLh6W90454>