Is this grade school?
I asked you to QUOTE the part of the Contract that Guarantees you any
rights, not post a link to a description of support options and what
they cost.
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?
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?
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.
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?
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
It is, if you ask a security expert you will find they agree with me.
Instead, archives should be kept in a format that can not be readable
forever? What do you think archives are for? I don't mean simple
backups.
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.
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.
I did. You just didn't understand it.
Yeah, sure. I don't understand your arguments. They are
incomprehensible nonsence.
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.
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?
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.
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.
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.
You forget that they depend on me. Namely, on my money.
God help them then.
Fortunatly there are other customers.
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.
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 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?
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.
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.
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.