Linked by Thom Holwerda on Wed 27th Jun 2007 18:45 UTC, submitted by BlueVoodoo
General Unix "Many directories in the UNIX file system serve a special purpose, and certain directories are named per long-standing convention. In this instalment of the 'Speaking UNIX' series, discover where UNIX stores important files."
Order by: Score:
Gee, how useful.
by MrDomino on Wed 27th Jun 2007 19:53 UTC
MrDomino
Member since:
2006-01-10

It sure would be nice if such an overview existed on your actual UNIX system . . .

$ man 7 hier

Reply Score: 5

RE: Gee, how useful.
by DoctorPepper on Wed 27th Jun 2007 20:31 UTC in reply to "Gee, how useful."
DoctorPepper Member since:
2005-07-12

Depends on your UNIX.

Can't find it on Solaris 8 or 10, but it does work on my SuSE 8.x box.

Reply Score: 1

RE[2]: Gee, how useful.
by renhoek on Wed 27th Jun 2007 20:48 UTC in reply to "RE: Gee, how useful."
renhoek Member since:
2007-04-29

Works here on openbsd and osx. But as far as i know it's not part of the unix spec.

The manual states "A hier manual page appeared in Version 7 AT&T UNIX.", we could not expect sun to implement all those new features also in their os which is just one version number ahead.

Reply Score: 1

RE[3]: Gee, how useful.
by Dr_J on Wed 27th Jun 2007 23:56 UTC in reply to "RE[2]: Gee, how useful."
Dr_J Member since:
2005-07-06

The manual states "A hier manual page appeared in Version 7 AT&T UNIX.", we could not expect sun to implement all those new features also in their os which is just one version number ahead.
I do hope this is a joke. Version 7, or more correctly, the 7th Edition, came out in 1978. The summary was released on September 7 according to my very yellow copy.

Reply Score: 2

RE: Gee, how useful.
by Oliver on Wed 27th Jun 2007 23:47 UTC in reply to "Gee, how useful."
Oliver Member since:
2006-07-15

If you are using FreeBSD for example, enter man hier in the shell :-)

It's a hint from Linux for Linux :o)

Edited 2007-06-27 23:48

Reply Score: 2

Unix filesystem is for Geeks only....
by rakamaka on Wed 27th Jun 2007 20:35 UTC
rakamaka
Member since:
2005-08-12

Joe user or even Joe developer has no idea where the program files goes after installation.
No way to find button to start newly installed program, if it doesnt appear in kde or gnome menu.
No way to uninstall program files completely without using exactly same apt or similar program manager.
No way to know is it etc/X11 or etc/kde....in case of x-config or other editing of configs.
No way to search my beloved mp3 file on the hard disk (is there any GUI file search program?)
No way for programmers to have uniformed file locations for each and every distribution.
Whom to blame unix filesystem or distributons??
It is great for developer but a mess for Joe....

Reply Score: 3

progster Member since:
2005-07-27

"No way to uninstall program files completely without using exactly same apt or similar program manager. "

Uhm not true a program could provide it's own uninstaller if it wanted to, most use the package manager provided though (just like most installers for windows do these days).

"No way to know is it etc/X11 or etc/kde....in case of x-config or other editing of configs. "
Got a point there :-)

"No way to search my beloved mp3 file on the hard disk (is there any GUI file search program?)"
Beagle, gnome search, quite sure kde has something similar

"No way for programmers to have uniformed file locations for each and every distribution."
Well no, but the same goes for different windows versions and "unix" distro's have only few things in common, most notably the gnu toolchain.

Edited 2007-06-27 20:53

Reply Score: 1

leos Member since:
2005-09-21

Joe user or even Joe developer has no idea where the program files goes after installation.

This bothered me when I first started to use Linux. I liked to know where my programs were on Windows, and the thought of them being scattered around the file system was disturbing to me.

Eventually I realized that the fact that I cared about where my program was stored was completely backwards thinking, brought about by years of being trained by the broken Windows method of installing applications. The fact is, no user should ever have to care about where an application goes in the file system. It's a technical detail that most people don't care a flying fig about, and shouldn't have to. Once you accept this, you will be way better off letting the system take care of your apps.

No way to find button to start newly installed program, if it doesnt appear in kde or gnome menu.

This problem is a thing of the past. In my experience if you install something in any modern distro, it will appear in the menus.

Also, any program you install with the package manager is in the system path, so you can just type it into the run dialog and it will pop up.

No way to uninstall program files completely without using exactly same apt or similar program manager.

So? This is not a disadvantage. And you can't do it on Windows either (dlls, registry entries will remain if you delele the folder in program files). You can do it on a mac, but the tradeoff is reduced possibility for integration with the OS, like automatic updates for all apps in a central location.

No way to know is it etc/X11 or etc/kde....in case of x-config or other editing of configs.

First of all, you shouldn't have to know this (ok, sometimes you still do), but the rule is, user settings are in your home directory (in the files/folders starting with .) and system settings are in /etc

No way to search my beloved mp3 file on the hard disk (is there any GUI file search program?)

Uhh.. yes. There are plenty of GUI search programs, both traditional (kfind) and new fangled desktop search programs that work with an index.

No way for programmers to have uniformed file locations for each and every distribution.

http://www.linuxbase.org/ establishes standards for that. I think all the major distributions are compliant by now. Or you can distribute your application with a windows-like installer, like Adobe, Google, and Skype (as well as others) do on Linux.

Edited 2007-06-27 20:57

Reply Score: 5

Thor Member since:
2006-09-18

Joe user or even Joe developer has no idea where the program files goes after installation.

This bothered me when I first started to use Linux. I liked to know where my programs were on Windows, and the thought of them being scattered around the file system was disturbing to me.


I don't know, but doesn't most distros have some util for that.

In gentoo:
equery files package

and you get a list with all the files that belongs to that package.

Edited 2007-06-27 21:06

Reply Score: 1

fsckit Member since:
2006-09-24

It's even easier than that. I have not yet met a Linux or BSD that didn't have the which command.

[jamesb@loki ~]$ which vim
/bin/vim

And yes, you are correct. dpkg, rpm, and slackware's package tools all have facilities for listing the file locations of anything in any package. I believe we both may be wasting our time though. The original poster is just another troll.

Reply Score: 1

samad Member since:
2006-03-31

The fact is, no user should ever have to care about where an application goes in the file system. It's a technical detail that most people don't care a flying fig about, and shouldn't have to. Once you accept this, you will be way better off letting the system take care of your apps.


The thing that pushed me from OSX and Windows to Linux is the more control over my system it offered me. I control
EXACTLY
what software is running on my box. If I don't like the kernel, I recompile it to
MY
settings. If I don't like a program, I remove it. Many Linux/*BSD users love this level of control, and that's why they picked their particular OS.

So no, some people DON'T like it when the control is passed on to the "system." That passing on control to the system is why so many people get turned off from commercial OSes in the first place.

Reply Score: 2

jwwf Member since:
2006-01-19

No way to search my beloved mp3 file on the hard disk (is there any GUI file search program?)

It is not that mysterious and you don't need a gui:

$ locate filename
(partial name or wrong case is fine)

$ find / -name "filename*"

To delete only regular files ending with .gz below /test:

$ find /test -type f -name "*.gz" -exec rm {} ;

And if you want the full path of an executable (say, cp) in your $PATH:

$ which cp

Reply Score: 1

Soulbender Member since:
2005-08-18

"No way to find button to start newly installed program, if it doesnt appear in kde or gnome menu. "

You mean, just like there's no way to "find button to start newly installed program" on Windows unless the installer added an item to the start menu?

"No way to uninstall program files completely without using exactly same apt or similar program manager. "

How is this a problem?

"No way to know is it etc/X11 or etc/kde....in case of x-config or other editing of configs. "

Uh, /etc/X11 is for xorg and /etc/kde for kde? Is this hard somehow? Of course, on a distro targeted at Joe User this is irrelevant since there'll be GUI tools.
It's not like it's easy to navigate the Windows registry or anything.

"No way for programmers to have uniformed file locations for each and every distribution. "

Except programmers don't have to care about distributions, the distributors does.

And people complain about Linux zealots...

Reply Score: 2

John Nilsson Member since:
2005-07-06

It is great for developer but a mess for Joe....
That is because the lazy developers decided it was a good idea to expose this interface to the user instead of developing a proper user interface on top of it.

Reply Score: 1

Heh...
by Almafeta on Wed 27th Jun 2007 21:30 UTC
Almafeta
Member since:
2007-02-22

This structure has always been one of the greatest flaws of the *nix structure. This obfuscation doesn't really do anything to help it compete, and it should have been nixed (no pun intended) ten years ago, if not earlier.

Instead of /, why not just use the base device's name? Instead of /bin, why not just call it 'Programs'? Instead of /home, why not just 'Users'? Why doesn't /usr contain information about users as the name suggests, instead of being dumping ground for anything and everything? Why is the contents of a potential 'System' folder (call it /sys or /nix if you like) spread over a half-dozen folders, many of which are also designated to store files that have absolutely nothing to do with the operating system? Why are components put into /dev or /mnt and treated as 'pseudofiles' instead of treating them as, you know, actual devices?

There's no particular reason that this system is adhered to, except for inertia, but even the greatest inertia can be overcome by someone willing to stand up and say, 'Bull.' Every time I see this heirarchy on some hobby OS, I can't help but think that even Microsoft had a more advanced, logical system back in the Windows 3.11 days, and to Win 3.11, that's damning with faint praise.

Reply Score: 4

RE: Heh...
by butters on Thu 28th Jun 2007 00:48 UTC in reply to "Heh..."
butters Member since:
2005-07-08

This structure has always been one of the greatest flaws of the *nix structure.

???

Instead of /, why not just use the base device's name?

Why should the user care which medium is actually storing their data? Isn't a single storage hierarchy easier to understand than a separate tree for each storage resource? How can the user understand how volumes relate to one another if they have no representation in a common namespace?

Instead of /bin, why not just call it 'Programs'?

For one thing, the items in /bin aren't programs, they're executable binaries. Programs include libraries and data.

Instead of /home, why not just 'Users'?

The traditional hierarchy had /usr/home; is that more of what you're looking for? I should note that the Windows equivalent is C:Documents and Settings. I think /home is better.

Why doesn't /usr contain information about users as the name suggests, instead of being dumping ground for anything and everything?

Because /usr isn't short for "users." Its purpose is to separate resources used by normal users from those used by the administrator. Anything required to boot the system, run the shell, and conduct basic administration is kept outside of this directory so that /usr can be mounted separately. It should be noted that /usr was created when K&R ran out of space and added a second hard disk to their PDP-11.

Why is the contents of a potential 'System' folder (call it /sys or /nix if you like) spread over a half-dozen folders, many of which are also designated to store files that have absolutely nothing to do with the operating system?

As I explained, everything critical to the operating system is in /, and nothing in /usr is necessary to boot and administer the system. On Linux 2.6, /sys is a powerful filesystem interface to the kernel. On traditional UNIX, /unix is the location of the kernel binary.

Why are components put into /dev or /mnt and treated as 'pseudofiles' instead of treating them as, you know, actual devices?

One of the central ideas behind UNIX is that devices can be abstracted as files. Everybody knows how to open, read, write, and close a file. How do you operate an "actual device"? This is a trick question, because every device is different. I don't want to know how to retrieve data from a particular device. I want to open its file and read it just like any other file.

There are Linux flavors with alternative storage hierarchies, and none of these have caught on. Of all the issues that negatively impact UNIX adoption, the directory structure is hardly a factor. It is what it is--a bit of a non-issue.

Reply Score: 5

RE[2]: Heh...
by Doc Pain on Thu 28th Jun 2007 20:41 UTC in reply to "RE: Heh..."
Doc Pain Member since:
2006-10-08

Allthough (or because?) your comment is at +5, I'd like to add a few notes.

"Why should the user care which medium is actually storing their data? Isn't a single storage hierarchy easier to understand than a separate tree for each storage resource? How can the user understand how volumes relate to one another if they have no representation in a common namespace?"

Technical devices may evaluate to more than one device file according to different usage options or access modes, such as the PD drive can be a PD drive or a CD-ROM drive:

% dmesg | grep PD
da0: <MATSHITA PD-1 LF-1000 A109> Removable Optical SCSI-2 device
cd0: <MATSHITA PD-1 LF-1000 A109> Removable CD-ROM SCSI-2 device

Both can be set to the same mount point if desired, or have on for each "subdevice". UNIX mount entry points give the ability to set up access rights as desired, or even lets the user have mount points inside his $HOME, or denys storage access.

"For one thing, the items in /bin aren't programs, they're executable binaries. Programs include libraries and data."

/bin is part of the / partition.

For explaination:

In UNIX world, different entries of the / tree do correspond to special devices and partitions. While / and /bin, /etc, /sbin etc. do belong to the paimary partition that is essential during startup, /usr is on a different partition, so is /home, /var and /tmp. This gies the ability do backup (dump/resore) data partitionwise, to tweak partition parameters (inode size etc.) and to restrict partition access rights if desired.

"The traditional hierarchy had /usr/home; is that more of what you're looking for? I should note that the Windows equivalent is C:Documents and Settings. I think /home is better."

Blanks in file names scare me. :-)

Today, /usr/home is still used at some PC oriented UNIX systems, and /home symlinks to /usr/home. You should still be aware that UNIX is a multi-user system so it's not strange to have tons of user groups and users inside the /home directory (or /home partition).

"Because /usr isn't short for "users.""

As it may have been mentioned before, USR == UNIX system ressources.

"Its purpose is to separate resources used by normal users from those used by the administrator. Anything required to boot the system, run the shell, and conduct basic administration is kept outside of this directory so that /usr can be mounted separately."

This is correct. Just as a friendly addition: /usr/ does contain things that do belong to the OS itself, except /usr/local, which contains software that is installed by the OS's package installer or via source code processing. I think /usr/X11R6 is now to be integrated into /usr/local. NB that /usr/X11R6 would not be part of the OS, too.

/usr and /usr/local replicate the substructure known from higher levels. If /etc contains system configuration and /etc/rc.d their control scripts, /usr/local/etc contains configuration for additional applications and /usr/local/etc/rc.d their control scripts. Users may have own configurations that override the application's default ones, using ./bla style directories. Please see the analogy for /bin, /usr/bin and /usr/local/bin, too.

"It should be noted that /usr was created when K&R ran out of space and added a second hard disk to their PDP-11."

Interesting fact, I didn't know this.

"As I explained, everything critical to the operating system is in /, and nothing in /usr is necessary to boot and administer the system. On Linux 2.6, /sys is a powerful filesystem interface to the kernel. On traditional UNIX, /unix is the location of the kernel binary."

FreeBSD offers the same functionality with its /boot directory, where the bootstrapping system, the kernel itself and its loadable modules reside. Even at an early stage, the system is ready for dialog in "kernel mode", without any mount operation that gives access to /usr/local.

"One of the central ideas behind UNIX is that devices can be abstracted as files."

This approach can be extended. Even "interprogram communication channels" can appear as files.

% man mkfifo

"Everybody knows how to open, read, write, and close a file. How do you operate an "actual device"? This is a trick question, because every device is different. I don't want to know how to retrieve data from a particular device. I want to open its file and read it just like any other file."

This is one reason why hardware access is that easy on UNIX. From the point in time when a technical device conforms to a specified and documented standard, no "driver" is needed anymore to use the device. This is because a simple file can be operated, Notable here are SCSI scanners, CD units and tape streamers, but DASD compatible USB cameras, too.

"There are Linux flavors with alternative storage hierarchies, and none of these have caught on. Of all the issues that negatively impact UNIX adoption, the directory structure is hardly a factor. It is what it is--a bit of a non-issue."

There is lot of abstraction possible. KDE can hide everything that's a non-issue to the user, so he does not get bothered with it. For someone who has the power (knowledge + experience) to handle difficult situations (X does not work correctly, USB stick does not work etc.) the established and well intended UNIX hierarchy is a lot of help. He does not have to search for files - he knows where they are due to logical thinking, abstraction and conclusion.

Reply Score: 2

RE: Heh...
by Tyr. on Thu 28th Jun 2007 01:15 UTC in reply to "Heh..."
Tyr. Member since:
2005-07-06

Congrats, you've just reinvented OSX which has system, applications and user folders. Of course the unix stuff is there too, it's just hidden.
The big simplifier in OSX is of course the App-folder which bundles all files of one application in one place. It's really neat.

Reply Score: 3

RE: Heh...
by Spellcheck on Thu 28th Jun 2007 02:09 UTC in reply to "Heh..."
Spellcheck Member since:
2007-01-20

"Unix System Resources"

No, it's not very descriptive, considering the weight /etc and /var pull. But at least try to make an effort at sorting it out and then we can take your criticism, which the file system actually does need, seriously.

Reply Score: 1

RE: Heh...
by MamiyaOtaru on Thu 28th Jun 2007 02:10 UTC in reply to "Heh..."
MamiyaOtaru Member since:
2005-11-11

Instead of /, why not just use the base device's name? Instead of /bin, why not just call it 'Programs'?

Because carpal tunnel is the black lung of programmers. Fewer characters to type = win.

Can it appear arcane? Sure, but users who don't understand it shouldn't be poking around in the file structure anyway. They need only worry about their home directory, and shouldn't care where their package manager dumps files. One of the ultimate newbie distros (Xandros) understands this and hides / by default in their file browser. Konqueror in KDE shows the home directory (~) by default and requires the root directory to be explicitly selected to display it.

Granted, people need to figure out where config files are stored when, for example, X doesn't start. However, it's not the weird hierarchy that makes Unix unsuitable for most people, it's the need to edit config files in the first place. Once that need disappears or is diminished (xorg 7.2 is working on that) then the hierarchy once again doesn't matter.

Each directory has a purpose that is well understood by the people who work with it. Those who don't understand it shouldn't need to. There's hardly a reason to undergo a massive upheaval to satisfy a few newbs who like to poke around in the directory structure. They don't need to be there, and Microsoft knows that as well. What does it say when a user browses into c:Program Files or c:Windows? I can't quote it but it is basically a message telling them they have no business there and are they sure they want to poke around ("you might wreck something!"). If people don't belong there, who cares what it's called. Tradition, and usefulness for people who actually belong there trumps feel-good renaming schemes.

Reply Score: 5

RE[2]: Heh...
by Doc Pain on Thu 28th Jun 2007 20:18 UTC in reply to "RE: Heh..."
Doc Pain Member since:
2006-10-08

"Granted, people need to figure out where config files are stored [...]"

Traditionally, in computer world there was a division between administrators (who had to know - and did) and users (who didn't need to know and therefore didn't). Today, because computers are accessible for everyone, user and administrator usually are the same person, especially in home settings. But let's continue.

"[...] when, for example, X doesn't start."

Again, in computer history, it was good if you could help yourself and correct a problem just by your knowledge and experience. Today, users don't have (and don't want to have) experience and knowledge, so it's clever (for them) to have someone else do the work - a person that you could consider to be an "administrator" (in respect to the original terminology).

"However, it's not the weird hierarchy that makes Unix unsuitable for most people, it's the need to edit config files in the first place. Once that need disappears or is diminished (xorg 7.2 is working on that) then the hierarchy once again doesn't matter."

While the new automated setup will work for most settings (including home settings), for special needs still knowledge and experience is needed. For example, how will you get a tree button mouse to work properly in new Xorg? You still need to edit xorg.conf and maybe recompile X. I do use a 3 button mouse because I don't want to suffer from mousewheel disease. :-)

"Each directory has a purpose that is well understood by the people who work with it."

This is correct. While their names may sound strange today, they have traditional roots, for example "etc" (where /etc/mount has been located) or "usr" (that does not read out "user", but "UNIX system ressources"). I may repeat and emphasize: The UNIX file system structure is well intended. While BSD has one of the most tidy structuring I've ever seen, Linux has more variants.

"Those who don't understand it shouldn't need to. There's hardly a reason to undergo a massive upheaval to satisfy a few newbs who like to poke around in the directory structure."

It's still hard to imagine why someone should know these details in fact. The OS and its system / package installers (that belong to the OS by default) take care about everything. Even as a developer I don't need to know where my files go at install time. Refer to the FeeeBSD ports and packages system for example; extend this knowledge to PC-BSD's PBI system, expecially in regards to GUI integration (namely KDE).

"They don't need to be there, and Microsoft knows that as well. What does it say when a user browses into c:Program Files or c:Windows? I can't quote it but it is basically a message telling them they have no business there and are they sure they want to poke around ("you might wreck something!")."

Therefore, they click "OK" and delete everything they don't know what it's good for. :-)

While in most UNIX cases users may see the content of directories outside their $HOME, they are not able to wreck anything there. So, at maximal stupidity, a user may delete all his files, but the rest of the system keeps running unimpressedly.

Reply Score: 3

RE: Heh...
by Soulbender on Thu 28th Jun 2007 03:16 UTC in reply to "Heh..."
Soulbender Member since:
2005-08-18

"This structure has always been one of the greatest flaws of the *nix structure."

Good thing we have the awesome Windows structure, eh? Or should I say lack thereof?

"Instead of /, why not just use the base device's name"

Why would you that? What's the advantage of that?

"Instead of /bin, why not just call it 'Programs'? Instead of /home, why not just 'Users'?"

Good thing this cant be abstracted in the User Interface, eh? Oh wait, it can be done and have been done.
Sure beats "C:Documents and Settings".

"Why is the contents of a potential 'System' folder (call it /sys or /nix if you like) spread over a half-dozen folders, many of which are also designated to store files that have absolutely nothing to do with the operating system?"

I know it's English but the words does not form any kind of meaning. What are you talking about?

"Why are components put into /dev or /mnt and treated as 'pseudofiles' instead of treating them as, you know, actual devices? "

Uh, there are no pseudofiles in /mnt. You know, since you obviously have no idea at all what you're talking about you should probably just stop talking.

Reply Score: 1

RE: Heh...
by ichi on Thu 28th Jun 2007 09:37 UTC in reply to "Heh..."
ichi Member since:
2007-03-06

Instead of /, why not just use the base device's name?

That'd just not be coherent. If we rename / as hda1/, then mounting hda2 as /home would either end being hda1/hda2 or hda1/home. The former is a mess and the latter is inconsistent with the naming convention you're proposing.

Reply Score: 1

RE: Heh...
by samad on Thu 28th Jun 2007 18:23 UTC in reply to "Heh..."
samad Member since:
2006-03-31

It's been done:
http://www.gobolinux.org/

Reply Score: 1

v ibm..
by hemry on Wed 27th Jun 2007 21:47 UTC
More A Manuel
by whendrik on Wed 27th Jun 2007 23:10 UTC
whendrik
Member since:
2006-12-16

I think it has more a manual function, for (AIX-)UNIX starters...

I can't believe the purpose is to tell something new, more a text they should have on there site since they are selling AIX....

Reply Score: 1

Good article
by BluenoseJake on Thu 28th Jun 2007 00:08 UTC
BluenoseJake
Member since:
2005-08-11

Not too heavy, just enough info to get somebody new to Unix-like systems a start

Reply Score: 3

RE: Good article
by netpython on Thu 28th Jun 2007 06:07 UTC in reply to "Good article"
netpython Member since:
2005-07-06

Yes it's actually a good article for starters. In addition there's as said "man hier".

Reply Score: 2

fair enough but /etc is still a pain
by OStourist on Thu 28th Jun 2007 04:28 UTC
OStourist
Member since:
2007-06-19

My criticism is that we configuration files
all over the place....../etc/app/config

/etc/config
/local/etc/conifig

I remember trying to get the config file
for xdm the X server because I wanted to add
window managers to it. I coud not find out how it was
done and the list maintainer of the distro
was stumped too.

In many cases it is distro specific and arbitrary.
And YES I am an ordinary user but a hacker too.

Unix file heiarchy could be more logical though overall it is not bad

Reply Score: 1

Doc Pain Member since:
2006-10-08

"My criticism is that we configuration files
all over the place....../etc/app/config

/etc/config"


Is a global configuration file belonging to the OS itself. Other examples:

/etc/hosts
/etc/rc.conf
/etc/ppp/ppp.conf

"/local/etc/conifig"

Should be:

/usr/local/etc/config

which is a global configuration file of an application that has been installed by the OS's default package installation system (or compiled from source). It may configure an additional service or be a set of default settings a user may override using his $HOME/.config. Other examples:

/usr/local/etc/pkgtools.conf
/usr/local/etc/ddclient.conf
/usr/local/etc/rc.d/smartd.sh

"I remember trying to get the config file
for xdm the X server because I wanted to add
window managers to it. I coud not find out how it was
done and the list maintainer of the distro
was stumped too."


I think the X configuration file does not contain any window managers... Refering to Xorg, xog.conf is stored in /usr/X11R6/etc/X11/xorg.conf or /etc/X11/xorg.conf. Window managers are added to the users default .xinitrc ($HOME/.xinitrc) or to the skeleton templates (/usr/share/skel/dot.xinitrc).

"In many cases it is distro specific and arbitrary.
And YES I am an ordinary user but a hacker too."


Yes, it is distro-specific in most cases, and while Xorg is in heavy development (modularity, automatition etc.), locations may change.

"Unix file heiarchy could be more logical though overall it is not bad"

I agree here. It would be great to have some consense in UNIX and Linux world, so location schemata between Solaris, BSD, Mandriva, Gentoo, SuSE etc. could be (nearly) the same.

Reply Score: 2

Unix is just great...
by BSDfan on Thu 28th Jun 2007 05:07 UTC
BSDfan
Member since:
2007-03-14

The hierarchy is simplistic and easy to understand...
The design is simply beautiful...

And yes I'm geeky, but I just love it.. ;-)

Reply Score: 2

RE: Unix is just great...
by netpython on Thu 28th Jun 2007 06:09 UTC in reply to "Unix is just great..."
netpython Member since:
2005-07-06

The hierarchy is simplistic and easy to understand...
The design is simply beautiful...


Glad to see i'm not alone here:-)

Reply Score: 2

RE[2]: Unix is just great...
by Doc Pain on Thu 28th Jun 2007 20:58 UTC in reply to "RE: Unix is just great..."
Doc Pain Member since:
2006-10-08

"Glad to see i'm not alone here:-)"

Using the own brain is fun! :-)

And I may repeat: The UNIX structure design has got historical roots that Joe Q. Average can't know about and therefore does not understand, but the design is well intended and... yes... if you are willing to switch on your brain it's really easy to understand. You even can say it's simply beautiful, because it just is. Using logical thinking, abstraction and conclusion you can even tell about file locations on a computer you've never seen. Can you imagine how impressed "usual" users are when you can tell them where their files are - via the phone? :-)

Reply Score: 2

There is always GoboLinux..
by Obscurus on Thu 28th Jun 2007 09:57 UTC
Obscurus
Member since:
2006-04-20

http://www.gobolinux.org/

While there are pros and cons to the standard *nix file hierarchy, for many developers and users, the cons outweigh the pros. If you are used to the way the *nix file hierarchy works, you might feel quite comfortable about it and see no reason to change it. But for some developers, system administrators and end users (although GoboLinux is not targeted at Linux novices), the file haierarchy could use some simplification, a la MacOS X, hence GoboLinux.

For the recird, I have not actually tried GoboLinux...

Reply Score: 2

Unix filesystem is NOT for Geeks only....
by madcap on Thu 28th Jun 2007 17:58 UTC
madcap
Member since:
2005-12-31

As a long time user of Windows, I don't think there is anything wrong with the layout of the Unix file system. For the most part, it's pretty straight forward. I've noticed various differences from different vendors, but that's got to be expected.

If you look at the Windows and the WindowsSystem folders, there is no organization to the files. These folders seem to be dumping groups for various programs. I wish there was "dll" folder for all the dll's, a "log" folder for all the log files, etc.

As for where your MP3's files are, where did you put them? Don't blame the file system.

Reply Score: 2

Doc Pain Member since:
2006-10-08

"As for where your MP3's files are, where did you put them? Don't blame the file system."

Users put their files on the desktop. Or inside the application. ("My music is on the desktop, while my documents are in 'Word'.") And if you wait for a while, everything will be on the desktop. :-)

Reply Score: 2