DOJ Gives Oracle Approval To Buy Sun
k33l0r writes "The BBC is reporting that the US Justice Department has approved Oracle's takeover of Sun Microsystems. The acquisition gives Oracle control over (or a leading role in), among other things, Java, MySQL, (Open)Solaris, ZFS, OpenOffice, and the NetBeans IDE. 'The European Commission has still to rule on the deal, a step that will be required before it can close. That body has indicated it will issue an initial opinion on Sept. 3, according to the Wall Street Journal. It may OK the deal at that time or launch a four-month probe of it. ... The Justice Department ruling came earlier than expected, a possible response to Sun's declining revenues and precarious business position in a steep recession, as the required reviews proceeded.' We first discussed the deal back when it was announced in April."
For those wondering why the merger wasn't simply rubber stamped, it has to do with the licensing of Java:
http://www.jroller.com/scolebourne/entry/no_java_7_us_doj
From what I read, it wasn't a *huge* deal, but enough of a concern that the DoJ had to work with Oracle instead of simply approving the merger right away.
The EU probably has similar concerns.
This space left intentionally blank.
Oracle's middleware business basically runs on Java. Why would they abandon it?
This space left intentionally blank.
Disclaimer: I work for Oracle.
When Oracle buys a company, they keep that company's staff to keep on working on whatever product they acquire. They dont shove that down the hall to whatever commando team. Based on personal observations of 4 companies that were absorbed and whose location merged in my area.
Also, as far as Java is concerned, Oracle has the best interest in keeping Java alive and well, as well as further push it. It's got a sizeable investment in Java for server-side stuff and even some client-side applications.
And from my perspective, all I can say is that more is to come.
Unfortunately said Pentium 4s also would fail 10x more often.
I don't know if you've worked (ie, have had direct administrative experience) with any of the larger Sun hardware such as E2900 and above, or even the Ex500's from back in the day, but if you did you'd also know that these servers have a knack for uptime and resiliency that x86 servers, even to this day, have never had. There was a reason for those higher costs.
Data Mining and Business Intelligence doesn't need huge powerhouses anymore. A low end server can easily handle the Millions of records Databases now. The Mid Range can handle Billions. What is left for Oracle and Sun are the Trillions of records DB. Which most sectors don't use. Also with advances in distributed computing we rarely need to go high end for the Trillions of records.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
...When Oracle buys a company, they keep that company's staff to keep on working on whatever product they acquire. They dont shove that down the hall to whatever commando team....
Tell that to the Virtual Iron Team
I say things which affects my Karma negatively. (and I don't care) For instance; All religion is false.
Actually the advantage is a fast backplane, not the memory. You may remember they bought the rights to the Cray asynchronous (really packet-switch-like) backplane quite a number of years ago, and have been expanding on it since.
It's easy to build a fast chip if it never has to maintain cache-consistency with anything off-chip. If it has to stay sane, even with only 64*4*2 = 512 threads banging on the same memory range, it not only takes an expensive bus, but it's also memory-transaction-rate limited.
That's why you read about transactional memory in Linux Weekly News: we all need it, SPARC and Intel both.
--dave
davecb@spamcop.net
My leaky memory says that 40% of Oracle's income (profit?) comes from Oracle on SPARC, and another 20% from
Oracle on other Unix.
I did the migration of the last Oracle Sparc to Oracle Linux system at my previous employer a couple years ago. Before this migration, it had moved to Fujitsu from Sun several years previous. (Oracle on Linux just wasn't there yet, a high-performance 8-CPU Intel machine monopolizing a whole SAN for performance reasons was full of race conditions because driver developers never had seen a machine or storage that powerful).
Sun just couldn't compete. For Sparc stuff, we would have needed a $5 million machine to outperform the $500k Fujitsu. The diminishing returns from the supposedly scalable Sun systems meant we had to skip two entire product lines. Unfortunately we couldn't test the next level up, and our experience with the E10K (64 CPUs underperforming 12) was that Sun machines don't always scale like this.
When we went to Intel hardware, we would have needed a $250k Sun machine and $250k SAN storage to perform comparably to a $50k Intel machine including internal storage.
We gave Sun a really good chance to compete each time, everyone involved had a strong personal attachment to making it work and had not yet accepted that Sun had failed as a business. We allways talk about that initial revelation that if Sun couldn't compete for our setup, they probably couldn't compete anywhere unless this is just a temporary gap in the product offering.
The Sun machines were the least reliable compared to the Fujitsu and Intel solutions. Random were weekly events on the Sun machines (e.g. [456]500s, E10Ks), every few months on the Fujitsu Primepower 850 machines, and hasn't happened ONCE after two years on the Intel machines. And I'm comparing it to a MUCH larger population of Intel machines (we added dev, qa for each of app groups, sysadmins, DBAs, "yesterday's data" for support people, added another server for performance, and then duplicated the entire 5-server setup when we took over another business unit's almost identical application.
Although I could say in theory I miss being able to identify and replace failed hardware components easily, the reality is that the HP servers identify the part that caused a crash with a fault light most of the time. Sun needed a case to be opened with them to explain a complicated error. This changes the hardware fix from under 5 minutes - a datacenter tech can do it himself - to hours at minimum, and days if their support screws you around.
Being able to do the hardware replacement faster also means no second downtime to do the actual fix. And the confidence level from a clear fault light is huge versus a vendor's first line support that is known for lying when decoding an error message based on what looked "obvious", not based on the real complexities involved.