Unix/Linux root folders

Is there any rhyme or reason as to folders that are listed under / in Linux OSes? In particular i’m playing with Suse Linux Open Enterprise Server 10 but i have noticed similar folders in Red Hat and AIX. In Windows world it’s fairly easy with 3 main folders, Documents & Settings, Program Files, and Windows. But here is the list i have under /

[ul]
[li]bin (this is short for binaries i take it, so should i pronounce it “bine?”)[/li][li]boot (i know GRUB lives here)[/li][li]dev[/li][li]etc[/li][li]home (looks like Documents & Settings)[/li][li]lib [/li][li]media[/li][li]mnt[/li][li]opt[/li][li]proc[/li][li]root[/li][li]sbin[/li][li]srv[/li][li]subdomain[/li][li]sys[/li][li]tmp[/li][li]usr[/li][li]var[/li][/ul]

Why so many folders and what does each one do that they can’t be lumped together into 1 main /Linux folder?[list]

This explains the standard Unix directories.

As to why, the directories are a defacto standard that Linux had to follow(and no doubt the POSIX standard does specify that certain configuration files must default into be under /etc, and so on, so the the existence of some of these directories is an actual standard).

Unix doesn’t have a “Windows” folder. There’s no particular reason for this except history. Windows was made to be user friendly, while *nix was made for software geeks.

[ul]
[li]bin (this is short for binaries i take it, so should i pronounce it “bine?”)[/li][/ul]
No idea. I pronounce it to rhyme with tin.
[ul]
[li]boot (i know GRUB lives here)[/li][/ul]
Bootloader, yes.
[ul]
[li]dev[/li][/ul]
All physical devices in the computer have a listing in the folder system. This gives a set way to refer to something. They all reside under /dev
[ul]
[li]etc[/li][/ul]
Configuration files for all your programs and services get lumped up into /etc
[ul]
[li]home (looks like Documents & Settings)[/li][/ul]
Yes
[ul]
[li]lib [/li][/ul]
The Linux version of DLLs all reside here
[ul]
[li]media[/li][/ul]
Non-standard. Sometimes it will go under mnt
[ul]
[li]mnt[/li][/ul]
The standard location for things like USB devices, CDs, or mounted hard drives to appear
[ul]
[li]opt[/li][/ul]
Not sure
[ul]
[li]proc[/li][/ul]
Info about all of the various drivers and the system itself can be accessed as text files.
[ul]
[li]root[/li][/ul]
The Documents & Settings folder for the root user (Administrator)
[ul]
[li]sbin[/li][/ul]
More binaries. Was never sure what the specific difference was between bin and sbin
[ul]
[li]srv[/li][/ul]
No idea.
[ul]
[li]subdomain[/li][/ul]
No idea.
[ul]
[li]sys[/li][/ul]
Standard, but not sure what goes in there
[ul]
[li]tmp[/li][/ul]
Standard location for temporary files
[ul]
[li]usr[/li][/ul]
Standard location for images and other files that applications need
[ul]
[li]var[/li][/ul]
Standard, not sure what it’s for really

There is some standardization, but not a whole lot. Every distribution likes to do things a little differently, all based on traditions inherited from various commercial Unix products and the BSDs.

That said, the important ones are:

/bin – for binaries required for system startup. Most other binaries will be in /usr/bin (this allows /usr to exist on a separate partition)
/dev – device files for various thingies. Your hard drive partitions live here (/dev/sd0, for example, if you’re using SCSI, otherwise /dev/hd0, or something else.) Every tty device also lives here, the console device, printers, mouses, keyboard, and the famous /dev/null
/etc – This is for global configuration files, mostly for server processes, global settings for various shells, and other programs. Lots of miscellaneous junk ends up here.
/home – for your users’ home directories.
/lib – Shared libraries (think .DLL files) that are required for system startup. Most others will be under /usr/lib
/mnt – root mount point for temporary media, like CD-ROM drives. By convention, if you pop a CD in, its filesystem will often be mounted under /mnt/cdrom, although SuSE may do it differently. It’s also a common convention to mount NFS or Samba shares here.
/opt – One location to place user-installed software.
/proc – This is for procfs, which lets you use the filesystem interface to gain information about every currently running process. Have fun catting the files in here, you may learn something interesting.
/root – root’s home directory. Not a good idea to put it under /home since /home may be on a different partition
/sbin – System binaries, most of which will be used only by the superuser (/sbin is not in regular users $PATH by default in most distributions.) Most of the stuff in here requires root privileges to run, but there’s nothing otherwise special about it.
/srv – Dunno
/subdomain – Dunno, but I’d guess it has something to do with subdomains.
/sys – Dunno
/tmp – This is the place for all temporary files generated by programs. Most distributions come with a cronjob that automatically cleans up /tmp of any old files, though programs are supposed to be well-behaved enough to clean up after themselves.
/usr – This is a secondary directory hierarchy which contains all non-boot-essential stuff, and may be on a separate partition. It mirrors the structure of some of the root directories, with subdirectories like /usr/bin, /usr/sbin, /usr/lib, and /usr/var on some systems. There’s also /usr/local, which is another place to put custom or user-installed software that’s local to that machine. It too will have /usr/local/bin, /usr/local/sbin/, /usr/local/lib, and so on.
/var – This is sort of the opposite of /tmp – it’s used by programs to store stuff that should stick around between runs. Database files, logs, lock files, mailboxes on some systems, etc.
Clear as mud.

That link is pretty good.

/bin: Pronounced like it looks. Like a generic container that you put stuff in.
/dev: Not generally a real location on disk; it’s created virtually by the kernel.
/etc: Pronounced “et-see”. I know, but that’s how it’s done. Notable contents include the hosts and resolv.conf files for DNS, the mail directory for email server configs, the init.d and rc.? directories to start and stop services (programs).
/opt: You put your 3rd party software here, so theoretically, all the servers you manage are the same everywhere but the /opt directory.
/proc: Prock. Also a fake filesystem built at boot time.
/sbin: Ess-bin. If you run a command from here, you’d better know what you’re doing. Historically, Solaris has made root’s shell /sbin/sh, a statically linked binary, so that if the system is hosed, you don’t need any other files to exist for it to execute. Which means you have a chance to fix things.
/tmp: Sometimes you need to pronounce this as “tmp”, so you don’t confuse it with temp, which can also exist in places. In Solaris, /tmp exists only in memory, so its contents disappear on reboot.
/var: You generally want /var to be a separate partition, so that when it fills up with logs and mail (which it will) your system doesn’t implode.

If you had a /unix directory, you would just have to have all of these directories inside of it. On a performance OS like Unix, it just makes sense that / is the Unix directory. The reason that they’re broken up is to keep some semblance of order. And because they, historically, would be mounted on separate tiny disk partitions. I can’t imagine the crazy finds and ls | greps I’d have to do to just to see the files I need if they were jumbled together.

Ha. No. (Look at the registry, for instance.)

This isn’t really full of files, but it looks like it is. Nothing in proc takes up disk space.

Don’t log in as root, in case you think you should sometimes. Using sudo is a lot safer.

bin is for normal programs, sbin is for special system programs needed to do the essential stuff. This is from when bin and sbin might not exist on the system at the same time.

I’m stumped, too. These definitely are not standard.

Also a lot of configuration stuff.

It’s for spools, like storing mail on your own computer instead of having to contact a mail server every time you want to check your mail.

This: Filesystem Hierarchy Standard
Explains the Linux directory hierarchy, including the mysterious /srv directory.

Much of this stuff was originally designed in an era when disks were relatively small, computers had multiple disks, and it was common to put different parts of the operating system on their own disks. That also helped improve the performance of the system. /, /usr, /tmp, /var, and /home might all be on separate disks.

Disclaimer: I’m basing everything off of Linux here. It’s been way too long since I’ve played with a non-Linux Unix, so I’ve forgotten a lot of the differences.

It’s a bit trickier than that. /dev is real on disk, and the files in /dev are real on disk. It’s merely the file contents that’re created virtually by the kernel.

In contrast, the only thing real on disk in /proc is the mount point (an empty directory until the virtually created file system is mounted on top of it).

While the difference between the two is often academic, there are some real consequences. For example, you can create, delete, or otherwise futz with the device files in /dev, and they’ll stay changed until someone or something fixes them (often via the MAKEDEV program). In /proc, there’s nothing to delete because all the files you see are an artifact of the proc file system code claiming that the files exist when a program inquires about the existence of the files. So you can delete /dev/hda (which really just wipes out a reference to the kernel representation of the hard drive and not the representation itself), but you can’t delete /proc/uptime.

Perhaps these are intended for use in Netware, since Netware is now using SuSE for its OS?

Everything in Unix is a file - including the devices. It was just the philosophy when they created it.

The first character of the file type in the long listing tells you what kind of file it is:


>drwxr-xr-x   4 root     other        512 Jan  9  2004 backup
lrwxrwxrwx   1 root     root           9 Nov 19  2002 bin -> ./usr/bin
-rw-r--r--   1 root     root           6 Dec  6  2004 bpstart
-rw-------   1 root     root     13115272 Jul 17 07:37 core
drwxr-xr-x   4 bin      lp           512 Jan 31  2005 cron.p30
drwxr-xr-x  19 root     sys        12800 Jul 17 07:15 dev

The “d” in the first position indicates a “directory” (don’t use the word “folder” - makes you sound like a (ugh!) Windows user). A directory is just a file of filenames (and other supporting information). It’s just a convenience in how you and the OS organize files - there’s no real folders/directories on a hard drive of course - no actual structure on the disk surface.

A “-” in the first position indicates a regular file, just a bunch of data blocks with a name attached. It could be a executable file, a script (like a .bat) file, or a flat file with a recipe for rice pudding - just a file.

An “l” (lower-case “L”) indicates a symbolic link (often called a “soft” link). This is a pointer to another file like the Windows “shortcuts”. Technically it’s an inode pointing to another inode but were getting pretty deep with that.

Devices come in one of two types, “c” and “b”, “character” and “block” devices respectively. The simple explanation is that these two types differ in how the OS buffers data to and from them. Character devices are usually serial ports, tty’s, pty’s, etc. Block devices tend to be disk drives, tape drives, and other bulk transfer devices.


brw-rw----  1 root disk     8,   6 Jul 18 08:48 sda6
brw-rw----  1 root disk     8,   7 Jul 18 08:48 sda7
crw-------  1 root root     4,   2 Jul 18 14:50 tty2
crw-rw----  1 root tty      4,  20 Jul 18 08:48 tty20

If you notice, it’s very different from the file types above. Field 5, the “size” field for any of the regular file types is now two numbers separated by a comma. These are the major and minor numbers. A major number usually describes a specific kind of device, the minor number often controls the behavior of that device.

For example, a tape drive can have many different modes of operation, different densities, different compression factors, etc. This’ll usually reflect in using the same major number for the device and having different minor numbers.

Messing around, deleting devices and writing/reading to devices under /dev can have an affect on your running system - it’s only by the grace of the programmers that some of it is rebuilt when the box boots. It didn’t used to do this on older systems (I once deleted /dev/null and had a bear of a time getting it back).

Wanna see live memory? “cat /dev/mem”

Write to it and you can crash your system.

/proc is a view into the running kernel, too. Some of it is read-only but other things under there can be modified. You can alter the running kernel process and cause bad things[sup]tm[/sup] to happen if you’re not careful.

Unix has very few controls to keep you from shooting yourself in the foot. If Linux asks you “are you sure”, it’s because some programmer someplace knew that Linux is where a lot of newbies start. Traditional Unixes just let you merrily delete the entire file tree and don’t say “boo” until they refuse to boot later.

Yep. It also makes sense in terms of backups; you may backup /home nightly, and /var weekly or whatever, but only the /bin, /usr, et cetera after system updates, which was important back in the day of slow and limited tape backups.

As for rhyme or reason, every *#*(&# Linux distro seems to do things a little bit different, and rarely in ways that are actually superior to one another. Unfortunately, there is no overarching standardization for Linux utilities; Tovalds controls the kernel, but everything else is up for grabs, and Red Had/Fedora is probably the closest thing to a standard, as mediocre as that is.

Stranger

Not recently. With Ubuntu getting as big as it has, the Debian standard (which you need to follow to use Debian packages) is likely bigger outside of the companies wedded to Red Hat support contracts. In reality, however, this matters relatively little: The Linux Standard Base is well-supported in both the Red Hat and Debian worlds, which compose a majority of modern Linux systems that aren’t embedded systems. (TiVo is ‘embedded’ for my purposes here.)

Without trying to start an argument, I have to say that I consider the Linux Standard Base to be something of a joke; there are still major differences permitted under LSB, and the requirement to use Redhat Package Manager format and utility for updating apps is just back-assward.

I may be biased because of the corporate standards, but Red Hat seems to have a much larger share, at least in major companies and for high performance computing server applications, particularly ones running commercial numerical solver codes (for finite element analysis, computational fluids, radar cross section, EM and multiphysics solvers, et cetera). Some software manufacturers support Red Hat and Suse, but I don’t know of any that support Debian or Ubuntu (though it is often possible to get software to work with a little tweaking under the hood). Personally, I think the .deb package format is far superior to .rpm (although I like FreeBSD ports and Gentoo Portage the best) but Red Hat seems to have cornered a lot of the corporate market.

Stranger

There is no requirement the distro use RPMs exclusively, merely that it support RPMs (specifically, the limited RPM format described by the LSB). Debian plus the alien program is LSB-compliant in this respect, even though 99% of the software is installed via debs.

It usually is not hard to get that software running on other distros. Even binaries can usually be coaxed to run if the system is setup to handle old binaries in general (old libraries, a well-configured interpreter (binfmt_misc really helps here), and maybe duplicate configuration files in strategic locations).

The Debian world has both alien and tons of volunteers following the Debian standards. This has worked for a long time indeed.

Red Hat owns the corporate market, but that’s never been the entirety of Linux, merely a range of applications for it. Debian would go on even if the corporate world decided to abandon Linux entirely.*

*(So would Slackware, but absolutely nobody would notice. ;))