Slashdot Mirror

In addition to the other answers, I will mention the FHS or Filesystem Hierarchy Standard: http://www.pathname.com/fhs/pub/fhs-2.3.html

Note its descriptions of /bin /usr/bin /var and /var/lib

Particularly:
"/var contains variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files."

and /var/lib:
"This hierarchy holds state information pertaining to an application or the system. State information is data that programs modify while they run, and that pertains to one specific host. Users must never need to modify files in /var/lib to configure a package's operation."

So it is just the wrong place entirely; and there are at least 3 potential correct places, /usr/(lib|bin), /opt/XXX or debatably /(bin|lib).... however even the last one is likely incorrect as those must be on the root filesystem and thus should only contain files that would be required during the boot process, before other filesystems (like /usr) might be available.

The only reason I could see for wanting this stuff in /var would be if the program ran in a chroot and needed to be able to dynamically load libraries. Even that is likely not the best approach.

With regards to Windows, I don't entirely disagree. However, there are APIs available that tell a developer/installer/whatever where the correct directories are located.

Yup, Linux has standards too. One's called ~. (Mac also uses this.) It always points to the current user's home folder where you can place your data. If that doesn't suit your fancy, getenv_("HOME") will get you the home folder as well.
It also has a standard location for binary files, shared binary, libraries, etc.: http://proton.pathname.com/fhs/2.2/ | http://www.tuxfiles.org/linuxhelp/linuxdir.html

Hint: /usr/bin is where you put your "user" "binaries"... I know it's such a hard concept to wrap your head around. Maybe you should take a few minutes to try to figure all that out.

What the hell are you doing outside your home folder? I love tweaking (as in swapping out schedulers in the kernel, using microarch optimized builds, low level fs utils...). But I always just yaourt -S pkgname and use it. What the hell do I care where it goes?
BTW, http://www.pathname.com/fhs/
Knock yourself out.

Boy, I hope to never encounter your software. You're saving yourself from minimal pain at the expense of your users What company do you work for again?

/usr/companyname [..] /appl/foo

Ever heard of /opt?

Actually the FHS states specifically for AMD64, PPC64, s390x and sparc64 that native (64-bit) libraries go in /lib64 while 32-bit (31-bit for s390) libraries go in /lib because the number of 32-bit binaries/libraries are expected to far outweigh the number of 64-bit binaries/libraries. It also states specifically for IA-64 that native (64-bit) libraries go in /lib as it reflects the deprecation of 32-bit binaries (and libraries) on that architecture.(source) For any other architecture, 64-bit or not, /lib32 and /lib64 might coexist with /lib being a symlink to one of them.(source) I presume that */lib and */libXX would be expected to be similar to /lib and /libXX. After all, who wants 64-bit binaries in /lib and 32-bit binaries in /lib32 but 64-bit libraries in /usr/lib64 and 32-bit libraries in /lib? However, the last version of the FHS was completed in 2004. Some deviation should be expected, especially when you consider how many 64-bit distros are in use compared to back then. It has been seven years after all. Time for a new FHS version? :)

Actually the FHS states specifically for AMD64, PPC64, s390x and sparc64 that native (64-bit) libraries go in /lib64 while 32-bit (31-bit for s390) libraries go in /lib because the number of 32-bit binaries/libraries are expected to far outweigh the number of 64-bit binaries/libraries. It also states specifically for IA-64 that native (64-bit) libraries go in /lib as it reflects the deprecation of 32-bit binaries (and libraries) on that architecture.(source) For any other architecture, 64-bit or not, /lib32 and /lib64 might coexist with /lib being a symlink to one of them.(source) I presume that */lib and */libXX would be expected to be similar to /lib and /libXX. After all, who wants 64-bit binaries in /lib and 32-bit binaries in /lib32 but 64-bit libraries in /usr/lib64 and 32-bit libraries in /lib? However, the last version of the FHS was completed in 2004. Some deviation should be expected, especially when you consider how many 64-bit distros are in use compared to back then. It has been seven years after all. Time for a new FHS version? :)

Still KDE is missing integration for FF, Chrome, OO.

Um. Surely you mean, "Still FF, Chrome, OO is missing integration for KDE"? Last time I checked, it was unreasonable to expect KDE developers to go out and patch KDE integration into [insert your every favourite application here].

I think OS community does not have enough resources to maintain different applications for several desktop, or maintain several desktops.

As long as people are able to choose to do something different, there will be people who do choose to something different. As soon as you mandate the One True Desktop Environment (for example) you lose most of the power of Free software.

Competition is good, but linux needs standards to make it easier for software and hardware manufactures to support it.

What, you mean like POSIX, the Filesystem Hierarchy Standard, and all of these other cross-DE specifications?

Yes, it's absolutely your fault, and there is an excuse. There's this thing called the Linux Standard Base (LSB) which was put together by all the major distros and is an agreement on how a variety of things should work in Linux to maintain a consistent platform. It's mediated by the Linux foundation. It includes by reference the Filesystem Hierarchy Standard (FSH) which is a map of how the filesystem should be laid out and how it should behave. The FSH recommends that /tmp be wiped on boot. They comment that it's only not a requirement because system administration decisions are outside the scope of the document.

Gentoo is just following the appropriate standards. I know that almost all Debian-derived distros delete /tmp on boot and I believe Red Hat derived ones do as well but I'm not sure about that. Regardless, it is the proper behavior as recommended by the appropriate standards.

I just did a search for .conf files here on my linux box. Im seeing files in /etc sure, but there are also files in /usr, /usr/share, /usr/local, /usr/src, /usr/libexec, /var/spool.

/usr/src is not for configs. It usually holds only kernel sources. Even if you build own kernels, it is better to build kernel packages on devel box and install only customized kernels on production machine.

/usr/share - how many files are not default ones and are not samples from /usr/share/doc?

/usr/local. What have I said about you doing something. Mandriva and other Linuxes don't put files there. Only basic directory structure.

Name configuration files that you have modified outside of /etc/ and /usr/local in order to make Linux work. I know only grub (which I usually don't modify and generate with /usr/sbin/grub-update in Debian) and qmail (which follows own standards)

FHS. Read and learn. Then you won't be lost in Linux directory tree.

http://elbitz.net/home.php is good, but they only open up registering every now and then (I remember I waited like 2 months to get my user). In general, though I just use the same popular torrent sites for everything else I get for books, too and I've gotten 6.28GB that way. Also, appear to have just found a .pdf with a huge list of ebook sites (and one for how to swear in all languages!). Haven't tried any of them, but go for it:
O'Reilly online http://www.oreilly.com/openbook/ | http://sysadmin.oreilly.com/ Computer books and manuals http://www.hoganbooks.com/freebook/webbooks.html | http://www.informit.com/itlibrary/ | http://www.fore.com/support/manuals/home/home.htm | http://www.adobe.com/products/acrobat/webbuy/freebooks.html The Network Book http://www.cs.columbia.edu/netbook/ Some #bookwarez.efnet.irc links http://www.extrema.net/books/links.shtml Some #bookwarez.efnet.irc fiction http://194.58.154.90:4431/enscifi/ Pimpas online books (Indonesia) http://202.159.16.55/~pimpa2000 | http://202.159.15.46/~om-pimpa/buku Security, privacy and cryptography http://theory.lcs.mit.edu/~rivest/crypto-security.html | http://www.oberlin.edu/~brchkind/cyphernomicon/ My own misc online reading material http://www.eastcoastfx.com/docs/admin-guides/ | http://www.eastcoastfx.com/~jorn/reading/ Computer books http://solaris.inorg.chem.msu.ru/cs-books/ | http://sweetrude.net/~cab/books/ | http://alaska.mine.nu/books/ | http://poprocks.dyn.ns.ca/dave/books/ | http://58-160.skarland.uaf.edu/books/ | http://202.186.247.194/~ebook/ | http://hooligans.org/reference/ Linux documentation http://www.linuxdoc.org/docs.html FreeBSD documentation http://www.freebsd.org/tutorials/ Sun documentation http://osiris.imw.tu-clausthal.de:8888/ | http://uran.vvsu.ru:8888/ SGI documentation http://newton.unicc.chalmers.se/ebt-bin/nph-dweb/dynaweb;td=2 | http://techpubs.sgi.com/library/tpl/cgi-bin/init.cgi IBM Online Redbooks http://www.redbooks.ibm.com/ Digital Unix documentation http://www.unix.digital.com/faqs/publications/base_doc/DOCUMENTATION/V40D_HTML/V40D_HTML/LIBRARY.HTM Filesystem Hierarchy Standard http://www.pathname.com/fhs/2.0/fhs-toc.html | http://www.linuxbase.com/ UNIX stuff http://ww

until the Linux community agrees upon a file structure...

Oh you mean like the Filesystem Hierarchy Standard? The FHS is a file tree standard for Unix systems. Ironically, Apple's OSX is a licensed Unix system that does not conform to the FHS. On the other hand, every general-use or enterprise Linux system conforms to this standard.

...(remember United Linux?)

No, but from a quick google search, it sounds like they were not too successful. The Linux Standard Base is making headway, despite the demise of UnitedLinux, however. The LSB defines uniform packaging specifications for third party vendors. The biggest problem is getting third party vendors to conform, even loosely, to the standards.

If you are ONLY using 64-bit libraries, you could just use a symlink to make /lib point to the correct place.

"64" qualifiers are allowed by the FHS.

unfortunately FHS is ambigous on the issues..

http://www.pathname.com/fhs/pub/fhs-2.3.html#LIBESSENTIALSHAREDLIBRARIESANDKERN

> The /lib directory contains those shared library images needed to boot the system and run the commands in the root filesystem, ie. by binaries in /bin and /sbin

Thus, if your /bin contains amd64 binaries needed to boot the system, you should put the amd64 libs in /lib.

FHS is built on assumption that the 32bit userland is the default and only selected binaries (databases, and others who really need 64bit pointers) are 64-bit - which is true for the older 64bit archs.

but lib64 is stupid idea in the first place.

It should be more generic: /usr/lib/$(arch)/

Thus you could support as many 32 and 64bit architectures as your cpu (and kernel) supports (and the rest via emulation).

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387446

Libraries should live in /Library or something like that, users under /Home or /Users, and end-user applications (like OpenOffice.org) in /Applications or /Programs.

/Applications or /Programs? That's what I thought /opt was for: add-on application software packages. For instance, a tetromino game called Lockjaw could install into "/opt/Lockjaw/lj".

in the end, users don't give a damn whether or not they can 'modify' this new driver they're installing to get compiz to work.

Ubuntu's restricted driver installer explains one benefit of Free drivers other than that the end user can modify them: it's that the developers of Compiz have the ability to trace into the driver to discover, work around, and report defects that they find in drivers.

So I went back to Microsoft.com and looked at the instructions. I have to click on a folder called WindowsXP. Why should I do that? Windows Update knows I am on Windows XP.

What does it mean to have to click on that folder? So I get a bunch of confusing stuff but sure enough one of them is Moviemaker. So I do the download. The download is fast but the Install takes many minutes. Amazing how slow this thing is.

What it means to have to click on that folder is that you have not provided adequate leadership on programming, the primary function of your software company. Because you have established no rules to make installation convenient for your paying customers, as the filesystem hierarchy standard does for Linux users for free, your programmers just toss their junk together in whatever way is most convenient for them. After all this time, to have failed to create an analogous Windows filesystem hierarchy standard, is atrocious, negligent incompetence.

College should teach programmers how to write efficient algorithms. You should teach them how to integrate those algorithms into a larger project, with your own model of advanced object-oriented programming, which you should have developed but have not. Then, every one of your programmers would know the same convention for the entire path of any downloaded install binary. It appears from your complaints in this article that you have not even defined a directory naming standard. I wasn't planning to be so hard on you for the many failures of your products to increase my convenience or to perform their advertised functions, but after your literally monumental public displays of incompetence, you have the audacity to whine that all the good programmers are foreign.

You are not a good programmer. You have failed to demonstrate the expertise to define standards that would ensure that useful information is made available by your various product teams to the other teams, for your buzzword "interoperability" to be meaningful within your own brand. You are therefore not qualified to speak at a junior college computer science faculty barbecue about good programming, or to anybody else about any other aspect of technical aptitude, because you have demonstrated a complete lack of any. The spectacle of you speaking to Congress as a technology expert is an embarrassment to the nation. I do not believe a corporation is entitled to the individual right to Free Speech which is incorrectly asserted as defense of corporate donations to politics. I do believe that the irrational exuberance of the dot-com boom that led to unprecedented price-to-earning ratios, which necessitated the eventual correction of the dot-com bust, was a direct result of that inappropriate tolerance of corporate interference in government. Politicians who should have been neutral were instead at the very best, shading the truth to say favorable things about their information technology donors whenever the subject was raised, and investors foolish enough to believe that anything they said about that industry was said as representative of the people concluded that then-current stock prices were likely to be justified by near-future earnings, and were taken to the cleaners.

You, of course, are not a big enough fish to be single-handedly responsible for all, or even for very much of that, but you are the most willing public mouthpiece of the information technology industry's thirst for cheaper foreign laborers. I want you to shut the hell up about all immigration laws, for one thing because your software demonstrates your abject lack of qualification to make any of the statements that you have previously made, to Congress no less, about the lack of talented programmers. You don't know a good programmer from Shinola, and nobody in the Congress would help you pretend that you are, excep

/var/tmp is supposed to persist past reboots.

In a similar vein, it is frustration with the out-dated UNIX system of spreading bits of applications around inconsistent places in /bin, /usr, /etc, /usr/local and who knows where else that has pushed me away from most Linux distros towards using BogoLinux, PC-BSD, and MacOS X.

As others have pointed out, with package management systems available, this makes no difference to usability.

More to the point, just because you don't understand the Filesystem Hierarchy Standard, don't knock it. Contrary to your beliefs, it's not just some disorganised relic of past Unix. It is designed to allow system files with different characteristics to be separated from each other so they can be spread across different filesystems and mounted in different ways. This is very useful for things like network booting, backup plans and security models.

"it would be nice to have some of the guesswork taken out of things. Then document it in a similar fashion. :-)"

It has been done for years, Mr. lymond01: http://www.pathname.com/fhs/

Read and internalize the Filesystem Hierarchy Standard.

It's a pretty easy read, and you'll understand where everything goes on a Linux system and why.

Just because you read it somewhere doesn't mean it's not bullshit.

Actually there are no .'s or ..'s in the file system. These little gems only denote relative directories and are never actually part of the file system. I'll refrain from calling you a noob. Like the . it is almost always implied, and in 99% of the cases is just redundant.

As for the /etc debate. I thought FSH settled all of this ridiculous bickering years ago? /etc is etcetera abbreviated. "Extended Tool Chest" is the most retarded thing i've ever heard. I don't know why people are still debating this. The people over at the FSH project put a lot of hard work in to their documents specifically to avoid stuff like this.

http://www.pathname.com/fhs/

This whole slashdot question is a little silly, as your post points out. Who really cares what it stands for as long as we know what goes in there.

I found this document interesting a while ago, thought I'd share it: http://www.pathname.com/fhs/pub/fhs-2.3.html

It's the 'Filesystem Hierarchy Standard by the Filesystem Hierarchy Standard Group' It's more useful for OTHER arguments like '/media' vs '/mnt' and '/var' vs. '/opt', etc. :)

Oh, /opt is where all the optical drive device files live, but only on Opteron-based systems, of course. :)

Actually, I'm trying to think where I first encountered /opt - it was either on a Sun or an SGI, around 1990-1996ish, I think. Anyway, it's basically for optional software packages - often third-party - that come with all their own libraries and baggage... like if you were installing the Netscape webserver or Adobe Photoshop 3 or something on an SGI box in the mid '90s, it might have gone into /opt. (Been a while, so I don't recall. :) Nuke something out of /opt and it should be gone pretty cleanly.

(Of course, modern package-management tools make this slightly unnecessary... but /opt bears a little bit of resemblance to OS X's /Applications in this regard - except that an application in /opt might also store its configuration, spools, and so on in its tree under /opt)

The FHS explanation of this seems pretty decent.

The /etc hierarchy contains configuration files. A "configuration file" is a local file used to control the operation of a program; it must be static and cannot be an executable binary. [4]

IIRC, some other systems (SunOS?) used to put binaries in there, which never made sense to me

utilities (by which you mean "command-line utilities" != Applications.

See what I meant about everyone has a different opinion? What's the difference between an application and a utility?

That's not the problem, that's the symptom. The problem is *that there's no specific place for them to put things*. Linux would gain 100-fold in usability were it to embrace application and framework/library bundles.

The problem goes much deeper than not having a standardized location, it's that types of programs can, and often do, bleed over into other definitions.

Linux does use libraries/frameworks. In addition to the ones already used, many have died for one reason or another, mostly due to software darwinism.

WTF? Ubuntu is the sole authority on its OS. RedHat is the sole authority on its OS. Debian is the.. well, you get the picture.

The named distros all follow http://www.pathname.com/fhs/. They are the sole authoritity, indeed. They have, however, all decided to follow the same standards. That's more than most OSs can claim.

WTF? take 2. That doesn't even make any sense in the normal way "Apple == MS" doesn't make sense.

They share a similarity in that there are no clear formal rules for what goes where. With debian, I'm all but guaranteed that the package I install from the repos follows all debian guidelines and has predictable locations for files. With OSX and Windows, the applications/utilities I install are all installed with the values the author decided.

To sum up: The difference between application and utility is very hard to gauge. It'd be ridiculous and error-prone to separate them out, so just group them together and be done with it. Maybe 10 years down the road computer science course will decide which end to cut the hard boiled egg on (big end or little end?) and we can make a new folder for apps. Maybe we can even call it "app" without the CAPITAL so we can keep our pinky usage to a minimum (no pun intended).

Adding applications

Once that was done, I started installing my favorite packages.

Tops on my list of applications are Firefox and Thunderbird, and I always get rid of modified versions and substitute the pristine versions direct from Mozilla.org. So I downloaded both, unzipped and untarred them into /usr/lib/, where Debian likes to keep them, and created symlinks in /usr/bin/ pointing to /usr/lib/firefox/firefox and /usr/lib/thunderbird/thunderbird, where the system expects to find them.

Apparently dude've never read FHS. Say goodbye to your favorite packages when you apt-get upgrade.

If this is the most authoritative source Microsoft can assemble to substantiate their claims Open Source is complex

No, this and this are the sites that say that. The OSS community doesn't need MS to point out flaws, when we can do it ourselves. The correct attitude to all this, of course, is to acknowledge valid points and fix them (because if you don't, well, that way lies Marketing)

You're right and you're wrong. Having every program use its own format is stupid, but so is creating a Registry.

The good solution is the one Mac OS X uses: have text config files for everything, but put them all in a standard format (plist).

By the way, your assertion that UNIX apps all put stuff in different directories is wrong -- well-behaved UNIX apps should follow the Filesystem Hierarchy Standard.

Every single distro does its own thing and there is no standardization whatsoever.

I humblely disagree.

Filesystem Hierarchy Standard (FHS)

The filesystem standard has been designed to be used by Unix distribution developers, package developers, and system implementors. However, it is primarily intended to be a reference and is not a tutorial on how to manage a Unix filesystem or directory hierarchy.

Gentoo FHS
RedHat FHS
Suse FHS&LSB

And for binary distros there is Linux Standard Base (LSB)

The LSB specification is made up of several components, known as modules. The base specification consists the of Core, Graphics and CXX (C++) modules. The specification is further extended with the Desktop set. Each module might be subdivided into a common document plus architecture-specific documents (in some cases the subdivision is not needed). A complete binary standard for a particular processor architecture consists of the set of necessary common documents plus the matching set of architecture-specific documents.

Latest LSB Spec 3.1.0

This hierarchy is intended to be shareable among all architecture platforms of a given OS; thus, for example, a site with i386, Alpha, and PPC platforms might maintain a single /usr/share directory that is centrally-mounted.

... every single Linux distribution I've seen for the past years has used /var/www for storing web pages?

Guess you haven't seen SUSE then, or indeed any LSB-compliant (or FHS 2.3 compliant) distro then.

The Filesystem Hierarchy Standard says to put that stuff under /srv (typically in /srv/www) and the Linux Standard Base says to follow the FHS. FHS 2.3 has been the standard for nearly two years, since January 2004.

Just because RedHat screws it up... (At least AS4 has /srv)

The reasoning for having a /bin and a /usr/bin is that you can have a very small root partition.

I don't see the need for that on a modern desktop system. Most of the guidelines in the Filesystem Hierarchy Standard come from a historical idea that you can share the same programs on every UNIX system on a site by mounting an NFS share on /usr, but this is an extra unnecessary complication for home users. Who even has separate / and /usr partitions today?

The /usr/share/bin directory is for binaries that may be shared among multiple systems.

I think the parent tricked you! The official description is:

The /usr/share hierarchy is for all read-only architecture independent data files.
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSH AREARCHITECTUREINDEPENDENTDATA

This precludes /usr/share from containing executable binaries, since they are different for each architecture. It was basically designed to separate the platform-specific and platform-independent files that were one both kept in /usr/lib. On my Ubuntu Linux system, /usr/share/bin doesn't even exist.

Filesystem Hierarchy Standard (FHS)
http://www.pathname.com/fhs/

This is a well known standard that has been around for quite some time. Most distros that I see have finally made the move to this structure. This was the primary driving force behind the /media and /srv additions you see in distros now days.

It's the non-standard nature of the directory tree that gets on my nerves. /bin, /usr/bin, /usr/share/bin, /usr/local/bin, /usr/local/share/bin... Aargh!

Whats non-standard about that?
http://www.pathname.com/fhs/pub/fhs-2.3.html

The filesystem structure is like that for good reasons. Go read up on them.

IIRC, it's FHS

The LFSS (Linux File System Standard) is the main standard I am really concerned about; if developers and OS distributions would stick to that it would solve a great deal of the problems I see when installing applications.

The LSB is overrated imho.

They are http://www.pathname.com/fhs/. C'mon... Mandriva? What the hell is this?

(..) that native 64-bit libraries don't live in /usr/lib, instead living in /usr/lib64. This is a mess, and in a few years the excuse that it's there for compatibility won't matter. It's not cool to pay more attention to backwards compatibility than to native code, and it's always something one regrets later.

How do you mean, a mess? To quote from the Filesystem Hierarchy Standard v2.3: "There may be one or more variants of the /lib directory on systems which support more than one binary format requiring separate libraries."

So for example a /lib64 or /usr/lib64 isn't there to indicate that libraries are native 64 bit, nor for backwards compatibility. Only for allowing different sets of libraries side-by-side on the same system, if needed. In that case, you can have a mix of binaries linked against different library sets, that live happily together.

Don't want or need that? A simple symlink, or hard-linking one directory to another, should do the trick.

.. and it's always something one regrets later.

a well-thought out directory structure

man 7 hier

The various Linuxen are still trying to straighten things out with the FHS.

Linux doesn't have to be like Windows. But it would be nice if some of the distributions solved a few of the problems that are already fixed in Windows.

For example, it would be nice to have a simple directory structure that makes sense. The FHS doesn't cut it. The /usr/bin directory is for "most" commands? The /usr/local directory is for software installed by the "administrator"? WTF?

What's with the single threaded linear bootup process? The kernel is capable of running how many process in parallel? And yet the init daemon has to start one service at a time in linear fasion regardless of dependencies?

We've got JFS, AFS, NFS, NTFS, ABCFS but how about a filesystem that supports generation datasets? Wasn't that available on other systems back in, oh I dunno 1900? It seems useful on other systems like VMS and OS. I guess Windows doesn't have this either so here's a chance to *gasp* make an improvement past Windows!

the Terminal.app is worth the investment in a PowerBook in itself.

Considering how much Terminal.app is like any terminal emulator (i.e., xterm, rxvt, etc.), you do realize that this line does, in fact, make you sound retarded.

If you're all hot and bothered about the *BSD userland, you can get that easily without a powerbook. You can even use a version that comes close to meeting the Unix Filesystem Hierarchy Standard instead of dumping shit wherever they wanted to (because /System/ just works, you know.)

-transiit

Thats one of the big issues I have with Linux. This hierarchy is left up to the various distributions and many times, a strong, well planned layout is simply not there.
http://www.pathname.com/fhs/

Debian follows the LSB pretty well.

Debian unstable seems to follow FHS 2.3, including /srv and /media directories. The only differences I see are that there's no symlink from /etc/grub to /boot/grub, and their AMD64 port doesn't use /lib and /lib64 in the recommended way (but there are symlinks for compatibility, so it shouldn't be a problem).

In short, the directory structures are being taken care of.

Personally, I see this like going back to the DOS days. Linux/BSD have been dealing with shared libs in pretty sane ways. Although rpm is sometimes a pain in the butt, Debian's package system and Gentoo's Portage prove that dealing with dependencies automatically is feasible and confortable.

And, anyhow, for special cases, you can always drop apps into /opt and get the equivalent of a bundle. Oracle does this, vmware does this, as there are countless other cases.

Duh! The "awful media replacement" is actually from Filesystem Hierarchy Standard and every distro should follow it.

Not to mention the awful "media" replacement for mnt...

http://www.pathname.com/fhs/pub/fhs-2.3.html#MEDIA MOUNTPOINT