What so special about PostgreSQL and other RDBMS?

[Jeff Rodriguez]

Part of the beauty of SQL is that there are standards which if you try and stick
with, you can relatively easily migrate to another solution such as PostgreSQL
once they reach maturity. PostreSQL really does support a lot, however they're
missing the speed, tools, and high-availability addons of MS SQL Server.

For a company that does thousands of dollars worth of transactions per minute,
such as the one I work for, that $14,000 per processor is a small price to pay
for the reliability we can get from a commercial app. such as MS SQL Server.

Do I like the fact that MS SQL Server is closed source? Of course not, however,
if I had a choice of commercial support providers I would definetly choose
Microsoft; open source or not. I don't know if you've ever had to use their
support, but you can get on the phone with them and within a couple hours have
just about anything worked out. Why? Because they're big, they've seen damn near
everything.

I do not believe that closed source software it infallible, however nither is
open source. Now I'm not going to say that we've never been hacked, because
saying so will make me out to sound like an ignorant ass. Instead I'll say that
we are not aware of ever having any problems with our SQL Server being hacked.

Anyway, down to what matters:

What I am trying to do, is to give some sensibile advice on what a
choice between closed and open source really means, namely that closed
source means an *exclusive* external dependency, when entering such a
dependency you are extreamly vulnerable and should only do so with
both eyes open, after you have determined that this is justified for
you needs. And even then, you should have an exit strategy so that
your investment is not lost when the relationship ends or the external
provider's product loses whatever advantage they had when you made the
deal.

In the case of SQL Servers, sticking as close to standard sql as possible gives
you an exit strategy. Extremely vulnerable? I disagree, if Microsoft were to die
tomorrow by some will of the software gods, someone would just pick up the
pieces and carry on where they left off. MS SQL Server would be sold to someone,
along with the licensees, yadda yadda yadda.


In conclusion I do not agree that using a closed SQL solution makes you
vulnerable, because there will always be support for you as long as the product
is still popular. MS SQL Server is very popular, and by the time one might
consider switching to a new solution, the open source solutions will be large
enough to be considered viable. Hell, if we're lucky maybe Novell will pick up
PostgreSQL...

 

[Volker Hetzer]

Your argument, as usual, is that I should just believe you, not
because you have explained yourself, but just because you *know*.

Wrong. My argument is that I've taken your "suggestion" long ago.

My orignal comments still hold true, the right to sue is cold comfort,
the right to pick up your pieces and try somewhere else, keeping your
application in tact as much as possible, is better.

It simply doesn't work. Try it sometime.

Even easier if you have abstracted your data access with a simple
function, and then used that function throught your application. I
have no idea why you find this so hard to believe.

As I said before, "a simple function" doesn't do it because
there are lots of other things specific to a database so that
the porting to another database won't be significantly eased.
And, I'm trying to convey this too, there's no need to ease it
much more because it's not much trouble anyway.

And for what purposes are you bringing up changing the application?
How is this comparison relevent? I am trying to explain how to protect
your investment in your application; to change it as little as
possible.

I'm trying to tell you that whatever API I'm using, the application
is protected enough against any change.

You make so little sence I wonder what is motivating you to carry on. Whatever.


Abstraction of your database access is a good idea. Why are you so
hell bent to dispute this.

It depends on how much performance it costs.

They [support contracts] make even more sence if you are not locked in to a single source.

I was talking about the case where I go to the developer and ask him
to do something for free.

Why would anybody do work fo you for free? Are you a charity of some
sort?

You started out by saying that maintenance contracts are evil things
devised by the big companies to suck their customers dry. Now suddenly
it's obvious that I pay for changes/fixes and that this is a cost factor when
deciding about an investment.

And the relevance of this is....?

That it doesn't make sense to turn me or our company into database specialists.
That therefore access to the source code doesn't make sense to us.
Even if we hired some other company, the only thing we need is having *them*
accessing the source code. If you've done any work under NDA's you'll know
what a difference this is.

If it did come to a dispute, they could not have supported there own
application, they where exclusively dependendant on an outside firm.

You are talking ifs here. The contract was as it was and they were right.

Because he had no right to go elsewhere if the vendor failed to
deliver.

And in what way is that different if mysql AB goes bust and fails to deliver?

Relevence? What insurance is provided in the case here?
Fire insurance you can buy, I have never heard of application
obsoletion insurance.

Maintenance is insurance to the database vendor. For a fixed price (or whatever)
the vendor agrees to do maitenance work. The database vendor obviously
balances maintenance costs and development costs, trying to minimize both.

The original point being, you can not recoup your own investment, just
the purchace price.

Yes. The same is with open source software. At least if you place a reasonable
limit on the costs to maintain the open source software yourself. (Reasonable
meaning it should cost less than a migration to another supported product.)

If they where a credible provider of support and development for this
particular product, they would certainly understand the code.

Well, looks like the only credible supporter of mysql is mysql ab.

Huh? No, like a competent development comany providing devlopment
services, exactly like Oracle does, but without trapping you into a
sole source situation.

And right now it works because they all more or less follow redhat.
Nevertheless, each commercial software gets certified for single platforms,
therefore you are still tied to a single distribution, or the supported
subset.

Your question is yet another fallacy, since you are responding to a
general statement,

So, who is the competitor for mysql ab?

IBM Application development and systems integration
http://www-1.ibm.com/services/us/index.wss/it/bcs/a1000402

Yes. Doesn't mention support or databases anywhere.
I had a look at the arcadia case:
"Key Components
Software IBM Lotus® Domino(tm)
IBM Lotus Notes®
IBM DB2® Universal Database(tm) for iSeries(tm)
IBM Net.Data®
Servers IBM iSeries
Services IBM Global Services"

If you can change it, you are not 'locked in.'

So, if I can change the db from oracle to db2 I'm not locked in either.

All these question depend on the case, and have nothing to do with the
topic, if you have a right to the source you are safer that if you do
not, if you have abstracted your access you are safer still. What is
it you can not understand?

That I am supposed to be safer with a bunch of code that, in the case
I need it, is obsolete or takes time and expertise to get into.

This conversation is becoming surreal.



You have the *right* to use it and have it changed for ever and ever,
not only by the permission of some outside company.

So what? The right to use it doesn't make me a programmer for that particular
database. It doesn't make anyone else (short of the original maintainers)
a programmer for that particular database on short notice. It doesn't make
the maintenance cheaper than the migration to a still supported database.
And it definitely doesn't make my boss keep a bunch of abandoned code
that we are the sole users of.

No, he can simply ignore you if he decides the relationship is no
longer profitable for him. You can do nothing.

I can stop paying maintenance and go somewhere else.

That's all I'm saying, Abstraction is a good idea. I was giving some
simple, good advice. What are you saying?

That "elegance" is more than "abstraction" and means different things
to different people. And abstraction doesn't always make sense either
because from a technical point of view one decides for a specific
product because of the specific properties of the product. If you
abstract away from them you won't need it either.

Nobody asked you to.

But you always tell me how good it's supposed to be. Well, it is not.

You have the right to use the product and never
talk to the developer if you like. You don't need to change it to
enjoy the rights
that source code gives, that is the right to use the
product for ever, and even have it changed *if you need to*

Oh, I've got the right to use oracle forever too. It's only what I
want updates that I have to talk to them.

My advice is to abstract when you have no source code, and perhaps
even then, I have repeated this many times and am not sure what you
are even disputing.

Your advice. Abstraction means you won't need/use a distinguishing feature.
This might cost you performance, it costs money to implement, if only that
feature makes your app possible you simply can't abstract from it and if the
interface is standardized anyways you don't need to bother either.
Therefore abstraction is to be decided on a case-to-case base just like
any other thing.

Yes, that's why I am *recomending* abstraction. Are you just typing
compulsively at this point?

No, I'm showing you the contradiction of your arguments.
If it's easy to change, the case for code rights disappears. Which way do
you want it?

Abstaction means your application can run for different clients with
different databases then. double plus good.

But, and that's the point here, if every vendor provided its own patched
mysql database the customer would be even more pissed off.
Believe me, it's easier to say "we require oracle" that "we require you
to run my oen hacked version of MyFavouriteOpenSourceDatabase.
Are you trying to change thread from opensource to abstraction?

However if your application is tied to one database, then the very
client you are describing is the very client that you will not get if
they use a different database from yours.

We do have such an app here. The result is that it doesn't run well
on *any* database.

But if they only sent there money to Lary because they purchaced your,
unabstracted application, they would be pissed off when it did not
work, and you blamed it on Larry.

Ah, but I only blame it on larry if it's larrys fault.

Exactly, so how are you going to accomplish this with your
unabstracted application? Do you even remember what side of this
debate you are on?

I use a database that can do that and tell them to get the discount
version if they don't need it. How do you going to accomplish
that with an open source app where you are the only surviving
supporter? Just to get back to the open source topic here.

Why do I have to?

Why would you have to provide support for a database then?
Remember you disputed that it's a good idea to let larry provide
the oracle support.

Since I can hire one of a million support providers
for any OS,
however for OSes without source, they can't do much when
the problem is with the OS itself. Same with the database.

So, how many have you under contract and how do your customers
react to the news that they have to run your own linux distribution?

Again, my argument summerized for the millionth time: If you have no
source Abstract access for sure, and it's also a good idea to abstract
access even if you do. I'm baffled how you've turned this into such a
long conversation.

In case you've already forgotten, the topic was open source, not abstraction.
In your case abstraction wouldn't have made sense because you won't ever
need to change the database because you'd just carry on supporting it or
buy the best (probably original) developers and go on, right?
But the abstraction thingie was a nice diversion.

Greetings!
Volker

 

[Volker Hetzer]

You are unlikely to be locked-in to purchase decision for your
cucumber for very long.

Also, maintenance is more like an emergency ration. If you discover
it's rotten after the mergency has happened you are in trouble.

IME they start to go runny after only a week or two in the fridge.

Right. With databases the feature stuff typically gets sorted out in the first
three months, maintenance took us about the same time (four or five service
requests) and everything else is a gamble.

Fortunately we always have some students here resulting in a healthy flow of
service requests, equivalencing a ration sampling regime.

Lots of Greetings!
Volker

 

[Volker Hetzer]

Is this grade school?



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. Or at least tke part that deals with after sales stuff.
That's exactly the link the licence agreement for the database points to when it
comes to what wecan expect for paying support.

And even so, if you bother to read that page you would have noticed
that it is mostly about protecting Oracle's rights from you, not
granting you any.

For example:

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

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?
What if you required support in case someone chokes on it and
the support company requires you only to buy certified 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. That's where the "for free"
stuff comes in.

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.

any more.

What nonsence, please demonstrate this by comparison, I have clearly
responded to all your arguments, regardless of how little sense they
made.

"> > > > > > The right to modify is a red herring.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
your worries when migrating to another app or the same app ten years later.
I brought up the chip design example because we've been through this.
I gould give you a board design example we are going through right now.
System 1 used informix, system 2 uses oracle. Guess what's the only part
of the migration that doesn' t give us any problems.

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

That they should think before they abstract.

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.

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

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

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

Why are you struggling so hard with such simple logic?

Because it's erroneus.

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

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

Weakening the case for the rights ot the source code.

- 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. For our new board design
tool we developed a database interface from scratch. 4 weeks, including
testing.
And yes, we went proprietary because otherwise we'd have spent ages
doing all the generic layers. And if oracle dies, so what? If our app
really still exists then we'll spend another 4 weeks interfacing to
wherever we want!

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

Thus my advice.


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

Which database do you have in 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.

Yeah, what about them?

They are dead.

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.

even have it modified if you
need to.

I can't because it's unmaintainable. At least groff is, to stay with that
example. It already was so in 1993.

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.

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.

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?
And if the db is dead *all* apps would be dead too, right?
Where's the difference to a commercial app then?

You keep basing your entire argument on nonsencical out-of-hand
dismissals, like 'it simply doesn't work.'

The difference is we've been through this and we are using open source
software and, to go back to the subject line of this thread, open source
databases for mission critical apps don't work better because of the right
to the source code. If I find a but in tcl I'll put it the activestate and let them
sort it out because I'm not going to maintain my own test suite and adapt it
to every new version. This is even more important for databases where I might
even not have a means of recovering thedata if my fix results in corrupted data
half a year later.
Btw, do you know what ARM paid for gcc support?
Over half a million bucks if I remember correctly. This for a supposedly
free product they could have fixed/ported themselves.

It does work, let me let you into a little secret: programmers modify
source code, that's how programs are made and fixed.

Or broken.

Without source
code you can not fix a program.

I can fix a program by telling the vendor to fix it, remember?
At least I can do that with all the programs we are currently introducing,
oracle and the said board development tool included.

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. Sometimes I still envy the TeX group at my old university.

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? Only I'm trying to learn from you.

The assertion you quote remains true, and your response, as usual, is
not a response at all.

Just you stating it doesn't make it true. People are creative, that means they
can do things you can't. So to use them you become 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. Remember, if I want informix support today I can go to
IBM too.

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.
What you mean is what open source software is famous for.

The best original developer of MySQL, the one with the greatest
knowledge of the system and code, quits MySQL AB and goes to work for
Databases-R-Us, since you do have source, you no longer need to deal
with MySQL AB, the copyright holder, and can instead, choose
Databases-R-Us, who employ the developer.

Fortunately commercial software rarely depends on one individual.

Suing him is a red herring. You applicaion is not powered by law
suits, but rather by compiled source code.

But it is powered by lawsuits. At least by the threat of it. Just
like boeing or airbus are when it comes to engineering security in.
They buy insurance against lawsuits and, with the insurance company work
out a process of ensuring quality which keeps the premiums down and
the insurance from losing lawsuits.

If stating the obvious is somehow of help to you, you're welcome. Whatever.



Try what?

Doing a maintenance contract and then measuring the few minutes per week
spending kicking their asses compared with all the programming you'd
have to do for yourself.

They also have an interest in dumping relationships that are no longer
profitable, and may not be interested in your obscure problem or
implemention, but rather more interested in selling you (or someone
else) something new.

In that case they'd offer me a migration path too, of course. Also,
if you ever manage to spend a few dollars on a oracle standard version
you might want to look at their bug site. Then you'll see to what lengths
they go. Personally I haven't hit any of those "too obscure" problems
yet. I've hit a couple real bugs, and once or twice they have nicely told
me that the problem wasn't what I thought but that my shitty code (first
steps as a PL/SQL programmer/first steps oracle spatial) crashed the
parser and that this was fixed in the next release the patch of which
was available already for download.

Other organisations may be quite interested in helping you, but are
unable to because you have no source code for them to fix.

If the main developer company abandons the product how long
do you think the others will survive? Besides, who tells
me that the others aren't just passing the service requests on to
the real one?

I would not recomed you 'pick some average application programmer off
the street' if you want to sort a bug in the postgres optimizer.

Many developers could do whatever you want, for instance: PostgreSQL,
Inc (not to be confused with PostgreSQL Org), Cybertec Geschwinde &
Schoenig, NuSphere, or many others which know the system well.

Nusphere takes one branch and supports that.
Cybertec can't even proper spell the stuff on their homepage.
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. Which makes me wary about relying on any of those
other two as a failsafe.
The fact that it's worth for nusphere to support one port also makes
me hesitant about PostgreSQL Incs policy re platforms/versions.

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.

Only as long as it is profitable for them and no more, then you get
'Desupported'

No, not "I" get desupported, a product gets desupported. For
all users.

Just you?

All it takes is a poster session at the next oracle world and it
won't be "just me". At least not if I had anything to complain about.

Only as long as you pay, and only on their terms, if you have source,
you need not change a working system just because it is not supported
by Oracle anymore.

I don't need to do that for oracle either. At least not as long as it runs.
And not, even for a open source software I would wait with the migration
for the first bug after desupport.

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?
Who is CA?

Again, you are depending on
good luck and good graces, if you have source, you know for sure, but
as I've said many times, it's even better to have an abstracted
application.

I'm not repeating again the problems of abstraction. Nor the easyness
you can migrate between databases today.

And by the way, don't think that IBM is above squeezing these newly
aquired hostages for every penny they are worth, and tosing aside the
ones who helping would not be profitable. You dont become a 100
billion dollar company by being stupid.

And you can't "toss aside" paying customers. Not sure if you are russian
and live in russia but if you are and do) you haven't got a particularly nice
capitalism working over there. Maybe you view problems as ordinary
that are viewed as pretty exotic in western europe or the US because
your country really works that way. Rest assured it's not so in the rest
of the world.

When you stoop to making ridiculous, incoherent, awkward streches of
logic to keep this conversation going on and on in the face of clearly
explained, good advice.

Ah, but I don't. Besides if I were you I'd leave the evaluation of your
advice to others.

Se here is a good example of your jumping up and down waving around a
fallacy a s if it was a point.

I did no such thing, I only explain what an elegent solution might be
//in this specific case// just as it says.

I never claimed to solve the general problem of elegent coding for the
rest world, this is just you wildly contorting yet again.

"you can solve this with your own wrappers through elegant coding".

And so does constantly changing everything to support differnet
databases when he finds your unabstarcted application does not use the
database that all his other applications do.

Believe me, it's easier to maintain three supported commercial databases
than three unsupported (because app-vendor patched) mysql databases.
there goes again your argument in favour of the private source code
modification.

And locked themselves out of the portion of the market which does not
use PL/SQL, but rather something else, or simply does not want to
bear the cost that using PL/SQL adds to the product not only on
implementation, but also in anual licencing and support costs.

The cool thing is they *still* required oracle. The other cool thing
is that somehow all the big customers (i.e. the ones with real money)
aren't really interested in mysql because of all the missing backup/recovery
and standby tools.

No, you only have to maintain the one you actuall have in production.

Per app. With a commercial db *I* tell them which version to use.

In most cases it does not make sence to build your application to
depend on Oracle, or any thing else, exclusively. However there are
certainly worse products to be dependant on, MS SQL for example.

Even this depends. If you are programming exclusively for windows
it's not a bad choice.

Again, if by 'We' you mean some imaginary person the rest of can't see
or hear, please ignore my intrusion, however if you mean You and I, we
are not.

Please read the first article of that thread.

We are talking about two different things, the advantages of source,
and the advangates of abstarction of access,

No. You are trying to change the topic.

I have made no comments
in this thread regarding commercial versus open source databases
except to agree that the commercial ones _do_ have more features, that
alone however does not always
make them the best choice.

See above.

Great, sadly however, not relevent.

Which ones have you worked with?

However, a closed source contract is designed to hold you hostage, and
to keep competitors away.

Forget about this okay? A contract gets designed by both parties, even
if the other side in this case is represented by oracles marketing department
that actually wants to sell the contracts. To big companies with big legal
departments.
And no one forbids me to run oracle and db2 and sqlserver on the smae machine.

No one you know is not no one.



The OS is a part of Network security, what manages user priviledges?

the OS.

The Switch? What controls device permissions? Your ethernet cables?

The OS.

Your network security is a product of the collection of OSes that make
up the nodes of your network. And the network is exactly as secure as
the weakest node.

Actually for a database it does not matter what the switch or anyone else
says. What comes throught the listener is what counts. Look up the oracle
architecture, or any other commercial one.

See, you have just provided an example of how bad network security can
undermine good database security, there are plenty of others as well.

No I haven't. Because having nfs tablespaces isn't good database security,
because it makes a database dependent on the security of the file
server. Which is not a network issue.

My point, once again, is that you can only have Database security,
*IF* you have a secure network, which means that the nodes on it are
secure.

You can make a database so insecure that it depends on network
security. It's a totally different thing.

Yes, that tool being the Application, the very thing following my
advice will help you protect.
Also, not all data is about creating
chips, in many cases the data is the purpose of the appliction, and
can outlive it, sometimes it must, by law, be accessible for a really
really long time,

Yes, and do you know what people do then?
They convert the .prn or .ps files to TIFF or
keep one machine with the original software somewhere in a
climaticed room and hope like hell the contacts don't rot.
We do have seven years liability here and storing bitmaps
of everything is what we do. And recopying them.
And no, we can't feed them into any current system, if we need to
deal with any seven year old problem we just print out the stuff
and look at it.
If you have that kind of advice to dispense, go and
ask for a job at Lufthansa or Siemens Medical. They are just
waiting for people like you.

like in the case of public data, as I said. In this
case in particular, keeping your data in a self contained, self
describing, human readable file format is good sence. That is why
things like XML and dublin core get invented.

See above. Just accept it. You really don't know what you are talking
about here.

Then your data does not have a long life span, so why are you
presenting it as an argument, when my advice was specificly qualified
to "ensure the perminancy and portabilty of your important data?"

See above.

If your data does not need to be either perment nor portable, why are
you discussing this, do you really imagine that because you data does
not need to be permenent or portable, that therefore no data needs to
be?

I'm saying is that regardless of the need, daya simply *isn't* permanent
or portable. Go, ask a bank why they still have the old mainframes running.
They should have the money to do things proper, right?

I can read
text files I created on my Apple ][, and no, I do not have the orginal
hardware (well maybe my mom does somewhere in her basement).

Not all textfiles are notices for you to read.

Yet some are, and for this data my advice holds true, I have never
implied that all data must be kept accessable forever, rather advising
on what to consider when it does.

That elegance is abstraction.

The quote says "That abstracting access to suspect dependencies is a
good idea" not "elegance is abstraction"

Yes, you changed that one from your original posting.

Here you are jumping up and down again.



It is, if you ask a security expert you will find they agree with me.



Instead, archives should be kept in a format that can not be readable
forever? What do you think archives are for? I don't mean simple
backups.

"This program has 400 features. No one will be able to use it."
"Ok, we'll add "ease of use" to the list."
Data isn't permanent out of choice but because no one has found a good
solution yet. Go, do your own, get rich. You've got my blessing and me
as a paying customer if it works.

You mean the same SAP that developed the Open Source SAP DB

It was old and they released it because they've milked it for what it
was worth.

and is now
working with MySQL DB in making it MaxDB?

Yes. And all the big installations run oracle.
If they get mysql to their feet support like, we'll have another look.
Besides, THEY are big enough to buy mysql ab if they want to,
right to the source code or no right to the source code.
Also, they invest money to spite oracle, which goes into SAPs market
by trying to buy peoplesoft. (I'm not saying that SAP's decision isn't
right, or oracle is blessed, ok?)
So, access didn't have much to do with it and it certainly isn't cheap
for them.

In anycase, I'm not intersted in what you are working on. It's
irrelevent and it sounds banal. Nor does it in anyway strengthen your
arguments.

I have put up evidence in terms of real world experience. What you think
of as banal or not is absolutely irrelevant to me.

How do you know what everybody thinks? you think what is posted in
this thread represent what everyone thinks?

Ok, you are the only one who posts this. OTOH I know the people
in a lot of other groups and have been corrected by them
before plenty of times .

Thanks, from now on I will never abstract my database access, ignore
network security, refuse to accept source code for any dependency of
my applications, insist on being locked in to single source for all my
support contracts and always, always keep my archives in an
incoprehensible filesystem blob that I can only access by way of a
third party, closed-source deamon.

You know, now that you say it it doesn't sound too bad?
You get a fast, efficient application, can draw on the development and
support expertise of other large successful enterprises and if your
customer wants permanency you can actually *ask him* how he would
have it done without trying to force your solution on him.

So we should not try to write good programms then? Quick, someone tell
Don Knuth.

The guy who still writes in TECO assembler? He might know algorithms but
he sure doesn't know coding.

Again: Not having source is a guarantee that one CAN NOT fix bugs.

Again: I don't have to fix them. I have to have someone fix them. Namely
the guys I've got the support contract with.

Who will fix the bugs when the vendor goes bust? Or compile it for
your new OS, or your new CPU? Or to link a updated library for which
there is a security patch?

No one. Who ports mysql to my cellphone?

And trim your posts better, you don't need to quote every line in the
previous post, only the ones you actually respond to.

The way you misunderstand me I'm tempted to leave everything in.

Sometimes it's best to change companies and keep the product,

Hm. Support from boeing for an airbus.

And you get what you pay for, do not imagine they will consent to
losing money on you for long if their costs go above your flat rate.

I don't care how much they win or lose as long as they fix the bugs.
Which they do. If they don't, I can still change.

Right, if fixing it costs them more that what you are paying them,
then they desupport you,

No. See my other post.

Who is the developer, you or IBM? If you are hiring IBM, why are you
messing with the code?

If not, why do I need the source code?

I'm sure, if you are willing to pay them
enough, IBM corporate services will indulge this crazy plan of yours,
but they will probably at least suggest you decide wether it is you
*OR* them who are developing the code, and if you already have screwed
it up, perhaps they might prefer to start with a fresh copy from MySQL
AB.

Great. We're making headway here.

Greetings!
Volker

 

[Quirk]

[comp.databases.ms-sqlserver removed]

Wow, five days later Volker is still scratching his head about this, I
though this thread was dead long ago.

Wrong. My argument is that I've taken your "suggestion" long ago.

Huh? If you have taken my suggestion, then why did respond to my
suggestions? Did you imagine, that although I was not responding to
you, somehow It was you I was talking about? As usual, you make no
sence.

It simply doesn't work. Try it sometime.

'Simply doesn't work' -- an unsubstantantiated out of hand dismissal,
which is, as anybody with clue knows, a fallacy.

'Try it sometime' -- Another attempt to portray yourself as having
greater experience, another fallacy.

Well, what more can we expect from Volker, the human fallacy?

As I said before, "a simple function" doesn't do it because
there are lots of other things specific to a database so that
the porting to another database won't be significantly eased.

The specific proprietary bindings can be wrapped in a simple function.
Additional functions can be used to issolate proprietry features.

And, I'm trying to convey this too, there's no need to ease it
much more because it's not much trouble anyway.

Thanks for all your effort Volker, but I will continue putting any
proprietary bindings my own functions, and use those functions through
out my application, rather than have proprietary binding through out
my application, and I will continue to recomend that others do the
same, you do whatever you want though.

I'm trying to tell you that whatever API I'm using, the application
is protected enough against any change.

The question was: Why are you bringing up changing the application as
if it was an argument _against_ my suggestions, since my suggestions
help protect your applications. Please try to follow.

Whatever.

I see. So so simple having nothing better to do? This will be my last
response in this thread then. At least outside the PHP newsgroups.

It depends on how much performance it costs.

Funny, that's what I said. Usualy however, performance concerns are
not terribly significant and the abstraction can be kept very light
weight.

You started out by saying that maintenance contracts are evil things
devised by the big companies to suck their customers dry.

No, closed source licence agreements are so devised. Maintenence
contracts are perfectly fine.

Now suddenly
it's obvious that I pay for changes/fixes and that this is a cost factor when
deciding about an investment.

You pay for labour, yes, why would this not be obvious?

That it doesn't make sense to turn me or our company into database
specialists.

I don't know what makes sence for your company, but it should be
obvious to you that my advice is not directed at your company
specificaly, and also, my advice is not to become database
specialists, but rather to not make your own application, especially
if it is a 'high end commercial application' as described in the post
I was responding to, exclusively dependend on a third party.

That therefore access to the source code doesn't make sense to us.

Access to the source code gives you the freedom to swith 'database
specialists' even if you never touch the code yourself.

It also means you never have to stop using the product simply because
the vendor wants to sell you a new one if the product continues to
meet your needs, since with source, you can recompile for for a new
cpu, a new os, or when new security updates are available for the
libraries it depends on.

With source, you have the assurance that the product is yours for
keeps, just like your own code, without source, you have no such
assurance.

You are talking ifs here. The contract was as it was and they were right.

Yet my advice is for the future, not the past, I see the example given
as cautionary tale because of the 'ifs'.

And in what way is that different if mysql AB goes bust and fails to deliver?

You still have the source code.

Maintenance is insurance to the database vendor. For a fixed price (or
whatever) the vendor agrees to do maitenance work.

Yet the vendor gaurantees nothing.

The database vendor obviously
balances maintenance costs and development costs, trying to minimize both.

The vendor only tries to maximize profits.

Yes. The same is with open source software. At least if you place a
reasonable
limit on the costs to maintain the open source software yourself. (Reasonable
meaning it should cost less than a migration to another supported product.)

You do not need to, just like if you design a curcuit with a
proprietary conector or a standard one, the former is expensive and
only comes from one comany, the later is cheap and comes from many.
Unless you really need the former, you would always chose the later.
In neither case are you required to manufacture connectors.

Well, looks like the only credible supporter of mysql is mysql ab.

There are as many as the market will bear, since there is no
artificial thing, like closed source, keeping competition away.

Since the Market is growing rather fast, and big names like SAP are
promoting it, I see no reason to worry about a lack of support for
MySQL.

And right now it works because they all more or less follow redhat.

What? Who follows Red Hat? What does this have to do with companies
providing development services? What are you blathering about?

Nevertheless, each commercial software gets certified for single platforms,
therefore you are still tied to a single distribution, or the supported
subset.

Different products have different cross platform stragies, the good
ones try and support the widest number of platforms, almost all
serious database software supports Linux now, including Oracle and
Sybase. But in anycase, I have no idea how this relates to anything we
are actualy discussing. Must be something funny in the drinking water
in your parts.

So, who is the competitor for mysql ab?

Anyone who wants to be, as many as the market will bear, each
competeting for customers and compentent labour with each other to the
benifit of the consumer, simple economics.

Oracle has you trapped because no one else can compete with them,
since their source is closed. BUT EVEN STILL, I am not recomending you
never use Oracle, I am only recomending that abstraction is a good
idea, particularliy when you do not have source.

Yes. Doesn't mention support or databases anywhere.

As I said, your question was a fallacy, since it was in responce to
the statement that many companies, including IBM, support open source
products, the statement did not say that IBM, specificaly, supports
MySQL, specificaly. Yet, if you wanted to, you could hire IBM to
support your MySQL implementation, if you had enough money, they would
be happy to take it. They do not promote themselves as such, and would
frankly be surprised to get such a contract, knowing that there are
cheaper alternatives and that MySQL users are not currently the
typical IBM consulting clients, however, with SAP behind MySQL AB,
this could soon change.

So, if I can change the db from oracle to db2 I'm not locked in either.

That's right, you are only 'locked in' if you can not change.

That I am supposed to be safer with a bunch of code that, in the case
I need it, is obsolete or takes time and expertise to get into.

If the code is a working part of your application, it is not obsolete,
however a closed source vendor can obsolete it on purpose to force you
to buy a new licence. And you need no expertise in it, since if your
product is popular, like say MySQL, the marker will attract lots of
competition for your business.

So what? The right to use it doesn't make me a programmer for that particular
database.

If it's a working part of a production system, you do not need to be,

It doesn't make anyone else (short of the original maintainers)
a programmer for that particular database on short notice.

If it is a viable market, there will be programmers for it.

It doesn't make
the maintenance cheaper than the migration to a still supported database.

It may make migration uneccessary by allowing new entreprenuers to
support it. Competition among them will even make maintenance cheaper,
and, of course abstraction makes migration, when neccessary, also
cheaper.

All this in perfect line with my adivice, as stated in my original
posting, and as still unrefuted in anyway by you copious blather.

And it definitely doesn't make my boss keep a bunch of abandoned code
that we are the sole users of.

First, if the system is widely used the code would not be abandoned,
second, a closed source product is not less likely to be abandoned
that an open source one, third if it is abandoned then you are in
better shape if you do have the code.

I can stop paying maintenance and go somewhere else.

You must also stop using the software then, and bear the costs related
to that.

That "elegance" is more than "abstraction" and means different things
to different people.

I have not attempted to define elegence for different people, only
given specific examples.

And abstraction doesn't always make sense either

I never said anything *always* makes sence, all projects have their
own requirements, I have only given some general advice, good advice.

But you always tell me how good it's supposed to be. Well, it is not.

No, I tell you that source gives you freedom to chose, but sadely,
you have trouble understanding simple things. It's probably quite a
good idea for you to pay Oracle to think for you, in your case, I
withdraw my advice, however it still holds true for others, mor
compitent profesionals

Oh, I've got the right to use oracle forever too. It's only what I
want updates that I have to talk to them.

First of all, you do not have any such right, secondly, without
source, how you will compile it for your new CPU, or new OS, or to
link a security-updated library?

Oh never mind, just call Oracle support, you are obviously unskilled
labour.

Good luck to you.

Your advice. Abstraction means you won't need/use a distinguishing feature.

If you do not need to use it, yes, if you do, then //issolate its
use// in your code with a wrapper function.

Therefore abstraction is to be decided on a case-to-case base just like
any other thing.

Funny, that's exactly what I said, many times in this thread. Yet
abstarction is good advice, which is, as I've also said many times,
all I have offered.

No, I'm showing you the contradiction of your arguments.

No, all your showing is your inability to follow a simple arguments.

If it's easy to change, the case for code rights disappears. Which way do
you want it?

The 'case for code rights' does not disapear, but by abstarction,
becomes less important, since abstarction is another layer of
protection. This has been clear from my very first post in this
thread. Keeping your archices in self-contained, self-describing,
human-readable format was my third recomendation. If you have all
three, you are in the best shape if your application and/or data has a
long life span.

But, and that's the point here, if every vendor provided its own patched
mysql database the customer would be even more pissed off.

No one is recomending this, that is only your own red herring. The
customer prerers abstacation when it means that they can use there own
database, if they only use the database for your application, then
they see the database as a part of your application, and only want it
to work.

Believe me, it's easier to say "we require oracle" that "we require you
to run my oen hacked version of MyFavouriteOpenSourceDatabase.

Depends on the costumer and wether or not they want to bear of adding
Oracle to their environement.

Are you trying to change thread from opensource to abstraction?

I am not trying to change 'the thread' -- I posted my recomendations,
which included abstractions, you are responding to them, therefore in
the discusion between you and I, it is my suggestions that are the
topic and my only intrest is in defending them, I have no other reason
to discuss anything with you.

We do have such an app here. The result is that it doesn't run well
on *any* database.

As I said, there are bad applications, both abstracted and
unabstracted ones, your argument, is, as usual, a fallacy.

Ah, but I only blame it on larry if it's larrys fault.

And, if your forced your customer into Larry's arms, they will blame
you, not Larry.

I use a database that can do that and tell them to get the discount
version if they don't need it. How do you going to accomplish
that with an open source app where you are the only surviving
supporter? Just to get back to the open source topic here.

I don't plan on being 'the only surviving supporter', yet another of
your fallacies, as the producs that I use are popular and their
popularity is growing, I also abstract my database access, so that if
this changes, I can change with the dominant trends.

(I wonder if you even know what a fallacy is, you use so so many of
them)

Why would you have to provide support for a database then?

I support my application and all the dependencies that I have forced
on the client by way of it. If my application fails because of a
dependency I have chosen for it, the customer will blame me.

Remember you disputed that it's a good idea to let larry provide
the oracle support.

Remember, it was limited to the situatuion where the customers only
dealt with Larry because of me. For the millionth time, please try to
follow.

So, how many have you under contract and how do your customers
react to the news that they have to run your own linux distribution?

What on earth are you talking about? I do not need to run my own linux
distribution. You are a nutcase.

In case you've already forgotten, the topic was open source, not abstraction.

I made a series of suggestions, including open source and abstraction,
you responded to my suggestions, therefore the topic is my suggestions
and your objections to them.

In your case abstraction wouldn't have made sense because you won't ever
need to change the database because you'd just carry on supporting it or
buy the best (probably original) developers and go on, right?

Well, you might have trouble understanding it, but I think I've made
it clear that both source and abstraction have their benefits.

But the abstraction thingie was a nice diversion.

Yeah, a 'diversion' I cleverly included in my very first post in this
thread.

What kind of idiot are you?

 

[Howard J. Rogers]

Quirk wrote:

[snip to cut to the chase]

Oracle has you trapped because no one else can compete with them,
since their source is closed. BUT EVEN STILL, I am not recomending you
never use Oracle, I am only recomending that abstraction is a good
idea, particularliy when you do not have source.

[Ditto]

It seems to me that if you are going to abstract because you lack the
source code, you are likely not going to be making much use of the
proprietary functionality you've just spent an arm and a leg on. Which
strikes me as a waste of money.

In other words, if you insist on taking out the abstraction insurance
policy, don't use Oracle, because it's just money down the drain for
functionality you're never going to use. Yet you say you would not
recommend never using Oracle. Stripping out the double negatives, that
presumably means you might recommend using Oracle *and* abstraction.

Personally, I think my software assurance comes from Oracle's size and
market share (and my support contract), and I don't need potentially
crippling abstractions to protect me against their failure at some
indeterminate and perhaps never-to-arrive point in the future.

I realise I'm butting in late, but that last post was soooo long, I'm
fairly confident not one person in 1000 is going to know what the hell
it was saying!

Regards
HJR

 

[Quirk]

[Oracle and Sybase groups removed]

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

They are dead.

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

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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,

 

[Quirk]

Quirk wrote:

[snip to cut to the chase]

Oracle has you trapped because no one else can compete with them,
since their source is closed. BUT EVEN STILL, I am not recomending you
never use Oracle, I am only recomending that abstraction is a good
idea, particularliy when you do not have source.

[Ditto]

It seems to me that if you are going to abstract because you lack the
source code, you are likely not going to be making much use of the
proprietary functionality you've just spent an arm and a leg on. Which
strikes me as a waste of money.

In other words, if you insist on taking out the abstraction insurance
policy, don't use Oracle, because it's just money down the drain for
functionality you're never going to use. Yet you say you would not
recommend never using Oracle. Stripping out the double negatives, that
presumably means you might recommend using Oracle *and* abstraction.

Hmm. Ok, well, first let me say I am in favour of the Open Source
databases, so it's a little awkward that I need to defend Oracle here,
but abstraction does not prevent you from benefiting from Oracle, for
one, Oracle has proven performance (even with standard SQL), security
and scalablity advantages that some applications and environment may
need and secondly, your product may need to run in a customer's
datacenter, where Oracle is the database they use.

Also, with lightweight abstraction, such as simple wrappers around
proprietery bindings, you do not realy lose performance, and when you
must use prorietary features, you can create additional wrappers to
issolate these.

By containing the Oracle bindings to only a few places in your code,
you make your application far easier to maintain and debug, let alone
migrate.

Using a large abstraction object may cause performance issues, but
using wrapper functions is just good coding in any case.

And regarding abstraction objects, as far as PHP goes, PEARB seems
to work well, with not to much lost as far as performance goes,
although I have not done any major benchmarking, and if performance is
critical to your application, you should. Ditto for Perl's DBI.

Personally, I think my software assurance comes from Oracle's size and
market share (and my support contract), and I don't need potentially
crippling abstractions to protect me against their failure at some
indeterminate and perhaps never-to-arrive point in the future.

And the choice is personal, so you are welcome to yours, however, you
can imagine that not all applications, especialy commercial ones, can
afford to tie themselves to one exclusive database, and many other
applications may not want to force there users into using one
exclusive database.

Also, your data abstraction functions need not be any more crippling
than the rest of the application's code, so if coding these will lead
to crippling the application, likely the application is well on it's
way to being coded into cripledom already. Also, abstraction will
generaly (i said //generaly//) have less impact on performance than
your data model will.

I realise I'm butting in late, but that last post was soooo long, I'm
fairly confident not one person in 1000 is going to know what the hell
it was saying!

Yes, I agree. Thanks for the truncation



 

 

[Galen Boyer]

And the choice is personal, so you are welcome to yours,
however, you can imagine that not all applications, especialy
commercial ones, can afford to tie themselves to one exclusive
database,

But then, that application vendor needs to have multiple code
bases, one to support each platform, each taking advantage of
that platform's performance characteristics.

 

[Noons]

Thanks for all your effort Volker, but I will continue putting any
proprietary bindings my own functions, and use those functions through
out my application, rather than have proprietary binding through out
my application, and I will continue to recomend that others do the
same, you do whatever you want though.

<nit-picking>
I really wish people would call things by the names they've had for
decades, rather than inventing new ways to say PRECISELY the same thing.
Let me provide the example:
"...but I will continue putting any proprietary dependencies in my
own functions, and use those functions through my applicatin, rather than
have proprietary dependencies through out my application..."

THERE! I've said it. "bindings" means exactly squat outside the world
of S&M. The correct term is "dependencies".

Funny, that's what I said. Usualy however, performance concerns are
not terribly significant and the abstraction can be kept very light
weight.

Actually, IME performance is the biggest concern. I still have
to see ONE application built using these modern "concepts" of
"abstraction" from everything and the kitchen sink that doesn't
have a serious performance problem outside of demo environments...

Access to the source code gives you the freedom to swith 'database
specialists' even if you never touch the code yourself.

Access to the source code of the database lets you do this?
I don't think so... I mean, isn't that the whole opposite
of abstracting implementation details?

Do what you recommend: wrap your application functionality around
the available API for the base-layer software, be that db or whatever.
And that's it. Why the heck would you want to become dependent on
yet another piece of source code? What's the point of writing
wrappers in the first place for something you have the source code of?

It also means you never have to stop using the product simply because
the vendor wants to sell you a new one if the product continues to
meet your needs, since with source, you can recompile for for a new
cpu, a new os, or when new security updates are available for the
libraries it depends on.

But, my dear cyber-friend: no vendor of anything considered
base-layer software like databases has EVER changed the product
so much that it broke all previous code! That would be called
"suicide" in market terms. It's never happened, it will never happen!
There is NO NEED to work around such an eventuality: it won't happen,
it's a wasted effort.

Now, if you have to interface to freeware, I'd be sick worried: there
is no guarantee whatsoever that some drongo won't go changing everything
next month. It's happened before many times. It's with freeware that
you need a STACK of wrappers to protect you from sudden underlying
code changes! Not with commercial software!

With source, you have the assurance that the product is yours for
keeps, just like your own code, without source, you have no such
assurance.

The question of course being: what the heck do I need that source
for in the first place?

You still have the source code.

I don't think Oracle, nor Sybase, nor M$ are about to go bust any day
now... Why worry about what might happen in 10 years time if
the average lifetime of any IT application nowadays is 3 years tops?
After that it's replacement/upgrade time. It's a waste of time
and resources to plan any further than that, I'm telling you!

You do not need to, just like if you design a curcuit with a
proprietary conector or a standard one, the former is expensive and
only comes from one comany, the later is cheap and comes from many.

It's the connector! NOT the entire wiring behind it that you need
to make portable, isn't it? Like I said: why bother with the
entire edifice of the source code for a db when all you want
is the API?

Unless you really need the former, you would always chose the later.
In neither case are you required to manufacture connectors.

Precisely. So, why bother with the source code that lets you
manufacture connectors? See what I mean?

Since the Market is growing rather fast, and big names like SAP are
promoting it, I see no reason to worry about a lack of support for
MySQL.

Now you lost me: ANYTHING that SAP promotes is emminently
objectionable and suspicious, IMHO! THERE is an example
of a totally proprietary company, if I ever saw one....

Oracle has you trapped because no one else can compete with them,
since their source is closed.

I BEG your pardon? Care to rephrase that? Since WHEN is
availability of source code ANY measure of competitiveness
or existence of competitiveness? Exactly where have you been
hiding if you think no one competes with Oracle? Helloooo????

typical IBM consulting clients, however, with SAP behind MySQL AB,
this could soon change.

I'll agree with that. Put SAP behind anything and it stops
being cheap and competitive...

If the code is a working part of your application, it is not obsolete,
however a closed source vendor can obsolete it on purpose to force you
to buy a new licence.

Don't confuse "making it obsolete" with "making it inoperational".
The two things are worlds apart. I drove a 15 year old car
for YEARS!

First of all, you do not have any such right, secondly, without
source, how you will compile it for your new CPU, or new OS, or to
link a security-updated library?

No one will, old chap. It's called upgrade lifecycle. You are
wasting a lot of resources and work making yourself obsolescence-free
in a society that made obsolescence a way of life about 30 years ago.

All this to say: I understand your motivation and it makes sense
in terms of engineering concerns. But, there is one thing called
(I hate to use a common place) "real world".
Wasted effort, in today's real world, to try and make an IT product
obsolescence-free.

Funny, that's exactly what I said, many times in this thread. Yet
abstarction is good advice, which is, as I've also said many times,
all I have offered.

Yeah sure. But abstraction doesn't mean over-complicate your work
by taking in even more source code! Abstraction is used PRECISELY
to reduce the amount of source code you have to worry about. That
is what an API is for!

What kind of idiot are you?

Now, that's the spirit!!!!!
Anyways I'm coming in late on this one, so reply only if
you could be bothered. I just thought I'd throw in a few thoughts
prompted by some things you said that rang a bell.

Cheers
Nuno Souto
(e-mail address removed)

 

[Joel Garry]

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.

Actually, I have seen both small and medium sized software companies
that have real developers doing support. With small, it hopefully is
obvious why, with medium, sometimes it is a policy of broadening the
employees experience, and sometimes it is due to the politics of
different groups seizing power and banishing those of a different
viewpoint to support. (I'm not talking about frontline or helpdesk
support here.)

With Oracle, I presume there are large organizations of both support
and development separated by a Chinese wall, but ocassionally I get
some back end support where the person seems very developer oriented -
I don't know whether it is simply someone bucking for a developer job,
or just working on replicating bugs gives them an insight, or what,
but it is invariably very useful to talk to such a person.


jg

 

[Doug Hutcheson]

Guys, Guys....
Calm down.
The propositions put forth by Quirk are becoming lost in a tide of acrimony.

Proposition 1:
There are circumstances under which my client is better protected against
commercial or accidental events, if he possesses source code to the
application and the underlying database management system.

I agree with that proposition.

Proposition 2:
There are circumstances under which my client is better protected against
commercial or accidental events, if I have coded my application in such a
way (by use of a database abstraction layer) that migrating my application
to a different database management system is made very easy.

I agree with that proposition.

Proposition 3:
There are circumstances under which my client is better protected against
commercial or accidental events, if he has a human readable backup of the
database of the type Quirk describes.

I agree with that proposition.

Note that neither Quirk nor I claim that these propositions always apply to
every situation, nor that there are not clear and obvious exceptions.

However, I must take issue with Noons, who states:

But, my dear cyber-friend: no vendor of anything considered
base-layer software like databases has EVER changed the product
so much that it broke all previous code! That would be called
"suicide" in market terms. It's never happened, it will never happen!
There is NO NEED to work around such an eventuality: it won't happen,
it's a wasted effort.

There are large companies in our industry who are famous for implementing
backward-incompatibility in new versions of their software. Further, most
support is time limited: once the software has reached a certain age, the
vendor demands that you upgrade (at your cost) if you want to continue to
receive support and bug fixes. Clearly, that makes good commercial sense and
nobody would dispute their right to drop suport for old products, but it
does lock customers into an "upgrade or else" cost cycle. 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.

The point here is that current commercial practice by many vendors forces
clients into expensive upgrades which have no direct commercial benefit to
the customer. Quirk's propositions present a scenario under which customers
have the freedom to choose what to upgrade and how much to spend, based on
their own business imperatives and not those of a third party on which they
depend.

After 25 years in the industry, I know of many organisations which are
getting heartily sick of spending vast sums of money in knee-jerk upgrades
(which usually involves staff retraining and other ancilliary expenses) at
the whim of a vendor. When I am able to offer my customers an alternative to
this revenue drain, I am happy to do so. It is not always possible or
appropriate, but when it is, the benefits are exactly as Quirk has laid out.

Your mileage may vary.

Kind regards,
Doug Hutcheson

 

[Jerry Gitomer]

Quirk wrote:

[snip to cut to the chase]

Personally, I think my software assurance comes from Oracle's size and
market share (and my support contract), and I don't need potentially
crippling abstractions to protect me against their failure at some
indeterminate and perhaps never-to-arrive point in the future.

And the choice is personal, so you are welcome to yours, however, you
can imagine that not all applications, especialy commercial ones, can
afford to tie themselves to one exclusive database, and many other
applications may not want to force there users into using one exclusive
database.

[snip to cut to the chase]

Commercial applications often must tie themselves to one exclusive
database. For example, the last inhouse database application I worked on
was a medium sized one -- 50 (wo)man years of developer time. Management
decided to use a three tier model, but then had us push all of the
functionality possible down to database access using Oracle's PL/SQL.

The decision was based on the need for performance and scalability in
dealing with several tables with over 10 million rows each in a web based
system expected to handle several thousand requests per hour.

Processing demands frequently dictate that commercial applications be
tightly coupled to a commercial vendor's proprietary tools and processing
languages. To do otherwise would produce a system that could not be
guaranteed to meet performance requirements.

I like MySQL (and I prefer PostgreSQL to MySQL), but when it comes to
creating an application that absolutely, positively must provide high
performance on a 24/7 basis I would opt to use Oracle or IBM's DB2 because
I know that either can provide me with whatever support I require (all it
takes is money), their products perform well, and their products are so
scalable that using either I can develop on a lap top running under
windows and move my code -- with no changes -- to a multi-mainframe
monster with as many disk drives as the customer can afford.

 

[Jerry Gitomer]

On Thu, 20 May 2004 00:00:48 +0000, Doug Hutcheson wrote:


Big snip here

There are large companies in our industry who are famous for
implementing backward-incompatibility in new versions of their software.
Further, most support is time limited: once the software has reached a
certain age, the vendor demands that you upgrade (at your cost) if you
want to continue to receive support and bug fixes. Clearly, that makes
good commercial sense and nobody would dispute their right to drop
suport for old products, but it does lock customers into an "upgrade or
else" cost cycle. 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.

The point here is that current commercial practice by many vendors
forces clients into expensive upgrades which have no direct commercial
benefit to the customer. Quirk's propositions present a scenario under
which customers have the freedom to choose what to upgrade and how much
to spend, based on their own business imperatives and not those of a
third party on which they depend.

After 25 years in the industry, I know of many organisations which are
getting heartily sick of spending vast sums of money in knee-jerk
upgrades (which usually involves staff retraining and other ancilliary
expenses) at the whim of a vendor. When I am able to offer my customers
an alternative to this revenue drain, I am happy to do so. It is not
always possible or appropriate, but when it is, the benefits are exactly
as Quirk has laid out.

Doug,

If you are dealing with the right vendor the cost of upgrades is included
in your support contract. When I was an active DBA working with Oracle
and Informix all I had to do was make a phone call and the manuals and
media for any currently supported version magically arrived -- at no
charge -- within a week. I would install the latest version on my test
system and see if the developers or quality control people ran into any
problems -- they never did. I would then install on the development boxes
and after a couple of weeks of complaint free (well, as complaint free as
developers ever are) work I would install on the production systems and
provide the operations staff with a set of scripts that made the new
version the active one and tested it to run after the backup was
completed. (Just in case I had them keep the back up in house instead of
sending it out for off-site storage the next morning -- but I never ever
needed that backup.)
Eureka, a painless and inexpensive upgrade.

To summarize there was no incremental cost for either software or manuals.
Since I was on salary there was no additional labor cost to install and
test a latter version.

Jerry

 

[Niall Litchfield]

Guys, Guys....
Calm down.
The propositions put forth by Quirk are becoming lost in a tide of acrimony.

Proposition 1:
There are circumstances under which my client is better protected against
commercial or accidental events, if he possesses source code to the
application and the underlying database management system.

I agree with that proposition.

It, and the ones that follow are somewhat lost in the fact that it is
largely meaningless.

Proposition 1a.
There are circumstances under which my client is better protected against
commercial or accidental events, if he possesses a contract with a
financially stable vendor of the application and/or underlying database
management system.

Is exactly as true as Proposition 1. Define the circumstances. then relate
them to the real business world.

Proposition 2:
There are circumstances under which my client is better protected against
commercial or accidental events, if I have coded my application in such a
way (by use of a database abstraction layer) that migrating my application
to a different database management system is made very easy.

I agree with that proposition.

Proposition 2a

There are circumstances under which my client is royally screwed if he has
an app that does not take advantage of the platform on which it is running,
even if this means being dependent upon that platform.

Proposition 3:
There are circumstances under which my client is better protected against
commercial or accidental events, if he has a human readable backup of the
database of the type Quirk describes.

I agree with that proposition.

Why do the words filing cabinet come to mind

Note that neither Quirk nor I claim that these propositions always apply to
every situation, nor that there are not clear and obvious exceptions.

Well I don't see anywhere that Quirk makes these assertions - though i do
see him claiming that open Source is a better model that closed source.

However, I must take issue with Noons, who states:



There are large companies in our industry who are famous for implementing
backward-incompatibility in new versions of their software. Further, most
support is time limited: once the software has reached a certain age, the
vendor demands that you upgrade (at your cost) if you want to continue to
receive support and bug fixes. Clearly, that makes good commercial sense and
nobody would dispute their right to drop suport for old products, but it
does lock customers into an "upgrade or else" cost cycle. 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.

Where can I get the security & performance fixes for linux kernel 1.5 - I
don't want to upgrade?

Your suggestion about backward incompatibility also seems to confuse
Microsoft Office with platform software. Even MS - to whom I assume you
refer - have platform software that is backwardly compatible for the last 5
years or so.

 

[Joel Garry]

[Oracle and Sybase groups removed]

[cdos put back in for those not using google to say that]
Those of us following the Oracle groups on google still see it in the thread.

jg

 

[Volker Hetzer]

[comp.databases.ms-sqlserver removed]

Wow, five days later Volker is still scratching his head about this, I
though this thread was dead long ago.

I've got some long test runs with not much to do in between, that's
why I spend a bit of time here.

Huh? If you have taken my suggestion, then why did respond to my
suggestions?

You implied that I didn't run the contract by our law department.

Did you imagine, that although I was not responding to
you, somehow It was you I was talking about? As usual, you make no
sence.

You did talk to me. Read up your article (e-mail address removed).

'Simply doesn't work' -- an unsubstantantiated out of hand dismissal,
which is, as anybody with clue knows, a fallacy.

Substantiation: When cygnus supported gcc, who else did?

'Try it sometime' -- Another attempt to portray yourself as having
greater experience, another fallacy.

So, what's your experience?

Well, what more can we expect from Volker, the human fallacy?

The specific proprietary bindings can be wrapped in a simple function.
Additional functions can be used to issolate proprietry features.

So, how do I isolate functional or bitmap indexes? How do
I isolate the queuing mechanisms of oracle?

The question was: Why are you bringing up changing the application as
if it was an argument _against_ my suggestions, since my suggestions
help protect your applications. Please try to follow.

"> > See my other posting. Compared to changing the application (replacing"
"> > it with another), changing the underlying database is easy."
If you are that forgetful maybe you shouldn't cut out that much.

Funny, that's what I said. Where?




No, closed source licence agreements are so devised.

If I buy oracle (or purify) or whatever, I buy a fixed price for the
product *once* and the maintenance annually. There is no
sucking dry part.

Maintenence contracts are perfectly fine. Ok.


You pay for labour, yes, why would this not be obvious?

I'm trying to make it obvious to you that I can pay for the labour perfectly
fine without having the right to the source code. It's what those
perfectly fine maintenance contracts are for.

I don't know what makes sence for your company, but it should be
obvious to you that my advice is not directed at your company
specificaly, and also, my advice is not to become database
specialists, but rather to not make your own application, especially
if it is a 'high end commercial application' as described in the post
I was responding to, exclusively dependend on a third party.

Ok, somehow you seem to think 4 (ok, at most 5) weeks migration
effort is an exclusive dependency justifying staying away from db2
or oracle. I guess that depends on the apps you are developing.

Access to the source code gives you the freedom to swith 'database
specialists' even if you never touch the code yourself.

See above.

It also means you never have to stop using the product simply because
the vendor wants to sell you a new one if the product continues to
meet your needs, since with source, you can recompile for for a new
cpu, a new os, or when new security updates are available for the
libraries it depends on.

And where are the security updates for the obsolete database?
Where are the customers that want to buy a piece of legacy code?

With source, you have the assurance that the product is yours for
keeps, just like your own code, without source, you have no such
assurance.

See above.

You still have the source code.

Yes, I can print it out and kill some trees with it. Somehow
you still think I will become a database developer or can convince
my boss to pay for the support of an obsolete application.

Yet the vendor gaurantees nothing.

He guarantees to put labour to my service requests.
Btw, what does mysql guarantee if you take out a service contract
with them?

The vendor only tries to maximize profits.

Yes, and where is the contradiction?

You do not need to, just like if you design a curcuit with a
proprietary conector or a standard one, the former is expensive and
only comes from one comany, the later is cheap and comes from many.
Unless you really need the former, you would always chose the later.
In neither case are you required to manufacture connectors.

Just checking... All the databases we are talking support sql, or at least
a reasonable subset of it right? So, by using sql I'm only tying those
parts to the particular db that are special and which I use, right?
So, the only "own investment" is tied to those features because I need them,
right?
This might sound unusual for you, but if you use a great library, and suddenly
it has a bug and there's no maintenance, the app is bust. Now, what are the cases
here:
- I'm poor. So, neither could I pay for the fix, nor for the company. My
product depends on someone richer to pick up the pieces. (the code
or the rights to the code)
- I'm rich. So, either could I agree to pay more maintenance and keep
the vendor alive, or pay a few percent less (by cutting out the management
level of the vendor) and hire the developers to go on.
- I'm a programming genius. then why did I use a library in the first case?

There are as many as the market will bear, since there is no
artificial thing, like closed source, keeping competition away.

Closed source is nothing artificial either, it's the only way to
go before you have payed the original developers.

Since the Market is growing rather fast, and big names like SAP are
promoting it, I see no reason to worry about a lack of support for
MySQL.

If I were using SAP and not worried about recovery beyond restoring
last night's backup I'd be using SAP/MySQL too, if I could send
my MySQL bug requests to SAP.

What? Who follows Red Hat?

The Linux distributors. As an example of a big open source project.
And that postgres windows company does the same, right (following
the main postgres company)?

Btw, spelled out: I *CAN'T* hire "many companies, large and small"
to support my open source product. For most, none exist, for some,
one exists, tying me down, for very few, some companies support
ports, some simply cash in.

Also, I've had my share of support by small companies. They have
no way to make all customers pay a flatrate, they *always* bill
by the hours, and they don't support new platforms if they differ
from the current Dell pc because that's all they can afford.
No, thanks, I'll stay with the biggies, and right now the only open source
biggie is RedHat for the OS and no one for databases. However,
if SAP buys MySQL AB that would make mySQL a real contender
in the database business.

What does this have to do with companies
providing development services? What are you blathering about?

The connection is that somehow the development has to be coordinated
because otherwise you won't have one project anymore but a bunch of
quickly diverging incompatible branches.
So, there are de facto owners. For Linux most commercial
software vendors make sure that their stuff works with redhat and the other
distributors scramble to make their distributions as compatible as
possible. Of course, each adds some bells and whistles, like a nice config
tool or checks whether all the packages work, but that's more or less it.

Different products have different cross platform stragies, the good
ones try and support the widest number of platforms, almost all
serious database software supports Linux now, including Oracle and
Sybase. But in anycase, I have no idea how this relates to anything we
are actualy discussing. Must be something funny in the drinking water
in your parts.

We are discussing vendor dependencies. And if you buy a commercial
linux product it typically says something like "RedHat Linux 7.2, 7.3, 8.0,
Enterprise AS 2.1, 3.0", not "guaranteed to run on any kernel you manage
to drag from the internet and compile on the PDA of your choice".

Anyone who wants to be, as many as the market will bear, each
competeting for customers and compentent labour with each other to the
benifit of the consumer, simple economics.

In other words, no one.

Oracle has you trapped because no one else can compete with them,
since their source is closed. BUT EVEN STILL, I am not recomending you
never use Oracle, I am only recomending that abstraction is a good
idea, particularliy when you do not have source.



As I said, your question was a fallacy, since it was in responce to
the statement that many companies, including IBM, support open source
products, the statement did not say that IBM, specificaly, supports
MySQL, specificaly.

What open source projects does IBM support, i.e. offer maintenance
for?

Btw, many companies support closed source products too, typically
their own. Some offer more, they are called consultants. So what?
If I go out now into your nice shining world, what do I see?
- Mysql: Mysql AB, with SAP sponsoring development.
- Postgres: one sham, one windows only supporter and the owner
So, regardles of what you wish for, If I depend on an open source
database for its features or whatever I'm still tied to one supporter.

Yet, if you wanted to, you could hire IBM to
support your MySQL implementation, if you had enough money, they would
be happy to take it.

If I had that kind of money I could have them implement my feature in DB2 too,
right?

They do not promote themselves as such, and would
frankly be surprised to get such a contract, knowing that there are
cheaper alternatives and that MySQL users are not currently the
typical IBM consulting clients, however, with SAP behind MySQL AB,
this could soon change.

At which point, your support requests still land at the same company regardless
of whether the bug form has mysql or sap on it.

If the code is a working part of your application, it is not obsolete,
however a closed source vendor can obsolete it

So can an open source vendor. Remember, I'm not beating up
a dead horse.

on purpose to force you
to buy a new licence.

He can't. The only thing he can do is stop bothering about my bug
requests (mysql ab can do that too) and tell the world that this
product is obsolete (mysql ab can do that too).

And you need no expertise in it, since if your
product is popular, like say MySQL, the marker will attract lots of
competition for your business.

What marker? And my product isn't mysql it uses it. (or,
oracle, in that case)

If it's a working part of a production system, you do not need to be,

See above, that paragraph about me being either rich and poor and how
the right to the source code is irrelevant.

If it is a viable market, there will be programmers for it.

If it's a viable marked the original support wouldn't have gone bust.

It may make migration uneccessary by allowing new entreprenuers to
support it.

Oh yes! And this doesn't work at all with closed source, see informix.

Competition among them will even make maintenance cheaper,

and, of course abstraction makes migration, when neccessary, also
cheaper.

And the product more expensive and slow in the first place.

All this in perfect line with my adivice,

I really love the way you congratulate yourself more and more often.

as stated in my original
posting, and as still unrefuted in anyway by you copious blather.

Oh, I did refute it, you just ignored it. And asked me to help you forget
by quoting shorter, right?

First, if the system is widely used the code would not be abandoned,

Ditto for a commercial product.

second, a closed source product is not less likely to be abandoned
that an open source one,

It is. Because someone invested real money in it.

third if it is abandoned then you are in
better shape if you do have the code.

Sigh... We've been through this. In what way am I in better shape then?
It doesn't make sense to wait for your mysterious entrepeneurs (who, in
any case could also bid for the property of the bust company) and
then we can reduce the problem to how do I as the sole left paying
guy get some support from someone other than the original supporter.
Which gives me the possibilities outlined above in the rich/poor stuff.

You must also stop using the software then, and bear the costs related
to that.

Ditto for open source. Remember, I leave when my bugs won't
get fixed, regardless of open/closed source.

I never said anything *always* makes sence, all projects have their
own requirements, I have only given some general advice, good advice.

You should become a consultant.

No, I tell you that source gives you freedom to chose, but sadely,

To choose what exactly? Any supporter out of one?

First of all, you do not have any such right,

I do. Witness all the 8.* and 7.* installations still around. Desupported
ages ago.

secondly, without
source, how you will compile it for your new CPU, or new OS, or to
link a security-updated library?

Even with the source, if I were to compile mysql to, let's pick
a platform at random, my new cellphone, I'd have to do a bit
more than ./configure&&make install, right? In fact, I'd have to go
though all the code, look for any system calls, get to know my
target system and how the system calls differ subtly, and
still I'd have a much lesser chance of making it work than if the
original maintainers did it.

Funny, that's exactly what I said, many times in this thread.

Where? (I mean, before I pushed your nose in it?)

No, all your showing is your inability to follow a simple arguments.


The 'case for code rights' does not disapear,

So, what are code rights good for if not for not having to change
the database?

but by abstarction,
becomes less important, since abstarction is another layer of
protection.

So my code gets clumsy and slow for no reason at all.

This has been clear from my very first post in this
thread.

To anyone else apart from you too?

Keeping your archices in self-contained, self-describing,
human-readable format was my third recomendation.

Oh yes, we've been through that too. Send me an email
once you've done this so I can redirect our ISO9000 auditors
to your webpage.

No one is recomending this, that is only your own red herring.

You are recommending this. Or, rather it follows from your recommendation.
An open source db stops getting maintained and every appvendor start to
do his own maintenance, resulting in a bunch of uncoordinated fixes.
And this is so, because the business case for a coordinated patch
and release management has disappeared.

The
customer prerers abstacation when it means that they can use there own
database,

The customer prefers to use his own database. How the vendor deals
with it is not his problem. *Our* problem right now *is* such an abstracted
product, which doesn't run properly on oracle because those guys never
tested it with an UTF8 database, much less ISO dates. From hindsight
we'd even accepted sqlserver if they had done it properly.
As for other abstractions, we've seen plenty of products available for
several platforms and the first question is "what is your main development
platform?" and that's typically what we'll use too because we are really
sick of Mainwin, mks toolkits where every path has a different \ or /
convention or Java apps which need three tries each time I try to
start them. (Before you ask: that's abstracting from the OS, ok?)

if they only use the database for your application, then
they see the database as a part of your application, and only want it
to work.

Yes. Then *you* will optimize your costs, looking for a partner who
can support your database. At which point we are at the maintenance
question. Again.

I am not trying to change 'the thread' -- I posted my recomendations,

See the subject line.

As I said, there are bad applications, both abstracted and
unabstracted ones, your argument, is, as usual, a fallacy.

In what way?

And, if your forced your customer into Larry's arms, they will blame
you, not Larry.

Yes, and if oracle isn't willing to fix it I can give oracle a lot more trouble
than mysql because their contracts are more expensive.
You should have read the next paragraph before responding.

I don't plan on being 'the only surviving supporter', yet another of

So, what was this "right to the source code" stuff about?

your fallacies, as the producs that I use are popular and their
popularity is growing,

And that somwhow doesn't work for commercial databases,
right?

I also abstract my database access, so that if
this changes, I can change with the dominant trends.

And somehow this relates to open source.

(I wonder if you even know what a fallacy is, you use so so many of
them)

Whatever your secret work experience may be your public english
experience isn't good enough to teach me that language.

I support my application and all the dependencies that I have forced
on the client by way of it. If my application fails because of a
dependency I have chosen for it, the customer will blame me.

Remember, it was limited to the situatuion where the customers only
dealt with Larry because of me.

Actually no. The point B was (and it's still in here for you to read)
that the customer trusts Larry more than me.
But you are right if we open a case D), "I force my customers
into oracle because I get a percentage or something", my customers
would be right to complain.

For the millionth time, please try to
follow.

Cut out this stuff. It makes you sound ridiculous.

What on earth are you talking about?

About how you solve that problem for your customers.

I do not need to run my own linux
distribution. You are a nutcase.

Then you depend on some linux vendor.
For you, simplified: You are deperately seeking a case where open source
beats closed source. If you can take someone elses distribution you are
dependent on him and need your customer to run that distribution. (Correct
me if all your programs consist of perl scripts and don't load any shared libraries.)
If no one else exists (any more) do your own support, directly or by hiring
others, yet still you need the customers run your OS.

I made a series of suggestions, including open source and abstraction,
you responded to my suggestions, therefore the topic is my suggestions
and your objections to them.

Abstraction is irrelevant to open source because the big thing is the right
to the source code, correct? And due to the small migration work
while moving from one sql database to another it's irrelevant to closed source
too. It's impossible if you depend on special features of your database. In that
case your customer knows it and is with you.

Well, you might have trouble understanding it, but I think I've made
it clear that both source and abstraction have their benefits.

See above.

Yeah, a 'diversion' I cleverly included in my very first post in this
thread.

What's the difference? You didn't start the thread.

What kind of idiot are you?

How old are you?

 

[Quirk]

Guys, Guys....
Calm down.

The propositions put forth by Quirk are becoming lost in a tide of acrimony.

Thanks Doug, it's nice to know that there are one or two actual
developers in these groups, but anyway, I think it's pointless to go
on discussing these things in this thread, it's pretty clear to me we
are dealing with zealots and those looking for genuine answers have
likely stopped reading long ago, I'll avoid argueing with them and
instead stick to giving good suggestions, the readers can make up
their own minds, as they should in any case.

You summary of the issues should be enough for those with real
questions, I'll add a few comments and leave it at that.

Proposition 2:
There are circumstances under which my client is better protected against
commercial or accidental events, if I have coded my application in such a
way (by use of a database abstraction layer) that migrating my application
to a different database management system is made very easy.

I agree with that proposition.

And also note that simply issolating database functions in your code
is a easy and light way to abstract data access, just to make this
clear for those that keep insisting that database access abstraction
means automaticaly including a third tier:

For instance, in pseudocode:

function myapp_query(query)
if not connected
prop_connect
result = prop_query(query)
for each result
data(ii++) = prop_fetch(result)
if not set cleanup
set cleanup connection callback
prop_disconnect
return data

That is a very simple wrapper, an abstraction object like PEAR:B is
a lot more complex, but that works for simple issolation assuming
standard SQL, we issolate the use of the proprietry bindings
('prop_*') to one function, and convert our result set into a standard
array, manage openning our db connection and register a callback to
close, all in one place.

Not using SQL as the argument, but rather a more general request
describer is a further abstraction that makes your application
cleaner, but that is another subject, which if there interest, I
could explain in more detail.

Then you have your application:

function myintreface()
global data
data = myapp_query(<query>)

function myview()
global data
for each data
display data (ii++)

function mydetail(key)
global data
display data(key)

And so on...

The functions themselves only use the wrapper, 'myapp_query', and a
native array, 'data'. So, if your application has hundreds of
functions that use the wrapper function and/or the native array, and
only a few functions where the proprietary bindings are issolated, you
can migrate much easier, or even take advantage of new features in
your existing platform more quickly, because you have issolated the
data access code.

I even use such a data access wrapper when I do use a data abstraction
object, it keeps my code cleaner, and I can even change the
abstraction object if I like, even, when needed, (*gasp*) intoduce
another tier.

Proposition 3:
There are circumstances under which my client is better protected against
commercial or accidental events, if he has a human readable backup of the
database of the type Quirk describes.

I agree with that proposition.

And, of course, a self contained, self describing, human readable file
is also usefull when the data has a long life span, and may in fact
out live the application and the platform, or when the data needs to
be shared with other organisations and their applications.

Note that neither Quirk nor I claim that these propositions always apply to
every situation, nor that there are not clear and obvious exceptions.

That's right, these are suggestions, each application has its own
requirements, this is why at first it was confusing to me why the
likes of Volker scream and shout that these suggestions are bad
because it deosn't suite their application (or so they think), but
then it became pretty obvious since Volkers most recent drivel, where
he argues with the subject title of the thread instead of my arguments
and claims that my arguments are an attempt at diversion, even though
I have maintained them form my first post. The likes of Volker are
just rabid scum, and talking to them, and the other zeolots just
distracts from the topic and likely drives away any readers who are
generaly interested in the topic being discussed.

Regards,
Dmytri Kleiner
my initials at trick dot ca will reach me
(I don't live in Canada anymore though)

 

[Quirk]

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.

Proposition 1a.
There are circumstances under which my client is better protected against
commercial or accidental events, if he possesses a contract with a
financially stable vendor of the application and/or underlying database
management system.

Is exactly as true as Proposition 1. Define the circumstances. then relate
them to the real business world.

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.

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.

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.

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.

If you can guarantee that your legel relationship with your vendor
will never break down, for financial or any other reason, then yes,
you can get away with not abstracting, and not having source code.
This, however, is not the real business world. Only a tiny, wealthy,
fraction of it.

If you have source code, as you do with free software, you can always
find a way forward, because you are not dependent on a relationship
with any single entity.

Proposition 2a

There are circumstances under which my client is royally screwed if he has
an app that does not take advantage of the platform on which it is running,
even if this means being dependent upon that platform.

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*

Why do the words filing cabinet come to mind

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

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.

Well I don't see anywhere that Quirk makes these assertions - though i do
see him claiming that open Source is a better model that closed source.

Open source is a better model than closed source, but that is not the
subject here, a particular piece of open source software,m such as a
database platform, MAY OR MAY NOT be better than a particular piece of
closed source software. I am not disputing that things like Oracle are
good software, only trying to help those making such a choice
understand there are other things to consider than simply comparing
Oracle against MySQL.

Where can I get the security & performance fixes for linux kernel 1.5 - I
don't want to upgrade?

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.

 

[Noons]

Thanks Doug, it's nice to know that there are one or two actual
developers in these groups, but anyway, I think it's pointless to go
on discussing these things in this thread, it's pretty clear to me we
are dealing with zealots and those looking for genuine answers have
likely stopped reading long ago, I'll avoid argueing with them and
instead stick to giving good suggestions, the readers can make up
their own minds, as they should in any case.

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.

However, thanks for giving me the opportunity of stating this in a less
civilized language (remember: YOU started the language, not I): none of
your points is by definition a "world truth". 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.

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

Goodbye and keep developing for a non-existent market. It has a
brilliant future. And yes, I DO have a future and nothing you can
possibly do will stop it.