Musing in the SUN – Set

Now with the EU approval coming the curtains have started coming down on the acquisition soap opera that has been going one for the past year or so. There are still a couple of regulatory approvals pending from Russia and China but the major hurdles have been crossed so that the assimilation process by Oracle can begin in earnest. This is good news for all SUN customers and users as the uncertainities end and roadmaps start to be delivered.

With this a decades long fantastic story of innovation and technical brilliance comes to an end, SUN as we have known it begins to set. Hopefully Oracle will keep the core essence alive and we will continue to see great developments happen on the most popular SUN platforms, Solaris, Java, Systems etc. Hopefully we will continue to see the opensource efforts continue and OpenSolaris community, source bases continuing to flourish.

It is both a time of relief and sadness for me seeing the acquisition process finally moving forward. I am proud to have been among the privileged denizens of the hallowed portals of this great organization. I worked for SUN for 4.5 yrs leaving it in the middle of 2008. Those years were probably the most exciting and fulfilling years of my career that I have had till date and will shine in my memories till the end of my days.

Leaving SUN has been one of the most excruciating decisions I was forced to take till date. It is akin to what an old Oak or Pipul tree might feel if it is transplanted. I was literally torn from my roots. I  still cherish the teams and the people I had worked with. The experience at the SUN workplace was so rewarding for me in a host of ways that I essentially regarded it as my second home. I will probably never get to experience such a fascinating workplace again: amazing people, exciting technology and projects, culture of innovation, work life flexibility, efficacy of people management, lack of hierarchy in perception and behavior of management, boundless opportunity to learn, freedom to define and create your own projects and work boundaries. These were some of the unparalleled qualities that I am yet to see anywhere else. My frustrating experience around lack of recognition of my BeleniX work (that provided the foundation for the OpenSolaris distro), towards the fag end of my SUN career was but a tiny fly in an otherwise spotless ointment.

Many will of course will have their own views and ideas on why SUN failed in spite of having some of the best technology talent in the industry. Since I have experienced the place first hand, let me put down a few pet views of my own:

• SUN has been and still continues to be the crucible of brilliant technology innovations but it lacked in business acumen and leadership. In this context I came across this thought-provoking article: http://blogs.harvardbusiness.org/anthony/2009/03/what_makes_a_company_the_world.html. I am hopeful of the future of the core SUN technologies under Oracle’s business acumen that SUN direly lacked.
• Pointless acquisitions.
• The OpenSolaris distro and the way some of the community matters have been handled. While the distro has been great for visibility and adoption I personally fail to see the justification of putting crucial time, money and effort into developing an opensource distro without a proper business model. Why would one put their business and top engineering resources into developing something without a revenue model ? Which enterprise customer will be willing to deploy a software from a development trunk into their data centers where they host business critical applications ? I am hopeful of Oracle here again. SUN customers would really like to lay their hands on Enterprise Solaris 11. Of course an opensource distro is needed so SUN should have followed the Fedora -> RHEL model. Empower the community and let it deal with distro things and focus your business resources in doing, ahem, business. There were efforts out of the community like BeleniX, SchilliX and others that could have fit the bill. Obviously BeleniX being my creation I am biased towards it. However BeleniX indeed provided the full foundation of OpenSolaris distro so it could have evolved, at that time, into the community distro variant like Fedora. However it was ignored after the benefits were extracted.

There are many obvious others I have skipped here. Anyway I am looking forward into the future with an expectation that Oracle can recover the market that Solaris and OpenSolaris lost in recent times. Solaris today is probably the most mature and technically capable OS out there in the wild and it deserves to be more widely adopted than it is today. While people only look at the blockbuster ZFS, Dtrace and Zones stuff, it is really full of compelling technologies that together make it a compelling platform: MDB/KMDB, Proctools, Truss, Apptrace, CTF, Resource Management, CIFS, Seamless Real Time extensions, Crossbow networking, I/O Multipathing, SMF and so on. Joerg Moellenkamp has an excellent brain dump of all these “other” features in his open book “Less Known Solaris Features“.

 

Building Packages on BeleniX #1

Several people have been asking me to detail the steps I use to build packages for BeleniX, so here is an overview of what needs to be done and what are the gotchas to be kept in mind.

BeleniX uses the Pkgbuild utility to build packages. Pkgbuild is similar to Rpmbuild and uses Spec files to store the build recipes. However instead of generating RPMs it generates SVR4 packages. Since we are actively considering a move to RPM from the venerable but somewhat dated SVR4, having spec files that need a little massaging is an advantage. Though this is still being discussed a bit. If you are not familiar with Spec files I’d recommend you to go through some of the excellent resources and howtos available on the net regarding writing Spec files and generating RPM packages. In addition Pkgbuild has some OpenSolaris – specific extensions that are documented in the Pkgbuild manual page.

However you should Not use the standard Pkgbuild utility from the original website. We have a slightly modified older version of Pkgbuild that supports the “Conflicts” directive among a few other tweaks. This is packaged via the BELpkgbuild package available in the BeleniX package repo.

If you have installed BeleniX 0.8 Beta1 using the install_belenix Network Installer mechanism, you will find that the installation lacks various headers, compilers and other files needed for development. To ease the task of getting a baseline development environment the package repo provides a group package called “devel” that pulls in all the necessary stuff. Consider this as the Debian “build-essential” thingy.

In BeleniX we primarily use the Gcc4 compiler since in the spirit of opensource we much prefer an opensource toolchain even though SUN Studio can provide some benefits over Gcc in terms of performance. In addition it is much easier to port and build third-party software using Gcc as compared to Studio since FOSS developers tend to use Gcc themselves. Since we are a resource-constrained small team we would prefer not to spend all our time chasing down compiler related build issues. The “devel” group package pulls in Gcc4 as well. However in addition to Gcc4 you will need Studio for certain things like building OpenSolaris from source. In that case I’d recommend you to download and install the latest tarball version of the SUN Studio compiler by visiting this page.

Next you will have to checkout the BeleniX spec files from the SVN repo and setup the initial Pkgbuild environment.

So preparatory steps are:

1. Install development packages:  pfexec spkg install devel
2. Install SUN Studio(optional)
3. Checkout spec files from BeleniX SVN: svn co https://belenix.svn.sourceforge.net/svnroot/belenix/trunk/spec_files belenix_specs
4. The above command may give an error due to an issue older locale packages on the beta1 release try setting the C locale explicitly: export LANG=C
5. Now create some directories that Pkgbuild expects. By default Pkgbuild expects a directory structure within the user’s home directory. The following directories need to be created: ~/packages/SPECS, ~/packages/SOURCES, ~/packages/BUILD, ~/packages/PKGS
6. Now copy the needed files into these directories:
   1. cp belenix_specs/base-specs/* ~/packages/SPECS
   2. cp belenix_specs/include/* ~/packages/SPECS
   3. cp belenix_specs/patches/* ~/packages/SOURCES
   4. cp belenix_specs/ext-sources/* ~/packages/SOURCES

Now you are ready to play around further. Typically Pkgbuild provides two utilities called pkgbuild (aka rpmbuild) and pkgtool a higher-level wrapper around pkgbuild that can automatically download sources files and execute all the pkgbuild steps to generate a package and also install it. You can read more about pkgtool and pkgbuild commands by executing them with the ‘–help’ option or read the online manual. i am not going to repeat the details here.

In order to correctly use pkgbuild however certain environment variables and PATH must be set. At the minimum CC and CXX variables must be set to point to the C and C++ compilers. To simplify things a wrapper script is provided that sets up things properly for SUN Studio or Gcc4. It can be found at belenix_spec/run-build assuming belenix_specs is where you have checked out the spec files. So to build a spec file using Gcc the incantation will look like this:  cd belenix_specs; sh run-build SFEfoo.spec gcc

The above invocation will automatically download the tarballs, apply patches, build, package and install the package. The SVR4 packages are kept under ~/packages/PKGS. During the build process the build output is sent to a log file having the package name. So for SFEfoo.spec the log file will be /tmp/SFEfoo.log. However pkgbuild first sends the logs to a temporary file and then appends those to SFEfoo.log. In order to monitor a running build the following simple script can be used:

#!/bin/sh
PID=`ps -ef | grep pkgb | grep " /bin/bash " | awk '{ print $2 }'`
LF=`pfiles ${PID} | grep "/tmp/pkgbuild.out" | head -1`
echo "********************"
tail -f ${LF}

This completes a brief intro into the initial preparatory steps. The next step is to actually look at a spec file and prepare a new one. There are various gotchas and things to keep in mind when doing that. I will briefly go through the stuff that one should do when preparing a new spec file on BeleniX in the next post. In the meantime one can look at existing spec files to check how things are done. Two suggested sample spec files to look at will be SFEpth.spec and SFEmrxvt.spec. Pth is the GNU portable threads library. It shows how to write a single spec file to build both 32Bit and 64Bit versions of a library. Mrxvt is a multi-tabbed terminal emulator. To look at typical cmake invocation that I have been using one can look at the KDE4 spec files in belenix_specs/kde4.

 

The loyal Dog on my PS3

I had got a PS3 a few months back with a multitude of objectives. Blu-Ray player for my planned Home Theater setup, general media center, watching Youtube on the big screen, Gaming of course and to hack on the Cell. For the last one piece fortunately I have the 80GB Fat/Phat model.

I had been holding out on the actual Linux installation and hacking since we experience power cuts and a power loss during a system update or Linux installation can leave me with an expensive brick that my wife will probably be prone to break on my head!

So I had to invest on a UPS. I already had an APC Back-UPS RS 1000 with additional battery backup for my PC. I decided to get a beefier Smart-UPS 1000UX with 100AH external batteries for my PC and hook up the PS3 to the Back-UPS. However the LCD TV is on line power and when power goes it goes dark naturally and I can’t switch off the PS3 without having a working display. I can hook the TV to the UPS but I do not want the UPS to be always powering the TV. So I whacked together a double-pole 2-way switch. I put 2 modular single-pole 2-way switches side by side and stuck 2 pvc pieces with superglue on either end. The common lines from these switches go to the TV. One set of poles connect to UPS power and one set to mains. Ordinarily the switch connects to mains. When power goes while PS3 is in use I can flick it to put the TV on UPS battery power. Admirably the Back-UPS can take a sudden load surge while on battery without tripping. The UPS has already saved me once.

Then I went about the process of formatting the PS3 for Linux and installing the kboot loader. Initially I decided to go with Ubuntu. Version 9.04 did not work with the latest 80GB console models so I tried 9.10. The GUI came up with that and it hanged trying to sync with NTP servers. After googling I decided to pull out the Ethernet cable from the PS3 while installing (I have a concealed CAT-5 cable running from PS3 in living room to a switch in another room). The installer proceeded beyond NTP server sync and hanged again. I decided to give up on Ubuntu and go with Yellow Dog Linux 6.2. I had avoided YDL initially since it is a large 3.4GB download. The experience with YDL was extremely smooth. It installed flawlessly and works quite fast. I have a happy puppy yapping on:

YDL 6.2 installation in progress

Post install configuration

Firefox and terminal running in E17

 

Impressive Fedora

I use Linux as well apart from my obsession with OpenSolaris. I have used several distros in the past and came to like Mandriva for general use. I was also once the biggest critic of Fedora. Having had bad experiences with FC3 and FC4 I cursed it and simply ignored it till recently when I started stealing spec file recipes and patches from FC 11,12 CVS repo for building packages on BeleniX

During the course of that usage I now stand to take back my earlier criticisms of Fedora. In fact I am thoroughly impressed with the quality of the work they are doing. The quality of the spec files and patches speak for themselves. Many of the conventions they follow align with how things are laid out on OpenSolaris as well. I am now going around and recommending Fedora 12 to anyone who is using Linux. The only issue that one will see is from a desktop use perspective. Out of the box Fedora has very few customizations and tweaks, so it takes a while of manual work to tune it to your liking.

 

BeleniX 0.8 Beta1 available via the Network Installer

After Belenix 0.8 Alpha which included exciting features such as the Google Widgets, Webkit, and KDE 4.2.4 — all built with GCC 4.4.0 in addition to Gnome 2.26, BeleniX 0.8 Beta1 is now available with improvements (bug fixes and functionality) to the KDE 4.3.1 desktop and other apps and new package additions. Several patches/fixes for various packages were taken from the Fedora Core 11 repository.

You need to use the Network Installer in order to install this 0.8 Beta1 Release. The Network Installer will not touch your current environment in any way. It creates a new Boot Environment and installs into that. Your current environment remains as the default one.

You can see the full announcement here: http://www.belenix.org/content/BeleniX-08-Beta1-available-Network-Installer

 

A CASCADE of Patches

I want to get Free-CAD working on BeleniX and have been going through the dependencies. One of them is OpenCASCADE that I started to build one week back. Since then it has been a tale of pain till finally once week later I do have a successful build.

Firstly the software is enormous having thousands of files. For eg. after a make install I find that it installs 15600+ header files! I started building it with GCC4.4.1 on BeleniX. Secondly their document mentions support for building with Sun Forte Compiler on Solaris 8 – primitive info. Obviously the combination of OpenSolaris platform + Mesa + Gcc 4.4.1 is untested. Once I started I came across some usual issues: The configure script assumes Sun Studio/Forte and has options not supported by Gcc, some headers assumed Sun Studio/Forte, needed proper declaration for bcopy, replace usage of ieee_handler with fex_set_handling  etc. After those I started coming across variable names like SS, CS that conflict with predefined macros for x86 register names on OpenSolaris. I have seen this on many occassions in KDE and other software in places.

However after manually patching about 15 files from 15 build failures, I started to wonder how many more. So to test I ran a simple command: find . -type f | xargs grep -w SS. Believe it or not there were hundreds of matches! From a hunch I started a round-robin search with all the possible register names and for the record the following are used: CS, SS, DS, GS, FS, ES, ESP, EIP in about 465 different files. The only option now was to whip up a simple shell script to do a global search and replace. The resulting generated patchset is huge and I am not keeping it as a patch! I have embedded the script in the pkgbuild spec file.

At the end of this all I found that the Makefile does not have 100% DESTDIR support in spite of it using the GNU autotools. So I had to patch Makefile.in and that resulted in a full build. After packaging I discovered a packaging issue and had to re-run make install. Even though the source tree is already built that resulted in another full build! Looks like broken Makefiles.

After an exasperating several days I do have a package. I had faced this usage of common variable names clashing in the namespace in several different software like for eg. in Celestia 1.6 that I built last week. It uses the obvious “sun” to represent Sol. This is however a predefined macro in Gcc on OpenSolaris. Granted that this can be worked around by using “-Usun”(Unsafe ?) in CFLAGS and OpenSolaris exposing register defines in headers by default looks like a bug, it is nevertheless a really, REALLY BAD IDEA to use obvious, common, short variable names in your software.

 

Ugly Beast errr Ritz on the road

Ugly Beast errr Ritz on the road

Here comes another weirdo from Maruti’s stable. It my not be entirely apparent in this picture but seen in person it appears as a cross between a car and an animal! From the back it is a frog’s rear with jutting wheels added, from the front it is a car reminiscent of the Hyundai i10 and from the side it looks as if Bluto has delivered a mighty kick to the rear making it concave.

It does have some goood aspects in terms of handling, mileage price etc. However a car needs to look like a car not a parody. It does not mean that Maruti does not make good-looking cars, but not this one. Hats off to Maruti for producing such an object on wheels and hats off the Indian consumer for actually buying it! I find it hard to believe that this is actually selling!

 

Ksysguard working on OpenSolaris

Ksysguard working on OpenSolaris

Anyone who might have tried the earlier KDE4.3 packages for BeleniX may have noticed that Ksysguard (CTRL+ESC or Kmenu -> Applications -> System -> System Monitor)  basically shows a blank slate. The process list is empty, CPU and Network stats are unavailable. The number of exposed sensors are too few.

I spent the last few days hacking on that component and got an initial working version that implements all the basic functionality for the OpenSolaris platform. There are still bugs to iron out and new sensors to add (using DTrace here can open up lots of possibilities). The current patch is here. The kdebase4-workspace package has been published into the BeleniX repository.

Ksysguard working on OpenSolaris

Common Monitors

Available Sensors

 

KDE 4.3.1 on BeleniX Screenshots

I am plugging in some obligatory screenshots of my Vbox VM running BeleniX 0.8 Alpha:

The KDM Login screen with Oxygen-Air theme

The KDE4 Splash screen

The KDE 4.3.1 desktop

The Kontact Addressbook application

The KBreakout Game

 

KDE 4.3.1 Available on BeleniX

The current 4.3.1 release of KDE is now available on BeleniX 0.8 Alpha. See this link for the details: http://www.belenix.org/content/KDE-431-now-available-BeleniX-08-Alpha. I have borrowed patches from the work of the KDE-Solaris team and Fedora Core 11 repository.

Currently 0.8 Alpha is only available via the network installer. We will be starting to work on building a LiveCD ISO soon. In addition 0.8 Alpha is based on OpenSolaris source drop for build 114. This will be updated to a more recent build. There are other things to look at like lofi bypass mode that should make it practical to use encrypted lofi on iSCSI targets – advantage being end-to-end encryption. Rework the ramdisk compression piece for the latest kernels and fix some oustanding corruption issue. Developer documentation for developing software on BeleniX, Hudson based bulk build setup for regular bulk builds on BeleniX repo, an installer written entirely in Python 2.6, A Gcc 4 build of Firefox with Profile Driven Optimization, Gcc build of OpenJDK on OpenSolaris, use RPM5 packaging with Smart Package Manager and lots of other stuff. One of the goals is use an Open Toolchain end-to-end. In that respect it is also important for us to look at a Gcc 4.2 build of the OpenSolaris kernel.

For me personally it is amazing to see how much BeleniX has progressed from the early days of a commandline-only ramdisk-only barebones kernel boot to single-user mode in an image assembled by hand. I manually went through and included individual files back in Sept 2005! Today some people may not realize it but BeleniX is a first-class OpenSolaris environment and a first-class KDE environment. People have been using it daily for months and it has been used in a multi-user build-server environment, like our build server in Moscow. Of course we face the problem of lack of developers, so developers are more than welcome!

In addition few people may know that the OpenSolaris distro from SUN owes it’s origin to BeleniX. Every technology that I developed for BeleniX during the 2.5 yrs prior to OpenSolaris-Distro coming out was used. In fact the first Beta release was based on BeleniX 0.4.1 with IPS and Caiman installer put in and KDE replaced by Gnome – I was part of the core team working on that!   See LiveCD Architecture Overview Diagram and LiveCD Features Timeline. Sadly there is not even a shred of information or documentation that alludes to this except for a sole reference in the OpenSolaris Bible.