Hi Alan,
Alan W. Irwin writes:
> I would like to permanently disable the gd and gcw device drivers as well
> as the gnome2 and pygcw bindings associated with the gcw device driver for
> this forthcoming release.
>
> Here is my justification for this proposed change.
> [...]
> * gd and gcw provide functionality which is (mostly) superseded by other
> device drivers.
> [...]
> + The gd device driver provides -dev png (now superseded by -dev pngcairo
> and -dev pngqt), and -dev jpeg (now superseded by -dev jpgqt).
> [...]
> Before taking the fairly drastic step of permanently disabling these devices
> (and associated bindings) I want to check with others here for your opinion
> of this proposed change. If anybody here feels strongly about keeping these
> devices around for the next release, I would certainly be willing to go
> along with the compromise of simply turning OFF these devices by default
> (which gives the users the choice of turning them ON if they really need
> them). However, I feel the above long list of woes is probably
> justification for more drastic action.
Thanks for the summary. While I agree with the points you have raised, there
is at least one point which I feel is under-represented, and that is what I
might call backward environmental compatibility, or possibly just longevity.
Probably too vague. The issue is, how do new PLplot releases fare on "old"
platforms (distros). My main concern here is Linux, since that's where I
work, but I'm sure the same arguments could be made about various Windows
versions that MS may have EOL'd, but people still use.
My own experience might be summarized as "life in a ginormous corporation".
As Linux pushes into large enterprises, companies/corporations wind up
spinning up ginormous (read bureacratic/slow) IT organizations which seek
"standardization" as they roll out server farms with gobs and gobs of cpus,
and even attempting to provide worldwide multi-site synchronization of the
software environment ("the stack") across this huge expanse of computing
hardware.
One hint: They don't use Debian etch, or Gentoo, etc. They use Red Hat
Enterprise Linux, and I don't mean 5.3. Right now I am staring at the most
computing horsepower I've seen since I left the US national labs, and it's
all been recently "upgraded" (cough cough) to the amazingly modern Linux
distro known as "Red Hat Enterprise Linux (drum roll) ... 4". There are
rumors of a skunk works RHEL5 eval study. I figure it will see the light of
day in 3 years at the earliest.
And my company is not the only one like this. There are lots of RHEL4
installs going into corporations these days.
So, while I'm all for pushing the edge, developing drivers and bindings and
all that work well with late model OSS packages, I think it is also important
for us to comprehend that there are users out there who do not and will not
have the benefit of latest/greatest anytime soon. Basically ever, because by
the time QT4, libpangocairo and all the rest show up in these corporate
environments, so much time will have gone by that other things not yet named
will be new by then, and drawing current developer attention. Which is all
fine and good, but I'm just saying, not everyone has the benefit of modern
operating environments.
Of course, one could say, "Fine, those users should include modern versions
of this that and the other OSS packages in their project specific build
environmnet, and configure PLplot against all that." But the list is getting
long these days. I can't run "yum install QT4" on my corporate platforms. I
would have to compile all of these things (QT, Gnome, pango/cairo and
whatever else) all from source, and incorporate all of that into my
project-specific "prefix", before I could take advantage of all the latest
developments in PLplot. It's too much for me, I'm sure too much for many
others. I pull in latest versions of what I can't live without (late model
Tcl/Tk/Python) into my project-specific "prefix", and live with the system
libraries for the rest.
I just checked, my corporate project's PLplot build is using the old png
driver. Now, *maybe* I could use the new one if I configured with all the
right options. I guess I could try to see about that this week, and report
back. But if a new PLplot release doesn't provide automatic access to a png
output capability on a stock RHEL4 system, I'm going to view that as a
non-starter. And I would be inclined to expect that many other users would
find that off-putting as well.
We mostly live on the forward edge here, I think, and frankly that works for
me in most ways. But I don't think we should forget that there is plenty of
computing done on inconceivably conservatively managed software stacks, and I
don't think it makes sense to obsolete functionality that is not replaced
with a stock config on such widely used distros (still) as RHEL4.
I will try to include a review of this issue (png support on RHEL4 sans the
gd/gcw drivers) in my short list at work this week. But my short list at
work has over 40 line items right now, so I can't promise to provide a direct
reading on this on short order. With an intensive meeting schedule next
week, there is a real risk that I'll miss the current release window
entirely on this questsion. (Not to mention that I'm becoming very late to
merge the python branch to trunk, which I had hoped to have done comfortably
before this next release.)
-Geoff
------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
