Subject: Re: PAM
To: Greg A. Woods <firstname.lastname@example.org>
From: Greywolf <email@example.com>
Date: 08/28/2002 17:38:17
On Wed, 28 Aug 2002, Greg A. Woods wrote:
# Dynamic loading for locales just doesn't make sense to me. The benefit
# of bloat avoidance is far outweighed by at least my own desire to want
# to use multiple locale features simultaneously in the same process. And
# who the heck cares about bloat except those of us who would only use
# EN_US (or some other 8-bit locale) on our old vaxen and SS1's anyway!?!?!?
Hello? *waves* Hi. Please don't assume that, just because the CPU,
disk, and memory can support bloat, they should be expected to. That
attitude miffs me more than anything. "Oh, we have the space/RAM/CPU
power to handle it, who cares?"
You want to do that, fine. I don't find it an acceptable stance.
Just because I happen to *have* a killer machine on my desk, as a
hypothetical example, doesn't mean I immediately want to find myself
maxing it out. In fact, quite the inverse: If I have a fast machine,
it's because I want it to run the less bloated code with greater dispatch.
That way, if I happen upon an app that needs those resources, it's not
going to be starved out by other niggly little programs that have been
placed on my system by someone with the attitude that "Hey, it doesn't
matter, you have the space/RAM/CPU power to handle it. Who cares?"
# Ultimately there is no technical _need_ for dynamic loading of code in
# any open source environment (outside of the bloat and recompile whines),
# especially not for forcing it across the board in an entire base
# open-source operating system.
Hey. Look. "bloat" is *not* a whine. Bloat is a reasonable concern.
(I'm neutral on recompiling, since I tend to want to recompile after a
binary install anyway!)
[Hm, I'm back in form again. Accord was nice while it lasted.]
As has been noted, however, we're rather dependent upon the GCC folks for
our toolchain. There are some severe technicalities which prevent us from
redesigning the CCS specs to handle the ability to do a dlopen() from
static-land. Even if we do clear the hurdles, we're not going to be able
to force the GCC team to buy it back (which they wouldn't -- we are
already the Special Case Scum of the Universe, or so it would seem looking
at GCC and any other vendor who offers solutions to the non-proprietary
folks (I see lots of Linux support, and some FreeBSD support and I think
even *OpenBSD* manages to secure more vendor support than we do!)).
I'm not crazy about introducing potential points of failure, either, but I
think we have reached the point of percussing an equine beyond the point
of mortality here.