What so special about PostgreSQL and other RDBMS?

[Sarah Tanembaum]

Beside its an opensource and supported by community, what's the fundamental
differences between PostgreSQL and those high-price commercial database (and
some are bloated such as Oracle) from software giant such as Microsoft SQL
Server, Oracle, and Sybase?

Is PostgreSQL reliable enough to be used for high-end commercial
application? Thanks

[Daniel Morgan]

Howard J. Rogers wrote:

Daniel Morgan wrote:

Howard J. Rogers wrote:

Daniel Morgan wrote:

[snip]

I hardly "rubbished" an operating system. I stated that it had a
weakness. Would you claim otherwise? If you can find an operating
system
that doesn't contain a weakness please inform us all.


Quote:
If it isn't secure who cares how fast it is?
And you would say that this statement is untrue?

If it isn't stable who cares how many features it has?

And you would say that this statement is untrue?

If it won't scale to the number of users who gives a rip about extras?

And you would say that this statement is untrue?

And, to be quite blunt, if the only operating system it will run on
is Windows that becomes a limitation affecting all of the above.

And you would say that this statement is untrue?

In 5 lines, you've said Windows isn't secure, stable or scalable. I
call that "rubbishing ".

Then by all means establish under what conditions you think it
appropriate to build line-of-business systems on a platform that is
not secure, not stable, and not scalable?

That's the whole point, isn't it? Windows *is* secure, stable and
scalable *enough* for a lot of people.

I don't recall ever disagreeing with what you just said. If you think
I did it was a misunderstandin g. Keep in mind ... I use Windows daily.
So do many of my smaller customers. I can't imagine what leap took you
to the conclusions you did.
It's the "it's not, period" school of thought I find so immensely
unprofessional.
I didn't enroll in that school and am totally perplexed by how you
came to the erroneous conclusion I did.
And that's a far more intelligent approach, don't you think, than simply
to dismiss.
I don't recall ever doing that and can't imagine how you came to the
conclusion I did.
I've told you before, but there's no adrenaline pumping here.
Then please explain the 'effing' and other angst filled comments? But
not here ... these people have probably had their fill of this thread
already. You have my email address ... lets take it off-line if it is
even worthy of that.
All I ask
is that you back off a little and acknowledge the facts of the world as
they actually are, where hundreds of thousands of databases run on SQL
Server, on Windows (obviously), and their owners and users don't find
that an appalling state of affairs. Or, in your words, a "limitation ".
A acknowledge to you, and to the entire universe that there is a place
where Windows and SQL Server are appropriate solutions to business
problems. Ok. Happy? I don't recall ever saying anything else. Taking
something into consideration does not mean automatic rejection.
I'm not defending anything, Daniel. I have no interest in defending
either Windows or SQL Server, because whether I am for them or against
them, they'll still be there tomorrow (which has been largely my point
throughout).
Then why didn't you just say it? And we could have ended this thread
days ago.
What I am doing is criticising what I consider to be your
unprofessionali sm or arrogance, call it what you will, in "rubbishing " a
platform as you have done in this thread.
Taking a weakness into consideration is not rubbishing. I can't recall
driving my car to the store without taking into consideration its
weaknesses.

I am hoping for a glimpse of humility or reason along the lines of 'Windows/SQL Server is a platform
which many businesses will find secure, stable and scalable enough for
their needs'.
And there is a difference between your use of "enough" and my statement
that these things need to be considered? I thought we spoke the same
language: Apparently not.
It might be asking a bit, but I'd also like to see an
acknowledgement that 'and DBAs who don't recognise it as such are not
exhibiting the rational professionalism which should be their hallmark'.

HJR

All DBAs that don't agree with you on each and every point you have
raised, raise, or will raise at some indeterminate point in the future
are flaming morons. Does that make you feel better?

Last time I checked ... everything ever posted to the usenet was
written as a personal opinion by its author and interpreted as personal
opinion by its readers. When did that change?

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.wash ington.edu
(replace 'x' with a 'u' to reply)

[Howard J. Rogers]

Daniel Morgan wrote:

I don't recall ever disagreeing with what you just said.
I quoted you the 5 lines where you did that. And also the "not one of my
customers would find that acceptable" statement.

As I've written to you elsewhere, "Not one would find it acceptable"
could have been written as "Yes, many will find it acceptable, though
the particular large corporations I am familiar with wouldn't".

Emphasis, nuance, subtelty and humility.
If you think
I did it was a misunderstandin g. Keep in mind ... I use Windows daily.
So do many of my smaller customers. I can't imagine what leap took you
to the conclusions you did.

It's the "it's not, period" school of thought I find so immensely
unprofessional.

I didn't enroll in that school and am totally perplexed by how you
came to the erroneous conclusion I did.

5 lines quoted earlier, and your tone.

And that's a far more intelligent approach, don't you think, than
simply to dismiss.

I don't recall ever doing that and can't imagine how you came to the
conclusion I did.

Repeating something ad nauseam is not a particularly meaningful
response, I would suggest.

I've told you before, but there's no adrenaline pumping here.

Then please explain the 'effing' and other angst filled comments?

The explanation comes from the context. If you read it in context, the
'effing' performed precisely the function it was supposed to: indicate a
dismissive reponse to your statement that a proposition I'd made
wouldn't apply to your customers, when the whole point I was getting you
to try and accept that what applies to your customers, and what you've
experienced in your career, may not be typical or representative.

In plain words, whether fact X applies to your customers or not was
irrelevant to the matter at hand. Where I come from, when something is
irrelevant, one tends to say 'So f***ing what?'. It is therefore a
phrase which is not angst-filled or adrenaline-fuelled.

[snip]

All I ask is that you back off a little and acknowledge the facts of
the world as they actually are, where hundreds of thousands of
databases run on SQL Server, on Windows (obviously), and their owners
and users don't find that an appalling state of affairs. Or, in your
words, a "limitation ".

A acknowledge to you, and to the entire universe that there is a place
where Windows and SQL Server are appropriate solutions to business
problems. Ok. Happy? I don't recall ever saying anything else.
Taking
something into consideration does not mean automatic rejection.

It shouldn't be like extracting blood from a stone, Daniel. That it has
been does not make me happy in the least. Although it has to be said as
well that my happiness has got nothing to do with the matter.

I'm not defending anything, Daniel. I have no interest in defending
either Windows or SQL Server, because whether I am for them or against
them, they'll still be there tomorrow (which has been largely my point
throughout).

Then why didn't you just say it? And we could have ended this thread
days ago.

I did, repeatedly. Read the thread again. The issue has always been
trying to get you to look beyond *your* experience and *your* customers
as though they were somehow definitive, and to acknowledge other
experiences as perfectly valid. Not grudgingly valid. But 100% valid for
their needs and circumstances.

Now you say that you never implied they were invalid. I would suggest
that your phrase and tone has done precisely that. If that's a matter of
interpretation and disagreement, I have no problem with that. So long as
you realise that your tone, and nuance, have indeed been misinterpreted
(and not just by me).

And whilst it is true that we can all be misinterpreted at times, some
posters here seem more prone to it than others.

What I am doing is criticising what I consider to be your
unprofessionali sm or arrogance, call it what you will, in "rubbishing "
a platform as you have done in this thread.

Taking a weakness into consideration is not rubbishing. I can't recall
driving my car to the store without taking into consideration its
weaknesses.

Tone and nuance, Daniel.
I am hoping for a glimpse of

humility or reason along the lines of 'Windows/SQL Server is a
platform which many businesses will find secure, stable and scalable
enough for their needs'.

And there is a difference between your use of "enough" and my statement
that these things need to be considered? I thought we spoke the same
language: Apparently not.

Your language, in this thread, has been littered with words like
"weakness" and "limitation " in a context where you have grandly
announced that "not one of my customers would find it acceptable".

One doesn't need to have a Masters in English to be able to draw an
obvious inference from all of that lot.

And again, if that inference should not have been drawn, then so be it.
But one questions the wisdom of providing the material that lets it be
so drawn in the first place.

[snip]

All DBAs that don't agree with you on each and every point you have
raised, raise, or will raise at some indeterminate point in the future
are flaming morons. Does that make you feel better?
No, Daniel, because now you're just being silly.

I'm not asking you to agree with me. I'm asking you not to rubbish the
many thousands of Windows/SQL Server users who don't agree with you.
Last time I checked ... everything ever posted to the usenet was
written as a personal opinion by its author and interpreted as personal
opinion by its readers. When did that change?

As I say, you're just getting silly now.

We *know* your comments about Windows and SQL Server were just personal
opinion. We know that, because tens of thousands of important databases
run very successfully on that platform and don't find it a 'limitation'
or a 'weakness'.

But I give up. You clearly don't want this to continue, for perfectly
understandable reasons; and no-one else seems bothered by your comments
anyway. So that's fine.

HJR

[Galen Boyer]

On Mon, 17 May 2004, hj*@dizwell.com wrote:

no-one else seems bothered by your comments anyway.

I have been reading this thread with alot of interest and my
quess is that I'm not even close to the only one who feels that
way. I have argued with Daniel more than once over exactly what
you are arguing with him about. I completely stayed out of this
one because I was interested in seeing whether someone who argues
with your eloquence and preciseness would be able to get Daniel
to actually understand/admit what his usenet persona actually
comes across as, but even you have been unsuccessful.

--
Galen Boyer

[Noons]

Daniel Morgan wrote:

You really think the legal cost of acquiring a product would stop a
malicious hacker?

If they can't get their hands on the hardware and operating system.
Yes.

How many OS/390 viruses have there been?

and God knows how open the darn thing is...

--
Cheers
Nuno Souto
wi*******@yahoo .com.au.nospam

[Volker Hetzer]

"Quirk" <qu***@syntac.n et> schrieb im Newsbeitrag news:4e******** *************** **@posting.goog le.com...

"Volker Hetzer" <vo***********@ ieee.org> wrote in message news:<c7******* ***@nntp.fujits u-siemens.com>...

What cold comfort that is. I would prefer the right to make my
aplication work without their good graces.

Before you consider suing them I suggest you reiview your contact with
an actual lawyer. So you can understand exactly how painted into a
corner you really are.

Look, we've got about 50 people here dealing with
exactly those questions, telling us what contracts to enter and what not.
When we buy support, we *know* what we are in for and when and
what to sue them for and how to deal with them before we sue them.
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.
at least, the right to cancel the
> contract which hurts them way more

How can you cancel the contract when your entire application is
dependanton there product? Can you afford to throw away your
application too?

See my other posting. Compared to changing the application (replacing
it with another), changing the underlying database is easy.
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.

> See my other postings and the reply about division of labour. You might
> also read up on Maos Great Leap Forward and north coreas policy of doing
> everything themselves.

You're not seriously trying to draw me into to a discusion on
communist history are you? If so, please go ahead, it may be
intersting. I've been reading the Fabian writing of George Bernard
Shaw recently myself.

Right. Mao wanted every village to be self-reliant and do everything on
their own. I think the best published example was that more or less
every village had its own steel factory, resulting in a very low efficiency
and crap steel. If you read about north corea you will sooner or later
stumble on something similar, called "Juche". A fierce desire to be
independent, an inability to recognize you can't be a specialist of
everything and, consequently, a desaster.

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.

> > I'm not sure what this example is supposed to illustrate. The vendor
> > failed to fix the bug originaly and ony did so under dures,

> The point was that contracts work.

It was quite a poorly demonstrated point, as they nearly did and could
well have lost their own customer under the arrangement.

Not "nearly", the legal opinion was correct and therefore the only ones
to worry were the sued ones.

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.
> which only
> > shows how vulnerable you where to begin with, Why was he vulnerable if he had a contract that required the vendor to > > > > work?
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?
As the old joke goes: "if this fire alarm fails, and your house burns
down, we will refund the entire purchase price (not including the
battaries)."

OTOH, "if you install this fire alarm, you will pay less insurance on
the house".
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 you had the right to
> > say 'OK, were going to fire you and give someone else the contract'
> > they would have fixed your bug pronto with no back talk.

No, they wouldn't, because first they would have to understand the code.
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.
Maybe, but in case of open source software they'd say 'Good luck
> working into our source code, see you in two years'.

Were do you get this idea? You can contract many companies, large and
small, to support your open source product, the difference being that
you can hire another when when they fail, because you have a right to
the source code, where as you have no recource when the provider has
all the rights.

Like, suse and redhat, each doing their own distributions?
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.

Could you provide a link where IBM actually provides support
for mysql? The only thing I have found is them bragging that MySQL AB
(fully) supports the AIX port, not that IBM supports MySQL.
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/ind...t/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"
Yes, developing applications costs money, it is this investment I am
advising people to protect by not getting locked into third party
dependencies.

I do get locked into a third party dependency, even if I can change
the third party.
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.

I agree, on the plus side, I can change support without
changing code, so who actually owns the code and merges the
fixes from the other guy, provided they don't want to keep them themselves
because they want to keep the customers?
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.
> or negotiate access to source for the vendors
> > product, the only difference being that you then have leverage.

> The access to the source means nothing, see above.

It means everthing.

Why? I can't change it.

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.
It means the difference being being the master of
your applications and contracts or being a slave to a third party
vendor.

He's my slave because I pay him.
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.
Maybe not 'out of the hat' but with less expense and retraining that
having to reprogram the entire application which was programmed with
proprietary bindings everwhere instead of properly abstracted code.

Abstraction can make the job easier, you are right here, but then
changing a database is not that hard too, as long as both are relational
ones.
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 "abstractio n" 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.
Including people who have been trained on it.
> In what way is a change from oracle to db2 easier than a change from
> postgresql to mysql?

Well, for one, you would never have to change away from the open
source products because of a dispute with the developer.

Yes, I would. Because I'm not going to maintain my own database
distribution.
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.
But in
anycase, my argument is not, and never was, oracle and db2 versus
postgresql or mysql. But rather for abstraction when you do not have
source code, or sometimes then too.

If I have abstraction it's even less necessary to mess around with
the db because it's easier to change the db.
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?
I certainly would
not expect my clients or users to be satisfied when I told them, I'm
sorry the application I provided for you doesn't work, but you will
have to discuss this with Larry Ellison. Nor would I be satisfied
giving such an excuse.

It's different for databases.
A) the customer quite often already has a database and expertise
maintaining it. He has an interest not to have another.

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

B) the customer may trust Larry ellison, or IBM more than me.
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.

C) the customer may want a database that can do more than I could
implement or maintain, like incremental backups, logical/physical
standby databases or security.
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.

Another case where it's different would, for instance be the OS.
How much linux maintenance do you think you can provide,
compared to redhat or suse? Is this really your corebusiness
or area of expertise?
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]

"Gawnsoft" <xl****@users.s ourceforge.remo ve.this.antispa m.net> schrieb im Newsbeitrag
news:gm******** *************** *********@4ax.c om...

By "tested the contarct" what you mean is you agreed to pay them
completely on their terms and where satisified with the results they
chose to give you.So, in what way is it different from let's say, buying a cucumber?

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]

"Quirk" <qu***@syntac.n et> schrieb im Newsbeitrag news:4e******** *************** **@posting.goog le.com...

"Volker Hetzer" <vo***********@ ieee.org> wrote in message news:<c7******* ***@nntp.fujits u-siemens.com>...

And what was your reply?

I asked first.
Is this grade school?
Realy, care to quote the part of the Contract that Gaurantees you any
rights?

http://oracle.com/support/index.html?policies.html

I asked you to QUOTE the part of the Contract that Guarantees you any
rights, not post a link to a description of support options and what
they cost.

That IS the licence agreement. 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.
Have you tested alternatives?

The other example was buyig gcc support from cygnus.
One bug, never got resolved in one year, consequently
we cancelled support.
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.
Are so so stupid that you actually expect a serious answer that was
obviously a
hostile attempt to insult by way of a rhetorical question?

Ok, so for you explicitly: That was not a rhetorical question. Your response
indicated youy didn't read my posting, or at least not the relevant part, so > I wanted to check whether it was worth posting 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.

> > Not if your application and the permenancy of your data is important." 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.

I start to repeat myself here.

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.

The right to the source code does not mean
anything useful, see the part you quoted below.
Yes it does, it's too bad you don't understand it.

If I have the source code, I know I can relly on a product for ever,
and never talk to the original developer again if I so chose. Withouth
source, the developer holds all the cards.

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

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?

Unsubstantiated bunk, if you have the source code, it is not magic to
fix it, or extend it, just normal progamming.

Right. So, if I do CAD programming, why should I learn database programming
only to support a dead database? It's much easier to migrate to another one.
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.

Besides, have you considered that quite a few open source projects get abandoned
because they have become unmaintainable?
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.

Anyone remembers hurd? Groff?
Yeah, what about them?

They are dead.

What was the last gmake improvement? And if the authors throw up their hands,
what can I do? Ask my boss to form a department for the beating of dead
horses?
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.
Simple calling something
an illusion does not explain why you condsider it impossible to
actually change a program. Perhaps you should consider a different
line of work.

Oh, it's pretty easy to change a program. Working through millions
of lines of code and repairing it with less time or money than it would
cost to migrate to another database is the trick.

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.

Convincing the customer to
install *my* database version is another, particularly if three or four
developers do this.
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?
Same question: Did you read what I wrote?

A better question: What kind of an idiot are you that, in the face of
good sense, the best you can do is attemp insulting, evasive
rehetoric?

It's not a better question. You keep bringing up that stupid
source code argument totally ignoring the fact that it simply doesn't
work, at least not for the money a normal support contract costs.
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.

And if support doesn't work, I still won't support it on my own.
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.
As I said, my comments where ment *FOR DEVELOPERS* that is those who
are developing *NEW* appliciations, and my advice is simple enough,
despite your contortions: If your application is important to you, do
not engineer a dependency on code you do not have access to.'

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

So, if windows or MacOs is among them I guess you will be dependent
on some libraries and kernel properties that you don't have access to,
right? 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.
More unsubstantiated bunk, first of all, in many cases you can hire
the original developers,

Yeah, exactly. A man year here costs about USD200000,-. A support
contract with oracle costs me about a tenth of that.
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.

And even if I buy some incident based support contract, there is still
no difference from an incident based support contract with oracle.
Yes there is, since you value the original developers so highly, we'll
try this example.

The best original developer of Oracle, the one with the greatest
knowledge of the system and code, quits Oracle and goes to work for
Databases-R-Us, since you have no source, you must continue to deal
with Oracle, the copyright holder, and can not hire Databases-R-Us,
who employ the developer.

You are mixing something up here. Oracle doesn't depend on
a single freak but on a well maintained turnover process.
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.
As long as that guy exists and I can sue him into doing his job I don't
need the source code (he needs) and otherwise I have no one to
replace him.

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.

But thanks for acknowleding that reliable support costs money. If stating the obvious is somehow of help to you, you're welcome.

Whatever.
regardless of your right to the source code,
secondly, by hiring the "Copyright Holders" you *ARE NOT NECESSARLIY
HIRING THE DEVELEORS*, who may not even be with the company anymore,
in fact you are often hiring some peon who they scooped of the
consulting market 5 minutes before sending him to your office as an
certified solutions prodiver or whatever idiotic buzzword whey have
for their unskilled labour.

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

Besides, remember, the company has an interest in providing
support because they live off it.

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?
And finaly, it is a falalcy to say that someone will do a worse job
simply because they are not the original developer.

So, if I pick some average application programmer off the street,

how long do you think it takes before he can start smoothing
out bugs in the postgres optimizer?

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.

But it stops short of guaranting that your apllication will actualy
work,

Of course they don't offer that. But they offer to put effort
in it.

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.

And they are dependent from me for my money.
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.
or that your existing version of the software will be supported.

They provide upgrades and desupport dates. Ok, they do
what I pay for.
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.

Just look at informix to see how
it goes when a db disappears from the market:
They had a big market share, market share dwindled, they got weak
and sold themselves to ibm because that's better than going bancrupt.
Now IBM handles the migration to db2 and supports me as application
developer in porting my app to db2. This is much better than handing
me the source code and telling me that from now on I have to develop
all the new features and fix bugs on my own or simply buy a new db
and do the migration on my own.

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.

I have no idea why you are insisting on jumping up and down like this
is crazy talk, the only plausible theory is that you get some kind of
thrill out of embarassing yourself.

Where do I jump up and down?

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.

This is just stupid, elegnt coding is hardly as unatainable an ideal
as you seem to be conviced, in fact in this specific case it's a
simply matter of using a standard wrapper function throughtout your
aplication to access your data rather than using proprietary bindings
throughout your application, if your application is sufficently
complicated, perhaps a data abstaction object might be usefull for
this function, perhaps not, if you use any non standard features of
your database server, then write some additional functions as wrappers
for these. It is anything but rocket science.

So you have defined "elegant" as "abstractio n" and expect the rest
of the programmers to agree that that's it?
Thanks for solving that problem for the rest of the world.

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

What about the human and financial load? As in the load on the DBA,
inhouse developers, consulting budgets and application support staff?

The load on the DBA depends on the problems the application makes.
That typical increases if the application ignores load reducing features for > the sake of being generic

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.

They could have done half the app in PL/SQL and saved 90%
of the network and client load.

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.

Also, if the database is not the standard one (because you have
fixed/improved it) I have, at the worst, maintain two independent
installations,
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.

We are talking about open source versus commercial databases.

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.

I picked
those two as examples because I have worked with both of them.
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.

So far no one has complained.
No one you know is not no one.
because Database security can only depend on it, not being able to
actualy protect devices, which is the burden on the OS and networking
environment.

The os protects devices, not the network. Or, daring to think the
unthinkable,

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.

do you mean that you consider it ok to have database data on nfs mounts?
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.
What does reading text files have to do with Chip design?

Because some tool will have to parse the text and create the chip out of it.
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.

This tool typically costs in the range of USD100000-200000 for a synopsys
ASIC compiler. You need the same tool because any other tool creates
totally different designs, ignores the original constraints and rules and
uses a different library which may even force a complete redisign.
Compared to that, a database migration is truly a breeze.

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.
Which ones? That abstracting access to suspect dependencies is a good
idea?

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.
That database security is secondary to network security?

Yes.
It is, if you ask a security expert you will find they agree with me.
That
one should keep archives in a format that is likely to be readable
forever?

Yes.

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.

whereas you are the only one who thinks my arguments are rubbish.

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.

that the very concept of good programming is an illussion,

No, it's just that so far no one has found out what it is, because
despite all the attempts software still is not substantially more stable
than software written 30 years ago.

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.

And if you are worrying about expiring licences, for many products
(purify and our oracle installation spring to mind) you get permanent
licences and pay yearly for support, so I can still use the app when the
vendor goes bust.

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.
not that anything will be accomplished.

Then they lose money if they don't accomplish anything.
Right, if fixing it costs them more that what you are paying them,
then they desupport you,

No. See my other post.

Many large companies, and profesional develpoers provide source
licences and/or support open source products, including the largest
computer company in the world, IBM.

Yep, so I can buy support, mess up the code I've access to and let
IBM sort it out, is this what I get by using a IBM supported mysql?

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

[Joel Garry]

"Howard J. Rogers" <hj*@dizwell.co m> wrote in message news:<40******* *************** *@news.optusnet .com.au>...

Oh, I dunno. Stick it behind a firewall with some AV software and at
least keep it (OS and AV) minimally up to date, and it will do quite

This does not seem to work at all, from what I've seen in many different places.

http://catless.ncl.ac.uk/Risks/23.35.html#subj8.1

jg
--
@home.com is bogus.
http://www.gcn.com/vol1_no1/daily-updates/1308-1.html

[Joel Garry]

Daniel Morgan <da******@x.was hington.edu> wrote in message news:<108463603 8.285336@yasure >...

Howard J. Rogers wrote:

And, to be quite blunt, if the only operating system it will run on
is Windows that becomes a limitation affecting all of the above. Any
time you database server is at risk from every 16 year old on the
planet. It can't really be called secure or stable.

Oh, I dunno. Stick it behind a firewall with some AV software and at
least keep it (OS and AV) minimally up to date, and it will do quite
reasonable service, and the script kiddies can be largely forgotten about.

Regards
HJR

And would you then ignore all of the security patches?

If you don't ... you still need to at least once a month, likely more
often, down your production database to apply them and reboot the
server.

For what possible benefit? I'm still looking for one thing Windows
can do that, for example, Linux can't do ... except perhaps steal
cycles from the CPU.

Be ubiquitous. (So far. :-)

jg
--
@home.com is bogus.
There might be better air in a SCUBA tank, but what are you breathing right now?

[Joel Garry]

"Howard J. Rogers" <hj*@dizwell.co m> wrote in message news:<40******* *************** *@news.optusnet .com.au>...

Daniel Morgan wrote:

Howard J. Rogers wrote:

And, to be quite blunt, if the only operating system it will run on
is Windows that becomes a limitation affecting all of the above. Any
time you database server is at risk from every 16 year old on the
planet. It can't really be called secure or stable.
Oh, I dunno. Stick it behind a firewall with some AV software and at
least keep it (OS and AV) minimally up to date, and it will do quite
reasonable service, and the script kiddies can be largely forgotten
about.

Regards
HJR

And would you then ignore all of the security patches?

If you don't ... you still need to at least once a month, likely more
often, down your production database to apply them and reboot the
server.

True enough. But not every patch needs to be applied to every server
(one can get more intelligent about these things that the CYA Microsoft
advisories suggest).

But even so. It takes me about 48 seconds to shutdown and re-start my
Windows 2000 Advanced server. I think I can live with 48 seconds of
downtime a month. I think *most* people could live with that sort of
downtime a month, actually. The number of people who truly, absolutely,
must have no compromises 5 9's uptime are actually quite small, if you
look at the planet as a whole.

But no one cares about who truly needs it. Perception trumps here.

For what possible benefit? I'm still looking for one thing Windows
can do that, for example, Linux can't do ... except perhaps steal
cycles from the CPU.

Well, that's a change in the terms of the debate. My issue is with
anyone calling Windows 'not an operating system', because it evidently
is. I didn't say it does one thing that Linux can't do. Nor vice versa.

Just accept the fact that a large number of servers around the world are
running Windows, whether you like it or not, and they somehow manage to
achieve productive work by doing so. A good DBA will therefore accept
Windows as just one more tool to be understood and used appropriately,
and not expend serious effort trying to slag it off.

I think a good DBA would consider that unnecessary problems that
reduce productivity and seriously add to workload in an enviroment of
insufficient IT resources are something to be avoided.
"Appropriat ely" indeed.

In the past, you could make your argument, because of the cost
differential between Windows and Everything Else. But with linux
mainstream and GUI, you now have to compare the differentials on the
same hardware with the same talent pool and low transition costs, and
it loses.

jg
--
@home.com is bogus.
http://www.ucolick.org/~jhhowell/gam...e/dndhumor.txt