Slashdot Mirror
OpenSolaris Governing Board Dissolves Itself
mysidia writes "Last month, it was mentioned that the OpenSolaris governing board issued an ultimatum to Oracle. It turns out that Oracle continued to ignore requests to appoint a liaison after the governing board's demands. This morning, the board unanimously passed a resolution to dissolve itself. Source code changes are no longer available, and it would appear that OpenSolaris and community involvement in the development of Solaris have been killed as rumored. We recently discussed a 'Spork' of OpenSolaris called Illumos. Perhaps now, this will have a chance at becoming a true fork."
It's not dead, Oracle just told them to go fork themselves.
Why can't we have a knife! I wanna knife! >sniff<
(One of the big benefits of OpenSolaris is that there's a hell of a lot of commercial software for Solaris that hasn't been - and may never be - ported to Linux. This would matter less if the ABI/IBCS module had been maintained, as Linux could then run Solaris binaries natively.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I'm retired now, but at my last job we had 20,000+ UNIX servers. My projects - I was a technical architect - had about 300 of those servers. Trying to compare the throughput for most x86 servers to a P590 or HP Superdome or Sun E25K just shows your ignorance of the larger UNIX system capabilities. From a compute standpoint, Intel CPUs are hard to beat, but when you need 10 fibre connections to storage and 20 10GigE connections and have 10,000 concurrent DB users, RH stuff ain't gonna cut it. Sorry, but those are the facts. These servers aren't for a website.
Then you have the issue of getting a vendor that only certifies their program on HP systems to bother with RedHat. The $3M that the DB server HW costs is nothing compared to the software costs for another platform to be supported by some vendors. The software ran on HP-UX - that's all. The software cost $25M for 2 prod instances and 5 non-prod instances (DR, Test1, Test2, pre-prod ... ) This is software you run your business on AND not very well designed. Bigger hardware is always the answer over system design changes. It is cheaper. Our prod DB servers were 64-way with 108GB of RAM. We had 4 of them - 2 production locations with 2 DB srvs each. An active/failover cluster model. We had 4 DR servers that were almost as large located in another data center that got data updates nightly. There were about 20 app servers inside data centers, about 40 app/GIS servers located in the same building as the users who were spread all over the USA for this project. Another 20 servers were used for the dev, test, pre-prod, test2, test3 environments. It was not possible to run all the software on the say system, at least 3 systems were required for each environment. Crap, I know. Back when I worked on it, VPARS were specifically not supported by the vendor, so we didn't use them - anywhere.
Just because RH claims to run on 20+ way systems, doesn't mean any of the software will. BTW, Oracle RAC was not supported by the sw vendor, so lots of small Oracle Nodes wasn't gonna work.
Anyway, you wanted some background on why anyone uses non-RH machines. Oh - we were seeing about 4k TPS on each production system during business hours. Transactions came from client tools, app servers, reporting tools, and ad hoc queries from blackberries and other portable devices.
We had an outage 1 day for about 6 hours around 2004 due to DB corruption - over 10,000 people couldn't do their jobs (half the users). It wasn't good. I'm glad only 1 production site was impacted.