[indiana-discuss] Indiana Problem Statement

Glynn Foster Glynn.Foster at Sun.COM
Mon Jun 11 03:33:29 PDT 2007


Hey,

So as I mentioned earlier, here's what I've been trying to work on over the past
couple of weeks based on discussion I've read, in an attempt to put some
boundaries around on what Indiana may eventually look like. This document is
intentionally high level in terms of content, allowing us to have a relatively
structured set of deep diving for technical implementation (some of which may
already exist).

I know *everyone* is deeply passionate about what they'd all like to see from
this project, but I would like to encourage everyone to act in a constructive
manner so we can get some good positive discussion going on. There's very likely
to be items missing or poorly thought out detail, however I'm trying to find the
balance between providing a base for encouraging discussion, and avoiding
scoping this project out to fine detail right from the start. There's also
separate discussions to be had around the release roadmap.

If you do comment, I'd personally prefer that we have some sort of email
protocol and only reply to a single section eg. Installation, Package
Management, etc.. per email. It will make it much easier to follow the
discussion, and share ideas or suggestions.


Glynn

==

Indiana Requirements Document v0.5

1) Executive Summary

   Project Indiana is a new project to create an OpenSolaris binary
   distribution. This distribution will focus on providing a single
   CD install with the basic core operating system and desktop
   environment, with the opportunity of installing additional
   software off network repositories.

   The distribution will showcase much of the work continuing in the
   OpenSolaris community and the best of breed open source software
   available within other open source communities. Moverover, the
   distribution will include work that closes the familiarity gap with
   existing GNU/Linux users eg. install and packaging.

   Project Indiana will be a leading edge distribution with an expected
   adoption of OpenSolaris enthusiasts and developers on single user
   systems and basic server setups. It will also encourage new users coming
   to the platform for the first time.

   With Project Indiana, other groups will be able to create derivative
   works according to their needs, for example, a special limited release
   for a conference or user group event. The infrastructure to produce these
   derivatives should be widely available, and it should be possible to
   swap out existing branding and configuration defaults.

   Project Indiana at the very core needs to be completely
   re-distributable to encourage the participitary effect of community
   advocacy and opportunity for strong support within the free software
   communities.

2) User Feedback

   2.1) Adoption Barriers

   Solaris is a world class operating system with many innovative
   features. However, in a few areas the user experience has
   been sub-optimal, causing a potential adoption barrier. Those
   areas in particular include ease of management, ease of install
   of the core operating system, the management of additional
   software and configuration and the availability of hardware
   support. Added to this is the frustration caused by the outdated
   nature of existing software, and the poor availability of
   certain development tools.

   2.2) Community Contribution

   The current 'standard' distribution with which to build OpenSolaris,
   and work on for various projects on opensolaris.org is Solaris Express
   Community Edition. That distribution is built and distributed
   solely by Sun, with little community influence over this process.

   2.3) Source or Distribution

   Despite the success of the OpenSolaris community over the last 2
   years, and the phenomenal growth it has seen, confusion has also
   grown over the expectations of whether OpenSolaris is a source
   base or a binary distribution. Many newcomers to the community
   assume there is an official OpenSolaris distribution to
   download and install.

   2.4) Distribution of Media

   Solaris has grown to 6 CDs or one DVD, and continues to push
   the bar on size requirements of the install media and in the
   case of Solaris Express, the upgrade ability. This has a
   disincentive for those people to try installing it for those
   who may not have the bandwidth resources to download the
   distribution.

   2.5) Path to Freedom

   Today, not all consolidations are 100% open source software due to
   the restrictions on certain parts of the code that is outside the
   control of Sun Microsystems. As a result, much of the core operating
   system cannot be self hosting ie. built without currently closed
   sources.

3) Technology Priorities

   3.1) Installation

        INS-1: Provide infrastructure to install Indiana from
               a single CD. The default install should be a
               graphical experience, with a text console install
               if preferred. The core install will be a basic
               operating system and desktop environment.

        INS-2: Existing installations should allow a seamless
               upgrade to the next consecutive stable
               release or future releases within certain well
               defined boundaries.

        INS-3: Any installation should be aware of existing
               installed operating systems, prompt the user
               for an appropriate action and intuitive
               steps to carry out that action, particularly
               with respect to re-partitioning if
               necessary.

        INS-4: A LiveCD should be available for a 'try first,
               install later' experience. The LiveCD functionality
               should be integrated into the core install CD.

   3.2) Package Management

        PKG-1: Provide package management infrastructure that
               allows easy install, configuration and removal
               of software with full dependency checking and a
               'just works' experience.

        PKG-2: Software will either be installed by default on
               a single CD, or easily available over the
               network in binary form through package
               management tools.

        PKG-3: Software should also be available in meta clusters
               for people to install specific to their needs eg.
               Web 2.0 meta cluster.

        PKG-4: An existing network repository can be easily
               mirrored, and users can appropriately configure
               their system to install packages from there
               instead.

        PKG-5: Provide a series of tools to allow developers
               to create and maintain their own set of
               packages as part of an unsupported package
               repository, or propose them for a supported
               package repository.

        PKG-6: Packages will be upgraded as appropriate
               through an automatic update facility and
               notification to the user.

        PKG-7: It should be possible to preserve the current
               environment prior to an update so that a
               rollback is possible in case of breakages.

   3.3) Familiarization

        FAM-1: Provide a set of packages in the default install
               and network repositories that users would typically
               expect to see with a similar UNIX operating system
               eg. GNU/Linux.

        FAM-2: Provide an environment such that migrating (particularly
               GNU/Linux) users will be familiar with the utilities
               available, while preserving the binary compatibility
               story that people want and expect.

   3.4) Laptop Support

        LAP-1: Provide a utility to generate feedback for system
               configurations that are being installed, and build
               a basic public hardware compatibility list. Provide
               drivers for the most popular configurations.

        LAP-2: The user environment should support basic power
               management, both suspend and resume. The user should
               be notified when their battery is low, and offer to
               shutdown or suspend. The system should also suspend
               in times of inactivity.

        LAP-3: The system should automatically connect to an available
               network, whether through a network cable or wireless
               connection.

        LAP-4: Any system connected up to an external video projector
               should work without needing added configuration.

   3.5) Derivative Distributions

        DST-1: Indiana should be created out of solely re-distributable,
               modular binary components that are open source. Indiana
               should value a strong commitment to freedom - the freedom to
               download, run, copy, share, change and improve.

        DST-2: Infrastructure to create a derivative distribution should
               be freely available, and easy to use.



More information about the indiana-discuss mailing list