Solaris Distributions

There are a number of Solaris package distributions available. Choosing the right distribution for your needs is essential as they focus on different aspects. These include things like the package selection policy, how they cope with 64 bits and quality control. I am participating in the OpenCSW project, so please judge my opinions accordingly. :-)

What distributions are compared?

The following distributions are taken into account (in alphabetical order):

Supported OS versions

  • Blastwave: Solaris 8, 9, 10 (packages may be provided for Solaris 10 only)
  • OpenCSW: Solaris 9, 10 (all packages must be available for all releases)
  • SpecFileExtra: Solaris 10
  • Sunfreeware: Solaris 2.5-10 (packages may be provided for a subset only)

64 Bit

Generally Solaris is able to run 32 bit binaries, regardless if you are runnning a 32 bit or 64 bit kernel, whereas 64 bit binaries require a 64 bit kernel. For Sparc 64 bit started with Solaris 7 with the sparcv9 ISA which was introduced with the first UltraSparc CPU. For the x86 architecture 64 bit was introduced much later with Solaris 10 on amd64.

  • Reference: Solaris Application Programming

Performance

The important thing to note about 64 bit is that it does not always perform better than 32 bit. The main reason for this is that 8 bytes need to be moved instead of 4 on memory operations, but when your application only requires 32 bit it takes a bit longer. To further complicate things some applications use different data-formats for their diskfiles between 32 and 64 bit versions making it impossible to simply switch back-and-forth. There are of course cases where 64 bit is better or even makes things possible. These cases are:

  • Need to access more than 2 GB of memory
  • Need to use more than 256 file descriptors (this includes sockets!)
  • Manipulate data larger than 32 bit and application is written to facilitate 64 bit variables
  • Need to access kernel data on a 64 bit kernel
  • Needs to operate on 64 bit applications (like compilers)

Selecting 32/64 bit

When both 32 bit and 64 bit versions of a software are offered there are multiple methods to select which version to run.

(A) Explicit: Here the user is responsible for selecting the appropriate version. Usually the 32 bit version resides in <disthome>/bin/ whereas the 64 bit version is located in <distname>/bin/(sparcv9|amd64)/.
(B) Manual: Instead of selecting the version explicitly by path here it is delegated to a central mechanism for switching binaries. This allows calling the application always under the same path but keeping the selection on package updates.
(C) Automatic: There is a mechanism in Solaris called 'isaexec' which automatically selects the "best" binary available for the running kernel.

  • Blastwave uses mostly (C) and (A) for applications with different on-disk formats for 32/64 bit. xxx packages (xxx%) are available as 64 bit.
  • OpenCSW uses (C) where possible and transitions from (A) to (B) (see [1] Alternatives) for different on-disk formats. Libraries are always offered in 64 bit. xxx packages (xxx%) are avaibale as 64 bit.
  • SpecFileExtra (pkgsrc): TBD, grep -l sparcv9 * | wc -l = 51
  • Sunfreeware uses (C). 64 bit packages are only offered when absolutely necessary. The only 64 bit packages are SFWgcc, SFWlsof, …(TBD)

Multiple library versions on upgrades

Most apps nowadays use a lot of libraries which are often distributed seperately. As development progresses the API of the libraries may change and a different version needs to be added in addition to the existing one. Existing applications are unable to use the newer version with the different API, so the old version needs to stay until all applications depending on it are recompiled. ([1] dump -Lv SONAME, $ISALIST)

  • Blastwave has a split-strategy where some library packages will include both the old- and new versions whereas others are updated when all dependencies have been recompiled (e.g. libtool).
  • OpenCSW includes the old versions of the libraries until all dependencies have been recompiled, than the old shared library is removed from the library. ([1] GAR integration of version modulations)
  • SFE doesn't handle it as no binary packages are distributed.
  • Sunfreeware only offers consistent versions of a library and will not update the library under the same name to an incompatible version. This leads to special-cases (svn -> neon).

Integration of startup scripts

Solaris 8 and 9 as a classical System V Unix systems have runlevel-control-scripts in /etc/rc.X/ for service startup and shutdown. Solaris 10 introduced a new mechanism to deal with the shortcomings of the classical rc-scripts called "system management facility" (SMF) which allows parallel execution, specific dependencies, enhanced logging and many other useful features.

  • Blastwave uses package-specific scripts and manifests for the packages
  • OpenCSW uses uniform class action scripts to allow a consistent integration of rc-scripts and smf-manifests
  • SFE: TBD
  • Sunfreeware does not offer rc-scripts or smf-manifests

Library dependencies

Applications depend on libraries, which themselves depend on other libraries. This can lead to huge dependency-trees for relatively simple applications. Depending only on project-delivered libraries allows a consistent set of packages across multiple Solaris versions and architectures but at the same time bloats the system as some libraries may also be shipped in a current version of Solaris. System-shippes libraries may or may not be updated regularly from Sun, so currentness is also probably be better on distribution-shipped libraries as opposed to distribution-shipped. Additionally, some libraries may be compiled a large optional set of libraries which may be useful in specific environments, but further increase the number of dependencies which may in other environments are at least superflous or even make the installation more vulnerable to attacks.

  • Blastwave ships their own libraries and compiles full-featured.
  • OpenCSW also ships their own libraries, but offers different alternatives for key-libraries with different levels of features to both offer full-featuredness and minimal dependencies on user requirements.
  • SFE is tailored specifically to the libraries shipped with Solaris allowing minimal dependencies and a smooth integration into the system. As SFE is only supported for OpenSolaris transitioning between OS releases is not an issue.
  • Sunfreeware offers different versions for different Solaris releases, sometimes built against their own libraries, sometimes against Solaris libraries. This requires careful planning on system updates.

Quality assurance

To maintain a high level of quality there needs to be quality checking of released packages, but also a method of user feedback in case of errors like a forum or bugtracker.

  • Blastwave has a webforum
  • OpenCSW has a bugtracker ([1]) and a mailing list ([2])
  • SFE has a bugtracker, mailing list and irc channel ([1] SF)
  • Sunfreeware has an email address where errors can be reported

Ease of use

Package installation with system-shipped tools is cumbersome, as it only allows installation of one package at a time. When a package depends on anotherone the dependency must be resolved by hand and the dependent package installed first. To bring the efficiency of an "apt-get" to Solaris there was 'pkg-get' developed. It is written in ksh and runs on any system. It allows downloading, verification, installation and automatic dependency resolution of packages. Later a tool 'pkgutil' with similar functionality was developed. As it is written in Perl a Solaris equipped with it is required, which is true starting with Solaris 8. Both tools allow downloading, installation and upgrades with dependency resolution, but differ in more advanced features. See [1] for details.

  • Blastwave uses a forked version of pkgutil as there are cyclic dependencies in the catalog which the original pkgutil does not allow. pkg-get is not used at Blastwave because the license does not allow redistribution of altered versions.
  • OpenCSW uses pkgutil and pkg-get.
  • SFE: SysV packages??
  • Sunfreeware can be used with pkg-get but has no dependency resolution, just the download and installation of single packages can be automated.

Openness

  • Blastwave: Free distribution of binary packages. The build recipes were published in the past, but are no longer accessible.
  • OpenCSW: Free distribution of binary packages and publishing of build recipes, open build system "GAR"
  • SFE: No binary packages are published, build recipes are accessible.
  • SunFreeware: Free distribution of binary packages. The build reciped are not accessible.

Financing

  • Blastwave is a privately held company. Money can be donated to the project and is managed by the company.
  • OpenCSW is an association by Swiss law. It is financed by non-money donations (hardware, bandwith) of its members.
  • SFE is a volunteer project from a Sun employee hosted at SourceFourge. It may not need funding (Donations?)
  • SunFreeware is a privately held company which gets funding from Sun.

Activity

(total number of packages)
- SFW: approx. 500
- SFE: approx. 1000
- BW / OpenCSW: approx 2000
(released packages per month)

Reachability

- BW: (Stats from Dennis' Mail)
- OpenCSW: ??? due to mirrors, link to ibiblio stats
- SFW: Stats??
- SFE: SF svn checkouts

The discussion of the above topics makes it hopefully easier to select a distribution which suits your needs best.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License