Archive for May, 2010

Silicon Valley OpenSolaris User Group: The End?

Wednesday, May 26th, 2010

I have tried so hard to be positive and encourage people… but I must bring sad news. The first of all OpenSolaris User Groups, the Silicon Valley OpenSolaris Users Group, may be ending, as we know it, at its final meeting in a Sun campus this Thursday, May 27th.

According to SVOSUG leader, the lovely Alta Elstad, Oracle policy does not permit user groups to be run by Oracle employees or to meet on Oracle properties. Therefore, this next meeting is likely to be the last meeting in the wonderful Santa Clara Campus Agnews Mansion.

At this meeting there will be discussion about the potential future of the group, in some form or another.

If you are in the Silicon Valley please attend! Even if only to pay your respects. Meeting is at 7:30PM.

I want to pay a special honor to Alan DuBoff who started the group and grew it so successfully. I remember approaching him in 2005 I think, with the idea for a Silicon Valley User Group… instead of pitching my idea, he shared his ideas on such a group and had already started to put it together… so at least I got to be one of the first members. :) Alan’s done a lot of great things for the community and we owe him a debt.

Alta Elstad took over leadership of the group when Alan left Sun (ask Alan, he has great stories, but I’ll leave it at that) and has done a great job of keeping the group going, even though attendance has continued to decline. Alta is a remarkable woman and someone whom I have great esteem for. She is truly one of a kind.

Finally, to all those who’ve presented, participated with, and attended SVOSUG over the years, props to you all. I really hope that SVOSUG or some form of a Sun Users Group perhaps can continue onwards in the Silicon Valley.

Understanding OpenSolaris & Its Governance

Tuesday, May 25th, 2010

I’ve discussed this many times before, but the reality still alludes many in our community. Therefore let me speak plainly such that you may understand.

OpenSolaris is not an open source project in the traditional sense. It can not and should not be thought of as such. If you attempt to do so you will only be frustrated and confused.

We have today seen yet another example of such a misunderstanding, when a community member wished to have a community leader punished by the OGB for failing (in his mind) to appropriately act in the best spirit of open source ideals. The specifics of the incident are irrelevant.

“OpenSolaris” as an “open source community” is little more than scaffolding around Solaris Engineering. There is a community structure, but its not really used. There is a governance and governing board, but they have no power and do nothing of significance. You can’t put back (ie: commit) to ON directly and must sign a contrib agreement to even submit code, which is only actually commited at the sole discretion of Sun/Oracle employees (typically your assigned “sponsor”).

Consider my analogy: scaffolding. Scaffolding allows you to navigate the exterior of a structure, to look in to the exterior windows on each level, to build things onto the exterior, or repair cracks and such, so on and so forth. Scaffolding doesn’t allow you to climb through the windows. You can knock on the glass and point at things, but you aren’t inside that structure… your on the outside, looking in.

So it is with OpenSolaris. Oracle owns the structure. We can’t see into its inner rooms, only those with windows to the exterior. We have the ability to look in, suggest or propose or create changes or additions, but we can only hand them to others who actually have access. We can repair the outside of the structure or create custom additions, but no one on the inside of that structure needs to be involved, since its no part of the primary structure itself. We can chat with other folks on the scaffolding, share ideas and fellowship, but we’re still on the outside. Those on the inside may choose to open a window to communicate with us, but only if they choose to do so.

Compare this with what you hear people say about OpenSolaris. I’ll include myself. We like to think we’re inside that building, along side everyone else. And we’re not. We are only as empowered as the good employees of Oracle choose to let us be, through their sponsorship. And this is never guaranteed anywhere… its purely based on their good will.

If you consider the constitution of OpenSolaris, it defines within it a social organization. The conventional word would be: club. And that’s what OpenSolaris is… a club. Little more, little less.

Whats important to you, my faithful reader, is to embrace the reality of this and then leverage it. If you dilute yourself, as I did for many years, into believing that you have some power or ability beyond influence, you will simply frustrate yourself and become ineffective.

What OpenSolaris provides is an amazing amount of access. The developers are available to you (CG/Project forums), the code is available to you, parts of the decision making process are available to you (ie: ARC, CR’s, etc), the support structure is available to you (bug databases), and more. You are not an Oracle employee and you are not in Solaris Engineering… but you can hang out with the folks who are. You can help them, you can talk to them, you can influence them, you can even send code their way. At the end of the day, they are going to do what they and their superiors (now that they have them, har har), instruct them to… but a little constructive and friendly influence can go a long long way in this world.

The harsh reality is, that if you don’t like this, you need to consider your options. Many of us have fought hard against it already and failed again and again and again, and only made enemies along the way. If you don’t like it, consider starting your own project based on the code. Build onto that structure all you wish. Nexenta has done it very successfully, so has Belenix, and Blastwave too. Those projects are successful and strong, but they don’t penetrate into the structure, that is, into Solaris Engineering. They stand independently.

One of the advantages of IPS will be that once a repo is added to your publishers list, you no longer thing about where the package comes from. Blastwave has traditionally provided add on packages in /opt/csw… clearly seperated from the OS. In the future, they will overlay the OS seamlessly. Therefore, consider a situation, such as above, in which the Sun version of some package isn’t what you wish it to be? Simply create your own version, publish it on your repo, and then go tell the community that a better version is available, please add it to their publisher list and install it. Viva la revolution. This, is the way to effect change, far more effectively than pounding and yelling through the glass.

I really have a desire to see the anger, bitterness, and cynicism die away from our great community. Consider the venerable Sun-Net-Mangers list… perhaps the best support list ever. Resources such as this have existed in the Solaris community for almost two decades, without Sun/Oracle involvement. We, as a community, have a lot of capability with or without Sun/Oracle. Lets not loose that can-do spirit. Re-kindle that passion, leverage the OpenSolaris community for what it really is, and make good things happen.

Review: Zabbix 1.8 Network Monitoring

Monday, May 24th, 2010

There are a lot of monitoring tools and frameworks out there. Some are expensive (such as HP OpenView) some are free (such Nagios). All of them have a niche to fill. Zenoss looks pretty. Nagios is will supported and highly extensible. Up.time and WhatsUp Gold are easy to get going. They’ve all got their thing. As such, I spend a lot of time evaluating and re-evaluating them. The one I circle back on most commonly is Zabbix.

Zabbix won’t win a beauty pageant… its ugly, lets face it. But once you get beyond that its all raw power. Its agent based making it easy to extend. Monitoring something new doesn’t require writting some plugin or writing a complex XML description, its just a simple single line in the agent config. It supports alerting through email, jabber, or SMS natively and is capable of doing fine grained escalations. It graphs everything, so there is no need to have Cacti or Munin or some custom RRDtool setup in addition. It is the only monitoring tool/framework that I’m aware of that natively handles IPMI, both for monitoring and actions. It has proxy capabilities for monitoring into hard to reach places (such as a small branch office) and can be multi-teered to control several sites from one point of control. The list goes on and on. Zabbix truly is the state of the art in monitoring…. and its free!

But… its not entirely the most intuitive tool to use. Several core concepts must be fully understood to be effective with Zabbix or its a big confusing mess.. power that can’t be harnessed.

So a very fortunate thing happened to me. I wanted to do a large proof of concept based on Zabbix 1.8.2 but needed to refresh on some basics, when it so happens that Packet Publishing tells me they’d like me to review Zabbix 1.8 Network Monitoring. While a strange coincidence, I wasn’t sure if this was a blessing or not. Most books on monitoring tools are abstract for the first 4-5 chapters, then have a really crappy installation chapter, followed by several chapters on topics that never seem to be what you actually need to do. That is to say, useless.

Thankfully, Zabbix 1.8 Network Monitoring is perhaps the most practical book I’ve ever read. I’d dare say that if I wrote a book on Zabbix it’d be pretty much the same. There is no lengthy flow of abstract BS, its essentially a systematic walkthrough of Zabbix from beginning to end. The first chapter is how to preform a full installation, hitting on the various options and capabilities impacted by them. Then chapter two moves onto configuration, ending with getting your first alert. So, you’ve got Zabbix fully installed, configured, and alerting, and thats just the first 2 chapters! Thats the way technical books should be. :)

The book is laced with screenshots and CLI examples at all turns. It really is a walkthrough, and author Rihards Olups shows you ever step. This is especially important because most of the real configuration in Zabbix is via a web interface, and its confusing to navigate unless you have a picture of what you should be seeing. Its all there, which means you don’t need to frantically flip pages in front of a screen trying to figure out how he did this or that.

It has a great chapter on reporting and another on graphing. I was really pleased that these we’re lumped together or breezed over. They are key capabilities and are given plenty of space.

There is also a great chapter on troubleshooting (appendix actually), which will help you in any areas that cause you to stumble initially.

If you want to get going with Zabbix and don’t want to waste time, this book will save you days. As I mentioned before, Zabbix is configured differently that the traditional tools out there, so you need a keen understanding of core concepts, such as “Hosts”, “Items”, and “Templates”. You can piece it together from the (poor) Zabbix manual and experimentation, your you can just buy the book and get going.

Now…. that said, there are only two shortcomings to the book.

The first is that it can, at times, be a little too fluff-less. There are times a little up-front explanation could have been enhanced before just jumping into it and explaining as he goes along. But that will really be dependent upon your learning style. If you want to get Zabbix going, its great, but if you just want to read about it, its not so easy to just jumping in and out of the text to understand concepts. Again, its a walkthrough, not an overview (such as O’Reilly books, which tell you a lot about it but typically not enough about how to actually make it happen.)

My second nitpick is that distributed monitoring isn’t really explored fully. There is a chapter on monitoring remote sites using proxies, but an additional chapter on complex mult-site installation featuring not just proxies, but also parent-child servers, would have been very welcome. I’m not sure if it was left out because of its complexity or some other reason. Perhaps he’s setting himself up for a sequel covering advanced topics. May have even been due to the length, the book is 428 pages and is really dense material.

The book runs $45 which is pretty standard. The PDF ebook is $33, which is a little steep imho, but like I said, this book really will save you days… so it’ll pay for itself in an hour or two. Incidentally, it looks great on my iPad. :) See the full list of contents and get a sample chapter here: Zabbix 1.8 Network Monitoring. Buy it direct or you can pick up direct from the publisher or at Amazon, or if you’re in the Silicon Valley don’t forget to help out the brothers at Digital Guru.

I’ll throw out a personal thank you to Rihards Olups for the way he wrote this book. His approach was fantastic, and as a technical writer myself I really like the way he tackled it. It takes a special mindset to write so clearly and concisely, and I really appreciate that.

Spoofing an OpenSolaris X86 hostid

Saturday, May 22nd, 2010

hostid’s on SPARC are handy things because through the PROM they are tied directly to the hardware. On Solaris X86, not so much. They are “soft hostids”, software emulated and essentially randomly generated. Because of this fact, it is easy for an upgrade or accidental deletion to wipe out the hostid and potentially cause you problems.

This post applies only to Nevada based installs post-snv_100. Or, more specifically, following the integration of “PSARC/2007/078 Hostid for X86 systems”. For information about the sysinit module and how things worked on X86 prior to snv_100, please see the excellent post The dark side of the source – hostids by Frank Hofmann.

So the hostid is generated during installation and stored in /etc/hostid. This file contains 2 lines, a comment line and the encoded hostid. A valid hostid is 7 hex chars or less, padded to 8 hex numbers. Therefore, 0x0fffffff (zero followed by 7 f’s) is valid, whereas 0xffffffff (zero followed by 8 f’s) is not. To be clear again, these are hex numbers, not ASCII characters.

To set it we first edit /etc/hostid with vi to remove the second line, such that only the comment on line 1 remains. (Backup the hostid file if you think you might want it again later, or if your just playing around). Then we use a bit of PERL (based on an extraction from the method of the hostid service) to add in the encoded hostid. To make it effective update the boot archive (always do this manually! don’t assume reboot will do it!) and reboot:

# echo "0x0ddb00b5" | /usr/perl5/bin/perl -e 'print("\""); while(<STDIN>){chop;tr/!-~/P-~!-O/;print $_;} print("\"\n"); exit 0;' >> /etc/hostid
# sync;sync
# bootadm update-archive
updating /platform/i86pc/amd64/boot_archive
updating /platform/i86pc/boot_archive
# sync;sync;reboot

When the box comes up you’ll have your new hostid!

# hostid
0ddb00b5

If for some reason you get a hostid of 00000000 or a warning that the hostid is invalid, you either got the value too large or encoded it wrong in /etc/hostid. Check that you pasted the code above properly and try it again.

Please note, I assume you’re not doing this to be naughty. I only spent time to figure this out because I had several systems which for some reason got stuck with 00000000 hostid’s (likely because something went wrong during jumpstart).

Creating an IPS Repository & Adding Your First Package

Friday, May 21st, 2010

So IPS is here to stay, most likely, and you no doubt want to get a feel for things. So lets quickly create our first repository and package.

Hold on just one second! Lets get this clear first, IPS is all about network package repositories. There is no “local package” file format. Therefore, its a little confusing to say “create a package”. So lets be crystal clear: we are going to send a bunch of files and meta-data as a package transaction to a package depot server. Fundamental concept…. moving on.

First things first, you can start an IPS Depot (“repository server”, but the daemon is actually pkg.depotd) using the pkg/server SMF service, or start it manually in a shell (so you can watch it work, useful for your first time) like so:

root@quatro ~$  /usr/lib/pkg.depotd -d /export/pkg -p 80 --set-property publisher.prefix=cuddletech
[21/May/2010:00:40:19] INDEX Search Available
[21/May/2010:00:40:19] ENGINE Listening for SIGHUP.
[21/May/2010:00:40:19] ENGINE Listening for SIGTERM.
[21/May/2010:00:40:19] ENGINE Listening for SIGUSR1.
[21/May/2010:00:40:19] ENGINE Bus STARTING
[21/May/2010:00:40:19] ENGINE Started monitor thread '_TimeoutMonitor'.
[21/May/2010:00:40:19] ENGINE Serving on 0.0.0.0:80
[21/May/2010:00:40:19] ENGINE Bus STARTED
..

If you point your browser at http://localhost/ you’ll see a web interface that looks identical to pkg.opensolaris.org. It has 0 packages. So lets add one.

There are many ways to add a package. The most popular way is to create a SysV package and then “convert it”… however I believe that to be extremely hypocritical, given that IPS is all about putting SysV packages to death. So we’re going to avoid that method and assume that we’re going to compile something from source and then package it.

I’ve decided to create a package for rsyslog. So I download the latest source and start to build it:

benr@quatro rsyslog-5.5.5$ ./configure --prefix=/usr
...
benr@quatro rsyslog-5.5.5$ gmake
...
benr@quatro rsyslog-5.5.5$ mkdir -p /tmp/staging_root
benr@quatro rsyslog-5.5.5$ DESTDIR=/tmp/staging_root gmake install
.....

Notice here that I built it to install into /usr, but before installing it I did a little switcharoo by over-riding the DESTDIR variable. The result is that gmake install installs into /tmp/staging_root, with all the links and configs as though it was in /usr.

Now that I’ve got my faked out installation, lets use pkgsend to import that directory structure:

benr@quatro rsyslog-5.5.5$ pkgsend open rsyslog@5.5.6
export PKG_TRANS_ID=1274430097_pkg%3A%2F%2Fcuddletech%2Frsyslog%405.5.6%2C5.11%3A20100521T082137Z
benr@quatro rsyslog-5.5.5$ export PKG_TRANS_ID=1274430097_pkg%3A%2F%2Fcuddletech%2Frsyslog%405.5.6%2C5.11%3A20100521T082137Z

benr@quatro rsyslog-5.5.5$ pkgsend import /tmp/staging_root

benr@quatro rsyslog-5.5.5$ pkgsend close
PUBLISHED
pkg://cuddletech/rsyslog@5.5.6,5.11:20100521T082137Z

And thats it. I first used pkgsend to open a new transaction to the depot server. This starts a new package. It returns to me a transaction ID which I export as a environmental variable used by future commands. Now I import the staging_root that I installed our tool into. Once done, I just close the transaction, and its done.

If I wanted to add meta-data, I could insert the following before closing the transaction:

$ pkgsend add set name=pkg.summary value="Rsyslog is an enhanced multi-threaded syslogd with a focus on security and reliability"
$ pkgsend add set name=pkg.description value="Rsyslog is an enhanced multi-threaded syslogd with a focus on security and reliability"
$ pkgsend add set name=description value="Rsyslog is an enhanced multi-threaded syslogd with a focus on security and reliability"
$ pkgsend add set name=packager value="Ben Rockwood (benr@cuddletech.com)"

Now go look at the repo in your browser again. Sure enough its there.

To install the new package, add your local repo to your IPS repo list and then install it:

benr@quatro ~$ pfexec pkg set-publisher -g http://localhost/ cuddletech
benr@quatro ~$ pkg publisher
PUBLISHER                             TYPE     STATUS   URI
opensolaris.org          (preferred)  origin   online   http://pkg.opensolaris.org/dev/
contrib.opensolaris.org               origin   online   http://pkg.opensolaris.org/contrib/
cuddletech                            origin   online   http://localhost/

benr@quatro ~$ pfexec pkg install rsyslog

DOWNLOAD                                  PKGS       FILES    XFER (MB)
Completed                                  1/1       33/33      0.7/0.7

PHASE                                        ACTIONS
Install Phase                                  41/41

Pretty easy right? Creating packages can be really hard if you add all the files manually and nit-pick it, but personally I find this “import /some/dir” to work just fine. It also works on tar files! :)

Good luck with IPS.

BFU, RIP

Thursday, May 20th, 2010

For those of you who may be unclear on what BFU is, it has become short for Blazing Fast Upgrades. The Solaris (“Nevada OS/Network Consolidation”, to be specific) source traditionally had the ability to output BFU images, which are really just cpio archives that can be overlaid on an installed system. The idea was to allow developers to quickly and painlessly (as possible) update to the new builds without the usual patch hassles or doing a full re-install.

For some time now you’ve had the option to download CD/DVD images of OpenSolaris (or SX:CE, or whatever), the source and tools themselves, or BFU images. When you combine BFU with the ACR (Automatic Conflict Resolution) tool, you could keep ugprading from build to build for a while before the works got so gummed up that you needed to reinstall.

You’ll notice that snv_139 and snv_140 didn’t include BFU’s, making me wonder if this was a temporary problem or a permanent change.

Turns out BFU’s are, essentially, gone for good. The source, supposedly, can still produce them, but they will no longer be provided with the source releases and very soon they won’t be possible at all.

In March, Liane Praza announced in a Flag Day report, among other things, that:

“BFU is still available (though ACR is not), but pkg image-update is the preferred testing method. Support for BFU is expected to be removed in a few builds.”

That was March, “in a few builds” is now.

I’m informed by James McPherson that following the integration of the IPS packaging changes, the onu (“Os/Net Update”) tool will be replacing BFU, preforming essentially the same function.

If you want to keep up on all the deep changes that are happening to ON because of IPS, please subscribe to the on-ips-dev mailing list.

I hope you can start to understand just how major a change IPS really is… its not a topical cream for Solaris… its a heart transplant.

The Case for IPS

Wednesday, May 19th, 2010

On the list of those who hate IPS, I am the first. Even so, it is a very long list, and one that will grow longer and longer as it ceases to effect hobbiest and early adopters and becomes a reality in a proper Solaris GA release.

While IPS has been around for some time now, only recently did I actually fully understand its purpose. In meeting with an engineer at Sun (whom I shall not name, but not directly involved with IPS) I started into my years old “Why IPS is an abomination” rant. However, during this vigorous back and forth debate, it finally clicked fully in my mind exactly why Solaris Engineering wants IPS so desperately. And, furthermore, why I am trying in vain to kill it.

You’ll recall back in time, when dinosaurs roamed the earth, that Bart Smaalder’s posted Rethinking Patching. This has been the real key, and I’ve known that, but for some reason his point was lost on me in the midst of his “Dim Sum” analogy and the takeaway phrase that ensued: “No more dim sum patching”. I’m sure some people really understood this and embraced it, but as for myself and many others I’ve talked with over the years, we somehow missed the essence of what he was pointing out and what its full ramifications would be.

Lets put the “dim sum” analogy away. What he’s getting at here is that Solaris patch management is and has been for a long time, a complete disaster. No one will dispute that. Proper patching requires that the environment be in a known consistent state such that it doesn’t inadvertently cause additional unexpected problems. But when you are installing dozens, perhaps hundreds, of patches over a period of time the OS become a tangled mess. The practical reality is that administrators reject “Patch early, patch often” for the more reliable “Don’t fix it if it ain’t broken.”

All that gets so much worse when people don’t simply patch the systems as Sun tells them to (through maintenance updates) but instead pick-n-pull only patches they want. Doing any kind of intelligent patch management is almost impossible because there are so many various dependencies and possible conflicts, only a handful of which that Sun even knows about.

Therefore, IPS first and foremost is about solving that very problem of patch management and going from one known state to another known state.

That’s it. It’s not about being easier to use (but that is a selling point). It’s not about being more like Linux (but that is a selling point). It’s not about moving from a bunch of DVD’s to a network repository (but that is a selling point). It’s all about unf**king patch management on Solaris for enterprise customers.

But, its not just about IPS. UFS isn’t an option for your root file system anymore; why? Because ZFS Boot Environments (BE’s) which allow point-in-time rollback following an update is just as critical to patch management and establishing “steady state” as IPS is.

Same thing goes for Sparse Zones. Managing dependencies between the Zones and the Global Zone is complex, IPS makes it even more so. Therefore, because IPS can already manage non-root images and ZFS Boot Environments can be extended to Zones, why not simply embrace the same model there. Those of us who would say, “Keep zones simple, let me manage the deps!” is akin to a customer saying “I still like the old pick-n-pull model, please let me continue.”

Additionally, although many of us value Sparse Zones for their security… Solaris Engineering (on the whole) see’s them primarily as a way to conserve disk space. Therefore, they will contend, ZFS Dedup relieves them of the requirement to support Sparse Zones.

For those of you who, like myself, want IPS removed from Solaris completely…. we’re almost certainly out of luck. The ONNV source code was changed, circa snv_131, to stop producing SysV packages from the Makefiles. It’s all IPS-ified now. That is why SX:CE died. Prior to that point, SysV packages would be produced from a build and they would be converted into IPS packages, this is why the IPS package names were the same as the legacy SysV packages (SUNWsomething). With that major code change in place, its not simply of matter of flicking the switch back to SysV.

Because Jumpstart is a harness around SysV packages, it dies too. You’ll notice that a single-user install from CD/DVD is actually just a local jumpstart… its the same process essentially. So when the old installer was replaced with Caiman (originally billed as an easy-to-use graphical installer), it now had to pickup the slack. Since retrofitting Jumpstart for IPS would essentially invalidate the work done on Caiman, it was extended to become AI, the Automated Installer.

So you can see that in untangling the patching mess, we’ve created a whole new breed of technologies which are simply a different kind of mess. And this isn’t one we can just petition to have removed. Solaris Engineering is right to try to ease the suffering of enterprise customers, and should be applauded for their valiant efforts to go the distance to solve it… even if it causes untold new problems for customers.

So, this isn’t about the continual Linux-ification of Solaris… that’s why they didn’t choose Yum or some other existing Linux packaging system. This is about patching. And if you, like myself, just accept that explanation and take it to heart, all the other weird and bizarre changes they are making seem to make sense. (We may still violently disagree, but they make sense.)

No News is Bad News

Monday, May 17th, 2010

A reader wrote today wondering why my entries have slowed down and there isn’t a lot of news coming. Quite simply there isn’t much to say. I’ve felt a need to return to blogging various smaller technical posts just to keep the blog on life support until something happens at Oracle.

Larry ranted about Sun’s problems to Reuters recently. Perhaps the only surprise was this: “More infuriating, says Ellison, is that Sun routinely sold equipment at a loss because it was more focused on boosting revenue than generating profits.” I think we all knew Sun was taking it in the shins to push sales, but apparently it was more widespread than I was aware. Larry added that Sun spent a fortune on airfaire the last days of a quarter to pack it in.

But I, like many of you, am focused on where we are now. Right now Oracle isn’t saying squat about the future of Solaris… just “its not dead, please wait.”

Regarding Solaris 11. There is no word. I personally believe with complete confidence that Oracle will announce Solaris 11(g?) at OpenWorld this September. I have no proof or evidence, I just personal believe it to be consistent with how Oracle operates and the development pace in Solaris Engineering. I think they’ll stay quiet until that release and then push Solaris forward with great gusto.

Regarding OpenSolaris 2010.03. It’s now 2.5 months late. It could come this week, it could come in 3 months… there is no way to tell. OpenSolaris dev updates on pkg.opensolaris.org have stalled at snv_134, so we know that snv_134 is the target build for 2010.03, but thats about it. I know they are working hard toward it, but I don’t know why or how or what precisely they are doing. Maybe they are vetting out all the compatability issues or fixing AI so it can get real adoption, but whats clear is that they are putting a lot of effort into something a lot of people think will be killed or sidelined.

A theory that just pops into my head is that Solaris 11 itself may be based on snv_134 as well and they are working on both to align them. Maybe that’s possible. I don’t know, its just a thought that comes to mind.

In the meantime, there is an increased exodus to Linux and other platforms. Particularly from customers who were unsatisfied with Solaris 10 and embraced SX:CE as an interim solution.

Some of you will recall my OPEN LETTER TO ORACLE. It got no response. None. Nothing.

Some of you will have noticed my push to explore the OpenSolaris delays through “proper channels”, that is through the OGB. The idea was this… OpenSolaris is developed in several OpenSolaris.org Community Groups (CGs), such as pkg (for IPS), Indiana, Distribution, ON (the kernel itself), SFW, etc. Therefore, if we wish to get answers, perhaps the OGB should simply formally request a status report from the appropriate CGs! That makes sense right? But the board members can’t seem to think this way… they insist that “OpenSolaris” the distro is an Oracle controlled thing and therefore won’t even try. The OGB has no interest in governing their own community or even making attempts, vain as they may be, to make progress. This is precisely why I declined nomination this year, the OGB is completely useless. The press that resulted from my proding turned into a useless circus with OGB members suggesting a fork is imminent…. and that’s simply madness.

But… is hope lost? NO! Is Solaris dead? NO! I still believe that things will be made right and that a new era is opening up for Solaris. We’re simply in a very scary transition period which will pass with time. Once Solaris 11 is released we’ll look back and wonder why we all made such a big fuss…. but it would sure be easier if we got a little love from Oracle or Solaris Engineering.

Keep the faith. Try to keep your organizations from flee’ing a great platform and just stick it out as long as you can. Lets all hope that Oracle gives us a little support here and lets all just keep taking it in the crotch until that time.