RFC

[Jim Knoble]

På 2000-Mar-15 klokka 23:48:51 -0500 skrivet Robert W. Current:

: 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).

No.  Not only should /usr/ be mountable read-only, but the admin should
be able to decide whether /home/ should be exported or mounted
orthogonally to /usr/.

: 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).

Which you can still choose to do or not to do using /space/local/ or
/local/ or whatever else it ought to end up becoming.

: 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 you need one of the following:

  (a) to move the necessary stuff to /bin/ (perhaps with symlinks in
      /usr/bin/ for backward compatiblity);

  (b) a rescue disk or CD (or DVD) containing the necessary stuff; or

  (c) to learn to live without whatever it is.

In particular, [a] might ought to be the job of the distribution
vendor, but certainly not of the LSB.  Only a distribution vendor can
know their system well enough to know whether e.g. `grep' is needed by
their boot or recovery scripts.

: 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.

I fail to understand what you mean here.  Could you elaborate or give
examples of what you mean?

: Ok, define "System" ;-)

What is it that you believe should be in /usr/local/?

: 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.

This sounds like a problem that should be solved through site-specific
policy, not through LSB or FHS.

: 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 can right now purchase a brand-new name-brand 20 GB UDMA hard drive
for less than US$200.  In twelve months i won't even be *able* to
purchase a new 20 GB drive because it's too small and the supplier
doesn't carry them---the minimum i'll be able to get is 30 GB, whereas
the US$200 price point will likely be 40 GB serial-IDE drives.

  $ bc
  bc 1.05
  Copyright 1991, 1992, 1993, 1994, 1997, 1998 Free Software Foundation, Inc.
  This is free software with ABSOLUTELY NO WARRANTY.
  For details type warranty'. 
  scale = 4
  (500 / (20 * 1024)) * 100
  2.4400

500 MB is two and a half percent of that 20 GB hard drive---just barely
a significant amount of that space.  A UDMA drive, with proper cables,
controller, and OS driver, can reach transfer speeds of 33 MB per
second (newer UDMA66 drives can double that).  Even at a transfer rate
of 10 MB per second, that's 50 seconds---less than a minute.  Double
that to account for reading the same data before writing it, and add in
some extra to account for seek times, and you get as much as 3 minutes.
Even the 15 minutes or so needed for actually installing that 500 MB
from CD-ROM is relatively trivial. It's probably significantly less
than the amount of time it would take to restore the same 500 MB from
the latest full+incremental backups.

I stand by my assessment.

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

When?  Filled with what?  I don't particularly think it should be
filled with KDE or GNOME myself, but i still can't understand why the
LSB ought to decide what's not allowed to go there.  Make the
distribution vendors decide that in a way that works for them and their
customers.  That's what distributions are about.

The LSB should certainly declare that certain stuff ought to be
available in /bin/, and that certain other stuff ought to be available
in /usr/bin/, but it has no business saying what ought not to be
allowed there.  The FHS says some things about that, and the rest is up
to the distribution vendor.

: 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... ;-)

And they can, while still having an LSB-compliant system.  They can
even make their own LSB-compliant distribution if they wish.

I've said this here before, but it's worth mentioning again: LSB is an
enabling technology.  It's not intended to be full of proscriptions and
restrictions, but rather a way to enable software vendors to get a
guaranteed, predictable environment to install in, to enable
distribution vendors to innovate around that environment, and to enable
users to reap the benefits of both innovative and competing operating
system distributions while remaining confident that compliant
applications will install and work on their system.

-- 
jim knoble
jmknoble at pobox.com