Sven Herzing wrote: > For me, it's the question, if I would need to buy support only to get some > updates, so why not use directly Solaris 10. Yes, I know there are features > in OpenSolaris which are not (yet) in Solaris 10, but at least I would have a > stable version and I would get security updates. > I like to use [Open]Solaris, but I also must look what it's going to cost > me. I'm not makeing money out of my page, so I'm not really happy that I > would need to pay a support contract. > Don't get me wrong, if I would have a business, ok, then a support contract > is not a problem, but right now, it's more a a study project for me to learn > more about Solaris and Opensolaris. > > Sven > -- > > This message posted from opensolaris.org > > _______________________________________________ > indiana-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/indiana-discuss > There are features that'll never be in Solaris 10.
Security and bugfixes will be free, it's backports that'd cost money. OpenSolaris 2008.5 is a developer preview despite marketing push. 2008.11 is intended for GA and that'll include a pipeline for maintaining packages that doesn't for the most part need you to upgrade major point releases. Right now the build monkier is used as the sub-communities release their own large consolidations under the umbrella BXX name, integrating into the mainline tree where it becomes generally available through full integrated builds. Currently integrated builds are the only sure bet on maintaining uniform compatibility across a particularly fast-paced development process throughout the distribution. You're fine to use Solaris 10, unless you're using it on a laptop, where B90+ features will indefinitely outweigh your other gripes. There are minimal barriers to upgrading right now, even with Indiana. If you want better support and a more proven release, go with Solaris Express Community Edition until Indiana is pronounced ready for general consumption. The only thing you really need to know how to do to get specific components upgraded on a SXCE installation are: JDS: unpack a tar.gz, run the upgrade script ON: learn how to BFU (It's quite easy btw, about 5 steps for kernel + userland update) Others: mostly in tar.gz/bz2 or in svr4 pkg format (Easy if you're coming from Solaris 10) Most components do not depend on a current version of OpenSolaris, it seems to happen more with Indiana, whereas if you upgrade JDS on SXCE for example you could be several releases behind, partly because the build machines themselves are several builds behind to make sure changes to components which have potentially critical effects in the utmost build are generally known throughout subsequent builds which could be in mass usage by users. Sun is not purposely breaking things or forcing you to upgrade. It's only the instances where a component that does not itself self contain the parts needed due to library/dependency changes where upgrading to a full build or more ahead is necessary. There is still established binary compatibility and testing done throughout all builds above what the actual components are built upon. There is some testing for releases outside the supported build, but this is obviously not as rigorously detailed and the majority of people keep within 5 builds. Based on a 2 week build schedule, you could go as long as 3 months with most components without upgrading, and again the update process all depends on what specifically you need updated. If you need to do a kernel update due to a security bug, it's not harder than it was to use smpatch on S10 to fix, it's a matter of specifying 3 environment variables, unpacking a tar.bz2 file, installing 1 supportive onbld package using pkgadd, running bfu with minimal arguments and rebooting once, where SMF and library changes will take effect as ON is a consolidation of base runtime libraries in addition to the kernel itself for instance. If you need any additional clarification of an what/if instance you really should ask before discounting the sustainability of OpenSolaris for your workflow. If you were brought to Indiana because it's what Sun pitched to you on the site, be warned it's still developer oriented and obvious things have not been fixed to address limitations, bugs and other general problems which have affected a subset of users. This is not to say that Indiana is not a bad product or unusable, but be ready to get your hands dirty. Just wait until 2008.11 if you're of a general sysadmin/user mindset. James _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
