[ On Friday, January 28, 2005 at 10:57:16 (+0100), Joerg Sonnenberger wrote: ]
> Subject: Re: static vs. dynamic runtime linking, esp. for citrus (was PAM and su -K)
>
> On Thu, Jan 27, 2005 at 05:19:52PM -0500, Greg A. Woods wrote:
> > And if you want a truly dynamic execution environment then why the heck
> > aren't you using an interpreted language (or at least JIT
> > byte-code-compiled one)?!?!?!?
> 
> You are arguing about speed and suggest an interpreted language?

No, I'm telling you that if you want to forego the efficiencies of a
static-linked application then _you_ should not try to consider bad
hacks just to get dynamic code loading and instead _you_ should simply
forego machine code altogether and instead choose a language and runtime
environment that's more directly suited to your needs.

Meanwhile those of us who want speed and will not put up with the
unnecessary overhead of a runtime dynamic linker doing the same
unnecessary things over and over again will choose our select set of
charset handling and conversion options for our select set of users and
will fix everything into a static, efficient, machine code binary.


> I consider including all the possible converion code bogus too.

It is certainly not bogus -- nor even necessarily inefficient (except
from a pure disk space utilization point of view).  We haven't had any
problem with avoiding loading unused code segments into memory for
decades -- that's why it's called "demand paging" and why it works
direct from the executable file image.


> I don't want to stop you from compiling in static modules, if you
> want too.

Thank you.


> But you have to face the problems arising from having to
> decide e.g. which character sets to support in an application
> before.

No, _I_ do not have to worry about that problem -- I can predict very
well exactly which character sets will be needed at all times for my
users and my systems.

And if I truly do wish to build a fully i18n system then I will want to
compile in all the possible known conversion code right way anyway and
let the Virtual Memory system worry about whether or not it has to be
loaded when and if some application wishes to call upon it.


Why do you want to re-invent a kind of specialized demand paged virtual
memory system just to load "optional" code?  It already exists and it
already works for free on _everything_, static-linked or not.

-- 
						Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>