From: "Eric Sosman" <
[email protected]>
|
| David H. Lipman wrote On 07/26/06 20:01,:|>> [...]
|>> (Disclaimer: I work for Sun, but do not speak for Sun.)
|>>|
| Well, that would be one of those areas where I *really*
| don't speak for Sun ...
||
| ... but I'll speculate, with the understanding that this is
| *only* speculation and *not* any kind of Official Say-So.
| (If people think I'm being overcautious with the disclaimers,
| just look at the nature of David's follow-up question and
| how quickly it was fired off.)
|
| If I'm trying to maintain a production system, upgrades
| and patches and stuff are a big source of worry. I may have
| great faith that Sun and IBM and BEA and Oracle have all
| tested their products and their product upgrades with care,
| but I'm also aware that they probably haven't tested the
| exact combination of components from all four that I happen
| to be using. And then there are the home-grown applications
| my own shop's programmers have turned out ... What's going
| to happen when I discover that upgrading both the Sun piece
| and the BEA piece causes the Oracle piece to run just a wee
| bit faster, thus exposing an unsuspected race condition in
| the home-grown app that books all our sales?
|
| Unforeseen version interactions are a fact of life, an
| unfortunate fact but a fact nonetheless. So I test all the
| new stuff as best I can on a non-production machine, and then
| I cross my fingers, hold my breath, and apply the upgrade to
| my production system -- and one thing I've made *really* sure
| of is that I have a quick and reliable way to return to the
| status quo ante if anything goes wrong.
|
| I would be *really* *not* *pleased* if the upgrade were
| to wipe out the old version automatically! It may only happen
| once in a hundred times that I need to do an emergency roll-
| back in the middle of the night, but on that hundredth time I
| *really* need to be able to do it just as smoothly and quickly
| as I can. I do *not* want to go back to some vendor's web site
| and start hunting for downloads of obsoleted versions and then
| hoping I can recall how I answered the installation script's
| questions; I want the old stuff still sitting on the system,
| unaltered and ready to roll as soon as I change an environment
| variable or re-target a symlink or flip a registry key or
| whatever.
|
| Not everyone has (or needs) quite such a mind set; some
| people are perfectly happy to just click "Do to me whatever
| you like" on a vendor's product maintenance page, and watch
| the pretty lights while the new stuff installs automagically.
| (My impression is that these are the same people who have
| never heard of backups.) If I were designing Java's upgrade
| procedures -- which I'm not; this is all speculation, right? --
| I would consider it more important to allow a careful person
| to do his job carefully than to make it easy for a carefree
| person to be careless.
|
| In an ideal world, system maintenance would be easy --
| heck, in an ideal world it would be unnecessary! But even
| though maintenance is harder than it might be, given the
| current state of technology I don't think it's an awful lot
| harder than it must be.
|
Based upon what you stated...
The there should NOT be an automatic stub installed to download and install a new version.
I hate it, really hateit, when software decides that it should install a stub to check for
updates. It is a waste of memory and resources and causes confusion to the LAN user.
Additionally the software defaults to an unlimited cache. That's certainly a wasted. I was
just at a Dell PC Today that had no less that 6 different versions of Sun Java installed and
according the "Add/Remove Programs" applet, the average version consume 140MB. That's
~.84GB.
All that is needed is a cache of between 10 ~ 50MB. I set the cache to 10MB on all my
managed platforms.
