Regan Heath, el 23 de October a las 17:24 me escribiste: > On Thu, 23 Oct 2014 15:27:50 +0100, Leandro Lucarella > <l...@llucax.com.ar> 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 surgery). > >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) http://llucax.com.ar/ ---------------------------------------------------------------------- Parece McGuevara's o CheDonald's
