OpenSolaris

1. Project: Indiana
   1. Discussions
   2. Documentation
   3. Status
      1. Accessibility
         1. Do-It-Yourself Constructor Notes
      2. Derivative Distributions
      3. Familiarization
      4. Installation
      5. Laptop
      6. Package Management
   4. Leaders
   5. Observers
   6. Library
   7. Files
   8. CD Space Analysis (primary languages)
   9. CD Space Recommendations
   10. Building ON

OpenSolaris 2008.11 Requirements Document

Document Author: Glynn Foster, v0.1

1. Executive Summary

OpenSolaris 2008.11 will continue to build on the new technology advancements introduced with the first release in May, particularly in the areas of installation and management of software, with a strong focus on user experience and good usability. Additionally, this release will include a focus on familiarity with existing GNU/Linux users and work towards lowering the barrier to adoption.

As the new package management infrastructure, IPS, starts to take shape, an increased emphasis will be on providing both best of breed open source software and commercial offerings in a set of network repositories for users to connect and install from.

OpenSolaris 2008.11 will also mark the introduction of a distribution constructor, allowing users to create derivative works according to their needs, for example, a network storage appliance.

OpenSolaris OS will continue to have a re-distributable install image that can be mirrored on download sites around the world to maximize the participatory effect of community advocacy and support within the free software world. The operating system will be available on SPARC platforms for the first time, with support for an automated installation profile rather than LiveCD install experience.

2. Technology Priorities

The following section lists out a set of technology priorities for OpenSolaris 2008.11. It by no means attempts to be an exhaustive list of projects for inclusion in this release.

2.1 Installation

        INS-1: Provide infrastructure to install OpenSolaris 2008.11
	       through the network as an automatic installation
	       based on a descriptive install profile. The default
	       install profiles provided should include both a minimal
	       installation (core operating system and command line
	       utilities) and graphical installation (core operating
	       system, command line utilities and desktop environment)
	       matching that of the default LiveCD install. The minimal
	       installation profile should provide enough of a system to
	       bootstrap the rest of the installation through a remote
	       network repository. Automatic installation should be
	       a command-line only interface at this time.

        INS-2: The automatic installation infrastructure should provide
	       the capability of writing additional installation
	       profiles for those wishing to install a different selection
	       of software packages. However, a set of more formal
	       command-line or graphical utilities to do this is not a
	       desired for this release.

        INS-3: Both x86 and SPARC platforms should be supported by the
	       installer. However, a SPARC based LiveCD install option is
	       not desired at this time.

        INS-4: The minimum memory for both graphical and automated installations
	       should continue to be 512 MB.

        INS-5: The installer should provide accessible interfaces for those
	       with disabilities to successfully install OpenSolaris.

        INS-6: The installer infrastructure should allow the opportunity of
	       adding additional data to the install media, without it being
	       installed.

        INS-7: The installer should be able to detect if existing platforms
	       are installed on a system, along with providing some basic
	       partitioning tools to make the transition to installing
	       OpenSolaris easier.

        INS-8: The installer (both graphical and network based) should be
                    able to install additional software from a network repository
                    at install time
     

2.2 Package Management

        PKG-1: Provide infrastructure to allow users to set up
	       local mirrors of existing package repositories, along
	       with the ability to automatically synchronize changes
	       made to the master repository.

        PKG-2: Provide a graphical package management client, that allows
	       the user to install, un-install and update packages on their
	       system from a single network repository, or any additional
	       repositories of their choosing. The user should be easily
	       able to assess what updates are available for their system
	       (choosing to automatically update based on a set of defined
	       criteria), or freeze certain parts of their system that
	       they do not wish to update.

        PKG-3: Provide a non re-distributable network package repository
	       so that additional software, not already present in
	       pkg.opensolaris.org, can be installed by the user on
               confirmation of the license ie. RealPlayer, MP3
               multimedia plugin, Flash browser plugin, etc.

        PKG-4: The user should be able to update their system as fixes
	       become available. They should be notified if they are
	       attempting to upgrade their system to a different set of
	       packages ie. those packages on the 'development tree' that
	       will eventually be associated with a subsequent milestone
	       release.

        PKG-5: The user should be automatically notified, preferably
               graphically, when updates or new packages become available
	       (particularly those that are security related).

        PKG-6: Provide a series of command-line tools to allow 
	       developers to create and maintain their own set of
	       packages in a repository, and, additionally, give them 
               the opportunity of contributing them to a community
	       repository.

        PKG-7: Provide a graphical interface to manage the current list of
	       boot environments, allowing the user to upgrade their system
	       safely and switch to their new boot environment.

        PKG-8: Packages should be signed either during their creation, or
               addition to a repository to allow users to confirm they are
	       coming from a trusted authority.

        PKG-9: The package repository depot server should provide a full
	       search capability through a web browser, and allow users
	       to determine information (name, description, version,
	       contents, license etc) about a given package. Additionally,
	       they should be able to determine which packages are available
	       for a given milestone release and associated updates.

       PKG-10: Provide a way through MIME type association or otherwise, for
	       the user to be able to perform a single-click download and

       PKG-11: Provide a way through a series of package operations for users
	       to see what files within that package have changed between two
	       given versions (or set of versions).

       PKG-12: Provide a graphical way to find out which are the most popular
	       packages that users are installing, allowing the user to 
	       rate a package, and submit that rating to a global database.
     

2.3 Familiarization

        FAM-1: Provide at least 80% of the software currently available in the
	       spec-files-extra packaging initiative through IPS packages in
	       the 'contrib' repository.

        FAM-2: Provide at least 80% of the top 20 searches to pkg.opensolaris.org
	       as new software packages in the network package repository.

        FAM-3: The default boot splash should be a graphical progress
	       indicator, hiding some of the boot messages from the user.
	       The user should have the option, during boot, to dynamically
	       show the boot messages should they wish.

        FAM-4: The set of GNU developer utilities ie. autoconf, automake, aclocal,
	       m4, gcc, etc. should be updated to the most recent (known stable)
               version.
     

2.4 Hardware Support

        HDW-1: Provide network drivers (both wired and wireless) for at least 50%
	       of the 10 most popular hardware systems reported through the Device
               Detection utility out of the box, with the opportunity of installing
               other peripheral drivers from the network package repository.  It
	       is not necessary to install all possible software drivers by default,
	       though a convenient detection mechanism for which software drivers
               are available is desired.

        HDW-2: At least 50% of the currently support wireless drivers should support the
	       802.11n wireless protocol.
     

2.5 Desktop

        DSK-1: A modern updated GNOME desktop (preferrably 2.24) should be
	       available as the default desktop environment, including
	       the Firefox 3.0 web browser.

        DSK-2: The default desktop environment, GNOME, should have a consistent
	       and pleasing set up, as outlined in the desktop user interface
	       specification.

        DSK-3: A user should be able to automatically detect printers
	       connected directly through USB, or attached to their network.
	       For each printer, they should be able to configure their
	       printing options with a simplified graphical user interface,
	       along with monitoring any queues to that printer, and their
	       current print job.

        DSK-4: Systems (including laptops) upon connecting to an external
	       video display, should automatically probe the resolutions of
	       that external display and provide an easy interface (on the
	       panel, or through the menus) to set the display to that external
	       device.

        DSK-5: Provide a graphical interface to allow the user to regularly
	       back up their data using ZFS snapshots. The user should be able
	       browse their snapshots over time, and store them remotely if
	       desired.

        DSK-6: Provide a graphical interface, and underlying search indexing
	       engine, to allow the user to search documents, emails, contact
	       address, etc. The indexing engine should react to changes made
	       and re-index as necessary. The indexing engine should not consume
	       a significant amount of resources to achieve this.

        DSK-7: Provide KDE 4.1 as an alternative desktop environment for those wishing
	       to install it.

        DSK-8: Provide the set of 'known to work' XOrg graphics drivers to allow some
               SPARC systems to run a graphical desktop environment.
     

2.6 Network

        NET-1: Provide a graphical interface to connect and disconnect
               to both wired, and wireless networks automatically and manually.
	       The graphical interface should also support basic profile management
	       for preferred networks.
     

2.7 Storage

        STO-1: Provide infrastructure to turn any OpenSolaris host into a SCSI target
               that can be accessed over the network by initiator hosts ie. Project
	       COMSTAR.

        STO-2: Provide a common set of drivers for storage platforms, based on x64
                and SPARC.
     

2.8 Documentation

        DOC-1: Those manual pages that aren't available on the default install, should be
	       available in a network repository (split by re-distributabilty).
	       network repository, if they aren't

        DOC-2: Provide the user the opportunity of installing additional online
	       help for the applications they use, as and when they need them
               ie. provide a graphical interface to download online help bundles from
               the network package repository from within the application itself.

        DOC-3: Provide at least 10 tutorials or how-tos to outline some of the most
	       common tasks that users may want to perform with their system ie.
	       connecting to a network, starting a service, installing OpenSolaris in
	       VirtualBox, creating an IPS package, ... With above documentation, provide
	       infrastructure to allow users to document their own experiences as a series
	       of follow-up comments to the given document.
     

2.9 Power Management

        PWR-1: The user environment should support basic power management, both suspend
	       resume and CPU frequency scaling, for at least 3 x86 platforms. The user
               should additionally be notified when their battery is low, and offer to
               shutdown or suspend.  The system should also suspend in times of inactivity. 
     

2.10 Developer Stack

        DEV-1: Provide a typical developer stack for the standard C, C++, Java, C#,
	       Python, Ruby and Perl developer in the network package repository.

        DEV-2: Provide DTrace probes by default for each of these language runtimes to
	       allow developers to trace their application performance.

        DEV-3: Provide at least 2 of the most popular IDEs, along with the necessary
	       compilers or build infrastructure for their backend ie. Sun Studio,
	       Netbeans, Eclipse, gcc, ant, .. in the network package repository.

        DEV-4: Provide a set of the most popular source code management tools
	       eg. CVS, Subversion, Mercurial, Bazaar, and Git in the network
	       package repository.

        DEV-5: Ensure that the necessary developer tools and developer headers are
	       easily available for the typical open source developer, such that
	       compiling the list of 'known to work on OpenSolaris' tarballs has
	       the potential to work out of the box.

        DEV-6: Provide a plugin to Sun Studio/Netbeans to allow developers to easily
	       create DTrace probes for their application.

        DEV-7: Provide a plugin to Sun Studio/Netbeans to allow developers to easily
	       create (and send) binary packages to a network repository.
     

2.11 Web Stack

        WEB-1: Provide a set of the 10 most popular web development frameworks
	       eg. Rails, Django, in the network package repository.

        WEB-2: Provide a set of the 10 most popular content management frameworks
	       eg. Zope, Plone, Joomla!, Drupal, SilverStripe in the network
	       package repository.

        WEB-3: Provide a set of the 5 most popular wiki frameworks eg. TWiki, JSPWiki,
	       MediaWiki, Moin Moin in the network package repository.

        WEB-4: Provide a set of the 3 most popular blogging frameworks
	       eg. Wordpress, Movable Type, Roller in the network package repository.

        WEB-5: Provide a set of 4 of the most popular database frameworks used by
	       various web applications eg. MySQL, postgresql, sqlite in the network
	       repository.

        WEB-6: For at least 70% of the frameworks added, provide an initial set of
               DTrace probes to allow developers to profile their web applications
               in realtime.

        WEB-7: For at last 40% of the frameworks added, provide an optimized experience
	       on OpenSolaris eg. optimized binaries, SMF service support

        WEB-8: For each framework added to the network package repository, provide the
               shortest time to startup possible, starting them using a default
	       configuration, default database, and port so that the user can see the
	       results of their software addition immediately.
     

2.12 Distribution Construction

        CON-1: Provide a set of command-line utilities to construct a derivative
	       distribution (extrusion) based on a simple descriptive profile. The
               profile should be able to detail what sofware packages to install,
               initial users to set up, and provide the opportunity for a basic set 
	       of re-branding eg. boot splash, desktop themes, /etc/release, etc.

        CON-2: The distribution constructor should also be capable of producing
	       images for use on CDs, DVDs, and USB sticks.

        CON-3: Provide infrastructure to easily create virtual images for VirtualBox.
     

2.13 Trusted Environment

        TRS-1: Provide the ability to work in a fully secure and trusted environment
	       by installing set of related software packages from the network
	       repository. A non-trusted, but secure by default, environment will be
	       the default installation.
     

2.14 Virtualization

        VIR-1: Ensure that OpenSolaris OS is capable of running as guest in different
                    virtualization platforms of interest eg. xVM Server, VMWare, Amazon
                    EC2, Microsoft Hyper-V, VirtualBox

        VIR-2: Ensure that OpenSolaris OS can act as a host OS in xVM Server.