Rage Against the File System Standard 612
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?
Why not go the extra step (Score:2, Insightful)
Who in their right mind places stuff outside of a program specific folder, if it's not gonna be used in multiple programs (like shared libraries)?
Still new to GNU/Linux (Score:2, Interesting)
I would think that even without a package handler to do it for me, the program itself would allow me to say where it should be installed...or is that just the Windows user in me talking?
The Alternative? (Score:4, Redundant)
Mike
Re:The Alternative? (Score:2, Interesting)
Re:The Alternative? (Score:5, Insightful)
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.
Re:The Alternative? (Score:4, Informative)
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.
Re:The Alternative? (Score:3, Interesting)
Or you could do what DJB does with
Re:The Alternative? (Score:5, Insightful)
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?
Re:The Alternative? No Alternative! (Score:2, Interesting)
Re:The Alternative? No Alternative! (Score:5, Informative)
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...)
Re:The Alternative? (Score:5, Informative)
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
Re:The Alternative? (Score:2, Informative)
http://pack.sunsite.dk/
Look at opt_depot (Score:4, Informative)
Many years ago, we wrote a set of Perl utilities for automating symlink maintenance called opt_depot [utexas.edu].
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.
Re:The Alternative? (Score:3, Informative)
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_
/
Why package management sucks (Score:5, Interesting)
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.
Re:Why package management sucks (Score:3, Informative)
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.
Re:The Alternative? (Score:2)
Re:The Alternative? (Score:3, Informative)
Re:The Alternative? (Score:4, Insightful)
Mosfet's not talking about a new directory for every little application. He's talking about moving out stuff like KDE and GNOME. So instead of just having /usr/bin in your $PATH, you would also include /opt/gnome/bin and/or /opt/kde/bin. Yes, this makes your path a bit larger, but unmanagable? Hardly.
I just checked on one of my PCs that has KDE2 installed (from the RH 7.2 RPMs), and there are over 200 files that match /usr/bin/k*. The only one that wasn't a part of KDE was ksh. My /usr/bin has 1948 files in it. There's a 10% reduction with one change. I don't have GNOME installed on this box, so a similar comparison isn't really possible. However, I imagine that the number would be similar if not greater for GNOME.
It's not like he's suggesting we sacrifice goats in the street. He's suggesting we actually implement what the FSS says.
Re:The Alternative? (Score:3, Informative)
/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
better command path system? (Score:3, Insightful)
I don't have a solution, but i'll devote a few idle cycles to it...
Re:better command path system? (Score:2)
oh yes, this is the way to go. Hundreds of applications, each storing different versions of the same needed system or application dll's in one dir, overwriting the one version that worked....
</sarcasm>
There is a reason that binaries are spread over different partitions on Real Operating Systems....
:-)
btw, it's nice to see that html-formatting is actually making sense in my first line..: <br><br>
Re:better command path system? (Score:3, Insightful)
PATH="$PATH
This would look in
Of course this adds the problem of ordering (/opt/a/bin/foo vs.
Re:better command path system? (Score:2)
C:\WINDOWS\COMMAND (9x)
C:\WINNT\SYSTEM32 (NT)
he's pretty far off base (Score:5, Interesting)
It's not about lazy distributors. It's about administrators who are used to doing things this way and distributors going along with tradition.
Re:he's pretty far off base (Score:2, Funny)
Re:he's pretty far off base (Score:3, Interesting)
Agreed, but does that make it right?
For the last few years, this is the kind of thing that has really been nagging me. All OSes seem to suffer from the same problem. Why are we so stuck with the mindset that traditions of the past shouldn't be challenged? Can't we, as "brilliant" computer scientist, start solving these problems and move on?
I recently demo'ed a good Linux distro to a friend and it finally dawned on me. When you load KDE, you are literally overwhelmed with options. My friend asked, "What is the difference between tools and utilities?". I didn't know. I tried to show him StarOffice and it took me a few minuets of digging in different menus.
No, I don't use Linux on a daily basis, and no, I'm not the smartest person in the world. But I think I see the problem. Everything seems to be an imitation of something else (with more bells and whistles). Where is the true innovation? Our computers and software are not significantly different than they were 20 years ago.
Why are we still using $PATH?
Re:he's pretty far off base (Score:5, Informative)
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.
Yup, HP-UX is much worse. (Score:3, Interesting)
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
I think it is better... (Score:5, Insightful)
Re:I think it is better... (Score:2)
It's true that having all the files associated with a given package in a single location makes it easy to see what-all you've got and which files belong to which package, but you'll still require something that will clean up all the symlinks that point off to nowhere.
Re:I think it is better... (Score:3, Insightful)
Re:I think it is better... (Score:5, Informative)
another tool: graft (Score:3, Informative)
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
Re:I think it is better... (Score:2)
A combination of "ls -l", "cut" and grepping for the subfolder you just "rm -rf"'d fed into "rm" perhaps? It shouldn't be too difficult to work out the regexp to sort out the "symlink -> target" bit at the end, but it's late in my day, so I'll leave that as an exercise for the reader... ;)
Re:I think it is better... (Score:2)
Each application would have its own tree and could have bin, sbin, lib and/or other directories.
These directories would be marked or registered so that they would appear as if they were part of
Re:I think it is better... (Score:2)
sounds like Encap (Score:5, Informative)
You want the Encap package management system [uiuc.edu]. From the FAQ [uiuc.edu]:
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.Re:sounds like Encap (Score:3, Informative)
There have actually been many, many implementations of this basic idea, each with their own frills and features. I have a comprehensive listing of these programs on our opt_depot [utexas.edu] page.
Take a look, if you're interested in that sort of thing.. I can think of relatively few ideas that have been implemented and re-implemented so many times.
Package Management (Score:4, Insightful)
DOS put programs in different folders because there was no other way to tell what package the software belonged to.
Re:Package Management (Score:3, Interesting)
Jay
Re:Package Management (Score:2)
Re:Dumb Dumb Dumb (Score:3, Insightful)
Shared libs are not only about wasting disk space (which we usually have plenty of). They're much more gained from them, namely sharing RAM by mapping common code pages into different processes' address spaces.
Think if you had a duplicate libc in every damned process running in a system.
because unix is unix (Score:2, Insightful)
Linux From Scratch (Score:4, Interesting)
Response (Score:3, Insightful)
And you should, normally. If you system installs binutils as an RPM, DEB, Sun/HP/SGI package, well, you _should_ use the package manage to upgrade/remove. After all, if you don't, you're going to start breaking your dependencies for other packages. That's why package managers exist!
In some respects, Linux is better than many commercial unices. SGI uses
I agree that there should be a new, standard directory structure, but I disagree that every package in the world should have its own directory. If you're using a decent package manager, included with ANY distro or commercial/free Unix variant, there's little need to do so.
Re:Response (Score:3, Insightful)
Ok, we all hate windows, but spreading FUD is useless, and makes you look as bad as they do. Every windows app I have _EVER_ uninstalled (and there has been alot!) _ALWAYS_ says something along the lines of "This is a shared DLL. The registry indicates no other programs are using it. I will delete it now unless you say otherwise". This sounds pretty much like it knows whats being used and what isn't. Unless you get your registry corrupted, which wouldn't be any different from having your package database (RPM or dpkg) corrupted.
Re:Response (Score:3, Interesting)
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...
hmmmm.... (Score:3, Informative)
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.
the BeOS filesystem (Score:5, Insightful)
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.
Everyone's guilty, noone has a solution. (Score:3, Insightful)
Limiting bad organisation to Red Hat is silly. The only Linux distros I've tried are Red Hat and Mandrake, both of which are equally poor in this regard. Nor, I have to say, does the FSS make it any easier to organise a hard drive properly. Is the
The whole
It's impossible to have a perfectly organised hard disk, of course. You can't fight entropy.
Ah, yes... (Score:5, Funny)
/opt/LINWsed/bin/sed
/opt/LINWdate/bin/date....
Why? (Score:5, Insightful)
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.
Re:Why? (Score:3, Insightful)
RPM and DPKG know every single file that was installed, and will remove every single file that was installed. And it actually keeps a database of dependencies so it won't let you uninstall a program if another program depends on it.
In the windows world, a program has the option of having an uninstall available. But from what I can tell it's really just a cheesy hack to get uninstall features without going through the work to setup a nice package manager. It seems to just have a list of the files it supposively installed and then mark some as shared and then uninstall the programs and ask the user if they want to uninstall the shared files, with no knowledge of whether or not they're being used by other programs.
That's why we don't need subdirectories for programs. Although it probably wouldn't be a bad thing because it would help people find global config files and stuff for programs. But really, if you know how to use RPM and DPKG there isn't a need, as you can ask it what the files are that belong to a program and other things.
Re:Why? (Score:3, Interesting)
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
Use /usr/local for add-ons, keep /usr clean (Score:4, Interesting)
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
Have a directory standard for applications. (Score:2)
This keeps all the application files in one directory. If you want to remove an application, you just rm -rf that one directory. Upgrading applications is much simpler since you just point to that one dir and put the files there. You can also have multiple versions of an application installed just by renaming their root directory.
Applications shouldn't spread themselves all over the system, they should be placed in one spot with a specific directory structure and be moduler to the rest of the system.
Tradeoffs/union fs (Score:2, Insightful)
Also, the question is how should the files be arranged? By type (bin, share/bin, lib, etc) or by package?
In Linux (redhat/FSSTD), the emphasis was placed on arranging files by type, and the file management was declared a separate problem with rpm (or other package managers) as a solution.
There is another solution which combines best points of each:
Install each package under
Unfortunately, unionfs never worked on linux, and on other operating systems its very tricky. (Such as, how do you ensure that underlying directories will not have files with same name? And if they do, which one will be visible? What do you do when a file is deleted? etc).
Translucent file system (Score:5, Interesting)
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.
Re:Translucent file system (Score:3, Funny)
Wait until KDE 3 / Gnome 2 com out with Xrender suport, and we can all have translucent filesystems!
HAR HAR!
QNX has it (Score:3, Interesting)
Re:Translucent file system (Score:5, Interesting)
DESCRIPTION
The mount_union command attaches directory above uniondir in such a way
that the contents of both directory trees remain visible. By default,
directory becomes the upper layer and uniondir becomes the lower layer.
Non-FreeBSD users can read an online version [freebsd.org].
Re:Translucent file system (Score:3, Interesting)
It's my impression that recent developments in the Linux kernel (along with bind mounts [ibm.com], etc.) are moving towards making this easy to implement.
Re:Translucent file system (Score:3, Informative)
Re:Translucent file system (Score:3, Interesting)
Re:Translucent file system (Score:3, Informative)
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 [bell-labs.com]
I wish unix had this... (Score:3, Interesting)
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
Related to yesterday's story (Score:5, Interesting)
I think the fundamental problem here is related to yesterday's story about new user interfaces [slashdot.org]. 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
Re:Related to yesterday's story (Score:2)
Isn't this what symbolic links are for...?
Re:Related to yesterday's story (Score:5, Interesting)
I think the fundamental problem here is related to yesterday's story about new user interfaces [slashdot.org] [slashdot.org]. It's a problem of how and where storing our files.
You could also trace it back to the hierarchical database article [slashdot.org], which is when I started making a lot of posts on the subject. It seems there is finally a lot of interest being generated about this sort of thing.
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.
This is exactly the sort of thing I'm doing with my Meta Object Manager (MOM) software called Mary. Metadata in the form of attributes and values is associated with each file/object and you can do a query (both textually and graphically) on that metadata. For simple paths like you describe, it is a value query irrespective of a particular attribute, but there is support for a more structured "path" (I actually call it a "focus" as it restricts your focus to a subset of the objects on the system) like /type=picture/location=Hawaii/year=2000. Because the focus items are metadata attributes, order is not significant. With such a system, there are no directories or symbolic links; it's all dynamically structured based on what your metadata focus is at any particular time.
Mary is just in the alpha stages at this point, but it already works well on the command line for the type of things you describe and I'm using it myself to manage nearly 350,000 objects that have been flowing through my system. I'm not exactly sure when it'll be ready for public consumption, and it'll require a GNUstep [gnustep.org] port to get working on Linux (I'm doing development on Mac OS X) systems. I was hoping year end, but I don't think I'll have the time. Summer 2002 has a nice ring to it, though. :-)
Re:Related to yesterday's story (Score:3, Insightful)
I've been hacking with this idea in my head. It seems to make the most sense. It is a sort-of multidimensional file system, where every file has to be placed in the dimensions in which it belongs. The tree is used only as a single representation of a single dimension.
There are three reasons I can think for this.
I figure if MS does something like this, it would save them from their drive-letter hell, and solve one of their greatest disadvantages when compared to UNIX... the impact to such a scheme to UNIX would be minimal.
Database systems would probably be the best place to start looking for methods to do this sort of thing.
Keeping one applications files in one place (Score:5, Informative)
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 [sourceforge.net]. 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
RiscOS... (Score:4, Interesting)
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...
Um, so? (Score:3, Informative)
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.
Six of one... (Score:2, Insightful)
UNIX is a mess in multiple ways (Score:4, Troll)
To sum it up UNIX programs all have their own sets of parameters, their own semantics for those parameters, their own config files with their own syntax. Generally a program's related files are scattered through out the system. Just making things consistent would hugely improve usability of unix and reduce system administrator training cost. Most of the art of maintaining a unix system goes into memorizing commandline parameters, configuration file locations and syntax and endless man pages. Basically the ideal system administrator is not to bright (after all it is quite simple work), can work very precise, and has memorized every manpage he ever encountered. The not to bright part is essential because otherwise he'll get a good job offer and he'll be gone in no time.
Here's a sample better solution for the problem (inspired by mac os X packages): give each app its very own directory structure with e.g. the directories bin, man, etc for binaries, documentation and configuration. In the root of each package specify a meta information file (preferably xml based) with information about how to integrate the program with the system (e.g. commands that should be in the path, menu items, etc.). Standardize this format and make sure that the OS automatically integrates the program (i.e. adds the menu items, adds the right binaries to a global path, integrates the documentation with the help system). Of course you can elaborate greatly on these concepts but the result would be that you no longer need package managers except perhaps for assisting with configuration.
I read this last night... (Score:2, Interesting)
I came away thinking "this man is insane".
He claims DOS had a better way of organizing applications. This is a red herring. I don't want to organize my applications. Ever. I want to organize my data. I don't remember many applications in DOS that were compatible with the same type of data. If there had been, the limitations of the DOS structure would have been readily made apparent. First, CD into the directory where your audio recording utility is and make a .wav file. Then, move the .wav file into the directory where your audio editing utility is and edit it. It works, but why not keep the data in one place and run programs on it as you see fit without regard for their location on your hard drive, and without having a 10-second seek through your PATH variable?
Besides which, DOS had c:\msdos50 (or whichever version you used). That was DOS's variation on /bin. Ever look in that directory and attempt to hand-reduce the number of binaries in it to save disk space? I did. A package management system would have made that doable.
You can have all the localized application directories you want in /usr/local. The point of /usr/local is to hold larger packages which are local to the system. (hmm... /usr/local/games/UnrealTournament, /usr/local/games/Quake3, /usr/local/games/Terminus, /usr/local/games/RT2...) And as a bonus, thanks to the miracle of symbolic links you can have your cake and eat it too - as long as the application knows where the data files are installed you can make a symlink of the binary to /usr/local/bin and run it without editing your PATH variable too! Isn't UNIX grand?
Don't install so much stuff! (Score:3)
Many distributions install lots of packages you don't need nowadays. Uninstall some, or switch to a more minimalist distribution. Try installing debian with only the base packages. Then whenever you need a program you don't have, apt-get it. It'll make for an annoying few weeks perhaps, but at the end you'll have a system with just what you need on it. I'll bet you will end up with only around 600 binaries in the end (Unless you install gnome... That's like 600 binaries on it's own.)
What does it matter anyway? If you have 1500 programs it's no better to have them in their own directories then to have them in one place. Also, it's not like you're dealing with all of them at once.
Hierarchy (Score:3)
There probably is no way to solve all of the issues simultaneously in one hierachical scheme. Symlinks could help because they crosslink the tree. Package managers add a more sophisticated database of relations. These relations are much more useful, but unfortunately are accessible only through the package manager program.
All in all, though, it seems that organizing by package makes the most intuitive sense, and the helpers like package managers should be responsible for figuring out how to run the app when you type it on the command line.
the problem is deeper (Score:2)
2. this needs to include all the files in /etc so app installers need to support flexible package management. Also note, the #!/shebang is totally broken in this sort of environment.
3. "the canonical places" (/usr, /etc, etc. :) should be a family of canonical places. The sysadmin group might not want to upgrade their perl scripts at the same time as the dbadmin group. decoupling their interdependency will lead to much more flexibility and quicker overall upgrading.
4. we can achieve this best if / is no longer / but is instead /root so there could be a /root1 and /root2 . Think of this, one file system containing two different distros that don't wrassle with one another.
do not evaluate this on whether you think it's a good idea. the point is that software allows soft parameterization, reentrency, soft configuration, etc. So, why can't we have it? Programmers need to stop hard coding shit, binding locations to one place.
I'd love to upgrade my workstation from RedHat 7.1 to RedHat 7.2 by installing onto the same partition without trashing the old. Then, over the course of the week I could work out the kinks and delete the old, knowing that at any time I could reboot the old to send a fax or whatever. There are 1000s of corporate uses for this type of environment too... how many times have you heard "we're taking the mailserver down to upgrade it overnight" and then heard "um... it didn't come back up..."
Recursive PATH (Score:2)
With package management software, who cares if it's all in one place? That's fine with me...
Besides, anything *I* add to the system, depending, usually ends up in /usr/local - which is a further distinction.
KDE binaries in /usr/bin (Score:2)
One workaround to remain LSB-compliant and still having them separated would be throwing them on /usr/lib/kde2 and /usr/lib/kde3 -- but it's an ugly hack. But so is arbitrarily breaking the standard and placing them in the correct place. Ugh.
So, what's the reason to do this again? (Score:2, Informative)
As for the rest of the rant, to simply call the current practice of file organization horrendous behavior, sloppiness, or laziness without ample argument or demonstrable advantages as to why breaking every package into separate sub directories is damaging to the cause at best. Had the rant contained any sort of claim that there are an unacceptable number of name space clashes, that simply doing an 'ls' in one of these directories blew away the file name cache mechanisms in the kernel, forever making certain optimizations useless, or anything of that sort would hold more weight than unsupported bashing.
The author laments the inability to manage these subdirectories effectively with standard tools, but as I see it, the option to not use package management has been there all along. Roll your own, putting things where you want them. Or, I might suggest broadening the concept of 'standard tools' to include the package management system installed, should the former option seem ludicrous.
Not having to muck around with the PATH - and moreso, not having to support users mucking around with their own PATHs - far outweighs the disadvantages of not being able to use 'standard tools'. What time I lose learning and using my package management system I make up tenfold in not supporting the very issues which I forsee the author's solution creating.
--Rana
Re: (Score:2)
FreeBSD (Score:4, Interesting)
/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
My take. (Score:2)
/sbin contains stuff that requires superuser priveleges. Stuff specific to maintaining the hardware, etc.
/bin contains solid, standard system binaries need to work (bash, grep, chmod, z-tools, gzip, etc). Stuff that you basically need.
/usr/bin/ contains... userland stuff. software installed/removed for general use.. I don't know the right way to describe it.
/usr/local/bin.. contains nothing. This is where, generally, I choose to put things I compile myself, so as not to confuse the package management system.
If we look at
/usr/bin for different OSen (Score:2, Informative)
% ls -l
258
On an OpenBSD 2.8 server, minimal install + gcc stuff:
$ ls -l
344
On an OpenBSD 2.8 server, full install (including X):
$ ls -l
373
On a Mandrake 8.0 server:
$ ls -l
1136
On a RedHat 7.1 system with a fairly typical installation:
$ ls -l
2203
I want
It seems to mean that there's a lot of overlap/duplication in the tool set on Linux distributions versus the centralized managed BSD distributions. A crowded
Not that I'm saying I disagree with "choice is good"
How to handle PATH... (Score:3, Interesting)
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
Clueless... (Score:3, Insightful)
This is another classic example of not letting programmers, especially GUI progrmmers, be involved in OS design.
For those of you who might be swayed by his foolish arguemnts, please read LHS, and the last decade of USENIX papers and LISA papers. Unix systems organization has been openly and vigorously debated for 15years. It has not be dictated by mere programmers from high on above like MS. And RedHat is to be applauded for properly implementing the FHS which is a standard, others like SUSE should be encouraged to become compliant (/sbin/init.d
I have played both sides of this arg (Score:5, Insightful)
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.
# rm -ff /usr/bin (Score:3, Informative)
Unless you are hand writing each file in
And Windows !=
Program Files ==
In some respects, I agree. (Score:3, Interesting)
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.
FHS 2.x - Filesystem Hierarchy System (Score:3, Interesting)
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.
Why windows doesnt... (Score:5, Funny)
So now my windows Start menu has 1000 items in it, but at least they are arranged hierarchically in 850 vendor program groups...
Baz
I think he's is quite correct (Score:3, Informative)
This is one of the reasons I created Beehive Linux [www.beehive.nutargetnew]. 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
He missed a major point of the FSS (Score:3, Insightful)
- systems may need a small partition with all files needed to boot
- configuration files need to be on a RW filesystem, while executables can be RO.
- many other reasons (read the FSS)
That doesn't mean all executables need to be in a single directory under /usr/bin. I agree it would be nice to come up with a good way to allow subdirectories and change the FSS accordingly. Just don't argue that all files related to a given piece of software be in a single directory as some have requested. That will make the life of an administrator of large systems even more difficult. My wife works in a place that does that and their system is nearly impossible to maintain.
Sure the FSS isn't perfect, but I have yet to see another system that does as good a job. Don't throw it away simply because you don't understand it, or even worse, because its biggest fault is a directory with 2000 entries.
-- YAAC (Yet Another Anonymous Coward)
Look at the "modules" project (Score:3, Informative)
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.
Specialize! (Score:3, Insightful)
The biggest problem with Linux is, in my opinion, the fact that people try to solve all the problems of the world with a single solution. Red Hat is a worthwhile cause, but I don't think a single distro can handle every possible use of Linux. I thought Linux was about choice. In that case, there should be many smaller distributions aimed at specific (or at least more specific) purposes.
No, I'm not a luser, nor am I a newbie. I know that there are countless distros out there, which fit on a single floppy, six CDs, and everything in between. (I've purchased so many distributions for myself and for others that I'm drowning in Linux CDs.) But everybody and his uncle uses Red Hat. (I personally like SuSE a LOT better, because it is far better organized in my opinion.)
Many common problems make the file system layout and package management suck. I don't mean to start a flamewar, but this problem is far smaller on FreeBSD, where the file system layout is a lot better organized than that of a Red Hat Linux system. (It's even better organized than a SuSE system.) The ports and packages collection, which works through Makefiles, makes installation and removal of many programs very easy, with dependency checks. Unless I'm imagining things, it does find dependencies that you install manually, as long as they're where the system expects them. However, glitches still exist, mainly in the removal of software, that require user intervention to remove some remaining files and directories.
When it comes down to it, I think that package management systems--whether they're Debian's system, RPMs, or the *BSDs' ports and packages--are supposed to serve as a shortcut for the system administrator, who still knows how to manage programs manually. The Linux community seems to have forgotten this, and expect package management to be a flawless installation system for any user with any amount of experience. Unfortunately, this is not the case, and it would be extremely difficult, maybe impossible, to make such a system. I believe this doesn't matter.
Skilled admins need control and flexibility over their programs. This is especially true for critical servers, but also applies to workstations. If the setup they want can be achieved with a package manager, they'll use it. If not, they can opt to build the program from source, or, if this installation takes place often, they might make their own package, perhaps customizing paths or configuration files for site-specific purposes. A well-organized hierarchy is very important.
Novice users are very different. They just want to install this thing called Linux from the CD and surf the web or burn some MP3s. For them, the solution isn't a great package management system, because a novice user probably doesn't know where to obtain programs. In some cases, there are hundreds of similar programs to choose from--novices can't handle all that choice! The solution for them is a distro that supports a very specific set of programs, and supports them well:
Finally, I would recommend that in the spirit of giving back to the community, any admin who makes his own packages should submit them back to the developer for distribution to others. (Unless these packages are designed for site-specific purposes, of course.)
Oh yeah, and I almost forgot the obligatory "oh well."
Regarding paths... (Score:2)
The searchapth ($PATH) are just explicit directories.
I don't see what all the fuss is about though...
Re:To all those suggesting /opt/[applicatinon] etc (Score:3, Informative)
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 [utexas.edu] 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 [nih.gov] 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.