Excerpts from Alex Yurchenko's message of Fri Feb 17 05:57:03 -0800
2012:
Finally! A post that makes all wrong points!
On 2012-02-17 11:53, Björn Boschman wrote:
> Hi Alex,
>
> Am 16.02.2012 19:33, schrieb Alex Esterkin:
>> As an end user, I would most strongly dislike this. You clearly
>> don't
>> understand how corporate users think and operate, how they work
with
>> open source technologies, and how they plan and evolve their
>> technical
>> roadmaps.
>
> I think I understand a bit of how corporate users think and
operate.
>
> When you are an enterprise user who has subscribed support from
MySQL
> via Oracle you are enforced to use the Oracle binaries and cannot
> just
> use the distribution supplied binaries at all.
> This includes bugfixes and security fixes from your vendor, in
this
> case Oracle (not Debian or any other distribution).
>
> When you do not have such a subscription you rely on the support
from
> your distribution.
Heaven, no! Otherwise I'd still be using MySQL 5.0.something on
CentOS
5. And nobody wants that!
Indeed, there are times to diverge from the distro, and times not to.
This gets complicated though, because there are components of the
distro
that rely on libmysqlclient, and the client programs. These all start
to get ugly when your new upstream version introduces incompatible
syntax into /etc/mysql/my.cnf, or your shiny upstream version uses
/tmp/mysql.sock while old stodgy client programs use
/var/run/mysql.sock.
These aren't hard problems to solve, but they're annoying things that
users have to deal with when they diverge from the distro.
Of course, I'm relying on Oracle to provide the latest security and
bug
fixes. Whoever wants/needs to run MySQL 5.5 has long given up on
"their"
distribution. And, really, why/how should I rely on somebody else
but
the vendor to fix his program?
Projects like Debian and Ubuntu give users full control over their
software. While you may be in a good position to test and verify that
a large changeset from MySQL's latest version doesn't break your app,
many are not. By only introducing tiny, finite changes, the distros
have
provided a very stable (as in change, not uptime) version of MySQL
that
can be relied upon not to change (for better or worse) for the life
of
the release.
Your statement that anybody who needs mysql will just use the
upstream
mysql could use some data to support it. I don't have data that I can
share on either use case, but I can say that I have encountered users
who
are grateful that they can trust 'apt-get upgrade' not to break their
app.
> That's the point this whole discussion is about.
> Neighter Debian nor Ubuntu can offer reliable bugfixes and
security
> support.
Indeed, because, in general, they are not qualified to, and are not
supposed to be. Their main task should be packaging and integration
of
software to allow painless installation and use. Key word here is
'painless'. And with respect to MySQL Linux distributions don't do
that
great of a job, because they are focusing on something they should
not.
And while Oracle fills in for RPM-based distros, Debian/Ubuntu users
are
on their own.
Perhaps distros serve another purpose, which is to give users a
single
point of contact for the support of all of the software on their
system.
Debian and Ubuntu play this role, and it is in fact the more
important
role than convenience of installation. For a user who has time to
find
the upstream bug tracker, report bugs, and extract patches, sure,
they
do not need the distro version. In a previous life, I would not have
used the distro mysql because it was a core competency. But I used
the
distro postgresql, because I didn't know anything about postgresql.
For a user who has a peripheral need for MySQL, the distro version
makes a lot of sense. Perhaps they want to run Bacula and expand its
capabilities beyond what sqlite gives them. They need an avenue for
resolving their problem. The distribution serves this purpose by
getting
them in contact with Bacula and MySQL interested persons. For Ubuntu,
they also have a clear path to commercial support by paying Canonical
to resolve this problem for them.
So, for Debian and Ubuntu, being able to only introduce finite change
post-release means that you can know whether or not you are faced
with
a problem that you created, or one that was already present in the
upstream code.
> Not because they don't want to.
And they better don't.
I may not understand much about corporate users thinking, but I do
understand a thing or two about software development. And I can tell
you
that
1) it takes enormous effort to fix bugs in a 3rd party software and
is
a big waste of resources compared to the vendor doing it.
Backporting
bugfixes may lead to side effects and require extensive testing. Why
duplicate efforts? Why don't you just let that 3rd party figure it
out?
After all it is between Oracle and MySQL users.
Indeed, I have wondered for a while if we are doing the wrong thing
by
focusing on the idea of only introducing finite change into the
system.
It has worked for a long time, but if its not possible, there are
other
ways to manage the effects of change.
Perhaps we should, instead, focus on automated regression testing and
just accept the pain up front, adding regression tests as we go
along.
2) it is _generally_ impossible to fix bugs without changing
software
behaviour and breaking compatibility, simply because many bugs
define
software behaviour and others may require fundamental architectural
and/or protocol changes. So it is totally naive to hope to stay on
ancient version, but keep it up to date at the same time. I really
appreciate stability of CentOS as a development environment, but
staying
on the same MySQL version for 5 years is patently insane.
Is the phrase "If it isn't broken, don't fix it" insane?
3) the whole goal is generally pointless - say, I'm running Ubuntu
10.10 LTS, it has MySQL 5.1.41. If Ubuntu backports ALL fixes to it,
it
would simply become 5.1.61. So why not just upgrade to 5.1.61 and be
done with it?
Since the release of Ubuntu 10.04 with MySQL 5.1.41, we have
backported
a few of the most critical fixes from MySQL. We would never backport
all of them. We have a firm policy of only backporting things that
lack
simple workarounds or have a massive effect on the usability of a
package.
Because of the opaque nature of the recent security announcements
though,
it is likely that we will end up just shipping 5.1.61 into lucid
though.
Its not something we really want to do, as it will challenge our
ability
to support the users, but we don't have much choice.
> Their hands are bound because
> MySQL/Oracle somehow is not willing to provide important
information
> such as detailed changelogs or security information.
Making it nice and easy for linux distributions takes effort too.
And
that means resources. And who's paying for that? Apparently Oracle
sees
little value there, and I can see why: making sure that 5.1.41 gets
all
fixes for 5 years instead of just upgrading to a newer version -
nobody
wants that! What's the point of releasing 5.1.42, etc, then?
Its not a resource issue. Oracle has a policy and they have their
reasons
for sticking to it, but as far as I know, none of those reasons are
resource based.
> This leads us to the following options:
> * Stay with MySQL but no security nor bugfixes
> * Search for an alternative which is even 100% compatible with
MySQL
> + having full community support
Or, stop playing security police and focus on what distributions are
supposed to do in the first place: package whatever is released and
make
it easy for the user to install and use?
See above. I do believe that distros have a much larger role to play
than
convenience.
> From my personal as well as my business perspective I want a
system
> where I can get bugfixes as well as security fixes. You should
> consider those questions in your roadmap as well.
And that's why, as it goes now, I'll be using RPM-based Linux
distribution to run MySQL because there I can at least rely on
Oracle to
do the job. And that's quite ironic as I develop on Ubuntu.
You can run Oracle's static binary tarball releases on Ubuntu if you
don't like the packaged versions.
