What so special about PostgreSQL and other RDBMS?

[Quirk]

It's a pity that you have considered my reply as that of a zealot.
I did concede a few points and debated yours in a civilized fashion.

Sorry if you thought I was refering to you specificly, rather I was
lamenting about the general quality of the responses in this thread,
like those of Volker, moronic zealot extraordinaire, a man so stupid,
that when I suggested he didn't know what a fallacy was, he thought I
was critisising his _english_ instead of his knowledge of logic and
the standards of debate.

However, there is clear zealotry in your post, for example:

You said: "It's with freeware that you need a STACK of wrappers to
protect you from sudden underlying code changes! Not with commercial
software!"

See: no other reasoning is given why underlying code may suddenly
change other than in one case it is _free_, in the other case it is
_commercial_. This is not a reasoned argument, but rather the faith of
a zealot.

Since neither freeness nor commercialness has a direct impact on code
stability, but rather the release management practices of the
development group has.

There are badly managed free software projects, and badly managed
nonfree ones, your argument is therefore a fallacy, although your
english, like Volker's is great!

However, thanks for giving me the opportunity of stating this in a less
civilized language (remember: YOU started the language, not I):

Please, use any language you like, you are quite welcome if my post
has given you a greater since of liberty.

none of
your points is by definition a "world truth".

When I say things like "the readers can make up their own minds, as
they should in any case" and "these are suggestions" (both present in
the post you are responding too) what makes you think I am defining
"world truths?"

You don't provide a single
supporting argument that does not involve your interpretation of what
software makers would do rather than what they in fact do.

Oh please, I have provided many clear aruments throughout this thread,
in my last message I even posted pseudocode, how much clearer do you
want?

Your stupid deduction that somehow only your view of the world is worthy
the title of "developer" defines you as the idiotic and moronic type of
geek that thinks the world was invented yesterday by your kind and all that
came before is just amateur effort. In character, I might say.

You know nothing about my character or world view. Amateur effort is
amateur effort, on it's own it is neither old nor new. None of the
ideas I have suggested are particularily new. The existince of a large
body of free software is fairly new, however the practice of acquiring
source licences for critical dependencies is not, and serves more or
less the same function. Abstraction is not new, good archiving
techniques are not new. A developer who did not understand these
techniques was an amateur in 1976, just as much as today.

You and your little group can go and drop dead as this thread ends
here for me: I don't have time to argue ANYTHING with "kewl" people.

I'm sorry the barbs you endured in your primary school still hurt you
so much, perhaps therapy can help.

Not worth the effort: the worst disasters in IT development I've ever seen
in 30 years of career have been prompted by your kind and I don't like
my name associated with that sort of unprofessional reputation. It
never pays in the long run.

Let's see, I am suggestion abstracting dependencies, getting source
code when you can and keeping your archives human readable.

What sort of disasters can come of this? The worst that can be said is
that, if implemented poorly, these suggestions may cause performance
degradation, hardly Godzilla crushing Tokyo.

However, It is quite easy to imagine disasters as a consequence of not
following these suggestions; customers lost by not being able to
support their database platform, production applications obsoleted by
obsoleted debendencies, unusable archives and lost permenant records.

Goodbye and keep developing for a non-existent market.
It has a brilliant future.

Which market is that? The market for good applications? I agree that
is too small and that too many firms are screwed by bad developers and
protectionist suppliers, however I assure you the marker for
developers who understand good, well designed, open systems is doing
quite well, and growing.

And yes, I DO have a future and nothing you can
possibly do will stop it.

Hey, I only want to improve your future with my advise! Here, I'll
give you another tip:

A "binding" is a term used to describe a native function (or method)
that provides access to an external dependency.

For instance, 'MySQL', the database server, is a dependency, in PHP,
the function mysql_query is called a binding. 'libcurl', the URL
handling library, is a dependency, the PHP function 'curl_exec', is a
binding.

An 'API' ("application programming interface") is the interface
provided by the dependency itself for external access, frequently for
C, the 'binding' is your platform's _native_ function or method that
provides access to this API, not the API itself.

Each of these terms, 'Dependency', 'Binding' and 'API' have distinct
meanings, and now, after a 30 year career, you can finaly understand
them!

I hope this helps.

Regards,
Dmytri.

 

[Dusan Bolek]

However, there is clear zealotry in your post, for example:

You said: "It's with freeware that you need a STACK of wrappers to
protect you from sudden underlying code changes! Not with commercial
software!"

See: no other reasoning is given why underlying code may suddenly
change other than in one case it is _free_, in the other case it is
_commercial_. This is not a reasoned argument, but rather the faith of
a zealot.

Since neither freeness nor commercialness has a direct impact on code
stability, but rather the release management practices of the
development group has.

There are badly managed free software projects, and badly managed
nonfree ones, your argument is therefore a fallacy, although your
english, like Volker's is great!

Sorry for interrupting your flame, but I must step in. This statement
is simply not true. In fact a problematic release management is
probably the biggest single problem of free software projects in
general. Even a big projects like Squid, Apache or even Linux itself
have serious problems in this area and the behaviour of smaller ones
is just unacceptable from a point of view of real production
implementations.
Typical for this is a lack of backward compatibility, a huge (and
often unnecessary) changes in config files (thus the need to rewrite
all configs after upgrade) and releasing unfinished code (too many
hacks used, no documentation ...).
I'm using a lot of both commercial and free softs, but I must admit
that these problems are much more frequent on the free ones.

 

[Gavin Kistner]

*PostgreSQL*
Free, loaded with features, not particularly fast, some extras

*MySQL*
Free, not so loaded with features, very fast, some extras

FWIW, although I have no first-hand experience to support this,
everything I've read recently says that:
(a) MySQL *used to be* much faster than PostgreSQL, but
(b) PostgreSQL is now just as fast (a bit faster in some areas, a bit
slower in others)

I'll refrain from entering any other part of this 'discussion'. Just
know that (again, from what I've been told) speed is *not* a reason to
choose MySQL over PGSQL. (And personally, in a choice only between
these two, there seem *to me* to be quite a sufficient number of
reasons to choose PGSQL over MySQL.)

 

[Niall Litchfield]

Thanks Nick, your alternative propositions are much clearer than the
FUD of the other posters. Although, your attitude seems no less
belligerent, so my hopes for a fruitfull discusion are not high.

Last time I looked my name was Niall, but then its only in my email address
and signature and display name so I guess I can forgive you for missing it
I'm afraid you are probably correct about the liklihood of a fruitful
discussion since you seem to have managed to get heated with every single
one of the posters that I am aware of who regularly post well thought out
informative posts.

Never the less

"Niall Litchfield" <[email protected]> wrote in message



In the real business world, outside of major corporations (and
sometimes even there), closed source software is either used
comepletely illegaly or seriously overdeployed, thus support from the
provider is unavailable or limited to simple telephone support.

The applications are generaly supported by consultants, who are
aquired directly or from
consuting agencies and not development firms.

I'm not saying that this is always the case, or is your case, but it
is the real world you asked about, and that's it.

If true, and there is some truth to this, I don't see what failing to get
the legalities right has to do with having access to the source. This is
about license management and control of procurement.

Having source, and using free software is becoming more and more
common in these cases, and it can be assumed that many of the people
asking questions in this news
group are working in such environements.

I'd be careful how you define 'this newsgroup' - it may well be true in
alt.php.sql - it is extremely unlikely to be true in
comp.databases.oracle.server, and I'd guess the sybase group would be
different as well.

So, when the question of Free versus Propietary Databases is asked, I
think it is important to help people understand the advantages of
having source, or using free software, of avoiding dependencies, *as
well* as comparing features.

No software project, even if you have access to all the source is 'free' of
dependencies, at the very least you are dependent on skill and expertise -
most probably on a whole host of things. FWIW most commercial projects that
fail, fail not because the software is commercial, but because the project
is poorly scoped, poorly managed, inadequately supported by management or
all if the above.

As I said in my article in the NonProfitTimes, wether or not a
particular peice of free software is better that a particular peice of
nonfree software, free is better than stolen.

Ah a straw man argument. Seen them before.

Issolating your data access code does not mean you can not take
advantage of the platform, it means that all your data access code is
in one place, meaning that you can more easily change your
application, for instance to migrate it, or for instance to *make
better use of the platform you are running*

It almost always does mean you can't take advantage of the platform.

I have 2 databases, both run on clustered hardware, db 1 can resume a select
statement that was issued on a failed node on a second node of the cluster,
db 2 can't. How, precisely, do you 'abstract' this difference in capability
whilst preserving the ability of db 1 to handle failed nodes more gracefully
than db 2. How, precisely, do you abstract differences in datatype between
two db platforms without performing excessive casting..

Because your companies record keepers distrust your closed-source,
unabstraced application's data so much that they insist on keeping
their trusty paper records.

And there I was thinking that a proper paper filing system worked just fine
for the purpose for which it was designed.

With proper electronic archives as I've described, they will soon
enough be conviced to replace the filing cabinets with datacabinets,
but it will take some convincing, since after years of dealing with
developers like Volker (my new synonym for unskilled labour), and
losing access to their data, they rightfully do not trust the
datasystems.

The open-paperless office I love the vision.

You snipped what i was referring to, perhaps you misunderstod

referring to

If a customer
decides not to upgrade, the vendor has effectively broken the code for the
customer as soon as the next bug or insecurity is encountered: no support
means no fix.

I said

You are equivicating here on the difference between installing more
recent software and paying for a new licence, one is not the same as
the other.

Not at all. You claimed that if I have access to the source, as I do with
Linux 1.5, then I can always find a way forward without external
dependencies. The only route to what you claim as an advantage would seem to
be rewriting the code in-house, or being dependent on external agencies with
whom I don't have a legal relationship (you don't seem to like legal
relationships much) . Perhaps you suggest that we review and understand in
house the change log between kernel 1.5 and kernel 2.4 before applying 2.4,
or is there a support contract available that will backport fixes from later
linux to earlier linux. Oracle can and do backport fixes.

Oh and by the way I am perfectly free under my licence to install new
versions of the Oracle software for no change in cost and with the same
support.

 

[Doug Hutcheson]

Niall,
Exactly !!
We are both correct - both propositions have merit and neither should be
taken as the justification for believing one way is somehow "right" and the
other "wrong" in every case without exception. The important point is to
define the problem space and fit the solution to it.
In spite of the highly charged language this thread has suffered from,
this is the nub of what Quirk - and, latterly, I - have been trying to get
across.
It is not a matter of anyone claiming the high moral ground on some point
of principle. It is not a matter of one side defeating the other on points.
It is just a matter of accepting that there is more than one way to ensure a
customer gets best value for the budget they have available and the task
they need performed.
Quirk and I both agree that Oracle, for example, is a fine product with
many important features. We both, however, understand that it is not the
only tool in our toolbox and it has drawbacks as well as advantages.
The circumstances help define the problem space and we propose that
circumstances differ from one project to the next. Your mileage may vary.
Kind regards,
Doug Hutcheson

 

[Quirk]

Last time I looked my name was Niall,

Sorry Niall.

I'm afraid you are probably correct about the liklihood of a fruitful
discussion since you seem to have managed to get heated with every single
one of the posters that I am aware of who regularly post well thought out
informative posts.

I guess the new free software movement is such a big threat to the
status quo that it makes them nervous and belligerent to even discuss
it, like many protectionists, they are worried their island is about
to be stormed by barbarians. Well, I guess they are right. The
consumer, however, will benifit. And those amongst you with real
skills will also get on just fine.

If true, and there is some truth to this, I don't see what failing to get
the legalities right has to do with having access to the source. This is
about license management and control of procurement.

Because with closed source software, 'failng to get the legalities
right' is a financial mater, in many cases companies *chose* not to
get them right, they know perfectly well they are overdeployed.
Sometimes the choice is made by the principals, sometimes the choice
is made further downstream; in the IT department who can't be bothered
going through the procurement cycle again and again and justifing
needing any more licences to the bean counters. They simply install
the software on an another server, or for another user. In larger
organisations the company tends to drift into overdeployment, in
smaller ones, overdeployment or outright piracy is frequently the
starting point.

Free software can not be overdeployed, which is one reason why linux
and bsd boxes are popping up in datacentres around the world, they
started with Webservers, LAN Servers and Firewalls (esp for NAT), then
Mail, now the Database, later the Desktop.

No software project, even if you have access to all the source is 'free' of
dependencies,

Sorry, I meant free of exclusive external dependencies: fixed
dependencies on outside organisations, not just software dependencies.

Ah a straw man argument. Seen them before.

No, perhaps a nonsequetor, but not a straw man, a 'straw man'
is refuting a weaker argument instead of the argument you have been
given, the passage you quote is an extension of my own argument 'free
is better than stolen', it is not a weakening of yours. You may
consider my extenstion irrelevant (I do not) but it is not a straw
man.

It almost always does mean you can't take advantage of the platform.

I have 2 databases, both run on clustered hardware, db 1 can resume a select
statement that was issued on a failed node on a second node of the cluster,
db 2 can't. How, precisely, do you 'abstract' this difference in capability
whilst preserving the ability of db 1 to handle failed nodes more gracefully
than db 2. How, precisely, do you abstract differences in datatype between
two db platforms without performing excessive casting..

The passage you quote talks about issolating your code to one place:
abstracting access from your application, which is a good coding
practice for reasons I explain, as quoted above, I am not recomending
you try and abstract //the difference between two databases// just
that you issolate the code: abstract the data access for the rest of
your application.

When and if you need to migrate your application to another DB,
presumably you have chosen db 2 based on your requirements and have
already decided on a solution to whatever problem you are facing,
having your code issolated means fewer code changes. Again, this holds
true for migration, it also holds true for simply making better use
(i.e. new features) of the platform you are currently using.

Not at all. You claimed that if I have access to the source, as I do with
Linux 1.5, then I can always find a way forward without external
dependencies.

With out _exclusive_ dependencies on third parties, sorry for the
confusion: without paying for a new licence.

The only route to what you claim as an advantage would seem to
be rewriting the code in-house, or being dependent on external agencies with
whom I don't have a legal relationship (you don't seem to like legal
relationships much).

You see, *this* is an example of a straw man argument: that I don't
like legal relationships, what I don't like is _bad_ legal
relationships that lock me and my application in to a sole source
situation and other specific restrictions, like limiting the
deployment of my own application to the licenced limits of the
dependency. I have no problem with good legal relationships, like
support contracts, employment contracts, service contracts. All yummy,
with a decent termination clause of course, and my perpetual right to
the source when possible.

Oh and by the way I am perfectly free under my licence to install new
versions of the Oracle software for no change in cost and with the same
support.

As long as you agree to pay whatever Oracle charges for support, a
price fixed not by competition, as it would be if you had source and
could contract who ever you liked, but by David Ricardo's concept of
Economic Rent, meaning that in the long run the price will rise to
what it would cost you to migrate away from Oracle. Interestingly, in
this way users of closed source software do marginaly benefit from
free software, since it lowers this theoretical rent. However, it is
clear that Oracle can benefit from ignorance of free options for quite
a while yet.

Also, your licence likely limits the number of users and severs you
are allowed to deploy, so therefor Oracle's licence has a cost push
effect on your own application as well, potentially killing your own
competitiveness, or forcing you into overdeployment.

Regards,
Dmytri.

 

[Quirk]

(e-mail address removed) (Quirk) wrote in message news:<[email protected]>...

Sorry for interrupting your flame, but I must step in. This statement
is simply not true. In fact a problematic release management is
probably the biggest single problem of free software projects in
general.

Dusan, phrases like 'simply not true' and 'in fact' must be based on
reasoning, your reasoning is limted to your anecdotal evidence from
your personal experience, which I do not deny, my experience however,
is the exact opposite.

In anycase, neither of us can state that our experience represents the
only possible case. i.e. My neighbour is noisy, ben is your neighbour,
therefore ben is noisy; This is a fallacaious argument.

You must explain *why* what you claim 'simply is true' or is a fact.
What are the forces at work that make it so?

The only _fact_ is that projects, free or nonfree, with good release
management are less likely to cause upgrade difficulties than
projects, free or nonfree, with poor ones, and that this differs on a
project by project basis, and also is not static, but rather also
changes with the maturity and popularity of the project.

So, back to our specific case, MySQL and PostgreSQL, versus Oracle,
Sybase, and MS SQL. As far as I know all of these have a good realease
record, the last, of course, suffers from the bad release record of
it's host OS.

Noon's claim, as I explained, is therefore a fallacy.

Regards,
Dmytri.

 

[Jim Kennedy]

"Niall Litchfield" <[email protected]> wrote in message

Sorry Niall.


I guess the new free software movement is such a big threat to the
status quo that it makes them nervous and belligerent to even discuss
it, like many protectionists, they are worried their island is about
to be stormed by barbarians. Well, I guess they are right. The
consumer, however, will benifit. And those amongst you with real
skills will also get on just fine.


Because with closed source software, 'failng to get the legalities
right' is a financial mater, in many cases companies *chose* not to
get them right, they know perfectly well they are overdeployed.
Sometimes the choice is made by the principals, sometimes the choice
is made further downstream; in the IT department who can't be bothered
going through the procurement cycle again and again and justifing
needing any more licences to the bean counters. They simply install
the software on an another server, or for another user. In larger
organisations the company tends to drift into overdeployment, in
smaller ones, overdeployment or outright piracy is frequently the
starting point.

Free software can not be overdeployed, which is one reason why linux
and bsd boxes are popping up in datacentres around the world, they
started with Webservers, LAN Servers and Firewalls (esp for NAT), then
Mail, now the Database, later the Desktop.


Sorry, I meant free of exclusive external dependencies: fixed
dependencies on outside organisations, not just software dependencies.


No, perhaps a nonsequetor, but not a straw man, a 'straw man'
is refuting a weaker argument instead of the argument you have been
given, the passage you quote is an extension of my own argument 'free
is better than stolen', it is not a weakening of yours. You may
consider my extenstion irrelevant (I do not) but it is not a straw
man.


The passage you quote talks about issolating your code to one place:
abstracting access from your application, which is a good coding
practice for reasons I explain, as quoted above, I am not recomending
you try and abstract //the difference between two databases// just
that you issolate the code: abstract the data access for the rest of
your application.

When and if you need to migrate your application to another DB,
presumably you have chosen db 2 based on your requirements and have
already decided on a solution to whatever problem you are facing,
having your code issolated means fewer code changes. Again, this holds
true for migration, it also holds true for simply making better use
(i.e. new features) of the platform you are currently using.

Instead of abstracting there are much better ways. Abstrating somethings
are good. Put the business rules and referential integrity in the DB not in
some middle tier or front end. (even access the db via stored procs) Then
you can swap out the front end , middle tiers much easier and be assured
that you do not have to rewrite and validate the business rules all over
again. (not tied to one technology). It is much more likely you are going
to swap out some middle tier or front end or have multiple programs
accessing the db. If you give access to the db only through stored procs
and put the business logic close to the database (in it) then it is just an
API for storing, retrieving your data. It is a way to encapsulate that
functionality. If you write a C++ or Java or other OOPL functionality the
concept (among others) is to encapsulate the functionality in that class.
The class does all the checking and data validation etc. Think of the db in
the same way with respect to data and its relationship to itself. (RI,
business rules) You can still have edit checks in a GUI, but the ultimate
RI and business rules should reside in the database. But if one is only a
programmer this is a difficult concept to agree with and understand.

With out _exclusive_ dependencies on third parties, sorry for the
confusion: without paying for a new licence.


You see, *this* is an example of a straw man argument: that I don't
like legal relationships, what I don't like is _bad_ legal
relationships that lock me and my application in to a sole source
situation and other specific restrictions, like limiting the
deployment of my own application to the licenced limits of the
dependency. I have no problem with good legal relationships, like
support contracts, employment contracts, service contracts. All yummy,
with a decent termination clause of course, and my perpetual right to
the source when possible.


As long as you agree to pay whatever Oracle charges for support, a
price fixed not by competition, as it would be if you had source and
could contract who ever you liked, but by David Ricardo's concept of
Economic Rent, meaning that in the long run the price will rise to
what it would cost you to migrate away from Oracle. Interestingly, in
this way users of closed source software do marginaly benefit from
free software, since it lowers this theoretical rent. However, it is
clear that Oracle can benefit from ignorance of free options for quite
a while yet.

BS. If you are so niave to believe that Oracle doesn't think it has
competition they you are from another galaxy. I assure you that they know
there are other companies out there and they price accordingly. This
includes support. I've been at many companies where there was competition
between Oracle and others and they were fully aware and concerned that they
would get the business. They priced accordingly.
Jim

 

[Galen Boyer]

When and if you need to migrate your application to another DB,
presumably you have chosen db 2 based on your requirements and
have already decided on a solution to whatever problem you are
facing, having your code issolated means fewer code
changes. Again, this holds true for migration, it also holds
true for simply making better use (i.e. new features) of the
platform you are currently using.

I fail to understand how this has anything to do with whether you
use open-source, free or commercial software, but it seems to be
the main impetus to your arguments.

 

[Quirk]

When and if you need to migrate your application to another DB,

Instead of abstracting there are much better ways. Abstrating somethings
are good.

Seems contradictory, I assume you mean there are _somtimes_ better
ways in the first sentence. In which case, I agree, sometimes there
are.

Put the business rules and referential integrity in the DB not in
some middle tier or front end.
It is much more likely you are going
to swap out some middle tier or front end or have multiple programs
accessing the db. If you give access to the db only through stored procs
and put the business logic close to the database (in it) then it is just an
API for storing, retrieving your data. It is a way to encapsulate that
functionality. If you write a C++ or Java or other OOPL functionality the
concept (among others) is to encapsulate the functionality in that class.
The class does all the checking and data validation etc. Think of the db in
the same way with respect to data and its relationship to itself. (RI,
business rules) You can still have edit checks in a GUI, but the ultimate
RI and business rules should reside in the database. But if one is only a
programmer this is a difficult concept to agree with and understand.

Good explanation.

There are still some aspects of abstraction that are relevent here:
Since you can use standard SQL to do what you describe, I would
recommend in this case that you isolate your nonstandard sql to as few
stored procedures as possible to facilitate potential migration down
the road.

Also, putting the execute binding into a wrapper function, as I've
described, is still a good idea.

And, in the case of permenant, long term, or shared data, creating
archives in a self contained, self describing, human readable format,
is also good.

Stored procedures are a really good approach when data security is
extreamly precise, i.e. record and field level security. And also, the
performance advantages make them almost essential for huge table
joins.

It really depends on whether the database is a replacable backend to
highly invested-in application or the application is a replacable
interface to a highly invested-in database.

The former is generaly model good for an application which you provide
to a client, who may have a different DB, The later is sometimes a
good approach for an inhouse application in a large operations center,
with a good DBA.

The number of applications that look more like the former far
outnumber the ones that look most like the latter. Only a tiny
percentage of organisations have a DBA of anykind, let alone a good
one.

If you are a bank, you should follow Jim's advice, however you
probably already know it, since you have a good DBA to keep the pesky
programmers under control.

If you are more like a book store, or a photo shop, or an HVAC repair
firm, or a small Non Profit, you should probably follow mine.

BS.
If you are so niave

Why the belligerence?

to believe that Oracle doesn't think it has
competition they you are from another galaxy.

They do not have any competition in regards to selling _Oracle_.

I assure you that they know
there are other companies out there and they price accordingly. This
includes support. I've been at many companies where there was competition
between Oracle and others and they were fully aware and concerned that they
would get the business. They priced accordingly.

Price is determined when the flow of product ENCOUNTERS the flow of
money.

The competetion you speak of is only at ONE ENCOUNTER, the orginal
decision to buy Oracle vs a competitor, so yes, at this encounter, the
price ceiling is determined by competion and to a certain extent,
costs.

Once you have become an Oracle customer, there is no further
competetion unless you chose to migrate away from Oracle, so for EVERY
FURTHER ENCOUNTER the price is determined by what it would cost to
migrate away from Oracle.

In economic theory, I am applying what is known as Economic Rent,
originaly forumulated by David Ricardo.

Since Oracle and their competitors all know this, they all have the
same pricing strategy.

Only vendors of free software face different factors.

With vendors of free software, the potential for competetion exists AT
EVERY ENCOUNTER, and therefore price is more closely driven by cost.

This of course doesn't not mean that you should never use nonfree
software, as sometimes there is no alternative for your needs, so the
price must be born and worked into your own business model, and
therefore passed on to your own customers.

But since your business realty may be more elastic than Oracle's, this
"cost push" can force you into a situation of overdeployment or
piracy, in which case your access to updates and support is
questionable.

In closing, Jim, if you have an inovated new price theory, please
explain it here, perhaps you can take my understanding beyond Ricardo,
Keynes and their descendents, I'm all ears. But calling what I said
BS, and me naive for saying it is just, as I said, Belligerent, or in
technical terms: 'Following in the footsteps of Volker.'

Regards,
Dmytri.

 

[Quirk]

On 25 May 2004, (e-mail address removed) wrote:

I fail to understand how this has anything to do with whether you
use open-source, free or commercial software, but it seems to be
the main impetus to your arguments.

I made four suggestions in my original post in this thread. One
regarding source, one regarding abstraction, one regarding human
readable archives, and one regarding network security trumping
database security.

Each is complimentary to the others, but not dependant on any of the
others.

My main impetus is the preservation of the application and it's data.

 

[Thufir]

]

MySQL has a better record because theres people being paid for doing it.
For documenting, for making propaganda, etc. MySQL isnt really 'Open
Source' or 'Freeware' as you *have* to buy a license if you happen to be
using MySQL for a commercial solution.

[...]

That's just total nonsense. MySQL is under the GPL, you can use it for whatever you like. If you want to distribute it, then get a license from Oracle. You're confused about the dual licensing.


-Thufir

 

[thufir]

MySQL has a better record because theres people being paid for doing
it. For documenting, for making propaganda, etc. MySQL isnt really
'Open Source' or 'Freeware' as you *have* to buy a license if you
happen to be using MySQL for a commercial solution.

[...]

That's just total nonsense. MySQL is under the GPL, you can use it for
whatever you like. If you want to distribute it, then get a license
from Oracle. You're confused about the dual licensing.

"Q4: What is Oracle’s dual license model for MySQL software?
A: Oracle makes its MySQL database server and MySQL Client Libraries
available under both the GPL and a commercial license. As a result,
developers who use or distribute open source applications under the GPL
can use the GPL-licensed MySQL software, and OEMs, ISVs and VARs that do
not want to combine or distribute the MySQL software with their own
commercial software under a GPL license can purchase a commercial
license. "

http://www.mysql.com/about/legal/licensing/oem/#4


Pardon, I stand corrected. You can hand out CD's on the corner, provided
you also provide the source code. As, err, with any other GPL'ed
software. Only if you don't want to distribute the code would you need a
license from Oracle.


-Thufir