OpenSolaris Governing Board Dissolves Itself 198
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."
bOrg (Score:4, Interesting)
So they took their toys and went home (Score:2, Interesting)
So what? OpenSolaris was a bad joke anyway.
In the true spirit of OSS, they packed up their bags, stuck out their tongues and said 'fuck it, we're done dealing with you guys, we're going home' ... and thats perfectly within their rights.
It should be noted however, since they were about the only ones using OpenSolaris, no one is really going to notice they are gone.
Using OpenSolaris is roughly the same as running Darwin instead of OS X. Roughly, not really the same, but both are pretty much pathetic bases of the what the person actually WANTS to run, which is the full version. Anyone who would consider running OpenSolaris will just pay the tiny little fee and run the real deal which has slightly (not much mind you) more spit and polish on it.
Re:What momentum may that fork have? (Score:5, Interesting)
Nothing, but if we always did the sensible thing we'd miss out on much of the good software that we have today, such as Linux. There was a time that when it offered very little.
Oh come on, that's revisionist history at best. When it was first released, it offered an alternative to Minix, and was one of the few protected-mode-capable Unix clones available for x86. As it progressed, it offered the first kernel (sorry Hurd) for a GNU-based OS.
Linux *always* had a niche to fill. I can't see how the same is true of OpenSolaris.
Re:What momentum may that fork have? (Score:3, Interesting)
A open and free version of solaris. Oracle is going to delay the release of the source code to make their propietary distro more attractive, but at some time they will release it. Illumos will offer a free version of that, and many people (including oracle customers) will want to use that. It bet it will be popular in the "solaris community". Also, there are companies like Nexenta which can try to develop new features. It won't be as nice as opensolaris was, but it's not the end of the world either. If I use solaris some day, I'm pretty sure it will be illumos.
Re:What momentum may that fork have? (Score:5, Interesting)
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.)
Re:Oracle shooting his own foot. (Score:1, Interesting)
This move by Oracle reminds me yahoo in the .com era. Open Solaris was not a revenue source but it was important as the means to get developers interested in Solaris. I don't think there will be much development or support for solaris from the open source community from now on.
Maybe, but OTOH Oracle was very profitable without much contribution from the open source community, while Sun despite having open sourced tens of millions of lines of code had a long sequence of black zeros and red zeros at the bottom of the balance sheet.
Another instance of BSD vs. GPL licensing... (Score:1, Interesting)
...and why the GPL is superior. With the GPL, it is prohibited to take work private that has been built by the community. The BSD license /* encourages */ it. I see on the website [blogspot.com] of an deeply involved OpenSolaris developer where he is complaining about Oracle not adhering to the spirit of the open source license. I suggest that there is only the /* letter */ of an agreement whenever "push comes to shove." Spirit goes out the window.
Re:And nobody cared.... (Score:2, Interesting)
Folks who do opensource NAS care, as ZFS on OpenSolaris is currently superior to anything else in the open sphere, and most if not all of the closed.
But as a Solaris admin, I would much prefer to see a more aggressive improvement of stock Solaris, particularly when it comes to package and patch management.. Nobody here ever did anything with OSol, but watched it to see what would be coming down the pike for Solaris 11..
That said, I'm sure Nexenta and Illumos will fully fork, and presumably if there are enough disgruntled-with-Sunacle devs who want to hack on it in their spare time, then they can make a go of it..
Re:What momentum may that fork have? (Score:4, Interesting)
and iOS, Android, Blackberry, Windows Mobile 7, WebOS, ChromeOS, Playstation/XBox custom OSes, and a few others. And clumping all "Linux" into one (from Ubuntu to Red Hat's Enterprise) is a bit of over-generalization.
In short, if you like playing around with new and interesting programmable systems, it may not be a Cambrian explosion, but we've certainly come out of the temporary bottleneck of the late 90's.
64-way DB Servers (Score:5, Interesting)
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.
Re:64-way DB Servers (Score:2, Interesting)
AC here ... "vendor only certifies on HP-UX", so trying anything else was worthless. The server programs were written in C/C++, so we weren't gonna get binaries for any other platform anyway.
Also, Z-Systems are great for IO, not so much for raw MIPS. Yes, I've watched the 1,000 linux servers running apache on a single mainframe reports. Interesting, but not really useful. BTW, I was a mainframe dev for 5+ years - MVS, JCL, clists, TSO. None of that rocks. Ruby - rocks. Perl - rocks.
I LOVE IBM-POWER-systems, but I would never consider dropping RH on them, except to play with. IBM's LPAR technology is the best there is in the virtualization world, IMHO, and I do a lot of virtualization on UNIX and x64 servers.
When your company is running critical systems and spends millions of dollars on HW and millions of dollars on software, you want as few throats to choke as possible. IBM is one. Oracle is two. The Software vendor is three. During an outage, getting 2 vendors to talk is nearly impossible. I don't want any of them to claim that RH is the issue and have to add a forth party to the issue to blame. Honestly, I'd prefer to remove Oracle and use DB2 on IBM hardware if just for the 1 less throat to look for during an outage.
I've been there with a "very large storage vendor" claiming all sorts of reasons that the outage couldn't be caused by their equipment. We were able to prove the issue was with background mirroring for DR purposes ("BCV copy") that impacted foreground read/write needs for the DB in question after building an accurate timeline for the issue. Basically, we proved it began at the instant the copy began and ended when the copy finished (about 15 min later). Teaching a vendor SE something that he should have known. Our environments tended to break vendor hardware and software. Yes, it was a very large telco.
When you need lots of IO, x64 is not the place to look for 8+ redundant backplanes.
Dangerous. (Score:3, Interesting)
Re:had a zfs scare, today (freebsd 8.0 to 8.1 hicc (Score:2, Interesting)
As someone who has tested out ZFS on both BSD and Solaris, and is familiar with the subject, I can tell you quite plainly: The Solaris implementation is good and generally, the BSD / FreeBSD implementation sucks, is buggy, missing features (or key features are buggy).
The OpenSolaris implementation is mature, well maintained, performs well, and is up to date. The FreeBSD implementation is immature, lags way behind OSol development, and seems to be unstable.
If you want a mission critical system running ZFS, FreeBSD is not an option, period.
ZFS is Stable on Solaris, and to a great extent on OpenSolaris and NexentaCore. There may be some gotchas, in OSol, particularly if you use new advanced features such as dedup.
There may also be some performance gotchas with certain hardware in all implementations (e.g. 32-bit proc, less than 2GB of RAM), and if you use gzip compression.
Just because work has been done to port the filesystem to BSD, does not mean it has the same stability or performance characteristics. It might have similar ones in the future, right now it does not. I would call it "Alpha" quality, even if it is in stable versions of BSD, at this point.
Re:So they took their toys and went home (Score:3, Interesting)
More or less, yes. There are two issues. One is that IOKit has a completely different (although, actually quite nice) design from any other *NIX kernel. This means that porting drivers is a bit of effort. The other is that the userland interfaces for sound on OS X are completely different, so if you port the subsystem from somewhere else you'll end up with something that doesn't look or behave like OS X from a developer perspective.
The same problem applies to the video interfaces. If you want 3D support, you either need to reimplement Quartz, add a whole new set of drivers to X.org, or port DRI from another platform. Porting DRI is the least effort (although still far from trivial), but then you've basically got a system that looks like FreeBSD, but has a poor VM subsystem (improved from 10.4 and earlier, when it was embarrassingly bad - now it's just bad), a terrible pthread implementation, and Mach ports.
You'd be better off writing a kernel module that provided Mach ports to FreeBSD, finishing the Launchd port, and ditching the rest of Darwin. About the only nice things in the open source part of Darwin are Launchd and libdispatch, both of which already work on FreeBSD.