Date: Fri, 25 Jan 2002 07:17:51 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Nathan Arun <nathan_arun@hotmail.com> Cc: arch@FreeBSD.ORG Subject: Re: a suggestion Message-ID: <20020125071750.F72285@gsmx07.alcatel.com.au> In-Reply-To: <F88HOzyfyz5b6KZmcK80000ce69@hotmail.com>; from nathan_arun@hotmail.com on Thu, Jan 24, 2002 at 12:18:02AM %2B0000 References: <F88HOzyfyz5b6KZmcK80000ce69@hotmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 :-). >/sys --> all system binaries, scripts that now reside in /bin, > /sbin, /usr/bin,/usr/sbin, /boot, /etc, including > KERNEL, gcc, ... will reside here. I presume this means that /bin/sh will become /sys/sh etc. > In addition /sys will have the following sub-directories: ... > /sys/mnt --> mount point (if necessary) What is this for? > /sys/conf --> conf file location for binaries in /sys > /sys/dev --> all device nodes > /sys/log --> log file location for binaries in /sys > /sys/src --> source code for the binaries in /sys > /sys/include, /sys/lib --> C/C++ sdk > /sys/man --> man pages for binaries in /sys This last entry provides a clear demonstration of the disadvantages of this approach: 1) /usr/bin/man is a command to display a man page. My understanding of your first point is that it would be renamed to /sys/man. This immediately precludes the use of /sys/man as a directory. 2) Man pages document far for than the binaries. They document the kernel and library interfaces as well as the configuration file formats etc. Where do all these other man pages go? Question for you: Where would you put things like the compiler back ends (currently in /usr/libexec), various datafiles needed by things like lint and perl (currently in /usr/libdata) and general files (/usr/share). >/apps --> all applications. for e.g. /apps can have ... Apart from your approach to the executable locations, this approach is used by some Un*x variants (though the directory is either /opt or /usr/opt). There are occasional discussions in FreeBSD lists about using this approach for ports. >/usr --> all user directories. for e.g. /usr can have > /usr/root > /usr/root/.cshrc Root's home directory needs to be in the root filesystem so that it is available in single-user mode when no other filesystems are mounted. For other user directories, it's fairly arbitrary whether they live in /usr, /user, /usr/users, /home or /lusers. >Other miscellaneous files that are currently under /usr/local, /usr/share, >/var can be moved under one of the above. This is where your proposal starts to lose steam. Most of these files don't fit into any of the categories or sub-directories mentioned above. Also, /var's sole reason for existence is to allow /usr to become read-only (the root filesystem was already virtually read- only). Mixing the files in /var back into other filesystems is a definite regression. >So there will be only 4 file systems: /, /sys, /apps, /usr. What about /tmp? If all the system executables have been moved into /sys, how does the system get from single-user mode (with only the root filesystem available) to multi-user mode (with all filesystems available). >What I have suggested is an exact copy of Windows' "Winnt", "Program Files" >and "Documents and Settings" directories. "Winnt" and "Program Files" are logically equivalent to /sys and /apps above, but I don't see any relationship between "Documents and Settings" and /usr. > But what's wrong in being easy and clear? Nothing. We currently have a logical filesystem layout. I think it's clearer and more logical than Windows. I've always thought that the idea of having random subdirectories within the directories forming the searchpath is very illogical. One of the things I dislike about Windows is the arbitrary and random structure - with subdirectories where I'd expect to find executables. >I'm suggesting this because it is confusing to have so many bin & sbin >directories. 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). > 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. 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. Keep in mind that what you're suggesting would require all Un*x sysadmins to re-learn the filesystem layout before they could use FreeBSD. This would significantly reduce the appeal of FreeBSD within the Un*x community. 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 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?20020125071750.F72285>