Slashdot Mirror
Rage Against the File System Standard
pwagland submitted a rant by Mosfet on file system standards. I think he's sort of over simplified the whole issue, and definitely wrongly assigned blame, but it definitely warrants discussion. Why does my /usr/bin need 1500 files in it?
Is it the fault of lazy distribution package management? Or is it irrelevant?
So, I'd say yes, it probably is partly because of lazy distro package management, but then again some people might still use some of this stuff and expect it to be there.
On most new distrubutions I've see this is actually getting better. The latest Slack at least completely separates gnome by putting it in /opt/gnome.
In any case though, I think there are more important things to worry about, such as all-purpose configuration tools, or at least lump them all together into a graphical management tool. You should be able to configure everything from sound/video to printers all in the same place.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
Here's what every unix administrator I know (including myself) does:
example$ ls
apache emacs krb5 lsof mysql openssl pico ucspi-tcp
cvs iptables lprng make-links openssh php qmail
(pico is for the PHBs, by the way)
example$ ls
default emacs-21.1
example$ ls -ld
lrwxrwxrwx 1 root root 10 Oct 23 16:33
Uninstalling software is 'rm -rf' and a find command to delete broken links. Upgrading software is making one link and running the script to make links again. No need to update anyone's PATH on a multi-user system and no need to mess with ld.so.conf. You can split
The unix system doesn't really dump all the files in /usr/bin. These are, almost without exception, executable files. For each executable, support files are usually installed into one or more directory trees, such as /usr/share/executable_name/. The main convenience gained by having all the main binaries in one place (or two - I usually try to leave system binaries in /usr/bin and my own installations in /usr/local/bin) is convenience for searching paths when looking for the binaries.
However, this paradigm is pretty ugly if you are browsing through your files graphically. It would be nice if each application/package installed into one directory tree, so you could reorganise the system simply by moving applications around. For example,
.. this dir holds all quake 3 files ...
... this dir hold all gimp files
/usr/applications/
/usr/applications/games/
/usr/applications/games/quake3/
...etc..
/usr/applications/graphics/
/usr/applications/graphics/gimp/
...etc...
If this appeals to you, you might like to check out the ROX project. This sort of directory tree layout was the standard on the Acorn Risc OS and made life extremely easy for GUI organisation. It makes a lot of sense to use the directory tree to categorise the apps and files.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
Much better to have a few thousand files in one dir than to have so many dirs that need to be in your $PATH that some shells will barf.
For instance, the POSIX standard (I believe) is 1024 characters for $PATH statements. That's a minimum. My users at work sometimes have need for much longer $PATH's. Some OS vendors say, ok, 1024 is the minimum for POSIX compliance, that's what we're doing. Some, like HP-UX (believe it or not) have increased this at user request to 4K.
In any case, this all seems pretty petty. It's not like our current and future filesystems can't handle it, and package managers are pretty good and know what they put where.
You want the Encap package management system. From the FAQ:
The technique is essentially compatible with RPM, but Encap goes so far as to define a package format, which probably is not. If you like RPM, you might do better to simply follow the same convention.--AP
The final solution to this mess.
/usr/bin who cares how many files their are there?
/usr
/usr
Unless you are hand writing each file in
And Windows !=
Program Files ==
This
Many years ago, we wrote a set of Perl utilities for automating symlink maintenance called opt_depot.
It's similar to the original CMU Depot program, but has built in support for linking to a set of NFS package volumes, and can cleanly interoperate with non-depot-managed files in the same file tree.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Most major distros install quite a bit of stuff by default that you will 1) you probably will never use 2) you probably dont know what it is 3) if it's a server you don't need anyway
/usr
/opt is reserved for the installation of add-on application software packages. A package to be installed in /opt must locate its static files in a separate /opt/ directory tree, where is a name that describes the software package.
/opt in their own subdirectory i.e.; /opt/kde2. I think this is a much better solution than cluttering up the /usr heirarchy, and makes it very simple to test a new version of without destroying the current setup.
This is one of the reasons I created Beehive Linux. It aims to be secure, stable, clean, FHS compliant, and optimized for hardware built in this century. Current version is 0.4.2, with 0.4.3 out in a week or so.
On one point however I must disagee with Mosfet:
The most obvious thing is separate the big projects like desktop projects into their own folders under
The FHS states:
Beehive puts large packages like apache, mysql, kde2 under
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety" - BF
How many directories in
Actually, it's perfectly possible to use a separate directory for every single package - right down to GNU grep - if you:
For the latter, try GNU Stow or (my favourite) Graft (available via Freshmeat). These tools could even be easily run as part of a package management post-install procedure.
The depot approach has a number of advantages, not least of which the ease of upgrading package versions and maintaining different versions concurrently. And it's obvious what's installed and which files they provide.
The challenge is in encouraging the vendors to embrace such a model as an integral part of their releases; that would require some significant reworking.
Ade_
/
Big Bubbles (no troubles) - what sucks, who sucks and you suck
I agree that this is a Linux-related issue that mostly stems from lazyness. I have been using the modules approach for tool management for years with very good results - even half a decade ago this was more advanced than any Linux approach out there today.
... environment to reflect the tools you want to use (note that this supports the usage of a tool, it is therefore not a replacement for package management tools like rpm, which are mainly concerned with installation.)
/bin etc.).
With this approach each tool/version-combination gets its own directory, including subdirectories for libraries, source code, configuration files etc.
You can then use a "module" commando to dynamically change your PATH, MANPATH,
Each tool/version combination comes with an associated modulefile (which has a tcl-like syntax) where you can influence a user's system environment upon loading/unloading the module. It is also possible to e.g. create new directories, copy default configurations or do platform-specific stuff for a tool (which greatly helps users less fluent in Unix, since they do not have to care about stuff like shell-specific syntax for setting environment variables).
It also allows you to give tool-specific help, e.g.
$ module whatis wordnet
wordnet: Lexical database for English, inspired by psycholinguistic theories of human memory.
$ module add wordnet
This is also very helpful if you want to keep different versions of the same tool (package, library) around and switch between them dynamically, e.g. for testing purposes (think different jdks, qt-libraries, etc.). With modules, you can e.g. do a simple
module switch jdk/1.2.2 jdk/1.3.1
and runs your tests again. And you never have to worry about overwriting libraries, configuration files etc. even if they have the same name (since they are kept in a subdirectory for each version).
For our institute I've set up a transparent tool management system that works across our Linux/Solaris/Tru64 platforms. All tools are installed this way (except the basic system commandos which still go into
Of course, it's a lot of work to start a setup like this, but in a complex environment it is really worth it, especially in the long run.
The tool I use (and prefer to GNU stow) to manage the stuff that isn't managed by a package manager is graft.
./configure --prefix=/usr/local/vim-6.0
/usr/local/vim-6.0, and graft creates symlinks in /usr/local/bin, /usr/local/man, etc.
/usr/local/vim-6.0
/usr/bin.
For stuff that uses GNU-style configure scripts to build, it's simply a matter of, e.g.
$
$ make
# make install
# graft -i vim-6.0
The files themselves are stored in
Removing the software simply involves:
# graft -d vim-6.0
# rm -rf
That said, I usually rely on the package manager, and don't really have a problem with 2000 files in
Have you actually had to manage a system that works like this? It's a royal pain in the ass.
Yup, I have. In fact, we've managed all of our UNIX systems that way for the last 8 years or so. It's not a pain in the ass at all.. in fact, with the opt_depot scripts we wrote, we support automagic NFS sharing of packages for all Solaris systems in our laboratory. Indidivual system administrators can choose to use a particular package off of their choice of NFS servers, or they can simply copy the package's directory to their local system.
Using symlinks gives you complete location independence.. all you need is a symlink from your PATH directory to the binaries, and a symlink from the canonical package location (e.g., /opt/depot/xemacs-21.5) to the actual location of the package directory, be it local or be it NFS.
There's a group at NLM who is working on tools and standard practices for managing NFS package archives using RPM, and then using the opt_depot scripts to integrate the package archives with each local system automatically.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
We do the same thing on our Tru64 boxen. All 3rd party software goes in /opt or /usr/opt. 3rd party executables go in /usr/local/bin. Some executables live in an app-specific subdirectory under /opt and the symlink in /usr/local/bin points to the physical location. It makes OS upgrade time tons simpler. And the first step of our DR plan is to backup OS-related stuff and backup software on special tapes. Those get restored first so that we get a bootable system in a hurry. Then the rest of the software and data can be restored using the 3rd party backup software. None of this would be as easy to do if we had 2000 programs all living under /usr/bin. If Mosfet has a point it's that some distribution vendors make a mess out of the directory structure by dumping way, way too much stuff under, say, /usr/bin.
\begin{rant}
RedHat, are you listening? I like your distribution but the layout of the files you install sucks big time. Anyone who updates their applications (Apache, PostgreSQL, PHP, etc.) from the developer's sites has to undo the mess you guys create. Either that or don't install the versions on your CDs at all and just go with the source tars.
\end{rant}
(OK, I feel better now...)
CUR ALLOC 20195.....5804M
You're right - Slackware, Debian, and SuSE (relatively older players in the Linux game than RedHat) did do this heavily in older versions. However, there has been some work in each of these distributions to remedy this. For example, in Slackware 8, all GNOME default-install stuff is in /opt/gnome (which is sensible and clean), all KDE default-install stuff is in /opt/kde (likewise), and contrib packages normally get installed in /usr/local (the semi-official place for things you compile yourself) or /opt (more sensible, since these are still distro packages).
/usr and make things a real nightmare to manage. Added atop that dependency conflicts where Program A needs library 2.3.4 while Program B needs library 2.4.5, and the system approaches unmanageable at a very high rate of speed.
As far as commercial UNIXes go, they really *are* better organized than the average Linux distribution. I'm speaking mainly from Solaris experience, but BSD/OS and HP/UX also keep a pretty good level of modularity to the filesystem structure.
RedHat certainly didn't start this fiasco, but then again they haven't been very proactive in fixing these problems either. I can't speak for GNOME or KDE on RedHat (since I only use RedHat for servers without X), but the contrib packages practically all get thrown into
A little more modularity in the file organization department wouldn't hurt us. It could also help the dependency problems if the package maintainers use a more modular file structure to their advantage.
.... um, i lost you after "0110100001101001".
Score:+1, Insightful (Virtual Moderator Point)
As a debian user, I'm a big proponant of using a well thought out package system. But, you're entirely correct. If you have a core system componant (like a library) and the packaged version doesn't provide a piece of functionality that you need, you are completely screwed.
Installing that one library from source doesn't solve the problem. The package mgmt system doesn't see the lib that you installed so it still doesn't install the prog that you want.
So you end up with two choices: install everything from source, or install everything from the package manager.
Debian uses the equivs package to resolve this problem. Basically, you use equivs to create an entry into the package for everything that you install from source. So let's say you install libFoo from source. And the package bar depends on libFoo. You create an equivs package that you install that provides "libFoo". Now you can install the prepackaged bar and everything works.
The other alternative is to add an additional step to everytime you compile from source: create a package for the system you're operating on. Sometimes this is easy, sometimes this is very difficult.
My point is that there are ways of interoperting a packaging system with programs that are installed from source.
Hope this is helpful.
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
True, but it doesn't help in the situation where you have a short shell script running - the shell that runs the script has to hash all those directories.
It just adds to overhead of running a shell script, and that is something I am opposed to on principle. (It's also why I use ash for /bin/sh rather than bash.)
Now, I believe the truly intelligent shells do not pre-emptively cache your whole path, they just add entries to the cache as needed. Either way, though, having a long path is harmful to performance - and a short-running shell (running a short script, say) is penalised more than a long-running shell due to less use of cache.
As an aside, I believe the only things that belong in bin dirs are binaries a user or administrator might ever actually want to run. In this regard, I think Debian packages sometimes go overboard - daemons, in my opinion, should go in /usr/lib/{subdir} or something rather than /usr/sbin, since you should really be invoking them via /etc/init.d/* scripts.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
yes, that's exactly how it works
/bin/$CPUTYPE /bin # cpu specific exes
/usr/$user/bin/bin /bin # my exes
/usr/$user/bin/rc /bin # my shell scripts
/usr/someapp/bin /bin # some app I want
/srv/boot /n/dump dump
/n/dump/1992/0716/mips/lib/libc.a /mips/lib/libc.a
/net
instead of a really long $path you just have
PATH=/bin
and then in termrc (for example)
bind
bind
bind
bind
the namespace is built on a per process group basis so I can pick and choose the exes ()or anything else) on a per process basis
To compile a program with the C library from July 16, 1992:
%mount
%bind
%mk
you can have a different set of libs per window
(or run the windowmanager INSIDE one of it's own windows and set one namespace for that whole group)
plan9 has no symlinks
because "everything is a file" this even works for remote servers & network stacks.
import helix
telnet tcp!ai.mit.edu
more
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
SuSe actuallly does this. On my /opt path I have:
./configure command.
/opt/kde
/opt/kde2
/opt/gnome
And they have bin directories under that. Funny, until now I've only ever heard people slam SuSe for doing it (something about not being Linux Standard Base compliant).
I personally like it. The only thing, whenever you compile a kde program, you add --prefix=/opt/kde2 to the