Slashdot Mirror

← Back to Stories (view on slashdot.org)

Should Dual Cores Require Dual Licenses?

Posted by CowboyNeal on from the symmetrical-multi-paying dept.

sebFlyte writes "The multi-core debate continues. HP and Intel have laid into Oracle and (to a lesser extent) BEA over their their treatment of multi-core processers. Oracle's argument that 'a core is a CPU and therefore you should pay us all your money' isn't a popular one, it would seem. What does Oracle's stubbornness imply for the industry as a whole, with multicore chips coming to the fore so strongly?"

3 of 425 comments (clear)

  1. That's mainframe thinking... by Dinosaur+Neil · · Score: 5, Interesting

    This is sort of scam is used on pricing for mainframes all the time. One place where I worked used this as an excuse to (finally!) dump some crappy and archaic Computer Associates products when they started charging us double for a dual processor, even though one processor was partitioned to another OS that didn't run any of their products.

    --
    "I'm a scientist! I don't think, I observe!" - Dr. Clayton Forrester
  2. Portable code solves this problem by Decaff · · Score: 5, Interesting

    Oracle's stubborness says, time to start looking at DB2.

    Absolutely. But how many can easily switch?

    For a long time I have had (occasionally heated) arguments with SQL addicts who insist that almost everything about an application should be coded in SQL and stored procedures. Meanwhile I have been moving all my logic away from the database engine, using APIs such as Java Data Objects, which makes my code very rapidly portable between databases. Now I am in a position to switch my code (and data) easily between different database vendors if there is a licensing or price issue.

    I strongly believe we should start to think of databases simply as engines for storing and retrieving inter-related objects and not as platforms for writing applications.

    1. Re:Portable code solves this problem by Decaff · · Score: 5, Interesting

      Whereas for my part I am absolutely sick of dealing with software that does not perform well on ANY platform and cannot be moved rapidly to a new technology.

      Me too. That is why I use Java+JDO, and not DB-specific SQL.

      Too bad they don't support the neato language where we put the business logic.

      Good point. Show me a platform that does not support Java. I would rather have the logic there than in some neato DB language that has to be ported, at great expense.

      whereas if the business logic had been stored in the database, reimplemention would be a few weeks work.

      A few weeks work? Have you actually worked on such a re-implementation? This is nonsense. A moderate project can take months, and a large scale project years, especially on a live system. I know this from personal experience.

      and the result will be 2 systems each faster, more scalable, and more secure than your portable system.

      This is simply a statement with no foundation.

      There are no security, scalability or speed issues with the system I use - JDO. It is designed to be secure and scalable, to work at high performance on clustered systems and to generate optimal SQL for each version of major databases. Large corporations use it for this purpose.

      Which doesn't even touch on the topic of data integrity...

      Why should the matter of data integrity be relevant? Systems like JDO and Hibernate and Toplink fully support all aspects of transactions, clustering and cache management. Data integrity is, of course, not an issue. If it were, these products would not be so widely and successfully used in critical projects.