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?
and just install in /?
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)?
We do not live in the 21st century. We live in the 20 second century.
Is it really that bad? Would I not have much control over where programs get installed to?
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?
I have 3656.9 Bogomips. How many Bogomips do you have?
I'd much rather have 2000 binaries in /usr/bin than 2000 path entries in my $PATH
Mike
Tales from behind the Lagom Curtain
imo, we need a better command path system thingy that allows easier categorization of executables and other stuff... Win32 has the System32 (or System) directory, *nix has /usr/bin, /usr/share/bin, /usr/local/bin etc...
I don't have a solution, but i'll devote a few idle cycles to it...
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
...makes this unnecessary. When I can use RPM to verify the purpose and integrity of every binary in /usr/bin, I don't see a need for separating software into a meaningless directory structure.
DOS put programs in different folders because there was no other way to tell what package the software belonged to.
in the dark old unixish days whenever you bought a bit of commercial software (remember that? buying? :) it'd install itself into /usr/local/daftname/ or /opt/daftname/ or somewhere. This meant there'd be a huge path variable to manage which was a nightmare.
The reason the windows equivalent isn't a problem is that windows is not commandline based - users access peograms through a link in a start menu (gross oversimplification but you get the idea). This simply doesn't translate to the command line paradigm.
So a simple answer - nice path variables, neat directory structures, usable command line interfaces, pick any two.
~mocktor
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.
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.
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
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
This is somewhat parallel to the situation common in Windows, where every new application tries to place its shortcuts in a separate folder off Start Menu/Programs. It's common to see start menus that take up two screens or more, whereas everything could be found much faster if properly categorised. MS made things worse in Win98 by having the menu nonalphabetical by default.
/usr/local distinction useful, for example? Wouldn't it make more sense to have a setup like /usr/apps, /usr/utils, /usr/games, /usr/wm, and so on - to categorise items by their function, rather than by who compiled them?
/home thing is equally confusing to a Windows migrant. Yes, *nix is a multi-user OS. But is that a useful feature for the majority of home users? Providing irrelevant directories is a sure-fire way to confusion.
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.
/opt/LINWgrep/bin/grep
/opt/LINWsed/bin/sed
/opt/LINWdate/bin/date....
Uh huh. And when something goes terribly wrong, how do you determine what went wrong? Our production servers (HPUX, Solaris, AIX) have in the /usr/* only what the system supplied. Everything else gets put in it's "proper place"- either /opt/, or /usr/local/ (it's own filesystem) or similar.
The paths are not so bad- and the system is healty and clean.
The alternative? A system easily attacked with a trojan horse.
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.
~> 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
Have a standard directory structure for every application. Put all the applications in /opt then require every application to have the subdirectory /bin so if you want to find the binaries of all applications you look through all the /opt/[app name]/bin directories. You could also have other dirs like /opt/[app name]/lib for libraries, etc... You don't need to know the specific name of each application to search all the /bin dirs, you just open /opt and get a list of the directories, then append /bin to all the names and try and open those, then search in those for the binaries.
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.
Outdoor digital photography, mostly in New Engl
Here, the tradeoff is being able to quickly determine the files belonging to a particular package/software vs time spent managing PATH/LD_LIBRARY_PATH and all sorts of other entries.
/opt/packagename. Then, use unionfs to join all /opt/packagename's under /usr tree. Thus, you still will be able to figure out which package has which files without using any package manager, but at same time, you are provided unified view of all packages installed.
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).
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.
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.
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.
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.
Half a dozen of the other. Of course there are pros/cons to both way; having all executeables in one (or O(1)) location/s makes finding programs also O(1), and a PATH length of O(1). Having one dir/"folder" for each program (or O(X) directories) would then have O(X) search time for a particular program, and O(X) entries in your PATH. On the other hand, finding and deleting entire packages becomes much harder if not all filenames belonging to that package are known. Personally I think it it doesn't matter either way.
Moderation: Put your hand inside the puppet head!
This is only part of the problem and characteristic for the way unix has evolved. The whole problem is that there are no standards, just conventions which most unix programmers are only partly aware of. I imagine the whole reason for putting all binaries in a single directory was that you then only have to add one directory to the path variable. In other words because of genuine lazyness you have around 2000 executables in your /usr/bin directory. Of course adding all 2000 programs to the path is not the right solution either (that would be moving the problem rather than solving it). Obviously the path variable itself is not a very scalable solution and needs to be reconsidered.
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.
Jilles
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?
In post-9/11 America, the CIA interrogates YOU!
How many of those 1500 binaries do you run, hmm?
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.
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.
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..."
No.. subdirectories are NOT included.
The searchapth ($PATH) are just explicit directories.
I don't see what all the fuss is about though...
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.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.
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.
To pick nits a touch, the reason X got its own sub directory was that it was often on a separate file system from the rest of /usr. In the long, long ago X was of such astounding size relative to the limited and expensive disk space of the day that special considerations had to be made upon its installation. It had little to do with any other sort of organization.
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
Last night, when I installed the Wolfenstein test, it put it all under /usr/local/games/wolf and made symlinks to /usr/bin for the executables. I wish more apps did that.
Imagine every app installed on your machine did this... so much more manageable....
Need Free Juniper/NetScreen Support? JuniperForum
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
Well...looking at my Debian system...
,say, systems where many things are mounted over nfs.. /usr/bin is one of these. /usr/local/bin is for things local to your machine.
/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
On a Secure Computing Sidewinder (BSD based): /usr/bin | wc -l
/usr/bin | wc -l
/usr/bin | wc -l
/usr/bin | wc -l
/usr/bin | wc -l
/opt (with subdir's per app) back ;-)
/usr/bin might be a consequence of the "choice is good" Linux philosophy.
...
% 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"
"The purpose of argument is to change the nature of truth." -- Bene Gesserit Precept
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
A package manager exists for Windows, it is called MSI. It is not very sophisticated and sometimes even stupid, but it works most of the time. It allows repair, uninstall and rollback of applications. Windows XP has an additional feature called System Restore that couples with MSI so that it allows driver rollback and return to a given restore point without destroying user documents.
¦ ©® ±
Have you actually had to manage a system that works like this? It's a royal pain in the ass.
Seriously.. what problems do people actually have with, say, the way debian organizes files now? Can anyone state a real-life issue and how a different system would make it better?
From all the unixes I've used, I've found, so-far, that debian is by far the easiest one to keep clean; but admin styles differ.. that could just be me.
The one comment I really dig was the one regarding translucent filesystems... I could actually see that working.
No package manager in Windows? That's funny.. because I find lately that every install I use uses InstallShield or some other similar tool, and windows lets me remove things via Add/Remove programs.
Now.. it's not exactly dpkg/apt, of course...
But it IS a package manager.
Mosfet is a emotionally unstable GUI hacker. His knowlege of the long history and tradition of UNIX administration is pathetic. He ignores simple observables like PATH searches are more expensive than bin lookups. One executable dir per App would be FAR SLOWER than 2000 executables in a single dir.
... mindless infidels :).
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 am not a fanatic, I am a true believer.
I absolutely agree! I think that the .app bundle model is a great way to group all the necessary files into on opaque folder, and .framework bundles for grouping libs. I would also like to see a push to something like this:
/Applications - All progs, GUI and CLI
/bin - All commandline progs for all users (hidden from normal
/sbin - All commandline progs for su only
~/Applications - holds symlinks to GUI apps you like/use
~/.bin - holds symlinks to commandline progs you like/use (hidden in file manager)
~/.sbin - like ~/.bin, but only created in root's (or other su's) home dir (hidden in file manager)
so a normal user would only need ~/.bin on his/her PATH, and root or other su would have ~/.bin AND ~/.sbin in his/her PATH
But thats just my opinion, I could be wrong =]
"I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
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
having 2000 entries in /usr/bin, just so long as they are executables that do not require dependencies, or libraries that are too specific for the task. When applications grow bigger, their dependencies on other things in the filesystem increase. They'll want an /etc entry, some icons here and there, specific libraries, development include files and so on. That's when the time comes to simply mkdir /usr/local/xxx and ./configure --prefix=/usr/local/xxx. After all that, you can still have symlinks in /usr/bin, but it won't matter, because when you rm -rf /usr/local/xxx, the symlinks go dead and you can remove them.
For "package-managing" stuff you compiled yourself, "stow" is really useful. Install all your apps in their own directory, like :
/usr/local/bin , lib, man..
/usr/local/* directories, but it's only links. To remove an application, just unstow it and then rm -rf the application directory.
/usr/local/apps/foo
/usr/local/apps/bar
and then use stow to create the relevant links to
You still end up with bloated
Another benefit is that you can keep several versions of the same app that way.
http://cr.yp.to/slash.html
it's not perfect, but it divides the filesystem (mostly) by maintainer - similarly to how packages are already deployed. but beyond that, it creates symlinks into one directory (in his example: /command) to keep $PATH sane.
package management _still_ makes my life easier- i don't like to hunt around packages manually. but if the filesystem mimicks the packages, we have solved the three biggest problems with package management at the same time:
i'm not saying don't use package management. i'm not saying don't use rpm. i'm actually agreeing with the topic for once and suggesting that we actually do need to change the filesystem.
Why not add in the ability to use subdirectories of dirs in the path variable. I propose use of \+ or something similar at the end of a directory entry to indicate subdirectories should be searched too.
It seems yesterday's article on next-generation user interfaces might be closely tied to this one.
On the other hand, having a $PATH with a gazillion entries just makes for faster searches, but you have to perform more of them. If the application you want is early in the PATH, it will be faster than with the 2000+ files in /bin. If the app is in the last item in your PATH, it will be slower.
There have been a couple of major points brough up in this debate:
Now (1) and (2) are good points to bear in mind ... but please, those who support (3), get a life and use Windows sometime.
The unofficial standard on Windows is to install applications in Program Files\\; which is far better even than just , as it allows vendors to structure their common files. Basically, locality is everything.
The problem with Windows is its library search mechanism: it looks in the .exe's directory, and windows\system32 (or winnt, as the case may be). i.e. Windows itself places a limitation on hierarchical structure because you can't dynamically specify library paths.
Now extend this to *nix, without the limitation: /, /usr, /usr/opt, /usr/local and /opt become your base locations into which stuff can be installed.
/ stays the same - essential binaries necessary for booting and recovery. /usr becomes all system utilities that are required and cannot be removed (unless you are seriously fiddling with the distribution). / and /usr keep the same structure as they currently have: none.
/usr/opt is the location for packages that come with the distribution, but are optional. Packages are grouped by "vendor", and then by "app" (read: group = directory). Binaries get symlinks into /usr/bin and libraries get sumlinks into /usr/lib.
/usr/local is for stuff you compile yourself. /opt is for third party applications that you install. They use the same vendor and app catagorisation, and have symlinks to /usr/local/bin, /usr/local/lib, /opt/bin and /opt/lib, as appropriate.
Of course at this point we should probably add that we should employ /var, /usr/var, /usr/local/var and /opt/var directories; as well as /etc, /usr/etc, /usr/local/etc and /opt/etc, all with symlinks to the relevant files in their proper locations.
And there you have it: hierarchical segregation for them all and symlinks to bind them.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
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
The reason a great many commands are in /usr/bin is because they are viewed as commands.. or small tools. It's the unix way. I *expect* them to be in /usr/bin; I don't WANT a different subdirectory for each individual file.
/usr/bin/fooap, and the config file will be /etc/fooap.something, or if there are more than one config file, /etc/fooap.something/
Comparing this to Windows using the Windows subdirectory is wrong; that truly WAS a mess.
But I *know* that, if I install a program called, say, fooapp, that the binary will be
Before (and after) reading this article, it occurred to me that I just don't see the problem the guy is getting at.
The /var directory used to be for files that are difficult to
backup to tape, because they varies too much (*see* that's the reason
for its name). A backup of /var used to be outdated after a few hours.
The print spool, the incoming and outgoing mail spool, pid and lock files and the man file cache are all files that changes rapidly, and in general does not need to be backed up every day. You need a backup of its directory structure in case of a disk crash, but doing a complete backup every night used to be a waste of time.
That is history. Now people wants to mount /usr read only, so they are slowly moving all
files that must stay on a RW file system from /usr to /var (eg. /var/www
for your web site). This is stupid, because you need to do a
backup of some directories in /var but not all. The grand idea of /var
is lost.
Please stop this trend before it is too late.
RFC1925
I think that he is missing the point.
One the aims of all the package management tools is to make the management easier. In particular this means, that you don't have to care, where are the files of application XYZ. So, if you wish to delete this, you ask your manager instead of finding all the subdirectories created by the package. You want to save your time, so you use the tools available. Era of manually managing everything is long gone.
Please note, that under Unices most of the applications are not installed in single directory - one is for binaries, one for documents, etc.
Under DOS and Windows, even the apps that went into their subdirectory had an annoing habbit of creating miscellaneous temporary/configuration files all over the place. And lack of file attributes did a lot to help this.
e-mail: karol at tls-technologies.com
www: http://www.tls-technologies.com
sig: not found
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.
I've been using Mandrake for a couple of years and hadn't noticed this problem. (RPMs provide some insulation) But I totally agree that its not the way things should be done. The biggest problem, as I see it is that it allows for no redundancy in the names of binaries. What if someone slips up and includes a filename in a package duplicating one already in /usr/bin. If its a new install I'll be alert enough to abort, but if its a re-install I'll assume it just didn't get cleaned up from the previous install and overwrite.
/usr/share/doc, does install each app in a separate directory...
Interestingly enough,
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
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
Is it me or does controversey always follow this guy around? :-)
He does make a good point but I think once the history of the file system evolution is taken into account, the layout makes sense. The problem is, not every distribution adheres to the fs layout unwritten rules for various reasons and the result is a mess.
Hopefully, the Linux Standards Base will help to address this.
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
- 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)
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
There is a package which does just that: GNU stow. I use that to organize /usr/local. Very easy to use.
You install each package under /usr/local/stow/<packagename>, and then you run stow <packagename> to make the links. After an upgrade, you do stow --restow <packagename>.
(To me, having all binaries in /usr/bin is not a problem: the package manager takes care of them. And stow is sufficient to handle the things I install locally.)
WWTTD?
addendum:
/Applications dir
while one could just make ~/.bin and ~/.sbin symlinks in and of themselves, or just use the original dirs on the PATH, with you own folder, you can install your own CLI progs in there, without contaminating the originals
same goes for ~/Applications... add symlinks, or real whole applications that you install and dont want to pollute the
"I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
"What is mind? No matter. What is matter? Nevermind."
XML is like violence. If it doesn't solve the problem, use more.
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
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
- /opt/package/foo is a link to
/opt/package/foo-1.2 ...
- and
/usr/local/bin/food is a link to /opt/package/foo/bin/food ...
- and you can re-generate
/usr/local/bin from scratch with a simple script when things change.
For our software , we also separate...I'm a bloodsucking fiend! Look at my outfit!
As far as I know, in windows there is no way to:
- output a complete list of what files belong to a package
- query a specific file to find out what package it belongs to
- list what other packages a package depends on
- list all other packages that depend on a given package
I am not nitpicking here. These are legitimate gripes.Check out the modified Unix style tree that BeOS uses
The whole (modified) Unix tree is inside a directory called 'BeOS', that only BeOS system upgrades from Be Inc touch.
Parrallel to 'BeOS' is 'home'. In home you can creat directories for whatever you want. a 'downloads' directory for downloads, with a 'apps', 'drivers' & 'shared files' inside, & inside 'shared files' you could have 'video' & 'music', inside 'video' you'd have 'porn', etc, etc
Parrallel to 'downloads', you can have a directory called 'installed apps', where you install aplications. If a file sharing program demands that its file sharing folder must be inside the program's install directory, that's no problem - you just symlink it to 'shared files' directory in the 'download' directory mentioned above.
Also inside 'home', you could creat a directory called 'installed drivers', where installed drivers go
This is where the beaty of BeOS file heirachy comes into play - also in 'home' is a 'config' directory which is a complet symlink mirror of the 'BeOS' Root directory, so if any apps need to load lib depencies, etc they load them here. As I said before the actually 'BeOS' directory only ever gets touched by BeInc system upgrades. So you need never go anywhere near the 'BeOS' directory. So one need never worry about WTF bin, lib, usr, etc, etc (:)) means.
It's not even close.
The windows uninstaller, as far as I know, provides no way for you to:
- list what files belong in a package
- for a given file, list what package that file belongs to
- list all other packages that a package depends on
- list all other packages that depend on a given package
Unix package managers do allow these things, so you can see exactly what it is doing and make sure that it works right.Also, in windows there is no centralized package management app -- Add/Remove programs pretends to give you central control, but behind the scenes it really just runs the uninstall app provided by the 3rd party vendor. In Unix, the situation is quite different -- there is a central program to manage packages (rpm on redhat, dpkg on debian, ports on BSD), and so there is no opportunity for lazy 3rd party developers to screw things up.
you see something like this:
n g/ about/see/spot/run/page1/paragraph1
/usr/local/bin/games/educational/for/kids/readi
(Yes, I suppose when I use turn signals *backing out* of the driveway does qualify as anal retentive).
If it is not on fire, it is a software problem.
Well if we're talking about this in terms of linux becoming a desktop OS. I don't think it matters.
/usr/bin is going to hold back the use of linux as a desktop OS is just stupid. There are things holding back linux, but that is not one of them. The users could care less, they want to manage the programs through graphical tools, and that's exactly what distros like Rehdat and Mandrake are giving them.
Every person I've ever met that uses windows and doesn't know much about computers (e.g. your ordinary desktop user). NEVER goes through the program files.
All they do is access programs from their start menu, uninstall them using the add/remove programs. And then go into my documents for their mp3/image/whatever files or sometimes just make directories on their desktop to hold them.
To say that the fact that we put all executables into
FiGZ.COM - A waste of perfectly good web space
No good reason? The reason stuff ended up in \Win(dows/NT)\System(32) was because, in order to get your program to work, you had to make sure that system files, common controls and third party controls were up to date. Prior to "side by side" bullshit, if you installed a DLL into the same directory as your executable, and it was used by another program, you could get interesting effects - eg Excel first and everything works, launch your prog first and Excel doesn't work. Reason? Older copies of the COM DLLs in your program's directory (severe slapping required for someone). Same applies to third party controls.
If the COM DLLs hadn't changed every 3 months (normally with the latest IE or Office) then you would never have to update the damn system files. SFP? Fucking brilliant solution to a problem which Microsoft created. I've been in charge of big shrink-wrapped stuff to go on MS OSes and, trust me, getting an installation which works is the hardest thing.
Oh well, I had some karma to burn.
This sig made only from recycled ASCII
Yeah, I totally agree. I'm having no problems with the current way. And he said he installs from source and puts programs where he wants them to be, so I'm not sure why he has a gripe.
/usr/local/kde/
My guess is that since he is the author of the High Performance Liquid theme for kde he has been getting a lot of emails from redhat users asking why when they just configured, make, and make installed it it didn't show up in KDE's configuration options. And the reason is probably he has it installing to
But I've seen RPM and DEBs of high performance liquid so he can just tell those users to install using them and problem solved.
I do see some advantages to having programs in their own directories though, such as being able to find a global configuration file for a program easily.
FiGZ.COM - A waste of perfectly good web space
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
Possessive its has no apostrophe.
The word it's, being a contraction of it is, has an apostrophe.
The word its, meaning belonging to it has no more apostrophes than his.
I know this is boring pedantry, which will be modded off topic. But the article in question misapostrophises its 9 (nine!) times, compared with 5 correct uses.
Because of it's openness, Linux is also self-repairing. Clutter in main directories is a real problem, and instead of ranting about it, at least one person went ahead and built a work-around, by writing "stow".
/usr/bin, /usr/lib, etc. directories into the right place. It destroys those links when you unstow, and minimizes link-count by putting the links in at as high a level as possible, and unlike package-maintenance schemes, doesn't rely on a package database, so there's no danger of it being incomplete or out of date.
This is a utility that allows you to put executables for packages where you like, and then automatically creates symlinks from the main
2*3*3*3*3*11*251
/opt is for external packages that are not part of your "core" system. Any third-party package (not from your distro) should definitely go here, although some distros make them damn near impossible to create with their standard tools. (Cluestick: maybe offical packages should never put stuff in /opt, but by the same measure unofficial packages should never put stuff into /usr/bin! Yet some distros have tools that make this nearly impossible.) Some vendors also put their official, but optional, packages in this directory.
/usr/local should also be under package management.)
/opt. If you have to package it yourself, put it in /usr/local. Another approach is to ask where you turn for updates. If it's another company, website, etc., put it in /opt. If it's Sue down the hall, put it in /usr/local. In both cases, if you distribute your package outside of your organization you (and they) should put the package under /opt.
/usr/local is for internal packages that are not distributed outside of your organization, for data files that don't fit anywhere else, etc. (Cluestick: see above. I'm also in the camp that says everything under
The line isn't always clear cut, but a good touchstone is the package management. If it's already packaged, put it in
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Ever heard about ./configure --prefix=/where/ever/you/like ? You have got the choice.. use rpm/dpkg or configure.
And, hm, about your lovely windows: do your apps ask you in which c:\windows\system32 they should put their dll trash?
As a longtime sysadmin, I use one big file system /usr/bin and drop everything in there. I hardly ever need to look inside /usr/bin.
Even if my pkg data gets trashed (and I am too foolish to mirror it), I at least know where to look for the programs: /usr/bin.
/usr/bin are, I feed the path to the pkg manager to find out. Why should I muck about with subdirs, huge $PATH's, and symlinks? In my experience, that makes a system too complex for one person to manage well, and every system's different paths figure into the management hassle.
/usr/subdir and using chmod, faclset for the rest of the day.
I've seen various postings and rants around technical sites looking for a 'new paradigm' to replace the file cabinet/desktop metaphor. Well, if we use the info in a system using pkgadd or RPM, it could be possible to ask the computer: 'any spreadsheet apps on this system?' Of course, the answer is only as good as the package maintainer's enclosed info, but it's an idea for a better way to manage a system, especially if you could add your own comments and keywords to your pkg database. Much better than 'find; cd; ls; strings.'
Look at how the Mac improved things with resource forks. I don't care where Excel is installed, because I open the _file_, not the app. If Excel is not installed, my Mac can still tell me it's an Excel file (whatever that is, but still, I know to ask the helpdesk for Excel).
On my UNIX systems, if I want to know what all those files in
If I need to secure an app from unauthorised users, I'd like to say 'set this installed package so that the owner is sybase, the users are fred and tony, and the only owner can use pkg manager to upgrade these files,' instead of poking around in
If you look at the history of RedHat, the manual I got for version 3 says that RPM was developed because more time was being spent maintaining a linux system than using it. Amen. When I started using RPM, I could manage much more software on many more machines than I could when I was using the old 'make, make install' method.
At my office, I never compile and install software with 'make install' scripts. I instead install it to a special chroot environment and build a Solaris pkg file from there. Then I can install, upgrade, or erase it from any of my 100 servers very easily. Add cfengine to the mix, and I can do it all from one server.
Are we sysadmins, or users? Thank goodness for package managers, I say. When I am dealing with executable binaries and shared libraries, I only want a file system to prevent corruption, provide security and fast i/o (and maybe give me historical views of itself, a la Clearcase, but that's a different thread). I want package managers to monitor installed software, unauthorised changes to binaries, new binaries that don't belong to a known package, and other management/security info. If you think of your computer as a file cabinet, it'll soon look as messy as your physical file cabinet. I like to think that as meta-data management improves, that will matter less and less.
QNX has a package filesystem like what you describe; it looks like it solves Mosfet's problem and keeps PATH simple.
Dump /opt. It is redundant philosophically to /usr/local for the most part. Each non-system addon app gets its own directory in /usr/local and the package manager/installer automatically creates a symlink in /usr/local/bin to the apps real binary in its own directory.
I still don't get /opt. Really. I see no logical or real difference to simply using /usr/local or, if you wish, stick it in its own directory in /usr. Instead of sticking files all over /usr or /usr/local everything specific to the app goes into its own /usr/ or /usr/local/ directory tree and symlinks are created in /usr/bin or /usr/local/bin. Path stays simple and you ALWAYS know where all the files for any app are.
In Bushworld, they struggle to keep church and state separate in Iraq as they increasingly merge the two in America.
Duh, this won't affect the average grandma using a computer for e-mail.
It's going to be one more reason that will prevent an advanced Windows user from switching to Linux. Of course there are a million other reasons as well.
But it's also a stumbling block for anybody that is serious about creating software for Linux if they are just going with the defacto standard of shoving everything into one folder. Why not put EVERYTHING in one folder then. It's just one of those things where it's not exciting enough for a developer to spend his time fixing it. That's another issue though.
My original comment wasn't meant to provide the magic solution as to why more people don't adopt Linux, it's a single piece of a 20,000 piece puzzle.
BTW, to the person that modded my original comment as a troll, grow up.
use epkg.
/usr/local, while the actual software is installed in its own subdirs. It's a compromise between keeping everything in their own subdirs and managing $PATH, and it works quite well. :-)
epkg has been around a while; it works by making symlinks in
Stating on Slashdot that I like cheese since 1997.
Why not store all files in some kind of root context, then augment them with attributes describing what type of file it is and what relationship it has to other files, and who is allowed to do what to it. That way everything is in the path (and I mean *everything*) but graphical filesystem browsers can organize things however they want by reading the file attributes.
You'd run into naming conflicts, but those can be resolved transparently by the filesystem. Think of it like a database with a multi-column key: the filename and it's path.
I use this method and it works nicely for binaries/paths. But it does not work well for shared libraries because ldconfig does not follow symbolic links. Currently I have to add each directory to /etc/ld.so.conf. Is there a good way round this?
Or am I just being stupid?
-K
Similarly, applications should look for their own resources anywhere in the indicated subtree, so that relative position within a package doesn't matter.
Perhaps the otehr BSD's do this, but I never use them. I like the fact that the package management, via /usr/ports and pkg_add puts all non-core, not part of the distribution in /usr/local.
/usr/www, /usr/java, /usr X11R6. My path rarely grows as that happens very rarely taht a new /usr dir is added.
/usr/local dir, all my installs on the base system are gone. I have a clean system again. with RPM, it screws up a bit, which I'm not too happy about, in terms of removing packages. A good rm -rf works wonders :)
Either that or for big things,
What I like best is if I just rm -r the
-s
-
ping -f 255.255.255.255 # if only
Well, duh. He wasn't suggesting that his password file is now /bin/passwd and his data sink is /bin/null and his POP3 spool was /bin/INBOX.
Yes, everything in /usr/bin is an executable. (Hence the bin, because they're all binaries.) That's true on every Unix.
And on most Unixes, /usr/bin is for core applications, graphical binaries go in (say) /usr/X11/bin, statically-linked binaries go in /usr/sbin or /sbin, etc. There is some breakdown based on the purpose of the executable.
But under Linux -- and I think this is what the complaint revolved around -- all of the X11 and other graphical things get dumped in /usr/bin under most distros. Including the "helper apps" that no user runs directly. It's a mess, it's a pain, and it slows down PATH hashing.
They seem to be forgetting what GNU's "libexec" directory is for, among other things.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
[[ First of all, note that it's not just the shell - the C library also makes use of $PATH in its execlp() and execvp() functions, so that would have to be updated as well. Not a problem, if you have the ear of a glibc developer or are willing to subject yourself to LD_PRELOAD hacks.... ]]
It might be instructive to note that XEmacs dealt with precisely this issue. The original GNU Emacs has lots of bundled LISP packages, and they used to come in one colossal directory. The XEmacs people started splitting things into their own dirs, but Emacs has a variable 'load-path' that works like $PATH for elisp files. Eventually they came up with a function that scanned the lisp dirs and made a list of subdirs - then used that function to build 'load-path' at runtime, when you start XEmacs.
Kind of clunky, but the same could be done with /etc/PATH or whatever the script might be called for your shell and your OS.
Just a thought....
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
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 OS is stored in /Linux-$VERSION-$VENDOR
(e.g., /Linux-2.4.14-RedHat) - this allows you to have multiple OS directories for quick and simple upgrades. The OS would, of course, include the kernel, modules, etc - the essentials.
Common commands should have a directory, lets call it "/Commands", however, it could be "/C" (ooh, very Amiga-like, the OS that had a decent directory structure from the start - we could learn a lot from that) or "/bin" for the die hards. This would hold utilities, tools, etc - command line stuff.
Applications would be stored under the "/Applications" directory, each application would have its own directory, and in that directory you could store different versions of the software. All software could be configured to run in a chroot'd environment for security. Software could come as a MacOSX style package.
Mount other drives in the "/Drives" directory. Mount devices in the "/Devices" directory, or in the "/Linux-$VERSION-$VENDOR/Devices" directory, depending on how you want to define the scope of the OS.
Sure, this needs a little work. But it is a lot more understandable and usable than the current system.
So a simple example would have:
(of course, you might want it all lower-case in a case-sensitive file system!).
True. The usual workaround (or "fix" if you want to term it such) is to apply the Debian diff to your source tree (which if it's a different version may or may not apply cleanly, but often works fine), then use 'dpkg-buildpackage' to make a binary .deb from it, then install that.
Can't customise the build? This depends on the packaging job, but often you can run the './configure' step or whatever, then have dpkg-buildpackage take over from there, using the '-nc' ("do not clean") option. YMMV. There are other ways to trick 'dpkg-buildpackage' too, again depending on how the package was packaged.
Note that you also have to make sure 'apt' doesn't try to overwrite your custom-compiled package with an "upgrade" - normally done by marking the package "on hold".
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
True. Now explain that to the users. Then explain it to some million linux distribution newbies.
I dont want to do that. But you can. If you want to.
On first inspection, it of course makes identifying and finding what put whom where ludicrously simple.
find / -group KDE
On second reflection, it adds a finer layer to group/user mangement, and administrative delegations.
Before I part with'em: two pennies weigh ~4.996+/-0.014g, have a zinc core, and the face of Lincoln. You can keep 'em.
Listen, Microsoft went down this package management road and discovered that, hey, it makes more sense to waste a little space duplicating shared libs and simply install programs into their own directories....
/usr/local/apache is really nice if you are used to it spreading itself 10 ways to sunday.
This is one of my biggest pet peaves. This LSB File System Standard serves no really useful purposes and causes endless heartache for whoever is interested in simply being able to use their system, and remove stuff with an rm -rf.
Having appache install itself in
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."
Its incredible that the current UNIX file structure actually works. There are so many namespace conflicts that it must be an act of god that keeps it moving. Take, for example, /etc. Tons of different programs park their config files in that one directory. The take every user's root directory. There are so many .this_stupid_program files in their it's ridiculous (plus RPM doesn't remove them). Then take /bin. All these different programs sharing a single namespace. IMO, the evolution of the UNIX filesystem should take several steps:
/lib and /usr/lib.
1) Get rid of the current library structure. All libraries should be explicitly managed by the system. If a program wants a shared library loaded, it has to install it at install time through special APIs. That way the system make several improvements, such as prelocating common libraries so they don't have to be relocated at run time, manage conflicts between libraries, since the information is explicit and not dependent on the filesystem, get rid of the need for ldconfig, and allow more complex security/sharing policies than available with
2) Revamp the include file namespace. Include files from so many libraries should NOT be sharing the same namespace. 'include' shouldn't even be part of the standard system, it should be an implementation detail left to compilers.
3) Revamp the configuration system. Again, no more allowing programs to directly access the filesystem. Configuration stuff should go through special APIs (like the Windows registry). Instead of a binary database, however, the registry should be a tree of text (probably XML) config files. This would also fix another problem. It would be much easier to write a unified configuration editor. Since there wouldn't be dozens of config file formats lying around, one could write a program that could read a standard XML format and allow the user to edit it.
4) Revamp application installation. That's the biggest problem with current OSs (even given package management like RPMS). Apps simply don't work right. Removing an RPM, for example, doesn't remove all traces of a program. Upgrading an application with a slightly different one is very difficult. The other day, I was trying to install TexStar's optimized KDE RPMs for Mandrake. Of course, I couldn't use RPM -uvh, since the they have two different tags (3mdk and 2tex). I had to remove the KDE rpms with --nodeps (which makes me cringe each time HOWTO suggests doing it) and install the new ones. Of course, it didn't work right, so I had to uninstall the whole KDE installation, reinstall with the tex RPMs, and reinstall all the apps. Of course, by then I had tons of stale config files lying around.
5) Paths. Paths are a huge problem. Just the very fact that a crashed program dumps core onto whatever happens to be the current directory shows how badly the UNIX hierarchy was thought out (or maybe how much its been streched beyond its original design). First, no programs should depend on explicit pathnames. Everything should go through at least one layer of abstraction. Maybe read paths for the standard config mechanism.
A deep unwavering belief is a sure sign you're missing something...
The only problem I run into lately on my Unix systems are calls to the wrong versions of libraries. Windows used to have this problem but has since taken care of it by allowing multiple versions of the same dll to coexist.
The thing that Windows does well that Linux package managers haven't even attempted is that it will not allow programs to be installed onto the system unless they meet certain requirements. Mainly for a program to get installed, there has to be a way to cleanly uninstall it. Otherwise it doesn't get installed.
If dpkg could do this, I'd be very happy. Not just for things bundled into a nice little Debian package, but for everything that gets installed into my system. If it gets installed, there should be a clean way to uninstall. Then, 2000 programs in
No, Thursday's out. How about never - is never good for you?
[localhost:~] local% uname -a /bin | wc -l
/usr/bin | wc -l
/usr/sbin | wc -l
/sbin | wc -l
Darwin localhost 5.1 Darwin Kernel Version 5.1: Tue Oct 30 00:06:34 PST 2001; root:xnu/xnu-201.5.obj~1/RELEASE_PPC Power Macintosh powerpc
[localhost:~] local% ls -l
32
[localhost:~] local% ls -l
450
[localhost:~] local% ls -l
113
[localhost:~] local% ls -l
58
Not too bad, eh?
How does MacOS X manage application files? It comes from BSD but, as far as I know, installing a Mac application is just drawing a folder on to the file tree.
__
Men with no respect for life must never be allowed to control the ultimate instruments of death.
GW Bu
The late (un?)lamented SCO OpenServer pretty much threw stuff into
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
Doing this better allows for the installation and maintenance of change root services.
Something the FHS seems to think is an unusual case, soemthing I personally see as the reason I use Unix for servers despite its other flaws.
I guess all you need to do is
/usr will be runnable and recoverable to determine whether files should be under / or /usr.
/, and other distro's have to put them under /usr, yo ucan give up on the idea of knowing where apps are on a Unix system. Which defeats the pourpose of the FHS.
/media proprosal without anyone's consultation was the last straw).
* define `add on'
* define` extra'
* define `essential'
* define `core'
In a way more than 10% of OSS Unix users wil agree on. Good luck. The FHS uses whether a system booted without
But they don't bother defining what's optional (leading to the pathetic situation of having ten or different sets of KDE packages for various Linuxes).
I don't consider a workstation to be functional unless it has a GUI. A set top box might have an TV tuner app and DVD player as an `essential' piece of software.
If they get to put these apps under
My $0.02 says the FHS has failed miserably (Rusty removing the long-awaited and long debated and finally resolved
Fuck it - let's all organize out system Dan bernstein style.
I've bitched about this for years.
/opt/apache, it's because I don't want my applications to get their fingers all into each other! Not because I'm a neat freak, but because I can't fucking uninstall half of them without doing so!
I've even put an entry in my slashdot journal about the problems that are keeping Linux out of the real spotlight.
Shitty package management/lack of app-installers (RPM and apt-get aren't quite InstallShield replacements), bad filesystem design (/usr/bin/all-my-execs), no lossless HD repartitioning utilities (none that I've found anyways), lack of good journaling filesystem (ext3 seems to have fixed this), shitty printer-driver model (text files describing my printer's abilities are hardly flexible enough to remove the need to recompile lpd), bad video model (Xservers & Xclients streamlining all of my gfx operations? come on!), nearly everything you get has to be compiled (GPL is great, but just because you need to make the source available doesn't mean you need to make the source the way you distribute it. GCC should not be a required option), no windows compatability (Wine seems to be getting this under control).
I've kicked this fucking horse right into the ground. Everyone bitches about it, but everyone also agrees that starting their own distrobution isn't going to solve the problem. Linux is a great server, but an ultimately shitty desktop. Believe me when I say that I know from experience. It's been my ONLY desktop for over 2 years.
I switched to Linux to avoid having to reinstall the OS every few months, yet I still find myself doing so simply because there's been a huge kernel change, or my RPM dependancies are completely fucked from trying to install a non-RedHat created RPM. Or maybe I've "configure; make; make install;"ed my way into a full hard-drive, with no idea of what files belong to what application. There's a reason that I always configure apache to install into
If it's an OS upgrade, then make it an RPM, or make it an apt-get package. If it's an application, then it needs to have it's own installer bundled with it, and it needs to put itself into it's own fucking dir tree, so when the installer DB pukes, I can still tell what files belong to what app.
I'm putting together a new linux distro from LinuxFromScratch.com, and developing an application installer, and hopefully a new paradigm of how Linux applications are distributed. What wagon are you on?
On point #1, objection. Binary names can clash, just not in packages used at the same time. Eg., if I have a foomatic program for both KDE and Gnome desktops, I want both versions of foomatic installed simultaneously, say in /usr/bin/gnome/foomatic and /usr/bin/kde/foomatic. I'll only put one of /usr/bin/kde and /usr/bin/gnome in my path at once, so there's no conflict at run-time.
There's even a sensible reason for having the same name. Suppose foomatic is the same program under both desktops, but the Gnome version's built with the Gnome/GTK toolkits and the KDE version's build with the KDE toolkits so that each version has the right look-and-feel for the desktop it's used with.
First of all, he keeps blabbing about "thousands of directories under /usr." I don't know about you guys, but on every Red Hat system I've ever used, "ls /usr" produces about 10 directories.
/usr/bin - well, that's just plain silliness. Of course there are binaries (and symlinks to binaries) in there. Does he expect us to have a $PATH that is 25k long?
If he's referring to
There are a lot of things that I would change about the filesystem layout, and about Linux/UNIX in general. This is not one of them.
At work we have software in /opt/- (A more windows-ish way). Some directories in opt are complete messes with little or no structure at all ( e.g. Netscape ldap, weblogic servletengine, etc ). I am vehemently opposed to this. I do my best to preach the benefits of GNU Stow every time a $PATH related confusion arises, but they've fallen on deaf ears thus far.
the first thing I really noticed about Linux after taking the plunge was that things were organized in a far superior manner (for the most part). I like having my PATH be $HOME/bin:/usr/local/bin:/usr/bin:/bin and at home it is. At work (HPUX) even /etc contains binaries, what a mess.
you're an idiot. first of all removing is not the same as purging.
and those files are configuration files. Now, the reason removing is not the same as purging is because purging WILL remove those.
Ooooh, oh no, I guess he does know what he's talking about, huh?
FiGZ.COM - A waste of perfectly good web space
only has 380 files in it, and I know exactly what each one of those files is for.
I don't know about mosfet's problems, but I have no problem managing my filesystems.
Would you care to share some of that overwhelming evidence? I haven't seen it.
I simply haven't seen much data to make me worry about any of this. In the time I've used Linux, I've seen one friend's ext2 partition get corrupted beyond repair, and I've not seen anyone's RPM database get corrupted at all.
Distributions are already doing the right thing. For example, with Debian the ghostscript package has:
XMMS has:
Application specific directories would be a nightmare for managing partitions. You would have
This might be OK for a single home user with a single large "/" partition. But it's the wrong thing for system management. It's mixing the system management in with the package management. Imagine trying to mount all the "share" areas as read-only and share one copy amongst a heterogenous network of x86, PPC, Alpha, Sparc. Perfectly possible with FHS due to the definition of what the "share" areas are. This wouldn't be possible if MOSFET's /opt/package scheme was being used.
Package management is a complex problem. There are many ways to address this problem. Either by using package management systems (Debian, RedHat) or by putting applications in /opt and using symlinks (depot-based systems) or whatever. The package management technique has the huge benefit of being able to solve packaging problems without influencing the filesystem layout.
Now, MOSFET does raise one very interesting point. Distributions are already going down the path of /usr/lib/package/ and /usr/share/package/. Why aren't they going further down the path of /usr/bin/package/? Maybe because most packages only have a single binary in /usr/bin. Maybe because PATH handling is real difficult. Either way I think this is the only valid argument he raises.
Keep in mind that MOSFET's arguments aren't new. They were debated when the FSSTND was first written and when the FHS replaced it. The /opt/package argument is weak and it lost out to the cleaner FSSTND/FHS layout both times.
Agreed.
/usr/local/ is designated for. Stuff that really can't be packaged somehow (like, er, what?) can be built from source with --prefix=/usr/local/stow/, and then stowed from there into /usr/local, *where it belongs*. The entities in your PATH would be nothing but symlinks, *and* under the control of a package manager (stow is one such beast), *and* would allow for the arch-independent files to be easily shared amongst machines. The filesystem *can* be its own package-manager, but you need the functionality of stow around it.
/usr/doc became /usr/share/doc in debian, followed by RH.)
I also don't know quite what he's complaining about. "Forced to use the package-manager"? Well, big furry deal. Better that there is a decent manager to be used, and that you use it, than that you have some kludgy mess where some files are owned by packages and some aren't.
This is, after all, what
I get the feeling that Mr Mosfet really doesn't have half a clue what he's talking about, and is just an old sales-droid unix-head who hasn't bothered reading either the FHS or `man dpkg` and doesn't know how to admin a box tidily.
And incidentally, his history is fscked as well: Debian has lead the way in FHS-compliance, *followed* by RH. (Cf how
~Tim
--
Rushing on down to the circle of the turn
Here's my evidence:
Computers break.
Bosses want them fixed RIGHT FREAKING NOW.
Here's your anecdotal evidence:
"My computer didn't break."
Read my other comments; it boils down to making a system as self-documenting as possible so that the poor schmuck who has to fix it has as easy a time of it as possible.
You are assuming that because you personally have never observed a problem with this software then the problem does not exist. I, on the other hand, am assuming that this software is like all other software I've seen - it is imperfect. If I am to be responsible for administering a system, I want to be prepared for every part of it to break.
This is NOT adequate. Yes it let's you uninstall stuff, but it does not get EVERYTHING! RPM generally get's most stuff except for user generated things that are dumped in their home directories. Documents and settings are generally left alone. Try this on both a windows system and a Linux system.
1. Look at free drive space using a appropriate command on each system ( yeah I know, highly inaccurate on windows since drive contents goes up and down due to swapping but good enough for this demo )
2. Install Mozilla on both Windows and Linux (use RPM or DEB based system).
3. Browse a bit on both.
4. Uninstall package/program using appropriate util.
5. Check drivespace.
I know the above is one program that doesn't drop a whole bunch of crap all over the drive in Windows, but chance are that the add/remove program util will miss something. I chalk most of this up to lazy programming practices. Also, Microsoft has a long history of letting programs update things and dumping things into both the Windows directory and the Windows/system directory. Microsoft said you weren't suposed to do it then several Microsoft programs did it themselves and now most do it to make sure you have the right levels. This main archetecture flaw is the main reason behind DLL hell. It's also the reason add/remove never gets everything. If Microsoft fixes this problem, then they may have a better system. Personally I think they can't fix it. It's been getting better, but Windows ME was nto as stable as they said it was going to be. Maybe XP is. I don;t have it nor do I use it at work yet so I have no clue. BUT I think alot of folks are asking for things to be like they were "back in the day" and we have to face it that they will never be like that. Code reuse force the use of shared libraries and such so it's a pain to do it the OLD way. Granted I think that APT/deb is the best, but Apt-RPM ain't the best and BOTH need some refinement. RPM more then APT/DEB.
Gorkman
The FreeBSD (and other BSD) filesystem layout still fails to accomodate commercial apps. In fact the whole ports system defaults to a path (and some programs fail if you try to change things) which collides with local apps. What is important to me is to keep locally selected applications separate from locally developed applications, and BSD simply does not do this. One choice (and not the only one, but BSD doesn't have any) is to put the locally developed ones in /usr/local and the ports and commercial apps in /opt (ooh, you might have to do mkdir). Now that's not the only way to choose to do it, and I'd certainly consider a different choice, but I want to see some decision, and see PATH defaults to include that choice.
Linux suffers from so much independence of packages that they get installed anywhere. What I think really needs to happen (on BSD, too) is that every package (ports included) needs to strictly follow local policy about where to be installed (and the installer program enforce this). If I tell it to be installed in /usr/foo then it should function just fine from there, and further, if I go rename /usr/foo to /usr/bar then what is installed must continue to function just fine that way. If I replicate the tree to a new system under a different directory, and access it that way, it should work there. Part of the problem is it is not easy to do so (a program might have to find its resource files ... where are they? ... how will the program know from which directory it was executed so it can find the matching set of resources?).
now we need to go OSS in diesel cars