Maybe worth adding ZSH to the list (gets installed by default). Postfix perhaps?
Cheers, Matt On 14/01/2011 20:36, Alasdair Lumsden wrote: > 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 > [email protected] > http://openindiana.org/mailman/listinfo/openindiana-discuss > _______________________________________________ OpenIndiana-discuss mailing list [email protected] http://openindiana.org/mailman/listinfo/openindiana-discuss
