On Saturday 18 January 2003 00:08, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Incidentally, has anyone else noticed the security update onslaught from
> > Red Hat for older PostgreSQL versions? They even backported the fixes to
> > 6.5.3 from Red Hat 6.2 (as well as for 7.0 and 7.1 as released in the
> > respective Red Hat Linux versions). Should I forward that notice here?
> Some of the guys in Toronto got excited about it, but I can't see a lot
> of value there myself. If you're still running 6.5.3, is it likely you
> notice updates from anywhere?
Why not? Upgrading to another major version of most things isn't supported by
Red Hat within a particular version. KDE is a prime example. GNOME is
another. XFree86 is another. BIND is yet another, although BIND8 upgrades
are available for the systems that shipped with BIND4. RPM itself is one of
the few exceptions. Going to 7.3 from 6.5 is not an update.
And lots of sites are still running 6.2. IIRC Red Hat's up2date automatic
upgrader tool was available in 6.2, and I know other autoupdaters are
available. And, as we all know, automatic upgrade of PostgreSQL is only
possible within a major version. Plenty of security conscious people still
run Red Hat 6.2. Many probably pay for the enterprise support contracts
through Red Hat, costing much money.
Hmmmph, I know of a user running a couple of sites still running 5.2, with no
intention of upgrading those machines. Will PostgreSQL 7.3 even build on Red
Hat Linux 5.2? Forced upgrades are nonsense. So I'm glad Red Hat decided to
put resources into supporting their userbase (even given the sunset on said
support).
On the BSD front, OpenBSD in particular still is running ancient versions of
some core network stuff, due to the extreme security nature of that OS. Last
I looked at OBSD it still shipped BIND4. 4.9 something. Positively ancient
code that they have thoroughly audited. BIND8 hadn't at that time been fully
audited.
> Red Hat 6.2 is still nominally supported (until March 31, it says here)
> so I suppose there's a corporate compulsion to back-patch anything
> that's labeled a security issue. But let's get real ... PG 6.anything
> is stone-age code now.
Why? If a user doesn't need the features of 7.x.x, and the codebase is
working well for him/her, why should said user/DBA feel compelled to go
through who knows what mechanations to upgrade to the latest version? That's
Microsoft-think. The upgrade from a 6.5.3 system to a 7.3.1 system is likely
to be traumatic at least and cataclysmic at worst (to upgrade PostgreSQL may
require upgrading the whole OS, which may require more memory (maybe more
memory than the motherboard will support, even)....). Yes, let's get real --
not everybody needs or necessarily even wants all the improved features of PG
7.3 versus even 6.5.
The 'corporate compulsion' you mentioned is more widely known as 'customer
service.' IOW, you want to stay in business, you support your customers.
The Red Hat 5.2 user mentioned previously is perfectly happy with the
featureset of PostgreSQL 6.3.2 (which is what 5.2 shipped with) and won't
upgrade until it's very necessary. But this is a very low resource machine,
where even the Linux 2.0 kernel makes sense. Now 6.5.3 will build on 5.2,
but I haven't tried anything more recent. And 6.3.2 is enough database for
their uses -- but these machines are in roles where security issues could be
problematic. If it were easier to upgrade, they might consider it.
_Of_course_ I'm not advocating that _we_ support these old of systems (after
all, the PostgreSQL Global Development Group _has_ no customers) -- but it
_is_ nice when a distributor acknowledges their older customers with real
security updates within their released versions, and doesn't force major
upgrades when unnecessary.
Now if the user needs _features_ then the upgrade is justified, and I have no
sympathy for a user who wants, say, schema support backpatched to 7.0.3, for
instance. That request is just ridiculous. But for security and critical
bugfixes, it should not be a forced major version upgrade, unless the bugfix
cannot be easily backported. I for one intend to get the source RPM's for
the fixed packages -- who knows, maybe some of the patches include the
ability to rebuild on later Red Hat Linux versions, helping my upgradability
crusade a little.
As to the 7.2.4 issue, much if not all of our userbase is more than used to
multiple concurrent OS kernel branches. Linux users in particular are very
used to parallel versions -- the 2.0.x and 2.2.x series still get occassional
releases even with 2.4.x out, and the development versions are in parallel
constantly (except during the first few versions of a recent stable) with
stable releases.. FreeBSD has their branches, etc. I think we should
release a 7.2.4 if the bugfixes warrant it. (Not a 7.1.4, though, or 7.0.4,
or 6.5.4, or 6.4.3, or 6.3.3, or....)
And I'm not against progress -- just against forced progress.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
