Surely a fundamental part of the premise here is that there has to be
some incentives to get people to join the OpenSolaris community to
build some of the user base necessary to bed in a new release, and
part of that is that the OpenSolaris builds be easy to deploy and have
an initial focus on cheap x86 desktops and servers, where those
desktops are probably targeted at developers as much as anyone else.
OpenSolaris is thus always going to be preparatory, an indication of
what's coming over the horizon that's considerably more substantial
than a demo but always ahead of release candidacy, so it'll never be
"finished" or "ready" in the sense that you seem to expect. After all,
Sun's problem doesn't appear to be getting Solaris to run well on high-
end servers (they've got decades of experience in that discipline) so
much as recruiting and retaining developer seats and allowing
customers a more straight-forward way to try out things that are
otherwise around the corner and to get behind that direction, while
Sun presumably does some further work on the release once there's a
stable code base implementing the new feature set before blessing it
as a Solaris release.
That's what makes OpenSolaris interesting: it occupies a space rather
ahead of he usual production cycle for developer/customer and Sun, yet
Sun's willing to provide full support for customers who are willing to
be more aggressive in deploying it, including for production (and I'd
think that there would be plenty of shops running open-source
infrastructure for n-tier apps who'd find that the time to market for
new features in OpenSolaris may be worth more on modest x86 SMP
systems than waiting for all the release to be massaged and cut as a
Solaris 10 update or Solaris 11 release that pulls every ounce out of
the bigger Sun iron). As far as hardware support goes, the likely
deployment profile for OpenSolaris, at least in its earlier days,
wouldn't be SPARC boxes, big or small, but x86 kit in engineering labs
that people wanted to get up and running quickly to see if Solaris
could do things that weren't quite coming together in production
("this Linux cack isn't working, what you got Solaris?"), where SPARC
kit and the kind of additional performance validation for big SPARC
boxes could wait until the most recent releases.
In addition to source code access to what's released in OpenSolaris,
these days people have tools like DTrace to give them an idea of
whether their workload runs as well or better with changes that may be
six months or more ahead of release, and there's considerable
advantage in using that to build excitement and confidence, not to
mention analytics that customers can share with Sun where they have
concerns. A decade ago this would have been access by invitation only,
largely limited to large commercial ISVs (I'm largely following the
account offered of the partnership with the major RDBMS vendors in the
Configuring and Tuning Databases on Solaris book by Alan Packer), with
source code licensed separately, but the last decade has shown that
there are distinct advantages to more participatory and open early
access, which is the space OpenSolaris targets. I may be wrong in that
understanding, and I'm sure someone from Sun will correct me if I'm
off-base. In the last decade Sun lost market share because shipping
Solaris lost customer bake-offs to Linux, where Sun couldn't put the
later and greater into the hands of customers to show that promised
improvements were more than vapourware (not to put too fine a point on
it, but if you were using Sun compilers ten years ago, you might be
forgiven for raising an eyebrow to Sun claims and finding yourself
reluctant to say "compilers bad, systems good" after being bitten by
the e-cache rash).
On the other hand, there's a foot-in-the-door element to delivering an
OS that's rather less raw than what arrives on Solaris 10 install
media, and you don't have to be a "shmoe at home" to want an OS that
does a bit more out of the box than does vanilla Solaris if you're
otherwise taking on the workload of sorting out a build with such an
experimental bent. Developers wanting to look ahead don't necessarily
want to have to deal with such initial configuration tasks, which
doesn't make for a simple opposition to "enterprise" deployment
(similar things should hold even for systems engineers). All of this
seems to me a pretty sharp adaptation to the current market, so I'd
struggle to imagine Oracle wanting to pull the legs out from under it.
Am 28 Jan 2010 um 22:08 schrieb Gary Bainbridge:
I realize that OpenSolaris isn't *entirely* separate from Solaris,
but if Sun intended to have the next release of Solaris based on
OpenSolaris, then millions will have to be spent to get it to that
point, and many years.
The better option would have been to have the next release built on
SXCE. Now, I am aware that SXCE was built on OpenSolaris, but it
was more ready for the enterprise because it had the installer,
zones, packaging, etc., already there.
The Sparc text installer for OpenSolaris was only released
yesterday. There can't be any denial that OpenSolaris was targeted
for a desktop user. Network Auto Magic? That doesn't yell
enterprise, but rather joe schmoe sitting at home. OpenSolaris
Sparc wasn't available for the longest time. AI isn't near ready
for the enterprise so how many years before OpenSolaris can be
ready. How is OpenSolaris going to run on M-Series servers? That
I'd like to see. Sun spent $500 million on Solaris 10. Is Oracle
going to spend that much on OpenSolaris to get it ready for the
enterprise? I doubt it. Take the good parts from SXCE and merge
them into Solaris 10 and create SolarisNextGen or something.
BTW, I do run OpenSolaris and have since 2008.05 and will install
dev preview 131 soon.
But please, OpenSolaris isn't ready to be installed on T- and M-
Series servers in a 2000 server data center.
--
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
[email protected]
_______________________________________________
opensolaris-discuss mailing list
[email protected]
