MySQL Bugs: #16518: Obsolescence is a mistake

Bug #16518	Obsolescence is a mistake
Submitted:	15 Jan 2006 19:48	Modified:	21 Jul 2006 3:34
Reporter:	Terry James	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Server: Compiling	Severity:	S4 (Feature request)
Version:	any	OS:	Windows (Windows NT Server 4.0)
Assigned to:		CPU Architecture:	Any

Description:
This is a precognitive bug.

This is the scenario:

A few years down the road a user implements an entirely new Operating System software under and entirely new hardware acrhictecture design [although this bug will occur even without any changes in hardware design].

The organization has been using MySQL for many years and has a massive database built on it. But this year a blackout occurred which affected numerous data nodes worldwide.

In order to recover its crucial database, the company has discovered that it must revert to rebuilding the entire database. However, the company soon discovers that it cannot simply reinstall the current Operating System and do this, it must, instead, back up to the Operating System that was running the entire worldwide company network before this new Operating System was released.

However, by this point, so many previous Operating System components and applications, as well as third party applications and components, and finally a vast majority of well known hardware and associated drivers, have all been consciously obsoleted by all of the vendors and original equipment manufacturers. In addition, no provision whatsoever was made for such a worldwide catastrophic event failure horizon.

There is now no way to recover from the disaster. The company must meticulously glean its well planned exaword database, and the company realises that the cost is going to be a loss leader for a few years, and, it will have to accept the loss of profit margin data and accounts thereby.

Furthermore, there will be lawsuits aimed against the company because it has lost crucial client financial information, including all accounting and debit/credit histories.

Lastly, it will be the object of governments worldwide for its pleas of innocence in having lost this information and these financial records, since there is now no way to balance its books and make the lawful payments it is required to make.

If you think this can't happen, it already has.

It happened because every company followed Microsoft's lead in obsoleting support for its software. Of course, it was not Microsoft that was the organization under scrutiny or facing the dilemna because, quite frankly, they don't use their own Operating System to run their massive company. They use mainframes and mostly Unix and Unix like [Linux] Operating Systems and its non-obsolescense structures and architectures.

The change was from NT to XP. However, this was well planned, since XP 5.1 is actually NT 5.1 and there is sufficient swoftware that did not become obsolete to prove that NT 4.0 can and does run XP software.

And there is your bug.

Your database does not work nor install with contingency security on NT 4.0 systems, and this leads to the obvious projection that at some time in the future your database will not run nor be recoverable under Microsoft's future Operating Systems and under future hardware.

Which means, principally, that at that point, every company that uses MySQL will face this dilemna, even if the catastrophy never occurs. However, if history is any guage of future failure, it most certainly will occur.

So you have to ask yourselves: Is MySQL a fully recoverable Linux database and application, or, has it become totally, addictively, and entirely dependent on one company's intravenous software?

I think it has, and I think you've made a mistake thereby.

I have no doubts that I could make both MySQL and Windows Installer work on NT 4.0 and allow for transition and recoverability for XP systems, if I have access to both source codes.

I simply can't understand why such a fine program is now on a Microsoft IV. Is the patient that critically wounded?

Dont' say it's not a bug.

How to repeat:
This is obvious. Try to bring in any NT machine that has crashed and convert it to XP. The install software for critical components is obsolete and, unless you have backups of all of the installers somewhere, the machine can't be re-initialized first as a recoverable NT machine and then upgraded to XP.

Suggested fix:
Ask Microsoft for the source for Windows Installer 2.0, or write something yourselves.

Release the source code needed to make the transition and keep old versions just in case things go all wrong in the future.

Edit tab did not take me to edit the original report for spelling, so please bear with me and with a site quirk.

What is the issue you wish to report? Please state the problem in 50-100 words, noting the behaviour you observed and how this differs from the behaviour you were expecting. A meaningful synopsis and a reproducible test case are also helpful.

Thank you.

Bug:  MySQL doesn't install correctly
Why: bad configure script
Behavior:  MySQL compile and install wastes about 100 hours of my time
Repeatability: over 50% reported compile and install failures by others
Synopsis: MySQL is not portable

Suggested fix:  Include the Apache Portable Runtime Libraries so that the configure option "--enable-layout=LAYOUT" can be implemented in MySQL's configure script.

Otherwise, just ignore it and it will all go away, right?  Apparently as fast as my suggestion is going away.

> Bug:  MySQL doesn't install correctly
So the right Category for this bug report would be "MySQL Server -> compiling",
not "MySQL Administrator", right?

> Why: bad configure script
You are compiling on windows using the configure script?
How do you do that? On Windows the only way to build MySQL
from source is using VisualStudio (unless you are using Cygwin
which we do not really support as a platform)

> Behavior:  MySQL compile and install wastes about 100 hours of my time
What are the exact errors you are running into?
Using which tools?

> Repeatability: over 50% reported compile and install failures by others
What "others" are you referring to? While we have some reports on compile
errors and intallation problems these i can't believe the 50% figure at all ...

> Synopsis: MySQL is not portable

> Suggested fix:  Include the Apache Portable Runtime Libraries so that the
> configure option "--enable-layout=LAYOUT" can be implemented in MySQL's
> configure script.

Sorry, but i can't see the connetion between the portable runtime lib and the
layout configure option. The layout option was already available in Apache 1.3
long before the portable runtime lib was introduced. 

> Otherwise, just ignore it and it will all go away, right?  
> Apparently as fast as my suggestion is going away.

Well, for now we are still not sure what problems you run into
and what your suggestion really is ...

I suppose I give up.  If you can't understand the plain English of "50% of compile and install failures are owing to the configure script" there's not much I can do to convey the idea.

I could state 100,000 things that are currently failing in both MySQL and it's close-knit presenter PHP, but if no one addresses the basic issue, failure to mass market and mass distribute, the management is hopelessly locked into a blindspot.

When I say that MySQL is not portable, that should be easily understood, and when I propose a solution using the APR's that should be understood.  And finally, when I say the majority of MySQL failures are owing to its inflexible non-portability because it has no --enable-layout=LAYOUT that should be understood by even the novice user of Apache and any webserver httpd, that is HyperText Transport Protocol Daemon.  If a programmer does not understand this, I must seriously doubt his credentials as a programmer.

I have tried to give good advice, it has been turned into some form anti-me defensive posturing.  Again, perhaps there will be a problem with understanding English, but it's not my problem.  I gave advice, it won't be taken, I give up.

MySQL will become non-backwards compatible and evolve to a Windows oriented program; I can see that so there is no point in going further.

> I suppose I give up.  If you can't understand the plain English of "50%
> of compile and install failures are owing to the configure script"
> there's not much I can do to convey the idea.

I only wanted to know where from you got this "50%" figure. 

You also failed to ask the simple question how you are able to make
use of "configure" at all on a Windows platform, together with all the other
questions asked by me and Jon ...

> I could state 100,000 things that are currently failing in both MySQL

Well, start by showing *one* actual failure? Remember that this is a
bug reporting system, if you want to start a general discussion on
how our build system works you should use one of our mailing lists 
or forums instead.

> and it's close-knit presenter PHP, but if no one addresses the basic
> issue, failure to mass market and mass distribute, the management is
> hopelessly locked into a blindspot.

as far as i can tell both PHP and us are doing pretty well mass distribution
wise

> When I say that MySQL is not portable, that should be easily
> understood, and when I propose a solution using the APR's that should
> be understood.  

Our server source compiles and works on almost any unixoid system out 
there, it also works on Netware and Windows. APR is not the only way
to make things portable, we already have a not-to-bad solution in place
so why should we switch to a new one that only emerged recently?

> And finally, when I say the majority of MySQL failures
> are owing to its inflexible non-portability because it has no
> --enable-layout=LAYOUT that should be understood by even the novice
> user of Apache  

For one you still fail to explain the relation between --enable-layout 
and the portable runtime library.

As far as i know the layout option is very special to the apache 
web server projects due to the fact that older apache versions used
a directory layout that was different to the default GNU autotools 
layout, so later the layout option was introduced to provide a 
choice between the "classic" apache layout and the GNU style layout

This is just a convenience option, the same result can be archieved
using the standard configure --*dir options, so i can't see a portability
problem here. 

--enable-layout is really very apache webserver specific, are you 
claiming that all the other autotools-based projects out there are 
not portable just because they miss this convenience option?

> and any webserver httpd, that is HyperText Transport Protocol Daemon. 
>
> If a programmer does not understand this, I must
> seriously doubt his credentials as a programmer.

I'm sorry, but insults like that won't get you anywhere ...

We are really trying to understand what your actual request 
is (and the actual connection between your first and second
posting), but not answering *any* questions you've been 
asked really doesn't help

> I have tried to give good advice, it has been turned into some form
> anti-me defensive posturing.  Again, perhaps there will be a problem
> with understanding English, but it's not my problem.  I gave advice, it
> won't be taken, I give up.
>
> MySQL will become non-backwards compatible and evolve to a Windows
> oriented program; I can see that so there is no point in going further.

Changed bug entry to feature request. Documentation clearly states that binaries are available for Win9x, Me, NT 4 etc. so you can download them from our servers (see http://dev.mysql.com/doc/refman/5.0/en/which-os.html). Source builds are also possible but only for a limited number of platforms (see http://dev.mysql.com/doc/refman/5.0/en/windows-source-build.html). Building on Windows requires 2000 or up.

I said that Apache Portable Runtime Libraries was a standalone library, or at least I thought I did.

The point was that APR allows all other developers to expand their configure script options to include those of Apache, which are the nicest set among all developers.

Rerouted as a feature request is fine.  I could not find "Feature Request" for all of the plentious content of the MySQL site.

I'm satisfied that someone at least looked at it.  It's very easy to include the APR's.  It should give MySQL a big boost.

I have an addendae here.

I have used every type of MySQL source and binary that there is.

The problem is, we don't use a lot of standard paths and locations.  It therefore becomes very hard to configure MySQL [and other programs] to consider them to be truly portable.  It's more like they are static than portable.

With the suggested APR's, all of the onus for packaging for all of the different architectures, distributions, and platforms, reverts to the user instead of to the developer staff at MySQL where is seems to be currently.

In essence, then, MySQL need only release one tarball for Windows and one tarball for Linux and let the user configure his own distribution.  Apache even provides the standard layouts for nearly all distributions and platforms in their file LAYOUT or config.layout or whatever it is.

This means, you don't have to have tarball for each of RedHat, Debian, Unix, Solaris, SlackWare, Mandrake, ad infinitum, but only one.  The same applies to the source tarball.

Secondly, Windows too would need only one tarball binary and one tarball source, in general.

The biggest problem encountered was getting everything to either install or compile and work together, and the four or five are needed:  MySQL Apache Perl PHP, SSL.

I work on trying to get them all up to current versions in the range of MySQL5 Apache2 Perl6 PHP5 SSL1

Which I call MAPPS, the required combination for secure database through the Internet.

Thanks

Ok, so it all comes down to having the same --enable-layout configure option
as provided by the APR? Which, as i already stated, is a convenience feature only
(although i have to confess that it is a nice one), it doesn't provide any additional
functionality over the already existing --???dir configure options.

But then i still don't see how this will provide this:

> In essence, then, MySQL need only release one tarball for Windows and
> one tarball for Linux and let the user configure his own distribution. 
> Apache even provides the standard layouts for nearly all distributions
> and platforms in their file LAYOUT or config.layout or whatever it is.
>
> This means, you don't have to have tarball for each of RedHat, Debian,
> Unix, Solaris, SlackWare, Mandrake, ad infinitum, but only one.  The
> same applies to the source tarball.

Even with --enable-layout the default pathes are compiled into the binaries
as this is a compile time option, not a runtime one. So we still have to provide
binary packages with the right pathes compiled in for each platform (and with
the right system library dependencies, too).

And regarding the source tarball: we have only one source tarball, and one
source ZIP for windows. Both are built from the same source repository,
we just leave out the files only needed for the other platform when creating 
these packages.

And then there are the platform specific source RPMs, these would still 
be platform specific with --enable-layout, just the difference between them
would be smaller.

PS: you still dind't reply to most of my qeustions in my first reply, e.g. how
you manage to use configure on windows, i'd really be interested in that if
you have a working solution that does not require Cygwin.

PPS: i fail to see the connection with the current line of thought around APR
and --enable-layout and your original posting?

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

All I said was that MySQL and PHP both need the APR's because they are not portable.  I have spent too many hours on too many forums telling others how to fix the "perhaps you should set your environment variable" errors to consider either portable.

I go back a long way, long before even Unix, and certainly before Windows.

I'm sorry if I expect more of programmers, but that's just me; had I had to hire a programmer based on his knowledge of what portability was, I would have to measure his knowledge of it first.  There was no intent to insult anyone, just business facts.

--enable-layout is an actually ancient concept, predating both Apache and Unix.  It instructs the compiler or the installer to use a text file for all paths, not just a handful, not just one or two directories, or ten, but all of them.  It is inherent in the C Compiler, but it must be specified as a variable for the autotools set.  Thereafter, it can be used, along with the directive --with-most to cutdown on all scripts errors, the length of configure and other scripts themselves, and the process time on a "per machine" and a "per customer" basis.

It seemed to me that no one knew of the options for the C Compiler, that's all, when no one seemed to know about the function of the two directives, that the whole object of the APR's was to set two simple variables, forgotten in the autotools, so that the portable runtime library is the --enable-layout and the
--with-most and the other options that Apache seems to show.  However, these are GNU options and GCC options, not Apache options; the Apache group just knew about their existence and implemented them in the autotools, something which the autotools developers themselves had not done, although they should have.

Most of the failures were on Unix/Linux systems, not Windows, and I'm not even sure how this all wound up under a Windows reference.

The subject of obsolescence came up because it seems that PHP developers are of the lent that they are going to replace html and http, but being major projects of M.I.T., I seriously doubt that anything will ever replace the originals.  PHP has implemented numerous rules that do not function in html and http.  Among them, the use of square brackets, and the obsolesence of greater than and less than indentures.  So that PHP is not fully compliant with html and http.  This would seem to indicate a feeling among PHP developers that somehow html and http were going to one day be replaced by PHP and that html and http would become obsolete.  It almost efforvesce's out of the thinking observed in PHP development.

I apologize also for not replying in a while, however, within the last year the Internet has crashed at least twice, one major DNS problem worldwide, and I'm not sure what happend within the last three days, I just know that most of the banks, credit card systems, nearly all email server, and DNS, seemed to have boggled just about everything.  People within the bowels of the Internet, backbones, mainframes, supercomputers, usually don't tell the world that something went wrong on their end, but when credit card systems shut down, you know something quite serious has happened and it keeps some of us busy.

In the end, all I'm saying is that the APR's are a good idea.  And that is advice from someone who has worked for and with J. Presper Eckert and John Mauchly, who laid the foundations for nearly everything in the computer and networking industries.  The idea was to make all computers talk to each other and work with software "out of the box."  Even the simple "subroutine" was their idea, among millions of others, including the Internet, regardless of who takes credit for it's founding [all of them students of the great men, including the Authors of C, Unix, and Linux].  They taught me that portability was the Number One solution.  They were the founders of the Free Software idea.  And Free Software can co-exist with proprietary software quite nicely, of which Linux and Windows are proof.

So, at this point, people can take it or leave it, as I'm becoming too busy anymore to address many discussions I have addressed in the past.  If you don't think that the APR's are a good idea, then just let this commentary bug fade away into history past.

Letting this commentary bug fade away into history past.

Until 2039, when, of course, all this will be called the Y2K39 cataclysm.

Of course, all the MySQL programmers will be dead or retired, so, not their problem

California will no longer exist, so, support will be provided from Mars.

The robots on Mars who write and continue to support MySQL will rename it MarsSQL in honor of the new god who has taken over, thanks to the inability of the human immigrants from California to Mars refusal to actually think.

Human language, per se, will be outlawed throughout the solar system in response to those few who do think having questioned the program god.

The Martian machines will take over Earth, thanks to the inability of Californians to think.

And access to the databases thereafter will be restricted to non carbon based life units.

Or has all of this happened already?  Californians, apparently, believe it has.

Along with that big spaceship that landed in California and delivered their Governator from the future.

Are they putting something in your water in Santa Clara County?

Just for the record, the nice woman who called me about our company utilizing MySQL and support, I believe she should be CEO because she, at least, listened like an intelligent human being to the concerns of businesses skeptical of the reliability of MySQL program.

She must have attended university back East.