Wednesday, December 30, 2009

Looking back a decade, part 1

It's now a new decade and a good time to take a look on the important things that's happened the last 10 years with focus on Sun and Solaris. I'll try reflect on the good things and mention some of the bad things that have forced Solaris and Sun into a series of transitions. I'll split this into three posts. I'll begin around the year 2000, probably in the 1998-2002 range.

The new millennia began with a massive hysteria about the Y2K bug and everybody was upgrading server, storing food and preparing for the final hour. Sun had spent the nineties transforming the business from workstations towards servers and fighting for open standards and network computing. Many Solaris sites where at the time running Solaris 2.6 and applying all the "Y2K" patches to their systems.

Solaris 7 was available, but since it was the first 64-bit release of Solaris, third party development was lagging. Veritas Volume manager (VxVM), which at the time was close to a mandatory part of all enterprise installations was delayed for a very long time. Sun was without a good volume manager for Solaris and UFS was yet to be enhanced for better performance and disk suite had not been kept up to date since Sun even had bundled VxVM. All this was probably enough to have a fresh look at a new storage solution for, i think an early internal name for this project was "pacific", but I might be wrong. Probably as an interim Solution the Solstice volume manager was integrated into the next release, Solaris 8 as the Solaris volume manager.

Apart for the lag in third part drivers the transition to 64-bit was made early in Solaris, and without any of the hassle we are seeing on other platforms today, ten years later. There was one distribution with could run either a 32 or 64 bit kernel and in the later binaries of different bitwidth could execute side by side.

Solaris 2.6 to Solaris 7 where dependable and competitive for the time, but compared to what we are used to today it was a bit slower and more of just an standard System V implementation than todays Solaris. It was also more "bare" with little additional software beside the core OS included. Several administrative tools that we take for granted today was not available, some of them was introduced with Solaris 8 such as prstat, pgrep, pkill and mdb. The Solaris development process was much more closed, no source, no blogs about new features, no public ARC cases and no external development builds to test.

On the hardware side the UltraSPARC II was powering the Ultra Enterprise series. While being the first high volume server series from Sun it was dependable and sold very good. The size ranged from the one socket Ultra Enterprise 1 to the 64 socket Ultra Enterprise 10000 (StarFire). With such large systems even in the late nineties it's no surprise that Solaris have had little problem scaling on todays multi core processors. I remember thinking if I could get my hands on a E3000 when it was time for retirement, over ten years later I now have one as beer table beside my armchair, not quite what I intended back then.

Sun had several very good years late nineties, they where the number one Unix vendor and for a short time I think they even one of the top storage resellers, much due to all internal drives. But when the decline began in 2000 sun was hit hard. The investments into research and development did however continue which bare fruit some years later and is still making a difference, but more on that in the next post.

Looking back, I sometimes wonder what would have happened if Sun made the decision to make Solaris freely available and open already at this time. It would probably have grown the community and general acceptance much faster since Solaris had more presence outside server environments then. It was more widely used at universities and still had some of the workstation business left. Then again, no other of the big vendor have released their source, it's not available for AIX, Irix, HPUX or Windows. The initial lack of commitment to the X86 platform probably also hurt Sun when it became de-facto standard for small servers, but as long as it did not provide any threat to SPARC, too little effort was put into the alternative hardware platform.

4 comments:

Henrik said...

My opinion is that Sun opened up Solaris too late and kept the closed source attitude.

I find it hard to track the development of OpenSolaris when so much work and information is kept "behind Sun firewalls".

I use OpenSolaris for my home entertainment server (mainly because of zfs & cifs) but would not use it in my work as software developer it's too inmature right now.

lanc said...

Are there followup-parts to part 1?

Henkis said...

Henrik: Yes, they where late, and it have taken a long time to change the attitude also, I think it's have gotten better the last two years or so, but there are still some parts of the development that are internal only until it is released. I think we will have to live with this, other companies does similar things even if released as open source later. Even if some other companies base their products on kernels with a more open development process, the companies itself often have restrictions on what they release in the form of information or even code.

I have used OpenSolaris both for desktop and as storage servers, i think the desktop have needed improvements but is quite usable since 2009.06, we'll se how 2010.03 turns out. I'm using OSX as well, as long as I have dtrace on my desktop I'm fine.

Servers depend on the need, at work we only use Solaris 10 due to support cycle, software support and maturity, for smaller projects or isolated needs such as storage OpenSolaris have worked quite well. It needs some more time before it's ready for the enterprise and I would let it handle the cooling for a nuclear reactor or something else where more than money is at stake ;)

Henkis said...

lanc: Sorry, yes, I've posted part 2, I have taken more time than I've had available.