Date: Sat, 12 Jul 1997 16:42:27 -0700 (PDT) From: asami@cs.berkeley.edu (Satoshi Asami) To: jkh@time.cdrom.com Cc: torstenb@ramsey.tb.9715.org, current@FreeBSD.ORG, hans@brandinnovators.com Subject: Re: Heads up and and a call for a show of hands. Message-ID: <199707122342.QAA10120@silvia.HIP.Berkeley.EDU> In-Reply-To: <7882.868710267@time.cdrom.com> (jkh@time.cdrom.com)
next in thread | previous in thread | raw e-mail | index | archive | help
* > The point is that, either way, there is an existing mechanism that can
* > easily be used without a need for additional features added to
* > ldconfig and/or /etc/rc.
*
* While this is true, I don't see it as an effective argument for
* mandating only _one_ way of doing things.
I see it that way. At least it effectively cancels the argument about
"this makes life easier for vendors".
* More to the point, I think that it's actually far more of a stretch to
* have the local package startup mechanism setting the ldconfig path
* than it is to have a specific mechanism for that purpose.
I have no idea why you think it that way. This is just a simple
application of a very generic mechanism. (Exactly the principle Unix
is designed around, if you ask me. :)
* I've had
* users ask me why, for example, that "modula3 needed a daemon." It
* doesn't, of course, but their confusion stems from the fact that
* during boot, the user sees something like:
* Local package initialization: apache m3 sshd
*
* And jumps to the obvious conclusion.
Maybe the user needs to be educated? ;)
Really, we can't help people from jumping to hasty conclusions, but
does that matter? If we add a xfree86.sh script to delete old
/tmp/.X0-lock files at startup, is that user going to ask why X needs
a daemon?
* /etc/ld.so.conf also appears in
* other UN*X environments, it's hardly a BSD first, and a growing number
* of admins are beginning to look there for override control. Our
* ${prefix}/etc/rc.d hack is, by contrast, something very FreeBSD
* specific.
Which systems have it? I don't find it on our Solaris box.
* local_dirs="/usr/local /usr/X11R6" # local hierarchies of importance.
* local_startup=YES # NO to deactivate local scripts.
:
* and that gives you both an engineer's override and configurable,
* vendor-editable files which follow the default ldpath.
I'm sorry, that looks very much like an over-engineered bloat. Having
too many ways to do a single thing can often lead to confusion. I
also am not comfortable with third party software editing files in
/etc -- that should be avoided unless really, really necessary (like
/etc/shells).
Am I the only one that is disturbed by the recent trend of
behind-the-door negotiations with vendors followed by a commit
followed by a big controversy? It seems like the vendors were not
even properly reminded of our standard way of doing things. I'd hate
to see unnecessary knobs and bells and whistles added to our system
because some vendor can't be bothered to do even the minimal
OS-specific customization.
If someone else feels the same way, please speak up. Otherwise, I'll
just slink back to my corner and close the rock behind me. ;)
Satoshi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707122342.QAA10120>