On Mon, 13 Jan 2003 18:09:41 +0200
Evgeny Stambulchik <[EMAIL PROTECTED]> wrote:
> >   Wrong! My host has tens of different hostnames, also a host might have
> > several IP addresses. Every application needs to know under which hostname
> 
> OK, so the config should be more complicated. E.g. 
> local_machine->network_settings->virtual_hosts[]->hostname. And then apps 

So Allon presented one flaw in your assumptions and you came with a
solution for this *specific* flaw...

> My point is simple: there should be NO redundant definitions of config 
> parameters relevant for a given object.

The world *should* behave as you just described, but...

> This rises no objections when the object is an application, but for some
> reason people start to get nervous when talking about the OS as a whole

Because an application has (hopefully) very specific domain and scope, while
an OS doesn't. Anybody who administered systems in real life knows that
many times the "unthinkable" is the only reasonable option. A short example
to make myself clear:
   Unix/Linux has a '-n' option to reboot that prevent syncing the
   buffer cache before reboot. Obviously this option would corrupt
   the mounted disks. Why is such an option needed? (and we are
   talking way before journaling filesystems :-)
   The answer is very simple (left as an exercise) and illustrate
   how real life sometimes force us into less than optimal solutions.

Applying a "logicaly closed" solution to systems management problems
has failed time after time. I think one of the reasons Unix survived
for >30 years is the avoidance from "over-engineering" --
there's too much diversity and too much complexity.
So your earlier suggestion about minimizing the config types to 1
is naive in my view.

What is *realistic* to achieve IMHO (and still not easy task) is to
try and encapsulate the known best practices -- i.e:
  - use the existing solutions as blueprints for what works (and
    what doesn't) in real life.
  - Fold all semantically equivalent solutions into a "canonical"
    solution for this "class" of solutions.

----------------------------------------------------------------
Oron Peled                             Voice/Fax: +972-4-8228492
[EMAIL PROTECTED]                  http://www.actcom.co.il/~oron

"Those who do not understand Unix are condemned to reinvent it, poorly."
         (H. Spencer)

=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]

Reply via email to