[NCLUG] /etc/environment

[Bob Proulx]

John L. Bass wrote:
> Only until you need to move /usr/local/etc/default/myjavadefaults
> at which point there will be a hell of a lot of editing, and some
> scripts are likely to get missed, making things fail for months.

This is actually very easy.

  oldvalue=/usr/local/etc/default/myjavadefaults

  newvalue=/usr/local/etc/default/my_new_java_defaults

  sed --in-place "s@$oldvalue@$newvalue@" $list_of_files

Or any of a number of ways to edit a set of files all at one time.  I
don't think it is good to trade off a one time editing of five or 25
files by a developer when making major changes to installation paths
against the complexity added if this is pushed into the user
environment.

Editing these files is something that would be a _developer_ task and
not a user task and I think developers should be expected to be able
to do this type of editing pretty easily.  If this were for the user
then I would expect the developer to create a system package for it
and handle these types of details within the package.  With a package
the user would only need to install it and be done.

> Using a single point of change, is by far better.

This provides a single point of change of the configuration.  I
believe rejecting this on the grounds that the installation files may
change location to be a pernicious point.

Using the wrapper script if needed to set all of the configuration to
be the better solution since it *) installation takes effect
immediately *) changes take effect immediately and cannot be stale in
an existing user environment *) does not require the user to log out
and back in to get an environment change to take effect *) does not
need to deal with ways to make different environments work [e.g. bash,
zsh, csh, pam, non-pam].

> Also that has the high overhead of having to fire up a /bin/sh if
> your java programs are used in scripts, which can be a performance
> killer for some applications.

Wait, wait, wait...  We were talking about Java here.  If we start
comparing the overhead of invoking /bin/sh versus *Java* I am pretty
confident that the shell is not going to be a significant negative
impact.  In particular because we are talking about Java I can't see
how I could lose.  :-)

Also I have no idea if this is a once invoked daemon at system start
time, an interactive user lauching a GUI application, or if this is an
application that actually will be invoked very often.  If the latter
then writing it in Java is probably the wrong choice.  If the former
cases then the shell spawn time is not significant.  And I would say
the same if it were Perl, Python or Ruby too and not just the shell.

But in fact I will strongly object in general and state that premature
optimization is the root of many evils and optimization to remove the
shell should not be applied at this point yet.  I disagree that the
overhead of the shell here is going to be in any way significant even
if it were wrapping an efficient compiled C program.  Even if this
were Perl, Python, Ruby with their greater overhead wrapping another
process it would be fine.

The shell is very likely to already be in memory on a system.  In a
typical desktop or server the shell is very likely to already be
available and the load performance time amortized across many other
applications.  [It is possible to contrive examples such as embedded
application boxes (e.g. Linksys routers, Mars rovers, etc.) with low
memory and specialized use where this is not true but those are not
the typical case and usually in those special cases many things need
to be customized and not just careful use of the shell.]

Bob