Slashdot Log In
Should Dual Cores Require Dual Licenses?
Posted by
CowboyNeal
on Sat Feb 12, 2005 12:46 PM
from the symmetrical-multi-paying dept.
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?"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading ... Please wait.

Processers? (Score:5, Funny)
Re:Processers? (Score:4, Insightful)
You asked a questions so my answer is.... (Score:5, Insightful)
Portable code solves this problem (Score:5, Interesting)
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.
Re:Portable code solves this problem (Score:5, Interesting)
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.
Competition (Score:5, Insightful)
Agree, or agree not. There is no should. (Score:5, Insightful)
Exactly (potentially)...
The original question was, "Should Dual Cores Require Dual Licenses?"
There is no should or shouldn't.
A contract is an agreement between two parties.
One sets forward their terms. The other agrees, steps away, or offers ammended terms for consideration. A license is essentially just a representation of that.
"Should" a dual core require dual licenses? There is no should. Oracle are allowed to consider it essential to them and for them to walk away if they don't get their way - and potential users are allowed to consider it too high a cost and walk away if they don't get their way too. Or they can come to an agreement.
Inevitably, one of three things happen:
Customers walk away, Oracle reconsiders its stance.
Customers suck it up, deciding it's still worth it, if less so. Oracle continues.
Oracle loses overall share but profits per customer are higher, thus they're willing to continue with fewer, more valuable customers.
From Oracle's perspective, why should customers halve their license fees by simply upgrading to dual cores? What happens in a few years when Intel has 8 core CPUs? Do they only get 1/8th revenues? As Oracle sees it, they're right.
From the customer's perspective, all they did was upgrade their hardware with a single piece. As they see it, they're right.
In the end, there's not really the notion of right or wrong. Just two different views. Ultimately, equilibrium will likely settle it somewhere in the middle.
Re:Riiiight! (Score:4, Insightful)
thus, logic states that it's no harder to switch than to upgrade...
I didn't know oracle even looked at processors (Score:5, Funny)
Open Letters, Briefings, etc. (Score:5, Insightful)
HP and Intel should manage their own business, and leave Oracle to mismanage theirs.
What have we come to that companies write open letters to themselves, using public opinion to try to damage competitors or enhance their own position... and the public eats it up and supports it?
Intel, this is your problem. Deal with it without whining to the public... or you'll look like whiners. It isn't like the wining is going to actually help your case anyway.
Wait... I thought it was $/user?!? (Score:5, Interesting)
Let them be stupid...the market will correct them.
--Mike--
There _Are_ Other DBMS's (Score:5, Insightful)
> industry as a whole, with multicore chips coming
> to the fore so strongly?"
PostgreSQL is coming along nicely...
Re:There _Are_ Other DBMS's (Score:4, Interesting)
It drives me crazy when I see the GPL text and the "I Agree" button on the installer for a GPL'd program. The GPL is a copyright and patent license, NOT a license to use the program. You have the right to use it, whether you agree or not. The only thing that you should need to agree to is a warranty disclaimer.
Re:There _Are_ Other DBMS's (Score:4, Interesting)
Would you put your business's future in the hands of Larry Ellison?
My high volume business IS using PostgreSQl. The money not paid to Oracle (part) funds a programmer. One day, some money will even go to the PostgreSQL project.
Oracle has shafted me twice. I won't risk a third time.
That's mainframe thinking... (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.
Oracle License is Painful (Score:5, Insightful)
My sense of things, though, is that to move from one database technology to another is a massive undertaking. You fight with these tools so much that you become an expert with them... warts and all... and even if someone else has a better and cheaper mouse-trap, mission-critical stuff just refuses to budge off the old workhorse.
The dual-core problem is just a new flavor of the Oracle licensing problem. It will be interesting to see if they budge.
Cell processors (Score:5, Insightful)
Due to greed and stagnancy, Oracle has maybe 5 years left before the "smell of rot" is all pervasive. When MySQL and PostgreSQL become so common place (think Apache on the net today vs. Netscape's web server from the mid to late '90s) [netcraft.com], Oracle will be lucky to be a million dollar company.
If you doubt my words, think of what MySQL and PostgreSQL were just a year ago. Then think "What will they be like with 5 more YEARS of development?". Then realize that they are free to everyone and you'll see why Oracle is doomed.
Of course, Microsoft will claim it as their victory, but you, me and everyone else not running SQL Server will know better.
They aren't the only ones (Score:5, Informative)
This is what drove many Oracle users to Windows, because Intel based servers tend to be smaller.
Oracle came after the place I was working for being out of license by around a million dollars. After a long negotiations Oracle agreed to charge us per installed CPU. So after signing the agreement with started pulling CPU's and max'ing out RAM. We ended up only owing Oracle a few thousand, and maintained performance with the extra RAM.
Veritas NetBackup is the same thing. Explain to me why it cost more to backup a multi-CPU server.
Re:As long as.... (Score:4, Interesting)
Also remember that you are entering into a contract with Oracle when you purchase their software. Oracle can define the terms of that contract however they want. If they want to start charging "per core" there is no reason why they can't. On the other hand, if you don't like the terms of their contract you can always find a new database to run things off of.
Re:Kinda torn (Score:5, Insightful)
But then, a person with a bigger L1 cache will also get better performance, so why not charge based on transistor count?
Why not just charge based on MFLOPS or MIPS? Why not charge based on actual transaction throughput?
This amounts to nothing more than a quick-and-easy way to try to sneak through a regular doubling of their pricing structure. Realistically, we can expect Moore's law to start applying to number of cores, rather than number of transistors. So, in 20 years, will Larry expect their customers to pay more than the GDP of most smaller industrialized nations? In 30 years, will he let us use Oracle if we just make him "Emperor Ellison I, monarch of Earth and the Lunar Colonies"?
No. In a few years, Oracle will simply reverse this policy, and go back to their current approach of striking the corporate rock with a big stick until it runs out of blood. That, or they will cease to exist. In the meantime... Anyone currently dependant on Oracle would do well to start migrating now, because, of the three possible outcomes (no change; no per-core pricing; going under), two mean you'll need to change eventually, and the remaining option means you'll at least get raped over the short-term.
Re:Kinda torn (Score:4, Informative)
Re:Kinda torn (Score:5, Interesting)
Everything I've read so far says that two separate chips will give better performance than a dual core at the same clock speeds.
So if you have a dual Xeon 3.6Ghz, you're likely to get better performance than a machine with a single dual core 3.6Ghz.
This comes down to cores having to wait for access to resources, etc.
This is why I don't like the dual core == dual licence scheme. I'm _NOT_ getting twice the performance as with a single chip, but I have to pay twice.
In fact, this is something that makes Fujitsu servers attractive as competition for Sun. You can get equivalent performance to a dual core Sun Sparc IV 1.25Ghz with a single 1.8Ghz Fujitsu Sparc processor. Those clock speeds might be slightly out, but find the nearest
Remember, it's not just a few players in the enterprise market that licence like this. Veritas, Oracle, HP Openview, Websphere MQ, they all do this. So if you can get the same performance from a single core CPU as you can from a dual core, halving your licence costs can be a big deal!
Re:Kinda torn (Score:4, Insightful)
This comes down to cores having to wait for access to resources, etc.
I think you are not saying what you think you are saying. In the case of Intel they should be nearly identical, since Intel shares the memory bu between two processors whether the cores are on one piece of silicon or two. AMD wil be an interesting study since a dual opteron can have memory for each processor, and each has its own connection to the peripherals. Weras all other thngs being equal a dual core Opteron would have only one memory bus for both cores and share a connection to the peripherals.
You can get equivalent performance to a dual core Sun Sparc IV 1.25Ghz with a single 1.8Ghz Fujitsu Sparc processor.
This suggests you are thinking single core higher clock vs two processors (dual core or separate). Which can often be true depending on the software.
Makes more sense than per chip or per core (Score:5, Interesting)
And it can hardly be argued that it's an issue of chip count, what if I were to take a dozen or more chips (PLAs, slice processors, and other exotic devices) and from these build up a single 386 class CPU? Clearly such a device would only require one license to run software, even though it was made of multiple chips. And since there are already court rulings that instruction sets can not be copyrighted, it is clearly my right to build such a device and software vendors would have no valid reason to keep me from legally buying copies of their software and running it on my creation.
One should also consider that my "single core" desktop computer actually contains at least two significant processors, the CPU and the graphics card (which may very well have more processing power than the CPU). While software like Oracle doesn't take advantage of the processing power of the graphics processor today, if some sophisticated user were to enhance his OS such that some improvements were made that could take some small advantage of the processing power of the graphics card, would this somehow change the processor count as far as Oracle was concerned?
If a 386 computer with a 387 co-processor counts as only one CPU, shouldn't I be able to designate one of two Athlon processors on my dual CPU motherboard as a "co-processor" and pay for only one machine? Sure, each of the Athlon processors is far more powerful that the 396 and 397 combined, but that's not the issue. And if chip count is the issue then the 386 and 387 certainly use as many or more chips (and more support chips).
Re:Oracle is asking for it... (Score:5, Informative)
First, it can be easier if you were running Linux, but the way it sounds, youre running solaris, right?
Well, if you do happen to be running Linux on this, just nab the 2.6 kernel, and make a Usermode Kernel. Run Oracle under the UML kernel, where it cant touch any hardware at all, without going through an abstraction layer. What it doesnt know wont hurt it. Even better yet, you could run this "Kernel Job" on proc #3 and give it sole prio over that CPU (in other words, run only that process- the UML process).
Since, you're probably running Solaris, I believe there's 2 possibilities.. For one, VMware I believe can run on that architechure. Just do with VMware what you can do with UML Kernel. Run it on last CPU like UML. Sits there happy as a clam at high tide.
The last possibility is what Im not completely not sure of. I believe the new solaris had UML-like capability and to partition hardware resources to seperate "Computers". Since Im not quite sure, I'll have have you go look at Sun's website about possibly looking down that path of execution (heh I made a funny).
Nevertheless, if there's a method of little overhead that partitions hardware resources, it's something you ought to look into.
Just an idea