Hi All,
I believe now would be a really good time for us to create our first stable
branch of OpenIndiana, given the timing of some developments within the project.
Below I've outlined my proposal and I'd love feedback from the community and
from OI developers!
Obviously as a new project with a small (but growing) developer base, providing
support for the whole release isn't feasible - there are literally thousands of
packages in the distribution. But we have to start somewhere, so I'm proposing
we provide limited support (outlined below) for a set of core packages.
********
* Why? *
********
Prior to the Oracle takeover, Solaris 10 was free to use in production, and for
a long time, security updates were provided free of charge. OpenSolaris was
also free to use, and updates were available by living on the bleeding /dev
edge. People were (mostly) happy.
Then Sun hit financial difficulties and discontinued free security updates for
Solaris 10. Then Oracle happened, ending the free use of Solaris in production.
This has left people wishing to use Solaris technologies on their production
servers in a difficult position. They have to pay Oracle, or use distributions
that don't provide security updates. Or switch to Linux.
There are a great many people who would jump at the chance to use Solaris if
there were a production ready version with security and bug fixes provided for
free.
Indeed, this is what people have come to expect from mainstream UNIX platforms
- Linux distributions such as Debian, CentOS, Ubuntu, etc, provide updates free
of charge - and this is one of the reasons they have become so popular.
We have a real opportunity to capitalise on the situation left by Oracle, to
capture server market share away from OpenSolaris, Solaris 10, and give users a
migration path other than switching to Linux (which a lot of people are doing).
There are a lot of people out there who *really really* want a stable build of
OpenIndiana - myself included, and I believe OpenIndiana's best chance of
gaining acceptance, market share, and building a thriving development community
is by capturing the server market.
There is also a risk that if we *don't* do this, we'll become an obscure fringe
distribution, like DragonflyBSD.
The goal here is to be the *mainstream* accepted de-facto Solaris distribution.
Something people talk about and seriously consider using.
Solaris contains killer technologies not seen on other platforms; technologies
like ZFS, Zones, SMF, DTrace, COMSTAR, Crossbow - I couldn't live without any
one of these, and we should capitalise on this while we can.
It's also worth keeping in mind that despite warning users that oi_147 and
oi_148 were development releases, people are already using it in production
environments, myself included, due to a lack of alternatives. The great news is
that it has proven to be exceedingly reliable, and I have no hesitation in
recommending it for busy workloads. All we need to do is add security updates
and critical bug fixes on top and we'll be in a great position. No small feat I
grant you, but we can start off small and work our way up.
Now is also an opportune time to do this - our next release will be based on
Illumos, which has seen rapid development and will involve some integration
pain. Some have called for a stable branch after Illumos is integrated, but it
could be many months until we have an Illumos dev build suitable for respinning
as a stable branch. That's months of lost opportunity.
So I say we do it now.
/dev builds will continue as normal, the next one will be Illumos based -
Desktop users can continue to use our /dev builds, and internet facing servers
can use the stable branch.
*********************
* What we'd provide *
*********************
The release would be aimed for February, and titled "2011.02". It would be based
on oi_148. We would only provide the Text Installer and Automated Installer
ISOs.
We would provide security and critical bug fixes only for:
1. OS/Net (The core OS consolidation)
2. A limited set of server oriented packages that have the greatest usage and
attack "surface area". The initial list I can think of includes:
- OpenSSL
- Sendmail
- Perl 5.8.4
- Python 2.6
- Ruby
- zip, bzip2, gzip
- Apache HTTPD 2.2
- PHP 5.X
- MySQL 5.X.X
- Postgresql 8.4
- Java
- Tomcat
- GNU Coreutils
- GCC
- RSync
- ISC BIND
- Bash
- Curl
- wget
We should also aim to provide security fixes for any bit of software in the
repo that allows an easily exploitable remote access vulnerability or root
privilege escalation, although we cannot guarantee to do so as monitoring
security updates for over 1000 software packages is unfeasible. An example
would be the recent Exim vulnerability on CentOS that allowed remote root
access by sending appropriately formatted emails. This area is something where
we will depend on users, not OI developers, alerting the project to the issue
so that a judgement call can be made on whether we have the resources to fix
the issue.
Security updates would be provided from 6 months of the release date, or until
the next stable release is released. Potentially we have the option as a
project of providing commercial support past the 6 month date if enterprises
desired this. I feel this could be a good way of generating revenue for the
project to fund development if there was a market for it.
If external contributors were able and willing to commit patches/fixes beyond
the supported list, we'd accept them with open arms, and this could be a great
way to extend the contributor list and get more people involved.
******************
* How we'd do it *
******************
1. We do a re-spin of oi_148 fixing any of the major bugs that we can (Eg
things like the Broadcom driver issue introduced in oi_148)
2. This gets pushed into pkg.openindiana.org/stable (or /release - tbc)
3. Security fixes and critical bug fixes for the supported packages get pushed
into the repo. People doing an image-update would then receive the latest
packages.
4. Security fixes and bug fixes would be backports to the version we currently
provide.
People should be able to update from oi_148 to 2011.02. And people should be
able to update from 2011.02 to oi_150. But people should not be able to
downgrade from oi_150 or later to 2010.02. This is the same as the situation
was with OpenSolaris releases.
To make the above easier to manage, one proposal I have is to match the
versions of Apache, PHP, MySQL, Tomcat etc to the same versions shipped in RHEL
6/CentOS 6. This way we can monitor their repositories for security updates
against these packages, and share the same backports. This will make life a lot
easier for us as a project.
The main thing will then be doing rebuilds of the packages involved. I would
suggest we keep a set of Zones on infra01.uk.openindiana.org around for doing
this, so that doing a rebuild is very easy to do, and well documented. Just a
case of logging in, patching the appropriate files, running a build, pushing to
a test repo, testing it, and then pushing into the public repo.
**********************
* Concluding Remarks *
**********************
I believe this is a great opportunity for us and I think it's the right time to
do it.
Although we're starting on the server only front, there's no reason why we
can't at a later date add support for the desktop if sufficient contributors
are able to make it happen.
I'm confident that with a stable branch, we can really increase our userbase on
servers, which will bring commercial opportunities from the enterprise, and
accelerate development of our favourite operating system :-)
Looking forward to feedback!
Cheers,
Alasdair.
_______________________________________________
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
