Regan Heath, el 23 de October a las 17:24 me escribiste:
> On Thu, 23 Oct 2014 15:27:50 +0100, Leandro Lucarella
> <> wrote:
> >Regan Heath, el 22 de October a las 10:41 me escribiste:
> >>>NO, this is completely false, and why I think you are not entirely
> >>>familiar with env vars in posix. LD_PRELOAD and LD_LIBRARY_PATH affects
> >>>ALL, EACH and EVERY program for example. D or not D. Every single
> >>>dynamically linked program.
> >>
> >>True.  And the reason these behave this way is because we *always*
> >>want them to - the same is NOT true of the proposed vars for D.
> >
> >No, not at all, you very rarely want to change LD_PRELOAD and
> >LD_LIBRARY_PATH globaly.
> Sure, but when you do change them you will want them to propagate,
> by default, which is why envvars are used for these.

No, not at all, specially with LD_PRELOAD, I think you almost never want
to propagate it. I think LD_PRELOAD is the closest example to what one
would want to do with runtime options (and some of the stuff, like
replacing the GC, could be done using LD_PRELOAD, actually, but you have
to replace it all, you have much less fine grained control, is major

> >Also, I don't have much of a problem with having command-line options to
> >configure the runtime too, although I think in linux/unix is much less
> >natural.
> Surely not, unix is the king of command line switches.

Is not about quantity, is about separation of concerns. Historically in
Linux a program only manages the switches it really knows, is not common
to hijack programs arguments in Linux (even when is done by some
applications, like GTK+, but is all under your control, you explicitly
pass the command-line arguments to the library, so it's quite a
different case). Anything that you don't control in your program, is
handled by environment variables.

> >or on a system level, by a system
> >administrator / devops (in which case for me environment variables are
> >superior for me).
> Disagree.  It's not something we ever want at a system level, it's
> somewhere within the range of a single session <-> single execution.

Why? On a single core I want ALL my applications by default NOT to use
the concurrent GC, as it will make things slower, while on a multi-core
I want to use the concurrent GC by default. You have an use case right
there. If I have tons of memory, I would want to have all my programs
preallocate 100MiB to speed up things. There might be more in the
future, who knows...

Leandro Lucarella (AKA luca)           
Parece McGuevara's o CheDonald's

Reply via email to