Re: What so special about PostgreSQL and other RDBMS?

"Niall Litchfield" <[e-mail]> wrote in message news:<40b25fc8$0$20518$[e-mail]>...

> "Quirk" <[e-mail]> wrote in message
> news:[e-mail]...

> > 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,

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.
 
> > 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.

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.

> > 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,

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

> > 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.

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.

> > 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..

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.