[uClibc] Re: filesystem layouts (was Re: static compiling)

[Rob Landley]

On Wednesday 18 February 2004 10:26, Bennett Todd wrote:
> I can well believe that the initial introduction of /usr was just a
> kluge to get around disk space limitations.
>
> And it's surely the case that private systems, special-purpose
> embedded systems, and the like have no need to be consistent with
> other plans.
>
> But the Filesystem Heirarchy Standard
> <URL:http://www.pathname.com/fhs/> does carry a lot of weight and
> support; it's a rendesvous point where an implementation conforming
> to the standard is provided by distribution creators, and is
> expected by application creators. What's more, it's designed with
> the hope and intent that it can have applicability across all
> Unix-like OSes.

i doubt the creators of the filesystem in the linksys routers care too much 
about being the same as Solaris.  I doubt that the MacOS X people care much 
either.  Personally, I care about what makes SENSE, and what's compatable 
with existing apps.

The symlinks make userspace not care if they're looking for /bin/sh and it's 
in /usr/bin/sh, hence backwards compatability with "#!/bin/sh" and 
"#!/usr/bin/perl".

> /{bin,boot,dev,etc,lib,sbin,tmp} should suffice to boot a system
> single-user; stuff in /usr should not be needed until going
> multi-user.

Assuming you're not using a boot CD to repair a heavily horked system, then 
you probably want network access to copy stuff over from backups.  ssh and 
scp are in /usr/bin.  On the off chance you need to chroot, that's in 
/usr/sbin.

Pointing at a standard and saying "it should work this way, because the 
standard says so" is circular logic.  Standards grow old, you know.  They 
become obsolete and stop being supported all the time.  "Is anybody anywhere 
relying on that behavior?" is a much better question.  Document the 
divergence and move on...

> Everything that's writeable should go into /var (except
> for /tmp).

And /home, presumably?

What about /etc/mtab?  Or /etc/resolv.conf in a dhcp environment?  If 
/etc/shadow isn't writeable, then the users can't change their passwords.  
Want more examples?

(P.S.  I _was_ suggestig making /etc a symlink to etc/var, by the way.  But 
that was just a suggestion... :)

> /tmp and /var/tmp differ; the first can be expected to be
> cleaned out on every reboot, the latter should generally have a much
> longer expiry time, if it's auto-cleaned at all.

A temp directory that isn't auto-cleaned?  Are you recommending manual 
intervention, do you think hard drives are so big today nobody ever needs to 
delete anything, or are you acknowleding that /var/tmp is almost never used 
on a modern system?  (I've been running Fedora Core 1 on my laptop for months 
now, and /var/tmp has nothing in it (ls -la shows . and .. and that's it).  
The datestamp on the directory says the last time its contents were touched 
was two days ago, and I'm fairly certain that was me. :)

And "much longer than every reboot" is too vague a metric to be meaningful, 
since reboots aren't a scheduled event anyway.  The last time I rebooted my 
laptop was to install the 2.6.2 kernel (although I've suspended and resumed 
it dozens of times since).  On linux, reboot isn't necessarily a regular 
enough event that you can put particularly fine grained policy around it: 
when it happens it's quite possible you're going to juggle hardware.

I know my usage patterns aren't everybody's usage patterns (neither is a 
linksys router's, neither are Sun and Debian workations at UT).  But just a 
little hint: logrotate isn't put off until the next reboot because it's quite 
possible you'll fill up the partition.

> initrd is a lovely hack, I've come to be very fond of it, but
> it's not a cross-OS standard, whereas the FHS strives to be.

The depth of my lack of concern for Solaris or HP-UX support cannot be 
expressed in words, but how does making /tmp and  /usr/tmp a symlink to 
/var/tmp violate this from an application compatability standpoint?  You have 
some dependency on what is or isn't in a temp directory?  (And oddly enough, 
on my fedora core 1 system /usr/tmp _is_ a symlink to ../var/tmp.  I don't 
think I did that one, either...)

> Again, don't get me wrong, I don't see any reason for an individual
> not to lay out their own system according to whatever logic suits
> them. But blanket statements that the /bin -vs- /usr/bin separation,

The /bin vs /usr/bin separation was the blanket statement.  The rest were 
largely comments about making a boot from CD system.  This topic came up 
because somebody was trying to figure out if something should go in /bin or 
/usr/bin, which is _always_ a waste of effort these days.

There's a large installed base of programs that get confused if the 
directories change out from under them, and THAT is the reality that you have 
to remain compatable with.  (You can always document a new "standard" and see 
if anybody salutes...)

> and all the other parallel ones, are a completely obsolete hack that
> should be discarded, do not (in my opinion) sound like generally
> sound advice.

The distinction between /bin and /usr/bin is a historical relic traceable back 
to a specific PDP-11 system running out of disk space and leaking into what 
they called the /home partion at the time.  (That is indeed documented.  It 
took them a few years to move user accounts into yet another partition, they 
had to get more hardware first.)

I agree that there is still a need to be able to access binaries at the paths 
/bin and /sbin, which is why the symlinks.  But the value of the actual 
separation is nil.  These days it's outright _silly_ to have half the OS in 
/root and have an unmatching half in /usr that could potentially segfault 
because your /usr/bin binary and /lib/libc.so.* don't match.  When something 
is silly to do on a modern system, and causes more potential trouble than any 
potential benefit, it is obsolete.  (Heck, you can't have THAT much 
decoupling between /boot and /lib/modules; the only reason /boot exists as a 
separate partition is due to BIOS limitations.  And we all acknolwedge THAT 
one as an implementation hack...)  How long it takes the standards to catch 
up is another matter.  Good standards usually do trail reality.  Hence the 
backwards compatability symlinks...

The rest of the filesystem is a large mess of halfhearted extensions, but they 
can largely be ignored.  Moving most of the stuff out of the root directory 
to /usr was a cleanup that didn't go far enough.  Sprouting /usr/local and a 
mirror of the /usr directory under that was _silly_.  Deciding that 
/usr/local was a bad job and sprouting "/opt" and "/misc" was sillier.

The point at which I decided it had gone to far was when an ex-coworker of 
mine built a package management system that installed everything into its own 
directory in /opt, and put symlnks in the rest of the OS into /opt.  (Isn't 
"opt" short for "optional"?)

Merging /bin and /usr/bin is something I can't ever see a reason _not_ to do, 
but that doesn't mean you have to.  You could put it in /walrus if you wanted 
to.  I don't care.  I don't have to use it... :)

> -Bennett

Rob