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.
Well, if he thinks the windows installs are clean, then let him just install 1000 programs, and deinstall them.
/bin dir (/bin, /usr/bin, etc).
Then check how much space you used before and after, and just start to panic.
Some Windows applications have become lax at this and started installing into the "windows" directory.
And I thought all Windows programs did this.
In a way I like to have all my programs in some
And if I want to know what program a certain file belongs to, I just do a rpm -qf file.
He's a bit ranting about RedHat, but I assume he means more Unixes than RedHat alone though.
Well, don't worry about that. We can get you back before you leave. (Dr. Who)
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.
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~ch eckout~/build/BUILD/Docs/build-draft.html?rev=HEAD &content-type=text/html
Sound's similar?
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.
You know, I hate it too, but hey at least with Linux you have a package manager. With Windows you don't have that! Also, KDE, GNOME and others are ALL dependant on shared libraries and you sure as heck don't want 40 copies of the libraries for all of the programs you run! Also, even if a program is in a sub directory under /usr, isn't everything in the path when you include /usr in your statement?? /usr is the parent of everything underneath it. If /usr is in the path, then so are it's children. At least I think that's the way it works. Anyway, with packagemanagers such as Debian's apt, this is moot! Who cares! Why would I delete it the hard way when I can press a button (in the graphical tool) or do a apt-get remove package???
Gorkman
/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.
Most people haven't read the article it seems. Allow me to copy the follow-up:
A few followups
The response to this commentary has been large and I've gotten a ton of emails, (mostly positive). A few things I think I should clarify. First of all, this seems to only be an issue in RH based systems - many Slackware and Suse users emailed me to say that their systems try to do the right thing. Second of all a few angry people questioned my qualifications to make the above commentary, and one person even called me a novice! Many people know who I am and that I've been involved in Linux for years, but I figure since most editorials state the author's experience I might as well, too. I'm a Unix and Windows developer, have certifications in HP-UX Systems Administration and Tru64 cluster management (TruCluster), and have been a either a Unix admin or developer since college. I've worked on free software for about 3 years and have been a Linux user since the 0.9x days. Last of all, a few users say I should just use RPM, usually stating something along the lines that I'm stupid and don't know how to use it. Nothing can be further from the case: I have a lot of experience with RPM both from a user experience and creating quite a few RPMs for Linux distributions in the past. Just because you have a package manager is no excuse for sloppy and lazy directory management.
We do not live in the 21st century. We live in the 20 second century.
All GNU software gets dumped into /usr/local/* by default unless you pass configure an option. That is probably why most of this /usr directory dumping started in the first place.
While I would be the first to admit that I hate having to hunt through screeds of files in a single directory by hand, most of us who operate *nix boxes of one colour or another on the desktop have far too many object files to make for easy digestion without having recourse to some kind of package manager, whether it be rpm, apt or whatever. I think only servers really can use the luxury of separate directories for everything nowadays.
~> 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/
One of the things about the proliferation of Windows is that people get used to a filesystem is generally organized by individual software entities. On Linux, it's organized by software type. Generally. Of course the rule gets broken both ways, and the Windows Directory throws its own set of curveballs, but for the most part, that's the way it goes.
.conf files...
The latter basically means that your source isn't always in the same place as the executable which isn't always in the same place as the libraries which isn't always in the same place as the documentation which isn't always in the same place as the user
Tomayto Tomahto. You get used to it. It would help if all the vendors got together and enforced the LSB on themselves, so that a common way of doing things with the filesystem would become a practiced standard in its own.
But really, in the end, you just get used to it, and Linux has usability problems in other areas that the community should probably look into before worrying about this one.
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
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.
Linux developers are geeks. They know that the only people that use their products are going to be geeks. Hence the end users will understand the laziness.
Of course I can't help but think that too much laziness is keeping developers from working towards making Linux a desktop competitor.
Not flamebait, not a troll, just a comment.
I've got 1200+ files under /usr/bin. That has caused no headache for me so far.
Anyway, if every package would have its own directory, there would be nearly 600 dirs. How would that be any better?
And, I should add, /usr/bin is not where an "application" resides. It is the place where the executables are. If you are talking about a whole application, it will have files likely at other places: /var, /etc, /home (for user-specific configuration), etc
So, this guy fails to state what is this problem (having a lot of files in a single dir is not a problem: the fs can handle that) and it is absolutely not clear how having separate dirs would give any advantage over the current situation - though it is absolutely clear what the disadvantages would be (having fscking long PATHs).
I would moderate him -1, drunk babbling, if I could ;)
Real life is overrated.
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
Well, traditionally under both Unix and DOS you used subdirectories to group related files. So Microsoft Office got it's own folder, CDE got it's own folder, X Windows got it's own folder, Oracle got it's own folder...
What's a folder?
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.
Instead of having 2000 programs that do only very specific things, have 1 program that can do everything. Think Microsoft Word for instance...
QED.
Sig (appended to the end of comments you post, 120 chars)
I think one of the big problems here is that all kinds of stuff ends up in /usr/bin, /usr/local/bin and other "catch-all" locations that really don't need to be there.
I'd prefer to see only commands that I am likely to use from a shell in /usr/bin - everything else should go somewhere else. Major applications like Mozilla need to be in their own directories - you shouldn't need to have these in your path since you're likely to launch them from buttons on the panel.
Microsoft is just now getting around to addressing a similar issue in Windows - for years, developers have dumped application-specific DLLs in \winnt\system32 for no good reason. Now they are strongly discouraging this.
This issue stems primarily from the simplistic path-searching mechanism shared by pretty much every OS out there. Either you dump tons of crap in standard locations like /usr/bin or you have a PATH variable a mile long. Perhaps there is an opportunity for a technical advancement here...
Do you really need to have all your apps in the path at all.
/usr/sbin/swlist.
/usr/sbin/swlist. After that if I keep using it its just swlist.
I mean Their are hundreds of apps that are installed that I (you?) will never use. I dont really need them in my path as long as their is a logical place to find them.
So if I have a good directory organisation, and then only add to my path the apps I really want to use a lot/quicklly (ll, vi, emacs, nedit, aCC, perl etc).
The rest I can just refer to by full path. Its not much harder to type
Stupidlly complicated sugestion update the shell to add any command you run to the path and keep it their until its been unused for a week. So first time I enter
Andrew
Flame my comments, not me.
There are probably some very valid reasons for the way UNIX does things. For example, manu application binaries and related files are shared between different applications and used with others because software is often cooperativily developed between vendors rather than in isolation the way windows stuff is typically developed. As a result, sharing of common resources, libraries, etc, is much easier to achieve.
/usr/bin might come from from a cpu architecture specific machine. To do this in /opt/packagename would mean all kinds of nfs 'micro-mounts' for portions of each applications tree. Having a common set of directory trees for applications rather than package specific ones makes it much easier to organize role specific network mounts.
/usr/share portion on my master nfs, without it also installing bin, etc, and having it install my /usr/bin or whatever portion on workstations or my cpu specific nfs servers without it installing /usr/share and such. Having a master config file in /etc that can explain this kind of usages to package managemement systems that can be setup on these machines would make that much easier to accomplish.
Also, most complex sites may use different kinds of nfs partial mounts on a file system. For example all of "/usr/share" may be off a single master nfs server, but
Of course, most of the current package management systems do not seem to understand the concept of role specific filesystem mounts. It would be nice if I could install a rpm for my
MacOSX seems to go about this by using bundles & frameworks. Applications have the ".app" extension and are actually directories (this is made transparent to a user). Within the app is a standard directory structure consisting of the application components. Libraries (aka. frameworks) do this in a similar fashion. In fact, frameworks encapsulate different library versions and API documentation within a framework. ARS technica has a nice description here
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.USE FORTH - REAL FORTH, not some hack that sits on top of a host OS. FORTH is the OS, the Language, and the File System.
I won't go so far as to say FORTH is God, but I will bet that God uses FORTH.
As long as I can use grep, I don't care how many files are in /usr/bin.
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
An easy way to keep different applications separated into their own directories, and not have a nightmare managing $PATH would be to create something like /etc/path, which would contain several little files, one for each application, each of which would append its own entry to the $PATH variable. Then, all entries in /etc/path could be parsed on login (in a SysV init sort of manner). Just call some path-init script from the system profile, or bashrc, or whatever.
/etc/path.
This would make things easy for package management too, since all you would need to do to remove a package would be to delete the unique directory the application lives in, then remove the matching path script from
PATH is always explicit.
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
The problem is not bad on Slackware. It includes an
I thought the article was lame, but I think its worse to erroneously criticize UNIX distributions that do a better job of segregating software packages than Red Hat.
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
If we invite concept of namespaces in file system, we can then set, for example
namespace staroffice
and then see only executables in staroffice::/usr/bin
that related to that package.
Denis
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
/bin
/usr/local is that it is used for distributions of software "local" to a particular network (e.g. for administration ease). This might have some place in a farm of servers, but what place does it have on a desktop machine??
/usr/sbin make? If it is a *system* binary, what is it doing in a /usr volume? Ok, I admit some of these distinctions may be for technical reasons of partitioning, distributing volumes accross disks, whatever. But really, that is the file system's problem, not the users problem. File hierarchy should be completely independent of being able to maintain integrity of the file system. I should be able to format one humongous honking partition and have the file system take care of the rest...not bother myself with cutting my file system into different fixed-sized partitions. What is this, DOS and FAT12??
/usr, /usr/local, no /etc with a pile of random configuration files. And for chrissakes, no /usr/local! Modern filesystems should be able to merge-mount remote filesystems (e.g. into /programs)...or just put them into /programs/remote/ or something, or some entirely different path. Really I haven't seen an adequate rationale for /usr/local being used for software "local" to a network. What it usually is used for is software that is installed ad-hoc by users, and /programs will serve just fine for that.
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin
WHY do we need all these directories? The explanation of
And what sense does
Here's something radical (and instantly distasteful because of its analog in Windows)
/system/conf
/system/bin
/system/...
/programs/bin
/programs/conf
/programs/...
BLAM! Done. No
Stop the insanity.
It's 10 PM. Do you know if you're un-American?
Personally, I don't care if I have 2000 binaries in /usr/bin. All I care about is that the programs work, and I sure don't want a monster PATH variable, or have to worry about 2000 symlinks in /usr/bin.
What do people have against package managers? I have no problem with RPMs. I don't want to fiddle with my system, I just want to use it to do work.
Jeff
stty erase ^H
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.
What I don't see in all the other comments is what I always thought to be the biggest advantage of putting all binaries in /usr/bin etc., logs and spools etc in /var: the ability to put files on different disks/partitions based on the kind of access. Easier for backups etc.
This sig under construction. Please check back later.
I read the Linux file system standard with some hope about a year ago and came away disappointed. It wasn't a thought-out organizational model. It was a justification for every single directory that has ever been created on any system! This is not what I had hoped for with the concept of "standard," i.e. design by years of committee.
I'd love to see a new, orderly, and well-reasoned standard. It would start with the competing interests of the system itself (such as read-only areas and binary areas and what not), cut to the core of necessity, then come up with a suitable hierarchy, leaving most of the play space in users's homes.
I hate to say it, but the Windows file standard is better, sadly.
I'd like to keep things as clean as possible but that's kind of the nature of UNIX. Just the fileutils and textutils dump around 100+ files there and you're not doing anything interesting yet.
I have 5500 files in my .mp3 directory :)
Thanks to file sharing, I purchase more CDs
Thanks to the RIAA, I buy them used...
If the article was a comment I would moderate it "-1, Troll". It's a stupid discussion that nobody needs, the question has been asked a thousand times..
The author doesnt even have a point, saying "if I would not use a package manager it would be a mess". Well, he uses one, so it's not a problem. And if he didn't he could easily put each package in a single directory and create the world's longest environment variable.
You can make them read only so hackers cant modify them.
Who gives a damn how many files are in the bin directory provided
a) there's no performance loss
b) a decent package manager exists?
c) your partition is big enough
That said I do prefer packages to install in their own private dirs and have symlinks from the bin directories.
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
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.
And he thinks having a PATH which is 7k in size is any better? Comeon, things are laid out in /usr/sbin, etc for a reason. We know stuff in /sbin and /bin are required for most systems' operation, /usr/sbin is system management and secure tools (sometimes, I think), /usr/bin for common apps, /usr/local/bin for local binaries, etc.
/usr/bin, /usr/sbin, /bin, /sbin and let other machines of the same type mount it and have only system specific stuff in /usr/local. Thats some of the intention behind this setup...
In theory, I could nfs export
Brielle
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
what i usually do is i build the code myself in a directory under /usr/local say and then have symbolic links to the binaries in the "standard" directory. this makes the filesystem more managable but also makes everything accessible to the path, which would be a pain in the ass to update everytime... not to mention very long. isn't that what symbolic links were basically meant for???
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
(If you are unfortunate and are not running BSDhttp://www.freebsd.org/doc/en_US.ISO8859-1/book s/handbook/dirstructure.html
$ man hier
NAME
hier - layout of filesystems
DESCRIPTION
A sketch of the filesystem hierarchy.
(..snip..)
-- Windows or Linux? Nah, I'll use a real OS (BSD)
The reliance on "package managers" is a crutch that can ultimately doom an OS. Windows is a classic example of this, with its program install/uninstall features that frequently leave cr@p all over your hard drive. This is acceptable for workstations and personal computers, but is unthinkable in a server environment.
On a personal note, I much prefer doing a 'rm -rf' on a directory that having to trust a package manager to auto-magically get it right.
What makes linux elegant is its simplicity. To stray too far from this is to miss the point.
PS: SuSE and Mandrake are not the panacea that some people make them out to be.
$ uname -a /usr/bin | wc
/usr/openwin/bin | wc
/usr/local/bin |wc
SunOS mochila 5.8 Generic sun4u sparc SUNW,Ultra-5_10
$ ls
549 549 3681
$ ls
236 236 2022
$ ls
836 836 7543
And Solaris' package management is useless. I fail to see how this is an improvement.
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.
boy am I glad I'm not running linux. 1,500 binaries in /usr/bin? BTW, I was looking at mandrake, and all the binaries in /bin were linked to libraries in /usr !! That's amazing, I'm in fear of what other ways they found to break unix.
FreeBSD has had their file organization figured out since 1993.
(sure, mod me troll - but it's still true)
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.
I think the way to fix the problem is the following. Add subdirectories to "/usr/bin" (and "/usr/lib", etc). You would have a directory for "/usr/bin/gnome", "/usr/bin/kde", "/usr/bin/X11R6". Eight to thirty-two subdirectories would yield a highly organized file structure. And you would only have to add eight to thirty-two directories to your path.
I'd rather subdivide this way than the windows way. That is I'd rather have:
"/usr/bin/gnome"
"/usr/lib/gnome"
"/usr/share/gnome"
than:
"/usr/gnome/bin"
"/usr/gnome/lib"
"/usr/gnome/share"
This way a smart path system could be setup, where every subdirectory under "/usr/bin" is in your path.
-Nathan
or maybe it's not a problem, as others have discussed -- a lot of people like having lots of things in a path directory instead of a very long path. At my employer we use a system that puts packages in different directories, and it's very nice (it searches a database and takes versions and platforms into account), but occasionally other tools complain about the very long paths that result. I also ended up writing a little Perl script that searchs for patterns in the contents of PATH-like variables in order to get a better grip on exactly where things in my environment are coming from.
.jpg files with a program, and you must know exactly where that program is. Whereas, if it's on a PATH, all you need to know is the name. With symbolic links and other Unix trickery, it's easier to move around such application. But the problem with Unix trickerey is that it's too complicated to follow for most people.
You must put things on the PATH for command-line purposes, although a desktop environment or package shouldn't require this. I don't use X-like environments for GUI tasks so I am unfamiliar with the approaches that they take to this problem. The related problem is that dynamic libraries also need to be searched as well, so sometimes even GUI packages need to modify the environment.
The nice thing about a big PATH is that less things have to know about exactly where things are for GUI explorer-type applications. For example, on the Mac or Windows, something needs to associate
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,
Don't forget that Linux and Unix are notorius for thier Documantation. Everything is documented. It would tell you what to expect and where to find it. If it is in /usr/bin then so be it, the docs would tell you exactly where it is.
"I think you know what I'm talkin' about, Mr. President; We're gonna kill us a mummy!" - Bruce Campbell as Elvis Presley
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
What does he do? Run commands by searching through /usr/bin/ using mc?
/usr/bin has over 2000 files is like complaining the sky is too blue.
Having $PATH=$EVERYAPP/bin, etc. is moronic.
Why make it harder?
Having an anal retentive filesystem isn't going to change program quality.
Having said that, I think filesystems could use the following concepts:
A directory = pointers to inodes for various files
A folder = list of files, pipes, devices, fifos, netconnections, organized together
A folder would contain a heading subfolder that referenced the directory files that had the inode pointers for the files in the folder.
A list = any delimiter separated sequence of objects referenced
You home directory would become your home area defined by a list of the folders that you wished to have organized there.
I think that sometimes people forget that there is no folder and there is no directory. There is just data. Arguing that
The message on the other side of this sig is false.
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.
There are some applications like XFree86 on OS X which put CLI implementations inside the bundle, but that's a pretty odd case, and besides, it's more of a Darwin application than an OS X application (although that is changing it it becomes more integrated with Aqua).
;->)
What I'd really like to see migrate to other Unices is the framework concept and version discipline for shared libraries. But the problem with that is maintainers of various Open Source DSOs like libz, libtiff, libpng, and so on would have to start tracking binary API compatiblity vs. mere source compatibility, which isn't trivial.
Alternatively, maybe there should be a Darwin project that collects the most popular libraries and gives them meaningful version information, so that dependent projects can take advantage of it. It would mean changing link statements in upstream projects but it is work that would avoid a needless proliferation of DSO versions, and could be eventually applied to other Unices if they ever come their senses. (OK,
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?
the solution is simple : use subdirectories, and provide sym-links to a main directory which is standard...
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.Why does your /usr/bin have 1500 files in it? It's called Redhat bloat!
Here's what I do on server systems (workstations I handle differently). I only install the minimum amout of packages during system install time. From that point onwards I only install under /usr/local/package_name. All my source goes into /usr/local/package_name/src. I always compile from source where possible. /opt is symlinked to /usr/local as well.
/usr/local
/etc/profile I have:
/usr/local/*/*bin )
/usr/local/*/man /usr/local/man/* )
h /b in:/usr/X11R6/bin:/usr/local/apache/bin:/usr/local /apache/cgi-bin:/usr/local/cvs/bin:/usr/local/cyru s/bin:/usr/local/cyrus/sbin:/usr/local/dhcp/sbin:/ usr/local/djbdns/bin:/usr/local/e2fsprogs/INSTALL. dllbin:/usr/local/e2fsprogs/INSTALL.elfbin:/usr/lo cal/exim/bin:/usr/local/firewall/bin:/usr/local/fr eeswan/bin:/usr/local/mathopd/bin:/usr/local/mysql /bin:/usr/local/openldap/bin:/usr/local/openldap/s bin:/usr/local/openssh/bin:/usr/local/openssh/sbin :/usr/local/openssl/bin:/usr/local/rsync/bin:/usr/ local/samba/bin:/usr/local/samba/sbin:/usr/local/s aprouter/bin:/usr/local/squid/bin:/usr/local/wget/ bin
$ cd
$ ls
apache djbdns firewall info mysql redhat share
bin doc freeswan kernel openldap rsync squid
cvs e2fsprogs games lib openssh samba src
cyrus etc imp man openssl saprouter wget
dhcp exim include mathopd portfwd sbin wu-imap
$
I use ksh, so in
LOCALPATH=""
for DIR in $( ls -d
do
if [[ -z $LOCALPATH ]]
then
LOCALPATH=$DIR
else
LOCALPATH=$LOCALPATH:$DIR
fi
done
PATH=/root/bin:$PATH:$LOCALPATH
MANPATH=/usr/man
for DIR in $( ls -d
do
MANPATH=$MANPATH:$DIR
done
And my PATH looks like:
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/openss
Which may look ugly, but I never actually look at it, and it works just fine. I've never noticed a speed decrease because of the long PATH... YMMV
I use Windows. I'm asked by the installers where I want to put my apps. It works, simple as that.
Moderators, think about this before modding down.
--jon
Cleanstick.org: Dumb weblog about nothing
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.
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
The great thing about open standards is there
are so many to choose from. -- A. Tannenbaum
There are so many "Standards" they cancel each other out. To be worthwhile you need a single standard. Then all others are deemed non-standard and you use them with that understanding.
The Start menu is user interface. You need to be able to use it. (On my /usr-using Debian system, each desktop environment's Start-menu-equivalent is organised in a nice neat hierarchy.)
/usr/bin doesn't *need* to be user-readable (and if you don't find the package manager useful, what are you doing choosing a packaged distro?)
/bin, /usr/bin, /usr/local/bin or wherever, as long as it runs and none of its required files are "owned" by two packages at once and liable to be deleted or overwritten by mistake (the Debian package installer, for one, specifically prevents you from installing two packages both claiming to own a given file).
/opt) because each program installs itself, and because there aren't well-defined locations for many things (there is no FHS for Windows) so some applications are programmed to look for "./MyDataFile" rather than the Unixish /usr/share/programname/mydatafile.
/usr and friends isn't based on the same assumptions as Windows; if you have many identical Unix boxes with NFS, you can give each its own /var and /tmp, share /home, possibly share /etc between boxes with the same hardware and configuration, share most of /usr (/usr/bin, /usr/lib, and so on) between boxes with the same hardware, and share /usr/share between everything (at least in theory).
/usr/local is useless are (1) ones with broken packages which install into /usr/local anyway (yech), and (2) Linux From Scratch :-) (which is what you use if you're allergic to package managers).
/home/myname, it's just a multi-user version of C:\My Documents (you do use that or your own equivalent instead of saving Word documents in C:\Winword or whatever, right?), with the added advantage that it's far quicker to type (although you rarely need to type it anyway thanks to the shell's ~ shortcut) and doesn't have that command-line-tool-breaking space in it... When set up for multiple users, Windows uses C:\Windows\Profiles\myname, which is rather worse than /home/myname, and when set up for one user, it puts a lot of what would be "dotfiles" on Unix straight in the Windows folder (user.dat for example), making just-the-important-stuff backups difficult. Using a subdirectory /home is a nice compromise between cluttering the root directory (/myname) and obscurity (the closest equivalent of Windows profiles directories would probably be /usr/profiles/myname?)
OTOH, if you have a package manager and a sensible $PATH,
When I run, say, ping from a command line, I don't particularly care whether it's in
Windows needs C:\Program Files (which is just like
The reasoning behind
You try doing that with large chunks of C:\Windows on anything except a network of clones. (No, wait, Windows doesn't have a Unix VFS, so you can't attach things to arbitrary points on the filesystem, you have to use drive letters... and you don't even get symlinks to make up for it...) Yes, this is redundant on a home PC; but so are many things. Many of Windows' various NetBIOS and related networking features are redundant on anything except a corporate network, but they're still there.
/usr/local is very useful on a package-managed system - it marks out part of the filesystem which the package management is not to mess with. Anything I do there won't get overwritten next time I upgrade a package, and vice versa. I wish Windows had something similar (oh, wait, Win98 has the Web View "no user-servicable parts inside" pages pasted across precisely the folders you often need to mess with to make things work). The only Linux systems I can think of where
As for
I think the point that's missed here is that this is not a problem with the FSS, but with how RedHat (and some others) have interpretted it. /usr/bin is for standard binaries -- but what is "standard"?
/usr/bin. I started using KDE before RedHat started packaging it, and compiled it myself where it should have been -- /opt/kde. That keeps everything nice and compartmentalized. I just about choked when I started using RPMs and saw that RedHat had put everything in /usr/bin. Add gnome in there as well, and you've just got a completely stupid situation.
Personally, I don't think anything with a GUI is a "standard Unix utility", and has no business being in
Unfortunately, I'm faced with the same problem many other people are: use a package manager, or have a decent filesystem layout. I chose the package manager, because I have so much stuff on my system these days that dependency checking is extremely valuable. And with that in mind, I use RPMs for everything, and don't really compile anything myself any more (well... mostly). Yes, I could (and did at one time) get the SRPMS and change the spec file to put things where they should be, but honestly I just don't want to take the time to muck with that any more. So I'll just hold my nose and try not to look too much at where the files are kept....
I have disagreed with some of what Mosfet has said in the past, but I fell he is right on target with this critisism.
Yea, making a long, complicated path name is ridiculous and adds more complication - but the fact is that something should be done to clean up the mess that is the Linux file system.
Even 600 binary applications in one directory is stupid and overcomplicated, and setting up a system where in order to manage these binaries requires a package manager is a broken way of thinking.
I am sure that, with all of the minds connected to Free software we could come up something that is better and more manageable.
Even with your solution, which is valid IMHO, you still need a package manager to check dependencies, perform auditing, and make installation and upgrades simpler. The RPM package manager allows your to choose the root that the files will be installed under. So your solution could be used in conjuction with so-called relocatable RPM packages. You could choose to install RPMs under /opt instead of /. In fact many of us choose not to go with the Solaris /opt naming and just use /usr/local (not that it makes a difference).
Someone else also commented that many sysadmins don't put every software package in its own directory, and choose to separate run-time data, and configuration files from the directory of the package. Your statements are fantastic but I think you've gone overboard that saying that all sysadmins adhere to your standard, and thus implied that anyone who doesn't isn't a sysadmin. ;-) There isn't "one right way" for installing software; that's why GNU configure has so many options. :-)
Some distributions put packages and some packages want to put themselves into system areas such as
Take some servers for example, samba, apache, bind, dhcp, etc.
There is no need for them to be scattered into system areas. There is no need for them to be in directories which would be in anyone's path.
Services like that should be in their own directories because their execution should be done via absolute paths and only by way of a few very specific startup scripts.
Not to say I told you so, but Mac OS X abides by this. phhhhhhbt!
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
There were e2 problems with large numbers of files in a directory (ask any tradspool USENET administrator) but somehow I don't think that applies to only a few thousand.
That said, I would prefer symlinks in /usr/bin to
actual programs. Debian is 'close' to that, in
it has an 'alternatives' system... I.E. vi points to elvis, vim, nvi, ae, etc, depending on what you have installed. Misses the point in that all 'alternative' binaries are in /usr/bin.
However, if one cared, it's not too hard to fix debian, since it's moving to a more hierarchial structure: /etc/samba/* rather then /etc/smb.conf, etc.
so, with a quick script, you can take the output of dpkg -L and move all the custom directories to /opt/packagname-version/*, and all
the bins to /opt/bla-1.0/bin
--Dan
You may want to check out stow. It's not exactly what you're talking about, but does allow you to have the traditional etc, bin, lib, etc., and a mutt directory with everything mutt-related at the same time.
I keep clear of /opt because it too is ingrained in some package setups. The place for all this is /usr/local
You can overdo it on directory entries as much as you can with files themselves. Now 2000 files is a lot in one directory, but I guess it really depends on your preferences/paranoia/whatever as to how many/few directories you want & the number of files in each.
I think a reasonable compromise would be to have the programs installed in their own directories and then softlink the binaries and libraries to the standard locations. That way, you don't muck with extremely long paths and you can tell what programs belong to which packages. It's a simple matter to resolve links if it becomes necessary to move the program directory or delete it.
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.
Maybe you should actually start paying attention when Dcrappage tries to remove/purge a program. It almost always leaves junk in /etc and occasionaly in subdirectories under /usr. Usually there is a man page or two left lying around as well.
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
So ah Mosfet, how much work have you done with the FHS group? Or do you just prefer to rant...
*Condense fact from the vapor of nuance*
Why does my
$5 / month hosted VPS on linux = awesome!
We're talking command line use...
Mosfet sez, at the end of his article:
Second of all a few angry people questioned my qualifications to make the above commentary, and one person even called me a novice!
Perhaps this is because he made a novice-level comment:
I asked around and it seems they don't want to manage the user's PATH variable, which tells Linux where it's programs are.
I don't think I need to point out the glaring newbie goof here. Well, maybe I do: the shell makes use of PATH, not Linux, not Solaris, not Windows. PATH has nothing at all to do with Linux.
I am not a Linux fan-boy, so I have no idea who Mosfet is, aside from this article where he sounds like a novice ranting about nothing important. Yeah, RH is bloated. Who'd have guessed?
Edith Keeler Must Die
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.
Fermilab's computing division made an interesting effort to solve the problem of a cluttered /usr/bin directory. Their primary objective, I think, was to allow for users to choose between multiple versions of various programs. The result was UPS/UPD. I think this system was based on a kind of "setup" utility from VMS, but I'm not sure of the details. You "setup" a product, optionaly giving a version number. This is sometimes important when a newer version of a product is not entirely backward-compatable. One good example is the early versions of the Tcl/Tk interpreters.
I don't think this is an ideal solution by any means. You can quickly end up with an extremely long $PATH, and exceed the built-in limitations. Besides, putting all this in your $PATH is a shell-dependant approach, which has many disadvantages. You also have to setup every program you are using, whether you know you are using it or not. There are problems with dependencies, and all sorts of other stuff.
Even so, I have not seen any other solution in Unix to the problem of maintaining multiple versions of a product.
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.
Why not install everything into root?
/sbin and /bin local and everything else network mounted. If network breaks, how will you fix it, if all / were on network?
/tmp and /var on fast RAID0, while /home on redundant RAID5 array.
/boot, /sbin and /usr/sbin, especially login code on read-only volume for better security.
/usr/X11/*.
/lib mounted alternativelly.
/usr/bin and /usr/X11/bin is speed. The $PATH search becomes shorter and the usually cashed directory directs you straight to the proper inode. That's why Linux and Unices are far faster than Windows.
/usr/share. In non-RPM system, these would be normally in /usr/local. Making a link from /usr/bin to the package directory for the binary is slow, but it can be done the ther way round. Why it is not done, I can't tell you, but it seems that the few good and big packages do it.
/usr/doc and /usr/man was moved into /usr/share. But not exactly all (not ViaVoice) and not the old packages from before upgrade. Tell me why they did not move the old stuff over first and why did not make the symbolic link /usr/man -> /usr/share/man, so that any of the thousands users who have old $MANPATH can at least see a manual for 'man' ?
There are reasons for all this madness. Let's list them just for the record:
Because you may want to have
Or, you might want to have
Or, because you might want to have
Or, on machine used as dmb terminal you might not want to have the big and bulky
Or, because you might want to have 2 versions of
The reason for no tree under
Actually there are quite a package specific trees under
However, there are reasons for criticism:
Mandrake, for instance, adopted HFS in 8.0. All
NG (Next Generation) Unix Directory Structure Standard
/etc
/boot
/dev
/proc, maybe /System would be better
/usr, contains no files
/usr/bin, be in path
/usr/sbin & /sbin, be in path for admins
/lib & /usr/lib
/usr/man, /usr/doc, etc.
/opt & /usr/local, contains no files
/Users
/tmp
/mnt, maybe something else?
/Programs/Libraries
/Programs. Only the standard system utils should go under /Programs/Executables
First Draft
/ -- no files here, one thing unix did right
/Config --
/Config/Boot --
/Devices --
/Devices/Processor --
/System --
/System/Executables --
/System/Executables/Admin --
/System/Libraries --
/System/Manual --
/Programs --
/Programs/Executables -- symlinks only, be in path
/Programs/Manual -- symlinks only to docs. either man pages or entire directories
/Programs/ProgramName -- program executables should reside here (at least primary ones)
/Programs/ProgramName/Config
/Programs/ProgramName/Whatever -- remaining directories should be app specific
/Home -- contains no files, maybe it should be
/Home/UserName -- contains files
/Home/UserName/Programs -- user installed programs
/Home/UserName/Programs/Executables -- should be in users path, symlinks only
/Home/UserName/Desktop
/Home/UserName/Mail
/Home/UserName/Documents
/Home/UserName/Web
/Temp --
/Drives --
Unix Directory Structure - Probably been around since 1970. Really defines unix more than anything.
Gonna have to be redone some time - Or else we will always look archaic next to windows, etc.
Everything WILL be broken - Might as well make it look good and redo it all.
Case Insensitive File Names - Do they really add anything?
Include files = Evil. - Shouldn't have include directories.
Libraries - Not sure what to do with those directories, as far as program libraries. Should there be a
I'm thinking that X, Perl, Emacs, Vi, etc. would go under
I don't like seperate partitions for some of the root directories. More trouble than it's worth.
Fully open to suggestions. Is anyone interested in starting work with me on a distro project that would use such a file system?
Bryan
bryan@cooltext.com
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.
Maybe I'm just being a little too simplistic here.. but why exactly does EVERY program need to be in the path? Of course I'm not exactly a command line person... it's a lot easier to be lazy with a mouse and a big pretty menu, but nonetheless when I do use a command line I'd much rather have sensible organization rather than a little less to type.
Or is it irrelevant?
/. are.
... most things on
“Common sense is not so common.” — Voltaire
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
Just an idea: /dev but also /usr/bin, /usr/man etc.,
/rootfs.
somebody could hack devfs to not only create a dynamic
or even
Does anyone know wheter QNX's package file system has an open standard?
---
NG (Next Generation) Unix Directory Structure Standard First Draft / -- no files here, one thing unix did right /Config -- /etc /Config/Boot -- /boot /Devices -- /dev /Devices/Processor -- /proc, maybe /System would be better /System -- /usr, contains no files /System/Executables -- /usr/bin, be in path /System/Executables/Admin -- /usr/sbin & /sbin, be in path for admins /System/Libraries -- /lib & /usr/lib /System/Manual -- /usr/man, /usr/doc, etc. /Programs -- /opt & /usr/local, contains no files /Programs/Executables -- symlinks only, be in path /Programs/Manual -- symlinks only to docs. either man pages or entire directories /Programs/ProgramName -- program executables should reside here (at least primary ones) /Programs/ProgramName/Config /Programs/ProgramName/Whatever -- remaining directories should be app specific /Home -- contains no files, maybe it should be /Users /Home/UserName -- contains files /Home/UserName/Programs -- user installed programs /Home/UserName/Programs/Executables -- should be in users path, symlinks only /Home/UserName/Desktop /Home/UserName/Mail /Home/UserName/Documents /Home/UserName/Web /Temp -- /tmp /Drives -- /mnt, maybe something else?
Unix Directory Structure - Probably been around since 1970. Really defines unix more than anything.
Gonna have to be redone some time - Or else we will always look archaic next to windows, etc.
Everything WILL be broken - Might as well make it look good and redo it all.
Case Insensitive File Names - Do they really add anything?
Include files = Evil. - Shouldn't have include directories.
Libraries - Not sure what to do with those directories, as far as program libraries. Should there be a /Programs/Libraries
I'm thinking that X, Perl, Emacs, Vi, etc. would go under /Programs. Only the standard system utils should go under /Programs/Executables
I don't like seperate partitions for some of the root directories. More trouble than it's worth.
Fully open to suggestions. Is anyone interested in starting work with me on a distro project that would use such a file system?
Bryan
bryan@cooltext.com
This is the entire reason why I refuse to install anyone's KDE, or GNOME, or even QT rpm package- even on a new install. I've even taken up the habit of compiling other large packages, such as libc, because I don't want that crap thrown into /usr. Put it where the developers default is!
As a developer I demand that if you distribute any copyrighted material of mine, to put it where I, or more importantly, where the user wants.
Mosfet is entirely correct here. RPM's have caused me much more pain than any 'dll hell' on windows ever did!
-- "Perceptions create reality. By changing your perceptions you change your reality."
NG (Next Generation) Unix Directory Structure Standard
/etc
/boot
/dev
/proc, maybe /System would be better
/usr, contains no files
/usr/bin, be in path
/usr/sbin & /sbin, be in path for admins
/lib & /usr/lib
/usr/man, /usr/doc, etc.
/opt & /usr/local, contains no files
/Users
/tmp
/mnt, maybe something else?
/Programs/Libraries
/Programs. Only the standard system utils should go under /Programs/Executables
First Draft
/ -- no files here, one thing unix did right
/Config --
/Config/Boot --
/Devices --
/Devices/Processor --
/System --
/System/Executables --
/System/Executables/Admin --
/System/Libraries --
/System/Manual --
/Programs --
/Programs/Executables -- symlinks only, be in path
/Programs/Manual -- symlinks only to docs. either man pages or entire directories
/Programs/ProgramName -- program executables should reside here (at least primary ones)
/Programs/ProgramName/Config
/Programs/ProgramName/Whatever -- remaining directories should be app specific
/Home -- contains no files, maybe it should be
/Home/UserName -- contains files
/Home/UserName/Programs -- user installed programs
/Home/UserName/Programs/Executables -- should be in users path, symlinks only
/Home/UserName/Desktop
/Home/UserName/Mail
/Home/UserName/Documents
/Home/UserName/Web
/Temp --
/Drives --
Unix Directory Structure - Probably been around since 1970. Really defines unix more than anything.
Gonna have to be redone some time - Or else we will always look archaic next to windows, etc.
Everything WILL be broken - Might as well make it look good and redo it all.
Case Insensitive File Names - Do they really add anything?
Include files = Evil. - Shouldn't have include directories.
Libraries - Not sure what to do with those directories, as far as program libraries. Should there be a
I'm thinking that X, Perl, Emacs, Vi, etc. would go under
I don't like seperate partitions for some of the root directories. More trouble than it's worth.
Fully open to suggestions. Is anyone interested in starting work with me on a distro project that would use such a file system?
Bryan
bryan@cooltext.com
Unfortunately I don't have any mod points today.
To be INSIGHTFUL mean sharing a non-obvious INSIGHT.
The prior post, ironically, dumbs down the whole point of the original rant to the point of ignoring any and all deeper issues such as the desirability of elegant structure, the foolishness of relying on a single tool when this is unnecessary, and many others no doubt raised below.
C'mon, moderators, get a grip! Interesting, maybe, flamebait, maybe, but INSIGHTFUL? Geez.
--Charlie
Similarly, applications should look for their own resources anywhere in the indicated subtree, so that relative position within a package doesn't matter.
SSH is your friend.
Sorry, couldn't resist. Your point in re: symlinks is of course excellent. I will mod myself down now.
--Charlie
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
However the files which default go into the /usr/share... directory give me problems, because the share hierarchy that comes with the application usually has its own appname/version subdirectories and linking from /usr/local/{bin|man|lib|include..} gets clumsy (I think at least) comments?
- what it is the share hierarchy for anyway?
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
I think a nice solution is to keep all the files in seperate directories, but then use symlinks to put the executables in the appropriate /bin dirs.
personally i prefer having lots of seperate directories for seperate apps and using the PATH variable. with the source setup of QT/KDE, i can uninstall all KDE programs with 1 command:
rm -rf $KDEDIR
and likewise with QT. It wouldn't be hard to set things up cleaner, nicer. But if the distro/package managers want to be stubborn, i'll settle for symlinks.
Both manage the symlinks for you and, for those who don't build their own, it is trivially easy to convert existing packages or tarballs to their system.
- technik
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...
IMO, the right thing to do is to have /opt (or /usr/site) contain a directory for each package, with normal /usr/local-ish directories under each package. I.e. you'd have /opt/gnome/bin, /opt/gnome/man, etc... Then symlink everything you want from /opt/*/bin, etc. into /usr/local/bin, etc.
/opt/gnome/bin-i386, /opt/gnome/bin-ppc, but still share /opt/gnome/man). If you're administering a bunch of workstations, this setup + NFS is probably the only way to fly. You can nfs mount /opt as well as /usr/local this way.
This lets you keep multiple versions of packages online, have simple paths for users, and even (if you're clever) keep things architecture independent. (i.e. you could have
It's possible to get GNU configure to build into this kind of setup with appropriate commandline switches.
I agree that there is too much crap in /usr/bin but why /opt for applications? My first encounter with /opt was on SunOS and Solaris workstations and I really hated it. Is /opt a Sun thing? If so why would we want it on GNU/Linux. I don't know why I hated it. I don't know if its the three letter combination of o p t or what, but /opt really makes my ass itch! I prefer /usr/local much more. It just sounds nicer. If /usr/local isn't appropriate can't we atleast come up with something better than /opt?
/usr/pkg or /usr/distro or /usr/app?
Maybe
Has anyone ever thought of setting system wide stuff similar to /etc/ld.so.conf???
/etc/bin.conf and list all the directories in there.
Instead have a
Seems simple for apps in many directories instead of having to change 3 files to edit system wide path.
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?
In my company we have lots of different packages (and libraries), many having several versions. These are all installed concurrently in their own directories, like /opt/gcc/2.95.2, /opt/gcc/2.95.3 etc. We have an inhouse tool that the user can use to manage symbolic links from $HOME/bin and $HOME/lib to the executables. This allows each user to select a specific version of a tool very easily.
This works very well at our sites, some with thousands of users.
[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?
Don't you wish k5 was back up and running so we didn't have to troll /. for kicks?
what the fuck are you doing reading slashdot?
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.
There are programs in
be called by a person. They are backend routines
that are called by some other program in
So put things in
and are safe to call by a user from the command
line. Put the backend programs that are not
user-interface programs ( slave programs for
other programs ) into
Look how many programs in
man page!
The KDE backround apps and screen savers are
an easy example and there are plenty of others.
examples:
Yeah, yeah, yeah, only an MSCE would whine like that, praise M$ by compairison, and not do anything to fix the problem. Does he really prefer the hundreds of undocumented closed source DLLs typically found on M$ platforms? Pttt-th-th-th-pt!
This user has no problem managing the files and links in /usr/bin for his Debian computers. "You have to use a package manager!" he screams. Give me a break.
DMCA, Hollings, Palladium. What might have sounded like paranoia is now common sense.
Wey-hey-hey! "Let me get this straight" is back, with a vengance. We can look forward to this as an important develpoment on the Slashdot scene. After all, trolls are an integral part of this grand community, and loved by everyone. Trolling is much-misunderstodd - indeed, pissing people off on a large scale is a very social activity, done by people with lots of friends and useful things to do. Celebrate the troll!
It's the MIMIC factor!!! This has been going on for decades!!!
Problem: Unix System Architects are Architects of Technology. Architects of Product do not exist in the Unix System Houses (i.e Sun, HP, Dec, AT&T, etc...)
Product in these large Unix houses come together thru the involvement of many people in many different parts of the companies. Anyone wishing to understand the entire process would be hard pressed to do so.... because of the breadth of people and organizations involved, and limited accurate documentation
Fundamentally the layout of filesystem, contents, installation and patching is one big reactionary, mostly chaotic process that occurs late in the life cycle. I've worked as a System Administrator, Buildmeister, Release Engineer, Configuration Management Engineer, Program Manager in the Unix world starting in 1984. I worked in and with Kernel Development, Network Development, System Installation, and assorted Unix Application teams during this time frame.
Where files will reside, how they will be installed, and patched are almost always the last things considered in the development process. The decision process is mostly MIMIC'd. The people involved are generally just trying get the thing ready for QA and Release.
Downstream organizations that attempt to resolve product issues, face extremely difficult challenges when attempting to influence upstream development teams.
Working in a large unix system house, one can mostly determine which group owns the technology... but try and identify who owns the product... it will be a group of committees and teams...
Because these issues are not properly designed up front, the result is downsteam reactiveness. The end result is new efforts MIMIC the past efforts in this area, all the current Linux distributions are examples of the MIMIC factor.
Solution: Work with your System Architects to influence change in this area.
Regards, Kramer
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.
/usr/bin/1/name
and
/usr/bin/2/name
Sure, the package manager will put things in the right place. But if both 1 and 2 are in your path, what happens?
Oh well, it's a red herring anyway. These things have never bothered me yet, so I imagine there are well established ways to sort things out. You know, like the utilities that everyone wants to use just going to /bin and programs that don't call them or something in /usr/bin simply calling something in it's own directory tree, while only a link exists in /usr/bin. I might also imagine that the .deb packageing system has conflict resolution and that the package maintainers pay attention to issues like this. If it were not true my Debian would act like M$ junk.
And then you get into naming conflicts down the road.. MS has this problem now
We are not going where they did.
DMCA, Hollings, Palladium. What might have sounded like paranoia is now common sense.
Rant alert.
/usr/bin. X, went into /usr/X11R6, and all other user apps went into /usr/local/someapp if it's big, like KDE, Mozilla, Apache, Sendmail and other apps that have their own lib/ directory get their own spot. /usr/local/kde is a symlinux to /usr/local/kde2.2.1, and if I upgrade to 3.0 later, I have an upgrade path that's incremental rather than sledgehammer.
/usr/local/bin.
The DOS analogy does not hold.
Even Windows does not follow discrete directories for each application. The Windows system applications, like telnet, and the CD player and stuff that comes with the OS goes in WINDOWS\.
Then other applications create their discrete folders, path get updated in registry, reboot yada yada.
So when I built my Linux box From Scratch. (http://www.linuxfromscratch.org). I followed FHS, and because I TOO am lazy, I put all basic linux utilities into
Small apps like lsof, nmap and stuff like that, I consider modern extensions to the basic system; they go in
So I always know where my apps are. If I want to upgrade linux; install from updated source my basic tools, or I can upgrade individual apps as they come out. Now that I think about, I'm going to put FHS stuff in a top dir called LINUX, and the rest in their own directory. Oh, but how will it boot? Never mind.
In sum, with a little thought as to how one operates one's OS over years (if you have that kind of experience), then one can devise a layout scheme that works.
Aside from that, my flameware contribution of the day, is that Linux needs to care not what works in Windows; because Windows is the mail order catalog OS, and worry about Apple's design innovations. Whatever Apple is doing is way better than anything either Linux or Windows is doing.
The only thing Linux has going for it is foremost 1) anarchy, it's what you want it to be;
2) Enlightenment 0.17, if we want to get behind something innovative that's it, hordes of people should be building plugin architecture for that with voice interface or 3dworlds; or some other "oo, ah" factors. Trust me, transparency is not 'oo, ah' and who gives a rat's ass if works in KDE. KDE and GNOME are both rip off interfaces that bore the shit out me, and make wish I had the $$$ for a PowerBook. I can hear you now "It won't run on my 486." Fuck you and your 486, arguments like that will keep Linux in 1990. If you like coding png bullshit into KDE, save your tendons, and do something better. KDE is outdated, I don't care if you add KOnCD, and bla bla bla Icon set. It's boring and world does not care.
3) GNUstep, if you are gonna back a rip-off; choose to rip-off something good. Furthermore, if you're gonna rip-off, rip-off 1) without being obvious, 2) try to make it better. Have you seen the screenshots to GNUstep? The widgets look like Athena from the 80's. You gotta do better than that.
Seriously, the mentality of "It's gotta be NOT Windows" really sucks. It begs the question; "what's it gotta be." If the answer is, "ummm... hybrid of everything in existence (KDE, GNOME); then we lose big. Critics allege well that open groups can't design interfaces. And they may be right, because the Enlightenment team is pretty small compared to KDE or GNOME. Those guys have a design reference. Shit as soon as MacOS X had zoom icons, so did KDE. That bites.
Open Source developers should leave the KDE and GNOME work to Red Hat and other commercial vendors. The little guys have no stake in whether Linux beats Windows at being Windows-like. That's their installed-base issue to overcome. Ours is "cool factor". And being an anarchy is not cool, if the mob comes up with suede loafers, used Levi's jackets as the new "cool."
I know I speak for many gui afficionados. "Unless Linux comes up with something better, soon, I'll be a Mac convert in a year." Come on... compete!
-Nate
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?
But that's OK, since Mac OS X's apps are almost always self-contained, making installation a simple drag and drop from a disk image. (Apps in Mac OS X are actualy directories full of stuff that, with a bit in the file system, will behave like a single file.) Only some "weird" apps and Apple's own stuff use the standard installer of Mac OS X.
But for the UNIX stuff, Fink does a great job, with the help of the Debian package manager (you know, "dselect"). Installing a rootless XWindows and Gnome is almost too easy.
- Benad
As one of the current FHS editors, I guess I'd better make some response.
/bin directories with a massive path doesn't help, since the binary names can't clash anyway. And I have 1211 entries in /bin, but I have 561 packages installed (Debian unstable).
1) Replacing a handful of
2) The GNU project has been pushing for a libexec/ dir for years: this would be where non-PATH binaries live (ie. obscure things only invoked by full path name, usually by other programs).
3) Al Viro once suggested altering shell semantics so that a filename with a / in it would still search the path, effectively giving another namespace, eg "gnome/hello --version" would not just search in "./gnome/" as it does now. For those with a passion about these things, this might be an interesting avenue to try.
Note: the FHS http://www.pathname.com/fhs is entering 2.3 discussions, and I imagine that libexec will be proposed again. This is your chance to make your voice heard (but read the latest draft first, especially the Purpose section).
Finally: remember that ALL standards stifle innovation, and that something radically different won't be compliant. That's FINE: there are no FHS police 8)
Cheers!
Rusty.
thanks for pointing that out...Rox is fast and friendly. Even works well on OpenBSD, seems as if everything else is so linux-centric these days :(
I just wanted to give my personal view of the situation. Hierarchal filesystems like the Linux distros use are great. Flat file systems are great. Filesystems like windows uses (one directory=one program) are great. All at their respective times.
Personally, I don't see why everybody is is hyped up over how to organize a static filesystem. It is clear that, even theoricially, no way is perfect. The solution is simple, put every file in a database with an arbitray amount of tags. These tags can be of mime types, the package it belonged to, the version, a user specified catagory etc, etc...
This dynamic files can be arranged at any time in any structure the user wants. It could happen dynamically and transparentally.
please, all this bickering over an archaic idea could be put to good use arguing over what database to use for the the filesystem.
It works pretty well, but still all programs that should show up in the Gnome or KDE menus etc. are still installed along with those packages. It is also often a lot of work to get programs to not install in /usr.
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
/usr/bin did the usual thing, ls /usr/.emacs/bin showed emacs binaries, cd /.emacs switched you to a "view" of the filesystem restricted to emacs files, and all such nifty stuff. These ".emacs" type directories were internally generated by the kernel, and were invisible when you normally said "ls". It rocked the pants off slackware's /var/adm/packages based manager, and sometimes, I think, off rpm too, maybe.
/.emacs/usr/share/docs; and then you want to switch to docs of vim, and you had to go all the way down. This was fixable in theory.. and would have been worth it too..
/.emacs and tar -zxvf emacs-upgrade.tar.gz. Dependencies can be a bitch.
/.emacs; tar zcvf ~/emacs.tar.gz *. This sort of thing, with added semantics like tar options to avoid .o file etc. can be marvellous for developers, compared to what's there now.
A good many years back, I used userfs and Linux-1.3.47 to hack up a file system for managing packages. This was for a course project in my undergrad sophomore year, six years ago. Semantics were nice: ls
We learnt some valuable lessons, especially applicable to developers of MOM and similar systems:
On the long run, it was systematic, and yet cumbersome to use. Suppose you cd
We only grazed the issues modification and upgrade. The idea was to cd
Lastly, it (automatically) supported one nifty feature, that of cd
SO I think there's potential in this direction, for stuff inconceivable from user space.
I'd love to be contacted with ideas/suggestions/questions/whatever, or if you want me to dig up the code or documentation.
"PATH searches are more expensive than bin lookups"
If we're discussing the principles of how things work, why not improve how PATH works?
When the system starts, have the system go through the PATH collecting all the file names and making a quick-search table. To find an executable it would just look in this quick-search table, not in the PATH directories.
Then the size of the PATH makes no difference at all. PATH searches will be equally quick regardless of the number of directories.
(Implementation details: The system must rebuild the quick-search table whenever files have been added or removed in any directory in the PATH, or the PATH itself has been modified.)
Terrorists can't threaten a country's freedom and democracy. Only lawmakers and voters can do that.
There are nefarious forces at work here. Lots of tools to use = good, path modifications = bad. gobs of files in bin = bad.
I think many OSS projects have too great a footprint in the bin directory. When a big project runs it should run in it's own directory, because modularity is *very* important. You think Linux has lots of stuff now just wait 5 years!
Of course, there's one problem with modularization how do you find the "right" version of the project? It's simple, you put a link or small bash script into bin that has the job of invoking the "big project" and doing it in the proper place. And it should only be 1 file per project. You heard me right 1 file! If you can't figure this out you shouldn't be writing big projects in the first place.
If you don't think 1 command can do any amount of processing necessary, you haven't used emacs(shudder) lately.
Here's an example:
I don't care how many files are in X11, but I'd like to have only 1 command to deal with it. In an ideal world you'd type in x11 -start or x11 -configure or x11 -do_my_laundry and one file and only one command would do absolutely everything. Actually... better yet, it should be x -configure or x -do_my_laundry with x11 also available, and just happening to be the default version invoked. (unless of course you were running some other type of x or something...)
Anything else is just a pain to use.
All that said, if you've got 2000 commands in your bin directory and each one represents a whole project with valid, original and useful functionality that you commonly use. All I've got to say is ye haw! (If only it were true...)
It should be perfectly possible to make using rpmdb a bogus filesystem, which follows the hierarchy defined by distributor, mount it on /packages.
/packages filesystem to browse and organize it.
It would either something like proc, completely in RAM, or data system actually written to the disk.
The tree would end in symbolic links to the actually installed files. Every package's own directory would have file DESCRIPTION, that contains standard RPM header, executable UNINSTALL for rpm --erase or VERIFY for rpm -v.
This way you would have the traditional {/usr;/usr/bin;/usr/share/doc} system to actually run Linux and
Any opinions?
Petrus
While you're at it try reading your own site without JavaScript. You have no genuine need for JS at all and yet your documentation—like your FAQ—(ostensibly there to persuade people to get your distro) can't be easily read without turning on something that is a continuing security issue and pain in the ass. I share your interest in a lean operating system distribution based on the Linux kernal but I was forced to give up on your GNU/Linux distro because I use links.
Remember: the web is about global access. Keep all of the web's users in mind.
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.
What Unix should really do is have executables be directories, rather
than be individual files. All the auxiliary files, man files, help
files, and dynamic libraries would live in this directory. Then if
you want to move an executable to a different place, you'd only have
to use "mv", rather than rebuild the software package from source. To
remove a package, you'd only need "rm -r". Package management tools
would no longer be necessary at all. (You might want some dependency
management tools, however, to tell you, for instance, that if you
remove package A, that package B will not be able to work.)
This, of course, would require a complete rearrangement of Unix, so
it's not likely to happen. To do it really right would require kernel
support to support executable directories, but it could be finessed by
having "bin" directories contain only symbolic links to the real
executables. An executable *can* figure out where it really lives in
order to find auxiliary files that are located in the same directory
as the executable, even in the face of running through a symbolic link
(Python does this, for instance), but it's a fair amount of effort so
very few programs actually do this. This capability could, of course,
be provided by a library, however, if the Unix community were to wish
to encourage developers to make all Unix software to work this way.
|>oug
We need this directories.
We cannot have part of directory on the network, part local read/write, part local read-only.
Stuff in
If we had it all in
Bug you could not connect to network, since all the commands that start, run and diagnose the network are in
What if we did something like this:
Each software package you download comes in one big file, but instead of extracting the thing all over your file system, you just stick it somewhere in a packages hierarchy, like so:
/packages/graphics/gimp.package
/packages/net/mail/pine.package
etc., and write some software which will automagically go inside these packages and read any files from there. Then installing/uninstalling software is as simple as adding/removing one file.
Other than some possible efficiency problems, is there any other issues with such a scheme?
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.
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.
I knew I should have hit preview...
some of the comments I've read here in the last 20minutes suggest to me that some people would be happy if they could do away with subdirectories completely and just have:
/home, in which each user will get one subdir each, but no subdirs within it!!!
/bin
/boot
/dev
/etc
/home
/lib
/mnt
/proc
/root
/var
and no subdirectories at all!!! except for
'Welcome to Rivendell, Mr. Anderson...'
as a newbie to linux knowing where to put and how organize files would help alot!!!!! I haven't found any info on this yet and at this point I only know enough to be dangerous. A book I've purchased suggests that program files (software packages) go to /usr or /opt? which is it?
Consider the following. ln -r /opt/FOO/bin/foo /usr/bin/foo. ln -r /opt/FOO/man/man1/foo.1 /usr/share/man/man1/foo.
/opt/FOO, and the corresponding reverse symlinks would be deleted as well.
It works like a symlink with a constraint. Upon removal of the original file, the symlink gets removed as well.
/usr/bin could now have 1200 files, but you could remove the entire package with an rm -rf
Something like this could be implemented if the "directory entry corresponds to inode" becomes a two-way relationship. Intuitively, that seems to break a basic philosiphy, but what's the tradeoffs?
I think you are missing the point here. The reason you claim to need LFS is that you do not have to use a package management system. If I understand correctly, that is because LFS does not include any sort of Package Management tool equivalent to dpkg or RPM. The solution gowen proposed is simple - don't type "dselect", don't futz with .rpm files. Install crap.tar.gz contents in /usr/tuttifruitty if you like. Then you have no problem. Debian won't try to overwrite anything, just don't encourage it to by doing something stupid like typing "apt-get crap" If you ignore the existence of package manager, then it won't try to manage your packages.
/usr/local/. That way the Debian Package Manager won't touch it - while it controls the rest of /usr, /usr/local is off limits. The other option is don't screw with the package manager if you don't want package management. LFS is an interesting Distro, but not because it stares blankly at you when you type "dselect".
Why does LFS neglecting to provide a package manager count as an advantage? It seems like you would complain about the God awful KDE interface ruining your user experience every time you kill GNOME and click on the KDE option in XDM. So your proposed solution is to install a distribution that doesn't provide an option for KDE.
Does this make sense to you? The proper way to install stuff by hand on a Debian sytem is to place your stuff into a subdirecotry of
Hmm I've just got an idea... (this might have been posted, but there is lots of posts to read thorugh).
/usr/bin but uninstalling a program would be as easy as removing its dir from the real fs.
What if the entire FHS thingie was a virtualfilesystem like proc or devfs.
You have real filesystem organized as a database where each app,progg,command,whatever had its own dir. And all was added in a convinietn database at the beginning of the fs. When the fs get mounted the kernel reads the database and creates a virtual FHS compilant filesystem.
It will still be lots of files in
With proper handling this could solve a lot of problems AND remove the FHS policy from userspace.
If you use layers...
RealFSFH --> FHS --> whatever-FH-you-want
and files shuold be accesible at any layer...
Perks:
Package managment would be as easy as just puting the packet file on disk...
Files can be accesed in diffrent FH layers...
How files really are managed could be a problem between dist, kernel and fs developers.
User can have their FH in anyway without breaking any packages.
Not so good:
RAM!!! It's going to be big db's...
But we are moving towards more ram anyway, and the db could be optimized to just manged bin, and conf files.
Well I don't know, bit of a radical change but it might be worth it...
You might eaven be able to speedup file manipulation considerably
what about LD_LIBRARY_PATH or ld.so.conf and LIBRARY_PATH or long gcc -L lines.
/opt to stay off my system.
Path is just the tip of the iceberg when installing software under their own directories. You also need to tell these programs where to find their libraries. And if these programs have the same libs then you have redundancy or you must know about and fix the issue, or you have to have installed the library first in a commonly searched directory...which is the current norm.
Yep, I will thank all fans of
NR
he he he
You've really found a good way to take a minor problem, and turn it into a major issue for the user. When i want to start a program i only use occasionally i don't want to have to look through the whole file system for it, i just want to type the name and have it start. Your way has no real benifit, casues most users lots of problems, and may end up as a security problem.
in a lot of apps, and tends to have far
deeper directory trees. Better to go with
To see the depths
to which this insanity can go, look at building gcc
for multiple paltforms over LUDE (logitheque
Universitaire Distribuee et Extensible) Don't
get me wrong, the package does it's job, it's
just that the result is pretty ugly...
(gcc & LUDE both take into account architectures,
so you have nested architecture trees three or four
levels deep.) the rationale goes back to the bad old days
when
potentially on different types of workstations.
With modern hard disks, this case should be
far less prevalent.
/opt came about for third party commercial apps,
originally, I think for Solaris systems. It was an
attempt to give ISV's somewhere to put things that
did not upset those persnickety Sysadmins, who all
had very set ideas about how
used (usually, there was no isolation of packages,
just a jumbled mess.)
/opt based setups tend to be younger and leaner (
ie. they do not account for multiple architectures.)
They often make use of the one directory per
package convention, So they are usually the better
choice.
That said. It doesn't actually matter whether you
use
intractable mess unless you use some form of package
encapsulation. (ie. a la depot, or one dir/app.)
Package encapsulation is what is important.
... To have catagories for small apps/single binaries
/opt
/usr/bin/mm for multimedia
/usr/bin/system for system apps
/usr/bin/editors for text editors
/usr/bin/graphics/ for graphics
/usr/bin/net/ for internet/networking
and set the path to use all of them.
Large Applications go in
/opt/kde
/opt/gnome
/opt/staroffice
/opt/jdk1.3
Data files go where the app wants them. usually
/usr/share
and so on.
This works quite well. I dont have thousands of binaries in one directory, and I dont have a huge $PATH. It also makes finding and deleting unwanted programs easy.
I use a Redhat system, but I generaly dont touch RPM, I compile from source, or extract the rpm and install binaries manually (Something tells me I should get slackware). If RPM gave you more control over where things went, then I would use it. But it has too many limitations at the moment.
This does not work. Many packages install files outside of their directory. For example, I consider start menu shortcuts, dlls in c:\windows, and desktop shortcuts to be part of the package.
As just one example, Microsoft IE6 installs dozens of files outside of the main program directory.
I assume you are talking about executables or DLLs, in which case Microsoft has had a program available for a long time called Dependancy Walker.
I agree that it is easy to see what dlls an .exe uses. But the reverse is, as far as I know, completely impossible on Windows: namely, given a dll, output a list of all .exe's that use that dll.
On linux with package managers this is a triviality. And you have to agree that this is useful functionality--if I want to know whether a dll on my system is needed or not, then I need to have a list of what exe's use it.
Perhaps you mean to say
"underfuntional bloated web interfaces are your enemy"
or
"superfluous GUIs suck, CLIs are your friend"
or something along those lines. How about "libNEWT is your friend"?
I still support "SSH is your friend" despite it not being the point you seem to have intended, unless you meant it in reference to Web management consoles exhibiting great suckage compared to more straightforward textual interfaces. Then perhaps the SSH statement fits.
WRT port services, wouldn't netcat be a better answer than telnet? The way I see it, "telnet is your occasionally useful historian" for legacy purposes only.
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.
In this regard UIX has a real problem. It seems a lot of people think the current UNIX way is the only way to arrange files.
I am beginning to believe the unix (linux in particular) crowd has blinkers on, and will not see the faults of their system.
that has to propagate itself through that mess.
Almost every DLL, OCX, ... goes into /Windows.
Sure symlinks do not exist. The closest one can get is shortcuts or the old join command, but neither works for this.
Any complaints? Nope. Just reformat and reinstall everything once in a while... About every 2 to 3 years is perfect: just in time for a new OS version (that will not work with the "old" hardware anyway) - i.e., if the system doesn't faults before...
Did I also mention the Windows registry?
Isn't this like the Macintosh had since long ago? Pretty clean solution.
BTW, Windows adopted a less clean variation -- associating file extensions with executables.
MIME types would had been a better approach, and more *nix-like.
I only need to find duplicates at
/usr
dpkg -L `dpkg -l \* | tail +6 | tr -s ' ' | cut -f2 -d' ' | tr \n ' '` | grep
with | sort | my.a.out to probe if there are bugs, xD
Use good old doskey or the 4nt aliases to create macro's, either to the executable or to the shortcut. Currently my 4nt startup batch consists of more than 100 aliases to programs. I only use the commandline to invoke these programs.
arleo
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.
Try Debian instead.
$ apt-cache search ldap2
libldap2 - OpenLDAP libraries.
libldap2-dev - OpenLDAP development libraries.
libopenldap1 - OpenLDAP libraries (obsoleted by libldap2).
$ apt-cache show libldap2
Package: libldap2
Priority: important
Section: libs
Installed-Size: 430
Maintainer: Wichert Akkerman
Architecture: i386
Source: openldap2
Version: 2.0.14-1
Replaces: libopenldap-runtime
Depends: libc6 (>= 2.2.3-7), libsasl7
Filename: pool/main/o/openldap2/libldap2_2.0.14-1_i386.deb
Size: 174132
MD5sum: 2a3b44f7c257d854e0a700624739e9ed
Description: OpenLDAP libraries.
These are the run-time libraries for the OpenLDAP (Lightweight Directory
Access Protocol) servers and clients.
Somewhat less than a full generation old in the Debian camp. OpenSSL is at least 0.9.6. Pine has to be built from source so as to not violate its copyright, but Debian provides the source and Debian diffs in their package manager all set to build. As for installing libraries, it works out fine if you use the package manager to do it. If you can build the libraries from source, then you are competent enough to make a package from that very same source. If there is a problem, then using the equivs package can convince your system that dependancies are met.
As for having the Package Management system look around your system to satisfy dependancies, perhaps Red Hat should do that. Debian dependancies are more sophisticated that "is that file present?" They need version information as well, which can be troublesome if you consider the variations possible with open source. Debian can only verify binaries which it generates. The best way to do that is by downloading directly from their archive.
How in the hell was the parent moderated up to 3?
/opt as part of a solution, for example. Slack is most unlike Red Hat and its many derivatives.
/usr/local useful. Perhaps the solution for you would involve /usr/local/apps, /usr/local/utils, etc. (/usr/local/etc? :P) Everything you compiled belongs within /usr/local/ if you choose to adhere to the guidelines set out in the FHS. Within that framework, you can organize by function, or whatever else you fancy.
/usr/internet or /usr/editor exists in the /etc/alternatives directory. Try "man update-alternatives". While /etc/alternatives/infobrowser exists for .html help pages, perhaps there sould be an /etc/alternatives/webbrowser entry.
/usr/home, provided all PATH environments are properly configured. Keeping personal files scattered throughout /bin directories is a better way to "sure-fire confusion".
/bin directories, try browsing at a high moderator number, and see a range from:
/opt, with appropriate links in /usr/bin. For systems w/package management, make that /usr/local/bin as in #2595732
/usr/bin, which calls the appropriate executable depending on its flag;#2598189
/bin subdirectory in the /usr hierarchy. ##2595676
I have seen multiple solutions posted while browsing at moderator level 3. Am I going to have to start browsing at 4 now?
There is no standard in Windows like the FHS, only Microsofts latest guidelines which don't to my knowledge address proper Start menu behaivor. Every app I know that tries to put a shortcut directly in the Start menu gives an option between having it in the start menu, on the desktop, and in the IE launch bar. The exception I've seen is AOL launcher, primarily because it is preinstalled. I will agree that the Windows Start Menu needs a coherent management scheme published.
Limiting your experience to Red Hat and Mandrake and then proclaiming anything about "everyone's guily" is silly. Mandrake is all but another distribution of Red Hat. Might as well make a blanket statement after using Debian and Progeny. There are many statements praising recent Slackware versions for using
The FSS is not intended to make organizing one's hard drive any easier, but to make distributions less likely to interfere with your organization. That is what makes
As for the distribution system, I don't see that such arbitrary classification is as useful for filesystem layout as grouping by the application's title. There are better places for those distinctions, like in the "Start Menu". In Windows, ideally, everything is installed into its own directory as much as possible, while the Start Menu is grouped more by user functionality.
In response to the anonymous coward of message #2596088, in Debian, the best place for such things as
/home is far from irrelevant. It is the only place where non-sysadmin related files should reside, unless they are being served over a network or removable media. Any non-root user should never have reason to leave
The best way to have an organized hard disk is to have a reasonable set of guidelines you follow on filesystem layout. After that, just follow them! The best way to fight entropy, is of course, to do something useful! After you die, then you should emprace entropy. I suspect that the rhetoric of apathy in these two statements garnered your 2 "insightful" moderations. Give me a break, learn some discipline and organization.
----
As to the solutions that "nobody" has offered to this problem of clutered and unwieldly
1. No problem, who cares what the Filesystem looks like when the Package manager suits your needs;
2. Use one of the automated soltions listed at the Opt Depot like GNU STOW;
3. Keep all "applications" in subirectories in
4. Keep only one symlink for any "application suite" in
5. My least favorite - expand your PATH variable to include every
Note to self:
##2596072 gives a reference and addresses the shortcoming of current Debian Package Management - concurrent divergent versions of applications.
prime example :
redhat 7.1 comes w/ an outdated version of openmotif (uil compiler doesn't work w/ our software due to some unapplied patch...dunno...ask the programmers) - so I grab latest source and/or patches (patches in the openmotif case), update the RPM to that level, rebuild w/ a suffix indicating my modification, TA-DAA - done in ${BUILD_TIME} + 5-30 minutes (even for those long pissy kernel and glibc RPMS...)
and it makes it great to add in commands/scripts to %post to do things like update lilo or other config files (so that you don't end up w/ the guy who just blew up last week's server by spilling Hi-C into the power supply going "gee, uh I upgraded the kernel, rebooted, and it just hung..." )
so there - package management is a good thing - but then again, so is a clean directory structure
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
On my RH systems, I often download tarballs and build from source in /usr/local, but I install using
checkinstall
which creates an RPM on the fly by monitoring the
package installation. Then I can have the benefits
of package management (especially uninstall and
query capabilities) while keeping up-to-date on sources.
Please note the phrase STUPIDLY COMPLICATED.
It wasnt meant to be a serious suggestion
What happened to the art of sarcasm without the overuse of smileys. It died.
Andrew Milne
Flame my comments, not me.