Re: RFC

["Robert W. Current" <current@hel-inc.com>]

Jim Knoble wrote:
> 
> Actually, /usr/ is really supposed to be the preeminent sharable
> hierarchy.  That's why all the mutable stuff got moved to the /var/
> hierarchy (e.g, logs moved from /usr/adm/ to /var/log/, mail spools
> moved from /usr/spool/mail/ to /var(/spool)?/mail/, etc.), and why
> architecture-independent stuff lives in /usr/share/ while
> architecture-dependent stuff lives in /usr/lib/.  Putting `local'
> system-specific binaries in /usr/local/ is nonsensical; then you end up
> having to export /usr/bin/, /usr/lib/, and /usr/share/ separately (not
> to mention /usr/X11R6/ and whatnot).

Actually, I tend to agree with Jim here.  The crucial part in my mind
is, defining what a complete, runable system with /usr unmounted should
work like.

But logic follows, if /usr is to be the default sharable, maybe /home
should be /usr/home (but I don't intend on pushing that, just following
the logic for the sake of logic).

This is all fine and dandy from a structural point of view, I have
always been more incline to export /usr/local (where all my fun apps
are).

Still, steping back, there seems to be a common feeling among
administrators I have spoke with that /usr unmounted, you can do
anything you need to do "recovery" wise to a system.  But at the same
time, /usr has long been the place where "standard" software (that is
not "base" or "required," but meaning the stuff you really can't live
without sometimes even in a recovery situation).

Then, there is the "iceing on the cake," the userland apps.  They are
the things you have to manage most frequently as an admin.  Users coming
up and saying "I need the new version of XYZ, I have a new project that
needs the new features" and your digging through /usr/bin looking at
their stupid app mixed in with the thousands of other apps, wishing you
could "own" /usr/bin for admin purposes, and their shit should be in
/usr/local/bin.  That's one of the appeals of BSD and Slackware systems.

So, that being said, I personally HATE /opt, because shit in /opt never
follows bin/ etc/ type logic, and I always have to go back into /etc and
edit paths for the mess that is in /opt.

But, maybe that can/should be cleaned up rather than thrown out?

> Here's what should be done with /usr/local/:
> 
>   rm -rf /usr/local/
> 
> System-specific binaries (and libraries and scripts and configuration)
> ought to go in a completely different tree.  Sun's /space/local/ would
> work, as would a simple /local/ (which is what i use).

Ok, define "System" ;-)

Better, maybe the logic of FHS should be considered.  What's system
specific?  What's likely to be exported?  What is essential?  What is
"basic" and should that be separate for the 200M to 5G of other binary
crap that has to go in some bin/ somewhere?

It's all so frigging vague that if your suddenly required to admin a 4
year old system, your going to spend an enormous amount of time figuring
out what the hell was going through the last admin's head.


> : Personally I think it would be good that if you accidentely
> : destoryed your root partition, you didn't have to overwrite
> : 500+MB of perfectly fine /usr during a reinstall. :)
> 
> Machines, busses, and storage devices are all large and fast enough
> nowadays that an extra 15 minutes and 500 MB are trivial.  If you trash
> only your root partition by mistake, those extra 15 minutes will help
> you remember not to do again next time.  If it's the disk's fault, you
> really should be replacing the disk anyway.  If it's because your
> machine was cracked or trojaned, you ought to be spending too much time
> trying to track down the unwelcome visitor to care about those extra 15
> minutes.  Get over it.

Jim, I agree with MOST of what you said.  But 500M being trivial because
of hardware advances is just a bit over the line...

500M is never trivial.  That's where system admins start to differ in
their ability to handle frustration.

I'd like to see a bit more open attitudes towards looking at how other
UNIX systems handle this.  Frankly, I like how FreeBSD handles this,
everything in /bin I understand the reasons for, everything in /usr/bin
makes sense, it's not "needed" in bin, but it's needed enough not to be
shoved out into /usr/local/bin.

Please, I know someone out there is going to say "If you like BSD, just
use that.."  Try just to be open minded and see that BSD is like that
for a reason, and before you dump on it, see why people like it ;-)  At
least consider how Linux could learn from FreeBSD (they sure have
learned a lot from Linux, and are exploiting Linux's achievements!)


> Nothing that is required to get a system running without a network has
> any business even being in the /usr/ hierarchy.  If you need it to get
> a system running, it needs to live in /bin/.  Plain and simple.

Ah, true... But should /usr/bin be allowed to grow over 4G and still
considered to be "reasonable?"

That's where most admins will probably wish for something better.  Even
the absolute haters of /opt would rather split some stuff off into /opt
before allowing /usr/bin to grow that large... ;-)