Hi, Sounds like an good move, however I don't think that you mentioned or proposed how we tackle one issue of taking OI into production server (which is possible, I go live with 3 OI servers on Monday <gulp> ;) ).
Currently the dependency chain of the packages, is erm to be polite utterly broken... Before we can consider a stable build, we have to fix that a text install takes 2.6GiB and includes so much stuff that doesn't belong. Trying to remove via pkg gets you nowhere as it horrible chained together incorrectly. It's a security nightmare, the only way I currently feel safe is that I have a zone that faces the world because zones (for some reason) install much more striped down installs. IMHO First thing should be making a minimal server install, debootstrap minimal. Get a unix base system, IPS package manager and wget and the rest can come later. TBH the install a new zone gets is more like the default install should be imho. Then have a number of repositories with different classes of supported apps, Primary being your list and with critical fixes etc. and then secondary being less supported apps. Your proposal to focus on a small set of apps is correct imho, new users to OI stable will be early adopters almost by definition, so by being honest and saying OS is stable and great and so are these major programs, but not everything out there is to the same level, we encourage champions to take their favorite program and get it on the major supported list. Also a smaller core will make the illumos switch faster, I'm personally not sure if stable should become before illumos integration. OI on illumos works now, with locales being the major issues (being worked on), it doesn't feel right to call OI stable without it using (even a WIP) the base that it requires going forward (OI on ON isn't really stable as it's a EOL, which implies an unstable future). As you're worried about missing the window, as OSol users migrate to linux or FreeBSD IMHO that is more a perception issue. OI website appears very slow moving, even dead. Bringing some life there may help that issue, call the WIP stable build, Early Adopter build or something like that, post EA new builds once a week on the front page. Get silly screen shots of shell doing zfs, or apache configuration files, all completely useless BUT highlights that look this thing is real and running apps you, as a IT geek are wanting to run... As a production OI deployer, I really care about 1) Minimal install with just the programs I want, 2) Critical fixes for the OS and those apps if I use the package system. 3) A safe build environment, as there is a fair chance I'll be building app myself at this stage (I use a separate machine for this as the safest way :) ) 4) Something that will upgrade nicely for the say 3 years. For OI that scream illumos IMHO 5) A community with nice central info pool, currently the OI wiki and webpages doesn't feel like a community, wiki access is restricted, so not encouraging writing up notes and most of the useful information isn't on there anyway. Half the time you end up on Oracle web pages, which makes you wonder if this is a real OS. 6) Security info and concerns, from articles to hardening the OS to using VMs (Xen, Zones, Virtual box?) to isolate components. Probably just an extension of the wiki and/or blogs but I'm sure some of the in the trenches guys would be happy to write a few articles on how we got OI onto the front line and in use. Hope this doesn't sound negative, as mostly I agree with your proposal (only thing I really disagree on is non illumos). At the moment OI is very much a shadow of OSol choices, which I don't think apply here, for it to go stable it needs to shake of its old masters clothes and choose its own route. Starting with a small server distro that just happens to have a huge repo of other apps including desktop, allows it to find a niche and then expand out from there. As a server (especially a storage server) OS imho its second to none :) Bye, Deano de...@cloudpixies.com -----Original Message----- From: Alasdair Lumsden [mailto:alasdai...@gmail.com] Sent: 14 January 2011 20:36 To: Discussion list for OpenIndiana; OpenIndiana Developer mailing list Subject: [OpenIndiana-discuss] Proposal: OpenIndiana Stable Branch 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 _______________________________________________ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
