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?
Anyone who claims that RedHat started the use of /usr/bin/ as a dumping ground can't be taken seriously. Pretty sure slackware and SLS did the same thing. Same goes for Solaris, AIX, AUX, Sun/OS, Irix, and HPUX.
It's not about lazy distributors. It's about administrators who are used to doing things this way and distributors going along with tradition.
I think it is better to install all your programs binaries under a subdirectory, then symlink the executables to the /bin /usr/bin or /usr/local/bin directorys. This gives you a lot easier way to remove programs that don't have an uninstall script included, and Is a lot more organized.
--
FearLinux.com
The database-like features of attributes/index of the BeOS filesystem could be an interesting solution to the problem of the PATH variable.
BeOS keeps a record of all executables files on the disk and is able to find which one to use to open a specific file type. You don't have to register it with the system or anything, if it's on the disk it will be found. That makes it easy to install BeOS applications in their own directories. However, BeOS doesn't use this system to replace the PATH variable in the shell but one could imagine a system that does just that.
True warriors use the Klingon Google
*sigh*
/opt/foo or wherever, then symlink to /usr/local/bin. yawn.
has anyone heard of symlinks? the theory is very simple - install the app into
or is that one of those secrets we're not supposed to tell the newbies?
remote access CLI with tools is the only friend you'll ever need.
/opt/LINWgrep/bin/grep
/opt/LINWsed/bin/sed
/opt/LINWdate/bin/date....
The one thing this guy fails to answer is "why is it bad that I have 2000 files in /usr/bin?". There are no tangible benefits I can see to splitting things up, other than perhaps a mild performance gain, and satisfying someone's overeager sense of order.
Failing to answer that, I think his whole discussion is pointless.
Blaming it on lazyness on not wanting to muck with PATH is wrong. Managing your PATH is a real issue, something an administrator with any experience should understand. In the bad old days we came up with ludicrious schemes that people would run in their dot files to manage user's PATH. I'm glad those days are over. Not having to worry about PATH is a tangible benefit. Forcing package mantainers to use a clear and concise standard on where to put programs is a tangible benefit.
Perhaps I'm biased because these past many years I've always worked with operating systems (Solaris, Debian, *BSD) that have package management systems. I don't care where they get installed, as long as when I install the package and type the command it runs. This is a Good Thing.
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
Even better would be if Linux had a translucent file system. Simply mount all the path directories on top of each other and let the OS do the rest.
For the uninitiated, a translucent file system lets you mount one filesystem on top of another filesystem, the idea being that if you tried to open a file the OS would first search the top filesystem, then the bottom one. In conjunction with non-root mounting of filesystems (e.g. in the Hurd) it removes the need for $PATH because you can just mount all the relevant directories on top of each other.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
I think the fundamental problem here is related to yesterday's story about new user interfaces. It's a problem of how and where storing our files. Regarding applicationsn, there are two ways to do it: you can store all files (binaries, config files, man pages, etc.) of the same application in the same directory, or you can store all files of the same type from different applications in their respective directories (all config files in /etc, man pages in /usr/share/man (I think), etc.).
Both approaches have their advantages. The problem with hierarchical file systems is that we have to choose one of them. I would love to see a storage system where we can use both ways _at the same time_. A system that groups file depending on relationships they have. Such that 'ls /etc' gives me all config files for all apps, and 'ls /usr/local/mutt' shows me all mutt-related files, including it's config file(s).
I have no idea how to implement such a beast. I'm thinking about a RDBMS with indices on 'filetype' and 'application', but I would love to see something much more flexible. All pictures should be accessible under ~/pictures and subdirectories, all files relating to my vacation last year in ~/summer2000. Files relating to both should be in ~/pictures/summer2000 _and_ ~/summer2000/pictures.
To a certain extent, this can be done via symlinks, but it should be much easier to deal with. You shouldn't have much manual work
This sig under construction. Please check back later.
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.
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.I have been lazy before with my linux box and let package management systems lay out files all over the freakin' place.
:->) with my Solaris box and followed this standard:
/usr/local/bin
/opt:
/usr/local/bin
/opt and put the damn symlink in /usr/local/bin.
/usr/local base.
I have done things the "right" way (according to my mentor admin anyway
/usr/bin - sh*t Sun put in.
Let pkgadd throw your basic gnu commands into:
Compile from source all major apps and services Database services, Web Servers etc...etc.. and put them into
/opt/daftname
symlink any executable needed by users into
(if you think like a sysadmin you realize most users do not need to automatically run most services)
Any commercial software goes to
Yes, it is extra work but it keeps you PATH short and fat and your users happy. This is not a problem with distros or package management systems as much as it is an issue of poor system administration.
I also understand it is a mixed approach with some things put under seperate directory structures for each program and some things in a comman
Common users do NOT need access to the Oracle or Samba bin. Give them a symlink to sqlplus and they are happy. Even though it is mixed if you stay consistent across all your boxes then the users are happy.
I understand it is tough but we have control in *nixes to put things where we want the deal is to use it.
PATH=/usr/bin:/usr/ucb:/usr/local/bin:.
export PATH
All a regular user needs.
ACK
The reason windows apps can happily install binaries in any directory is because they then go install their shortcuts in the Start menu, or the desktop. Of course if you want to run one from a command line interpreter you're pretty stuck.
So now my windows Start menu has 1000 items in it, but at least they are arranged hierarchically in 850 vendor program groups...
Baz
Package management is a way to standardize the way software is installed, upgraded, and removed.
It sounds very appealing. The problem is that a lot of the software I need right now (openLDAP, openSSL, etc) has packages that are a full development generation old. There isn't a 2.x package yet for openLDAP on RH 6.2, for example, and I don't think anybody in particular is in charge of building it.
Building from source is the only way to be current, although it is often an immense pain in the ass.
The other gripe I have is about packages failing to recognize libraries that are installed just because they weren't installed by a package manager. Yes, you can force a --nodeps sometimes and cross your fingers, but you shouldn't have to lie to the software to get it to work. Package managers should be a little smarter and be able to look around a little to satisfy dependencies.
If the package system really worked cleanly, it would be great, but I'm still using Pine 4.20 on my box because of conflicting dependencies in the 4.3x packages. I'm about to nuke the whole thing and build Pine from source - which I'll do as soon as I can get those library dependencies solved.
Grr.
-- http://frobnosticate.com
The system does not go through all of the directories in the path every time you type a command. No shell that I know of is stupid enough to do that.
Shells do a lot of cacheing. The most common strategy these days is to automatically regenerate the path cache every time you change your cache. Many shells also have a way of manually directing it to rebuild it's cache.
With an intelligently designed cache, the memory use difference between cacheing binaries from a small number of huge directories, and a huge number of small directories is small to zero.
That said, I still disagree with Mosfet. I've also done time as a sysadmin. Personally, I think that having the binaries stored together is preferable, because I'm capable of using a package manager to manage my applications; but many of my users find it extremely difficult to deal with paths. (Not to mention the degree of sensitivity it produces when you change a system. If I use RPM to install a new version of something, then the RPM database id modified with information about the new version. If I install something in a way that modifies the directory heirarchy, then I have to make sure that every user of my system correctly modifies their path.
Personally, I think RPM style package managers are a huge step forwards, and they make the admins job a lot easier. Why should I care that there are thousands of files in my /usr/bin, as long as I have a useful tool for managing them?
Now, data files are a different matter... But they get separate directories in the current style. So that's not a problem.
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