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?
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.
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
/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?
Which anybody not using Windows can tell from the fact that your apostrophes appear as question marks due to Microsoft not using ASCII. Please fix...
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger