Quirk said:
Is this grade school?
I asked you to QUOTE the part of the Contract that Guarantees you any
rights, not post a link to a description of support options and what
they cost.
That IS the licence agreement. Or at least tke part that deals with after sales stuff.
That's exactly the link the licence agreement for the database points to when it
comes to what wecan expect for paying support.
And even so, if you bother to read that page you would have noticed
that it is mostly about protecting Oracle's rights from you, not
granting you any.
For example:
"Oracle may provide additional releases or versions of its programs
in the form of an Update as part of our technical support services. It
may become necessary as a part of Oracle's product lifecycle to
desupport the programs and, therefore, Oracle reserves the right to
desupport its programs."
So? That's what desupport notices are for. The good thing is that
you find out beforehand, not after you start asking around because
the latest ftp download is from 1996.
If my application required a cucumber, I wouldn't sign a deal with a
cucumber vendor that insisted I could only buy cucumbers from them,
for ever, even if their cucumbers no longer work for me, while they
could stop providing cucumbers any time they feel like it and still
forbid me to use my own, proprietary cucumber dependant, application.
I would, at least, make my application work with any cucumber.
But what if you required a cucumber with special properties, like a monsanto
engineered one which contains some drug you want to sell?
What if you required support in case someone chokes on it and
the support company requires you only to buy certified cucumbers?
This converation has gotten ridiculous, can it be that you really
don't know the difference between a cucumber and an application
dependency?
It's a buying decision. You invest money and get a ware. Open source
is only different in that you can go behind the stall and see whether you
can make something of the stuff they dropped. That's where the "for free"
stuff comes in.
Yet in this case, you could have purchaced gcc support from another
company, however, without source, you would not have this option.
No, I couldn't because no one else was selling it.
any more.
What nonsence, please demonstrate this by comparison, I have clearly
responded to all your arguments, regardless of how little sense they
made.
"> > > > > > The right to modify is a red herring.And this after I just detailed how a migration is made way more difficult by
all the other bits that change and that the underlying database is really the least of
your worries when migrating to another app or the same app ten years later.
I brought up the chip design example because we've been through this.
I gould give you a board design example we are going through right now.
System 1 used informix, system 2 uses oracle. Guess what's the only part
of the migration that doesn' t give us any problems.
Worth posting what? Your great advice that developers should *NOT*
abstract their code?
That they should think before they abstract.
Too bad you have no actual argument to repeat, you are merely
repeating your empty rhetoric and unsubstantiated bunk.
That seems so to you because you can't read back more than one quote.
Yes it does, it's too bad you don't understand it.
If I have the source code, I know I can relly on a product for ever,
and never talk to the original developer again if I so chose. Withouth
source, the developer holds all the cards.
You know what, you do that. Use any open source database, and
ten years after the project has been abandoned you go and port
it to another platform, and try to get customers to use it okay? Then
we'll talk again about "forever".
Let's take a simple case, say you hired a consultant to write you a
simple
application, say a specialized contact manager.
When the project was over, would you let the consultant leave your
office, only turning over a compiled binary of the application? Or
would you insist that he provide the source?
Depends on how simple and how frequent my requirements change.
If he's the only guy that understands it I'd insist on maintenance
and a customizing possibility (like ActiveX or an integrated tcl interpreter).
If the requirements are volatile I'd do a long term contract detailing what
money he has to pay for getting out of it.
By the way, we did a bit of chip design before and had a tool made by a small
company situated here near Augsburg. Great tool. There we did what I
said (with the customizing) and we also got the source code. And you know what?
It was much too much bother even to get it to compile, much less change.
It was always cheaper to let those guys do the work. And what do you think
would have happened if we had wanted them to support code *we* modified?
Why are you struggling so hard with such simple logic?
Because it's erroneus.
- If a Dead Database means your application is also dead, if
migration is impossible; having source code can save the day.
My customers won't want a dead database so I'd have do
migrate or die anyway.
- If migration is possible, migrating is easier with abstraction.
Weakening the case for the rights ot the source code.
- If you have source *AND* you have abstracted, whoa nelly, you are
in *really* good shape.
As I said before, database migration isn't hard. For our new board design
tool we developed a database interface from scratch. 4 weeks, including
testing.
And yes, we went proprietary because otherwise we'd have spent ages
doing all the generic layers. And if oracle dies, so what? If our app
really still exists then we'll spend another 4 weeks interfacing to
wherever we want!
- If your data is archived in a self contained, self describing,
human readable format, why, you are all but invincable.
Another case on not reading what I write.
Thus my advice.
And closed-source applications have never been abondoned???
Which database do you have in mind?
Another simple question: If your application is abandoned, are you in
better shape with, or without source code?
I assume, you mean if my database is abandoned.
It doesn't matter because I'll be migrating anyway.
They are dead.
If you are dependent on them, at least you always have the source code
and can thus continue to use the product,
I can do that with oracle.
even have it modified if you
need to.
I can't because it's unmaintainable. At least groff is, to stay with that
example. It already was so in 1993.
Reminder: I am an the one advocating Abstraction, which would make it
easier to migrate to another database. What the hell are you talking
about?
No, you are the one talking rights to the source code. Abstraction is
just a side tracking because the right to the source code should, in your
world nullify the need to abstract.
And If, for some reason, you *must* repair the database, say the bug
is simple and is easier to fix than to migrate a large working
implemtation, at least with the source, you can, without the source
you can not.
If the program is fixable it wouldn't get abandoned.
Leaving the customer stranded because your application is hosed by an
obsoleted dependency is even a harder sell.
So, we need the original maintainer org to do the maintenance because only in
that case you can get one consistent version hosting all apps, right?
And if the db is dead *all* apps would be dead too, right?
Where's the difference to a commercial app then?
You keep basing your entire argument on nonsencical out-of-hand
dismissals, like 'it simply doesn't work.'
The difference is we've been through this and we are using open source
software and, to go back to the subject line of this thread, open source
databases for mission critical apps don't work better because of the right
to the source code. If I find a but in tcl I'll put it the activestate and let them
sort it out because I'm not going to maintain my own test suite and adapt it
to every new version. This is even more important for databases where I might
even not have a means of recovering thedata if my fix results in corrupted data
half a year later.
Btw, do you know what ARM paid for gcc support?
Over half a million bucks if I remember correctly. This for a supposedly
free product they could have fixed/ported themselves.
It does work, let me let you into a little secret: programmers modify
source code, that's how programs are made and fixed.
Or broken.
Without source
code you can not fix a program.
I can fix a program by telling the vendor to fix it, remember?
At least I can do that with all the programs we are currently introducing,
oracle and the said board development tool included.
You can do what you want, my advice is just that, advice, many people
are in different situtations from you, and have a different point of
view.
Typically they sit at universities and have access to plenty of cheap and
skilled labour. Sometimes I still envy the TeX group at my old university.
Yes, I have and do develop for many platforms, but *I* am not the
topic of this thread, despite your desperation. Once again, you only
attack the arguer because you have no argument.
So, if windows or MacOs is among them I guess you will be dependent
on some libraries and kernel properties that you don't have access to,
right? Only I'm trying to learn from you.
The assertion you quote remains true, and your response, as usual, is
not a response at all.
Just you stating it doesn't make it true. People are creative, that means they
can do things you can't. So to use them you become dependent on them.
In many cases you can aquire a support contract from corporations that
have the original developers working for them.
Right. At which we are back to the point where open source doesn't give
me an advantage. Remember, if I want informix support today I can go to
IBM too.
Yes there is, since you value the original developers so highly, we'll
try this example.
The best original developer of Oracle, the one with the greatest
knowledge of the system and code, quits Oracle and goes to work for
Databases-R-Us, since you have no source, you must continue to deal
with Oracle, the copyright holder, and can not hire Databases-R-Us,
who employ the developer.
You are mixing something up here. Oracle doesn't depend on
a single freak but on a well maintained turnover process.
What you mean is what open source software is famous for.
The best original developer of MySQL, the one with the greatest
knowledge of the system and code, quits MySQL AB and goes to work for
Databases-R-Us, since you do have source, you no longer need to deal
with MySQL AB, the copyright holder, and can instead, choose
Databases-R-Us, who employ the developer.
Fortunately commercial software rarely depends on one individual.
Suing him is a red herring. You applicaion is not powered by law
suits, but rather by compiled source code.
But it is powered by lawsuits. At least by the threat of it. Just
like boeing or airbus are when it comes to engineering security in.
They buy insurance against lawsuits and, with the insurance company work
out a process of ensuring quality which keeps the premiums down and
the insurance from losing lawsuits.
If stating the obvious is somehow of help to you, you're welcome. Whatever.
Try what?
Doing a maintenance contract and then measuring the few minutes per week
spending kicking their asses compared with all the programming you'd
have to do for yourself.
They also have an interest in dumping relationships that are no longer
profitable, and may not be interested in your obscure problem or
implemention, but rather more interested in selling you (or someone
else) something new.
In that case they'd offer me a migration path too, of course. Also,
if you ever manage to spend a few dollars on a oracle standard version
you might want to look at their bug site. Then you'll see to what lengths
they go. Personally I haven't hit any of those "too obscure" problems
yet. I've hit a couple real bugs, and once or twice they have nicely told
me that the problem wasn't what I thought but that my shitty code (first
steps as a PL/SQL programmer/first steps oracle spatial) crashed the
parser and that this was fixed in the next release the patch of which
was available already for download.
Other organisations may be quite interested in helping you, but are
unable to because you have no source code for them to fix.
If the main developer company abandons the product how long
do you think the others will survive? Besides, who tells
me that the others aren't just passing the service requests on to
the real one?
I would not recomed you 'pick some average application programmer off
the street' if you want to sort a bug in the postgres optimizer.
Many developers could do whatever you want, for instance: PostgreSQL,
Inc (not to be confused with PostgreSQL Org), Cybertec Geschwinde &
Schoenig, NuSphere, or many others which know the system well.
Nusphere takes one branch and supports that.
Cybertec can't even proper spell the stuff on their homepage.
So, PostgreSQL Inc would be the one we'd be dealing with.
I didn't find Nusphere of Cybertec on PostgreSQL Inc's homepage,
at least not in the partner section. Can't be much love then that's lost
between them. Which makes me wary about relying on any of those
other two as a failsafe.
The fact that it's worth for nusphere to support one port also makes
me hesitant about PostgreSQL Incs policy re platforms/versions.
However when Oracle lets you talk to a programmer, that is just who
they let you talk to, some average programmer they picked off the
street, the good programmers in their organisations to not work in the
support department, but rather on new features for new versions and
products to sell.
Actually, that depends on how long the bug stays unresolved.
they escalate bugs. Of course the first guy is there to make sure you've
read the manual but then you get the development guys.
Only as long as it is profitable for them and no more, then you get
'Desupported'
No, not "I" get desupported, a product gets desupported. For
all users.
All it takes is a poster session at the next oracle world and it
won't be "just me". At least not if I had anything to complain about.
Only as long as you pay, and only on their terms, if you have source,
you need not change a working system just because it is not supported
by Oracle anymore.
I don't need to do that for oracle either. At least not as long as it runs.
And not, even for a open source software I would wait with the migration
for the first bug after desupport.
Or instead of IBM they could have been bought by CA, and fucked up
royaly. Or just been allowed to disapear.
Databases have customers which are worth a lot. Do you think IBM
bought them for their marvellous technology?
Who is CA?
Again, you are depending on
good luck and good graces, if you have source, you know for sure, but
as I've said many times, it's even better to have an abstracted
application.
I'm not repeating again the problems of abstraction. Nor the easyness
you can migrate between databases today.
And by the way, don't think that IBM is above squeezing these newly
aquired hostages for every penny they are worth, and tosing aside the
ones who helping would not be profitable. You dont become a 100
billion dollar company by being stupid.
And you can't "toss aside" paying customers. Not sure if you are russian
and live in russia but if you are and do) you haven't got a particularly nice
capitalism working over there. Maybe you view problems as ordinary
that are viewed as pretty exotic in western europe or the US because
your country really works that way. Rest assured it's not so in the rest
of the world.
When you stoop to making ridiculous, incoherent, awkward streches of
logic to keep this conversation going on and on in the face of clearly
explained, good advice.
Ah, but I don't. Besides if I were you I'd leave the evaluation of your
advice to others.
Se here is a good example of your jumping up and down waving around a
fallacy a s if it was a point.
I did no such thing, I only explain what an elegent solution might be
//in this specific case// just as it says.
I never claimed to solve the general problem of elegent coding for the
rest world, this is just you wildly contorting yet again.
"you can solve this with your own wrappers through elegant coding".
And so does constantly changing everything to support differnet
databases when he finds your unabstarcted application does not use the
database that all his other applications do.
Believe me, it's easier to maintain three supported commercial databases
than three unsupported (because app-vendor patched) mysql databases.
there goes again your argument in favour of the private source code
modification.
And locked themselves out of the portion of the market which does not
use PL/SQL, but rather something else, or simply does not want to
bear the cost that using PL/SQL adds to the product not only on
implementation, but also in anual licencing and support costs.
The cool thing is they *still* required oracle. The other cool thing
is that somehow all the big customers (i.e. the ones with real money)
aren't really interested in mysql because of all the missing backup/recovery
and standby tools.
No, you only have to maintain the one you actuall have in production.
Per app. With a commercial db *I* tell them which version to use.
In most cases it does not make sence to build your application to
depend on Oracle, or any thing else, exclusively. However there are
certainly worse products to be dependant on, MS SQL for example.
Even this depends. If you are programming exclusively for windows
it's not a bad choice.
Again, if by 'We' you mean some imaginary person the rest of can't see
or hear, please ignore my intrusion, however if you mean You and I, we
are not.
Please read the first article of that thread.
We are talking about two different things, the advantages of source,
and the advangates of abstarction of access,
No. You are trying to change the topic.
I have made no comments
in this thread regarding commercial versus open source databases
except to agree that the commercial ones _do_ have more features, that
alone however does not always
make them the best choice.
See above.
Great, sadly however, not relevent.
Which ones have you worked with?
However, a closed source contract is designed to hold you hostage, and
to keep competitors away.
Forget about this okay? A contract gets designed by both parties, even
if the other side in this case is represented by oracles marketing department
that actually wants to sell the contracts. To big companies with big legal
departments.
And no one forbids me to run oracle and db2 and sqlserver on the smae machine.
No one you know is not no one.
The OS is a part of Network security, what manages user priviledges?
the OS.
The Switch? What controls device permissions? Your ethernet cables?
The OS.
Your network security is a product of the collection of OSes that make
up the nodes of your network. And the network is exactly as secure as
the weakest node.
Actually for a database it does not matter what the switch or anyone else
says. What comes throught the listener is what counts. Look up the oracle
architecture, or any other commercial one.
See, you have just provided an example of how bad network security can
undermine good database security, there are plenty of others as well.
No I haven't. Because having nfs tablespaces isn't good database security,
because it makes a database dependent on the security of the file
server. Which is not a network issue.
My point, once again, is that you can only have Database security,
*IF* you have a secure network, which means that the nodes on it are
secure.
You can make a database so insecure that it depends on network
security. It's a totally different thing.
Yes, that tool being the Application, the very thing following my
advice will help you protect.
Also, not all data is about creating
chips, in many cases the data is the purpose of the appliction, and
can outlive it, sometimes it must, by law, be accessible for a really
really long time,
Yes, and do you know what people do then?
They convert the .prn or .ps files to TIFF or
keep one machine with the original software somewhere in a
climaticed room and hope like hell the contacts don't rot.
We do have seven years liability here and storing bitmaps
of everything is what we do. And recopying them.
And no, we can't feed them into any current system, if we need to
deal with any seven year old problem we just print out the stuff
and look at it.
If you have that kind of advice to dispense, go and
ask for a job at Lufthansa or Siemens Medical. They are just
waiting for people like you.
like in the case of public data, as I said. In this
case in particular, keeping your data in a self contained, self
describing, human readable file format is good sence. That is why
things like XML and dublin core get invented.
See above. Just accept it. You really don't know what you are talking
about here.
Then your data does not have a long life span, so why are you
presenting it as an argument, when my advice was specificly qualified
to "ensure the perminancy and portabilty of your important data?"
See above.
If your data does not need to be either perment nor portable, why are
you discussing this, do you really imagine that because you data does
not need to be permenent or portable, that therefore no data needs to
be?
I'm saying is that regardless of the need, daya simply *isn't* permanent
or portable. Go, ask a bank why they still have the old mainframes running.
They should have the money to do things proper, right?
I can read
text files I created on my Apple ][, and no, I do not have the orginal
hardware (well maybe my mom does somewhere in her basement).
Not all textfiles are notices for you to read.
Yet some are, and for this data my advice holds true, I have never
implied that all data must be kept accessable forever, rather advising
on what to consider when it does.
That elegance is abstraction.
The quote says "That abstracting access to suspect dependencies is a
good idea" not "elegance is abstraction"
Yes, you changed that one from your original posting.
Here you are jumping up and down again.
It is, if you ask a security expert you will find they agree with me.
Instead, archives should be kept in a format that can not be readable
forever? What do you think archives are for? I don't mean simple
backups.
"This program has 400 features. No one will be able to use it."
"Ok, we'll add "ease of use" to the list."
Data isn't permanent out of choice but because no one has found a good
solution yet. Go, do your own, get rich. You've got my blessing and me
as a paying customer if it works.
You mean the same SAP that developed the Open Source SAP DB
It was old and they released it because they've milked it for what it
was worth.
and is now
working with MySQL DB in making it MaxDB?
Yes. And all the big installations run oracle.
If they get mysql to their feet support like, we'll have another look.
Besides, THEY are big enough to buy mysql ab if they want to,
right to the source code or no right to the source code.
Also, they invest money to spite oracle, which goes into SAPs market
by trying to buy peoplesoft. (I'm not saying that SAP's decision isn't
right, or oracle is blessed, ok?)
So, access didn't have much to do with it and it certainly isn't cheap
for them.
In anycase, I'm not intersted in what you are working on. It's
irrelevent and it sounds banal. Nor does it in anyway strengthen your
arguments.
I have put up evidence in terms of real world experience. What you think
of as banal or not is absolutely irrelevant to me.
How do you know what everybody thinks? you think what is posted in
this thread represent what everyone thinks?
Ok, you are the only one who posts this. OTOH I know the people
in a lot of other groups and have been corrected by them
before plenty of times .
Thanks, from now on I will never abstract my database access, ignore
network security, refuse to accept source code for any dependency of
my applications, insist on being locked in to single source for all my
support contracts and always, always keep my archives in an
incoprehensible filesystem blob that I can only access by way of a
third party, closed-source deamon.
You know, now that you say it it doesn't sound too bad?
You get a fast, efficient application, can draw on the development and
support expertise of other large successful enterprises and if your
customer wants permanency you can actually *ask him* how he would
have it done without trying to force your solution on him.
So we should not try to write good programms then? Quick, someone tell
Don Knuth.
The guy who still writes in TECO assembler? He might know algorithms but
he sure doesn't know coding.
Again: Not having source is a guarantee that one CAN NOT fix bugs.
Again: I don't have to fix them. I have to have someone fix them. Namely
the guys I've got the support contract with.
Who will fix the bugs when the vendor goes bust? Or compile it for
your new OS, or your new CPU? Or to link a updated library for which
there is a security patch?
No one. Who ports mysql to my cellphone?
And trim your posts better, you don't need to quote every line in the
previous post, only the ones you actually respond to.
The way you misunderstand me I'm tempted to leave everything in.
Sometimes it's best to change companies and keep the product,
Hm. Support from boeing for an airbus.
And you get what you pay for, do not imagine they will consent to
losing money on you for long if their costs go above your flat rate.
I don't care how much they win or lose as long as they fix the bugs.
Which they do. If they don't, I can still change.
Right, if fixing it costs them more that what you are paying them,
then they desupport you,
No. See my other post.
Who is the developer, you or IBM? If you are hiring IBM, why are you
messing with the code?
If not, why do I need the source code?
I'm sure, if you are willing to pay them
enough, IBM corporate services will indulge this crazy plan of yours,
but they will probably at least suggest you decide wether it is you
*OR* them who are developing the code, and if you already have screwed
it up, perhaps they might prefer to start with a fresh copy from MySQL
AB.
Great. We're making headway here.
Greetings!
Volker