Programming and writing about it.

echo $RANDOM

Category: OpenSolaris

Update to the OpenSolaris 2008.11 final release

If you have been running any of the pre-release versions (RC1 or earlier) of OpenSolaris 2008.11, updating yourself to the final release is easy: (Please refer this link for more information)

$pfexec pkg image-update

I was running RC1 and so it d/led around 225 MBs of stuff and a new boot environment was created for me. You will get a new GRUB entry called opensolaris-1, which you can boot into on restart.

The desktop looks awesomely attractive:


OpenSolaris 2008.11 on VirtualBox

With the official release of OpenSolaris 2008.11, this post may be useful:

OpenSolaris 2008.11 release is out!

Grab the bits from

OpenSolaris 2008.11 RC 2 is out

OpenSolaris 2008.11 RC 2 is out. Its one step nearer to the final release. All details are in this post

ISO images are available from You can ofcourse go ahead and try it using your favorite Virtuallization software. I had put some instructions for trying out Open Solaris 2008.11 RC 1 with VirtualBox on Ubuntu:

Belenix Documentation linked my blog post

Updated: Belenix 0.7, Ubuntu 8.04 and Sun xVM Virtual Box 1.6

My blog post Installing Belenix 0.7 with VirtualBox on Ubuntu 7.04 has been linked from the Belenix official documentation, Yay!

Indiana Release Candidate available for testing

A test image for the 2008.05 release from Project Indiana is now available. The official announcement is here.

Download via a BitTorrent from

Here is a 5-page review, just in case you would want to read about it before you start the download.

Happy users: will probably look like this

Glynn Foster has a mockup. Things are still being worked out though, but the templates, mockup looks GOOD

Of course, Order is important and hence, augurs well for

Dependency hell

I first used the term Dependency hell while preparing the slides of my talk on Image Packaging System (IPS) (

A good couple of days later, I just wanted to verify whether the seemingly _correct_ term was _really_ correct or not. I wasn’t disappointed (

Though it encompasses lot of other things, but I was glad to see that I was not wrong!

Observations on the Image Packaging System


Project Indiana is an effort to create a single CD Open Solaris distribution and a top draw for its immense importance is its network centric package management system project- Image Packaging System (IPS). In this paper, the importance of this project – both technically and how it affects Open Solaris at large has been touched upon.

Keywords: Linux Distribution Model, Open Solaris, Open Source, Package Management


Package Management is the ability to install and upgrade software over the network in a seamlessly integrated fashion. We have ‘apt-get’ system in Debian/Ubuntu, and the ‘yum’ system in Redhat/Fedora which are examples of some package management systems in popular Linux distributions.

Package Management is said to be the single biggest advancement Linux has brought to the industry [1]. This again has been the single most important factor for the phenomenal growth of Linux in the operating system scene.


Making the software easy to install, upgrade and uninstall (not necessarily in that order) over the network has resulted in single CD (and even 1.2 PROJECT INDIANA & IMAGE PACKAGING SYSTEM (IPS)

Project Indiana [2] is working towards creating a binary distribution of an operating system built out of the Open Solaris source code. “Refashioning Solaris as a distro is the essence of Project Indiana—and package management is the key technology that will hold it all together” [1].

Project Indiana [2] is leaps forward in Open Solaris based distributions mainly because of its network centric package management system- Image Packaging System (IPS) [3], which is the first time in history of Solaris that a network-centric management system is made available to its users.


The image packaging system, written in Python [4] is an attempt to design and implement a software delivery system with interaction with a network repository as its primary design goal. It is a portable software packaging and delivery system intended to allow efficient, observable, and controllable transitions between known configurations of software content.


IPS is a network-oriented binary packaging system. Although it will have on-disk representations for versioned packages, the primary expected use for installation of software will be between an intelligent client and one or more relatively simple servers.

The project defines a client-server publication mechanism. The publication client offers up transactions on packages.

The server evaluates transactions from the publication client. Transactions that are deemed to be complete and/or safe by server are then made available to the retrieval client. The initial transport will be HTTP and HTTPS, protocols around which most sites have developed mature access policies.

The default package depot server is maintained at [6] and the client is configured to connect to this package depot server. You can set up your own IPS repositories as illustrated in [7] [9].

A simple usage scenario would be:
1. User X issues the appropriate commands to install package P from the client program.
2. The depot server checks if the package requested is present. If yes, then proceeds to install else reports appropriate message- package already installed or package not available.


The IPS currently exports the following interfaces via CLI [3]:
1. retrieval client CLI,
2. publication client CLI,
3. administrative and server CLIs,
4. client metadata representations,
5. server metadata representations,
6. retrieval and publication protocol operations,
7. dynamic language API to access packaging functions,
8. an on-disk package format,
9. package metadata conventions,
10. available package constituents (“actions”), and
11. package naming and versioning conventions


As of now, there is no well defined language API. However, the Python code base may be re-used to implement custom solutions.[8]

A scripting interface to IPS seems to be out of the question [5].


Use Case 1: Installation scenario when the package does not exist in the repository

amit@opensolaris-vbox:~# pkg install SUNWxmv
pkg: no package matching ‘SUNWxmv’ could be found in current catalog
suggest relaxing pattern, refreshing and/or examining catalogs
install failed: Unable to assemble image plan

Use Case 2: Installation scenario when the package exists in the repository

amit@opensolaris-vbox:~# pkg install SUNWxvm

SUNWxvmdom 0/2 0/385 0.00/6.52


The source code may be checked out from the repository at [10]. The project is still at its infancy and in need of more developers to fix the bugs, try out the features and improve the code base.


Winds of change are blowing over the Solaris world and Image Packaging System is going to be a definite player in shaping the future. Are the Open Solaris people trying to copy the whole model of the Linux world? No. [1]




Last Update: April 28, 2008

Package Naming in Indiana

If you have played around a bit with the Image Packaging System (IPS) in Indiana, you will observe that all packages are prefixed with a ‘SUNW’. Why is that?

I fired my query to the pkg-discuss list and Shawn Walker quickly told me the reason why: “

Because Sun’s official previous policy on package naming was that
creators of packages used their company stock ticker to ensure package
names were easily identified and unique.

Now, it is because the existing packages in Indiana, etc. are imported
from Solaris Express builds that still use the old naming convention.

It will go away eventually.

You may follow the discussion here

knew that Sun’s stock ticker was ‘JAVA’, then why ‘SUNW’? Google took me to this blog post on Jonathan’s blog titled “JAVA is everywhere

Now, I am relieved that I know why.