Re: What so special about PostgreSQL and other RDBMS?

From: Quirk (quirk_at_syntac.net)
Date: 05/19/04 

Date: 19 May 2004 04:20:53 -0700

[Oracle and Sybase groups removed]

> > > > Realy, care to quote the part of the Contract that Gaurantees you any
> > > > rights?
>
> > > http://oracle.com/support/index.html?policies.html
> >
> > I asked you to QUOTE the part of the Contract that Guarantees you any
> > rights, not post a link to a description of support options and what
> > they cost.

> That IS the licence agreement.

Once again, what I asked Volker was to quote the part of the contract
that Gaurantees him any rights, he was of course unable too, this his
ugly equivication.

> > "Oracle may provide additional releases or versions of its programs
> > in the form of an Update as part of our technical support services. It
> > may become necessary as a part of Oracle's product lifecycle to
> > desupport the programs and, therefore, Oracle reserves the right to
> > desupport its programs."

> So? That's what desupport notices are for. The good thing is that
> you find out beforehand, not after you start asking around because
> the latest ftp download is from 1996.

Again, trying to imply that free sofwtare is likely to not have been
updated since '1996' is another Fallacy, as is usual form the
closed-source zealots, since a lot of free software is frequently
updated, especialy popular packages, just as many closed-source
software is not updated until you pay for a new version, the
'Desupport' notice is in this case simply a gun pointed at your head,
to force you to upgrade, I have no idea why the likes of Volker find
comfort in these.

> > If my application required a cucumber, I wouldn't sign a deal with a
> > cucumber vendor that insisted I could only buy cucumbers from them,
> > for ever, even if their cucumbers no longer work for me, while they
> > could stop providing cucumbers any time they feel like it and still
> > forbid me to use my own, proprietary cucumber dependant, application.
> > I would, at least, make my application work with any cucumber.

> But what if you required a cucumber with special properties, like a monsanto
> engineered one which contains some drug you want to sell?

I would avoid depenending on, let alone eating monsanto cucumbers.

> > This converation has gotten ridiculous, can it be that you really
> > don't know the difference between a cucumber and an application
> > dependency?

> It's a buying decision. You invest money and get a ware. Open source
> is only different in that you can go behind the stall and see whether you
> can make something of the stuff they dropped.

No, in the econonic sence, open source means perfect competion, the
consumer wins, closed source means a protected market, the consumer
should beware.

> > Yet in this case, you could have purchaced gcc support from another
> > company, however, without source, you would not have this option.

> No, I couldn't because no one else was selling it.

Yes, there are plenty of people who will fix a bug in GCC for you,
check the GCC contributors list for a starting point.

GCC is very widely, and successfully used and many projects large and
small, that Volker's company was too stupid to use it, tells you much
more about them, than it.

> And this after I just detailed how a migration is made way more difficult by
> all the other bits that change and that the underlying database is really the
> least of

Volker can not seem to understand that many applications are different
than his, than in many cases the application does not change.

In anycase, if the application is abstracted, migrating is at least a
little easier, regardless of how much else there is to do, at least
the code that needs to change is issolated.

> > Worth posting what? Your great advice that developers should *NOT*
> > abstract their code?

> That they should think before they abstract.

They should think in every case. This was never in dispute. They
should also think before not abstracting, before chosing a
closed-source product, before keeping archives in a format that might
be inaccessable later, thus my good advice.

> > Too bad you have no actual argument to repeat, you are merely
> > repeating your empty rhetoric and unsubstantiated bunk.

> That seems so to you because you can't read back more than one quote.

No, it is because Volker doesn't have, and have never had a clear
argument, whereas my argument has been consisted, and every point
defended since my first post.

> > > The right to the source code does not mean
> > > anything useful, see the part you quoted below.
> >
> > Yes it does, it's too bad you don't understand it.
> >
> > If I have the source code, I know I can relly on a product for ever,
> > and never talk to the original developer again if I so chose. Withouth
> > source, the developer holds all the cards.

> You know what, you do that. Use any open source database, and
> ten years after the project has been abandoned you go and port
> it to another platform, and try to get customers to use it okay? Then
> we'll talk again about "forever".

Once again, Volker promtes the fallacious belief that open source
products will automaticaly have a shorter life span than closed source
products, and once again, since their is no logical argument that can
made to support such a wacky belief, he resorts to rhetorical
pretentions.

The truth is that popular products will have a longer lifespan than
unpopular products, and since there are popular open source products
and unppoular closed source products, his argument is nonsencical.

> > Let's take a simple case, say you hired a consultant to write you a
> > simple
> > application, say a specialized contact manager.
> >
> > When the project was over, would you let the consultant leave your
> > office, only turning over a compiled binary of the application? Or
> > would you insist that he provide the source?

> Depends on how simple and how frequent my requirements change.

Once again, Volker does not understand the need to recompile the
programm, even when it has not changed, like for a new cpu, a new OS
of because of security update. Again, I guess I should not expect much
more from unskilled labour.

> If he's the only guy that understands it I'd insist on maintenance
> and a customizing possibility (like ActiveX or an integrated tcl interpreter).
> If the requirements are volatile I'd do a long term contract detailing what
> money he has to pay for getting out of it.

And when he gets hit by a bus?

>
> By the way, we did a bit of chip design before and had a tool made by a small
> company situated here near Augsburg. Great tool. There we did what I
> said (with the customizing) and we also got the source code.

Good. clearly, someone in the company has more brains than Volker.

> And you know what?
> It was much too much bother even to get it to compile, much less change.
> It was always cheaper to let those guys do the work. And what do you think
> would have happened if we had wanted them to support code *we* modified?

Having source means the *right* and *ability* to have it modified, it
does not mean that *need to* or *should* modify it.

> > - If a Dead Database means your application is also dead, if
> > migration is impossible; having source code can save the day.

> My customers won't want a dead database so I'd have do
> migrate or die anyway.

A free databse is not more likely to become a dead database that a
closed-source database. In fact, bacuese it can survive the death of
the copyright holding firm, it is less likely to become a dead
database.

Yet, if the database is dead, at least with source you can go on, if
needed, without you can not.

> > - If migration is possible, migrating is easier with abstraction.

> Weakening the case for the rights ot the source code.

No, not at all, making a different case to protetc yourself in a
different, complementary way.

> > - If you have source *AND* you have abstracted, whoa nelly, you are
> > in *really* good shape.

> As I said before, database migration isn't hard.

Changing a few lines of code in one place is easier than chaniging it
out throught a large application.

> > - If your data is archived in a self contained, self describing,
> > human readable format, why, you are all but invincable.

> Another case on not reading what I write.

Why does Volker assume I only talking about him and his company, what
he is qouting is my repeating my original advice, trying to give him
some context of my original suggestions, that he is, for some
inexplicable reason, trying to dispute, because he feels my advice is
not needed for his obscure application.

> > And closed-source applications have never been abondoned???

> Which database do you have in mind?

The statement asks where "closed-source applications have never been
abondoned" what makes Volker think I have any particular one one mind.

> > Another simple question: If your application is abandoned, are you in
> > better shape with, or without source code?

> I assume, you mean if my database is abandoned.
> It doesn't matter because I'll be migrating anyway.

And again, my advice including abstraction, makes migrating easier.

> > Yeah, what about them?

> They are dead.

So are most of Volker's brain cells, evidently.

> > If you are dependent on them, at least you always have the source code
> > and can thus continue to use the product,

> I can do that with oracle.

With closed source applications you can not continue to use it,
because you can not recompile it for your new CPU, your new OS, or for
the latest security updates of it's libraries.

> > even have it modified if you
> > need to.

> I can't because it's unmaintainable.

Of couse, the intlegent reader will not that you can and all Volker
has done is call something 'unmaintainable' with out explaining why.
> > Reminder: I am an the one advocating Abstraction, which would make it
> > easier to migrate to another database. What the hell are you talking
> > about?

> No, you are the one talking rights to the source code. Abstraction is
> just a side tracking because the right to the source code should, in your
> world nullify the need to abstract.

No, abstracting, having source code are two good things, having your
archives in self-contained, self-describing, human readable files is
thr third suggestion I made, all these are good, all of them
complimentary.

Abstraction is, of course, made more important if you do not have
source code.

> > And If, for some reason, you *must* repair the database, say the bug
> > is simple and is easier to fix than to migrate a large working
> > implemtation, at least with the source, you can, without the source
> > you can not.

> If the program is fixable it wouldn't get abandoned.

Another fallacy, a program might be abondoned for many different
reasons.

> > Leaving the customer stranded because your application is hosed by an
> > obsoleted dependency is even a harder sell.

> So, we need the original maintainer org to do the maintenance because only in
> that case you can get one consistent version hosting all apps, right?

No, many orgs can contribute to an open source project, and even
maintain
there own forks when needed.

> And if the db is dead *all* apps would be dead too, right?

Only if the case of a close-source db. An open source db can be braugh
back to life, or in anycase, kept alive in the one production
environment your applucation needs it, until migration is completed.

> Where's the difference to a commercial app then?

When your closed source db dies, all applications are one security
update or server upgrade away from dying with it.

> > Without source
> > code you can not fix a program.

> I can fix a program by telling the vendor to fix it, remember?

In the case of closed source application, the vendor can ignore you.

> > You can do what you want, my advice is just that, advice, many people
> > are in different situtations from you, and have a different point of
> > view.

> Typically they sit at universities and have access to plenty of cheap and
> skilled labour.

This is idiotic, and outdated characterisation, and of course, another
fallacy, since it does not respond to the quoted statement.

> Sometimes I still envy the TeX group at my old university.

I am sure the envy is not recipricated.

> > > Do you develop for platforms other than linux?
> >
> > Yes, I have and do develop for many platforms, but *I* am not the
> > topic of this thread, despite your desperation. Once again, you only
> > attack the arguer because you have no argument.

> So, if windows or MacOs is among them I guess you will be dependent
> on some libraries and kernel properties that you don't have access to,
> right?

No, an application may support certain envoronments with being
dependent on them.

> > In many cases you can aquire a support contract from corporations that
> > have the original developers working for them.

> Right. At which we are back to the point where open source doesn't give
> me an advantage.

The only point is that VOlker is unable to understand the advantage,
it seems though that he has a bone to pick and does not really want to
understand.

If any others have further questions, I will be happy to respond, but
clearly Volker is just wasting my time and his own.

> > > And even if I buy some incident based support contract, there is still
> > > no difference from an incident based support contract with oracle.
> >
> > Yes there is, since you value the original developers so highly, we'll
> > try this example.
> >
> > The best original developer of Oracle, the one with the greatest
> > knowledge of the system and code, quits Oracle and goes to work for
> > Databases-R-Us, since you have no source, you must continue to deal
> > with Oracle, the copyright holder, and can not hire Databases-R-Us,
> > who employ the developer.

> You are mixing something up here. Oracle doesn't depend on
> a single freak but on a well maintained turnover process.

Oracle, like any company, does depend on a few highly skilled people
who would be difficult to replace, and whole army of unskilled labour
to take care of the ruitine stuff.

> What you mean is what open source software is famous for.

Good, popular, Open source products, of couse also have a good, and
quite transperent turnover process, can keep their highly skilled
contributers throughout there careers, and are aided by a world wide
user community in taking care of the routine stuff.

Volker is attempting to portray all free software as being small,
hobby, projects, but this is hardly the case at all.

PHP, Apache, MySQL are but a few examples of well organized projects
that one can certainly relly one.

> So, PostgreSQL Inc would be the one we'd be dealing with.
> I didn't find Nusphere of Cybertec on PostgreSQL Inc's homepage,
> at least not in the partner section. Can't be much love then that's lost
> between them.

PostgresSQL Inc, BTW way is not PostgreSQL Org, but rather a support
company that is but one contributer to PostgreSQL Org.

> > However when Oracle lets you talk to a programmer, that is just who
> > they let you talk to, some average programmer they picked off the
> > street, the good programmers in their organisations to not work in the
> > support department, but rather on new features for new versions and
> > products to sell.

> Actually, that depends on how long the bug stays unresolved.
> they escalate bugs. Of course the first guy is there to make sure you've
> read the manual but then you get the development guys.

Volker, being unskilled labour, easyly thinks that the next line of
support os a 'development guy' - -this is not true, you will never get
a real developer doing support.

> > Or instead of IBM they could have been bought by CA, and fucked up
> > royaly. Or just been allowed to disapear.

> Databases have customers which are worth a lot. Do you think IBM
> bought them for their marvellous technology?

No, for there hostages, I agree.

> Who is CA?

Computer Associates.

Be filled with dread if your platform is baught by them.
 
[remaining crap snipped -- I have no more time for this, if I have
neglecting to respond to a real argument somewhere in it, please bring
it up again]

Regards,