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?

Comments

I think it is better...

[nll8802]

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.

the BeOS filesystem

[codexus]

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.

Re:The Alternative?

[Meleneth]

*sigh*

has anyone heard of symlinks? the theory is very simple - install the app into /opt/foo or wherever, then symlink to /usr/local/bin. yawn.

or is that one of those secrets we're not supposed to tell the newbies?

Why?

[DaveBarr]

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.

I have played both sides of this arg

[ACK!!]

I have been lazy before with my linux box and let package management systems lay out files all over the freakin' place.

I have done things the "right" way (according to my mentor admin anyway :->) with my Solaris box and followed this standard:

/usr/bin - sh*t Sun put in.

Let pkgadd throw your basic gnu commands into: /usr/local/bin

Compile from source all major apps and services Database services, Web Servers etc...etc.. and put them into /opt:
/opt/daftname

symlink any executable needed by users into /usr/local/bin
(if you think like a sysadmin you realize most users do not need to automatically run most services)

Any commercial software goes to /opt and put the damn symlink in /usr/local/bin.

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 /usr/local base.

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.

Re:The Alternative?

[MarkCC]

The system does not go through all of the directories in the path every time you type a command. No shell that I know of is stupid enough to do that.

Shells do a lot of cacheing. The most common strategy these days is to automatically regenerate the path cache every time you change your cache. Many shells also have a way of manually directing it to rebuild it's cache.

With an intelligently designed cache, the memory use difference between cacheing binaries from a small number of huge directories, and a huge number of small directories is small to zero.

That said, I still disagree with Mosfet. I've also done time as a sysadmin. Personally, I think that having the binaries stored together is preferable, because I'm capable of using a package manager to manage my applications; but many of my users find it extremely difficult to deal with paths. (Not to mention the degree of sensitivity it produces when you change a system. If I use RPM to install a new version of something, then the RPM database id modified with information about the new version. If I install something in a way that modifies the directory heirarchy, then I have to make sure that every user of my system correctly modifies their path.

Personally, I think RPM style package managers are a huge step forwards, and they make the admins job a lot easier. Why should I care that there are thousands of files in my /usr/bin, as long as I have a useful tool for managing them?

Now, data files are a different matter... But they get separate directories in the current style. So that's not a problem.