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.
This is _EXACTLY_ why I use LinuxFromScratch. You do not HAVE to use the package managment system, you can install anything *just* the way *you* want it. X applications in /usr/bin? No way jose! (My appoligies to anyone named Jose, I'm sure you are sick of hearing that one), /usr/X11 it is! If you are not happy with the standards, make your own, it just takes a little time and in-depth knowledge.
You would only need 2000 path entries if your expect your shell to have the same exact semantics that it does today. There is no reason whatsoever that PATH couldn't mean "for every entry in my PATH environment variable look for executables in */bin". A smart shell could even hide all of these behind the scenes for you and provide a shell variable SMART_PATH that gets expanded to the big path for legacy apps.
/command and symlink everything to one place. Although I'm not sure if that solves the original complaint. Actually, I'm not sure what the original complaint is, having re-read the article.
Or you could do what DJB does with
~> ls /usr/bin | wc -l
/bin | wc -l
/sbin | wc -l
/usr/sbin | wc -l
/usr/local/bin | wc -l
/usr and puts all extra stuff in /usr/local (sometimes the executable is in /usr/local/bin, sometimes in /usr/local//bin).
/usr.
/usr/local. It can be done, and keeps things tidy and clean.
403
~> ls
36
~> ls
91
~> ls
220
~> ls
796
This is FreeBSD, which installs a relatively clean OS under
I like that much more, it is the old UNIX way to separate the essential OS from optional stuff. It really is a pity that most Linux distro's dump everything directly in
As for my slackware, I installed only the minimum, and roll my own packages for everything I consider not to be 'core Linux'; all these packages go under
And then you get into naming conflicts down the road.. MS has this problem now, and is dealing with it partly with the new fandangled "Private Packages" or whatever in XP.. Basically unsharing shared libraries.. There DOES need to be separation that can be controlled more than it can be now, or we are going to see problems in the future. Have you ever installed a package and a file was already there? Were they the same file? Do you know? Version? Its a bad idea to clump everything together... what we need is to make a path statement extension, that basically says /usr/bin/*/ to allow everything one directory down, OR, allow packages to register their own paths in their install directories (ie, a file that gets installed and then pointed to to say "search here for executables as well"). Make it an config in /etc that points to these other little files that contain places to look, then at boot time enumerate that all out and make a tree of the executables.. fast and easy to manage..
Jay
"What's this script do? unzip ; touch ; finger ; mount ; gasp ; yes ; umount ; sleep Hint for the answer: not everyth
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 wish Unix/Linux had a mechanism where a directory could be marked executable and executing the directory whould internally call some default dot file (such as .name_of_directory)within the directory, and some environmental variable (like $THIS_PATH) was set to the directory and passed to the application process.
Maintance for applications like these whould be a no-brainer. Just move the directory and all the associated preference files and whatnot travel with the app.
-Steve
-- Making computers see, hear, and think... http://www.componica.com/
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.
There's also a unique shared modules directory in the System folder.
This system is at least 10 to 15 years old (not sure Arthur was as modulable, though) and sure proved to be an excellent way to deal with this problem...
Trolling using another account since 2005.
The file systems on a Unix system make a lot of sense, when people use them correctly.
/usr/local but they put a single executable in /usr/local/bin so that you do not need to change your path.
/usr/bin. Other programs are spread about the file system in sensible locations or are user installed. Possibly the only directory that does not make a whole lot of sense is /usr/libexec (where most of the internet daemons are kept).
/bin for binaries needed to boot a corrupted system.
/sbin for system binaries needed to boot a system.
/usr/bin for userland binaries installed with the base system.
/usr/sbin for system binaries installed with the base system. The are not programs required to boot the system.
/usr/local/bin for locally installed user binaries such as minicom, mutt, or bitchx.
/usr/local/sbin for locally installed system binaries such as apache.
Large locally installed programs such as Word Perfect get installed in a sub directory of
FreeBSD has only about 400 programs in a complete
-sirket
From my .zshenv, works in .profile too. Could be used also for other path variables. Works for all Operating Systems with a reasonable Bourne Shell.
/usr/local/gcc-2.95.2/bin
/opt/kde/bin
/usr/lib/java/bin
/usr/X11R6/bin
/usr/local/samba/bin
/usr/local/ssl/bin
/usr/local/bin
/usr/local/bin/gnu
/usr/bin
/bin
/usr/local/sbin
/usr/sbin
/sbin
/usr/ucb
/usr/bin/X11
/usr/ccs/bin
export PATH
reset_path() {
NPATH=''
}
set_path() {
if [ -d "$1" ]; then
if [ -n "$NPATH" ]; then
NPATH="$NPATH:$1"
else
NPATH="$1"
fi
fi
}
reset_path
set_path $HOME/bin
set_path
set_path
set_path
set_path
set_path
set_path
set_path
set_path
set_path
set_path
set_path
set_path
set_path
set_path
set_path
set_path
PATH="$NPATH:."
unset reset_path set_path
I agree, Windows isn't the problem in the case of DLLs. It really is stupid for an uninstall routine to ask the user whether to delete a DLL. It seems it should either know that it's not needed by any other program, or leave it alone. Asking the user (and really think about your typical Windows user) about deleting system files is a mistake. I've walked more friends and family through reinstalls after having uninstalled crappy shareware...
/usr/local/apache/* though it does tend to scatter a few things around. MySQL, Qmail, and a few others generally create subdirectories for most of their files. Not perfect, but it's a step in the right direction anyway.
.rpm any day. I do like *BSD's ports collection quite a bit, but on RedHat RPM is about the best we've got. RPM is fine for the initial install, and even for adding some system-level tools/packages/upgrades, but any major software instalation after that I prefer to install manually; and of course, this doesn't help the issue at hand one bit...
Unfortunately this practice is common thanks to InstallShield being used by so many programs, as InstallShield always asks before deleting a so-called "shared" DLL. Keep in mind, half of the time the DLL is program-specific (ie not shared), and other times it's something the program itself did not install in the first place (was already there). I don't think Windows itself is to blame here...
Win2k still suffers from this, but if you do delete a DLL it almost always magically reappears. It's part of some scheme to protect the system from its users I believe, but it is a real pain when you actually want to remove a DLL...
As for the Unix side, I've always wondered about the organisation (or lack thereof) of programs. Many tools do IMO belong in central locations (cat, grep, ls...) but anything larger should have its own directory. I long for the day when I can say:
export PATH=$PATH:/usr/programs/*/bin
or something to that effect...
Most of your larger packages do attempt to install into their own locations; Apache by default ends up with
I personally hate RPM, and I generally snag a tarball over an
Unfortunately, I have my complaints about filesystem standards, but I don't have any solutions either, really. Too much software exists that depends upon our current system, though a proposed future standard might be nice. Maybe a new POSIX recommendation is in order... and once some years go by, software vendors will slowly migrate to the new standard... of course I don't know what that standard might be...
NGWave - Fast Sound Editor for Windows
When you consider the /usr or /local was similar in purpose as "program files" (or progra~1 if you want to be specific) had the best of intentions.
Well we know about which road going where based on good intentions.
At any rate, part of the "problem" is there is a certatin point a section of the file system gets unmanageable. Where that is, quite frankly, varies.
RedHat has impressed me with its compatability but it does so with static libs. There are times when god forbid you should wish to compile something and get gripe messages that you window manager was done under X set of libs, your theme manager under Y's libs and your shared libs are of version Z.
That is just trying to update the WM, god forbid you wish to compile a kernel.
And with the static libs, the performance hit is astounding.
The other side, as with Slackware, is shared libraries can be as unforgiving as well.
Heh, as a newbie I deleted a link to a ld.so.X.
Hint: never, ever do this! ls, ln, mv et al stop working...oops.
Stupidity on my part, but, hey, I was a newbie. (finger; fire; burn; learn. simple.)
Back on track. Slack is fast, configurable but through sheer will, accident, or stupidity can be broken a lot faster (and in some cases fixed a lot faster).
Windows...well the sword cuts both ways. It impresses and suffers *both* of the good and bad points of RH/SL (or static and dynamic libs).
And, if the above does not either blow your mind or make you nod off consider OS X.1.1 (.1.1.1....)
Under OS X's packages system a 'binary/folder/application' (oye) can and does contain static libs. Ok, that can be good/bad.
Here is the kicker (and cool part): if it finds *better* or more *up to date* libs it can use them and ignore what *it* has.
If the new libs break the app, or cause problems, the application can be "told" or "made" to use only its own libs, or update the newer libs.
Most will see where that is going. It will be good to keep "static" then use "dynamic" or update the "dynamic/shared" libs.
The down side is the potential to fix one application and break 10+ others.
This has not happened...yet. However, the *ability* to make or break is there, just no information is given until a spec/CVS set of rules is fleshed out.
I will be the first to admit that the "binary folder" or "fat binary" (arstechnica.com article) idea sounded "less than thrilling"...until you realize the headache's it cures with this kind of file system bloat.
Think about it: You have an app, that is really a folder, that you can't see inside/manipulate/fix/break unless you know how *and* have a reason to.
In all three cases there are limits to even the most intelligent of design. Knowing this truth is easy to accept. Finding where it lies and where it breaks down...that is another discussion.
If it is not on fire, it is a software problem.
While not perfect, it addressed the following issues:
1) separating O/S from "other" packages;
2) maintain a sane place to put different packages;
3) support the notion of linking to specific package directories from a common place to keep PATH small;
4) was compatible with a number of "traditional" conventions.
Of course, FHS 2.1 has this concept of the "operating system" files and "other files". Presumably the "operating system" is that which the distro bundler provides... so Red Hat would be free to put as much as it wants under /usr. But this causes a problem if you looks at a common standard base for several distros, like the LSB.
Do you have a "standard base" part, and a "distro part", and then a "local part"? Clearly what's needed is a hierarchical way of taking an existing "operating system" and customizing it to a "custom operating system". Right now, FHS allows this for distro bundler and end user, but there is no support for the process iterating.
Of course, my experience has been with FHS 2.1 and have since moved on to employment elsewhere, so perhaps the FHS addresses these issues.
You could've hired me.
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
QNX has a package filesystem like what you describe; it looks like it solves Mosfet's problem and keeps PATH simple.
While Red Hat is certainly a major offender, HP-UX 11.0 has device log files in the /etc hierarchy, and the runlevels are still under /sbin, and every "optional software" dumping ground ever invented (share, contrib, usr/local, opt, and more) as well as a totally brain-dead depot system that makes RPM look inspired.
/opt folder!
I've said it before - and I'm not the first or last to notice - HP-UX is a *train wreck* of a unix. HP puts Fibre Channel controllers that are necessary for the system to BOOT in the
--Charlie
The problem is when it DOESN'T just work.
:) glom ALL your files together in / with no problem. When you mount another file system, all the files within that system are added to the pile in /. Why not do that? Because there are benefits to a hierarchical file structure. There are benefits to hierarchies at every level, though it is possible to take it to an extreme.
/. The problem is when something breaks and a HUMAN BEING has to analyze what's on the system. This is less of a problem on hackers' personal systems, used and administered by solitary individuals at their own whim, than it is on a business server, used and administered by many. You want as much as possible of your system to be obvious to human eyeballs when most everything on the system is broken.
You could theoretically (and actually, too, since you've got the sources
If everything works, there's actually no problem in glomming everything together in
This, BTW, is why I am fundamentally morally opposed to binary storage of configuration data (a la the win32 registry) versus plain-text storage. Binary is easier for the computer to handle, which is great as long as things work. Plain text is easier for me to handle, which is useful only when things break. Since the computer can work with either, plain text is preferable.
When things break, I must have the ability to go from zero knowledge about a broken system's configuration to a fully functional system as quickly as possible. Well-organized files that take full advantage of a hierarchical file structure, and plain-text config files, are much helpful in this situation.
(It just occurred to me that referring to the root directory as "/" at the end of a sentence produces an ambigous symbol; suffice to say I don't mean slashdot.org by "/.")
IF everything always worked, there would be no advantage to . You could eliminate the path statem