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

Bit offtopic, but yes, indeed it is. Starting point on that,

http://advocacy.postgresql.org/casestudies/


Cheers

Rove


--
Rove Monteux
Systems Administrator


Sarah Tanembaum wrote:

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

"Sarah Tanembaum" <sarah.tanembaum@yahoo.com> schrieb im Newsbeitrag news:c78jfi$vomj$1@ID-205437.news.uni-berlin.de...
> 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
No idea. What I like about oracle is the tools, especially rman and the wizards
and also the support. Paying for something gives me power over the guy I pay.
Also, I like to have lots of little screws to tailor my database to the specific hardware
and load profile.

Lots of Greetings!
Volker

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sarah Tanembaum wrote:

> 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

I would recommend MySQL if you are looking for an alternative. I know
nothing of PostgreSQL, but I know that MySQL is suitable for use as a
high-usage database.

Fred
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAl95/ima0zti2BQgRAo6FAJ0eUN3b9uYV86budS8uVuhj492OfwCeJE92
/ZA1d4Uu1NdwN/Kmcuquh+Y=
=Q60M
-----END PGP SIGNATURE-----

On Tue, 2004-05-04 at 14:23, Fred Emmott wrote:
> > Is PostgreSQL reliable enough to be used for high-end commercial
> > application? Thanks

PostgreSQL runs RubyForge... it's not very high volume - half million
records, 70-80K queries a day - but it does the job.

<shameless>
Good tools for it too!  http://pqa.rubyforge.org/
</shameless>

Yours,

Tom

Sarah Tanembaum wrote:

> 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

PostgreSQL is highly overrated and not suitable for any environment
where little things like crash recovery and security are a priority.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

Postgresql and MySQL are both very impressive.

The latest Oracle 10g comes with zillions of features that might
be relevant to you or not.

Oracle 10g has many features you might maybe never need,
but mysql cluster does not yet contain.  I do not know much
about the latest DB2 clustering possibilities.

These "monster" Databases like Oracle are more than just
a database. You have tons of platform integration possibilities.

I think the choice really depends on what you are going todo
and there is no simple answer.

Good luck,
  -Armin




 

Daniel Morgan wrote:
> 
> PostgreSQL is highly overrated and not suitable for any environment
> where little things like crash recovery and security are a priority.
> 
In what sense is Postgresql overrrated?
Have you used the newer versions of PG recently?

Not to say that I'm advocating using PG for a "high-end commercial 
application", but I've been working with it for several months now, 
along with our Oracle db's, and it has served our needs well without 
failure. Obviously, Oracle has more going for it, but that's to be 
expected from a perennial market leader.

....or were you just trying to start another flame war?

"Daniel Morgan" <damorgan@x.washington.edu> wrote

> > 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
>
> PostgreSQL is highly overrated and not suitable for any environment
> where little things like crash recovery and security are a priority.

Why postgresSQL?? Why don't u say that all RDBMS except Oracle is
highly overrated. This way u don't have to fear about ur job for any
foreseeable future.

Your attitude reminds me of the attitude Americans had towards outsourcing
some 4/5 yrs ago. At that time all they could do is to arrogantly dismiss
outsourcing as unsustainable model. We all know what happened to them today.

I see lot of similarity between movement towards outsourcing few yrs
ago and now movement towards open source database. US companies, after
achieving cost savings thru outsourcing will next turn their attention
to money guzzling enterprise software like RDBMS. How long do you think
it will take them to realize that most of them don't deserve the price
tag they pay.

See ya after 3 yrs in Bangalore :-)

(xrefs removed)

In message <c78quu$136n3$1@ID-75254.news.uni-berlin.de>, rkusenet 
<rkusenet@sympatico.ca> writes
>"Daniel Morgan" <damorgan@x.washington.edu> wrote
>
>> > 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
>>
>> PostgreSQL is highly overrated and not suitable for any environment
>> where little things like crash recovery and security are a priority.
>
>Why postgresSQL?? Why don't u say that all RDBMS except Oracle is
>highly overrated. This way u don't have to fear about ur job for any
>foreseeable future.
>
>Your attitude reminds me of the attitude Americans had towards outsourcing
>some 4/5 yrs ago. At that time all they could do is to arrogantly dismiss
>outsourcing as unsustainable model. We all know what happened to them today.
>
>I see lot of similarity between movement towards outsourcing few yrs
>ago and now movement towards open source database. US companies, after
>achieving cost savings thru outsourcing will next turn their attention
>to money guzzling enterprise software like RDBMS. How long do you think
>it will take them to realize that most of them don't deserve the price
>tag they pay.
>
>See ya after 3 yrs in Bangalore :-)

Can you do a snapshot backup whilst using PostgreSQL or MySQL?  I 
suspect not.  This kind of functionality is what you are getting with 
Informix and Oracle, and for a 24x7 operation it's vital.


-- 
Five Cats
Email to: cats_spam at uk2 dot net

On Tue, 04 May 2004 19:03:35 GMT, Bricklen <bricklen-rem@yahoo.comz>
wrote:

>Daniel Morgan wrote:
>> 
>> PostgreSQL is highly overrated and not suitable for any environment
>> where little things like crash recovery and security are a priority.
>> 
>In what sense is Postgresql overrrated?
>Have you used the newer versions of PG recently?
>
>Not to say that I'm advocating using PG for a "high-end commercial 
>application", but I've been working with it for several months now, 
>along with our Oracle db's, and it has served our needs well without 
>failure. Obviously, Oracle has more going for it, but that's to be 
>expected from a perennial market leader.
>
>...or were you just trying to start another flame war?
Wasn't thst what the OP was up to, making some negative observations
about Oracle. If you subscribe to the Open Source Religion, why asking
questions in the camp of the Enemy?


--
Sybrand Bakker, Senior Oracle DBA

Sybrand Bakker wrote:

> On Tue, 04 May 2004 19:03:35 GMT, Bricklen <bricklen-rem@yahoo.comz>
> wrote:
>
>>...or were you just trying to start another flame war?
> 
> Wasn't thst what the OP was up to, making some negative observations
> about Oracle.

On reflection, I worded that wrong. It should have read "...or were you 
just trying to _amplify_ another flame war..."
I didn't even hint that I agreed with the OP. I happen to agree with 
_you_ that the OP was likely trying to start another tiresome 
open-source war, either that or (s)he is wholly ignorant of the vagaries 
of usenet in general.


> If you subscribe to the Open Source Religion, why asking
> questions in the camp of the Enemy?

Square peg, round hole. I don't fall into one camp or the other.
My job dictates that I use both (and many other things) to get done what 
needs to be done. Besides, I'm not going to get involved in a flame war 
based on my likes and dislikes of _software_, I just don't have the time 
for that (nor the inclination). In addition, it was more of a rhetorical 
question, since we both know that Daniel should know better than to fall 
into simplistic traps like that.
> 
> --
> Sybrand Bakker, Senior Oracle DBA

Cheers,

Bricklen

rkusenet wrote:

> "Daniel Morgan" <damorgan@x.washington.edu> wrote
> 
> 
>>>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
>>
>>PostgreSQL is highly overrated and not suitable for any environment
>>where little things like crash recovery and security are a priority.
> 
> 
> Why postgresSQL?? Why don't u say that all RDBMS except Oracle is
> highly overrated

Because saying so wouldn't be true. There are documented security and
recovery practices for all of the commercial RDBMS products. There are
books, case studies, and years of experience from industry professionals
supporting the fact that while they may be different ... they all work.
The same can not be said for PostgreSQL. MySQL, in this regard, has a
far better record.

Care to disagree? Fine. Provide the names of 5 major commercial
installations of PostgreSQL.

I'll do it for the Oracle side.
  1. Amazon.com
  2. Mastercard
  3. Visa
  4. Federal Bureau of Investigation
  5. Boeing Commercial Airplane Group
  6. Bank of America
  7. Washington Mutual Bank
  8. American Express
  9. Starbucks
10. Oracle Corporation

There ... gave you five more for free. If you've got something to
talk about ... name names ... otherwise stop promoting freeware
as though it was worth more than its price.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

Bricklen wrote:

> Daniel Morgan wrote:
> 
>>
>> PostgreSQL is highly overrated and not suitable for any environment
>> where little things like crash recovery and security are a priority.
>>
> In what sense is Postgresql overrrated?
> Have you used the newer versions of PG recently?
> 
> Not to say that I'm advocating using PG for a "high-end commercial 
> application", but I've been working with it for several months now, 
> along with our Oracle db's, and it has served our needs well without 
> failure. Obviously, Oracle has more going for it, but that's to be 
> expected from a perennial market leader.
> 
> ...or were you just trying to start another flame war?

Not interested in flame wars ... just facts. Corrupt the data with a 
byte editor and try to recover.

If you succeed then I'll withdraw my comment with respect to the most
recent version.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

Five Cats <cats_spam@[127.0.0.1]> wrote:
> Can you do a snapshot backup whilst using PostgreSQL or MySQL?  I 
> suspect not.  This kind of functionality is what you are getting with 
> Informix and Oracle,

Searching for "mysql hot copy" lead to http://www.innodb.com/order.php:
InnoDB Hot Backup is a tool which allows you to backup a running InnoDB
database under MySQL without setting any locks or disturbing normal
database processing. You get a consistent copy of your database, as if
the copy were taken at a precise point in time.

> and for a 24x7 operation it's vital.

But in those situations you don't want to be dependend one 1 machine,
and with more machines available taking 1 down for a backup isn't that
big an issue IMHO.

-- 

  Daniel Tryba

"Daniel Morgan" <damorgan@x.washington.edu> wrote

> Because saying so wouldn't be true. There are documented security and
> recovery practices for all of the commercial RDBMS products. There are
> books, case studies, and years of experience from industry professionals
> supporting the fact that while they may be different ... they all work.
> The same can not be said for PostgreSQL. MySQL, in this regard, has a
> far better record.
>
> Care to disagree? Fine. Provide the names of 5 major commercial
> installations of PostgreSQL.

Mine was a comment on ur attitude towards any non oracle product.
I can show examples where you attacked MYSQL also. Just like you
attack DB2/Informix and your pet hate object SQLServer.

You are right that MySQL has a far better record than PostgreSQL
and IMO they will give all commercial RDBMS a run for their money.

I can only spell PostgreSQL. So I can't name any installations
of PostgreSQL.

> There ... gave you five more for free. If you've got something to
> talk about ... name names ... otherwise stop promoting freeware
> as though it was worth more than its price.

Freeware also includes MySQL. (actually they are no longer free
for profit oriented corporations)

Fred Emmott <pcfreak65@hotmail.com> wrote in message news:<1d3lm1-js6.ln1@fred.lan>...
> I would recommend MySQL if you are looking for an alternative. I know
> nothing of PostgreSQL, but I know that MySQL is suitable for use as a
> high-usage database.

You are kidding, right? Out of curiosity I took a look at MySQL
performance tuning manual. It's almost empty. The example where their
engine picks up Cartesian Product due to type mismatch is strikingly
naive. Scanning a single table by index that MySQL seems to emphasize
is not a benchmark.

"rkusenet" <rkusenet@sympatico.ca> wrote in message news:<c78quu$136n3$1@ID-75254.news.uni-berlin.de>...
> Your attitude reminds me of the attitude Americans had towards outsourcing
> some 4/5 yrs ago. At that time all they could do is to arrogantly dismiss
> outsourcing as unsustainable model. We all know what happened to them today.

Yes, you've got the point. Behind both of these models (outsourcing
and free soft) is the idea that the quality is not important, the only
thing that matter are costs and their cuts. And you're also true that
freeware alternatives will earn their place. In the world where CIO is
one year temp job and the best thing on CIO's CV is cutting cost to
10% and sack off 80% of internal staff because of outsourcing to
India, in this world free databases are very tempting way to go. Of
course, the outcome will be lowered availability, higher maintenance
costs, security problems and damaged business reputation, but who gave
a f*ck, we saved 90% of our internal IT budget.

--
Dusan Bolek

Email: spambin@seznam.cz
Pls add "Not Guilty" to the subject, otherwise your email is going to
be burnt as a SPAM.

"rkusenet" <rkusenet@sympatico.ca> wrote in message news:<c79fr5$1bi40$1@ID-75254.news.uni-berlin.de>...
> 
> You are right that MySQL has a far better record than PostgreSQL
> and IMO they will give all commercial RDBMS a run for their money.
> 
> I can only spell PostgreSQL. So I can't name any installations
> of PostgreSQL.
> 
> > There ... gave you five more for free. If you've got something to
> > talk about ... name names ... otherwise stop promoting freeware
> > as though it was worth more than its price.
> 
> Freeware also includes MySQL. (actually they are no longer free
> for profit oriented corporations)

Evident you are mislead by the 'Free is better' religion and you don't
care for robustness and stability. Otherwise you wouldn't state MySQL
will give all commercial RDBMS a run for their money. If you would
honestly compare the architecture of Oracle (and most other commercial
RDBMSes) and you would be frank, you would have to admit MySQL is a
toy. Nothing more, nothing less.
Evidently, there are too many people around in the field, who never
*learned* to develop robust applications and databases, and who mainly
deliver software which is hacked together. Of course, this mentality
perfectly suits the Open Source Community. I wouldn't want to be in
anyone shoes if your silly assertion becomes true, because that means
the bean counters have finally won, and are going to ruin their own
employers by trading in robust, stable and scalable software like
Oracle for toys like MySQL.

Also, you are evidently being dishonest, and contradicting yourself.
You both don't know any PostgreSQL, while you hail it as being better
than Oracle, and you label MySQL as free software, and in the same
phrase you have to admit MySQL isn't true.
I would take better care before you start accusing people here.

Sybrand Bakker
Senior Oracle DBA

"Dusan Bolek" <pagesflames@usa.net> wrote in message news:1e8276d6.0405042216.779e50c6@posting.google.com...

> Yes, you've got the point. Behind both of these models (outsourcing
> and free soft) is the idea that the quality is not important, the only
> thing that matter are costs and their cuts.

This isn't about the subject of this thread, but it got me curious.

Are you suggesting that outsourcing to India means reduction in quality.
I am asking this because what is believed is the other way, that is,
outsourcing to India means better quality work. There was an article
in eweek "time to debunk myth that indian programmers are better".
I will post the link later. Don't have it now.

"Sarah Tanembaum" <sarah.tanembaum@yahoo.com> wrote in message
news:c78jfi$vomj$1@ID-205437.news.uni-berlin.de...
> 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

<monumental xposting removed for my own sanity...>

<groan>

some people are sooo stupid....

-- 
Cheers
Nuno Souto
wizofoz2k@yahoo.com.au.nospam

Daniel Morgan <damorgan@x.washington.edu> wrote in message news:<1083695957.163784@yasure>...
> PostgreSQL is highly overrated and not suitable for any environment
> where little things like crash recovery and security are a priority.

Sounds like you have an extensive experience with PostgreSQL. Out of
curiosity, exactly how much?

Cheers,
Igor

--T4sUOijqQbZv57TR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, May 05, 2004 at 03:19:08PM +0900, Dusan Bolek wrote:
> Behind both of these models (outsourcing and free soft) is the
> idea that the quality is not important, the only thing that
> matter are costs and their cuts.

BS.  Revisit your Economics lessons.

> in this world free databases are very tempting way to go. Of
> course, the outcome will be lowered availability, higher
> maintenance costs, security problems and damaged business
> reputation, but who gave a ****, we saved 90% of our internal
> IT budget.

YABS.  Or just trolling? :-)

/me returns to Pickaxe and some LiveCD-related stuff to help
people (*shrug*) cut on their IT/win32 budgets.  That is, throw
less money away.

PS: somehow my spamfilter was totally correct on this post...
probably I'd better ignore the troll altogether. :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

--T4sUOijqQbZv57TR
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAmNm9bsPDprYMm3IRAmniAKCxumRkUMaQ9P94ZxxZK72OP7/TTACgvo2U
6bMCHsqMbnXssk1DlsgX47U=
=gQIK
-----END PGP SIGNATURE-----

--T4sUOijqQbZv57TR--

<sybrandb@yahoo.com> wrote :-

> Evident you are mislead by the 'Free is better' religion and you don't
> care for robustness and stability. Otherwise you wouldn't state MySQL
> will give all commercial RDBMS a run for their money.

If 'freeware' Linux can give a run for their money to Windows / Solaris,
why not mysql. Why do people have to associate instability with every
freeware product.
Mysql has some other problems for me. Its SQL is not ANSI standard, at least
in the stable version. Plus lack of support for correlated subquery etc
(in stable version) makes it hard to write SQL. MYsql is fixing it and once
they iron it out in their next stable version, I will consider them seriously.
It is just a question of time.

BTW Mysql is no longer free (non profit organization can still get it for
free).

"rkusenet" <rkusenet@sympatico.ca> wrote in message
news:c7aqfj$1h5su$1@ID-75254.news.uni-berlin.de...
> <sybrandb@yahoo.com> wrote :-

> why not mysql. Why do people have to associate instability with every
> freeware product.

I think you just answered this:^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

with this: VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV

> BTW Mysql is no longer free (non profit organization can still get it for
> free).



-- 
Cheers
Nuno Souto
wizofoz2k@yahoo.com.au.nospam

"rkusenet" <rkusenet@sympatico.ca> wrote in message
news:c7af0p$1jfmr$1@ID-75254.news.uni-berlin.de...

> Are you suggesting that outsourcing to India means reduction in quality.
> I am asking this because what is believed is the other way, that is,
> outsourcing to India means better quality work. There was an article
> in eweek "time to debunk myth that indian programmers are better".
> I will post the link later. Don't have it now.

http://www.eweek.com/article2/0,1759,1583257,00.asp?kc=EWNWS050304DTX1K0000599

rkusenet wrote:
> 
> "rkusenet" <rkusenet@sympatico.ca> wrote in message
> news:c7af0p$1jfmr$1@ID-75254.news.uni-berlin.de...
> 
> > Are you suggesting that outsourcing to India means reduction in quality.
> > I am asking this because what is believed is the other way, that is,
> > outsourcing to India means better quality work. There was an article
> > in eweek "time to debunk myth that indian programmers are better".
> > I will post the link later. Don't have it now.
> 
> http://www.eweek.com/article2/0,1759,1583257,00.asp?kc=EWNWS050304DTX1K0000599

Aren't you contradicting yourself here? You seem to be implying that
outsourcing to India *does not* mean a reduction in quality and then you
post an article which says the quality is not necessarily better. Which
is your viewpoint?

Cheers,
Brian

-- 
===================================================================

Brian Peasland
dba@remove_spam.peasland.com

Remove the "remove_spam." from the email address to email me.


"I can give it to you cheap, quick, and good. Now pick two out of
 the three"

rkusenet wrote:
> "Dusan Bolek" <pagesflames@usa.net> wrote in message news:1e8276d6.0405042216.779e50c6@posting.google.com...
> 
> 
>>Yes, you've got the point. Behind both of these models (outsourcing
>>and free soft) is the idea that the quality is not important, the only
>>thing that matter are costs and their cuts.
> 
> 
> This isn't about the subject of this thread, but it got me curious.
> 
> Are you suggesting that outsourcing to India means reduction in quality.
> I am asking this because what is believed is the other way, that is,
> outsourcing to India means better quality work. There was an article
> in eweek "time to debunk myth that indian programmers are better".
> I will post the link later. Don't have it now.

It depends. For somethings outsourcing to India provides both quality
and quantity for a lower cost. For other things ... for example
corporations trying to lower costs by outsourcing internal app
developement it is definitely a case of lower quality and poorer
implementations.

The thing that must be remembered is that many, if not most, IT projects
fail not due to the quality of the developers (though many are marginal)
but rather due to the lack of clear well written specifications. If the
same specs were handed to me as are sent to Bangalore ... I could easily
beat the Indians at their own game: Delivering better quality at the
same cost in less time.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

"Brian Peasland" <dba@remove_spam.peasland.com> wrote in message
news:4099104F.F5CC564B@remove_spam.peasland.com...
> rkusenet wrote:
> >
> > "rkusenet" <rkusenet@sympatico.ca> wrote in message
> > news:c7af0p$1jfmr$1@ID-75254.news.uni-berlin.de...
> >
> > > Are you suggesting that outsourcing to India means reduction in quality.
> > > I am asking this because what is believed is the other way, that is,
> > > outsourcing to India means better quality work. There was an article
> > > in eweek "time to debunk myth that indian programmers are better".
> > > I will post the link later. Don't have it now.
> >
> > http://www.eweek.com/article2/0,1759,1583257,00.asp?kc=EWNWS050304DTX1K0000599
>
> Aren't you contradicting yourself here? You seem to be implying that
> outsourcing to India *does not* mean a reduction in quality and then you
> post an article which says the quality is not necessarily better. Which
> is your viewpoint?

No I am not contradicting. I was giving a link to Dusan Bolek
which shows that how some believe that outsourcing increases quality
and how some think it is not.
if everyone believed like Dusan, why would there be a need to debunk
myth, right? Won't it be taken as granted that outsourcing means
poor quality.

Brian Peasland wrote:

>rkusenet wrote:
>  
>
>>"rkusenet" <rkusenet@sympatico.ca> wrote in message
>>news:c7af0p$1jfmr$1@ID-75254.news.uni-berlin.de...
>>
>>    
>>
>>>Are you suggesting that outsourcing to India means reduction in quality.
>>>I am asking this because what is believed is the other way, that is,
>>>outsourcing to India means better quality work. There was an article
>>>in eweek "time to debunk myth that indian programmers are better".
>>>I will post the link later. Don't have it now.
>>>      
>>>
>>http://www.eweek.com/article2/0,1759,1583257,00.asp?kc=EWNWS050304DTX1K0000599
>>    
>>
>
>Aren't you contradicting yourself here? You seem to be implying that
>outsourcing to India *does not* mean a reduction in quality and then you
>post an article which says the quality is not necessarily better. Which
>is your viewpoint?
>
>Cheers,
>Brian
>
>  
>
There is no sense belabouring this because in both places they are just 
people both w/better and lesser skills at certain things in certain 
contexts.Certainly 15k for a programmer is better than 75k. If you look, 
you could find a 15k programmer better thatn the 75k programmer here - 
and vice versa.

Back to the topic of the thread. I've not used Oracle much(and when i 
did it thought it was overly complex) but I've used A LOT of MS SQL and 
mysql (and a little postgres). My needs have been quite simple so i 
really do not know enough to know the things that I might be missing. 
Even after facing(and not fully rectifying) the 'Mysql has gone away' 
problem(from both php and ruby:dbi) I still would rather use mysql than 
mssql. I suppose this has more to do with ruby and less to do with the 
db but that's my pennies worth.

'You get what you pay for'.
'Good enough is good enough when good enough is all you need.'

"Daniel Morgan" <damorgan@x.washington.edu> wrote

> The thing that must be remembered is that many, if not most, IT projects
> fail not due to the quality of the developers (though many are marginal)
> but rather due to the lack of clear well written specifications.

totally agreed.

> If the same specs were handed to me as are sent to Bangalore ... I could easily
> beat the Indians at their own game: Delivering better quality at the
> same cost in less time.

For everyone like you, there are equally arrogant Indians who claim that
majority of Americans in the IT field are DUMB.

Anyhow IMO it is the oracle folks who have to worry the most, because India
has a huge pool of oracle savvy developers. Larry Ellison realized it years
ago. he opened up a centre in bangalore in early 1990s when outsourcing was
at a nascent stage. Today Oracle India is a significant cog in their wheel.

(X-posts removed)


In message <c7af0p$1jfmr$1@ID-75254.news.uni-berlin.de>, rkusenet 
<rkusenet@sympatico.ca> writes
>"Dusan Bolek" <pagesflames@usa.net> wrote in message 
>news:1e8276d6.0405042216.779e50c6@posting.google.com...
>
>> Yes, you've got the point. Behind both of these models (outsourcing
>> and free soft) is the idea that the quality is not important, the only
>> thing that matter are costs and their cuts.
>
>This isn't about the subject of this thread, but it got me curious.
>
>Are you suggesting that outsourcing to India means reduction in quality.
>I am asking this because what is believed is the other way, that is,
>outsourcing to India means better quality work. There was an article
>in eweek "time to debunk myth that indian programmers are better".
>I will post the link later. Don't have it now.

I think the big problems with outsourcing coding to (say) India is not 
the quality of what is produced, but the problems of managing it, and 
also cultural differences.  For example, when working on a Housing 
Benefit system in a country where such a thing doesn't exist has it's 
own specific problems.
>
>

-- 
Five Cats
Email to: cats_spam at uk2 dot net

> This isn't about the subject of this thread, but it got me curious.
> 
> Are you suggesting that outsourcing to India means reduction in quality.
> I am asking this because what is believed is the other way, that is,
> outsourcing to India means better quality work. There was an article
> in eweek "time to debunk myth that indian programmers are better".
> I will post the link later. Don't have it now.

I am going to go out on a limb and say worse quality work because I
can't understand them when I talk to them on the phone.

On Thu, 2004-05-06 at 02:53 +0900, NorwoodThree wrote:
> > This isn't about the subject of this thread, but it got me curious.
> > 
> > Are you suggesting that outsourcing to India means reduction in quality.
> > I am asking this because what is believed is the other way, that is,
> > outsourcing to India means better quality work. There was an article
> > in eweek "time to debunk myth that indian programmers are better".
> > I will post the link later. Don't have it now.
> 
> I am going to go out on a limb and say worse quality work because I
> can't understand them when I talk to them on the phone.

A Global Survey of Software Development Practices

http://ebusiness.mit.edu/research/papers/178_Cusumano_Intl_Comp.pdf

Best,

Richard

"Sarah Tanembaum" <sarah.tanembaum@yahoo.com> wrote in message news:<c78jfi$vomj$1@ID-205437.news.uni-berlin.de>...
> 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

Depends.

How much is your data worth?  
How much will downtime cost?
How much will a commercial database cost?

PostgreSQL is a really nice little database, and has a lot going for
it:
- easy to install, admin, and use
- easy to port databases between PostgreSQL and other commercial
databases
- very high-quality implementation

However, on the other side of the coin:
- missing many of the high-end features needed in large data volumes
like partitioning, clustering, parallelism, materialized views, query
rewrite, etc.
- missing many of the high-availabity features
- missing lots of the various stuff: replication, etc

Personally, when I've got a lot of value in my database I typically
opt for a commercial offering.  But there are those exceptional
situations - like:
- no budget
- just want to prototype
- it's read-only data and you can create a dozen small databases
- the data isn't super-valuable
Then in these cases - PostgreSQL is a nice little product, and I
wouldn't hesitate to use it.  Much better, btw than its primary
competitor - MySQL with its limited, non-ansi sql, and amazing
exception handling irregularities.


kenfar

"rkusenet" <rkusenet@sympatico.ca> wrote in message news:<c78quu$136n3$1@ID-75254.news.uni-berlin.de>...
> "Daniel Morgan" <damorgan@x.washington.edu> wrote
> 
> > > 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
> >
> > PostgreSQL is highly overrated and not suitable for any environment
> > where little things like crash recovery and security are a priority.
> 
> Why postgresSQL?? Why don't u say that all RDBMS except Oracle is
> highly overrated. This way u don't have to fear about ur job for any
> foreseeable future.
> 
> Your attitude reminds me of the attitude Americans had towards outsourcing
> some 4/5 yrs ago. At that time all they could do is to arrogantly dismiss
> outsourcing as unsustainable model. We all know what happened to them today.
> 
> I see lot of similarity between movement towards outsourcing few yrs
> ago and now movement towards open source database. US companies, after
> achieving cost savings thru outsourcing will next turn their attention
> to money guzzling enterprise software like RDBMS. How long do you think
> it will take them to realize that most of them don't deserve the price
> tag they pay.
> 
> See ya after 3 yrs in Bangalore :-)

There is a backlash against outsourcing now.  Some parts are
sustainable and some are not.  Anyone can do bad java code.  For
administrative purposes, the database (well, not really, it's the
managers) requires someone local.  And the definition of
administration is broadening.

I had come to this conclusion myself, then saw a talk on
administration futures by Guy Harrison where he said it, then a
solicited commercial email from Mike Ault where he said it, too.

Deserving has nothing to do with it.  It's the useful application that
gets the money.

And the drudge development that can be outsourced?  Bangalore is
losing it to China and Eastern Europe.

jg
--
@home.com is bogus.
http://www.time.com/time/archive/preview/from_search/0,10987,1101040419-610085,00.html

"Sarah Tanembaum" <sarah.tanembaum@yahoo.com> wrote in message news:<c78jfi$vomj$1@ID-205437.news.uni-berlin.de>...

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

Some rules of thumb, A guide to the perplexed:

- If you don't have the source code for a product, and the right to
modify and redistribute it in perpetuity, nothing you develop on top
of it can be relied upon, so therefore the open source applications,
or applications for wich you've been granted such rights via an
non-expiring licence, are much *MORE* suitable for high-end commercial
applications, since you are not locked into any external dependencies.

- Ideally, your Application's data access will be built around a data
abstraction layer that can use alternative database backends, i.e.
PEAR::DB.

- If your data is really important to you, you will use network, not
application or database level security to protect access to it.

- If your data is really important to you, you will only keep a
secondary copy of it in *ANY* SQL server for indexing and querying
purposes, not as the primary datastore.

- Your primary datastore should be self contained, self describing and
human readable, something like a heirarchy of XML files. This is the
best way to ensure the perminancy and portabilty of your important
data.

- Anyone who calls Free Software 'Freeware', implies that believing in
it is a 'religion' or thinks that it is low quality as a rule should
be considered unskilled labour, not a source of real advice.

I'm also in Berlin BTW :) I hope you had a fun May 1st.

Cheers.

"Quirk" <quirk@syntac.net> schrieb im Newsbeitrag news:4e20d3f.0405060711.176b495d@posting.google.com...
> "Sarah Tanembaum" <sarah.tanembaum@yahoo.com> wrote in message news:<c78jfi$vomj$1@ID-205437.news.uni-berlin.de>...
> 
> > Is PostgreSQL reliable enough to be used for high-end commercial
> > application? Thanks
> 
> Some rules of thumb, A guide to the perplexed:
> 
> - If you don't have the source code for a product, and the right to
> modify and redistribute it in perpetuity, nothing you develop on top
> of it can be relied upon, so therefore the open source applications,
> or applications for wich you've been granted such rights via an
> non-expiring licence, are much *MORE* suitable for high-end commercial
> applications, since you are not locked into any external dependencies.
That's not true. The main problem is not the right to the source code
but the right to get maintenance.
An example: How many corporations had UTF8 built into oracle before
the UTF8 enabled distribution came out?
Who implemented ANSI PL/SQL for mysql before the mysql developers did?
The right to modify is a red herring. If I'm prepared to spend man-years on having
a developer work itself into postgresql or mysql (plus set up all the QA stuff)
I can also ask any other db company for the price of a feature. Or, in case
of old versions, buy vintage support.

> 
> - Ideally, your Application's data access will be built around a data
> abstraction layer that can use alternative database backends, i.e.
> PEAR::DB.
Which either gives me the freedom to write nonportable code
("create bitmap index", "where A(+)=B") or loses efficiency
on all but the dumbest platform.

> 
> - If your data is really important to you, you will use network, not
> application or database level security to protect access to it.
Wrong. If it's important it must not matter whether one tries to
access the data from a local or remote machine. A defense in depth
will always include a securely configured database.


> 
> - If your data is really important to you, you will only keep a
> secondary copy of it in *ANY* SQL server for indexing and querying
> purposes, not as the primary datastore.
The primary store is the safe with the tapes of last night. So what?

> - Your primary datastore should be self contained, self describing and
> human readable, something like a heirarchy of XML files. This is the
> best way to ensure the perminancy and portabilty of your important
> data.
Until the next version can't read the old format (or DTD in the XML case).
In any case, permanency across more than two major database or other
software releases is difficult, regardless of the format.

> - Anyone who calls Free Software 'Freeware', implies that believing in
> it is a 'religion' or thinks that it is low quality as a rule should
> be considered unskilled labour, not a source of real advice.
It's not "low quality" as a rule, at least not as long as one reduces product
quality to code quality. The problem is that as soon as the developers feel
they are fed up with the product or get a real job they dump the code
on you and leave you alone with it. They get nothing, so they are not
required to do anything.
So, I'd only trust mysql if I could do a contract detailing response times,
recovery services, a patch process and all that. Since I then have to
pay anyway, I might as well go for the company that's best at it. Oracle
has a reputation for that and after 5 service requests I've never been
disappointed yet. No idea how IBM or M$Soft do in the service area.

Lots of Greetings!
Volker

rkusenet wrote:
> "Daniel Morgan" <damorgan@x.washington.edu> wrote
> 
>>If the same specs were handed to me as are sent to Bangalore ... I could easily
>>beat the Indians at their own game: Delivering better quality at the
>>same cost in less time.
> 
> For everyone like you, there are equally arrogant Indians who claim that
> majority of Americans in the IT field are DUMB.

Equally arrogant? No! They'd be absolutely correct. The fact that the
majority of anything, anywhere, is dumb is not going to surprise anyone,
anywhere, at any time.

That doesn't mean that the minority doesn't do a damned good job of
keeping things running. You have looked at a set of indisputable facts
and drawn a totally erroneous conclusion.

> Anyhow IMO it is the oracle folks who have to worry the most, because India
> has a huge pool of oracle savvy developers. Larry Ellison realized it years
> ago. he opened up a centre in bangalore in early 1990s when outsourcing was
> at a nascent stage. Today Oracle India is a significant cog in their wheel.

I wouldn't even attempt to compete with the Indians, or the Chinese, or
the Russians, or even the Australians in their area of competence. That
doesn't mean they are competent at all things in all places.

You seem to leap from small facts to large conclusions with little
critical thinking in between.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

In message <4e20d3f.0405060711.176b495d@posting.google.com>, Quirk 
<quirk@syntac.net> writes
>"Sarah Tanembaum" <sarah.tanembaum@yahoo.com> wrote in message 
>news:<c78jfi$vomj$1@ID-205437.news.uni-berlin.de>...
>
>> Is PostgreSQL reliable enough to be used for high-end commercial
>> application? Thanks
>
>Some rules of thumb, A guide to the perplexed:
>
>- If you don't have the source code for a product, and the right to
>modify and redistribute it in perpetuity, nothing you develop on top
>of it can be relied upon, so therefore the open source applications,
>or applications for wich you've been granted such rights via an
>non-expiring licence, are much *MORE* suitable for high-end commercial
>applications, since you are not locked into any external dependencies.
>

So you think most places have a programmer of suitable talent to be let 
lose on something as mission-critical as the database in the situation 
described?


>- Ideally, your Application's data access will be built around a data
>abstraction layer that can use alternative database backends, i.e.
>PEAR::DB.

Depends on what your application is written in.  The more layers are 
added in, the more places there are for things to go wrong, and for 
performance bottlenecks to occur.

>
>- If your data is really important to you, you will use network, not
>application or database level security to protect access to it.

If it's *really* important you will be using all these methods to 
protect it.

>
>- If your data is really important to you, you will only keep a
>secondary copy of it in *ANY* SQL server for indexing and querying
>purposes, not as the primary datastore.

Depends on what the balance between query etc. is, and how important it 
is that the query users see the latest view.  If querying is really 
putting a strain on the database (and with high-end commercial RDBMS 
systems it's amazing what they can do) then thought should be given to 
using OLAP.  Remember that with most databases, most of the activity is 
querying.  Users need to see information from the database to answer 
queries, and to have the information they need to add more data.

And, of course, if your data is *really* important to you you will have 
a decent backup strategy and will have tested restoring it.  You might 
even use a high-end DBMS which can sort out the problems of partially 
written transactions should the server fall over for some reason.

And, of course, you will be using a high-end server with redundancy 
left, right and centre so that disks etc. can be swapped without having 
to bring it or the DBMS off-line.

You might *even* have a second server in a different building you can 
rush a restore to in the event of major catastrophes.

>
>- Your primary datastore should be self contained, self describing and
>human readable, something like a heirarchy of XML files. This is the
>best way to ensure the perminancy and portabilty of your important
>data.

Someone who believes XML is the cure for everything....  I would put 
this at the bottom of the list.  If this is a high-end database 
application the chances are that it's mission critical and moving it 
from one machine to another is the last thing on people's minds most of 
the time.  *when* the time comes to move it the whole business is 
carefully planned, and in the case of the database my paying customers 
use, it comes with all the tools one could with for to get the data out 
of it and into either a different version of it on another platform, or 
a different DBMS offering.

>
>- Anyone who calls Free Software 'Freeware', implies that believing in
>it is a 'religion' or thinks that it is low quality as a rule should
>be considered unskilled labour, not a source of real advice.

And anyone who believes it's the answer to all our prayers is just as 
deluded.
>
>I'm also in Berlin BTW :) I hope you had a fun May 1st.
>
>Cheers.

-- 
Five Cats
Email to: cats_spam at uk2 dot net

> > - If you don't have the source code for a product, and the right to
> > modify and redistribute it in perpetuity, nothing you develop on top
> > of it can be relied upon, so therefore the open source applications,
> > or applications for wich you've been granted such rights via an
> > non-expiring licence, are much *MORE* suitable for high-end commercial
> > applications, since you are not locked into any external dependencies.

> That's not true. 

Yes it is.

> The main problem is not the right to the source code
> but the right to get maintenance.

With out the right to modify the source code you can have no "right to
maintenenence" as all rights are held by one vendor, exactly the sort
of dependency I recomond avoiding.

> The right to modify is a red herring.

Not if your application and the permenancy of your data is important.

> > - Ideally, your Application's data access will be built around a data
> > abstraction layer that can use alternative database backends, i.e.
> > PEAR::DB.

> Which either gives me the freedom to write nonportable code
> ("create bitmap index", "where A(+)=B") or loses efficiency
> on all but the dumbest platform.

You can always write bad code, my point being that if you are using a
commcial SQL server, such as Oracle, you should abstract your data
access so that you can use something else instead down the road, you
can do this with your own wrappers through elegent coding, or use a
class such as PEAR::DB (for PHP), depending on what your application
requirs. Efficiency is very relative, eficiency of what? Code
Executution? Application Extension? Interoperability? Tip: The first
is not always the most important.

> > - If your data is really important to you, you will use network, not
> > application or database level security to protect access to it.

> Wrong.

Famous last word(s).

> If it's important it must not matter whether one tries to
> access the data from a local or remote machine.

Interesting that you believe that this can not be accomblished with
network security.

> A defense in depth
> will always include a securely configured database.

Yes, a securely configured database, protected by a secure network,
the later being far more important!

> > - If your data is really important to you, you will only keep a
> > secondary copy of it in *ANY* SQL server for indexing and querying
> > purposes, not as the primary datastore.

> The primary store is the safe with the tapes of last night. So what?

Not only last night, but also perhaps thirty years later, or maybe a
hundred in the case of public data, which is why some incomprehensible
filesystem blob, accessible only through a deamon for which you do not
even have the source code will not do, rather as I say, self
contained, self describing, human readable files. The filesystem blob
is designed for optimized access not perpetual storage.

> > - Your primary datastore should be self contained, self describing and
> > human readable, something like a heirarchy of XML files. This is the
> > best way to ensure the perminancy and portabilty of your important
> > data.

> Until the next version can't read the old format (or DTD in the XML case).

What is it about "Self Contained, Self Describing, Human Readable"
that you do not understand?

> In any case, permanency across more than two major database or other
> software releases is difficult, regardless of the format.

For unskilled labour, yes. That is why vendor educated developers who
can not see passed their favourite commercial product should not be
asked for advice on this subject.

> > - Anyone who calls Free Software 'Freeware', implies that believing in
> > it is a 'religion' or thinks that it is low quality as a rule should
> > be considered unskilled labour, not a source of real advice.

> It's not "low quality" as a rule, at least not as long as one reduces product
> quality to code quality. The problem is that as soon as the developers feel
> they are fed up with the product or get a real job they dump the code
> on you and leave you alone with it.

If you have the source code, you are the developer, if you contract an
outside developer or licence an existing product, fine, as long as you
have perpetual access to the source code and the *right* to modify it,
or contract someone else to. If you do not, than you can not gaurantee
the permenance of your application.

Cheers.

"Quirk" <quirk@syntac.net> schrieb im Newsbeitrag news:4e20d3f.0405070046.50c2d5dd@posting.google.com...
> > > - If you don't have the source code for a product, and the right to
> > > modify and redistribute it in perpetuity, nothing you develop on top
> > > of it can be relied upon, so therefore the open source applications,
> > > or applications for wich you've been granted such rights via an
> > > non-expiring licence, are much *MORE* suitable for high-end commercial
> > > applications, since you are not locked into any external dependencies.
> 
> > That's not true. 
> 
> Yes it is.
What was the value of this reply?

> 
> > The main problem is not the right to the source code
> > but the right to get maintenance.
> 
> With out the right to modify the source code you can have no "right to
> maintenenence" as all rights are held by one vendor, exactly the sort
> of dependency I recomond avoiding.
I do have the right to maintenance, because that's in the contract. Very simple.

> 
> > The right to modify is a red herring.
> 
> Not if your application and the permenancy of your data is important.
You didn't read my posting, right? I don't *want* to create my own development
team competing with the original one. I don't want to merge my change back into
their code with every new release! I don't want to develop code and then have
them decide whether they condescend to incorporate it or not! I want the authors
of the software to do the coding based on what I'm willing to pay for!

> 
> > > - Ideally, your Application's data access will be built around a data
> > > abstraction layer that can use alternative database backends, i.e.
> > > PEAR::DB.
> 
> > Which either gives me the freedom to write nonportable code
> > ("create bitmap index", "where A(+)=B") or loses efficiency
> > on all but the dumbest platform.
> 
> You can always write bad code, my point being that if you are using a
> commcial SQL server, such as Oracle, you should abstract your data
> access so that you can use something else instead down the road, you
> can do this with your own wrappers through elegent coding,
Elegant coding... The holy grail of software engineering. Why am I spontaneusly
reminded of http://www.dilbert.com/comics/dilbert/archive/dilbert-20040417.html ?

> or use a
> class such as PEAR::DB (for PHP), depending on what your application
> requirs. Efficiency is very relative, eficiency of what? Code
> Executution? Application Extension? Interoperability? Tip: The first
> is not always the most important.
For db computing, reducing server load is the important thing. Interoperability
typically means primitive, network/db intensive sql.

> 
> > > - If your data is really important to you, you will use network, not
> > > application or database level security to protect access to it.
> 
> > Wrong.
> 
> Famous last word(s).
[empty reply]

> 
> > If it's important it must not matter whether one tries to
> > access the data from a local or remote machine.
> 
> Interesting that you believe that this can not be accomblished with
> network security.
Yes. Now you figure out why.

> 
> > A defense in depth
> > will always include a securely configured database.
> 
> Yes, a securely configured database, protected by a secure network,
> the later being far more important!
A network will alway have holes, simply because legitimate users
have to get through and legitimacy can change while they are in.
Therefore you protect the data where they are. In the db.

> > > - Your primary datastore should be self contained, self describing and
> > > human readable, something like a heirarchy of XML files. This is the
> > > best way to ensure the perminancy and portabilty of your important
> > > data.
> 
> > Until the next version can't read the old format (or DTD in the XML case).
> 
> What is it about "Self Contained, Self Describing, Human Readable"
> that you do not understand?
The fact that you believe such a thing exists. Unless you mean a printout
of the database contents.

> 
> > In any case, permanency across more than two major database or other
> > software releases is difficult, regardless of the format.
> 
> For unskilled labour, yes.
Right. You show me how do convert VENUS chip designs into Synopsys
without going into a museom for the original hardware and getting all
the versions in between.

> That is why vendor educated developers who
> can not see passed their favourite commercial product should not be
> asked for advice on this subject.
Get some real world experience.

> 
> > > - Anyone who calls Free Software 'Freeware', implies that believing in
> > > it is a 'religion' or thinks that it is low quality as a rule should
> > > be considered unskilled labour, not a source of real advice.
> 
> > It's not "low quality" as a rule, at least not as long as one reduces product
> > quality to code quality. The problem is that as soon as the developers feel
> > they are fed up with the product or get a real job they dump the code
> > on you and leave you alone with it.
> 
> If you have the source code, you are the developer,
Wrong. I am the user, regardless of whether the vendor wants me to do his
development work or not.

> if you contract an
> outside developer or licence an existing product, fine, as long as you
> have perpetual access to the source code and the *right* to modify it,
> or contract someone else to. If you do not, than you can not gaurantee
> the permenance of your application.
When will you get it, I don't *need* the right to modify it as long as I
have the right to have it modified by the guys who wrote it in the first plac
and are competent at it.

Greetings!
Volker

Daniel Morgan wrote:

> rkusenet wrote:
>
>> "Daniel Morgan" <damorgan@x.washington.edu> wrote
>>
>>
>>>> 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
>>>
>>>
>>> PostgreSQL is highly overrated and not suitable for any environment
>>> where little things like crash recovery and security are a priority.
>>
>>
>>
>> Why postgresSQL?? Why don't u say that all RDBMS except Oracle is
>> highly overrated
>
>
> Because saying so wouldn't be true. There are documented security and
> recovery practices for all of the commercial RDBMS products. There are
> books, case studies, and years of experience from industry professionals
> supporting the fact that while they may be different ... they all work.
> The same can not be said for PostgreSQL. MySQL, in this regard, has a
> far better record.
>
> Care to disagree? Fine. Provide the names of 5 major commercial
> installations of PostgreSQL.
>
> I'll do it for the Oracle side.
>  1. Amazon.com
>  2. Mastercard
>  3. Visa
>  4. Federal Bureau of Investigation
>  5. Boeing Commercial Airplane Group
>  6. Bank of America
>  7. Washington Mutual Bank
>  8. American Express
>  9. Starbucks
> 10. Oracle Corporation


1. BASF
2. Vanten Inc.
3. Shannon Medical Center
4. Mohawk Software
5. Dravis Group

I myself have implemented solutions based on PostgreSQL in clients such 
as Baltimore.

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

In that sense PostgreSQL hasnt all the 'commercial' propaganda behind 
it. PostgreSQL IS freeware AND opensource. Isnt GNU either, so gets no 
GNU (eg. Linux community) support.

Not that any of that affects in its functionality at all, its a great 
product, but people like yourself tied to all the commercial and 
burocratic work tend to ignore.

Bit like Ruby. Pretty sure people that develop and use PostgreSQL would 
bother with it at all.

But now saying that ' they all work.  The same can not be said for 
PostgreSQL. MySQL, in this regard, has a far better record.'.

Give me a break.

If commercial value and propaganda were signal of quality, Windows would 
be the better OS in the world by far. OpenBSD/FreeBSD would be muck. And 
anything not used by Warner, or Amazon.com, and less than $2000 in a tag 
price would be muck as well.

Give me a break.


Cheers


Rove


--
Rove Monteux
Systems Administrator

rove.monteux@fluid-rock.com

>
> There ... gave you five more for free. If you've got something to
> talk about ... name names ... otherwise stop promoting freeware
> as though it was worth more than its price.
>

Volker Hetzer wrote:


> You didn't read my posting, right? I don't *want* to create my own development
> team competing with the original one. I don't want to merge my change back into
> their code with every new release! I don't want to develop code and then have
> them decide whether they condescend to incorporate it or not! I want the authors
> of the software to do the coding based on what I'm willing to pay for!


Precisely. There's nothing wrong with contracts, or a willingness to pay 
for a willingness to support. This is where open source can indeed 
become the socialist flim-flam that Microsoft spoke about (though in the 
wrong context, and drawing the wrong conclusions). Good software 
requires a bit more than warm hugs and cuddles. It requires a contract.

And I heartily concur with your point about not wanting to create your 
own development team. Was 200 years of division-of-labour theory in 
vain? I think not. I'd quite happily pay for a competent team to do my 
development for me, if that happens to free me up to do the stuff *I* 
happen to be modestly competent at.

Why such trade-offs should be considered the spawn of Beelzebub, I have 
no idea.

Regards
HJR

Daniel Morgan <damorgan@x.washington.edu> wrote in message news:<1083705347.538046@yasure>...
> 
> Care to disagree? Fine. Provide the names of 5 major commercial
> installations of PostgreSQL.

Here's a newsflash for alot of DBA's.   Most applications _do not_
need a database as powerfull as Oracle.   Like it or not I would bet a
few apps could get by with flat files.  (I'm half joking...)

I've been a DBA for about 8 years and its rare for a company to use
the advanced features of Oracle.  Advanced Queueing, Replication (in
all its forms), RAC, flashback query, VPD, etc. etc.   In all honesty
how often are these features used?   I worked in a dev. shop once
where they were prepared to spend 6 months developing a feature that
could easily be handled by Oracle.  Their reasoning was that they
didn't want to get tied into a particular database.

Now, i'm not a big fan of mysql... The gotchas link someone else
posted in this thread says it all but I think postgresql is a good for
small-mid sized apps.  It has alot of features that mysql is missing. 
Now, would I use it for my production financials system?  Ummm no, but
I would use it for the corporate employee timesheet system.   For
critical applications I wouldn't hesitate to recommend Oracle, in some
cases maybe even SQLServer but there is room for opensource databases.

"Volker Hetzer" <volker.hetzer@ieee.org> wrote in message news:<c7fl8s$bjo$1@nntp.fujitsu-siemens.com>...

> "Quirk" <quirk@syntac.net> schrieb im Newsbeitrag news:4e20d3f.0405070046.50c2d5dd@posting.google.com...

> > > That's not true. 

> > Yes it is.

> What was the value of this reply?

What was the value of yours? Or this latest one?

> > > The main problem is not the right to the source code
> > > but the right to get maintenance.
> > 
> > With out the right to modify the source code you can have no "right to
> > maintenenence" as all rights are held by one vendor, exactly the sort
> > of dependency I recomond avoiding.

> I do have the right to maintenance, because that's in the contract. Very 
> simple.

Yes, you have the right to be overcharged for work that may or may not
not suit your needs by only _one_ vendor, and no right to go elsewhere
when they fail, ignore you outright, stop supporting your application
or vanish from the face of the earth. Have you actually read your
contract or software licence? It only protects the vendor, not you.

> > > The right to modify is a red herring.
> > 
> > Not if your application and the permenancy of your data is important.

> You didn't read my posting, right? 

You are one funny guy. Really. I'll bet you're the first guy in usenet
to ever ask this question rhetoricly.

> I don't *want* to create my own development
> team competing with the original one. I don't want to merge my change back 
> into their code with every new release! I don't want to develop code and
> then have them decide whether they condescend to incorporate it or not! I 
> want the authors of the software to do the coding based on what I'm willing 
> to pay for!

You are dependent on their licence because you built your own
application on top of a platform for which you have no source code,
and no right to modify, you then also have no leverage with the vendor
of the orginal software.

You have no rights at all, wether or not you are willing to pay.

> Elegant coding... The holy grail of software engineering. Why am I 
> spontaneusly reminded of http://www.dilbert.com/comics/dilbert/archive/
> dilbert-20040417.html ?

I dunno, because you're culturaly issolated and have a poor
imagination?

> For db computing, reducing server load is the important thing. 

No, it is not, in most cases CPU is not the most limited resource.

> Interoperability
> typically means primitive, network/db intensive sql.

No, interoperability means abilty to integrate applications in a
heterogeneus environment. It means standards and flexibilty.

> > > If it's important it must not matter whether one tries to
> > > access the data from a local or remote machine.

> > Interesting that you believe that this can not be accomblished with
> > network security.

> Yes. Now you figure out why.

Because you don't know what you are doing maybe? Oh wait, you don't
need to, after all, you have decided to pay a vendor to know for you,
I remember now.

> > Yes, a securely configured database, protected by a secure network,
> > the later being far more important!

> A network will alway have holes, simply because legitimate users
> have to get through and legitimacy can change while they are in.
> Therefore you protect the data where they are. In the db.

If your network has holes, then your database is insecure, because I
can get right at the filesystem blobs, the reverse however is not
true.

> > What is it about "Self Contained, Self Describing, Human Readable"
> > that you do not understand?

> The fact that you believe such a thing exists. Unless you mean a printout
> of the database contents.

What is it about "Self Contained, Self Describing, Human Readable"
that you do not understand?

> > > In any case, permanency across more than two major database or other
> > > software releases is difficult, regardless of the format.

> > For unskilled labour, yes.

> Right. You show me how do convert VENUS chip designs into Synopsys
> without going into a museom for the original hardware and getting all
> the versions in between.

What does this have to do with "Self Contained, Self Describing, Human
Readable" files that can be read on any system past or present?
 
> > That is why vendor educated developers who
> > can not see passed their favourite commercial product should not be
> > asked for advice on this subject.

> Get some real world experience.

Wow. Not only a comedian, but also a master logician.
What a compelling argument, tell me, how much do you know about my
experience, and why do you feel that talking about _me_ is a response
to my argument?

> > If you have the source code, you are the developer,

> Wrong. I am the user, t.

Oh, well then I guess we have nothing further to discuss, my comments
here where meant for actual developers.

> > if you contract an
> > outside developer or licence an existing product, fine, as long as you
> > have perpetual access to the source code and the *right* to modify it,
> > or contract someone else to. If you do not, than you can not gaurantee
> > the permenance of your application.

> When will you get it, I don't *need* the right to modify it as long as I
> have the right to have it modified by the guys who wrote it in the first plac
> and are competent at it.
�
You have no such right, ever, the only right you _can_ have is the
right to modify it yourself or contract someone to do it. Please read
your licence.

Cheers.

quirk@syntac.net (Quirk) wrote in message news:<4e20d3f.0405070046.50c2d5dd@posting.google.com>...

> ... my point being that if you are using a
> commcial SQL server, such as Oracle, you should abstract your data
> access so that you can use something else instead down the road, you
> can do this with your own wrappers through elegent coding, or use a
> class such as PEAR::DB (for PHP), depending on what your application
> requirs.

Son, it sounds like you're the victim of some simplistic advise from
database 101 book:
1.  database portability is not (typically) as important as
application portability - since applications come & go far faster than
databases change, and some databases support multiple application
technologies (java + .net, php + python, etc).
2.  abstraction layers can often cause more complexity than they
solve, unless the project is fairly sizable
3.  the most powerful SQL capabilities are seldom supported in
abstraction layers - living without OLAP capabilities, for example,
means that you're limiting the usability & functionality of the
application.
4.  having said all that - yeah, go with portable sql as much as you
can, and only deviate if there's a value in doing so.  But don't work
yourself up into a religious hysteria about it.


> > > - If your data is really important to you, you will use network, not
> > > application or database level security to protect access to it.

Don't be a fool, implement security measures on each level.


> > > - Your primary datastore should be self contained, self describing and
> > > human readable, something like a heirarchy of XML files. This is the
> > > best way to ensure the perminancy and portabilty of your important
> > > data.

That's a damn funny idea - now exactly how do you plan to keep the
6000 tables from a SAP financial database for a fortune 100 updating a
hierarchy of XML tables?  You realize that the database is never
static, that performance & quality are already tough challenges
(without non-acid writes to XML files).  And you must also realize
that nobody will care about that detail of that data in 30 years,
right?  Oh yeah, and if you *really* want to archive it you'll keep it
on non-acid paper instead of in an electronic archive.  Now - getting
transactions to span a print-device - that would make for an
interesting little undergraduate project.

Here's the thing - you've got yourself a nice objective there, and I
encourage you to pursue it.  Just keep in mind that complex XML isn't
"human readable", that it doesn't contain sufficient business rules
and integrity constraints to be fully "self describing" either.  So,
ten years from now if you really wanted to read that data (and most
often you won't) you really won't have a clue what it means - due to
the massive loss of context.  Sure, you'll be better off than if you
had a file format you couldn't read at all - with XML you'll probably
be able to find a way of structuring the data (got help you if you
can't).  But you will still have  spent a lot of time & money on a
solution that'll fail you in the end.

So, you've got yourself a fine start on database technology.  Now, go
get yourself a job, keep these objectives in mind, and in a few years
discover the wisdom in what Yogi had to say:
"In theory there is no difference between theory and practice. In
practice there is."


Buck

"Dave" <shoad316@hotmail.com> wrote in message
news:78cf0572.0405070608.465cb083@posting.google.com...
> Daniel Morgan <damorgan@x.washington.edu> wrote in message
news:<1083705347.538046@yasure>...
> >
> > Care to disagree? Fine. Provide the names of 5 major commercial
> > installations of PostgreSQL.
>
> Here's a newsflash for alot of DBA's.   Most applications _do not_
> need a database as powerfull as Oracle.   Like it or not I would bet a
> few apps could get by with flat files.  (I'm half joking...)
>
> I've been a DBA for about 8 years and its rare for a company to use
> the advanced features of Oracle.  Advanced Queueing, Replication (in
> all its forms), RAC, flashback query, VPD, etc. etc.   In all honesty
> how often are these features used?   I worked in a dev. shop once
> where they were prepared to spend 6 months developing a feature that
> could easily be handled by Oracle.  Their reasoning was that they
> didn't want to get tied into a particular database.
>
> Now, i'm not a big fan of mysql... The gotchas link someone else
> posted in this thread says it all but I think postgresql is a good for
> small-mid sized apps.  It has alot of features that mysql is missing.
> Now, would I use it for my production financials system?  Ummm no, but
> I would use it for the corporate employee timesheet system.   For
> critical applications I wouldn't hesitate to recommend Oracle, in some
> cases maybe even SQLServer but there is room for opensource databases.


As Dave here said, most of the application around don't need more than what
PostgreSQL or MySQL gives.
MySQL as i see it has a better future, and i wouldn't bet on an application
with unknown future.
It sounds the same way microsoft staff talks about linux... (or ignore
it...)
Linux is open source and google runs on it.
so fucking what?
Wonder why would a tiny company like SAP would be interested in MySQL
engine?
follow up :
http://www.oreillynet.com/pub/wlg/4715

In article <4e20d3f.0405070707.96af5a2@posting.google.com>,
	quirk@syntac.net (Quirk) writes:
> "Volker Hetzer" <volker.hetzer@ieee.org> wrote in message news:<c7fl8s$bjo$1@nntp.fujitsu-siemens.com>...
> 
>> "Quirk" <quirk@syntac.net> schrieb im Newsbeitrag news:4e20d3f.0405070046.50c2d5dd@posting.google.com...

[stuff snipped]

>> > if you contract an
>> > outside developer or licence an existing product, fine, as long as you
>> > have perpetual access to the source code and the *right* to modify it,
>> > or contract someone else to. If you do not, than you can not gaurantee
>> > the permenance of your application.
> 
>> When will you get it, I don't *need* the right to modify it as long as I
>> have the right to have it modified by the guys who wrote it in the first plac
>> and are competent at it.
> �
> You have no such right, ever, the only right you _can_ have is the
> right to modify it yourself or contract someone to do it. Please read
> your licence.


Got a news flash for ya...

If you have a maintenance contract with a vendor and something of
theirs' is broken, they must fix it if you need it.  I know this
because it happend to us recently at work.  We found something broken
it a version of a prticular commercial RDBMS that had been fixed in a
later release, but due to customer requirements we cannot yet upgrade
to that version (i.e., the customer is unwilling to pay for it at this
time).  The vendor didn't want to fix it but because the customer is
paying them beaucoup bucks for a maintance contract we demanded that
they do so.  They did and supplied us with the necessary patch.

The only way you can get that kind of support is with a maintance
contract.  With Open Source we'd have had to spend many extra
man-hours trying to find where the problem was and how to fix it
without breaking anything else.  And we didn't hace the time to fool
with such nonsense as this occurred in a production application that
had to be up 24x7x365.


-- 
Ed. Hillman
Signature?!?  I don't need no stinking signature!!

Daniel Morgan wrote:

 ... otherwise stop promoting freeware
> as though it was worth more than its price.

Your true colors are showing, especially when I see all the newsgroups this is
crossposted to.  Shill be gone!

Matt O.

Matt O'Toole wrote:
> Daniel Morgan wrote:
> 
>  ... otherwise stop promoting freeware
> 
>>as though it was worth more than its price.
> 
> 
> Your true colors are showing, especially when I see all the newsgroups this is
> crossposted to.  Shill be gone!
> 
> Matt O.

I didn't start this thread. So if you wish to shoot the source.
Improve your aim.

And ... BTW ... learn the meaning of words before you use them.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

In article <v4EukoG8k$lAFwkJ@[127.0.0.1]>,
Five Cats  <cats_spam@uk2.net> wrote:

>Can you do a snapshot backup whilst using PostgreSQL

yes

"Mookstah" <dont_spam_my@mailbox.com> wrote in message news:<409bb687$1@news.bezeqint.net>...

> As Dave here said, most of the application around don't need more than what
> PostgreSQL or MySQL gives.
> MySQL as i see it has a better future, and i wouldn't bet on an application
> with unknown future.

Ah, the typical small database might be easily handled by either of
the above.  However, I still wouldn't recommend MySQL: portability
between mysql & any other database is hampered by their non-ansi sql,
their lack of basic sql features results in bizarre application code,
and their amazing exception handling problems means that quality
errors should be considered the norm - not the exception.

And yeah - it does have a pretty bright future.  But by the time they
completely rewrite the engine to handle basic sql, transactions, etc -
it'll be a completely different product.

buck

Daniel Morgan <damorgan@x.washington.edu> wrote in message 

> Equally arrogant? No! They'd be absolutely correct. The fact that the
> majority of anything, anywhere, is dumb is not going to surprise anyone,
> anywhere, at any time.
> That doesn't mean that the minority doesn't do a damned good job of
> keeping things running. You have looked at a set of indisputable facts
> and drawn a totally erroneous conclusion.

The 'arrogant' I was referring to was your statement "I could easily
beat Indians at their own game". What game are you talking about,
given
the context. The only 'game' I am aware of is the low cost of Indians
(that is those who are in India, not in North America). I am not sure
how an american like you can beat Indians in the cost game. 

> I wouldn't even attempt to compete with the Indians, or the Chinese, or
> the Russians, or even the Australians in their area of competence. That
> doesn't mean they are competent at all things in all places.

can't attempt or just can't :-) Given the myopic tendency of
american companies to cut cost, I don't see how you can ever compete
with
indians on cost. On second thoughts, I can wait for your reply and
learn something. I also live here and all this  outsourcing will
effect me as
much as you.

> You seem to leap from small facts to large conclusions with little
> critical thinking in between.

Thanks for the homely. Now what should I learn about facts from you:-

"we moved an application from SQL Server to oracle and the performance
improved without any tuning to 10x". (there is not a single bench mark
which proves it).

"Microsoft is using Oracle for its SAP implementation".
(despite denial by Microsoft employees).

Quirk (quirk@syntac.net) writes:
> You can always write bad code, my point being that if you are using a
> commcial SQL server, such as Oracle, you should abstract your data
> access so that you can use something else instead down the road, you
> can do this with your own wrappers through elegent coding, or use a
> class such as PEAR::DB (for PHP), depending on what your application
> requirs. Efficiency is very relative, eficiency of what? Code
> Executution? Application Extension? Interoperability? Tip: The first
> is not always the most important.

This may sound good in theory. Real life is different.

One should keep in mind that few tools are so extremely powerful to make
things go really slow as database engines.

There are of course applications where portability is a requirement. I 
once had contact with a small company who authored a system for producing
financial reports for big corporations. Their philosophy was that they
could not mandate which engine to use, so they aimed at portability. I
guess that was a fairly small system.

The system that I work with now runs only on RBDMS: MS SQL Server. This is
a business-critical system for our customers, and if I had support multiple
platforms, I would not be able to give our customers acceptable performance,
nor acceptable functionality. At least not to acceptable prices.

A competitor of ours were working on a replacement for their current
system - which dates from the end of the 1980s - and they worked just
along the line they suggested. Their owners poured in around 250
million SEK into that work, and the system is far from completed. That 
competitor recently fired about 80% of their staff, and that new
system will never be completed.


-- 
Erland Sommarskog, SQL Server MVP, sommar@algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp

rkusenet wrote:

> Daniel Morgan <damorgan@x.washington.edu> wrote in message 
> 
> 
>>Equally arrogant? No! They'd be absolutely correct. The fact that the
>>majority of anything, anywhere, is dumb is not going to surprise anyone,
>>anywhere, at any time.
>>That doesn't mean that the minority doesn't do a damned good job of
>>keeping things running. You have looked at a set of indisputable facts
>>and drawn a totally erroneous conclusion.
> 
> 
> The 'arrogant' I was referring to was your statement "I could easily
> beat Indians at their own game". What game are you talking about,
> given
> the context. 

You critize my statement and then, after the fact, ask me "what am I 
talking about"?

SELECT *
FROM user$
WHERE clue IS NOT NULL;

Next time ask for clarification BEFORE offering an opinion.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

bucknuggets@yahoo.com (Buck Nuggets) wrote in message news:<66a61715.0405070916.4b3945b0@posting.google.com>...
> quirk@syntac.net (Quirk) wrote in message news:<4e20d3f.0405070046.50c2d5dd@posting.google.com>...

> > ... my point being that if you are using a
> > commcial SQL server, such as Oracle, you should abstract your data
> > access so that you can use something else instead down the road, you
> > can do this with your own wrappers through elegent coding, or use a
> > class such as PEAR::DB (for PHP), depending on what your application
> > requirs.

> Son, it sounds like you're the victim of some simplistic advise from
> database 101 book:

Ok Dad, it sounds like you're the victim of the patronizing ass school
of discourse. My condolences to your coleagues.

> 1.  database portability is not (typically) as important as
> application portability - since applications come & go far faster than
> databases change, and some databases support multiple application
> technologies (java + .net, php + python, etc).

Both are important, which is more important depends on the data and
the application, in both cases my advice to either rely on open
standrads or abastract access when possible holds true.

> 2.  abstraction layers can often cause more complexity than they
> solve, unless the project is fairly sizable

I agree, when you have the perpetual right to the database and It's
source code, but if you are using a proprierty database then not using
an abstaction layer is folly, unless the project is so small that the
code is disposable.

Abstracting your data access can be as simple as writing a function to
use as a wrapper OR as complex as a full blown data access object,
depending on the application.

> 3.  the most powerful SQL capabilities are seldom supported in
> abstraction layers - living without OLAP capabilities, for example,
> means that you're limiting the usability & functionality of the
> application.

I have no argument here, as so far this is true, but experience
prompts me to bring up two points: First is how often are 'powerful
SQL capabilitites' used to compensate for poor database design?
Second, how certain are you that Proprietary databases (in fact than
YOUR particular one) always have more features than Open Source (or
Competetive Alternatives) ones to justify engineering your application
so that you are dependant on it forever?

I know, the answer is 'depends', but I hope you see what I'm getting
at.

> 4.  having said all that - yeah, go with portable sql as much as you
> can, and only deviate if there's a value in doing so.  But don't work
> yourself up into a religious hysteria about it.

I agree, I never said anything different, the only time you *must*
abstract your data access is when your application and/or it's data
has a long expected life time and depends on a prorietary Database.

> > > > - If your data is really important to you, you will use network, not
> > > > application or database level security to protect access to it.
> 
> Don't be a fool, implement security measures on each level.

OK Mr. T.  I agree. What I was really argueing against where those
(like Volker) who think that Database security is a replacement for
network security, I'm trying to make it clear that network security is
more important, since databasy securite depends on it, although, yes
both are important.

> > > > - Your primary datastore should be self contained, self describing and
> > > > human readable, something like a heirarchy of XML files. This is the
> > > > best way to ensure the perminancy and portabilty of your important
> > > > data.

> That's a damn funny idea

I'm a funy guy, always good for a laugh or two.

>  - now exactly how do you plan to keep the
> 6000 tables from a SAP financial database for a fortune 100 updating a
> hierarchy of XML tables?

It was only an example, one that for some applications makes sense,
you can always randomly chose an example wher it does not make sence
but this, my silly friend, is what is know as a straw man.

I guess this would be a good time to mention that SAP has been working
closely with MySQL these days.

>  You realize that the database is never
> static, that performance & quality are already tough challenges
> (without non-acid writes to XML files).

Yes I do realize this, but don't let my understanding discourage you
from further random blather if it makes you feel smart.

>  And you must also realize
> that nobody will care about that detail of that data in 30 years,
> right?

To bad you didn't realize that I never suggested otherwise.

>  Oh yeah, and if you *really* want to archive it you'll keep it
> on non-acid paper instead of in an electronic archive.

Perhaps, but paper is not always superior to some sort of WORM
storage, provided you use an intellegent storage format, my main point
is that an imcomprehensible file system blob, readable only by a
deamon for wich you have no source code, is not such a format.

> Now - getting
> transactions to span a print-device - that would make for an
> interesting little undergraduate project.

I would consider redundant WORM devices instead.
 
> Here's the thing - you've got yourself a nice objective there, and I
> encourage you to pursue it.  Just keep in mind that complex XML isn't
> "human readable", that it doesn't contain sufficient business rules
> and integrity constraints to be fully "self describing" either.

Thanks for the XML tips.

Sheesh. Where were you when I was writing my Pull DOM to DOM parcer?

>  So,
> ten years from now if you really wanted to read that data (and most
> often you won't) you really won't have a clue what it means - due to
> the massive loss of context.  Sure, you'll be better off than if you
> had a file format you couldn't read at all - with XML you'll probably
> be able to find a way of structuring the data (got help you if you
> can't).  But you will still have  spent a lot of time & money on a
> solution that'll fail you in the end.

Ok so your argument amounts to that since any approach *MIGHT* fail, I
should recomend the aproach that *WILL* fail?

What the hell are you trying to say?
 
> So, you've got yourself a fine start on database technology.  Now, go
> get yourself a job, keep these objectives in mind, and in a few years
> discover the wisdom in what Yogi had to say:
> "In theory there is no difference between theory and practice. In
> practice there is."
�
If I happen to meet the unemployed, inexperience person you imagine
you are talking to, I'll tell him that the ignorant pompous ass says
hello.

Cheers.

edwardh@highstream.net (Edward Lloyd Hillman) wrote in message news:<109o67992jbs0c1@news.supernews.com>...

> > You have no such right, ever, the only right you _can_ have is the
> > right to modify it yourself or contract someone to do it. Please read
> > your licence.
> 
> 
> Got a news flash for ya...

Oh boy, it's Seseme Street News, OK Kermit, keep talking.
 
> If you have a maintenance contract with a vendor and something of
> theirs' is broken, they must fix it if you need it.

Perhaps, but when the product in question is proprietary you have no
recourse when they fail, because no one else has any right to modify
the source code.

When you have a right to the source code you can sign such a contarct
with any firm you like, and fire their ass and hire another when they
fail.

>  I know this
> because it happend to us recently at work.  We found something broken
> it a version of a prticular commercial RDBMS that had been fixed in a
> later release, but due to customer requirements we cannot yet upgrade
> to that version (i.e., the customer is unwilling to pay for it at this
> time).  The vendor didn't want to fix it but because the customer is
> paying them beaucoup bucks for a maintance contract we demanded that
> they do so.  They did and supplied us with the necessary patch.

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, which only
shows how vulnerable you where to begin with, 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. In anycase,
you were lucky the vendor did decide to support you, other folks in
the same situatuion have not been so lucky.
 
> The only way you can get that kind of support is with a maintance
> contract.  With Open Source we'd have had to spend many extra
> man-hours trying to find where the problem was and how to fix it
> without breaking anything else.

Why? You could have the exact same contarct with a vendor supporting
an open source product, or negotiate access to source for the vendors
product, the only difference being that you then have leverage. Or
failing that, your application could have been designed to to give you
alternatives,

You programmed yourself into a corner, and are now trying to use your
folly, which nearly cost you a customer, as a positive example.
Interesting.

It is people like you that warm the hearts of confidence men
everywhere.

>  And we didn't hace the time to fool
> with such nonsense as this occurred in a production application that
> had to be up 24x7x365.

But you put yourself in a position were you may have been unable you
support your own customer _AT_ALL_ except for the good graces of your
vendor. I pitty your customers if they really do expect to get
24x7x365 under such an arrangement.

Cheers.

Erland Sommarskog <sommar@algonet.se> wrote in message news:<Xns94E56CC9BDEYazorman@127.0.0.1>...
> Quirk (quirk@syntac.net) writes:

> The system that I work with now runs only on RBDMS: MS SQL Server. 

Well, I hope that the other readers of the thread now know enough to
never hire a company as stupid as yours.

I hope you one day learn how to write real software before your
unskilled labour is no longer needed in the industry.

Cheers.

Quirk wrote:

>>Son, it sounds like you're the victim of some simplistic advise from
>>database 101 book:
> 
> Ok Dad, it sounds like you're the victim of the patronizing ass school
> of discourse. My condolences to your coleagues.

Apparently you went to that school too ... and graduated with honors.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

"Quirk" <quirk@syntac.net> schrieb im Newsbeitrag news:4e20d3f.0405100025.fd32875@posting.google.com...
> edwardh@highstream.net (Edward Lloyd Hillman) wrote in message news:<109o67992jbs0c1@news.supernews.com>...
> 
> > > You have no such right, ever, the only right you _can_ have is the
> > > right to modify it yourself or contract someone to do it. Please read
> > > your licence.
> > 
> > 
> > Got a news flash for ya...
> 
> Oh boy, it's Seseme Street News, OK Kermit, keep talking.
>  
> > If you have a maintenance contract with a vendor and something of
> > theirs' is broken, they must fix it if you need it.
> 
> Perhaps, but when the product in question is proprietary you have no
> recourse when they fail, because no one else has any right to modify
> the source code.
I have, at most,  the right to sue them, at least, the right to cancel the
contract which hurts them way more than if I go to a postgres developer
and tell him I'm not interested any more. So, unlike open source developers,
they actually have an interest in doing something.

> 
> When you have a right to the source code you can sign such a contarct
> with any firm you like, and fire their ass and hire another when they
> fail.
But it doesn't make sense to use any other firm than the guys who wrote it.
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.

> 
> >  I know this
> > because it happend to us recently at work.  We found something broken
> > it a version of a prticular commercial RDBMS that had been fixed in a
> > later release, but due to customer requirements we cannot yet upgrade
> > to that version (i.e., the customer is unwilling to pay for it at this
> > time).  The vendor didn't want to fix it but because the customer is
> > paying them beaucoup bucks for a maintance contract we demanded that
> > they do so.  They did and supplied us with the necessary patch.
> 
> 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.

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

> 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.
Maybe, but in case of open source software they'd say 'Good luck
working into our source code, see you in two years'.

> > The only way you can get that kind of support is with a maintance
> > contract.  With Open Source we'd have had to spend many extra
> > man-hours trying to find where the problem was and how to fix it
> > without breaking anything else.
> 
> Why? You could have the exact same contarct with a vendor supporting
> an open source product,
Yes, but then it would cost like any other product, right?

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

> Or
> failing that, your application could have been designed to to give you
> alternatives,
Right. And the customer throws away years of experience with one db system
and pulls a finished, reliable and maintainable alternative installation out of the hat.
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?

> 
> You programmed yourself into a corner, and are now trying to use your
> folly, which nearly cost you a customer, as a positive example.
> Interesting.
> 
> It is people like you that warm the hearts of confidence men
> everywhere.
> 
> >  And we didn't hace the time to fool
> > with such nonsense as this occurred in a production application that
> > had to be up 24x7x365.
> 
> But you put yourself in a position were you may have been unable you
> support your own customer _AT_ALL_ except for the good graces of your
> vendor.
Why? He doesn't support the db. The db vendor does that. All he has to do is to
show that it's othe db's fault, at which point his customer's maintenance
contract with the db vendor kicks in. Normal business practice.

> I pitty your customers if they really do expect to get
> 24x7x365 under such an arrangement.
Oh, they do get it. Because it's in the contract, you know?

Greetings!
Volker

"Quirk" <quirk@syntac.net> schrieb im Newsbeitrag news:4e20d3f.0405070707.96af5a2@posting.google.com...
> "Volker Hetzer" <volker.hetzer@ieee.org> wrote in message news:<c7fl8s$bjo$1@nntp.fujitsu-siemens.com>...
> 
> > "Quirk" <quirk@syntac.net> schrieb im Newsbeitrag news:4e20d3f.0405070046.50c2d5dd@posting.google.com...
> 
> > > > That's not true. 
> 
> > > Yes it is.
> 
> > What was the value of this reply?
> 
> What was the value of yours? Or this latest one?
A question is not an answer.

> 
> > > > The main problem is not the right to the source code
> > > > but the right to get maintenance.
> > > 
> > > With out the right to modify the source code you can have no "right to
> > > maintenenence" as all rights are held by one vendor, exactly the sort
> > > of dependency I recomond avoiding.
> 
> > I do have the right to maintenance, because that's in the contract. Very 
> > simple.
> 
> Yes, you have the right to be overcharged for work that may or may not
> not suit your needs by only _one_ vendor, and no right to go elsewhere
> when they fail, ignore you outright, stop supporting your application
> or vanish from the face of the earth. Have you actually read your
> contract or software licence?
Of course. See the end of this posting.

> It only protects the vendor, not you.
I've read  the licence and done even more: I've used the software and tested the contract.
> 
> > > > The right to modify is a red herring.
> > > 
> > > Not if your application and the permenancy of your data is important.
> 
> > You didn't read my posting, right? 
> 
> You are one funny guy. Really. I'll bet you're the first guy in usenet
> to ever ask this question rhetoricly.
Nice way of avoiding an answer.

> 
> > I don't *want* to create my own development
> > team competing with the original one. I don't want to merge my change back 
> > into their code with every new release! I don't want to develop code and
> > then have them decide whether they condescend to incorporate it or not! I 
> > want the authors of the software to do the coding based on what I'm willing 
> > to pay for!
> 
> You are dependent on their licence
I'm dependent on the author's licence regardless of which database I use.
It's just that some licences give me the illusion of being able to do something
while mainly giving me in reality the ability to shoot myself in the foot or paying
someone else to shoot me in the foot.

> because you built your own
> application on top of a platform for which you have no source code,
Same question: Did you read what I wrote?
I don't care about the source code, I care about product and support
quality. And, since I am not the developer of the software, nor is anyone else,
apart from *the* developers, anyone else is going to make a worse job than
them. So, I get the best support when I'm paying them and no one else.

> and no right to modify, you then also have no leverage with the vendor
> of the orginal software.
> 
> You have no rights at all, wether or not you are willing to pay.
Read oracles licence some time. There it says very clearly what
you get if you enter a support agreement.

> 
> > Elegant coding... The holy grail of software engineering. Why am I 
> > spontaneusly reminded of http://www.dilbert.com/comics/dilbert/archive/
> > dilbert-20040417.html ?
> 
> I dunno, because you're culturaly issolated and have a poor
> imagination?
No, it's because the phrase "elegant coding" is just as empty.
Or as the phrase "the one true god" uttered by people of
different religions.

> 
> > For db computing, reducing server load is the important thing. 
> 
> No, it is not, in most cases CPU is not the most limited resource.
> 
> > Interoperability
> > typically means primitive, network/db intensive sql.
Yup. Which, in a well configured db is CPU load because
caching, indexing and db specific sql takes care of the i/o load.
Nevertheless, I concede, it *is* possible to have such a
horribly configured system that i/o load becomes an issue. It's also
possible to have a database that permits so few actions
that the dba can't do anything about a badly written app.
fortunately, oracle is different.

> 
> No, interoperability means abilty to integrate applications in a
> heterogeneus environment. It means standards and flexibilty.
So? What's more "standardised" about mysql's socket interface than
about oracles OCI or ESQL?

> 
> > > > If it's important it must not matter whether one tries to
> > > > access the data from a local or remote machine.
> 
> > > Interesting that you believe that this can not be accomblished with
> > > network security.
> 
> > Yes. Now you figure out why.
> 
> Because you don't know what you are doing maybe?
Wrong. Try again.

> Oh wait, you don't
> need to, after all, you have decided to pay a vendor to know for you,
> I remember now.
Right. The alternative is not paying anyone and trying to figuring out the
source code on my own, right? Or paying someone else who starts
from scratch too?

> 
> > > Yes, a securely configured database, protected by a secure network,
> > > the later being far more important!
> 
> > A network will alway have holes, simply because legitimate users
> > have to get through and legitimacy can change while they are in.
> > Therefore you protect the data where they are. In the db.
> 
> If your network has holes, then your database is insecure, because I
> can get right at the filesystem blobs, the reverse however is not
> true.
Care to elaborate? An insecure network does not mean that someone can
log on to the database server from anywhere but the console screwed onto
it. And securing the listener (in case of oracle) is part of the database
configuration.

> 
> > > What is it about "Self Contained, Self Describing, Human Readable"
> > > that you do not understand?
> 
> > The fact that you believe such a thing exists. Unless you mean a printout
> > of the database contents.
> 
> What is it about "Self Contained, Self Describing, Human Readable"
> that you do not understand?
See above.

> 
> > > > In any case, permanency across more than two major database or other
> > > > software releases is difficult, regardless of the format.
> 
> > > For unskilled labour, yes.
> 
> > Right. You show me how do convert VENUS chip designs into Synopsys
> > without going into a museom for the original hardware and getting all
> > the versions in between.
> 
> What does this have to do with "Self Contained, Self Describing, Human
> Readable" files that can be read on any system past or present?
It has to do with permanency. Try to read what you quote.

>  
> > > That is why vendor educated developers who
> > > can not see passed their favourite commercial product should not be
> > > asked for advice on this subject.
> 
> > Get some real world experience.
> 
> Wow. Not only a comedian, but also a master logician.
> What a compelling argument,
Thanks.

> tell me, how much do you know about my
> experience,
What your arguments tell me.

> and why do you feel that talking about _me_ is a response
> to my argument?
Because your argument isn't backed by anything. Give me some
substance and we can talk about it. All I've hear so far is the
usual open source rethoric about me or someone else being able
to magically support a product in a few days or weeks after the
original developers have abandoned it, or me.

> 
> > > If you have the source code, you are the developer,
> 
> > Wrong. I am the user, t.
> 
> Oh, well then I guess we have nothing further to discuss, my comments
> here where meant for actual developers.
So, oracle people should further develop oracle and mysql people
mysql. Did I get this right?

> 
> > > if you contract an
> > > outside developer or licence an existing product, fine, as long as you
> > > have perpetual access to the source code and the *right* to modify it,
> > > or contract someone else to. If you do not, than you can not gaurantee
> > > the permenance of your application.
> 
> > When will you get it, I don't *need* the right to modify it as long as I
> > have the right to have it modified by the guys who wrote it in the first plac
> > and are competent at it.
> 
> You have no such right, ever, the only right you _can_ have is the
> right to modify it yourself or contract someone to do it. Please read
> your licence.
"Assistance with my SRs 24 hours per day, 7days a week". Practically I usually
get two or three guys working on a typical SR of mine, depending on how
log it takes. Without a contract I'd get a 'buzz off, I'm doing my exams this month'.

Volker

Bottom line, whem it comes to medium/large application/database or even
CRM./ERP... would MySQL/PostgreSQL have a problem to handle it?
I mean, when the code is set up right and the database structure design is
right.
an honest answer would be appreciated.


"Daniel Morgan" <damorgan@x.washington.edu> wrote in message
news:1084195499.492013@yasure...
> Quirk wrote:
>
> >>Son, it sounds like you're the victim of some simplistic advise from
> >>database 101 book:
> >
> > Ok Dad, it sounds like you're the victim of the patronizing ass school
> > of discourse. My condolences to your coleagues.
>
> Apparently you went to that school too ... and graduated with honors.
>
> -- 
> Daniel Morgan
> http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
> http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
> damorgan@x.washington.edu
> (replace 'x' with a 'u' to reply)
>

Quirk (quirk@syntac.net) writes:
> Erland Sommarskog <sommar@algonet.se> wrote in message 
news:<Xns94E56CC9BDEYazorman@127.0.0.1>...
>> Quirk (quirk@syntac.net) writes:
> 
>> The system that I work with now runs only on RBDMS: MS SQL Server. 
> 
> Well, I hope that the other readers of the thread now know enough to
> never hire a company as stupid as yours.
> 
> I hope you one day learn how to write real software before your
> unskilled labour is no longer needed in the industry.

Well, I have the guts to sign my articles with my real name. You haven't.
So you don't really have to consider whether what you say affects your 
possibilities on the market.

The product that my company manufactures is for a narrow segment on the
market: stock brokers and other actors on the financial markets, so most
readers would not have reason to contact us anyway.

Anyway, I only offered testimony from real life. As I said, a compeitor
of ours tried precisely what you teach. And that company never managed
to complete their system.

-- 
Erland Sommarskog, SQL Server MVP, sommar@algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp

"Mookstah" <dont_spam_my@mailbox.com> wrote in message news:<409fb8f1$1@news.bezeqint.net>...
> Bottom line, whem it comes to medium/large application/database or even
> CRM./ERP... would MySQL/PostgreSQL have a problem to handle it?
> I mean, when the code is set up right and the database structure design is
> right.
> an honest answer would be appreciated.

Could it do it?  yes, it certainly could.  But there's a huge gulf
between could & should.  Just like - you shouldn't haul firewood in a
car, but I sure as hell knew a guy who did it in his AMC Pacer.

Would I do it?  No.  By the time you price out an ERP solution for a
large company (say a SAP implementation at $20 million, or a Siebel
solution at $6k / desktop) - the cost of database licensing is
inconsequential - especially when related to the risks associated with
a project failure.  In other words - don't let a $20m project fail
because you tried to shave $200k off the database price. And why is
the risk greater for these open source databases?  Not a problem with
open source, just maturity.

Postgresql is a good DBMS, but still lacks quite a few features that
are really useful in the large-scale ERP/CRM world.  The lack of major
BI capabilities like partitioning, parallelism, etc as well as more
robust admin tools is really risky when it comes to the big apps.

MySQL is missing more features - and is developed by a vendor that
continuously downplays ANSI SQL standards, basic early-80s database
features, etc.  They've played up their performance figures, but
seldom on significant hardware in a mixed-write environment with
transactions (only supported on the third-party product Innodb. 
Worse, the way that MySQL fails to alert the user of exceptions
drastically increases the likelihood of undetected data corruption. 
Lastly, its lack of so many basic features means that application
level code has to be significantly changed in order to port from any
other significant database to mysql.  On the other hand, they've got a
lot of users, so they'll probably eventually get everything rewritten
and have something reasonable to show.

You asked about large complex databases, and the above comments are my
opinion on applying open source databases to that challenge today.  On
the other hand, I'd say that there a ton of other potential ways to
use these databases in the enterprise successfully.

These days I'm recommending postgresql for some little database
projects we've got.  It's easy to develop on, easy to maintain, can
handle millions of rows, and is easy to port to the in-house
commercial database we use here if that becomes necessary (usually due
to administrative/management reasons rather than performance).  On the
other hand, I wouldn't implement a MySQL database unless it was the
only option with the product.  Just isn't worth the headaches.

BTW, didn't mention Firebird - I've heard that it was a decent
database, and isn't very expensive at all.

Mookstah wrote:
> Bottom line, whem it comes to medium/large application/database or even
> CRM./ERP... would MySQL/PostgreSQL have a problem to handle it?
> I mean, when the code is set up right and the database structure design is
> right.
> an honest answer would be appreciated.

Probably. But only right up until it crashed or some cracker tried
to break in. Then it would likely be both as fragile and as transparent
as a sheet of glass.

Does anyone really believe that if SAP and PeopleSoft could make as
much or more money writing their products to work against these
products they wouldn't? Does anyone really believe that CFOs and CIOs,
looking at their budgets, wouldn't be running to these products en-mass?

I am a strong supporter of the open-source community. I have and will
continue to advocate management dump MS Office for OpenOffice. But I
would never risk any organization's data, read that business assets,
and I can't think of too many others in my position that would.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

"Volker Hetzer" <volker.hetzer@ieee.org> wrote in message news:<c7o8i3$3bk$1@nntp.fujitsu-siemens.com>...

> > > > > That's not true. 
>  
> > > > Yes it is.
>  
> > > What was the value of this reply?
> > 
> > What was the value of yours? Or this latest one?
> A question is not an answer.

And what was your reply?

> > Yes, you have the right to be overcharged for work that may or may not
> > not suit your needs by only _one_ vendor, and no right to go elsewhere
> > when they fail, ignore you outright, stop supporting your application
> > or vanish from the face of the earth. Have you actually read your
> > contract or software licence?
> Of course. See the end of this posting.

> > It only protects the vendor, not you.
>  I've read  the licence and done even more: I've used the software and tested the contract.

Realy, care to quote the part of the Contract that Gaurantees you any
rights?

Instead, what you will find is that the contracts insists that the
Software is not gauranteed to be usefull for any particilar purpose,
and that they deny all responsibilitty for it to the extent possible
by law.

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.

Have you tested alternatives?

> > > > > The right to modify is a red herring.
> > > > 
> > > > Not if your application and the permenancy of your data is important.
>  
> > > You didn't read my posting, right? 
> > 
> > You are one funny guy. Really. I'll bet you're the first guy in usenet
> > to ever ask this question rhetoricly.

> Nice way of avoiding an answer.

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?

> > > I don't *want* to create my own development
> > > team competing with the original one. I don't want to merge my change back 
> > > into their code with every new release! I don't want to develop code and
> > > then have them decide whether they condescend to incorporate it or not! I 
> > > want the authors of the software to do the coding based on what I'm willing 
> > > to pay for!
> > 
> > You are dependent on their licence

> I'm dependent on the author's licence regardless of which database I use.

Yes, which is why you should choose one that give you a perpetual
right to the source code, otherwise you are locked into a dependancy
that may prove fatal to your application.

> It's just that some licences give me the illusion of being able to do 
> something while mainly giving me in reality the ability to shoot myself in 
> the foot or paying someone else to shoot me in the foot.

Unsubstantiated bunk, if you have the source code, it is not magic to
fix it, or extend it, just normal progamming. 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.

> > because you built your own
> > application on top of a platform for which you have no source code,

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

> I don't care about the source code, I care about product and support
> quality. And, since I am not the developer of the software, nor is anyone else,
> apart from *the* developers,

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.

> anyone else is going to make a worse job than
> them. So, I get the best support when I'm paying them and no one else.

More unsubstantiated bunk, first of all, in many cases you can hire
the original developers, 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.

And finaly, it is a falalcy to say that someone will do a worse job
simply because they are not the original developer.
 
> > and no right to modify, you then also have no leverage with the vendor
> > of the orginal software.
> > 
> > You have no rights at all, wether or not you are willing to pay.
> Read oracles licence some time. There it says very clearly what
> you get if you enter a support agreement.

But it stops short of guaranting that your apllication will actualy
work, or that your existing version of the software will be supported.

In anycase, I am not arguing agianst using Oracle, as I said, if
Oracle suits your needs and you think it's worth the money, use it,
however, my advice is that if you do develop an application, write
your code in such a way that you do not depend on Oracle, but can
easily switch it over the the greatest extent possible.

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.

> > I dunno, because you're culturaly issolated and have a poor
> > imagination?

> No, it's because the phrase "elegant coding" is just as empty.
> Or as the phrase "the one true god" uttered by people of
> different religions.

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.

> > > For db computing, reducing server load is the important thing. 
> > 
> > No, it is not, in most cases CPU is not the most limited resource.
> > 
> > > Interoperability
> > > typically means primitive, network/db intensive sql.
> Yup. Which, in a well configured db is CPU load because
> caching, indexing and db specific sql takes care of the i/o load.

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

> Nevertheless, I concede, it *is* possible to have such a
> horribly configured system that i/o load becomes an issue. It's also
> possible to have a database that permits so few actions
> that the dba can't do anything about a badly written app.
> fortunately, oracle is different.
 
> > No, interoperability means abilty to integrate applications in a
> > heterogeneus environment. It means standards and flexibilty.
> So? What's more "standardised" about mysql's socket interface than
> about oracles OCI or ESQL?

Are you having a nightmare in which we are dicussing the various
merits of MySQL versus Oracle? Please follow your own advice and read
this thread again so that you might figure out what is it we are
actually taking about.

> > > > > If it's important it must not matter whether one tries to
> > > > > access the data from a local or remote machine.
>  
> > > > Interesting that you believe that this can not be accomblished with
> > > > network security.
>  
> > > Yes. Now you figure out why.
> > 
> > Because you don't know what you are doing maybe?

> Wrong. Try again.

The more you talk, the clearer it is how right I was.

> > Oh wait, you don't
> > need to, after all, you have decided to pay a vendor to know for you,
> > I remember now.
> Right. The alternative is not paying anyone and trying to figuring out the
> source code on my own, right? Or paying someone else who starts
> from scratch too?

More straw men and red herrings. If you are a Developer, which is who
my comments are addressed to, it is your responsiblilty to your users
and clients to know how your application works and to be able to
support it without allowing some third party to hold them hostage.

> > > > Yes, a securely configured database, protected by a secure network,
> > > > the later being far more important!
>  
> > > A network will alway have holes, simply because legitimate users
> > > have to get through and legitimacy can change while they are in.
> > > Therefore you protect the data where they are. In the db.
> > 
> > If your network has holes, then your database is insecure, because I
> > can get right at the filesystem blobs, the reverse however is not
> > true.

> Care to elaborate? An insecure network does not mean that someone can
> log on to the database server from anywhere but the console screwed onto
> it. And securing the listener (in case of oracle) is part of the database
> configuration.

If the above is true, that someone can only access any of the devices
on your Database server via the local console, then your network *IS*
secure (perhaps too secure, but that's beside the point), However, if
your network is not secure, then that is not true, and your Database
security is a dangerous false sence of security.

This is what I'm trying to say, that network security comes first,
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.

Once again, It must be assumed that your consternations to contend
this point are some weird form of self-flagilation.

> > > Right. You show me how do convert VENUS chip designs into Synopsys
> > > without going into a museom for the original hardware and getting all
> > > the versions in between.
> > 
> > What does this have to do with "Self Contained, Self Describing, Human
> > Readable" files that can be read on any system past or present?

> It has to do with permanency. Try to read what you quote.

What does reading text files have to do with Chip design? 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).

Try to avoid making an ass of yourself with further pretentions.

> > tell me, how much do you know about my
> > experience,

> What your arguments tell me.

Which ones? That abstracting access to suspect dependencies is a good
idea? That database security is secondary to network security? That
one should keep archives in a format that is likely to be readable
forever?

All these things come from experience, your attempt to question my
experience, only show that you are unable to formalute an actual
argument, so you try and discredit the arguer instead of the argument.

> > and why do you feel that talking about _me_ is a response
> > to my argument?

> Because your argument isn't backed by anything. Give me some
> substance and we can talk about it.

Oh please, my argument has been presented well enough, attacking me
just shows you can not defend your own, that is if you actually had
one.

If my argument was not backed up by anything it would easy enough to
refute it without attempting to insult me, you started with the
insulting precicely because you could not defeat my arguments.

But please, don't take this as discourgement from continuing to try
your silly insults, I don't mind being given the oportunity to
embarrass you personaly as well as refute your arguments, but it is
hard for me to understand why would chose to subject yourself to such,
as one would think it would more pleasent for you to simple lose a
respectfull debate, rather than lose a debate and a battle of wit at
the same time.

> All I've hear so far is the
> usual open source rethoric about me or someone else being able
> to magically support a product in a few days or weeks after the
> original developers have abandoned it, or me.

These must be voices in your head that you are hearing. Since my
argument have been quite clear and even sumerized several times.

Your arguments amount to the metaphysical belief that only the
copyright holders of your favourite proporiety software know how to
program, that the very concept of good programming is an illussion,
and therfore the only way forward is to make yourself both tehnicaly
and legaly dependent on them as much as possible.

> > > > If you have the source code, you are the developer,
>  
> > > Wrong. I am the user, t.
> > 
> > Oh, well then I guess we have nothing further to discuss, my comments
> > here where meant for actual developers.

> So, oracle people should further develop oracle and mysql people
> mysql. Did I get this right?

No, that's not right, that's not even wrong.

(with applogies to Wolfgang Pauli)

Application developers should avoid locking themselves in to external
dependencies, either by not using products to which they have no right
to the source code, or abstracting access when they do use such
products. Simple.

And having right to the source code does not mean that the program is
'open source,' as you can purchace such a right for propretary code,
as is common for libraries.

Of course, when the program _is_ open source, you are guaranteed that
right.

> > You have no such right, ever, the only right you _can_ have is the
> > right to modify it yourself or contract someone to do it. Please read
> > your licence.

> "Assistance with my SRs 24 hours per day, 7days a week". Practically I 
> usually get two or three guys working on a typical SR of mine, depending on
> how log it takes. Without a contract I'd get a 'buzz off, I'm doing my exams > this month'.

"Assitance" only means that they will provide someone whose time they
can bill you for, not that anything will be accomplished. And you
discredit yourself by attemping the fallacy that the only way to have
access to an applications source code is to hire some one who is doing
exams. Many large companies, and profesional develpoers provide source
licences and/or support open source products, including the largest
computer company in the world, IBM.

Cheers.

"Volker Hetzer" <volker.hetzer@ieee.org> wrote in message news:<c7o7il$u0k$1@nntp.fujitsu-siemens.com>...

> "Quirk" <quirk@syntac.net> schrieb im Newsbeitrag news:4e20d3f.0405100025.fd32875@posting.google.com...
> > edwardh@highstream.net (Edward Lloyd Hillman) wrote in message news:<109o67992jbs0c1@news.supernews.com>...
> > 
> > > > You have no such right, ever, the only right you _can_ have is the
> > > > right to modify it yourself or contract someone to do it. Please read
> > > > your licence.
> > > 
> > > 
> > > Got a news flash for ya...
> > 
> > Oh boy, it's Seseme Street News, OK Kermit, keep talking.
> >  
> > > If you have a maintenance contract with a vendor and something of
> > > theirs' is broken, they must fix it if you need it.
> > 
> > Perhaps, but when the product in question is proprietary you have no
> > recourse when they fail, because no one else has any right to modify
> > the source code.

> I have, at most,  the right to sue them,

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.

Good luck in your legal adventures. I prefer to solve my problems by
programming. (my users and clients seem to prefer this too)

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

> than if I go to a postgres developer
> and tell him I'm not interested any more. So, unlike open source developers,
> they actually have an interest in doing something.

What on earth are you trying to say here? Why is a postgresql
developer any more or less interested in your contarct than one who
pedals proprietary software?

> > When you have a right to the source code you can sign such a contarct
> > with any firm you like, and fire their ass and hire another when they
> > fail.
> But it doesn't make sense to use any other firm than the guys who wrote it.

Why? What magic powers are possesed by the firm that holds the
copyright? Expcet the power to prevent anyone else from touching or
looking at their code?

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

By the way, I am _not_ arguing that one must do everything
themeselves, only that one should not get locked into being dependant
on a single provide.

As I'v said, I'm baffled that this is so controversial that you all
expect me to defend my good name merely for saying it.

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

> 
> > 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 there is no such requirement, you can not really force an
unwilling vendor to do work that do not want to do. If you think you
can, you are delusional. If you have enought legal might, you may be
able to get a refund, usualy limited to the whatever you originaly
paid, not compensating you for you own ivestment.

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

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

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

> > > The only way you can get that kind of support is with a maintance
> > > contract.  With Open Source we'd have had to spend many extra
> > > man-hours trying to find where the problem was and how to fix it
> > > without breaking anything else.
> > 
> > Why? You could have the exact same contarct with a vendor supporting
> > an open source product,

> Yes, but then it would cost like any other product, right?

Yes, developing applications costs money, it is this investment I am
advising people to protect by not getting locked into third party
dependencies.

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

> > Or
> > failing that, your application could have been designed to to give you
> > alternatives,

> Right. And the customer throws away years of experience with one db system
> and pulls a finished, reliable and maintainable alternative installation out
> of the hat.

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.

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

> > But you put yourself in a position were you may have been unable you
> > support your own customer _AT_ALL_ except for the good graces of your
> > vendor.

> Why? He doesn't support the db. The db vendor does that. All he has to do is > to show that it's othe db's fault, at which point his customer's maintenance
> contract with the db vendor kicks in. Normal business practice.

Yes, passing the buck is unfortunalty the normal business practice,
however good firms neither do it or put up with 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.

BTW, this latest response is much better in tone than your last one, I
hope this is a trend.

Cheers.



�

"Mookstah" <dont_spam_my@mailbox.com> wrote in message news:<409fb8f1$1@news.bezeqint.net>...
> Bottom line, whem it comes to medium/large application/database or even
> CRM./ERP... would MySQL/PostgreSQL have a problem to handle it?

The unfortunate answer is 'depends,' on one hand SAP has been working
quite closely recently with MySQL AG, and PostegreSQL has some of the
smartest people in the industry helping to develop it, and there are
many medium/large applications that run very well on both.

However, both, like all software, do have their deficiencies, and
there is no question that comercial products, Oracle in particular,
has functionality that
neither offer.

The answer must be made on a case by case basis, after thourough
design and analysis.

The best advice you can heed is that your application should be
programmed in such a way that it is not dependant on any external
dependancy for wich you do not have source code. Either by only using
products for which you do have source code, or abstracting access when
you do not, and that your data should be archived in such a way that
you will never lose access to it.

> I mean, when the code is set up right and the database structure design is
> right.
> an honest answer would be appreciated.

The honest answer is that open source is better in most, but not all
cases.

Cheers.

Daniel Morgan <damorgan@x.washington.edu> wrote in message news:<1084195499.492013@yasure>...
> Quirk wrote:
> 
> >>Son, it sounds like you're the victim of some simplistic advise from
> >>database 101 book:
> > 
> > Ok Dad, it sounds like you're the victim of the patronizing ass school
> > of discourse. My condolences to your coleagues.
> 
> Apparently you went to that school too ... and graduated with honors.

Yup. That's actualy an understatement. Those who insist on playing
dozens with me should take warning, I admit, I do relish the game, in
fact, I even know it's history and cultral signifigance, from the
slave communites to modern hip hop, with a healthy study of the art of
controversy and the logical fallicies to boot.

However, I am just as happy to engage in respectful discusion, as
anyone can see, but when someone starts a discusion by calling me
'son' you must admit that he had it comming. And I was rather mild I
think.

Also note that I responded to all his actual arguments clearly and
reasonably.

Cheers.

Erland Sommarskog <sommar@algonet.se> wrote in message news:<Xns94E5F1AA3FB9BYazorman@127.0.0.1>...

> > I hope you one day learn how to write real software before your
> > unskilled labour is no longer needed in the industry.
> 
> Well, I have the guts to sign my articles with my real name.

My name is Dmytri Kleiner, you could have easily found that out with a
simple search on any known search engine. I am possibly one of the
easiest people in the world to find.

> The product that my company manufactures is for a narrow segment on the
> market: stock brokers and other actors on the financial markets, so most
> readers would not have reason to contact us anyway.

Good thing that you only mislead a few customers into overpaying for
crap. Your company is just a bankruptcy waiting for a competent
competitor to make it happen.

> Anyway, I only offered testimony from real life.

Yeah, you and Kaspar Hauser.

> As I said, a compeitor
> of ours tried precisely what you teach.
> And that company never managed
> to complete their system.

What bunk, saying the competitor tried 'precicely what I teach' and
thus failed is an obvious attempt to fallaciously discredit my
argument with out actually addressing it. You're a ham fisted shill.

It's is as obvious that this competitor is unlikely to have 'tried
precisely what I teach' as it is that you have not shown us that this,
and not another reason, was why they failed.

bucknuggets@yahoo.com (Buck Nuggets) wrote in message news:<66a61715.0405101439.8b3ada0@posting.google.com>...

> Would I do it?  No.  By the time you price out an ERP solution for a
> large company (say a SAP implementation at $20 million, or a Siebel
> solution at $6k / desktop) - the cost of database licensing is
> inconsequential - especially when related to the risks associated with
> a project failure.  In other words - don't let a $20m project fail
> because you tried to shave $200k off the database price. And why is
> the risk greater for these open source databases?  Not a problem with
> open source, just maturity.

This is good advice.

But, of course, not all database projects are $20 million projects, in
fact most are not.

What I find surprising is that so many companies *will* spend so much
money and wind up without the right to modify the source code of the
applications they paid for, I don't mean only using open source, or
having the right to distribute their modifications, I mean //not
having the right to fix their own multi million dollar production
application// whithout the good graces of the original vendor.

From a business point of view this is lunacy. Anybody in supply chain
management will warn you of the dangers of a //single source//. In
almost every
case executives in charge of insuring a critical supply will force any
provider to sign agreements with third parties, or allow the client to
contract third partes. For instance, almost the entire PC business can
be attributed to IBM forcing these kinds of agreements on their
suppliers, including Intel. I have no idea why CIOs have so little
understanding of this that they are frequently hoodwinked into single
source situations regarding the supply of //support// for their
critical applications.

Whatever you do, make sure you have as much source code for your
production application as you can�get, and when you can not get it,
abstract the interfaces so it is as easy to change down the road as
much possible (and of course practical).

And, perhaps most importantly, make sure you can get at your data, at
least for archive purposes, without *any* access method for which you
have no source code.

Bucks is however correct his description of the limitations of the
open source SQL servers, however it is anything but impossible to live
with these limitations, just as it is anything but impossible to get
screwed (not to mention robbed) by a closed source provider.

Cheers.

Dmytri Kleiner (quirk@syntac.net) writes:
> Good thing that you only mislead a few customers into overpaying for
> crap. Your company is just a bankruptcy waiting for a competent
> competitor to make it happen.

Our customers seems to be quite satisfied with our system.

And - in difference to you - they actually know the system in question,
so I think they are somewhat better apt to tell whether it is crap or
not.
 
> What bunk, saying the competitor tried 'precicely what I teach' and
> thus failed is an obvious attempt to fallaciously discredit my
> argument with out actually addressing it. You're a ham fisted shill.

I think that I made it quite clear in my first post that your suggested
strategy indeed may be very valid sometimes. But what I've been pointing
out is that this far from always the case. 

Doing the sort of abstraction you suggested is *very* expensive, and
for small companies like ours or our competitor, this a huge enterprise
to take on for systems with over 500 tables and over 3500 stored procedures.
(That data is for our system; Obviously I don't have the data for our
competitor's system, but I do know the business they were targeting.)

-- 
Erland Sommarskog, SQL Server MVP, sommar@algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp

Erland Sommarskog <sommar@algonet.se> wrote in message news:<Xns94E6F1BC7C070Yazorman@127.0.0.1>...
> Dmytri Kleiner (quirk@syntac.net) writes:

> > Good thing that you only mislead a few customers into overpaying for
> > crap. Your company is just a bankruptcy waiting for a competent
> > competitor to make it happen.

> Our customers seems to be quite satisfied with our system.
> 
> And - in difference to you - they actually know the system in question,
> so I think they are somewhat better apt to tell whether it is crap or
> not.

The Application that you wrote I have no reason to doubt is of
sufficient quality to keep your customers satisfied.

Unfortunately you have created unneeded dependencies for them, the
worst of which is not MS SQL, since it is fairly easy to get at data
in MS SQL and archive it or export it in a usefull way, the worst is
that you have tied your customers to a terrible Operating System with
a terrible licence, even Oracle users are not so screwed since at the
very least they have a choice when it comes to OS.

> > What bunk, saying the competitor tried 'precicely what I teach' and
> > thus failed is an obvious attempt to fallaciously discredit my
> > argument with out actually addressing it. You're a ham fisted shill.
> 
> I think that I made it quite clear in my first post that your suggested
> strategy indeed may be very valid sometimes. But what I've been pointing
> out is that this far from always the case. 

I would say you made it quite clear that your basic message was that
it would be folly to do what I was suggesting, and that was your whole
purpose in posting, as I said, I can tell this by the obvious
rhetorical devices you used, claiming this unnamed third party did
'precicely what I teach' a wretchedly unlikely and unqualified
generalisation, followed by saying that this, implying that this
_alone_, lead to the failure of their project. This is obvious FUD.
The lack of any other content, or even specifics in your post is the
final damning evidence. As I said, you are a shill, and a ham fisted
one at that.
 
> Doing the sort of abstraction you suggested is *very* expensive,

It is not, as I've said, it can be as simple as writing a wrapper
function around your data access.

Not as expensive as having the system itself obsoleted by an obsoleted
dependency or the inabilty to get support for a dependency due to a
licencing dispute.

But for you, this is probably useless advice, since no doubt not only
have you chosen a SQL server with a bad licence, and an OS with a bad
licence, but no doubt you have also choses a development platform with
a bad licence, let me guess: Visual Basic?

As I said, enjoy your solvency while it lasts.

> and
> for small companies like ours or our competitor, this a huge enterprise
> to take on for systems with over 500 tables and over 3500 stored procedures.
> (That data is for our system; Obviously I don't have the data for our
> competitor's system, but I do know the business they were targeting.)

All the more reason to protect your investment and that of your
customer by not getting trapped into becoming dependant on a third
party for the continued operation of their own system.

But it's pretty clear that encouraging such pitiable dependencies is
exactly what you are here to do.

Daniel Morgan <damorgan@x.washington.edu> wrote in message news:<1083695957.163784@yasure>...
> Sarah Tanembaum wrote:
> 
> > 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
> 
> PostgreSQL is highly overrated and not suitable for any environment
> where little things like crash recovery and security are a priority.

What database does Google use?

Steve

"Quirk" <quirk@syntac.net> schrieb im Newsbeitrag news:4e20d3f.0405110058.684e5968@posting.google.com...
> "Volker Hetzer" <volker.hetzer@ieee.org> wrote in message news:<c7o8i3$3bk$1@nntp.fujitsu-siemens.com>...
> 
> > > > > > That's not true. 
> >  
> > > > > Yes it is.
> >  
> > > > What was the value of this reply?
> > > 
> > > What was the value of yours? Or this latest one?
> > A question is not an answer.
> 
> And what was your reply?
I asked first.

> 
> > > Yes, you have the right to be overcharged for work that may or may not
> > > not suit your needs by only _one_ vendor, and no right to go elsewhere
> > > when they fail, ignore you outright, stop supporting your application
> > > or vanish from the face of the earth. Have you actually read your
> > > contract or software licence?
> > Of course. See the end of this posting.
> 
> > > It only protects the vendor, not you.
> >  I've read  the licence and done even more: I've used the software and tested the contract.
> 
> Realy, care to quote the part of the Contract that Gaurantees you any
> rights?
http://oracle.com/support/index.html?policies.html

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

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

> 
> > > > > > The right to modify is a red herring.
> > > > > 
> > > > > Not if your application and the permenancy of your data is important.
> >  
> > > > You didn't read my posting, right? 
> > > 
> > > You are one funny guy. Really. I'll bet you're the first guy in usenet
> > > to ever ask this question rhetoricly.
> 
> > Nice way of avoiding an answer.
> 
> 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.


> 
> > > > I don't *want* to create my own development
> > > > team competing with the original one. I don't want to merge my change back 
> > > > into their code with every new release! I don't want to develop code and
> > > > then have them decide whether they condescend to incorporate it or not! I 
> > > > want the authors of the software to do the coding based on what I'm willing 
> > > > to pay for!
> > > 
> > > You are dependent on their licence
> 
> > I'm dependent on the author's licence regardless of which database I use.
> 
> Yes, which is why you should choose one that give you a perpetual
> right to the source code, otherwise you are locked into a dependancy
> that may prove fatal to your application.
I start to repeat myself here. The right to the source code does not mean
anything useful, see the part you quoted below.

> 
> > It's just that some licences give me the illusion of being able to do 
> > something while mainly giving me in reality the ability to shoot myself in 
> > the foot or paying someone else to shoot me in the foot.
> 
> 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.

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

> 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. Convincing the customer to
install *my* database version is another, particularly if three or four
developers do this.

> 
> > > because you built your own
> > > application on top of a platform for which you have no source code,
> 
> > 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.
And if support doesn't work, I still won't support it on my own.

> 
> > I don't care about the source code, I care about product and support
> > quality. And, since I am not the developer of the software, nor is anyone else,
> > apart from *the* developers,
> 
> 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?

> 
> > anyone else is going to make a worse job than
> > them. So, I get the best support when I'm paying them and no one else.
> 
> 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.
And even if I buy some incident based support contract, there is still
no difference from an incident based support contract with oracle.
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.
But thanks for acknowleding that reliable support costs money.

> 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. Besides, remember, the company has an interest in providing
support because they live off it.

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

>  
> > > and no right to modify, you then also have no leverage with the vendor
> > > of the orginal software.
> > > 
> > > You have no rights at all, wether or not you are willing to pay.
> > Read oracles licence some time. There it says very clearly what
> > you get if you enter a support agreement.
> 
> 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. And they are dependent from me for my money.

> or that your existing version of the software will be supported.
They provide upgrades and desupport dates. Ok, they do
what I pay for.

> 
> In anycase, I am not arguing agianst using Oracle, as I said, if
> Oracle suits your needs and you think it's worth the money, use it,
> however, my advice is that if you do develop an application, write
> your code in such a way that you do not depend on Oracle, but can
> easily switch it over the the greatest extent possible.
Why "the greatest extent"? That costs me more time and money
and customers that it's worth. 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.

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

> 
> > > I dunno, because you're culturaly issolated and have a poor
> > > imagination?
> 
> > No, it's because the phrase "elegant coding" is just as empty.
> > Or as the phrase "the one true god" uttered by people of
> > different religions.
> 
> 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 "abstraction" and expect the rest
of the programmers to agree that that's it?
Thanks for solving that problem for the rest of the world.

> 
> > > > For db computing, reducing server load is the important thing. 
> > > 
> > > No, it is not, in most cases CPU is not the most limited resource.
> > > 
> > > > Interoperability
> > > > typically means primitive, network/db intensive sql.
> > Yup. Which, in a well configured db is CPU load because
> > caching, indexing and db specific sql takes care of the i/o load.
> 
> 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. This creates an excessive amoung of simple
queries and lots of network traffic. Right now we have huge problems
getting an application to work properly that claims to support mysql and
oracle. They could have done half the app in PL/SQL and saved 90%
of the network and client load.
Also, if the database is not the standard one (because you have
fixed/improved it) I have, at the worst, maintain two independent installations,
at best, two independent update cycles. 
Developers are constrained by (among other things) the load they are allowed
to put on the db. That's a business decision.
As for consulting, we pay a flatrate for db support, so we unload as much
of our problems on the oracle people. Works fine.
Ditto for support staff. Our users have oracle, so the more we make the db do
the less problems we have in our own code.

> 
> > Nevertheless, I concede, it *is* possible to have such a
> > horribly configured system that i/o load becomes an issue. It's also
> > possible to have a database that permits so few actions
> > that the dba can't do anything about a badly written app.
> > fortunately, oracle is different.
>  
> > > No, interoperability means abilty to integrate applications in a
> > > heterogeneus environment. It means standards and flexibilty.
> > So? What's more "standardised" about mysql's socket interface than
> > about oracles OCI or ESQL?
> 
> Are you having a nightmare in which we are dicussing the various
> merits of MySQL versus Oracle? Please follow your own advice and read
> this thread again so that you might figure out what is it we are
> actually taking about.
We are talking about open source versus commercial databases. I picked
those two as examples because I have worked with both of them.

> 
> > > > > > If it's important it must not matter whether one tries to
> > > > > > access the data from a local or remote machine.
> >  
> > > > > Interesting that you believe that this can not be accomblished with
> > > > > network security.
> >  
> > > > Yes. Now you figure out why.
> > > 
> > > Because you don't know what you are doing maybe?
> 
> > Wrong. Try again.
> 
> The more you talk, the clearer it is how right I was.
> 
> > > Oh wait, you don't
> > > need to, after all, you have decided to pay a vendor to know for you,
> > > I remember now.
> > Right. The alternative is not paying anyone and trying to figuring out the
> > source code on my own, right? Or paying someone else who starts
> > from scratch too?
> 
> More straw men and red herrings. If you are a Developer, which is who
> my comments are addressed to, it is your responsiblilty to your users
> and clients to know how your application works and to be able to
> support it without allowing some third party to hold them hostage.
No one holds anyone hostage. I let people do what they are good at.
I'm ok with application programming in the CAD world. Oracle (or
IBM, or microsoft) are good at programming databases. So, I
profit from their expertise by being able to provide a better application
than if I had to do db development (or fixing) as well.
So far no one has complained.

> > Care to elaborate? An insecure network does not mean that someone can
> > log on to the database server from anywhere but the console screwed onto
> > it. And securing the listener (in case of oracle) is part of the database
> > configuration.
> 
> If the above is true, that someone can only access any of the devices
> on your Database server via the local console, then your network *IS*
> secure
one can of course log on to the database. Via the listener and all the stuff.
In theory from an unsecure network. So, db security is not network security,
because all the stuff of protecting data from different users needs the
cooperation of the database.

> This is what I'm trying to say, that network security comes first,
You can have a secure database within an insecure network.

> 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,
do you mean that you consider it ok to have database data on nfs mounts?

> 
> Once again, It must be assumed that your consternations to contend
> this point are some weird form of self-flagilation.
> 
> > > > Right. You show me how do convert VENUS chip designs into Synopsys
> > > > without going into a museom for the original hardware and getting all
> > > > the versions in between.
> > > 
> > > What does this have to do with "Self Contained, Self Describing, Human
> > > Readable" files that can be read on any system past or present?
> 
> > It has to do with permanency. Try to read what you quote.
> 
> 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.
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.

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

> 
> Try to avoid making an ass of yourself with further pretentions.
> 
> > > tell me, how much do you know about my
> > > experience,
> 
> > What your arguments tell me.
> 
> Which ones? That abstracting access to suspect dependencies is a good
> idea?
That elegance is abstraction.
> That database security is secondary to network security?
Yes.
> That
> one should keep archives in a format that is likely to be readable
> forever?
Yes.
Those are the tree main reasons. The fourth one is your persistent
belief that the right to the source code is of value.

> 
> All these things come from experience,
So, what migrations have you done so far?
Right now I'm in the process of doing two, one boing our board design
toolchain, with plenty of data translation and the other a business flow app.
So far we've spent at least four man years on the CAD flow and it's far
from over. As for the other, try to imagine having a small busines flow
tool and then introducing SAP companywide.
And we get migration support from the new vendor.
Believe me, a database migration is *EASY* compared to that.
Even if I hardwire OCI calls into my c-code and then switch to
ODBC or something.

> your attempt to question my
> experience, only show that you are unable to formalute an actual
> argument, so you try and discredit the arguer instead of the argument.
I did. You just didn't understand it.

> 
> > > and why do you feel that talking about _me_ is a response
> > > to my argument?
> 
> > Because your argument isn't backed by anything. Give me some
> > substance and we can talk about it.
> 
> Oh please, my argument has been presented well enough, attacking me
> just shows you can not defend your own, that is if you actually had
> one.
You might have noticed that you got responses from different people
whereas you are the only one who thinks my arguments are rubbish.
Now, statistics is not fact, but it's evidence and should get you thinking.

> 
> If my argument was not backed up by anything it would easy enough to
> refute it without attempting to insult me,
I don't insult you I'm trying to get through to you.
Reasonable arguments didn't work.

> > All I've hear so far is the
> > usual open source rethoric about me or someone else being able
> > to magically support a product in a few days or weeks after the
> > original developers have abandoned it, or me.
> 
> These must be voices in your head that you are hearing. Since my
> argument have been quite clear and even sumerized several times.
Yes. The right to source code balances nonexisting support and
buying support for a open source software (instead of trying to
fix things oneself) is somehow better than doing the same with
commercial software. Did I leave out anything important?

> 
> Your arguments amount to the metaphysical belief that only the
> copyright holders of your favourite proporiety software know how to
> program,
No, that they are the only ones that should be allowed because they
are the only ones that can take responsibility.

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

> and therfore the only way forward is to make yourself both tehnicaly
> and legaly dependent on them as much as possible.
You forget that they depend on me. Namely, on my money.

> 
> > > > > If you have the source code, you are the developer,
> >  
> > > > Wrong. I am the user, t.
> > > 
> > > Oh, well then I guess we have nothing further to discuss, my comments
> > > here where meant for actual developers.
> 
> > So, oracle people should further develop oracle and mysql people
> > mysql. Did I get this right?
> 
> No, that's not right, that's not even wrong.
So, what is it?

> 
> (with applogies to Wolfgang Pauli)
> 
> Application developers should avoid locking themselves in to external
> dependencies, either by not using products to which they have no right
> to the source code, or abstracting access when they do use such
> products. Simple.
There it is again, this source code right thingie. And you complain about me
getting rude.
Again: The source code is no guarantee of fixed bugs, much less improvements.
It's not even what I want. I also can go and tinker with the airbag of my car
if I think it's broken, I don't do that either but go to a repair shop.
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.
And before you come again about the source code I can fix and improve,
or pay someone to do it, I won't because that would be wasting company
money and that would be because a migration is cheaper than tinkering with
the old software and it wouldn't lose us customers either because customers
don't like dead software.
When we figured out that our new CAD tool doesn't support oracle 9.2
we gave them a ding behind the ear and, see, the next release, out
in two months supports it and til then we got a workaround.

> 
> And having right to the source code does not mean that the program is
> 'open source,' as you can purchace such a right for propretary code,
> as is common for libraries.
And still, if something goes wrong, I file a service request.
And if the company does ceases to offer the product I change company.

> 
> Of course, when the program _is_ open source, you are guaranteed that
> right.
> 
> > > You have no such right, ever, the only right you _can_ have is the
> > > right to modify it yourself or contract someone to do it. Please read
> > > your licence.
> 
> > "Assistance with my SRs 24 hours per day, 7days a week". Practically I 
> > usually get two or three guys working on a typical SR of mine, depending on
> > how log it takes. Without a contract I'd get a 'buzz off, I'm doing my exams > this month'.
> 
> "Assitance" only means that they will provide someone whose time they
> can bill you for,
As I said, we pay a flatrate.

> not that anything will be accomplished.
Then they lose money if they don't accomplish anything.

> 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?
If not, what's the difference to buying db2 support?
(One thing more: No, if IBM abandons mysql I'm still not taking
on the support task, ok?)

Greetings!
Volker

I noticed that Message-ID:
<6f8cb8c9.0405120252.6f31f716@posting.google.com> from Steve contained
the following:

>> PostgreSQL is highly overrated and not suitable for any environment
>> where little things like crash recovery and security are a priority.
>
>What database does Google use?

Google's data is stored in data coops.
http://www.google.com/technology/pigeonrank.html

-- 
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

"Quirk" <quirk@syntac.net> schrieb im Newsbeitrag news:4e20d3f.0405110143.3fba4756@posting.google.com...
> "Volker Hetzer" <volker.hetzer@ieee.org> wrote in message news:<c7o7il$u0k$1@nntp.fujitsu-siemens.com>...
>
> > "Quirk" <quirk@syntac.net> schrieb im Newsbeitrag news:4e20d3f.0405100025.fd32875@posting.google.com...
> > > edwardh@highstream.net (Edward Lloyd Hillman) wrote in message news:<109o67992jbs0c1@news.supernews.com>...
> > >
> > > > > You have no such right, ever, the only right you _can_ have is the
> > > > > right to modify it yourself or contract someone to do it. Please read
> > > > > your licence.
> > > >
> > > >
> > > > Got a news flash for ya...
> > >
> > > Oh boy, it's Seseme Street News, OK Kermit, keep talking.
> > >
> > > > If you have a maintenance contract with a vendor and something of
> > > > theirs' is broken, they must fix it if you need it.
> > >
> > > Perhaps, but when the product in question is proprietary you have no
> > > recourse when they fail, because no one else has any right to modify
> > > the source code.
>
> > I have, at most,  the right to sue them,
>
> 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.

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

>
> > than if I go to a postgres developer
> > and tell him I'm not interested any more. So, unlike open source developers,
> > they actually have an interest in doing something.
>
> What on earth are you trying to say here? Why is a postgresql
> developer any more or less interested in your contarct than one who
> pedals proprietary software?
A developer who does not earn mony by it is less interested in providing
work than one who does. Therefore, support contracts make sense.
I was talking about the case where I go to the developer and ask him
to do something for free.

>
> > > When you have a right to the source code you can sign such a contarct
> > > with any firm you like, and fire their ass and hire another when they
> > > fail.
> > But it doesn't make sense to use any other firm than the guys who wrote it.
>
> Why? What magic powers are possesed by the firm that holds the
> copyright? Expcet the power to prevent anyone else from touching or
> looking at their code?
They developed it.

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

>
> By the way, I am _not_ arguing that one must do everything
> themeselves, only that one should not get locked into being dependant
> on a single provide.
>
> As I'v said, I'm baffled that this is so controversial that you all
> expect me to defend my good name merely for saying it.
>
> > > 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.

>
> >
> > > 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 there is no such requirement,
See my other posting.

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

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

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

>
> > > > The only way you can get that kind of support is with a maintance
> > > > contract.  With Open Source we'd have had to spend many extra
> > > > man-hours trying to find where the problem was and how to fix it
> > > > without breaking anything else.
> > >
> > > Why? You could have the exact same contarct with a vendor supporting
> > > an open source product,
>
> > Yes, but then it would cost like any other product, right?
>
> 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. 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?

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

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

>
> > > Or
> > > failing that, your application could have been designed to to give you
> > > alternatives,
>
> > Right. And the customer throws away years of experience with one db system
> > and pulls a finished, reliable and maintainable alternative installation out
> > of the hat.
>
> 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.

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

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

>
> > > But you put yourself in a position were you may have been unable you
> > > support your own customer _AT_ALL_ except for the good graces of your
> > > vendor.
>
> > Why? He doesn't support the db. The db vendor does that. All he has to do is > to show that it's othe db's fault, at which point
his customer's maintenance
> > contract with the db vendor kicks in. Normal business practice.
>
> Yes, passing the buck is unfortunalty the normal business practice,
> however good firms neither do it or put up with it.
And that is why special libraries, databases or servers exist?

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

Greetings!
Volker

"Steve" <stevesusenet@yahoo.com> schrieb im Newsbeitrag news:6f8cb8c9.0405120252.6f31f716@posting.google.com...
> Daniel Morgan <damorgan@x.washington.edu> wrote in message news:<1083695957.163784@yasure>...
> > Sarah Tanembaum wrote:
> > 
> > > 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
> > 
> > PostgreSQL is highly overrated and not suitable for any environment
> > where little things like crash recovery and security are a priority.
> 
> What database does Google use?
They offer jobs maintaining a "Linux cluster consisting of more than 10,000 servers".
I doubt that any single database scales that far.

Lots of Greetings!
Volker

In message <4e20d3f.0405120034.31bd92ac@posting.google.com>, Quirk 
<quirk@syntac.net> writes
>Erland Sommarskog <sommar@algonet.se> wrote in message 
>news:<Xns94E6F1BC7C070Yazorman@127.0.0.1>...
>> Dmytri Kleiner (quirk@syntac.net) writes:
>
>> > Good thing that you only mislead a few customers into overpaying for
>> > crap. Your company is just a bankruptcy waiting for a competent
>> > competitor to make it happen.
>
>> Our customers seems to be quite satisfied with our system.
>>
>> And - in difference to you - they actually know the system in question,
>> so I think they are somewhat better apt to tell whether it is crap or
>> not.
>
>The Application that you wrote I have no reason to doubt is of
>sufficient quality to keep your customers satisfied.
>
>Unfortunately you have created unneeded dependencies for them, the
>worst of which is not MS SQL, since it is fairly easy to get at data
>in MS SQL and archive it or export it in a usefull way, the worst is
>that you have tied your customers to a terrible Operating System with
>a terrible licence, even Oracle users are not so screwed since at the
>very least they have a choice when it comes to OS.

Just how often do you think a client changes the OS and/or database they 
are using for a live application that is meeting their business needs? 
Answer: probably not until they replace the application.


<snip>

-- 
Five Cats
Email to: cats_spam at uk2 dot net

In message <c7t3p2$b15$1@nntp.fujitsu-siemens.com>, Volker Hetzer 
<volker.hetzer@ieee.org> writes
<snip>

It occurs to me that we may be feeding a troll and the best diet for a 
troll is starvation!

-- 
Five Cats
Email to: cats_spam at uk2 dot net

> What database does Google use?

Random access memory.

Completely custom, too.

Ari

Daniel Morgan <damorgan@x.washington.edu> wrote in message news:<1084253467.342535@yasure>...

> Probably. But only right up until it crashed or some cracker tried
> to break in. Then it would likely be both as fragile and as transparent
> as a sheet of glass.

FUD

"As a cryptography and computer security expert, I have never
understood the current fuss about the open source software movement.
In the cryptography world, we consider open source necessary for good
security; we have for decades. Public security is always more secure
than proprietary security. It's true for cryptographic algorithms,
security protocols, and security source code. For us, open source
isn't just a business model; it's smart engineering practice."
-- Bruce Schneier, Founder and CTO Counterpane Internet Security, Inc.

http://www.schneier.com/crypto-gram-9909.html#OpenSourceandSecurity

"Microsoft is really good at producing really cool stuff. Security
isn't cool, I want to produce good stuff and customers want dancing
pigs."
-- Carl Ellison, security architect at Microsoft Corp.

http://www.eweek.com/article2/0,1759,1386333,00.asp

> Does anyone really believe that if SAP and PeopleSoft could make as
> much or more money writing their products to work against these
> products they wouldn't?

SAP does:

http://www.mysql.com/news-and-events/press-release/release_2003_16.html

> Does anyone really believe that CFOs and CIOs,
> looking at their budgets, wouldn't be running to these products en-mass?

They are.
 
http://www.dwheeler.com/oss_fs_why.html

"Volker Hetzer" <volker.hetzer@ieee.org> wrote in message news:<c7t3p2$b15$1@nntp.fujitsu-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*.

Wether you have 50 people or 100 people 'around there', the fact
remains that it is very unlikely that your investment can be saved by
a lawsuit, for every 50 you have, Oracle has more. And if you do have
more legal might than Oracle, you are the exception, not the rule.

For most organisations, sueng Oracle, or anyother major corporation is
simply not an option.

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.

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

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.

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

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

> > > than if I go to a postgres developer
> > > and tell him I'm not interested any more. So, unlike open source developers,
> > > they actually have an interest in doing something.
> >
> > What on earth are you trying to say here? Why is a postgresql
> > developer any more or less interested in your contarct than one who
> > pedals proprietary software?

> A developer who does not earn mony by it is less interested in providing
> work than one who does.

Why would anyone provide work for you without earning money? Geez, I
feel like I should be earning a paycheque just for talking to you.

As I've said, their are many profesional developers who provide
support for open source products, or provide source licences for their
own.

>  Therefore, support contracts make sense.

Of course they do.

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

> > Why? What magic powers are possesed by the firm that holds the
> > copyright? Expcet the power to prevent anyone else from touching or
> > looking at their code?

> They developed it.

Not necessarily, they merely own the copyright. And even so, that
still does not mean that somebody else can't modify it, and do so
well, sometimes even better than the original developers.

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

> > By the way, I am _not_ arguing that one must do everything
> > themeselves, only that one should not get locked into being dependant
> > on a single provide.
> >
> > As I'v said, I'm baffled that this is so controversial that you all
> > expect me to defend my good name merely for saying it.
> >
> > > > 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.

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

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

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

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

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

> 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, that many large companies, including IBM, support
open source applications or provide source licences for there own
applications,  but if you really want to hire IBM to support your
MySQL implemtation, you can, I would recomend you try MySQL AB first
though.

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

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

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

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.

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

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

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

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.

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

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

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.

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

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

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

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.

Dmytri Kleiner (quirk@syntac.net) writes:
> The Application that you wrote I have no reason to doubt is of
> sufficient quality to keep your customers satisfied.
> 
> Unfortunately you have created unneeded dependencies for them, the
> worst of which is not MS SQL, since it is fairly easy to get at data
> in MS SQL and archive it or export it in a usefull way, the worst is
> that you have tied your customers to a terrible Operating System with
> a terrible licence, even Oracle users are not so screwed since at the
> very least they have a choice when it comes to OS.

The fact that you may found Windows a terrible operation system is 
of course completely irrelvant to the discussion.

If it wasn't clear: we offer our customers a product, and they are not
only tied to the DBMS and operating system, they are just as well tied
to our product. They can still change a competing system, and this
has happened, for instance in conjunctions with mergers. (In which case
it is more an issue of politicis and which company that buys which
that determines which system they go for, than the technical qualities
of the respective systems.) Converting data from one system to another
is of course a major task. 

As for the platform, the customers knows what they get when they buy
our system. If they don't accept Windows, they are not likely to go
for us either. 
 
> I would say you made it quite clear that your basic message was that
> it would be folly to do what I was suggesting, 

Yes, it would be a folly to do so out of principle always. Sometimes
it may be necessary, sometimes you are better off tying yourself to
one single platform.

> It is not, as I've said, it can be as simple as writing a wrapper
> function around your data access.

Yes, if you build your system with all logic in a middle layer. Which
often can result in serious performance problems, because a lot of
data has to travel forth and back over the network. We have a lot of
the business logic in stored procedures, and we have also found that
this works best.
 
> Not as expensive as having the system itself obsoleted by an obsoleted
> dependency or the inabilty to get support for a dependency due to a
> licencing dispute.

Well, my company has worked this system since 1992, and nothing close
to that has happened yet.

-- 
Erland Sommarskog, SQL Server MVP, sommar@algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp

quirk@syntac.net (Quirk) wrote in message news:<4e20d3f.0405110058.684e5968@posting.google.com>...
> "Volker Hetzer" <volker.hetzer@ieee.org> wrote in message news:<c7o8i3$3bk$1@nntp.fujitsu-siemens.com>...
> 

> > > Yes, you have the right to be overcharged for work that may or may not
> > > not suit your needs by only _one_ vendor, and no right to go elsewhere
> > > when they fail, ignore you outright, stop supporting your application
> > > or vanish from the face of the earth. Have you actually read your
> > > contract or software licence?
> > Of course. See the end of this posting.
>  
> > > It only protects the vendor, not you.
> >  I've read  the licence and done even more: I've used the software and tested the contract.
> 
> Realy, care to quote the part of the Contract that Gaurantees you any
> rights?
> 
> Instead, what you will find is that the contracts insists that the
> Software is not gauranteed to be usefull for any particilar purpose,
> and that they deny all responsibilitty for it to the extent possible
> by law.
> 
> 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.
> 
> Have you tested alternatives?
> 

....

> > > > I don't *want* to create my own development
> > > > team competing with the original one. I don't want to merge my change back 
> > > > into their code with every new release! I don't want to develop code and
> > > > then have them decide whether they condescend to incorporate it or not! I 
> > > > want the authors of the software to do the coding based on what I'm willing 
> > > > to pay for!
> > > 
> > > You are dependent on their licence
>  
> > I'm dependent on the author's licence regardless of which database I use.
> 
> Yes, which is why you should choose one that give you a perpetual
> right to the source code, otherwise you are locked into a dependancy
> that may prove fatal to your application.
> 
> > It's just that some licences give me the illusion of being able to do 
> > something while mainly giving me in reality the ability to shoot myself in 
> > the foot or paying someone else to shoot me in the foot.
> 
> Unsubstantiated bunk, if you have the source code, it is not magic to
> fix it, or extend it, just normal progamming. 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.

As someone who has profited greatly from this, I must point out that
he is correct.  I've profited both from the fact that during and after
the lawsuit there is a great, _and artificially created_, shortage of
technical talent, and the fact that companies will indeed shoot
themselves in the foot by automating existing processes rather than
reengineering them, if having the source code allows them to do so. 
And when it gets obsolete and no young 'uns want to deal with it,
that's when the big bucks begin.


....

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

New or old, they get old or they die horribly.  Until there is some
desire in the industry for stability over time, this is a red herring.

> 
> > anyone else is going to make a worse job than
> > them. So, I get the best support when I'm paying them and no one else.
> 
> More unsubstantiated bunk, first of all, in many cases you can hire
> the original developers, 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.

Make buckets o' cash following them, too.

> 
> And finaly, it is a falalcy to say that someone will do a worse job
> simply because they are not the original developer.

Not necessarily.  I've seen plenty of "design drift," especially over
time when the newbies may not have the context of the original
developers, and the managers feel the need to compete with completely
different things from competitors.  There is also the classic case of
developers going from place to place because they are only interested
in new stuff, so follow-on developers miss a lot of the organizational
wisdom.


....

> In anycase, I am not arguing agianst using Oracle, as I said, if
> Oracle suits your needs and you think it's worth the money, use it,
> however, my advice is that if you do develop an application, write
> your code in such a way that you do not depend on Oracle, but can
> easily switch it over the the greatest extent possible.

Well, this is double-edged.  As someone who has spent a great deal of
the last couple of decades dealing with heterogenousity, I can state
with some confidence that the lowest-common-denominator approach will
make it very easy for the competition to eat your lunch after you've
created their market.  I think SAP has seen this and that is why they
are so hot on controlling mysql, and I think Oracle has seen this and
that is why they are so hot on controlling peoplesoft (they scheduled
the court date for September IIRC?), and I think MS has seen this, and
I think everyone else has seen that MS has seen this, and all the low
to midrange enterprise app competition are already going under.  Niche
markets excepted, but perhaps even more sensitive to LCD.
....

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

If you use non-standard features, your wrapper has to emulate it for
those db's that don't have it.  This may well be rocket science you
are reinventing.  I've seen it be a problem over and over.


....
> 
> > > > > If you have the source code, you are the developer,
>  
> > > > Wrong. I am the user, t.
> > > 
> > > Oh, well then I guess we have nothing further to discuss, my comments
> > > here where meant for actual developers.
>  
> > So, oracle people should further develop oracle and mysql people
> > mysql. Did I get this right?
> 
> No, that's not right, that's not even wrong.
> 
> (with applogies to Wolfgang Pauli)
> 
> Application developers should avoid locking themselves in to external
> dependencies, either by not using products to which they have no right
> to the source code, or abstracting access when they do use such
> products. Simple.
> 
> And having right to the source code does not mean that the program is
> 'open source,' as you can purchace such a right for propretary code,
> as is common for libraries.
> 
> Of course, when the program _is_ open source, you are guaranteed that
> right.

OK, give me the source to the Redhat 5 tape driver.

....

>  
> > "Assistance with my SRs 24 hours per day, 7days a week". Practically I 
> > usually get two or three guys working on a typical SR of mine, depending on
> > how log it takes. Without a contract I'd get a 'buzz off, I'm doing my exams > this month'.

ROTFL!

> 
> "Assitance" only means that they will provide someone whose time they
> can bill you for, not that anything will be accomplished. And you
> discredit yourself by attemping the fallacy that the only way to have
> access to an applications source code is to hire some one who is doing
> exams. Many large companies, and profesional develpoers provide source
> licences and/or support open source products, including the largest
> computer company in the world, IBM.

It's so funny, because I've heard it.  And at one time, I almost
actually said it.  I did once say something like "I'm not coming in
while my wife is having a baby merely because your 'lead dba' can't
follow instructions to load a test database."

jg
--
@home.com is bogus.
I change my vote, unmoderated is more fun: 
http://groups.google.com/groups?selm=1996Feb27.215203.22774%40rossinc.com&output=gplain

"Volker Hetzer" <volker.hetzer@ieee.org> wrote in message news:<c7t0v0$sbv$1@nntp.fujitsu-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.

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

What do think "Desupport its progams" means?

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

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.

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

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

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

You attempt empty rhetoric exactly because you have no real argument.

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

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

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

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?

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

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

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

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

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

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

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

> Anyone remembers hurd? Groff?

Yeah, what about them?

> 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, even have it modified if you
need to.

If, however, you are dependent on a closed-source dead horse, well,
you are horse-shit out of luck.

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

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.

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

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

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

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

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

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

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

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

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.

Just one simple example of how having the source gives you more
freedom, and how the developer and the copyright holder are not the
exact same thing, to say nothing of the support peon they actually let
you talk to.

> 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 thanks for acknowleding that reliable support costs money.

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

> > 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? The paragraph you are quoting explains the difference
between original developer and copyright holder, what are you
suggesting I try?

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

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

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

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.

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

> And they are dependent from me for my money.

Just you?

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

> > In anycase, I am not arguing agianst using Oracle, as I said, if
> > Oracle suits your needs and you think it's worth the money, use it,
> > however, my advice is that if you do develop an application, write
> > your code in such a way that you do not depend on Oracle, but can
> > easily switch it over the the greatest extent possible.

> Why "the greatest extent"? That costs me more time and money
> and customers that it's worth.

Because it will save you time and money in the long run in many cases,
but it is, like everything else a case by case call, I was not trying
to make design decisions for you or anybody else, just giving some
advice, good advice, I have no idea what you are trying to do other
than be a crank.

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

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.

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

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

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

> This creates an excessive amoung of simple
> queries and lots of network traffic. Right now we have huge problems
> getting an application to work properly that claims to support mysql and
> oracle.

There are bad application out there, including ones that are
Abstracted, and ones that are not.

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

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

> As for consulting, we pay a flatrate for db support, so we unload as much
> of our problems on the oracle people. Works fine.

Just because it works fine sometimes, in some cases, does not mean
that it works fine in all cases, my advice was generic, I am not
anti-Oracle.

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.

> Ditto for support staff. Our users have oracle, so the more we make the db do
> the less problems we have in our own code.

Your specific case is not neccesarily the general or even common case.

> > Are you having a nightmare in which we are dicussing the various
> > merits of MySQL versus Oracle? Please follow your own advice and read
> > this thread again so that you might figure out what is it we are
> > actually taking about.

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

We are talking about two different things, the advantages of source,
and the advangates of abstarction of access, 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.

> I picked
> those two as examples because I have worked with both of them.

Great, sadly however, not relevent.
�
> > More straw men and red herrings. If you are a Developer, which is who
> > my comments are addressed to, it is your responsiblilty to your users
> > and clients to know how your application works and to be able to
> > support it without allowing some third party to hold them hostage.

> No one holds anyone hostage. I let people do what they are good at.
> I'm ok with application programming in the CAD world. Oracle (or
> IBM, or microsoft) are good at programming databases. So, I
> profit from their expertise by being able to provide a better application
> than if I had to do db development (or fixing) as well.

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

> 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 Switch? What controls device permissions? Your ethernet cables?

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.

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

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.

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

It's unfortunate that you can not see the value of something simply
because you it is not needed for your specific application, and waste
my time and yours trying to convice me that because you do not need
it, I shouldn't recomend it to anyone, and by doing so I prove that I
am inexperienced, however many years of experience I may or may not
have.

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

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

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.

> Those are the tree main reasons. The fourth one is your persistent
> belief that the right to the source code is of value.

The right to source code is very much of value in many cases, even if
it's not of value to you.

You still have demonstrated nothing about my experience, which you
still know nothing about. And your insisting on having pretentions of
being more experienced than me only help you make an ass of yourself.

> > All these things come from experience,

> So, what migrations have you done so far?

As I've said, I'll rather leave my arguments speak for themselves
rather than be drawn into a pissing contest about who has done more
migrations. Since having done more migrations would not make me
automaticaly correct.

As I've already tried to explain to you, an argument that attacks the
arguer instead of the argument is a fallacy.

When I attack you, it is purely for the fun of it, I refute your
arguments by addressing them directly.

> Right now I'm in the process of doing two, one boing our board design
> toolchain, with plenty of data translation and the other a business flow app.
> So far we've spent at least four man years on the CAD flow and it's far
> from over. As for the other, try to imagine having a small busines flow
> tool and then introducing SAP companywide.
> And we get migration support from the new vendor.
> Believe me, a database migration is *EASY* compared to that.
> Even if I hardwire OCI calls into my c-code and then switch to
> ODBC or something.

You mean the same SAP that developed the Open Source SAP DB and is now
working  with MySQL DB in making it MaxDB? Did you not tell them that
source is of no value? Think of all the effort you could have saved
them! Forunatly there customers, who value their data, told them
different.

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.

> > your attempt to question my
> > experience, only show that you are unable to formalute an actual
> > argument, so you try and discredit the arguer instead of the argument.

> I did. You just didn't understand it.

Yeah, sure. I don't understand your arguments. They are
incomprehensible nonsence.

> > Oh please, my argument has been presented well enough, attacking me
> > just shows you can not defend your own, that is if you actually had
> > one.

> You might have noticed that you got responses from different people

And I responded in kind, if one of them made an argument you feel I
didn't address well enough, feel free to quote it, although I am happy
you feel a sence of support from MS SQL shills.

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

> Now, statistics is not fact, but it's evidence and should get you thinking.

Better evidence is how easily all your arguments are refuted.

> > If my argument was not backed up by anything it would easy enough to
> > refute it without attempting to insult me,

> I don't insult you I'm trying to get through to you.

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.

Now that you have educated me on the fact that law suits and not
source code is what I should depend on, I will give up my long career
as a developer and begin training to be a lawyer.

You've really set me straight.

I bow before your awesome experience.

> Reasonable arguments didn't work.

Always ready to go beyond the call of duty for a good cause, huh?

> > These must be voices in your head that you are hearing. Since my
> > argument have been quite clear and even sumerized several times.

> Yes. The right to source code balances nonexisting support and
> buying support for a open source software (instead of trying to
> fix things oneself) is somehow better than doing the same with
> commercial software. Did I leave out anything important?

Yes, my entire argument, but dont let that stop you from blathering.

> > Your arguments amount to the metaphysical belief that only the
> > copyright holders of your favourite proporiety software know how to
> > program,

> No, that they are the only ones that should be allowed because they
> are the only ones that can take responsibility.

See, "the only ones that can," -- they posses a special metaphysical
quality that no one else posses. Interesting faith you have.

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

> > and therfore the only way forward is to make yourself both tehnicaly
> > and legaly dependent on them as much as possible.

> You forget that they depend on me. Namely, on my money.

God help them then.

Fortunatly there are other customers.

> > > So, oracle people should further develop oracle and mysql people
> > > mysql. Did I get this right?
> > 
> > No, that's not right, that's not even wrong.

> So, what is it?

A non sequitor, a red herring, a straw man, a fallacy, irrelevent,
what it isn't is a response to my argument, neither a right, nor a
wrong response.

> > Application developers should avoid locking themselves in to external
> > dependencies, either by not using products to which they have no right
> > to the source code, or abstracting access when they do use such
> > products. Simple.

> There it is again, this source code right thingie. And you complain about me
> getting rude.

I don't complain, go ahead and serve, I'll snap. I like dozens. I just
wonder why you're such a glutten for punishement.

> Again: The source code is no guarantee of fixed bugs, much less improvements.

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

> It's not even what I want.

Yet others may not want what you want, do you think that my advice was
directed at you and your application specifically?

> I also can go and tinker with the airbag of my car
> if I think it's broken, I don't do that either but go to a repair shop.

Yes, and just like software, your financing contract may allow you to
go to any repair shop, or even fix it yourself if you are able to, or
it may force you into only using the repair shop of the dealer. The
later, by the way, is sometimes a rip off.

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

> And before you come again about the source code I can fix and improve,
> or pay someone to do it, I won't because that would be wasting company
> money and that would be because a migration is cheaper than tinkering with
> the old software and it wouldn't lose us customers either because customers
> When we figured out that our new CAD tool doesn't support oracle 9.2
> we gave them a ding behind the ear and, see, the next release, out
> in two months supports it and til then we got a workaround.
> don't like dead software.

You just do whatever you want, I'm sick of talking to you, however
surely you must know that not everyone agrees with you, even if you
haven't noticed that, your reasoning is based on nothing substantial
but your insistances and pretentions, even so you are entitiled to
hold your goofy ideas. Good luck to you. Just dont bore me with what
you want, or what you do, or anything about you at all, or me for that
matter, stick to the topic or go away.

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

> > And having right to the source code does not mean that the program is
> > 'open source,' as you can purchace such a right for propretary code,
> > as is common for libraries.

> And still, if something goes wrong, I file a service request.
> And if the company does ceases to offer the product I change company.

Sometimes it's best to change companies and keep the product,
sometimes it's best to abstract your code to make changing products
easier. What is your point exactly?

> > "Assitance" only means that they will provide someone whose time they
> > can bill you for,

> As I said, we pay a flatrate.

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.

> > 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, and you, not having source code can not find
someone who can (or will) do it cheaper, and you, thinking that
database access abstraction is a waste of time, must change your
entire application. Have fun. Your systems and data may have a short
enough life span that this works for you, do not assume that this is
the case for all applications and all data.

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

But anyway, this is nothing more than you jumping up and down again
making ludicrous examples.

> If not, what's the difference to buying db2 support?
> (One thing more: No, if IBM abandons mysql I'm still not taking
> on the support task, ok?)

IBM corporate services will not abondon anything as long as you keep
paying, heck, this is the company that created VisaulAge Cobol and
CICS for NT, however if you do have source, you can get someone else
to take over if you chose. But I know, source code is useless, good
programming is a myth, data abstraction a waste of time, readable file
formats are for novices, and network security is nothing but humbug.
Thanks for enlightening us all. I'm sure you think normalized data
models are for pussies too.

Regards,
Dmytri Kleiner
Wide eyed heretic, who believes tabs are better than spaces, does not
have a preference between Emacs or vi, yet actually thinks coding
standards matter. Go figure.

Five Cats <cats_spam@[127.0.0.1]> wrote in message news:<52tL3qcVSnmAFw$p@[127.0.0.1]>...

> >- If you don't have the source code for a product, and the right to
> >modify and redistribute it in perpetuity, nothing you develop on top
> >of it can be relied upon, so therefore the open source applications,
> >or applications for wich you've been granted such rights via an
> >non-expiring licence, are much *MORE* suitable for high-end commercial
> >applications, since you are not locked into any external dependencies.
> >
> 
> So you think most places have a programmer of suitable talent to be let 
> lose on something as mission-critical as the database in the situation 
> described?

Most places who develop "high-end commercial applications" should,
yes, or at least have a contract with a firm that does. Perhaps we
have a different idea of what "high-end commercial applications"
means. What mission-critcal database has been described? I didn't
catch a specific describtion. It's been a long thread, perhaps I
missed it or forgot it. I just posted my favourite advice. I didn't
realise it would upset so many people.

> >- Ideally, your Application's data access will be built around a data
> >abstraction layer that can use alternative database backends, i.e.
> >PEAR::DB.
> 
> Depends on what your application is written in.  The more layers are 
> added in, the more places there are for things to go wrong, and for 
> performance bottlenecks to occur.

This is true, you should add your layers wisely, database abstraction
is commonly a good place, but not always. I've never regreted it
though.

> >- If your data is really important to you, you will use network, not
> >application or database level security to protect access to it.
> 
> If it's *really* important you will be using all these methods to 
> protect it.

Yes. of course, you should use both methods, but your network security
should be first and foremost, everything else depends on it and is
useless without it.

> >- If your data is really important to you, you will only keep a
> >secondary copy of it in *ANY* SQL server for indexing and querying
> >purposes, not as the primary datastore.
> 
> Depends on what the balance between query etc.

Of course it depends, everything always depends, that's what software
devlopment is about, making these sorts of choices on a case by case
basis.
My advice was just that, advice, not the univerasl law. This item in
particular depends on how important you define "realy important data"
and how far in the future the data is really important for, as well
as, yes, how it is to be accessed now, and how much performance is a
factor.

> And, of course, if your data is *really* important to you you will have 
> a decent backup strategy and will have tested restoring it.

Not only a backup, which only recovers live data, but also perhaps
archives of old data, that may not be accessed at all for years, but
still must be kept, such as public records.

>  You might 
> even use a high-end DBMS which can sort out the problems of partially 
> written transactions should the server fall over for some reason.

For live data, perhaps, for the archives I recomend useing self
contained, self describing, human readable files if possible.
 
> And, of course, you will be using a high-end server with redundancy 
> left, right and centre so that disks etc. can be swapped without having 
> to bring it or the DBMS off-line.

I agree, but this only addresses online concerns, not data permenancy,
which is another factor with it's own issues.
 
> You might *even* have a second server in a different building you can 
> rush a restore to in the event of major catastrophes.

Distributed, Reduntant, and Highly Available are good. So is readable
when the servers are junk, the software antiquated and the buildings
just memories in old photographs. In some cases, our databases contain
the Pompeii Wall Paintings of the archiologists of the future.
Painting everything on walls maybe taking things a little to far, but
self contained, self describing, human readable is not a bad idea when
it is possible.

> >- Your primary datastore should be self contained, self describing and
> >human readable, something like a heirarchy of XML files. This is the
> >best way to ensure the perminancy and portabilty of your important
> >data.
> 
> Someone who believes XML is the cure for everything....

Who? Where? Not me. But it works as far as text file formats go.

>  I would put this at the bottom of the list.

Isn't that where you found it in my list, at the bottom?

> >- Anyone who calls Free Software 'Freeware', implies that believing in
> >it is a 'religion' or thinks that it is low quality as a rule should
> >be considered unskilled labour, not a source of real advice.
> 
> And anyone who believes it's the answer to all our prayers is just as 
> deluded.

I dont know about you, but my prayers are not answered by any
software. I'll take source code when I can get it though.

Cheers.

Five Cats <cats_spam@[127.0.0.1]> wrote in message news:<52tL3qcVSnmAFw$p@[127.0.0.1]>...

> >- If you don't have the source code for a product, and the right to
> >modify and redistribute it in perpetuity, nothing you develop on top
> >of it can be relied upon, so therefore the open source applications,
> >or applications for wich you've been granted such rights via an
> >non-expiring licence, are much *MORE* suitable for high-end commercial
> >applications, since you are not locked into any external dependencies.
> >
> 
> So you think most places have a programmer of suitable talent to be let 
> lose on something as mission-critical as the database in the situation 
> described?

Most places who develop "high-end commercial applications" should,
yes, or at least have a contract with a firm that does. Perhaps we
have a different idea of what "high-end commercial applications"
means. What mission-critcal database has been described? I didn't
catch a specific describtion. It's been a long thread, perhaps I
missed it or forgot it. I just posted my favourite advice. I didn't
realise it would upset so many people.

> >- Ideally, your Application's data access will be built around a data
> >abstraction layer that can use alternative database backends, i.e.
> >PEAR::DB.
> 
> Depends on what your application is written in.  The more layers are 
> added in, the more places there are for things to go wrong, and for 
> performance bottlenecks to occur.

This is true, you should add your layers wisely, database abstraction
is commonly a good place, but not always. I've never regreted it
though.

> >- If your data is really important to you, you will use network, not
> >application or database level security to protect access to it.
> 
> If it's *really* important you will be using all these methods to 
> protect it.

Yes. of course, you should use both methods, but your network security
should be first and foremost, everything else depends on it and is
useless without it.

> >- If your data is really important to you, you will only keep a
> >secondary copy of it in *ANY* SQL server for indexing and querying
> >purposes, not as the primary datastore.
> 
> Depends on what the balance between query etc.

Of course it depends, everything always depends, that's what software
devlopment is about, making these sorts of choices on a case by case
basis.
My advice was just that, advice, not the univerasl law. This item in
particular depends on how important you define "realy important data"
and how far in the future the data is really important for, as well
as, yes, how it is to be accessed now, and how much performance is a
factor.

> And, of course, if your data is *really* important to you you will have 
> a decent backup strategy and will have tested restoring it.

Not only a backup, which only recovers live data, but also perhaps
archives of old data, that may not be accessed at all for years, but
still must be kept, such as public records.

>  You might 
> even use a high-end DBMS which can sort out the problems of partially 
> written transactions should the server fall over for some reason.

For live data, perhaps, for the archives I recomend useing self
contained, self describing, human readable files if possible.
 
> And, of course, you will be using a high-end server with redundancy 
> left, right and centre so that disks etc. can be swapped without having 
> to bring it or the DBMS off-line.

I agree, but this only addresses online concerns, not data permenancy,
which is another factor with it's own issues.
 
> You might *even* have a second server in a different building you can 
> rush a restore to in the event of major catastrophes.

Distributed, Reduntant, and Highly Available are good. So is readable
when the servers are junk, the software antiquated and the buildings
just memories in old photographs. In some cases, our databases contain
the Pompeii Wall Paintings of the archiologists of the future.
Painting everything on walls maybe taking things a little to far, but
self contained, self describing, human readable is not a bad idea when
it is possible.

> >- Your primary datastore should be self contained, self describing and
> >human readable, something like a heirarchy of XML files. This is the
> >best way to ensure the perminancy and portabilty of your important
> >data.
> 
> Someone who believes XML is the cure for everything....

Who? Where? Not me. But it works as far as text file formats go.

>  I would put this at the bottom of the list.

Isn't that where you found it in my list, at the bottom?

> >- Anyone who calls Free Software 'Freeware', implies that believing in
> >it is a 'religion' or thinks that it is low quality as a rule should
> >be considered unskilled labour, not a source of real advice.
> 
> And anyone who believes it's the answer to all our prayers is just as 
> deluded.

I dont know about you, but my prayers are not answered by any
software. I'll take source code when I can get it though.

Cheers.

"Quirk" <quirk@syntac.net> wrote in message
news:4e20d3f.0405120034.31bd92ac@posting.google.com...
>
> Unfortunately you have created unneeded dependencies for them, the
> worst of which is not MS SQL, since it is fairly easy to get at data
> in MS SQL and archive it or export it in a usefull way, the worst is
> that you have tied your customers to a terrible Operating System with
> a terrible licence, even Oracle users are not so screwed since at the
> very least they have a choice when it comes to OS.

I'm curious about this terrible OS you refer to.  I know the one I use is
stable, hasn't crashed on me once for SQL Server on 1/2 dozen machines for
4+ years and so far has not succumbed to any security holes.  Or is this
just blatant bias?

On Wed, 12 May 2004 13:14:39 +0200, "Volker Hetzer"
<volker.hetzer@ieee.org> wrote (more or less):

>
>"Quirk" <quirk@syntac.net> schrieb im Newsbeitrag news:4e20d3f.0405110058.684e5968@posting.google.com...
>> "Volker Hetzer" <volker.hetzer@ieee.org> wrote in message news:<c7o8i3$3bk$1@nntp.fujitsu-siemens.com>...
>> 
>> > > > > > That's not true. 
>> >  
>> > > > > Yes it is.
>> >  
>> > > > What was the value of this reply?
>> > > 
>> > > What was the value of yours? Or this latest one?
>> > A question is not an answer.
>> 
>> And what was your reply?
>I asked first.
>
>> 
>> > > Yes, you have the right to be overcharged for work that may or may not
>> > > not suit your needs by only _one_ vendor, and no right to go elsewhere
>> > > when they fail, ignore you outright, stop supporting your application
>> > > or vanish from the face of the earth. Have you actually read your
>> > > contract or software licence?
>> > Of course. See the end of this posting.
>> 
>> > > It only protects the vendor, not you.
>> >  I've read  the licence and done even more: I've used the software and tested the contract.
>> 
>> Realy, care to quote the part of the Contract that Gaurantees you any
>> rights?
>http://oracle.com/support/index.html?policies.html
>
>> 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.

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


-- 
Cheers, 
   Euan
Gawnsoft: http://www.gawnsoft.co.sr
Symbian/Epoc wiki:  http://html.dnsalias.net:1122
Smalltalk links (harvested from comp.lang.smalltalk)  http://html.dnsalias.net/gawnsoft/smalltalk

"Greg D. Moore \(Strider\)" <mooregr_deleteth1s@greenms.com> wrote in message news:<0wBoc.183156$M3.141910@twister.nyroc.rr.com>...

> "Quirk" <quirk@syntac.net> wrote in message
> news:4e20d3f.0405120034.31bd92ac@posting.google.com...
> >
> > Unfortunately you have created unneeded dependencies for them, the
> > worst of which is not MS SQL, since it is fairly easy to get at data
> > in MS SQL and archive it or export it in a usefull way, the worst is
> > that you have tied your customers to a terrible Operating System with
> > a terrible licence, even Oracle users are not so screwed since at the
> > very least they have a choice when it comes to OS.
> 
> I'm curious about this terrible OS you refer to.  I know the one I use is
> stable, hasn't crashed on me once for SQL Server on 1/2 dozen machines for
> 4+ years and so far has not succumbed to any security holes.  Or is this
> just blatant bias?

Eeek. Someone actually wants me to discuss Windows.

If you're really interested in learning, which I doubt, read this:

	http://kirch.net/unix-nt

	"Why Windows NT Server 4.0 continues to exist in the enterprise would
be a topic appropriate for an investigative report in the field of
psychology or marketing, not an article on information technology."

-- John Kirch, Networking Consultant and Microsoft Certified
Professional

NOTE TO SELF: remember to notice when groups like
comp.databases.ms-sqlserver are in the newsgroup list and remove them
in replies, lets at least maintain //some// level of quality in these
discussions.

[comp.databases.ms-sqlserver removed from Groups, not intersted in
windows versus unix holy war]

Erland Sommarskog <sommar@algonet.se> wrote in message news:<Xns94E7EB1BB3781Yazorman@127.0.0.1>...
> Dmytri Kleiner (quirk@syntac.net) writes:

> The fact that you may found Windows a terrible operation system is 
> of course completely irrelvant to the discussion.

That it is terrible is irrelevant, yes, that your application is tied
to it is relevent.

> If it wasn't clear: we offer our customers a product, and they are not
> only tied to the DBMS and operating system, they are just as well tied
> to our product.

Which would be a better product if it were not tied to a particular OS
at the very least, and, if possible, not to a particular database
either.

Oracle or Sybase, at least run on several OSes. Not to mention
PostgreSQL and Firebird. One of these would certainly be a better
choice than MS SQL, again, not that MS SQL server is particularly bad,
it's not, part of was writen by Sybase . It's that it traps you in
Windows.

> As for the platform, the customers knows what they get when they buy
> our system. If they don't accept Windows, they are not likely to go
> for us either. 

Good comanpies educate there clients, bad companies take advantage of
their ignorance.
  
> > I would say you made it quite clear that your basic message was that
> > it would be folly to do what I was suggesting, 
> 
> Yes, it would be a folly to do so out of principle always.

Ah, thw word 'always' -- after duress, some qualification! 

I have never recomended doing anything always, only given some good
advice.

> Sometimes
> it may be necessary, sometimes you are better off tying yourself to
> one single platform.

There are always exceptions to all rules of thumb, however, in the
case of data abstraction, only extream performance concerns are
generaly a good enough reason, and then, if your application is so
specialized that abstraction is not workable, you are _usualy_ better
off using something for wich you have source code.

> > It is not, as I've said, it can be as simple as writing a wrapper
> > function around your data access.
> 
> Yes, if you build your system with all logic in a middle layer. Which
> often can result in serious performance problems, because a lot of
> data has to travel forth and back over the network. We have a lot of
> the business logic in stored procedures, and we have also found that
> this works best.

try this:

 * create a wrapper around the execute binding, that way your
application can at least execute stored procured on any backend that
supports them.

 * use standard syntax as much as possible.

 * issolate the use of non standardized syntax in as few procedures as
possible.

How difficult is that?

> > Not as expensive as having the system itself obsoleted by an obsoleted
> > dependency or the inabilty to get support for a dependency due to a
> > licencing dispute.

> Well, my company has worked this system since 1992, and nothing close
> to that has happened yet.

Come gather 'round people
Wherever you roam
And admit that the waters
Around you have grown
And accept it that soon
You'll be drenched to the bone.
If your time to you
Is worth savin'
Then you better start swimmin'
Or you'll sink like a stone
For the times they are a-changin'.

Five Cats <cats_spam@[127.0.0.1]> wrote in message news:<YC0DqIbKLioAFw40@[127.0.0.1]>...

> >Unfortunately you have created unneeded dependencies for them, the
> >worst of which is not MS SQL, since it is fairly easy to get at data
> >in MS SQL and archive it or export it in a usefull way, the worst is
> >that you have tied your customers to a terrible Operating System with
> >a terrible licence, even Oracle users are not so screwed since at the
> >very least they have a choice when it comes to OS.
> 
> Just how often do you think a client changes the OS and/or database they 
> are using for a live application that is meeting their business needs? 
> Answer: probably not until they replace the application.
�
Interesting that you believe that you an application need not last
longer than the server it is installed on, or that the next server
should automatacaly have the exact same OS or else the appliction
should be obsoleted.

Would it not be better if the customer could keep the application?

In message <4e20d3f.0405130435.6fe3861@posting.google.com>, Quirk 
<quirk@syntac.net> writes
>Five Cats <cats_spam@[127.0.0.1]> wrote in message 
>news:<YC0DqIbKLioAFw40@[127.0.0.1]>...
>
>> >Unfortunately you have created unneeded dependencies for them, the
>> >worst of which is not MS SQL, since it is fairly easy to get at data
>> >in MS SQL and archive it or export it in a usefull way, the worst is
>> >that you have tied your customers to a terrible Operating System with
>> >a terrible licence, even Oracle users are not so screwed since at the
>> >very least they have a choice when it comes to OS.
>>
>> Just how often do you think a client changes the OS and/or database they
>> are using for a live application that is meeting their business needs?
>> Answer: probably not until they replace the application.
>�
>Interesting that you believe that you an application need not last
>longer than the server it is installed on, or that the next server
>should automatacaly have the exact same OS or else the appliction
>should be obsoleted.
>
>Would it not be better if the customer could keep the application?

I was really (but not very clearly) referring to a change between 
Windows & Unix.  The commercial databases are ported to loads & loads of 
Unix platforms so changing one Unix machine (or one version of a Unix OS 
for a later one) is usually not a problem.


-- 
Five Cats
Email to: cats_spam at uk2 dot net

Quirk (quirk@syntac.net) writes:
> [comp.databases.ms-sqlserver removed from Groups, not intersted in
> windows versus unix holy war]

It appears that you failed to do that. That is the newsgroup from
where I read this thread. If you feel this group is not the venue
for you, just don't reply at all.

And if you want to avoid holy wars, don't come with blanket statments
about "terrible operating system" or barf just because people say
"SQL Server".
 
> Which would be a better product if it were not tied to a particular OS
> at the very least, and, if possible, not to a particular database
> either.

Only if you hold non-tiedness as a religious belief. Making a system
portable over platforms, not the least RDBMSs, is very expensive, and
I would suggest that our customers prefer to get more functionality 
out of the system.
 
> try this:
> 
>  * create a wrapper around the execute binding, that way your
> application can at least execute stored procured on any backend that
> supports them.
> 
>  * use standard syntax as much as possible.
> 
>  * issolate the use of non standardized syntax in as few procedures as
> possible.
> 
> How difficult is that?

Very.

And if you had any experience of developing an enterprise OLTP system
you would know that.

>only extream performance concerns are generaly a good enough reason, 

Rewriting an UPDATE statement which actually used standard syntax
(correlated subquery in the SET clause), to one that use the 
proprietary FROM clause with a derived table, slashed execution time
from two minutes to a few seconds. 

And those cases are common place when you work with an RDBMS. Even if
your standard SQL ports from one RDBMS to another (not all support
the same subset of the standard), you cannot rely on that you 
performance does.

-- 
Erland Sommarskog, SQL Server MVP, sommar@algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp

"Quirk" <quirk@syntac.net> wrote in message
news:4e20d3f.0405130341.8761e58@posting.google.com...
> "Greg D. Moore \(Strider\)" <mooregr_deleteth1s@greenms.com> wrote in
message news:<0wBoc.183156$M3.141910@twister.nyroc.rr.com>...
> >
> > I'm curious about this terrible OS you refer to.  I know the one I use
is
> > stable, hasn't crashed on me once for SQL Server on 1/2 dozen machines
for
> > 4+ years and so far has not succumbed to any security holes.  Or is this
> > just blatant bias?
>
> Eeek. Someone actually wants me to discuss Windows.
>
> If you're really interested in learning, which I doubt, read this:

No, I don't seem to be the one who has the closed mind.

>
> http://kirch.net/unix-nt
>
> "Why Windows NT Server 4.0 continues to exist in the enterprise would
> be a topic appropriate for an investigative report in the field of
> psychology or marketing, not an article on information technology."

Interesting, but not the OS in question.

Thanks for playing troll.

>
> -- John Kirch, Networking Consultant and Microsoft Certified
> Professional
>
> NOTE TO SELF: remember to notice when groups like
> comp.databases.ms-sqlserver are in the newsgroup list and remove them
> in replies, lets at least maintain //some// level of quality in these
> discussions.

Yes, we would rather keep the level of discussion professional and based on
facts, so please, in the future excuse yourself.

Sarah Tanembaum wrote:

> 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
> 
> 
_Short Summary_

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

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

   *SQL Server*
/Definetly/ not free, jam packed with features, very fast, lots of extras

   *Sybase and Oracle*
Can't say, I have no experience with them.


_Answer to your question_
Suitable for a high-end commercial application? I'm not sure I would risk my job 
on it...

We use SQL Server where I work and we well, beat the shit out of the server. The 
hardware is backed with F.C. NAS from Network Appliance. The actual hardware is 
a Dell 4-way (excluding Hyper Threading) with ~8GB of RAM and considering what a 
beating the box has to endure it does really well until one of the developers 
starts joining half a million records off of a table with insufficient indexes. 
But I digress...

Personally, I wouldn't use it for commercial apps. The commercial solutions have 
something very useful, commercial backing. This gives them the opportunity to 
work on the server itself, extra features, extras like management interfaces and 
clustering software.

IMHO current open source RDBMS do not have the robustness, stability, or 
performance to use in mission-critical situations.

_A Message to Open Source Bible Beaters_
I'm one of you too, but I also work in a company where we make thousands of 
dollars per minute. Downtime is /not/ an option and frankly, open source 
databases are not quite there yet. I forsee things seriously shifting in the 
next decade or so.

Erland Sommarskog <sommar@algonet.se> wrote in message news:<Xns94E8F322F2011Yazorman@127.0.0.1>...

> Quirk (quirk@syntac.net) writes:
> > [comp.databases.ms-sqlserver removed from Groups, not intersted in
> > windows versus unix holy war]
> 
> It appears that you failed to do that. That is the newsgroup from
> where I read this thread. If you feel this group is not the venue
> for you, just don't reply at all.

Sorry. This time it's removed, so if Erland is not able to see the
response, I guess this discussion is over, since he already claimed
that I would agree with him if only I had more experience, he already
shot his load anyway.

> And if you want to avoid holy wars, don't come with blanket statments
> about "terrible operating system" or barf just because people say
> "SQL Server".

Erland thinks that the holy war is due to my blanket statements, and
that is the problem, the real truth is talking sence to windows
zealots is useless, most do not even understand their own systems
enough to discuss them, and the ones that do understand read other
news groups, so its best to simply avoid the ms specifc newsgroups.

> > Which would be a better product if it were not tied to a particular OS
> > at the very least, and, if possible, not to a particular database
> > either.
> 
> Only if you hold non-tiedness as a religious belief. Making a system
> portable over platforms, not the least RDBMSs, is very expensive, and
> I would suggest that our customers prefer to get more functionality 
> out of the system.

Yet it is obvious that by using phrases like _would be better_ and _if
possible_ I am in no way holding anything as a religion, only giving
good design advice. The only zealot is Erland, who is trying to send
the message that abstracting data access and not depending on MS SQL
would be folly, because he is a MS SQL Shill, Most Valuable Peon, as
it says in his sig.
  
> > try this:
> > 
> >  * create a wrapper around the execute binding, that way your
> > application can at least execute stored procured on any backend that
> > supports them.
> > 
> >  * use standard syntax as much as possible.
> > 
> >  * issolate the use of non standardized syntax in as few procedures as
> > possible.
> > 
> > How difficult is that?
> 
> Very.

> And if you had any experience of developing an enterprise OLTP system
> you would know that.

You see, it would be *very* difficult, but only a man with great
expertise, like Erland, can know why. Typical FUD.

> >only extream performance concerns are generaly a good enough reason, 
> 
> Rewriting an UPDATE statement which actually used standard syntax
> (correlated subquery in the SET clause), to one that use the 
> proprietary FROM clause with a derived table, slashed execution time
> from two minutes to a few seconds. 

Again, one, unqualified example, we do not know why the update
statement is so slow, nor do we know if the proprietry from clause is
the only, let alone the best solution, nor do we know whether other
servers would have the same issue, nor do we know if Erland's data
model itself is behind the problem, yet we should automaticly believe
Erland that this proprietary from clause is the only way and that
abstraction from MS SQL will lead us to ruin.

Also, of course, you may have noted that the final point in my
recomendation to Erland is "issolate the use of non standardized
syntax in as few procedures as
possible." So even if a propietary clause was needed, it could be
used, but if its use is issolated, then porting is much easier,
because you know wich procedures contain nonstandard syntax.

I hope none is fooled by his nonsence.

[comp.databases.ms-sqlserver group removed]

Jeff Rodriguez <newsgroup1@gurugeek.EXAMPLENOSPAM.com> wrote in message news:<40A457C7.4000304@gurugeek.EXAMPLENOSPAM.com>...

>    *PostgreSQL*
> Free, loaded with features, not particularly fast, some extras
> 
>    *MySQL*
> Free, not so loaded with features, very fast, some extras
> 
>    *SQL Server*
> /Definetly/ not free, jam packed with features, very fast, lots of extras
> 
>    *Sybase and Oracle*
> Can't say, I have no experience with them.

Ok, in very general terms, true enough, but of course anyone making
such a choise should ask themselves, what are my performance needs,
which features to I need, which extras do I need, etc.

> _Answer to your question_

> Suitable for a high-end commercial application? I'm not sure I would risk my > job on it...

But you *would* risk your Job on developing "high-end commercial"
applications for which you have no source code for dependencies, or
even perpetual access (at any cost) to the dependencies, and a sole
source for your support?

Interesting priorities your employer has, certainly no real software
developement company, like microsoft for instance, would put
themselves in
such a position, namely making their //own// software, that they have
invested there own money in developing, depend exclusively on an
//external// product, for which they only have a binary.

> We use SQL Server where I work and we well, beat the shit out of the server. > The hardware is backed with F.C. NAS from Network Appliance. The actual 
> hardware is a Dell 4-way (excluding Hyper Threading) with ~8GB of RAM and 
> considering what a beating the box has to endure it does really well until
> one of the developers starts joining half a million records off of a table
> with insufficient indexes. 
> But I digress...

You do digress, so I'll take this window of offtopicness to say that
in no way am I suggesting that one should _never_ use proprietary or
closed source applications. For high end or very specialized
applications they often make a lot of sence, and are sometimes the
_only_ solution.

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.
 
> Personally, I wouldn't use it for commercial apps. The commercial solutions 
> have something very useful, commercial backing. This gives them the 
> opportunity to work on the server itself, extra features, extras like 
> management interfaces and clustering software.

Commercial backing is available for //all// products, closed or open
source, except that with open source, you can chose the commercial
backer, and with closed source, you can only chose the copyright
holder.

> IMHO current open source RDBMS do not have the robustness, stability, or 
> performance to use in mission-critical situations.

That depends on the mission. If your mission really does depend on
million record table joins, I may agree with you, if your mission
depends on being able to build new commodity-grade servers anytime you
need one, with out risking getting sued for 'over-deployment' I may
not.
 
> _A Message to Open Source Bible Beaters_

> I'm one of you too,

Then why do you preach FUD?

In anycase, open source is a good engineering practice, not a
religion, we do not need 'bible beaters' thank you.

The real 'bible beaters' are those that endlessly repeat their
metephysical belief in the infallibility of closed source vendors, and
even they can not agree on *which* closed source vendor is the real
infallible one, simular to actual bible beaters and their scriptural
disputes. The open source community are better compared to Quakers, no
source is sacred.

Most of the poor closed-source zealots do not even realize what a
small segment of the computer industry licence vending closed-source
software developers actualy are.

> but I also work in a company where we make thousands of 
> dollars per minute.

If I where I you I would feel antsy about an application where being
down for
a minute would cost me a thousand dollars, and yet I had no source
code and was locked into a exclusive external support contract. But
good luck.

> Downtime is /not/ an option and frankly,

Microsoft released an unprecedented release of eight patches that
repaired 21 security holes on April 13, how safe where you on April
12? Since you have no source code, no one knows but Microsoft (and the
hackers).

I'm glad you trust Microsoft, I would rather trust the likes of Bruce
Schneier.

> open source databases are not quite there yet.

For million record table joins, perhaps not, but for large
commodity-grade clusters that can handle billions of simple
transactions, they may be, as I said, it all depends on the
application. Google, perhaps the worlds biggest database application,
doesn't use any database products at all, comercial or otherwise, but
rather uses their own specialized code built on top of as many lines
of open source code as they can their mits on.

> I forsee things seriously shifting in the 
> next decade or so.

Really? I see the barbarians of the Open Source database world
storming the datacenters quite aggresively, PostgreSQL, MySQL, MaxDB,
Firebird, SQLite, and many other less prominent ones. And NetApp is
losing ground to the likes of DRDB. Huge powerhouses like IBM, SAP and
Novell are joining the charge, if you think the paradigm shift is a
decade off, you need get out of your chair and look out of the window
a little.

Not much longer than a decade ago there was no MS SQL Server.

[comp.databases.ms-sqlserver removed]

Reply direct to other readers, not Greg since he may no longer get
this reply if he only reads the ms-specific group, which I am not
interested in contributing to, life is too short.

> > Eeek. Someone actually wants me to discuss Windows.
> >
> > If you're really interested in learning, which I doubt, read this:
> 
> No, I don't seem to be the one who has the closed mind.

Greg thinks I have a closed mind simply because I refuse to consider
Windows,
ignoring the possibilty that I have not only considered windows but
have used it extensively in the field. Having come to a conclusion
about something is not the same as having a closed mind.

> > http://kirch.net/unix-nt
> >
> > "Why Windows NT Server 4.0 continues to exist in the enterprise would
> > be a topic appropriate for an investigative report in the field of
> > psychology or marketing, not an article on information technology."
> 
> Interesting, but not the OS in question.

Yet Greg's mind is so closed, that in reponse to a detailed article
comparing Windows-based Servers to Unix servers his only response it
is //that it is not the OS in question//, meanining that it is not the
same //version// of the OS that Greg uses. Of course, as anybody with
an open mind can see, many of the issues discussed in the article hold
true. But as I guessed at first, Greg was never really interested in
learning.

> Thanks for playing troll.

When you have no argument: attack the arguer.

> > NOTE TO SELF: remember to notice when groups like
> > comp.databases.ms-sqlserver are in the newsgroup list and remove them
> > in replies, lets at least maintain //some// level of quality in these
> > discussions.
> 
> Yes, we would rather keep the level of discussion professional and based on
> facts, so please, in the future excuse yourself.

'Based on facts', if we had as much Oxygen as Greg provided facts we
would quickly suffocate.

John Kirsh, however, provided many facts, Greg's response, as typical
for the MICROS~1 zealots, was an unsubstantiated, out-of-hand
dismissal.

Thanks Greg!

Quirk (quirk@syntac.net) writes:
> [comp.databases.ms-sqlserver group removed]

You really need training! You failed again! (And while you are at it,
drop comp.lang.ruby which we both were requested by mail to do.)
 
> But you *would* risk your Job on developing "high-end commercial"
> applications for which you have no source code for dependencies, or
> even perpetual access (at any cost) to the dependencies, and a sole
> source for your support?

It happens to the be the case that in my position as an SQL Server MVP
I could get access to the source code for SQL Server, or at least I
think so. But I have not taken up on this offer. Why? Because I would
absolutely no use for it. I know about SQL programming, the SQL Server
source code is a lot of C++ code which is far beyond my field of
expertise.

And this applies to the very vast majority of SQL Server users.

> Most of the poor closed-source zealots do not even realize what a
> small segment of the computer industry licence vending closed-source
> software developers actualy are.

I don't know if there are any closed-source zealots out there. I am 
certainly not one of them. If I knew that MySQL or PostgresSQL was
the best solution for someone, I would not hesitate from making the
recomendation. Admittedly, it is a bit unlikely, but that is only 
because my expert knowledge lies with SQL Server, so I would really
know what I am recommending. (And, no, I would not recommend SQL 
Server, just because I know that one well.)
 

-- 
Erland Sommarskog, SQL Server MVP, sommar@algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp

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

On Fri, 14 May 2004, newsgroup1@gurugeek.EXAMPLENOSPAM.com wrote:
> 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. 

I like the seats and dashboards of my BMW, so just yesterday, I
pulled them out and put them in my wifes Ford Escort, but damn,
the car just doesn't seem to perform as well.  I really thought
the car industry standard was supposed to take care of these
performance degradations.

-- 
Galen Boyer

Jeff Rodriguez wrote:

> _Short Summary_
> 
>   *PostgreSQL*
> Free, loaded with features, not particularly fast, some extras
> 
>   *MySQL*
> Free, not so loaded with features, very fast, some extras
> 
>   *SQL Server*
> /Definetly/ not free, jam packed with features, very fast, lots of extras
> 
>   *Sybase and Oracle*
> Can't say, I have no experience with them.
> 
> 
> _Answer to your question_
> Suitable for a high-end commercial application? I'm not sure I would 
> risk my job on it...

Interesting list ... Speed and extras. Not one would be on my list
of most important considerations. How about rating them on:

1. Security
2. Stability
3. Scalability

If it isn't secure who cares how fast it is?
If it isn't stable who cares how many features it has?
If it won't scale to the number of users who gives a rip about extras?

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.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

Daniel Morgan wrote:

> Jeff Rodriguez wrote:
> 
>> _Short Summary_
>>
>>   *PostgreSQL*
>> Free, loaded with features, not particularly fast, some extras
>>
>>   *MySQL*
>> Free, not so loaded with features, very fast, some extras
>>
>>   *SQL Server*
>> /Definetly/ not free, jam packed with features, very fast, lots of extras
>>
>>   *Sybase and Oracle*
>> Can't say, I have no experience with them.
>>
>>
>> _Answer to your question_
>> Suitable for a high-end commercial application? I'm not sure I would 
>> risk my job on it...
> 
> 
> Interesting list ... Speed and extras. Not one would be on my list
> of most important considerations. How about rating them on:
> 
> 1. Security
> 2. Stability
> 3. Scalability
> 
> If it isn't secure who cares how fast it is?
> If it isn't stable who cares how many features it has?
> If it won't scale to the number of users who gives a rip about extras?
> 
> 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.

Would I want to do a database on Windows that was servicing 2000 users? 
No, not really, though I think it might just conceivably stretch that 
far. But 200? Yes. With rather vital data? Yup. Been there, done that. 
Can't mention specific names, but the Australian securities market 
springs to mind.

Windows *is* an operating system. It might not be perfect (which one is? 
  And you're not allowed to mention VMS in your reply to that rhetorical 
question!). And it might have its issues (they all do). It might even 
have more issues than most others. But it does the job, for many people, 
in many circumstances.

As a happy user, at one time or another, of DOS, Windows Kiddie (er, 2.0 
to 98), Windows Proper (NT to XP), Linux, Solaris, Tru64, Novell, BeOS 
and OS X, all have their quirks and all have their perks. I know which 
one I'd implement Oracle on (Linux by choice). And I know which one will 
be easiest to manage (Windows by a long shot).

But life would be far more productive if people would stop dissing the 
tools that others use perfectly happily, and instead were to concentrate 
how to make the best use of *whatever* tools that fall readily to hand.

Regards
HJR

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.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

"Daniel Morgan" <damorgan@x.washington.edu> wrote:-

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

First you exaggerate that any 16 yrd old can bring down SQLServer
and now you exaggerate the need to apply security patch. Did it occur
to you that if your database server is safely behind the firewall,
the need to apply security patches reduces drastically. Almost all
of the security patches is only when your windows is exposed to
the outside world.

Our customers who run our application on SQL Server *always* use
it behind the firewall and one of them has SQL Server up and running
for more than 6 months. No problem for them.

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

This is a different issue. If you want to argue on this, I will
not dispute with you. I also prefer unix over Win, but some of
your criticism against SQLServer (just because it runs on Win only)
is puerile and just shows your insecurity.

Just curious: Have you ever worked with SQLServer.

"rkusenet" <rkusenet@sympatico.ca> wrote in message
news:2gn1l9F3s1d3U1@uni-berlin.de...
> "Daniel Morgan" <damorgan@x.washington.edu> wrote:-
>
> > 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.
>
> First you exaggerate that any 16 yrd old can bring down SQLServer
> and now you exaggerate the need to apply security patch. Did it occur
> to you that if your database server is safely behind the firewall,
> the need to apply security patches reduces drastically. Almost all
> of the security patches is only when your windows is exposed to
> the outside world.
>
> Our customers who run our application on SQL Server *always* use
> it behind the firewall and one of them has SQL Server up and running
> for more than 6 months. No problem for them.
>
> >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.
>
> This is a different issue. If you want to argue on this, I will
> not dispute with you. I also prefer unix over Win, but some of
> your criticism against SQLServer (just because it runs on Win only)
> is puerile and just shows your insecurity.
>
> Just curious: Have you ever worked with SQLServer.
>
>
>

We have a slew of SQL Servers behind a firewall (none are outside it) and we
have to apply the patches monthly.  If we do not then we have what happened
a little over a week ago when the latest worm came out.  We had to apply an
emergency patch in the middle of the day on our production systems that used
Windows.  If we waited the machines would have kept rebooting due to the
worm.  (as they already had 5 times that day).  So don't give me this hooey
that you don't have to patch the servers monthly; we are at the whims of
some teenager in some foreign land. (and sometimes not so foreign)
Jim

rkusenet wrote:

> "Daniel Morgan" <damorgan@x.washington.edu> wrote:-
>
>>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.
> 
> 
> First you exaggerate that any 16 yrd old can bring down SQLServer
> and now you exaggerate the need to apply security patch. Did it occur
> to you that if your database server is safely behind the firewall,
> the need to apply security patches reduces drastically. Almost all
> of the security patches is only when your windows is exposed to
> the outside world.

I didn't exagerate anything ... I asked a question. Please note the
question mark at the end of the sentence.

So you would, in fact, intentionally not apply Microsoft security
patches to your database servers. That is certainly one choice.

> Our customers who run our application on SQL Server *always* use
> it behind the firewall and one of them has SQL Server up and running
> for more than 6 months. No problem for them.

Which is only possible if you never applied a security patch. Once
again ... a choice.

>>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.
> 
> This is a different issue. If you want to argue on this, I will
> not dispute with you. I also prefer unix over Win, but some of
> your criticism against SQLServer (just because it runs on Win only)
> is puerile and just shows your insecurity.
> 
> Just curious: Have you ever worked with SQLServer.

I don't criticize it "just" because it only runs on Windows. That is
just one argument among many. We could, for example, look at the
inability to cluster servers without federating data and many other
things. But that wasn't the point of the post to which I responded
and I'm not interested in starting another meaningless flame war.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

Daniel Morgan wrote:
> rkusenet wrote:
> 
>> "Daniel Morgan" <damorgan@x.washington.edu> wrote:-
>>
>>> 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.
>>
>>
[snip]

Following on in this current 'just curious' vein, why are any of your 
database servers accessible from the internet?

Steve

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.

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

Regards
HJR

"Daniel Morgan" <damorgan@x.washington.edu> wrote

> > First you exaggerate that any 16 yrd old can bring down SQLServer
> > and now you exaggerate the need to apply security patch. Did it occur
> > to you that if your database server is safely behind the firewall,
> > the need to apply security patches reduces drastically. Almost all
> > of the security patches is only when your windows is exposed to
> > the outside world.
>
> I didn't exagerate anything ... I asked a question. Please note the
> question mark at the end of the sentence.

This is the not the first time. All ur rants against Windows is
well chronicled. didn't you predict that the day is not far off
when a virus in T-SQL will float around.

> So you would, in fact, intentionally not apply Microsoft security
> patches to your database servers. That is certainly one choice.
> Which is only possible if you never applied a security patch. Once
> again ... a choice.

Applying a patch becomes moot if it does not even apply to you.
If it does become critical, I assure you necessity overrides anything.


> I don't criticize it "just" because it only runs on Windows. That is
> just one argument among many. We could, for example, look at the
> inability to cluster servers without federating data and many other
> things. But that wasn't the point of the post to which I responded
> and I'm not interested in starting another meaningless flame war.

I guess teaching in Univ. has made you a bit of theoretician. Go out
and check the real world. There are many users who are perfectly
happy with windows and it serves them very well. Not necessary piss ant
customers. Some real big ones. I work in one such industry where SS is
firmly enterenched.

Howard J. Rogers wrote:

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

That may be true of 'your' customers. But not one of mine would find
that acceptable.

Well maybe those with RAC taking down nodes once at a time. But
otherwise they expect to be up 7x24x365. It is very hard to explain
to your web customers that you are interrupting their book purchase
or that the search they wanted to do will have to wait ... or ...
we're terribly sorry you can't purchase plane tickets or check your
bank balance for awhile.

It just isn't acceptable.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

rkusenet wrote:

>>I didn't exagerate anything ... I asked a question. Please note the
>>question mark at the end of the sentence.
> 
> 
> This is the not the first time. All ur rants against Windows is
> well chronicled. didn't you predict that the day is not far off
> when a virus in T-SQL will float around.

So rather than acknowledging that you misread, intentionally or
otherwise, what I wrote you've decided to play the children's game
of changing the subject. You'll have to play that diversion game with
someone else.

Perhaps this will help you:
http://www.ubersoft.net/d/20040507.html

And be careful about your other presumptions ... they are equally
likely to be incorrect ... make that 100% likely.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

"Jim Kennedy" <kennedy-downwithspammersfamily@attbi.net> wrote in message
news:bWupc.6750$gr.523362@attbi_s52...
> We have a slew of SQL Servers behind a firewall (none are outside it) and
we
> have to apply the patches monthly.  If we do not then we have what
happened
> a little over a week ago when the latest worm came out.  We had to apply
an
> emergency patch in the middle of the day on our production systems that
used
> Windows.  If we waited the machines would have kept rebooting due to the
> worm.  (as they already had 5 times that day).  So don't give me this
hooey
> that you don't have to patch the servers monthly; we are at the whims of
> some teenager in some foreign land. (and sometimes not so foreign)
> Jim
>
>

I will give you that hooey.  While in most cases we are quite religious
about applying patches, for reasons I can't get into, we could not apply the
patches against Slammer for months.  And yet, Slammer had ZERO effect on us.
Why?  Because there are other security measures besides patches.  If someone
can't reach your SQL Server, then they can't Slammer to it.  If you're
getting hit, even behind the firewall, you've suffered from the jelly donut
issue and have a bigger issue than applying patches during the middle of the
day.

"Daniel Morgan" <damorgan@x.washington.edu> wrote in message
news:1084657054.933581@yasure...
>
> So you would, in fact, intentionally not apply Microsoft security
> patches to your database servers. That is certainly one choice.
>

Yes, in fact in many cases I would not.

Keep in mind, that most hotfixes are NOT regression tested and there's
always a fairly good sized risk from applying them.

Note the actual number of patches that apply to SQL Server vs. say IE or
Windows Media Player, etc.

In most cases those have little to no reason to be ON your SQL Server in the
first place, so applying a hotfix is generally a HIGHER risk than not
applying it.

(note Service Packs are regression tested and we tend to be much more likely
to apply those.)


> > Our customers who run our application on SQL Server *always* use
> > it behind the firewall and one of them has SQL Server up and running
> > for more than 6 months. No problem for them.
>
> Which is only possible if you never applied a security patch. Once
> again ... a choice.

Yes, of course it's a choice.  Your point?

Daniel Morgan wrote:
> Howard J. Rogers wrote:
> 
>> 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.
> 
> 
> That may be true of 'your' customers. But not one of mine would find
> that acceptable.

Daniel. Before you type, why don't you read? And why don't you just stop 
to pause a little and think who comes to this group?

I frankly couldn't care about *your* customers. I carefully didn't 
include them in my comments by using the word "most".

I didn't make any sweeping statements about *my* customers either. That 
also is the function of the word "most".

If you actually took time to read and consider what others posted here, 
you wouldn't come up with some of the smartass comments that you do.


> Well maybe those with RAC taking down nodes once at a time. But
> otherwise they expect to be up 7x24x365. It is very hard to explain
> to your web customers that you are interrupting their book purchase
> or that the search they wanted to do will have to wait ... or ...
> we're terribly sorry you can't purchase plane tickets or check your
> bank balance for awhile.
> 
> It just isn't acceptable.

That's just fine and dandy, and FOR THAT REASON, you wouldn't recommend 
they use Windows. Perfectly understandable, perfectly reasonable. A 
*reasoned* business decision.

But I wasn't talking about your customers. I was talking about the 
*generality* of customers on the planet *as a whole*. And *they*, my 
friend, might very well (correction: do) find Windows a perfectly 
acceptable platform on which to run vital and important databases. 
Monthly patching and 1 minute downtime due to patching-inspired reboots
included.

What I'm asking you to do, Daniel, is to lift your nose from *your* 
perspective and *your* customers, and consider a rather bigger picture.

And if you did that, you wouldn't be sitting there rubbishing one of the 
more common operating systems a wide-perspective DBA is likely to 
encounter in his/her professional career.

That is all.

HJR

"Greg D. Moore (Strider)" <mooregr_deleteth1s@greenms.com> wrote in message
news:ClCpc.192539$M3.152517@twister.nyroc.rr.com...
>
> "Jim Kennedy" <kennedy-downwithspammersfamily@attbi.net> wrote in message
> news:bWupc.6750$gr.523362@attbi_s52...
> > We have a slew of SQL Servers behind a firewall (none are outside it)
and
> we
> > have to apply the patches monthly.  If we do not then we have what
> happened
> > a little over a week ago when the latest worm came out.  We had to apply
> an
> > emergency patch in the middle of the day on our production systems that
> used
> > Windows.  If we waited the machines would have kept rebooting due to the
> > worm.  (as they already had 5 times that day).  So don't give me this
> hooey
> > that you don't have to patch the servers monthly; we are at the whims of
> > some teenager in some foreign land. (and sometimes not so foreign)
> > Jim
> >
> >
>
> I will give you that hooey.  While in most cases we are quite religious
> about applying patches, for reasons I can't get into, we could not apply
the
> patches against Slammer for months.  And yet, Slammer had ZERO effect on
us.
> Why?  Because there are other security measures besides patches.  If
someone
> can't reach your SQL Server, then they can't Slammer to it.  If you're
> getting hit, even behind the firewall, you've suffered from the jelly
donut
> issue and have a bigger issue than applying patches during the middle of
the
> day.
>
>
>

You are probably in a small shop then.  We have tens of thousands of
computers on our global network.  Bank of America got hit, Siebel's site was
down for days.  Yet look at Sun or Oracle, nary a hiccup.  Gee, might be a
pattern here....  I guess we could do what the CIA and NSA do and make sure
there isn't a connection to the outside world, the ultimate firewall.
Jim

Howard J. Rogers wrote:
>>
>> That may be true of 'your' customers. But not one of mine would find
>> that acceptable.
> 
> Daniel. Before you type, why don't you read? And why don't you just stop 
> to pause a little and think who comes to this group?

I've thought about it. What conclusion would you like me to reach?
I think the people that come here, and please note this is going to
two different groups, are interested in multiple opinions ... and in
the end make up their own minds based on their situation.

> That's just fine and dandy, and FOR THAT REASON, you wouldn't recommend 
> they use Windows. Perfectly understandable, perfectly reasonable. A 
> *reasoned* business decision.

I didn't say the words you put in my mouth. There are times when Windows
is the appropriate solution. But that said ... one makes that decision
based on understanding the reality of the impact it will have on every
aspect of the database and its operations.

The thread I was responding two, if you review it, will clearly show
that the first posting related to a list that seemed to sum up
decision making as based on performance and extras. I pointed out
that there were more important considerations such as security,
stability, and scalability.

That you have latched onto a single sentence about Windows in which I
made reference to its specific issues related to stability is your
decision and a segue from the point I was trying to make.

> That is all.

Hopefully  ;-)
> 
> HJR

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

Jim Kennedy wrote:

> "Greg D. Moore (Strider)" <mooregr_deleteth1s@greenms.com> wrote in message
> news:ClCpc.192539$M3.152517@twister.nyroc.rr.com...
> 
>>"Jim Kennedy" <kennedy-downwithspammersfamily@attbi.net> wrote in message
>>news:bWupc.6750$gr.523362@attbi_s52...
>>
>>>We have a slew of SQL Servers behind a firewall (none are outside it)
> 
> and
> 
>>we
>>
>>>have to apply the patches monthly.  If we do not then we have what
>>
>>happened
>>
>>>a little over a week ago when the latest worm came out.  We had to apply
>>
>>an
>>
>>>emergency patch in the middle of the day on our production systems that
>>
>>used
>>
>>>Windows.  If we waited the machines would have kept rebooting due to the
>>>worm.  (as they already had 5 times that day).  So don't give me this
>>
>>hooey
>>
>>>that you don't have to patch the servers monthly; we are at the whims of
>>>some teenager in some foreign land. (and sometimes not so foreign)
>>>Jim
>>>
>>>
>>
>>I will give you that hooey.  While in most cases we are quite religious
>>about applying patches, for reasons I can't get into, we could not apply
> 
> the
> 
>>patches against Slammer for months.  And yet, Slammer had ZERO effect on
> 
> us.
> 
>>Why?  Because there are other security measures besides patches.  If
> 
> someone
> 
>>can't reach your SQL Server, then they can't Slammer to it.  If you're
>>getting hit, even behind the firewall, you've suffered from the jelly
> 
> donut
> 
>>issue and have a bigger issue than applying patches during the middle of
> 
> the
> 
>>day.
>>
>>
>>
> 
> 
> You are probably in a small shop then.  We have tens of thousands of
> computers on our global network.  Bank of America got hit, Siebel's site was
> down for days.  Yet look at Sun or Oracle, nary a hiccup.  Gee, might be a
> pattern here....  I guess we could do what the CIA and NSA do and make sure
> there isn't a connection to the outside world, the ultimate firewall.
> Jim

Thanks Jim because I think you are absolutely correct. Small shops don't
need a lot of things required by larger shops. My customers tend to be
in telecommunications, aerospace, government, and many with 7x24x365 web
sites. Being off-line is something for which they have a dollar figure
calculated and in some cases that dollar figure is very very large.
When servers come down, and/or an SLA is not met ... people lose their
jobs.

If that is not true in a smaller shop, or in another country, on that
I can not comment. But those persons need to at least appreciate the
nature of their environment and the fact that their decisions is a good
one within their specific context only. There is no context in which
having a server that doesn't need to be off-lined is a bad thing.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

Daniel Morgan wrote:
> Howard J. Rogers wrote:
> 
>>>
>>> That may be true of 'your' customers. But not one of mine would find
>>> that acceptable.
>>
>>
>> Daniel. Before you type, why don't you read? And why don't you just 
>> stop to pause a little and think who comes to this group?
> 
> 
> I've thought about it. What conclusion would you like me to reach?

That the people who come here are a wide and varied bunch, and the fact 
that *your* customers need to run 24x7x365 is not sufficient 
justification for rubbishing the O/S and database they have decided to use.

> I think the people that come here, and please note this is going to
> two different groups,

I am quite well aware of the fact.

> are interested in multiple opinions ... and in
> the end make up their own minds based on their situation.

Rubbishing one of the most common O/Ses, and one of the top three 
RDBMSs, does not constitute an 'opinion'. It is, however, something you 
do a lot of. Not on any technical basis, because that might be a 
discussion worth having, but because "my customers wouldn't find that 
acceptable".

>> That's just fine and dandy, and FOR THAT REASON, you wouldn't 
>> recommend they use Windows. Perfectly understandable, perfectly 
>> reasonable. A *reasoned* business decision.
> 
> 
> I didn't say the words you put in my mouth.

More's the pity then, because they are reasonable words. Although it 
helps not to snip the context in which they were said, and if you are 
going to snip (which is actually most unlike you) to indicate that you 
have done so.

> There are times when Windows
> is the appropriate solution. But that said ... one makes that decision
> based on understanding the reality of the impact it will have on every
> aspect of the database and its operations.
> 
> The thread I was responding two, 
> if you review it, will clearly show
> that the first posting related to a list that seemed to sum up
> decision making as based on performance and extras. I pointed out
> that there were more important considerations such as security,
> stability, and scalability.

No, Daniel. That is called "re-writing history". You didn't make 
reasoned comments about those three things, but said Windows was 
insecure, needed patches all the time and so on. What I have called 
"rubbishing Windows". I was merely trying to point out that a reasoned 
business decision can be made for running on Windows because security 
and stability and scalability can be managed in a way that will keep the 
vast majority of customers happy.

Rather than graciously accept that a reasoned business decision might 
actually favour Windows and SQL Server from time to time, you simply 
announced "well, that wouldn't suit my customers".

My point was then: so effing what? Or put another way, your experience, 
with your customers, doesn't (obviously) qualify you to comment on the 
experience and needs of the vast majority of O/S and RDBMS users on the 
face of this planet.

> That you have latched onto a single sentence about Windows in which I
> made reference to its specific issues related to stability is your
> decision and a segue from the point I was trying to make.

No, not a single sentence. An attitude that speaks volumes.

> 
>> That is all.
> 
> 
> Hopefully  ;-)

Why? Do you dislike having to actually justify the sweeping statements 
you are occasionally prone to making?

Humility, Daniel, consists in part in understanding that your particular 
experiences are not necessarily indicative of the experiences of others. 
You could try it sometime.

HJR

Howard J. Rogers wrote:

> Daniel Morgan wrote:
> 
>> Howard J. Rogers wrote:
>>
>>>> That may be true of 'your' customers. But not one of mine would find
>>>> that acceptable.
>>>
>>> Daniel. Before you type, why don't you read? And why don't you just 
>>> stop to pause a little and think who comes to this group?
>>
>> I've thought about it. What conclusion would you like me to reach?
> 
> That the people who come here are a wide and varied bunch, and the fact 
> that *your* customers need to run 24x7x365 is not sufficient 
> justification for rubbishing the O/S and database they have decided to use.

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.

>> are interested in multiple opinions ... and in
>> the end make up their own minds based on their situation.
> 
> Rubbishing one of the most common O/Ses, and one of the top three 
> RDBMSs, does not constitute an 'opinion'. It is, however, something you 
> do a lot of. Not on any technical basis, because that might be a 
> discussion worth having, but because "my customers wouldn't find that 
> acceptable".

You think it is an 'opinion' that major corporations reported spending
billions last year downing servers and cleaning up after a variety of
worms? You think all of the down time suffered by US banks and other
financial institutions is an opinion? That hospitals have had pharmacy
systems stop functioning while trying to get meds to patients an
opinion?

Give me a break Howard. It is not an opinion ... it is documented
non-disputable fact.

Maybe you have some version of Windows down there in Australia that
doesn't require patching? Or maybe there are no viruses or worms
that infect systems south of the equator? Or maybe you think that
the only companies using Microsoft products are such light-weights
that they don't care if their systems come down regularly. But among
my clients last year was the largest toy company on the planet. Their
Oracle system was, and still is, on Win2K. And they are not exactly
happy with the number of sales they lost due to down-time related to
the operating system ... not the database.

>> There are times when Windows
>> is the appropriate solution. But that said ... one makes that decision
>> based on understanding the reality of the impact it will have on every
>> aspect of the database and its operations.
>>
>> The thread I was responding two, if you review it, will clearly show
>> that the first posting related to a list that seemed to sum up
>> decision making as based on performance and extras. I pointed out
>> that there were more important considerations such as security,
>> stability, and scalability.
> 
> No, Daniel. That is called "re-writing history". You didn't make 
> reasoned comments about those three things, but said Windows was 
> insecure, needed patches all the time and so on.

Are you going to accuse Microsoft this same blasphemy?

http://www.microsoft.com/downloads/search.aspx?DisplayLang=en&ExpandTopList=true

I count 17 security patches that you apparently choose to ignore because
you are behind a firewall: Fine! Some of us have had experiences that
demonstrate that your strategy is not fool-proof. And far from it have
experienced very expensive outages.

> Rather than graciously accept that a reasoned business decision might 
> actually favour Windows and SQL Server from time to time, you simply 
> announced "well, that wouldn't suit my customers".

Are you serious? I use Windows. I have customers that use Windows. But
we go into it understanding that it is a limitation. If you have a list
of specifications under which you think SQL Server on Windows is a
better choice than Sybase or Informix on Linux by all means put it
forward. Just please address the points I originally raised ...
security, stability, and scalability ... not extras.

> My point was then: so effing what? Or put another way, your experience, 
> with your customers, doesn't (obviously) qualify you to comment on the 
> experience and needs of the vast majority of O/S and RDBMS users on the 
> face of this planet.

Nor does yours. So why so much angst over this? You have an opinion. I
have an opinion. So what? Why so much adrenaline over a matter of so
little consequence?

> No, not a single sentence. An attitude that speaks volumes.

By all means tell me what my attitude is. I really want to know?

> Why? Do you dislike having to actually justify the sweeping statements 
> you are occasionally prone to making?

If you don't like my sweeping statements ... contradict them with facts
not emotions. Do you wish to dispute the cost to industry for dealing
with Windows security issues? If so ... have at it.

Start by going to Google and putting in the following search criterion:
"Cost of" AND "Windows Security"

> Humility, Daniel, consists in part in understanding that your particular 
> experiences are not necessarily indicative of the experiences of others. 
> You could try it sometime.

Have you considered looking into a mirror when making such statements?
You are criticizing me for exactly, and I do mean EXACTLY, what you are
doing yourself. Have a beer and relax. This is software not the possible
end of civilization as we know it.

> HJR

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

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?
If it isn't stable who cares how many features it has?
If it won't scale to the number of users who gives a rip about extras?

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

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

[snip]

> You think it is an 'opinion' that major corporations reported spending
> billions last year downing servers and cleaning up after a variety of
> worms? You think all of the down time suffered by US banks and other
> financial institutions is an opinion? That hospitals have had pharmacy
> systems stop functioning while trying to get meds to patients an
> opinion?
> 
> Give me a break Howard. It is not an opinion ... it is documented
> non-disputable fact.

Once again, you've missed (ie, changed) the point. I haven't commented 
at all on the above, or suggested anything about it. What I have said is 
that your one-liner response to me that "my customers wouldn't find that 
acceptable" is not sufficient as a basis for rubbishing an entire 
platform. And that you might broaden your horizons a little and realise 
that many, many businesses and organisations find what you find so easy 
to diss a perfectly acceptable platform on which to run rather important 
business-critical databases and related functions.

> Maybe you have some version of Windows down there in Australia that
> doesn't require patching? Or maybe there are no viruses or worms
> that infect systems south of the equator? Or maybe you think that
> the only companies using Microsoft products are such light-weights
> that they don't care if their systems come down regularly. But among
> my clients last year was the largest toy company on the planet. Their
> Oracle system was, and still is, on Win2K. And they are not exactly
> happy with the number of sales they lost due to down-time related to
> the operating system ... not the database.

Then they should consider changing their operating system, clearly. And 
that's a decision that would seem to be based upon business needs versus 
technical realities. But for every Daniel that is dealing with Boeing, 
Amazon and the biggest toy company on the planet, there will be 
thousands of other DBAs who are not, and where the needs v realities 
assessment will suggest other outcomes. And (here's the real point) when 
you post, you might attempt to give some room for them and their 
decision-making processes, and not seek or seem to dismiss them as being 
ill-informed or badly done.

[snip]

> I count 17 security patches that you apparently choose to ignore because
> you are behind a firewall: Fine! Some of us have had experiences that
> demonstrate that your strategy is not fool-proof. And far from it have
> experienced very expensive outages.

It isn't my strategy, and I didn't say I would ignore them. I said that 
there can be a bit more intelligence applied to the business of 
installing them than you appear to give credit to. And that, for me, and 
for many of my customers, and for most customers around the world, I 
suspect, a minute or so of downtime a month as a consequence of NOT 
ignoring them would be acceptable.

That's all. I'm not in Microsoft's corner. I'm not making claims for the 
O/S which you seem to think I'm making. I personally wouldn't install 
Oracle, for example, onto anything other than Linux or Unix if I had a 
choice in the matter, though that has more to do with memory management 
than anything else. But I wouldn't dismiss an entire operating system in 
5 lines of thoughtlessness, either.

 >> Rather than graciously accept that a reasoned business decision 
might >> actually favour Windows and SQL Server from time to time, you 
simply >> announced "well, that wouldn't suit my customers".
> Are you serious? 

Your post is on the record. It started with the line "That may be true 
of 'your' customers. But not one of mine would find
that acceptable." Even though now, apparently, one of them does, somehow.

So yes, I am serious.

>I use Windows.

Of course you do. Most people do, you know.

> I have customers that use Windows. But
> we go into it understanding that it is a limitation. 

Case closed.

>If you have a list
> of specifications under which you think SQL Server on Windows is a
> better choice than Sybase or Informix on Linux by all means put it
> forward. Just please address the points I originally raised ...
> security, stability, and scalability ... not extras.

I did address them. But apparently "not one of [your] customers would 
find it acceptable" to do likewise, so they weren't worthy of further 
discussion by you.

That is my point.

>> My point was then: so effing what? Or put another way, your 
>> experience, with your customers, doesn't (obviously) qualify you to 
>> comment on the experience and needs of the vast majority of O/S and 
>> RDBMS users on the face of this planet.
> 
> 
> Nor does yours. So why so much angst over this? You have an opinion. I
> have an opinion. So what? Why so much adrenaline over a matter of so
> little consequence?

Because, Daniel, this isn't a matter of my opinion versus yours, but of 
a global reality versus your ego, apparently.

Not that, even so, this is a matter of adrenaline on my part at least. 
Just an attempt to extract a modicum of moderation from you. A smidgen 
of a realisation that your work history is not perhaps representative. 
That others, lots of them, might find perfectly reasonable, scalable, 
secure and stable solutions using technology you simply see as a limitation.

That the Book of Daniel is not necessarily a gospel for our times.

>> No, not a single sentence. An attitude that speaks volumes.
> 
> 
> By all means tell me what my attitude is. I really want to know?

Please read my posts, then.

>> Why? Do you dislike having to actually justify the sweeping statements 
>> you are occasionally prone to making?
> 
> 
> If you don't like my sweeping statements ... contradict them with facts
> not emotions. Do you wish to dispute the cost to industry for dealing
> with Windows security issues? If so ... have at it.

Nice try. I haven't attempted to dispute anything but your dismissive 
attitude to one of the most prevalent O/Ses and RDBMSs in use. And you 
might factor that scale of usage into your calculations of why these 
security issues cost so much to deal with whilst you're at it.

> Start by going to Google and putting in the following search criterion:
> "Cost of" AND "Windows Security"
> 
>> Humility, Daniel, consists in part in understanding that your 
>> particular experiences are not necessarily indicative of the 
>> experiences of others. You could try it sometime.
> 
> 
> Have you considered looking into a mirror when making such statements?
> You are criticizing me for exactly, and I do mean EXACTLY, what you are
> doing yourself. 

No, Daniel. I am not. Unlike you, I take an open-minded approach to 
platforms, OSes and RDBMSs, and I wouldn't dismiss one of the most 
prevalent with a 5-line pay-off, nor then attempt to justify it with a 
one-line "My customers wouldn't find it acceptable".

I am on record here as 'hating' Linux, because I find it so damn obscure 
at times. But I use it, regularly, and recommend it to many, because it 
has clear advantages in certain circumstances. Would that you could be 
likewise platform-agnostic.

>Have a beer and relax. This is software not the possible
> end of civilization as we know it.

Nice try yet again. The issue is *you*, Daniel. Not software, which most 
people recognise needs assessing on its case-by-case merits. Nor the end 
of civilisation, which isn't actually at issue in this thread. Just you, 
your attitude, and the way you have expressed it in this thread.

The people who write about "M$", "Micro$oft" and "Windoze" are similarly 
encumbered. It's a silly attitude to have, frankly. More to the point, 
perhaps, it's unprofessional.

But it is clearly brick-wall-and-head time again.

HJR

"Jim Kennedy" <kennedy-downwithspammersfamily@attbi.net> wrote in message
news:AuEpc.19040$6f5.1748445@attbi_s54...
>>
> You are probably in a small shop then.

Huh?  So what you're basically saying is that large shops can ignore basic
security steps and then complain when they get bit?

It doesn't matter if I have 1 or 1000 SQL Servers, the basic security steps
(such as blocking port 1433 to the outside world) are the same.  If
corporations had simply blocked 1433 and 1434 at the firewall, Slammer would
have been a non-event, patches or no patches.


>We have tens of thousands of
> computers on our global network.  Bank of America got hit, Siebel's site
was
> down for days.  Yet look at Sun or Oracle, nary a hiccup.  Gee, might be a
> pattern here....  I guess we could do what the CIA and NSA do and make
sure
> there isn't a connection to the outside world, the ultimate firewall.

Funny though.  I can get to servers of the CIA and the NSA.  But I can't get
to critical systems.  So if you "guess" you could do that, I'd suggest
that's exactly what you do.  Partitioning systems that are required to be
secure from non-secure systems is basic security 101.

The biggest pattern I've seen is that most Windows administrators don't know
the basics about administering in a high security and high availability
environment.

Take a Unix administrator w/o a snobbish attitude (and yes, I've found quite
a few that are snobs and a number that are open-minded) and you'll find that
many of the same techniques that can be used to secure Unix systems and make
them highly available can be applied to Windows systems with similar degrees
of success.

The problem in my experience is not so much the OS as the operators.


> Jim
>
>

"Daniel Morgan" <damorgan@x.washington.edu> wrote in message
news:1084719755.450820@yasure...
> Jim Kennedy wrote:
>
> Thanks Jim because I think you are absolutely correct.

No he isn't.

> Small shops don't
> need a lot of things required by larger shops.

Wrong.  SOME small shops don't need a lot of the things required by larger
shops.  And some do.  And some larger shops don't need them.


>My customers tend to be
> in telecommunications, aerospace, government, and many with 7x24x365 web
> sites. Being off-line is something for which they have a dollar figure
> calculated and in some cases that dollar figure is very very large.
> When servers come down, and/or an SLA is not met ... people lose their
> jobs.

    That can be just as true for smaller shop.

    You build your system based on your requirements.  If you need 24x7x365,
you'll pay what's require, large shop or small.

>
> If that is not true in a smaller shop, or in another country, on that
> I can not comment.

And yet you just did above.

> But those persons need to at least appreciate the
> nature of their environment and the fact that their decisions is a good
> one within their specific context only. There is no context in which
> having a server that doesn't need to be off-lined is a bad thing.

I'll tell that to my CFO next time I'm budgetting an upgrade.  "Sir, we only
use this system 9-5 and even then only 2-3 people use it. If it's down, they
can work on other stuff w/o any loss in effeciency.  But we need to build a
clustered HA environment, since there's no context where having a server
that doesn't need to be off-lined is a bad thing."

I'll let you know how he takes that.

(btw, I do have a database that basically meets the above requirement and
it's doing just fine on Access.)


>
> -- 
> Daniel Morgan
> http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
> http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
> damorgan@x.washington.edu
> (replace 'x' with a 'u' to reply)
>

"Greg D. Moore (Strider)" <mooregr_deleteth1s@greenms.com> wrote in message
news:PPRpc.199824$M3.111450@twister.nyroc.rr.com...
>
> "Jim Kennedy" <kennedy-downwithspammersfamily@attbi.net> wrote in message
> news:AuEpc.19040$6f5.1748445@attbi_s54...
> >>
> > You are probably in a small shop then.
>
> Huh?  So what you're basically saying is that large shops can ignore basic
> security steps and then complain when they get bit?
>
> It doesn't matter if I have 1 or 1000 SQL Servers, the basic security
steps
> (such as blocking port 1433 to the outside world) are the same.  If
> corporations had simply blocked 1433 and 1434 at the firewall, Slammer
would
> have been a non-event, patches or no patches.
>
>
Fire wall is blocked on those ports and many more, has been for a many
years.  That's not the problem.  The problem is when one of these things
gets inside the firewall then the firwall doesn't help much does it?  Gee,
don't have this problem on port 1521 with Oracle.  If it were as shoddily
written as MS SQLServer's security  you know people would be attacking it
and it would be in the news.  It isn't because the products come from 2
different mind sets.  When someone's mainframe goes down or suffers an
undexpected service interuption then the CEO is on the phone with the CEO of
the mainframe company demanding to know why and when the fix is going to be
installed.  I remember encountering a problem with Oracle's SQLNet product
to DB2 running on a mainframe, where if the client rebooted it locked up a
CPU on the mainframe.  American Transtech called Oracle and Oracle had
someone out there to fix it the next morning. (from California to
Jacksonville)  When someone's PC goes down people don't call MS (because
that is useless); they just reboot and hope it goes away.  Same project.
Tried a sophisticated mail merge with Word and the OS would crash after 50
documents (Windows 3.11 which was the latest version at the time) due to a
memory leak in Word and Excel.  Sent MS a test case and they admitted it was
a defect.  No solution, it might get fixed some day.  Never mind we had to
do a mail merge of 150,000 letters and documents.  We had paid about
$350,000 for super special support from MS and that was the best they could
do, tell us to wait for some future release and it might be fixed then,  50
at a time wasn't going to cut the mustard.  We switched to WordPerfect.

But clearly the company attitudes are very different with regards to
stability, security, and performance.  I agree that one should use the right
tool for the right job.  However, one should also look at all the costs one
is going to occur in using the tool.  (unexpected downtime, loss of data,
performance etc.)  If the trade offs are okay, go for it; just don't be
niave they don't exist.


> >We have tens of thousands of
> > computers on our global network.  Bank of America got hit, Siebel's site
> was
> > down for days.  Yet look at Sun or Oracle, nary a hiccup.  Gee, might be
a
> > pattern here....  I guess we could do what the CIA and NSA do and make
> sure
> > there isn't a connection to the outside world, the ultimate firewall.
>
> Funny though.  I can get to servers of the CIA and the NSA.  But I can't
get
> to critical systems.  So if you "guess" you could do that, I'd suggest
> that's exactly what you do.  Partitioning systems that are required to be
> secure from non-secure systems is basic security 101.

You can get to their public web servers.  Big woop.  That's as far as you
can get.

>
> The biggest pattern I've seen is that most Windows administrators don't
know
> the basics about administering in a high security and high availability
> environment.

The big problem is that Bill declared the shortest month of the year
security month.  Says a lot doesn't it.  It isn't important to MS.  They
give lip service to it.  When programming security is like performance and
scalability; they are aspects of the job, not things to be bolted on
afterwards.  You have to do them all the time, not "at the end of the
project" if we have time.  That attitude means it isn't important.
MS is mainly a marketing organization,

>
> Take a Unix administrator w/o a snobbish attitude (and yes, I've found
quite
> a few that are snobs and a number that are open-minded) and you'll find
that
> many of the same techniques that can be used to secure Unix systems and
make
> them highly available can be applied to Windows systems with similar
degrees
> of success.
>
> The problem in my experience is not so much the OS as the operators.
You can't fix something broken by design.  How many Security certifications
does SQL Server or Windows 2000 have? (none)
Jim


>
>
> > Jim
> >
> >
>
>

"Jim Kennedy" <kennedy-downwithspammersfamily@attbi.net> wrote in message
news:5lSpc.62944$xw3.3682312@attbi_s04...
> >
> Fire wall is blocked on those ports and many more, has been for a many
> years.  That's not the problem.  The problem is when one of these things
> gets inside the firewall then the firwall doesn't help much does it?

In other words, you have a jelly donut of a network.  Again, why are you
blaming a poor security design on the OS?

>Gee,
> don't have this problem on port 1521 with Oracle.

"So Far".  That's the problem with approaches such as patching to security.
It assumes you know about the threat.  What happens if someone tomorrow
comes out with the Oracle version of slammer?  You're in just as much
trouble.


> If it were as shoddily
> written as MS SQLServer's security  you know people would be attacking it
> and it would be in the news.  It isn't because the products come from 2
> different mind sets.  When someone's mainframe goes down or suffers an
> undexpected service interuption then the CEO is on the phone with the CEO
of
> the mainframe company demanding to know why and when the fix is going to
be
> installed.  I remember encountering a problem with Oracle's SQLNet product
> to DB2 running on a mainframe, where if the client rebooted it locked up a
> CPU on the mainframe.  American Transtech called Oracle and Oracle had
> someone out there to fix it the next morning. (from California to
> Jacksonville)  When someone's PC goes down people don't call MS (because
> that is useless);

It is?  Gee, I guess those times where they've fixed my problems is just a
myth.

"Greg D. Moore (Strider)" <mooregr_deleteth1s@greenms.com> wrote in message
news:bNSpc.200462$M3.149289@twister.nyroc.rr.com...
>
> "Jim Kennedy" <kennedy-downwithspammersfamily@attbi.net> wrote in message
> news:5lSpc.62944$xw3.3682312@attbi_s04...
> > >
> > Fire wall is blocked on those ports and many more, has been for a many
> > years.  That's not the problem.  The problem is when one of these things
> > gets inside the firewall then the firwall doesn't help much does it?
>
> In other words, you have a jelly donut of a network.  Again, why are you
> blaming a poor security design on the OS?

Should read:
" In other words, you have a jelly donut of a network.  Again, why are you
 blaming a poor security design on the poorly designed OS?"

Security is not locking everything up so no one can get to anything.  Sure
you won't have any "breaches", but you won't have any access either.  If the
problem was only Slammer I wouldn't worry about it, but it happens about
aevery 3 or 4 months despite staying up with patches. (and all the attendant
testing before putting a patch into production.  Don't have all that problem
on my UNIX boxes and they get some patches, just not as many and not as
urgent.  Why?  Because the OS is a heck of a lot more secure.  The
manufacture is more careful.  I go by pragmatic experience and not some
nebulose claim that the company's security is at fault.
(eg companys are not hit as hard with attacks on non-windows production
systems, and they do happen, because the supplier is a better more careful
producer of software and hardware.)
>
> >Gee,
> > don't have this problem on port 1521 with Oracle.
>
> "So Far".  That's the problem with approaches such as patching to
security.
> It assumes you know about the threat.  What happens if someone tomorrow
> comes out with the Oracle version of slammer?  You're in just as much
> trouble.
>

I assure you that if it was vulerable it would have happened. Larry put out
the Unbeakable challange in 8i (years ago) and of course attracted a lot of
hackers.  Nothing came of it and it has been years.  As I said before, it is
a matter of what the vendor thinks is important.  MS doesn't think its
important.
>
> > If it were as shoddily
> > written as MS SQLServer's security  you know people would be attacking
it
> > and it would be in the news.  It isn't because the products come from 2
> > different mind sets.  When someone's mainframe goes down or suffers an
> > undexpected service interuption then the CEO is on the phone with the
CEO
> of
> > the mainframe company demanding to know why and when the fix is going to
> be
> > installed.  I remember encountering a problem with Oracle's SQLNet
product
> > to DB2 running on a mainframe, where if the client rebooted it locked up
a
> > CPU on the mainframe.  American Transtech called Oracle and Oracle had
> > someone out there to fix it the next morning. (from California to
> > Jacksonville)  When someone's PC goes down people don't call MS (because
> > that is useless);
>
> It is?  Gee, I guess those times where they've fixed my problems is just a
> myth.
Logic problems are not the same as finding a major problem with a vendor's
product.  I love it that you haven't given one example where you found a new
(new to the vendor - MS)  critical (to you) flaw in their software and they
produced a patch for you.  You can't because MS won't do that.  Had problems
with them for over a decade and not once did they issue a patch to fix my
problem.  Yet, I have with other major software vendor's repeatedly.


>
>
>

"Jim Kennedy" <kennedy-downwithspammersfamily@attbi.net> wrote in message
news:AwTpc.62041$536.10434195@attbi_s03...
> Logic problems are not the same as finding a major problem with a vendor's
> product.  I love it that you haven't given one example where you found a
new
> (new to the vendor - MS)  critical (to you) flaw in their software and
they
> produced a patch for you.  You can't because MS won't do that.  Had
problems
> with them for over a decade and not once did they issue a patch to fix my
> problem.  Yet, I have with other major software vendor's repeatedly.

I can't because that would violate confidentiality agreements.  But they
have in fact done so.

But, I can't give details.   Sorry.

"Greg D. Moore (Strider)" <mooregr_deleteth1s@greenms.com> wrote in message
news:APTpc.201201$M3.20343@twister.nyroc.rr.com...
>
> "Jim Kennedy" <kennedy-downwithspammersfamily@attbi.net> wrote in message
> news:AwTpc.62041$536.10434195@attbi_s03...
> > Logic problems are not the same as finding a major problem with a
vendor's
> > product.  I love it that you haven't given one example where you found a
> new
> > (new to the vendor - MS)  critical (to you) flaw in their software and
> they
> > produced a patch for you.  You can't because MS won't do that.  Had
> problems
> > with them for over a decade and not once did they issue a patch to fix
my
> > problem.  Yet, I have with other major software vendor's repeatedly.
>
> I can't because that would violate confidentiality agreements.  But they
> have in fact done so.
>
> But, I can't give details.   Sorry.
>
>
>
>
>
Of course, I'll believe that.  I'm also looking to buy a bridge over the
East River in NY.
Jim

"Jim Kennedy" <kennedy-downwithspammersfamily@attbi.net> wrote in message
news:7kUpc.63536$iF6.5587443@attbi_s02...
> >
> Of course, I'll believe that.  I'm also looking to buy a bridge over the
> East River in NY.

Jim, believe what you want.

However, I'm not in any market for bridges.  Even with tolls, the upkeep is
often to costly.


> Jim
>
>

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?

Now if you wish to debate whether a particular O/S is or is not those
things that is not the point. First establish that they are not
important criteria. If you can I'll be surprised.

If you can't then we can get into the vaugaries of whether a particular
operating system is or is not more secure, more stable, or more
scalable,  than any other. At which point my preference might well be
OS/390.

> HJR

I've known you a long time Howard and I'm not buying the amount of
adrenaline you've pumped into this thread. I've seen a lot of work
you've done on your website in Linux and not a lot relating to
Windows. A lot relating to Oracle and not a lot relating to SQL Server.
So I'm a bit intrigued ... why this sudden interest in riding like a
White Knight to defend an O/S and product you seem to have little or no
other interest in?

There was a time, way back in the history of this thread, it was
about PostgreSQL. And that is a product I did savage with malice
and aforethought.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

Greg D. Moore (Strider) wrote:

> "So Far".  That's the problem with approaches such as patching to security.
> It assumes you know about the threat.  What happens if someone tomorrow
> comes out with the Oracle version of slammer?  You're in just as much
> trouble.

If they could ... they would ... they haven't. Draw your own conclusion.

Is Oracle impregnable? Of course not. But there is a magnitude or more
of difference between the two environments. And lets be honest and also
acknowledge that there aren't a lot of 16 year olds with HP/UX 11i,
Solaris 2.9, or AIX 5L on their home machines. Sometimes security is
implicit in the cost of the ante.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

Greg D. Moore (Strider) wrote:

> "Jim Kennedy" <kennedy-downwithspammersfamily@attbi.net> wrote in message
> news:AwTpc.62041$536.10434195@attbi_s03...
> 
>>Logic problems are not the same as finding a major problem with a vendor's
>>product.  I love it that you haven't given one example where you found a
> 
> new
> 
>>(new to the vendor - MS)  critical (to you) flaw in their software and
> 
> they
> 
>>produced a patch for you.  You can't because MS won't do that.  Had
> 
> problems
> 
>>with them for over a decade and not once did they issue a patch to fix my
>>problem.  Yet, I have with other major software vendor's repeatedly.
> 
> 
> I can't because that would violate confidentiality agreements.  But they
> have in fact done so.
> 
> But, I can't give details.   Sorry.

Sorry but what you've written is, to use Howard's word, rubbish.

When I discovered a flaw in Microsoft's ODBC 3.0 implementation
Microsoft immediately wrote a custom patch for the Boeing company.
And no one was asked to sign any confidentiality agreement. In fact
that patch was released simultaneously by Microsoft on their web site.

So Microsoft will write custom patches ... if they are required for
general distribution ... and Microsoft does not, from my experience,
ever ask for a confidentiality agreement to cover that which they
would then release to their user base (something I have confirmed
with friends at Microsoft before writing this).

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

"Daniel Morgan" <damorgan@x.washington.edu> wrote in message
news:1084760811.431715@yasure...
> Solaris 2.9, or AIX 5L on their home machines. Sometimes security is
> implicit in the cost of the ante.
>

Wow, there's one I haven't heard before.

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


> -- 
> Daniel Morgan
> http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
> http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
> damorgan@x.washington.edu
> (replace 'x' with a 'u' to reply)
>

"Daniel Morgan" <damorgan@x.washington.edu> wrote in message
news:1084761131.172458@yasure...
>
> Sorry but what you've written is, to use Howard's word, rubbish.
>
> When I discovered a flaw in Microsoft's ODBC 3.0 implementation
> Microsoft immediately wrote a custom patch for the Boeing company.
> And no one was asked to sign any confidentiality agreement. In fact
> that patch was released simultaneously by Microsoft on their web site.

That's nice.  Now please point out wher I said it was Microsoft that was
requiring my confidentiality?

I do have agreements with my employer as to what I can and can't talk about.

And to be honest, this patch was long enough ago (SQL 7.0 or SQL 6.5) that
I'm not about to go look up if my company would be ok me discussing it.

Now, on the other hand, to be fair, in one of their "patches" (SQL 7.0 SP3)
broke functionality for many Full Text Index users.  And their basic answer
to customers was "screw you."

So, it's not always sunshine and roses.

But my point stands, and you've confirmed it for me, that MS has and does
release patches per customer problems.

Sorry if I wasn't clear on who was requiring my confidentiality.  I didn't
mean to imply it was MS.


>
> So Microsoft will write custom patches ... if they are required for
> general distribution ... and Microsoft does not, from my experience,
> ever ask for a confidentiality agreement to cover that which they
> would then release to their user base (something I have confirmed
> with friends at Microsoft before writing this).
>
> -- 
> Daniel Morgan
> http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
> http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
> damorgan@x.washington.edu
> (replace 'x' with a 'u' to reply)
>

"Jim Kennedy" <kennedy-downwithspammersfamily@attbi.net> wrote in message
news:AwTpc.62041$536.10434195@attbi_s03...
>
> I assure you that if it was vulerable it would have happened. Larry put
out
> the Unbeakable challange in 8i (years ago) and of course attracted a lot
of
> hackers.  Nothing came of it and it has been years.  As I said before, it
is
> a matter of what the vendor thinks is important.  MS doesn't think its
> important.

I would agree that nothing on the order of slammer has come of it.

But I wouldn't say "nothing" either.  A quick scan of google can find
article relating to security flaws found in 8i and 9i.

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.

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

> Now if you wish to debate whether a particular O/S is or is not those
> things that is not the point. First establish that they are not
> important criteria. If you can I'll be surprised.

I'd be surprised if, in the course of this dialog, you could actually 
address points I raise without inventing ludicrous suggestions I would 
never have raised (and never did).

> If you can't then we can get into the vaugaries of whether a particular
> operating system is or is not more secure, more stable, or more
> scalable,  than any other. At which point my preference might well be
> OS/390.

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

> I've known you a long time Howard and I'm not buying the amount of
> adrenaline you've pumped into this thread.

I've told you before, but there's no adrenaline pumping here. 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".

They may not be "your" customers. But they still count.

> I've seen a lot of work
> you've done on your website in Linux and not a lot relating to
> Windows. 

In fact, most of my papers and examples are done on Windows first, with 
a Linux differential if needed. There's a lot of linux papers there 
because I had to write up how in God's name to do battle with that 
operating system so I wouldn't forget it the next time.

>A lot relating to Oracle and not a lot relating to SQL Server.

Er, that would be because I wouldn't arrogate to myself the right to 
pass any comment whatsoever about SQL Server, though I use it a lot and 
know it reasonably well.

> So I'm a bit intrigued ... why this sudden interest in riding like a
> White Knight to defend an O/S and product you seem to have little or no
> other interest in?

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). What I am doing is criticising what I consider to be your 
unprofessionalism or arrogance, call it what you will, in "rubbishing" a 
platform as you have done in this thread. 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'. 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

Greg D. Moore (Strider) wrote:

> "Daniel Morgan" <damorgan@x.washington.edu> wrote in message
> news:1084760811.431715@yasure...
> 
>>Solaris 2.9, or AIX 5L on their home machines. Sometimes security is
>>implicit in the cost of the ante.
>>
> 
> 
> Wow, there's one I haven't heard before.
> 
> 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?

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

Greg D. Moore (Strider) wrote:

> "Jim Kennedy" <kennedy-downwithspammersfamily@attbi.net> wrote in message
> news:AwTpc.62041$536.10434195@attbi_s03...
> 
>>I assure you that if it was vulerable it would have happened. Larry put
> 
> out
> 
>>the Unbeakable challange in 8i (years ago) and of course attracted a lot
> 
> of
> 
>>hackers.  Nothing came of it and it has been years.  As I said before, it
> 
> is
> 
>>a matter of what the vendor thinks is important.  MS doesn't think its
>>important.
> 
> 
> I would agree that nothing on the order of slammer has come of it.
> 
> But I wouldn't say "nothing" either.  A quick scan of google can find
> article relating to security flaws found in 8i and 9i.

Every piece of software ever written has flaws. But just like stability,
security, and scalability ... there are no absolutes ... only shades of
gray.

We all make decisions every day as to how much risk we can tolerate.
Hopefully good ones. But we can not make informed decisions based on
marketing hyperbole and product-religious fervour.
-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

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 misunderstanding. 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 
> unprofessionalism 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/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan@x.washington.edu
(replace 'x' with a 'u' to reply)

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

On Mon, 17 May 2004, hjr@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

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
wizofoz2k@yahoo.com.au.nospam

"Quirk" <quirk@syntac.net> schrieb im Newsbeitrag news:4e20d3f.0405121205.4c9ac7e8@posting.google.com...
> "Volker Hetzer" <volker.hetzer@ieee.org> wrote in message news:<c7t3p2$b15$1@nntp.fujitsu-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/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"

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

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

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

"Gawnsoft" <xlucid@users.sourceforge.remove.this.antispam.net> schrieb im Newsbeitrag
news:gmn6a05ku51foi7aghpund00757onjjt33@4ax.com...
> >> 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

"Quirk" <quirk@syntac.net> schrieb im Newsbeitrag news:4e20d3f.0405121614.28ecad7b@posting.google.com...
> "Volker Hetzer" <volker.hetzer@ieee.org> wrote in message news:<c7t0v0$sbv$1@nntp.fujitsu-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 "abstraction" 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

"Howard J. Rogers" <hjr@dizwell.com> wrote in message news:<40a5d165$0$31679$afc38c87@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

Daniel Morgan <damorgan@x.washington.edu> wrote in message news:<1084636038.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?

"Howard J. Rogers" <hjr@dizwell.com> wrote in message news:<40a6ab3f$0$31675$afc38c87@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. 
"Appropriately" 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/games/whiteisle/dndhumor.txt

"Jim Kennedy" <kennedy-downwithspammersfamily@attbi.net> wrote in message news:<5lSpc.62944$xw3.3682312@attbi_s04>...

> 
> But clearly the company attitudes are very different with regards to
> stability, security, and performance.  I agree that one should use the right
> tool for the right job.  However, one should also look at all the costs one
> is going to occur in using the tool.  (unexpected downtime, loss of data,
> performance etc.)  If the trade offs are okay, go for it; just don't be
> niave they don't exist.

This is the real problem.  Most places that use Windows don't know how
and won't pay someone else to properly figure the trade-offs.

> >
> > The problem in my experience is not so much the OS as the operators.
> You can't fix something broken by design.  How many Security certifications
> does SQL Server or Windows 2000 have? (none)

No, the purveyors of the OS made the decision to put ease of use over
security in the face of overwhelming evidence of what most operators
will do.

jg
--
@home.com is bogus.
Buy a lotto ticket lately?

Joel Garry wrote:

[snip]

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

It's not as pat as that.

I know it's not quite the same thing, but I am more than willing -in 
fact, I am desirous- to convert my newish (5 months) laptop to running 
Linux. You know why XP is still on it? Because 3 of the distros refuse 
to even install on it. Fedora and Mandrake do, but neither of them have 
a clue about my 802.11g wireless card. One has a problem with my 
graphics driver. And both have problems with the external firewire drive.

Now I'm sure I could poke around inside /etc/something and fix all that 
up. But Windows gets all of it right, first time, every time, and I 
don't have to fiddle at all. So what's the cost equation there? And if 
it's not true for me that "the same talent pool" can make both work 
equally well, I suspect it's not going to be true for a lot of shops 
without some serious re-training/retrenchment/re-hiring costs.

Now, it's a laptop, and Linux on laptops is a bit tricky generally, and 
that's rather different from the server market, I'll agree. And yes, I 
have Linux servers running Oracle perfectly well. But those are fairly 
old boxes (early Penitum IVs, an Athlon 1200, etc), and not state of the 
art. And I know all about IBM and HP's enthusiastic Linux involvement, 
amongst others.

But I still don't think that you can just trot out the "it loses" 
argument and not justify it case by case (where, many times, Linux will 
justify itself handsomely I have no doubt). But Hardware vendor support? 
Drivers? Linux frequently seems to just play catch-up. Which might, or 
might not, be a show-stopper.

Plus, given the context of the current discussion, there are many 
occasions when someone will positively want to run SQL Server, and 
perfectly justifiably too. At which point, it (Windows) most certainly 
doesn't lose, does it? I don't think Crossover Office quite does SQL 
Server just yet.

Regards
HJR

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

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

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

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

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

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.

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

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.

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

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

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

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

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

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.

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

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

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

You still have the source code.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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

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

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.

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

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.

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

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

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

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

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

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

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.

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

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.

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

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.

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

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.

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

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

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

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

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

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)

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

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.

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

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

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

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?

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

[Oracle and Sybase groups removed]

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

> That IS the licence agreement.

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

> That they should think before they abstract.

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

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

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

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

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

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

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

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

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

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

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

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

And when he gets hit by a bus? 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> Another case on not reading what I write.

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

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

> Which database do you have in mind?

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

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

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

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

> > Yeah, what about them?

> They are dead.

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

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

> I can do that with oracle.

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

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

> I can't because it's unmaintainable.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I am sure the envy is not recipricated.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

No, for there hostages, I agree.

> Who is CA?

Computer Associates.

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

Regards,

"Howard J. Rogers" <hjr@dizwell.com> wrote in message news:<40aa69a3$0$3037$afc38c87@news.optusnet.com.au>...
> It's not as pat as that.
> 
> I know it's not quite the same thing, but I am more than willing -in 
> fact, I am desirous- to convert my newish (5 months) laptop to running 
> Linux. You know why XP is still on it? Because 3 of the distros refuse 
> to even install on it. Fedora and Mandrake do, but neither of them have 
> a clue about my 802.11g wireless card. One has a problem with my 
> graphics driver. And both have problems with the external firewire drive.
> 
> Now I'm sure I could poke around inside /etc/something and fix all that 
> up. But Windows gets all of it right, first time, every time, and I 
> don't have to fiddle at all. So what's the cost equation there? And if 
> it's not true for me that "the same talent pool" can make both work 
> equally well, I suspect it's not going to be true for a lot of shops 
> without some serious re-training/retrenchment/re-hiring costs.

I can't argue with you about your laptotp, but in general Linux has
much better hardware support build inside than Windows. The reason for
this is that even the newest Windows XP are quite old (about two
years), so they're not supporting hardware younger than two years. On
the other hand, any major Linux distribution has new versions
available at least twice a year, not mentioning new kernel releases on
monthly basis.
For example on my one year old PC, Fedora Core 1 just out of the box
can recognize and install all of my hardware. When installing XP I
need to:

1. borrow an ancient device called floppy disc drive, because that's
the only way how to supply a driver for my on-board serial-ATA
controller.

2. install drivers for nForce2 chipset

3. install drivers for Radeon 9700Pro (or enjoy VGA resolution and
colours).

4. install drivers for on-board NIC.

5. install drivers for Audigy 2.

So on my one year old hardware it is not even possible to install the
latest Windows.
People are often confusing operating system hardware support with
having all CDs with drivers around. Is it true, that all hardware is
comming with Windows drivers, but that's a vendor support, not
operating system support.
For Linux users getting an appropriate driver could be more
challenging, but situation is steadily improving and when I needed to
get and install a driver for a brand new Intel 1000 NIC it took less
than five minutes (the same time as on Windows) and was needed only
because of a two year old distribution used (any newer distro has
support for this card already built-in).
So I think the support for hardware is a reason for and not against
Linux. Of course, there could be some problems and some hardware still
needs some tweaking or is not working at all, but that's the problem
of a manufacturer and there is a lot of brands for any component, so
is not a big problem to buy a proper one.

--
Dusan Bolek

Email: spambin@seznam.cz
Pls add "Not Guilty" to the subject, otherwise your email is going to
be burnt as a SPAM.

"Howard J. Rogers" <hjr@dizwell.com> wrote in message news:<40ab3835$0$8990$afc38c87@news.optusnet.com.au>...

> 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, PEAR:DB 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 :)



�

[comp.databases.ms-sqlserver removed]

> Of course, I'll believe that.  I'm also looking to buy a bridge over the
> East River in NY.

Jim, I think you will find life much easier if you simply remove
comp.databases.ms-sqlserver, or any other ms specific groups from your
replies.

There is not point in talking to these people, they are a cult.

Regards,

On 19 May 2004, quirk@syntac.net wrote:

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

-- 
Galen Boyer

Dusan Bolek wrote:

> I can't argue with you about your laptotp, but in general Linux has
> much better hardware support build inside than Windows. 

A little bit of a sneaky word play there, Dusan!  I don't care which O/S 
has better support "inside". I just care which O/S has better support 
period. Whether my drivers have to be sourced from third party websites, 
or are included on the O/S installation CDs, it really doesn't matter.

> The reason for
> this is that even the newest Windows XP are quite old (about two
> years), so they're not supporting hardware younger than two years. On
> the other hand, any major Linux distribution has new versions
> available at least twice a year, not mentioning new kernel releases on
> monthly basis.
> For example on my one year old PC, Fedora Core 1 just out of the box
> can recognize and install all of my hardware. When installing XP I
> need to:
> 
> 1. borrow an ancient device called floppy disc drive, because that's
> the only way how to supply a driver for my on-board serial-ATA
> controller.
> 
> 2. install drivers for nForce2 chipset
> 
> 3. install drivers for Radeon 9700Pro (or enjoy VGA resolution and
> colours).
> 
> 4. install drivers for on-board NIC.
> 
> 5. install drivers for Audigy 2.

As I say, installing drivers is not an issue.

I have to install a driver for my 802.11g network card on Windows XP, 
too. You know what the vendor said when I asked about Linux support: 
"there is a generic driver, but you'll need to recompile your kernel 
before it works". And that was the hardware vendor talking!!

Slightly different, don't you think?

> So on my one year old hardware it is not even possible to install the
> latest Windows.
> People are often confusing operating system hardware support with
> having all CDs with drivers around. Is it true, that all hardware is
> comming with Windows drivers, but that's a vendor support, not
> operating system support.

Well, people may well confuse it, but I don't. Provided a simple driver 
installation is all that's required, to me that counts as 'working first 
time every time'. If it involved registry hacking, different story (but 
it rarely does). If it involves kernel recompilation, forget it!

> For Linux users getting an appropriate driver could be more
> challenging, but situation is steadily improving

Yes, I keep hearing this. And it's true. All I have to do for my laptop 
to work is simply wait until some new distro ships that includes the 2.6 
kernel in-built. Unless I want to get seriously adventurous in the 
meantime.

That isn't an option, of course, when everything works as advertised, 
right now, on this dreadful 2 year-old operating system we call Windows.

> and when I needed to
> get and install a driver for a brand new Intel 1000 NIC it took less
> than five minutes (the same time as on Windows) and was needed only
> because of a two year old distribution used (any newer distro has
> support for this card already built-in).
> So I think the support for hardware is a reason for and not against
> Linux. 

Well, that's an interesting outcome from a logic process: HJR reports 
hardware incompatibilities only for Linux. So let's just say Linux is 
better with hardware than Windows! I suppose it may well be true for 
you. It certainly isn't true for me, though.

> Of course, there could be some problems and some hardware still
> needs some tweaking or is not working at all, but that's the problem
> of a manufacturer

It also happens to be the problem for the *end user* if it's the poor 
end user that's trying to get their system working under Linux!

Now, as I say, me and my laptop are not a particularly good example of 
what will necessarily happen in a server room, and I readily accept that.

Regards
HJR

quirk@syntac.net (Quirk) wrote in message news:<4e20d3f.0405190205.416ed0ce@posting.google.com>...

> 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". 
</nit-picking>

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

> > And in what way is that different if mysql AB goes bust and fails to deliver?
> 
> 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
wizofoz2k@yahoo.com.au.nospam

quirk@syntac.net (Quirk) wrote in message news:<4e20d3f.0405190320.956255b@posting.google.com>...
> 
> 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
--
@home.com is bogus
RIP Leonard Rosenberg 1920-2004.  AKA Tony Randall.  Started having
kids at 77, you dawg!

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

--
Remove the blots from my address to reply

On Wed, 19 May 2004 10:03:34 -0700, Quirk wrote:

> "Howard J. Rogers" <hjr@dizwell.com> wrote in message
> news:<40ab3835$0$8990$afc38c87@news.optusnet.com.au>...
> 
>> 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.

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

"Howard J. Rogers" <hjr@dizwell.com> wrote in message news:<40abd701$0$1583$afc38c87@news.optusnet.com.au>...
> Dusan Bolek wrote:
> I have to install a driver for my 802.11g network card on Windows XP, 
> too. You know what the vendor said when I asked about Linux support: 
> "there is a generic driver, but you'll need to recompile your kernel 
> before it works". And that was the hardware vendor talking!!

<snipped>

 
> Well, people may well confuse it, but I don't. Provided a simple driver 
> installation is all that's required, to me that counts as 'working first 
> time every time'. If it involved registry hacking, different story (but 
> it rarely does). If it involves kernel recompilation, forget it!

It seems to me that we hit the point. For me, a kernel recompilation
is a normal task to be done, but for some people (probably including
you) recompiling of linux kernel still has some aura of an advanced
hacking. It was true in old days (five years before), but now it is an
extremely easy task, almost anyone can do this. Really, try to
reconfigure and recompile some of new 2.6 kernels and you will see
that there is no problem at all. Just:

1. download, untar <- no big deal
2. run make menuconfig and you will get GUI (well it is in text mode,
but it behave like GUI, however X-Win version is also available),
where you can select and unselect anything including drivers (probably
also for your wireless card).
3. make <- compilation starts
4. make modules_install <- instalation of modules, nothing to be worry
about, no option just run
5. make install <- on advanced distributions with GRUB this will also
copy a new kernel into /boot, create initrd file and update your
configuration so your brand new kernel is already in GRUB menu after
reboot!

That's all. Maybe I'm weird, but for me this is much easier than
making my eight year old FDD work (as I remember according to MS and
Intel five years before should FDD alredy be a part of history).

--
Dusan Bolek

Dusan Bolek wrote:

> "Howard J. Rogers" <hjr@dizwell.com> wrote in message news:<40abd701$0$1583$afc38c87@news.optusnet.com.au>...
> 
>>Dusan Bolek wrote:
>>I have to install a driver for my 802.11g network card on Windows XP, 
>>too. You know what the vendor said when I asked about Linux support: 
>>"there is a generic driver, but you'll need to recompile your kernel 
>>before it works". And that was the hardware vendor talking!!
> 
> 
> <snipped>
> 
>  
> 
>>Well, people may well confuse it, but I don't. Provided a simple driver 
>>installation is all that's required, to me that counts as 'working first 
>>time every time'. If it involved registry hacking, different story (but 
>>it rarely does). If it involves kernel recompilation, forget it!
> 
> 
> It seems to me that we hit the point. For me, a kernel recompilation
> is a normal task to be done, but for some people (probably including
> you) recompiling of linux kernel still has some aura of an advanced
> hacking.

That is absolutely true. But just to show I'm not timid, I have printed 
out your mail and am going to try it tomorrow.

However, whether it counts as advanced or not, I would say it's a tad 
more inconvenient than supplying the vendor's drivers!!

> It was true in old days (five years before), but now it is an
> extremely easy task, almost anyone can do this. Really, try to
> reconfigure and recompile some of new 2.6 kernels and you will see
> that there is no problem at all. Just:
> 
> 1. download, untar <- no big deal
> 2. run make menuconfig and you will get GUI (well it is in text mode,
> but it behave like GUI, however X-Win version is also available),
> where you can select and unselect anything including drivers (probably
> also for your wireless card).


Now just you wait a cotton-pickin' minute right there!

*This* is the tricky bit, don't you think!? "Just select or unselect 
anything" makes it sound like the dessert counter at Wendy's. But we've 
not talking varieties of Bavarian Cheesecake, but indecipherable options 
with unfathomable implications.

Well, we were last time I ever tried this.

Oh. And also the last time I ever tried this, I was there for a good 
hour working my way through all the options before giving up.

What you've done here is a bit like the pope saying to Michelangelo, 
"Well, I was thinking of a bit of a paint job".


> 3. make <- compilation starts
> 4. make modules_install <- instalation of modules, nothing to be worry
> about, no option just run
> 5. make install <- on advanced distributions with GRUB this will also
> copy a new kernel into /boot, create initrd file and update your
> configuration so your brand new kernel is already in GRUB menu after
> reboot!
> 
> That's all. Maybe I'm weird, but for me this is much easier than
> making my eight year old FDD work (as I remember according to MS and
> Intel five years before should FDD alredy be a part of history).
> 
> --
> Dusan Bolek

I will give it a go, nonetheless. It's been at least 7 weeks since I 
re-installed my laptop (with XP), and I get a bit stir-crazy after that 
long.

One of the things I actually like about Linux is that it is so awkward 
to use, I tend not to muck around with it much once it's working, and as 
a result, things don't continually and progressively 'degrade' over 
time. Accordingly, my Linux installs last *much* longer than my Windows 
ones.

:-)
HJR

Doug Hutcheson wrote:

> Proposition 1:
> I agree with that proposition.

Disagree.  I can't think of ONE circumstance where that
would be the case IF a commercial db is used.  I can
certainly think of a few if a freeware db is used...

> Proposition 2:
> I agree with that proposition.

1000% agreed.


> Proposition 3:
> I agree with that proposition.

Same as 1.

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

Of course.


> However, I must take issue with Noons, 

of course.


> There are large companies in our industry who are famous for implementing
> backward-incompatibility in new versions of their software. 

Name one and a concrete example in the database business.  You are confusing
M$ with database server vendors.  There IS a difference...

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

So what?  If you have not yet experienced a bug and you have not changed
the application code, why the heck would you need support and/or bug fixes
beyond the support period of the maker?  The thing doesn't exactly "wear off",
does it?  If it works now, it will work in 10 years time.

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

NO it MOST definitely does NOT lock customers into ANY upgrade cycle!
Customers GET locked into the upgrade cycle because they believe
the rubbish put out by nongs like M$.

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

And what makes you think all of a sudden a bug will be found after de-support
that was never found in all the previous years the software was supported?
Software is not mechanical, it doesn't wear off.

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

No way.   What forces them to extensive upgrades is the misguided notion
that something is magically obsolete as soon as the next model is out.
A notion fostered of course by those same commercial makers.  But there is
no book that says you have to follow their "advice".  Same argument as
not buying a new TV every year.

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

What you are saying is the "mysterious bug" that would make the upgrade 
mandatory would show up without source code but magically wouldn't show
up if the customer had "access to the source code"?  Hmmm, I think not....

Anyway: how many "customers" do you know about that could care one iota about
source code anyway?  How many do you know about that even KNOW what a compiler 
is?   Walk into a small business and try to convince them that having source
code is better for them and see how far you get...  99.9999999% of them don't 
even know what you mean by the word "source" and couldn't care less if they did.


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

Me too, after 30 years.  And guess what: the answer is simple.
Do NOT upgrade, unless you absolutely have to.  I know of many customers
still running the SAME hardware and software they were running 10 years ago.

If it works and does the job, don't touch it.  If it doesn't, then find
someone who can fix it.  If it's too old and no one stocks it anymore,
then buy a new one.  What's the problem with that?  It's what the entire
economy is based on...

 > When I am able to offer my customers an alternative to
> this revenue drain, I am happy to do so.

Here is the alternative: if it does the job, do NOT upgrade.  Simple.

-- 
Cheers
Nuno Souto
wizofoz2k@yahoo.com.au.nospam

On Thu, 20 May 2004, wizofoz2k@yahoo.com.au.nospam wrote:
> Doug Hutcheson wrote:
>> 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.
> 
> NO it MOST definitely does NOT lock customers into ANY upgrade
> cycle!  Customers GET locked into the upgrade cycle because
> they believe the rubbish put out by nongs like M$.

Noons,

How many customers of Oracle do you know whom are willing to say
no to having support for their database that is in production?  I
would guess this is a small number, but you may have seen alot
different numbers.

-- 
Galen Boyer

On Thu, 20 May 2004,
doug.blot.hutcheson@nrm.blot.qld.blot.gov.blot.au wrote:

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

How many open-source projects do you know that have developers
fixing bugs on earlier major releases of their codebase?

-- 
Galen Boyer

Galen Boyer wrote:

> How many customers of Oracle do you know whom are willing to say
> no to having support for their database that is in production?  I
> would guess this is a small number, but you may have seen alot
> different numbers.


Heaps different, judging by the very large number of customers
still in V7 and V8.0/8.1.x
Most of them run third party turn-key app(s) and couldn't care
less what Oracle version is or is not supported, provided the darn
thing works without problems.  Simple.

-- 
Cheers
Nuno Souto
wizofoz2k@yahoo.com.au.nospam

Galen Boyer wrote:


> How many open-source projects do you know that have developers
> fixing bugs on earlier major releases of their codebase?

Yup.   Forgot that one, thanks for bringing it up.

-- 
Cheers
Nuno Souto
wizofoz2k@yahoo.com.au.nospam

On Thu, 20 May 2004, wizofoz2k@yahoo.com.au.nospam wrote:
> Galen Boyer wrote:
> 
>> How many customers of Oracle do you know whom are willing to
>> say no to having support for their database that is in
>> production?  I would guess this is a small number, but you may
>> have seen alot different numbers.
> 
> 
> Heaps different, judging by the very large number of customers
> still in V7 and V8.0/8.1.x 

How do you know this number?  

> Most of them run third party turn-key app(s) and couldn't care
> less what Oracle version is or is not supported, provided the
> darn thing works without problems.  Simple.

Ah, those guys.  Yeah, there are probably a boatload of them.

-- 
Galen Boyer

On Thu, 20 May 2004, wizofoz2k@yahoo.com.au.nospam wrote:
> Galen Boyer wrote:
> 
> 
>> How many open-source projects do you know that have developers
>> fixing bugs on earlier major releases of their codebase?
> 
> Yup.   Forgot that one, thanks for bringing it up.

Yes, even the Emacs guys say, "Just upgrade".  No open
source/free software guy wants to work on older code bases.  They
all want to be playing with the latest and greatest.

-- 
Galen Boyer

Noons wrote:
> Galen Boyer wrote:
> 
>> How many customers of Oracle do you know whom are willing to say
>> no to having support for their database that is in production?  I
>> would guess this is a small number, but you may have seen alot
>> different numbers.
> 
> 
> 
> Heaps different, judging by the very large number of customers
> still in V7 and V8.0/8.1.x
> Most of them run third party turn-key app(s) and couldn't care
> less what Oracle version is or is not supported, provided the darn
> thing works without problems.  Simple.
> 

Just about to comment the same: lots of (semi-)governamental
organisations here are still on 7.3, and quite happily so.

What's this "if it aint broke, let's fix it" nowadays?
-- 

Regards,
Frank van Bortel

Galen Boyer wrote:


> How do you know this number?  

As someone who works in a services company who deals with
a large number of Oracle sites, I know.  Having discussed the matter
with a number of members of the AUSOUG, I got the same feedback
from them.  Don't ask me for concrete names and cases, though: the
company is not mine and I don't have the authority to disclose that
information.  And no: I do NOT provide support to old versions.

> Ah, those guys.  Yeah, there are probably a boatload of them.

Yup.  Quite popular with anyone who can't afford to have a dedicated
development team.  Synonym for: the vast majority of potential clients
out there.  They are also the ones likely to run free-ware apps at
some future stage.  Does anyone seriously believe they want to
even *know* how to spell "source"?

-- 
Cheers
Nuno Souto
wizofoz2k@yahoo.com.au.nospam

Frank van Bortel wrote:

> 
> What's this "if it aint broke, let's fix it" nowadays?

When the business model is: "let's not make $$$ out of
selling software, let's make $$$ out of adding value by supporting it",
what do you expect?

-- 
Cheers
Nuno Souto
wizofoz2k@yahoo.com.au.nospam

"Doug Hutcheson" <doug.blot.hutcheson@nrm.blot.qld.blot.gov.blot.au> wrote
in message news:QySqc.2189$IH5.98940@news.optus.net.au...
> 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:
>
> > 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.

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.

> 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
>
> --
> Remove the blots from my address to reply
>
>

quirk@syntac.net (Quirk) wrote in message news:<4e20d3f.0405190320.956255b@posting.google.com>...
> [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
--
@home.com is bogus.
http://non-contradiction.com/ac_works_b31.asp

Noons <wizofoz2k@yahoo.com.au.nospam> wrote in message news:<40ac9f95$0$1586$afc38c87@news.optusnet.com.au>...

> Me too, after 30 years.  And guess what: the answer is simple.
> Do NOT upgrade, unless you absolutely have to.  I know of many customers
> still running the SAME hardware and software they were running 10 years ago.
> 
> If it works and does the job, don't touch it.  If it doesn't, then find
> someone who can fix it.  If it's too old and no one stocks it anymore,
> then buy a new one.  What's the problem with that?  It's what the entire
> economy is based on...

The problem is the applications software is not a small
interchangeable thing.  I know of a company that is running on some
old VMS stuff that was heavily customized.  Their HQ on another
continent was supposed to roll out SAP, but that didn't work for them,
too difficult to customize to their business model or something.  So
now it's even more years later and they are starting all over again,
and perhaps having issues finding the rare obsolete skills to keep the
old stuff going.  So "if it works" depends on definitions, and "buy a
new one" is not a matter of running down to Frye's when they have an
ad for a $400 computer limited to supplies on hand (dang, didn't see
that one till Saturday afternoon -with 17" color monitor, color Canon
printer, buncha USB ports... and no way to tell beforehand if RHAS
would work).

> 
>  > When I am able to offer my customers an alternative to
> > this revenue drain, I am happy to do so.
> 
> Here is the alternative: if it does the job, do NOT upgrade.  Simple.

A balance must be maintained between the wheel and the dead hamster. 
Simply not upgrading is a false economy, since it loses the effect of
getting major enhancements with the development costs amortized among
many other customers.  Eventually you are in a deep hole and have to
spend big capital bucks to get out of it.  That amortization argument
also works against open source, because you have too much
fragmentation and duplication of effort (like all the former linux
variants, for just one example).  Bleeding edgeism is obviously a
mistake for many places, too.

jg
--
@home.com is bogus.
http://www.zapcom.net/~rci/rcigall.htm

"Quirk" <quirk@syntac.net> schrieb im Newsbeitrag news:4e20d3f.0405190205.416ed0ce@posting.google.com...
> [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.

> 
> > > 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.
> 
> 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 4e20d3f.0405110143.3fba4756@posting.google.com.

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

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


> > It depends on how much performance it costs.
> 
> Funny, that's what I said.
Where?


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

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

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

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

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

> 
> > > 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.
> 
> 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 database vendor obviously
> > balances maintenance costs and development costs, trying to minimize both.
> 
> The vendor only tries to maximize profits.
Yes, and where is the contradiction?

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


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

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

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

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


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

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

> 
> > 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.
If it's a viable marked the original support wouldn't have gone bust.

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

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

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

> 
> > > > 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.
> 
> No, I tell you that source gives you freedom to chose, but sadely, 
To choose what exactly? Any supporter out of one?

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

> > 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.
Where? (I mean, before I pushed your nose in it?)


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

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

> > Are you trying to change thread from opensource to abstraction?
> 
> I am not trying to change 'the thread' -- I posted my recomendations,
See the subject line.

> > > 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.
> 
> As I said, there are bad applications, both abstracted and
> unabstracted ones, your argument, is, as usual, a fallacy.
In what way?

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

> 
> > > > 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?
You should have read the next paragraph before responding.

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

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

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

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

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

> 
> > But the abstraction thingie was a nice diversion.
> 
> 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?

"Doug Hutcheson" <doug.blot.hutcheson@nrm.blot.qld.blot.gov.blot.au> wrote in message news:<QySqc.2189$IH5.98940@news.optus.net.au>...

> 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::DB 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)


 

 
> 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

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.

"Niall Litchfield" <niall.litchfield@dial.pipex.com> wrote in message news:<40ad113c$0$20509$cc9e4d1f@news-text.dial.pipex.com>...

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

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

> 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*
 
> > 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 :(

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

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.

On 22 May 2004, quirk@syntac.net wrote:
> "Doug Hutcheson"
> <doug.blot.hutcheson@nrm.blot.qld.blot.gov.blot.au> wrote in
> message news:<QySqc.2189$IH5.98940@news.optus.net.au>...

[...]

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

Do you think the above is solid programming, ie, do you have code
in your codebase with something like the myapp_query function in
it?

If you do, could you post it?

-- 
Galen Boyer

On 22 May 2004, quirk@syntac.net wrote:
> Thanks Nick, your alternative propositions are much clearer
>> > 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 :(
> 
> 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.

I'm a huge free software fan.  Ask anybody who works with me if I
like to talk about Emacs, and they will groan.  But the above
statement has nothing to do with open or closed software and,
frankly, I don't see what point you are making at all.

The bulk of the rest of your statements are the common, database
independence arguments, but they are not referencing free versus
closed source.  Freedom arguments have never been, "if I go with
free I'll be able to migrate".

-- 
Galen Boyer

Joel Garry wrote:

> The problem is the applications software is not a small
> interchangeable thing.  I know of a company that is running on some
> old VMS stuff that was heavily customized.  Their HQ on another

You know of ONE company where it does not apply.  Abnormal case that
by no means defines an industry.


> A balance must be maintained between the wheel and the dead hamster. 
> Simply not upgrading is a false economy, since it loses the effect of
> getting major enhancements with the development costs amortized among
> many other customers.  Eventually you are in a deep hole and have to

If you DO need the new features, then upgrade.  If you don't, stay
where you are.  In what way does having the entire source
code for everything and the kitchen sink help you there?

-- 
Cheers
Nuno Souto
wizofoz2k@yahoo.com.au.nospam

Quirk wrote:

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

-- 
Cheers
Nuno Souto
wizofoz2k@yahoo.com.au.nospam

Noons <wizofoz2k@yahoo.com.au.nospam> wrote in message news:<40af7768$0$3038$afc38c87@news.optusnet.com.au>...

> > 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
 
> It's a pity that you have considered my reply as that of a zealot.
> I did concede a few points and debated yours in a civilized fashion.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I hope this helps.

Regards,
Dmytri.

quirk@syntac.net (Quirk) wrote in message news:<4e20d3f.0405240218.6eedf26e@posting.google.com>...
> Noons <wizofoz2k@yahoo.com.au.nospam> wrote in message news:<40af7768$0$3038$afc38c87@news.optusnet.com.au>...
> However, there is clear zealotry in your post, for example:
> 
> You said: "It's with freeware that you need a STACK of wrappers to
> protect you from sudden underlying code changes!  Not with commercial
> software!"
> 
> See: no other reasoning is given why underlying code may suddenly
> change other than in one case it is _free_, in the other case it is
> _commercial_. This is not a reasoned argument, but rather the faith of
> a zealot.
> 
> Since neither freeness nor commercialness has a direct impact on code
> stability, but rather the release management practices of the
> development group has.
> 
> There are badly managed free software projects, and badly managed
> nonfree ones, your argument is therefore a fallacy, although your
> english, like Volker's is great!

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

--
Dusan Bolek

OMG. this argument is still alive...

IS THERE A PUNCH LINE ANYWAY NEAR?

"Quirk" <quirk@syntac.net> wrote in message
news:4e20d3f.0405240218.6eedf26e@posting.google.com...
> Noons <wizofoz2k@yahoo.com.au.nospam> wrote in message
news:<40af7768$0$3038$afc38c87@news.optusnet.com.au>...
>
> > > 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
>
> > It's a pity that you have considered my reply as that of a zealot.
> > I did concede a few points and debated yours in a civilized fashion.
>
> Sorry if you thought I was refering to you specificly, rather I was
> lamenting about the general quality of the responses in this thread,
> like those of Volker, moronic zealot extraordinaire, a man so stupid,
> that when I suggested he didn't know what a fallacy was, he thought I
> was critisising his _english_ instead of his knowledge of logic and
> the standards of debate.
>
> However, there is clear zealotry in your post, for example:
>
> You said: "It's with freeware that you need a STACK of wrappers to
> protect you from sudden underlying code changes!  Not with commercial
> software!"
>
> See: no other reasoning is given why underlying code may suddenly
> change other than in one case it is _free_, in the other case it is
> _commercial_. This is not a reasoned argument, but rather the faith of
> a zealot.
>
> Since neither freeness nor commercialness has a direct impact on code
> stability, but rather the release management practices of the
> development group has.
>
> There are badly managed free software projects, and badly managed
> nonfree ones, your argument is therefore a fallacy, although your
> english, like Volker's is great!
>
> > However, thanks for giving me the opportunity of stating this in a less
> > civilized language (remember: YOU started the language, not I):
>
> Please, use any language you like, you are quite welcome if my post
> has given you a greater since of liberty.
>
> >  none of
> > your points is by definition a "world truth".
>
> When I say things like "the readers can make up their own minds, as
> they should in any case" and "these are suggestions" (both present in
> the post you are responding too) what makes you think I am defining
> "world truths?"
>
> >  You don't provide a single
> > supporting argument that does not involve your interpretation of what
> > software makers would do rather than what they in fact do.
>
> Oh please, I have provided many clear aruments throughout this thread,
> in my last message I even posted pseudocode, how much clearer do you
> want?
>
> > Your stupid deduction that somehow only your view of the world is worthy
> > the title of "developer" defines you as the idiotic and moronic type of
> > geek that thinks the world was invented yesterday by your kind and all
that
> > came before is just amateur effort.  In character, I might say.
>
> You know nothing about my character or world view. Amateur effort is
> amateur effort, on it's own it is neither old nor new. None of the
> ideas I have suggested are particularily new. The existince of a large
> body of free software is fairly new, however the practice of acquiring
> source licences for critical dependencies is not, and serves more or
> less the same function. Abstraction is not new, good archiving
> techniques are not new. A developer who did not understand these
> techniques was an amateur in 1976, just as much as today.
>
> > You and your little group can go and drop dead as this thread ends
> > here for me: I don't have time to argue ANYTHING with "kewl" people.
>
> I'm sorry the barbs you endured in your primary school still hurt you
> so much, perhaps therapy can help.
>
> > Not worth the effort: the worst disasters in IT development I've ever
seen
> > in 30 years of career have been prompted by your kind and I don't like
> > my name associated with that sort of unprofessional reputation.  It
> > never pays in the long run.
>
> Let's see, I am suggestion abstracting dependencies, getting source
> code when you can and keeping your archives human readable.
>
> What sort of disasters can come of this? The worst that can be said is
> that, if implemented poorly, these suggestions may cause performance
> degradation, hardly Godzilla crushing Tokyo.
>
> However, It is quite easy to imagine disasters as a consequence of not
> following these suggestions; customers lost by not being able to
> support their database platform, production applications obsoleted by
> obsoleted debendencies, unusable archives and lost permenant records.
>
> > Goodbye and keep developing for a non-existent market.
> > It has a brilliant future.
>
> Which market is that? The market for good applications? I agree that
> is too small and that too many firms are screwed by bad developers and
> protectionist suppliers, however I assure you the marker for
> developers who understand good, well designed, open systems is doing
> quite well, and growing.
>
> > And yes, I DO have a future and nothing you can
> > possibly do will stop it.
>
> Hey, I only want to improve your future with my advise! Here, I'll
> give you another tip:
>
> A "binding" is a term used to describe a native function (or method)
> that provides access to an external dependency.
>
> For instance, 'MySQL', the database server, is a dependency, in PHP,
> the function mysql_query is called a binding. 'libcurl', the URL
> handling library, is a dependency, the PHP function 'curl_exec', is a
> binding.
>
> An 'API' ("application programming interface") is the interface
> provided by the dependency itself for external access, frequently for
> C, the 'binding' is your platform's _native_ function or method that
> provides access to this API, not the API itself.
>
> Each of these terms, 'Dependency', 'Binding' and 'API' have distinct
> meanings, and now, after a 30 year career, you can finaly understand
> them!
>
> I hope this helps.
>
> Regards,
> Dmytri.

On May 13, 2004, at 11:23 PM, Jeff Rodriguez wrote:
>   *PostgreSQL*
> Free, loaded with features, not particularly fast, some extras
>
>   *MySQL*
> Free, not so loaded with features, very fast, some extras

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

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


--
(-, /\ \/ / /\/

"Quirk" <quirk@syntac.net> wrote in message
news:4e20d3f.0405220405.57e0a8bf@posting.google.com...
> Thanks Nick,  your alternative propositions are much clearer than the
> FUD of the other posters. Although, your attitude seems no less
> belligerent, so my hopes for a fruitfull discusion are not high.

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

Never the less


> "Niall Litchfield" <niall.litchfield@dial.pipex.com> wrote in message
news:<40ad113c$0$20509$cc9e4d1f@news-text.dial.pipex.com>...
>
> > > 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.
>
> > 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.

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

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

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

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

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

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

Ah a straw man argument. Seen them before.


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

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

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

> > > 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 :(
>
> Because your companies record keepers distrust your closed-source,
> unabstraced application's data so much that they insist on keeping
> their trusty paper records.

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


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

The open-paperless office I love the vision.

You snipped what i was referring to, perhaps you misunderstod

referring to

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

I said

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

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

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


-- 
Niall Litchfield
Oracle DBA
http://www.niall.litchfield.dial.pipex.com

> > "Niall Litchfield" <niall.litchfield@dial.pipex.com> wrote in message
> news:<40ad113c$0$20509$cc9e4d1f@news-text.dial.pipex.com>...
> >
> > > > 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.
> >
> > > 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.

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

--
Remove the blots from my address to reply

Dear friends,

Could you kindly take comp.lang.ruby out of the list of follow-up
newsgroups when you post to this thread?

Thanks --


David

-- 
David A. Black
dblack@wobblini.net

"Mookstah" <dont_spam_my@mailbox.com> wrote in message news:<40b226c0@news.bezeqint.net>...
> OMG. this argument is still alive...
> 
> IS THERE A PUNCH LINE ANYWAY NEAR?

Q:  "How many free software programmers does it take to change a light bulb?"

A:  "How much free beer do you have?"

jg
--
@home.com is bogus.
http://www.levenez.com/unix/

Ditto for comp.databases.sybase.  Tks.

David A. Black wrote:
> Dear friends,
> 
> Could you kindly take comp.lang.ruby out of the list of follow-up
> newsgroups when you post to this thread?
> 
> Thanks --
> 
> 
> David
> 

"Niall Litchfield" <niall.litchfield@dial.pipex.com> wrote in message news:<40b25fc8$0$20518$cc9e4d1f@news-text.dial.pipex.com>...

> "Quirk" <quirk@syntac.net> wrote in message
> news:4e20d3f.0405220405.57e0a8bf@posting.google.com...

> > Thanks Nick,  your alternative propositions are much clearer than the
> > FUD of the other posters. Although, your attitude seems no less
> > belligerent, so my hopes for a fruitfull discusion are not high.
> 
> Last time I looked my name was Niall,

Sorry Niall.

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

I guess the new free software movement is such a big threat to the
status quo that it makes them nervous and belligerent to even discuss
it, like many protectionists, they are worried their island is about
to be stormed by barbarians. Well, I guess they are right. The
consumer, however, will benifit. And those amongst you with real
skills will also get on just fine.
 
> > I'm not saying that this is always the case, or is your case, but it
> > is the real world you asked about, and that's it.
> 
> If true, and there is some truth to this, I don't see what failing to get
> the legalities right has to do with having access to the source. This is
> about license management and control of procurement.

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

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

> > So, when the question of Free versus Propietary Databases is asked, I
> > think it is important to help people understand the advantages of
> > having source, or using free software, of avoiding dependencies, *as
> > well* as comparing features.
> 
> No software project, even if you have access to all the source is 'free' of
> dependencies,

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

> > As I said in my article in the NonProfitTimes, wether or not a
> > particular peice of free software is better that a particular peice of
> > nonfree software, free is better than stolen.
> 
> Ah a straw man argument. Seen them before.

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

> > Issolating your data access code does not mean you can not take
> > advantage of the platform, it means that all your data access code is
> > in one place, meaning that you can more easily change your
> > application, for instance to migrate it, or for instance to *make
> > better use of the platform you are running*
> 
> It almost always does mean you can't take advantage of the platform.
> 
> I have 2 databases, both run on clustered hardware, db 1 can resume a select
> statement that was issued on a failed node on a second node of the cluster,
> db 2 can't. How, precisely, do you 'abstract' this difference in capability
> whilst preserving the ability of db 1 to handle failed nodes more gracefully
> than db 2. How, precisely, do you abstract differences in datatype between
> two db platforms without performing excessive casting..

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

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

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

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

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

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

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

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

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

Regards,
Dmytri.

pagesflames@usa.net (Dusan Bolek) wrote in message news:<1e8276d6.0405240850.6528ed09@posting.google.com>...

> quirk@syntac.net (Quirk) wrote in message news:<4e20d3f.0405240218.6eedf26e@posting.google.com>...

> > Noons <wizofoz2k@yahoo.com.au.nospam> wrote in message news:<40af7768$0$3038$afc38c87@news.optusnet.com.au>...
> > However, there is clear zealotry in your post, for example:

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

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

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

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

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

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

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

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

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

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

Regards,
Dmytri.

"Quirk" <quirk@syntac.net> wrote in message
news:4e20d3f.0405250037.4d99dd34@posting.google.com...
> "Niall Litchfield" <niall.litchfield@dial.pipex.com> wrote in message
news:<40b25fc8$0$20518$cc9e4d1f@news-text.dial.pipex.com>...
>
> > "Quirk" <quirk@syntac.net> wrote in message
> > news:4e20d3f.0405220405.57e0a8bf@posting.google.com...
>
> > > Thanks Nick,  your alternative propositions are much clearer than the
> > > FUD of the other posters. Although, your attitude seems no less
> > > belligerent, so my hopes for a fruitfull discusion are not high.
> >
> > Last time I looked my name was Niall,
>
> Sorry Niall.
>
> > I'm afraid you are probably correct about the liklihood of a fruitful
> > discussion since you seem to have managed to get heated with every
single
> > one of the posters that I am aware of who regularly post well thought
out
> > informative posts.
>
> I guess the new free software movement is such a big threat to the
> status quo that it makes them nervous and belligerent to even discuss
> it, like many protectionists, they are worried their island is about
> to be stormed by barbarians. Well, I guess they are right. The
> consumer, however, will benifit. And those amongst you with real
> skills will also get on just fine.
>
> > > I'm not saying that this is always the case, or is your case, but it
> > > is the real world you asked about, and that's it.
> >
> > If true, and there is some truth to this, I don't see what failing to
get
> > the legalities right has to do with having access to the source. This is
> > about license management and control of procurement.
>
> Because with closed source software, 'failng to get the legalities
> right' is a financial mater, in many cases companies *chose* not to
> get them right, they know perfectly well they are overdeployed.
> Sometimes the choice is made by the principals, sometimes the choice
> is made further downstream; in the IT department who can't be bothered
> going through the procurement cycle again and again and justifing
> needing any more licences to the bean counters. They simply install
> the software on an another server, or for another user. In larger
> organisations the company tends to drift into overdeployment, in
> smaller ones, overdeployment or outright piracy is frequently the
> starting point.
>
> Free software can not be overdeployed, which is one reason why linux
> and bsd boxes are popping up in datacentres around the world, they
> started with Webservers, LAN Servers and Firewalls (esp for NAT), then
> Mail, now the Database, later the Desktop.
>
> > > So, when the question of Free versus Propietary Databases is asked, I
> > > think it is important to help people understand the advantages of
> > > having source, or using free software, of avoiding dependencies, *as
> > > well* as comparing features.
> >
> > No software project, even if you have access to all the source is 'free'
of
> > dependencies,
>
> Sorry, I meant free of exclusive external dependencies: fixed
> dependencies on outside organisations, not just software dependencies.
>
> > > As I said in my article in the NonProfitTimes, wether or not a
> > > particular peice of free software is better that a particular peice of
> > > nonfree software, free is better than stolen.
> >
> > Ah a straw man argument. Seen them before.
>
> No, perhaps a nonsequetor, but not a straw man, a 'straw man'
> is refuting a weaker argument instead of the argument you have been
> given, the passage you quote is an extension of my own argument 'free
> is better than stolen', it is not a weakening of yours. You may
> consider my extenstion irrelevant (I do not) but it is not a straw
> man.
>
> > > Issolating your data access code does not mean you can not take
> > > advantage of the platform, it means that all your data access code is
> > > in one place, meaning that you can more easily change your
> > > application, for instance to migrate it, or for instance to *make
> > > better use of the platform you are running*
> >
> > It almost always does mean you can't take advantage of the platform.
> >
> > I have 2 databases, both run on clustered hardware, db 1 can resume a
select
> > statement that was issued on a failed node on a second node of the
cluster,
> > db 2 can't. How, precisely, do you 'abstract' this difference in
capability
> > whilst preserving the ability of db 1 to handle failed nodes more
gracefully
> > than db 2. How, precisely, do you abstract differences in datatype
between
> > two db platforms without performing excessive casting..
>
> The passage you quote talks about issolating your code to one place:
> abstracting access from your application, which is a good coding
> practice for reasons I explain, as quoted above, I am not recomending
> you try and abstract //the difference between two databases// just
> that you issolate the code: abstract the data access for the rest of
> your application.
>
> When and if you need to migrate your application to another DB,
> presumably you have chosen db 2 based on your requirements and have
> already decided on a solution to whatever problem you are facing,
> having your code issolated means fewer code changes. Again, this holds
> true for migration, it also holds true for simply making better use
> (i.e. new features) of the platform you are currently using.
>
Instead of abstracting there are much better ways.  Abstrating somethings
are good.  Put the business rules and referential integrity in the DB not in
some middle tier or front end.  (even access the db via stored procs)  Then
you can swap out the front end , middle tiers much easier and be assured
that you do not have to rewrite and validate the business rules all over
again. (not tied to one technology).  It is much more likely you are going
to swap out some middle tier or front end or have multiple programs
accessing the db.  If you give access to the db only through stored procs
and put the business logic close to the database (in it) then it is just an
API for storing, retrieving your data.  It is a way to encapsulate that
functionality.  If you write a C++ or Java or other OOPL functionality the
concept (among others) is to encapsulate the functionality in that class.
The class does all the checking and data validation etc.  Think of the db in
the same way with respect to data and its relationship to itself. (RI,
business rules)  You can still have edit checks in a GUI, but the ultimate
RI and business rules should reside in the database.  But if one is only a
programmer this is a difficult concept to agree with and understand.

> > Not at all. You claimed that if I have access to the source, as I do
with
> > Linux 1.5, then I can always find a way forward without external
> > dependencies.
>
> With out _exclusive_ dependencies on third parties, sorry for the
> confusion: without paying for a new licence.
>
> > The only route to what you claim as an advantage would seem to
> > be rewriting the code in-house, or being dependent on external agencies
with
> > whom I don't have a legal relationship (you don't seem to like legal
> > relationships much).
>
> You see, *this* is an example of a straw man argument: that I don't
> like legal relationships, what I don't like is _bad_ legal
> relationships that lock me and my application in to a sole source
> situation and other specific restrictions, like limiting the
> deployment of my own application to the licenced limits of the
> dependency. I have no problem with good legal relationships, like
> support contracts, employment contracts, service contracts. All yummy,
> with a decent termination clause of course, and my perpetual right to
> the source when possible.
>
> > Oh and by the way I am perfectly free under my licence to install new
> > versions of the Oracle software for no change in cost and with the same
> > support.
>
> As long as you agree to pay whatever Oracle charges for support, a
> price fixed not by competition, as it would be if you had source and
> could contract who ever you liked, but by David Ricardo's concept of
> Economic Rent, meaning that in the long run the price will rise to
> what it would cost you to migrate away from Oracle. Interestingly, in
> this way users of closed source software do marginaly benefit from
> free software, since it lowers this theoretical rent. However, it is
> clear that Oracle can benefit from ignorance of free options for quite
> a while yet.
>

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


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

On 25 May 2004, quirk@syntac.net wrote:

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

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

-- 
Galen Boyer