“The first thing that most new users shifting from Windows will find confusing is navigating the Linux filesystem. The Linux filesystem does things a lot more differently than the Windows filesystem. This article explains the differences and takes you through the
layout of the Linux filesystem.” This is a pretty old article, but it’s still a good read, especially for newbies.
The Linux Filesystem Explained
About The Author
Adam Scheinberg
Technology Executive • Web Developer • Father • Foodie • Music Snob • OS enthusiast
Follow me on Mastodon @[email protected]
If every distro followed common sense guidelines, or established a STaNDaRD, then this article would bear some relevancy; however, your Linux distros vary considerably in where they put their user-installed crap, system crap, binaries here there and everywhere. As a gratuitous example, /boot stores different things for different distros, from just the kernel to kernel+KDE+other junk too, from my last SuSE experience. This makes general guides to partitioning distro-specific, and plenty annoying. Anybody ever use SuSE? Red Hat? Mandrake? Hell, Mandrake’s built on Red Hat and they even have different .rc file locations from Red Hat’s “standard.”
Good luck deriving practical information from this article.
I know this is nitpicking, but this article would probably be better titled “The Linux Filesystem Layout Explained” as I (like the moderated down fellow) was expecting a technical article on Linux filesystems, or at least an article on the Linux VFS…
The teaser text of our newsbit says just that: filesystem layout. If people would bother to read the teaser, they would understand what it is all about. We don’t usually alter the headlines of the articles we link to.
The Linux filesystem does things a lot more differently than the Windows filesystem.
That doesn’t make sense atall. Plus this is about the layout not the filesystem.
becasue you can type a file path quickly in linux.
/usr does not mean user, I believe it’s Unix System Resources. This would explain why so many things are located in /usr and why there is still a /home. Allot of other stuff is also located in /usr/bin and /usr/sbin. I personally believe it’s a mess when looked at from a desktop perspective. And I don’t care if /bin takes less time to type than /apps, use tab. I hate chasing down installed program files all over the disk. I hate the way many simmilar apps are in seperate directories. It would be simpler to install stuff to /apps/opera and place a link to the stuff that needs to be in PATH in /apps/bin.
ps. Short directories or not, it’s still a pain to cd to and install /home/jim/temp/avifile-0.53.5-1mdk.i586.tar.gz
The contents of /bin are not necessarily best described as “applications”. Consider a typical directory for a large application that includes source (/src), headers (/include), binaries (/bin), and libraries (/lib). The /bin directory does not contain the entire application; it only contains the binaries.
Getting rid of /bin is a bad idea, but it would be just fine to have /Applications/SomeProgram/bin, like OS X and BeOS applications often are.
SuSE puts KDE where??!!! That doesn’t even make any sense. You’re boot partition isn’t supposed to by any bigger than a few tens of megabytes. I highly doubt that is accurate. To tell the truth, the different Linux distributions aren’t all that different. The only major differences you’ll find is in the layout of the startup scripts, and the location of KDE/GNOME. It’s rather unusual to see deviations other than that.
@Sajiimori: Why are you digging through the bin directories? You have to understand you UNIX does things. The user is never supposed to leave /home. Pretty much everything you could ever want is in that directory. It’s up to the admin to maintain the other stuff. Now, I belive this is a very powerful feature in the ease-of-use department. The filesystem layout should be abstracted as much as possible, and interaction limited to a documents directory like /home. Now the main issue is that on home desktops, the user *is* the admin. Thus the problem isn’t that programs are in /usr/bin and /bin and all that, but that the user ever needs to interact with the programs directories. Going forward, that’s the feature (never needing to touch anything outside /home and maybe /usr/share) that’s going to have big payoffs in the ease-of-use department. Now many Linux systems are mostly there already. In Gentoo, the package manager handles programs for me. I issue simple commands to install/uninstall programs, and I really don’t care where the system puts it. Long as I get a link in my KMenu I’m happy. With APT4RPM (which RedHat really should install by default…) the same is true for “easy to use” distros like RedHat as well. In fact, the biggest headache for me has not been finding things in /usr/bin and whatnot, but finding icons, which are scattered between /usr/share/icons, /usr/share/pixmaps, /usr/kde/3.1/share/icons, etc.
PS> I find this whole “directory layout” arguement silly. Has anybody ever *looked* in c:windows? It’s an absolute mess in there!
Closest to root under Windows would be c:.
I would say the closest thing is My Computer.
no not realy.
my computer is an abstraction layer of the file system. it is a location that consolidates all the devices.
/ is the top level of the file system. windows has a fragmented file system that is based on the device so if you did a cd / in d: it would go to the top level of the d: drive not of the system (which would be my computer if it was a real location in the file system.
Don’t explain it, *fix* it!
/System (everything I don’t need to worry about; /System/kernel, System/drivers, etc.)
/Programs (where applications go – subdivided into user-created categories, ie. Programs/Office, Programs/Games, etc.)
/UserFiles (only files saved by user)
/ is an abstraction layer as well when you take into account /proc and /dev
i wouldnt say that there was a win32 equivalent as these two are completely different paradigms(sp?)
In ancient times, file names were limited to x characters depending on the system (ie. 8.3 for DOS). Today, all modern file systems allow for much longer file names. It is therefore not very user friendly to use cryptic file names. Case in point – /usr. That stands for Unix System Resources, but its amazing how many people (including the author of the above article) confuses it with user. Likewise, /sbin, /etc, /var, /mnt and others are just too short. Windows has a similar problem – in the System directory, most executables and DLL’s still adhere to the 8.3 naming scheme which disappeared more than 10 years ago. Not only that, but when you check what daemons and services are running, you get cryptic file name information – what the hell is msghrt.dll?
One of the nicer (read user friendly) features of BeOS and MacOS is that they have descriptive file names and system directory names. Ie. if I check my BeOS file system from the desktop, I can see a file called : BeDisk/beos/system/servers/audio_server. Have a quick guess what that file is. Likewise, another file is BeDisk/home/config/addons/kernel/drivers/bin/ac_97. Nice, easy to understand, descriptive.
I guess that we’ll always have 3 approaches:
– the *nix approach, where everything is conscise, efficient, and difficult to understand.
– the Mac approach, where everything is easy to understand, but maybe slower and less efficient.
– the Windows approach, which is a hybrid of the above 2.
How anybody who says that the Linux filesystem should be changed invariably suggests something with TitleCaseCapitalization, like Windows, Program Files, and My Documents? Maybe we’re just being a little bit slavish to what we’re used to
To those complaining about the system, take a look at projects like ROXOS http://lemmit.kaplinski.com/home/green/Linux/ (based on GTK2/ROX) or LinuxStep or SimplyGNUStep (both based on GNUStep, linked to from http://www.gnustep.org).
ROX and GNUStep both use AppDirs (the entire application is packaged within a directory, and you click the directory to run, like NeXTSTEP/MacOS X). Additionally, they’ve both eschewed the stardard filesystem layout and do things like having /System directories and whatnot.
(I’ve never tried SimplyGNUstep, but to my knowledge it’s the only one that’s released a package. RoxOS is still in the designing phase… discussion on the mailing list, no real development just yet. I don’t know about LinuxStep.)
root dir [/] in windoze would be ur desktop…
/mnt would be My Computer
“The only major differences you’ll find is in the layout of the startup scripts, and the location of KDE/GNOME. It’s rather unusual to see deviations other than that. ”
Are you kidding? Where are your system-wide Mozilla plugins?
/usr/share/plugins
/usr/share/netscape/plugins
/usr/share/mozilla/plugins
/usr/lib/mozilla/plugins
/usr/lib/mozilla/1.3a/plugins
/usr/lib/mozilla/1.3/plugins
/opt/netscape/plugins
/opt/mozilla/plugins
/usr/local/mozilla/plugins
And this is just Mozilla. It’s a total mess. Also take a look where specific kde libs are installed or try to find two distributions with the same file layout of Qt. Just because KDEDIR point to the same directory in two distributions doesn’t mean the it’s the same layout. Red Hat for example is famous when it comes to placing libraries to strange locations.
FHS didn’t solve many problems and LSB doesn’t cover such things at all. For a comercial software company who doesn’t want to give away their sources, the Linux platform is a horror which is the reason why most vendors only support a very very small number of distributions. I don’t believe this will change.
Those who are unhappy with the standard Unix fileystem layout (which is however much more pratical, powerful, useful, and makes more sense than windows mess, and overall quite consistent among OSes and versions) should have a look to OpenStep/GNUstep FS layout…
There is a book that some may find interesting :
William von Hagen, “Linux Filesystems”, Sams Publishing, 2002, 555 pages.
It gives a good insight on all types of filesystems used in Linux.
Disclaimer : I’m related to neither the editor nor the writer of the above mentioned book
They have Sun Solaris boxes and all the apps and things they install on top of the system go in /opt… something like the gimp goes in /opt/pkg/apps/gimp… and inside of that directory they have /bin /etc /share /lib … then these things are linked to the standard locations /usr/bin /usr/share /usr/lib /etc … When they remove an app they delete the directory, then they occasionally run a tool they wrote themselves to go through and recreate/delete the symbolic links.
I really believe that user level add-on applications should go in /opt (or /usr/local as seems to be how BSD does it)… and system and standard stuff should go where they do now (standard as in, vi, grep, cat, etc…). Way too much stuff goes in /usr/bin IMO (takes ages to read that directory in KDE)…
rpm does allow relocation of packages, but the package has to allow it. I think autopackage is going to allow relocation, I just hope that they _require_ that an app packaged with autopackage has to be able to be relocated. Then in a GUI tool you could set autopackage to have a standard prefix for “Application” Class packages (e.g. I would like my packages to go in /opt/apps). There could be “System” class packages that don’t obey this rule too.
/System (everything I don’t need to worry about; /System/kernel, System/drivers, etc.)
/Programs (where applications go – subdivided into user-created categories, ie. Programs/Office, Programs/Games, etc.)
That wouldn’t work. How would you deal with $PATH? The more dirs in PATH the slower the shell will become. You could symlink the binaries into a bin dir but then that would be messy and difficult to maintain.
Why can’t there be a user-level opt/ directory? (/home/$user/opt) It could be used for storing things that the user would like to have more control over installing (Mozilla, *Office, GIMP), and that directory could use the packaging system and be run through symlinks (since the user that wants this kind of thing usually wants just a shortcut, a .desktop file works too). For other apps (system, various CLI, tiny GTK pieces of crap, other things for a multiuser system), they could use the distro’s packaging method and have their /bin directories.
All in all, the FHS is very easy to understand and navigate once one gets the hang of it.
who thinks this whole *nix file system layout is annoying and archaic.
Thanks for the reference to OpenStep and all that… Anyone who is seriously trying to bring *nix into the modern era deserves some attention.
And no, I don’t want slavish uses of names. I’m okay with the short and simple names in BeOS (such as apps, beos, home, etc, but there’s still stupid posix junk there hidden) though I think Classic Mac OS has lessons that were never learned by anyone, including Apple, that need to be re-noticed (Apple is going backwards now that they too are using Unix – maybe they will do some evolving of the *nix world too…).
Classic Mac OS had a SIMPLE layout with OBVIOUS names that weren’t too long. Not to mention, without the NEED for a terminal (and therefore not having one at all), you could comfortably have names with caps and spaces and not give a crap. It’s disgusting that people think ADDING a Terminal to an OS’s lineage is an Advancement! But then, it IS a Unix and if you don’t have a terminal, you’re screwed at some point, no matter how cute the GUI is that’s stapled on top.
root dir [/] in windoze would be ur desktop…
/mnt would be My Computer
Wrong. The desktop is located elsewhere in the file system. In DOS-based Windows, it is in the C:Windows directory. In multi-user Windows, it is found either in “C:Documents and settings” (which is a stupid-ass name) or [insert old NT style folder name here because I can’t remember it any more].
Root (/) in Windows is C: (the indicates ROOT which you would know if you had grown up with DOS). There is no device independent root (virtual root?) since drives are the base of the file system tree and there’s no dev structure like in a Posix environment. There’s no “live structure” in a DOS or Windows system.
DOS/Windows does not allow you to see, nor do I believe it contains, anything lower on the tree than the root of the drive letter (volume).
/mnt has no equivalent in DOS/Windows. If anything, it’s not more or less similar to “C:” being the root. It doesn’t matter what drive you’re talking about. A, B, C, D, etc. Since DOS/Windows has no dev structure, there are as many roots as there are volumes.
WinNT/2k/XP has methods for mounting volumes without drive letters but I don’t recommend using them (my experience is that it doesn’t work as you would like it to; it is a hack, either in the system end or in the GUI end – a hack on either end leads to problems). When using that “feature” it “mounts” volumes as folders. Where do those folders live? Not in a root/dev structure. It appears wherever you stick it, like a shortcut. There’s no logic to it. It’s supposed to be flexible but it is more problem-causing than anything else. I’ve used it and nothing ever worked correctly (surprise surprise, it’s a hack and no one at MS tests this stuff very much because they don’t think users will use it and they may be planning it to be expanded in the future).
DOS, and its original creators, left the PC world with one of the worst curses ever to befall computing: DRIVE LETTERS! Just you try to avoid drive letter schemes in your “fancy new” XP or W2K OS. The whole freaking architecture is addicted to drive letters at the most basic level and the sooner this is eliminated (good luck waiting for that to happen) the better.
This is one of the many reasons I prefer dealing with non-MS operating systems (and non-DOS-styled open source operating systems). Volume names are where it’s at. It’s the only way to free yourself from the nightmare of drive ordering. Eliminate the drive scheme!
“DOS, and its original creators, left the PC world with one of the worst curses ever to befall computing: DRIVE LETTERS! Just you try to avoid drive letter schemes in your “fancy new” XP or W2K OS. The whole freaking architecture is addicted to drive letters at the most basic level and the sooner this is eliminated (good luck waiting for that to happen) the better.
This is one of the many reasons I prefer dealing with non-MS operating systems (and non-DOS-styled open source operating systems). Volume names are where it’s at. It’s the only way to free yourself from the nightmare of drive ordering. Eliminate the drive scheme!”
IIRC the drive letters came from cp/m, like the 8+3 filenames. It made sense at a time when drives and RAM were very small.
What happens on a Windows system with more than 26 partitions?
Volume names are definitely where it’s at. We have always had these in AmigaOS, and the DOS system seems very crude. And as for “logical partitions”!
Just you try to avoid drive letter schemes in your “fancy new” XP or W2K OS
Easy : use NTFS partitions and mount all partitions that aren’t your boot partitition in a folder instead of assigning them a driveletter.
Volume names are definitely where it’s at. We have always had these in AmigaOS
Yes! I remember to install a program that came on a floppy to HD all you had to do was use the ‘assign’ command to point that volume name to a certain folder. That rocked.
Easy : use NTFS partitions and mount all partitions that aren’t your boot partitition in a folder instead of assigning them a driveletter.
Oops , you said this. Just ignore my comment. It works fine for me though, then again I don’t spend that much time in Windows any more theses days
Linux file system requires detail knowledge of its structure but it is more robust than windows file system.
/System (everything I don’t need to worry about; /System/kernel, System/drivers, etc.)
/Programs (where applications go – subdivided into user-created categories, ie. Programs/Office, Programs/Games, etc.)
That wouldn’t work. How would you deal with $PATH? The more dirs in PATH the slower the shell will become. You could symlink the binaries into a bin dir but then that would be messy and difficult to maintain.
It’s simple: You don’t deal with $PATH!
It’s one thing to stick small, non-interactive, command-line programs in one or two big directories with the $PATH pointing there. That kind of program doesn’t need big configuration files, resource data and internal libraries.
LS, Cat, More and IFConfig and their ilk can be kept together without the user worrying about clutter. But why would you stick larger GUI programs or for that matter larger CLI programs in one, two or three big directories? They have a lot of data apart from the main executable, and aren’t often started from a CLI, hence the $PATH is of no concern. CLI programs reside on $PATH, GUI programs don’t.
And if you’re really aching to start your program from the command-line without typing its path and without including it on the $PATH, just make a link. After all, that’s one of the more comfortable features of a modern filesystem.
There are tons of reasons to have GUI applications in the $PATH. This way scripts and stuff (which can use DCOP or the GNOME equivilent to talk to GUI apps) don’t need to know the exact path of an application. It also greatly eases creating shortcuts and whatnot. And to a user who uses the “Run” functionality in the menu, just typing “konqueror” makes a whole lot more sense than “c:windowsexplorer.exe”.
Remember old DOS days? When HDD’s were very slow, it was common to have sepaprate directory just to store batch files, that would act as shortcuts to other programs, so you needed only this directory included in your PATH.
Byr frankly – I think that the layout proposed (with /System etc.) really makes sense – maybe, if it would be problematic for the shell, it is good idea to rework the shell, or some other parts of OS and instead of trying to keep the FS layout ugly and messy because of this. Priorites 🙂
And last thing – maybe it is really high time to include standard FS layout as *mandatory* part of LSB (for example). The inconsistencies between distributions are a real trouble, and not only for newbies. It is sad to see people (and companies) concentrating their development and training only on one distro (and in most cases this means – on RedHat) because of such small things…
Why would DCOP need to know the path of a program? Doesn’t it talk to the program’s port?