What so special about PostgreSQL and other RDBMS?

Discussion in 'Ruby' started by Sarah Tanembaum, May 4, 2004.

  1. Sarah Tanembaum

    Quirk Guest

    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.
     
    Quirk, May 11, 2004
    #41
    1. Advertisements

  2. Sarah Tanembaum

    Quirk Guest

    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.
    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.
    Yeah, you and Kaspar Hauser.
    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.
     
    Quirk, May 11, 2004
    #42
    1. Advertisements

  3. 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.
    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, May 11, 2004
    #43
  4. Sarah Tanembaum

    Quirk Guest

    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.
    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.
    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.
    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.
     
    Quirk, May 12, 2004
    #44
  5. Sarah Tanembaum

    Steve Guest

    What database does Google use?

    Steve
     
    Steve, May 12, 2004
    #45
  6. I asked first.
    So, in what way is it different from let's say, buying a cucumber?
    The other example was buyig gcc support from cygnus.
    One bug, never got resolved in one year, consequently
    we cancelled support.
    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 start to repeat myself here. The right to the source code does not mean
    anything useful, see the part you quoted below.
    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?
    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.
    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.
    Do you develop for platforms other than linux?
    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.
    Try it. Besides, remember, the company has an interest in providing
    support because they live off it.
    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?
    Of course they don't offer that. But they offer to put effort
    in it. And they are dependent from me for my money.
    They provide upgrades and desupport dates. Ok, they do
    what I pay for.
    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.
    Where do I jump up and down?
    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.
    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.
    We are talking about open source versus commercial databases. I picked
    those two as examples because I have worked with both of them.
    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.
    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.
    You can have a secure database within an insecure network.
    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?
    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.
    Not all textfiles are notices for you to read.
    Yes.
    Those are the tree main reasons. The fourth one is your persistent
    belief that the right to the source code is of value.
    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.
    I did. You just didn't understand it.
    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.
    I don't insult you I'm trying to get through to you.
    Reasonable arguments didn't work.
    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?
    No, that they are the only ones that should be allowed because they
    are the only ones that can take responsibility.
    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.
    You forget that they depend on me. Namely, on my money.
    So, what is it?
    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 still, if something goes wrong, I file a service request.
    And if the company does ceases to offer the product I change company.
    As I said, we pay a flatrate.
    Then they lose money if they don't accomplish anything.
    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
     
    Volker Hetzer, May 12, 2004
    #46
  7. Sarah Tanembaum

    Geoff Berrow Guest

    Geoff Berrow, May 12, 2004
    #47
  8. 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.
    See my other posting. Compared to changing the application (replacing
    it with another), changing the underlying database is easy.
    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.
    They developed it.
    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.
    Not "nearly", the legal opinion was correct and therefore the only ones
    to worry were the sued ones.
    See my other posting.
    OTOH, "if you install this fire alarm, you will pay less insurance on
    the house".
    No, they wouldn't, because first they would have to understand the code.
    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.
    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?
    Why? I can't change it.
    He's my slave because I pay him.
    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.
    Yes, I would. Because I'm not going to maintain my own database
    distribution.
    If I have abstraction it's even less necessary to mess around with
    the db because it's easier to change the db.
    And that is why special libraries, databases or servers exist?
    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
     
    Volker Hetzer, May 12, 2004
    #48
  9. 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
     
    Volker Hetzer, May 12, 2004
    #49
  10. Sarah Tanembaum

    Aredridel Guest

    What database does Google use?

    Random access memory.

    Completely custom, too.

    Ari
     
    Aredridel, May 12, 2004
    #50
  11. Sarah Tanembaum

    Quirk Guest

    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.
    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.
    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.
    Of course they do.

    They make even more sence if you are not locked in to a single source.
    Why would anybody do work fo you for free? Are you a charity of some
    sort?
    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.
    And the relevance of this is....?
    If it did come to a dispute, they could not have supported there own
    application, they where exclusively dependendant on an outside firm.

    Because he had no right to go elsewhere if the vendor failed to
    deliver.
    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 they where a credible provider of support and development for this
    particular product, they would certainly understand the code.
    Huh? No, like a competent development comany providing devlopment
    services, exactly like Oracle does, but without trapping you into a
    sole source situation.
    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
    If you can change it, you are not 'locked in.'
    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.
    You have the *right* to use it and have it changed for ever and ever,
    not only by the permission of some outside company.
    No, he can simply ignore you if he decides the relationship is no
    longer profitable for him. You can do nothing.
    That's all I'm saying, Abstraction is a good idea. I was giving some
    simple, good advice. What are you saying?
    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.
    Yes, that's why I am *recomending* abstraction. Are you just typing
    compulsively at this point?
    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.
    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.
    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?
    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.
     
    Quirk, May 12, 2004
    #51
  12. Sarah Tanembaum

    Joel Garry Guest

    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.


    ....
    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.
    Make buckets o' cash following them, too.
    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.


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


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

    ....
    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
     
    Joel Garry, May 12, 2004
    #52
  13. Sarah Tanembaum

    Quirk Guest

    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?
    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?
    Yet in this case, you could have purchaced gcc support from another
    company, however, without source, you would not have this option.
    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?
    Too bad you have no actual argument to repeat, you are merely
    repeating your empty rhetoric and unsubstantiated bunk.
    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?
    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.
    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?
    Yeah, what about them?
    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.
    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.
    Leaving the customer stranded because your application is hosed by an
    obsoleted dependency is even a harder sell.
    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.
    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.
    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.
    In many cases you can aquire a support contract from corporations that
    have the original developers working for them.
    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.
    Suing him is a red herring. You applicaion is not powered by law
    suits, but rather by compiled source code.
    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?
    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.
    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.
    Only as long as it is profitable for them and no more, then you get
    'Desupported'
    Just you?
    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.
    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.
    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.
    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.
    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.
    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.
    There are bad application out there, including ones that are
    Abstracted, and ones that are not.
    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.
    No, you only have to maintain the one you actuall have in production.
    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.
    Your specific case is not neccesarily the general or even common case.
    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.
    Great, sadly however, not relevent.
     
    However, a closed source contract is designed to hold you hostage, and
    to keep competitors away.
    No one you know is not no one.
    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.
    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.
    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.
    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?
    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.
    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.
    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.
    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.
    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.
    Yeah, sure. I don't understand your arguments. They are
    incomprehensible nonsence.
    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.
    How do you know what everybody thinks? you think what is posted in
    this thread represent what everyone thinks?
    Better evidence is how easily all your arguments are refuted.
    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.
    Always ready to go beyond the call of duty for a good cause, huh?
    Yes, my entire argument, but dont let that stop you from blathering.
    See, "the only ones that can," -- they posses a special metaphysical
    quality that no one else posses. Interesting faith you have.
    So we should not try to write good programms then? Quick, someone tell
    Don Knuth.
    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.
    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: Not having source is a guarantee that one CAN NOT fix bugs.
    Yet others may not want what you want, do you think that my advice was
    directed at you and your application specifically?
    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.
    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?
    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.
    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?
    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.
    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.
    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.
    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.
     
    Quirk, May 13, 2004
    #53
  14. 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?
     
    Greg D. Moore \(Strider\), May 13, 2004
    #54
  15. Sarah Tanembaum

    Gawnsoft Guest

    Gawnsoft, May 13, 2004
    #55
  16. Sarah Tanembaum

    Quirk Guest

    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.
     
    Quirk, May 13, 2004
    #56
  17. No, I don't seem to be the one who has the closed mind.
    Interesting, but not the OS in question.

    Thanks for playing troll.
    Yes, we would rather keep the level of discussion professional and based on
    facts, so please, in the future excuse yourself.
     
    Greg D. Moore \(Strider\), May 14, 2004
    #57
  18. _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.
     
    Jeff Rodriguez, May 14, 2004
    #58
  19. Sarah Tanembaum

    Quirk Guest

    [comp.databases.ms-sqlserver group removed]

    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
    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.
     
    Quirk, May 14, 2004
    #59
  20. Sarah Tanembaum

    Quirk Guest

    [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.
    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.
    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.
    When you have no argument: attack the arguer.
    '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, May 14, 2004
    #60
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.