Sun has really shifted gears lately with regards to Solaris, SPARC, and x86. For many years, Sun seemed to relegate Solaris x86 to the status of red-headed stepchild, undeserving of attention, nurturing, and support. It furthered this perception when in January of 2002, Sun announced it would not release Solaris 9, the newest upcoming Solaris operating system, on the x86 platform. Solaris 9 was to be a (more lucrative) SPARC-only platform release.
NOTE: All tests were conducted by Tony Bourke. OSNews had no participation in the tests or its procedure.
However, Sun has since changed its tune by releasing Solaris 9 x86.
They are now pushing Solaris for the x86 platform, in an attempt to
regain market in the low and mid-level server market, as the
Intel/AMD systems have been decimating SPARC sales. While this move
might signal capitulation, or at least compromise, on the x86
question, they are now engaging in a full-fledged battle with Linux.
Sun’s new story is that Solaris x86 is a better, safer, and more
stable alternative to Linux. Sun has even gone so far as to offer a
a couple of top-of-the-line Intel-based x86 systems in single and
dual processor configurations. The systems currently include at no
extra cost licensed Solaris 9 x86 pre-installed (no-cost up until
January 4, 2004), with an option to purchase Red Hat Enterprise Linux
for an additional cost.
Here is a quote from Sun executive VP Jonathon Schwartz in an eWeek
article which sums up Sun’s position with regards to Linux and
Solaris (full article at
“Also, let me really clear about our Linux strategy. We
don’t have one. We don’t at all. We do not believe that Linux plays a
role on the server. Period. If you want to buy it, we will sell it to
you, but we believe that Solaris is a better alternative, that is
safer, more robust, higher quality and dramatically less expensive in
With this new push for
Solaris x86 I decided to take a fresh look with Sun’s latest, Solaris
9 x86 Platform Edition and pit it against Red Hat Linux 9 in a number
of categories, including features, security, and performance.
To start off, perhaps I should give a little
background on myself. I’ve been an avid Linux and Solaris user (on
x86 and SPARC, respectively) for about 8 years now. I’ve used Linux
since the 1.2.13 kernel (Slackware, back in the day), and Solaris
since 2.4. I’ve used them both extensively in my personal and
professional work, and I enjoy both of them for their various
strengths. I don’t consider myself biased toward one or the other, as
both have been very good to me over the years.
While I’ve dabbled with Linux on Alpha and SPARC,
I’ve primarily used it on the x86 platform. For Solaris, I’ve almost
exclusively used it on the SPARC platform, with the exception of a
brief stint with Solaris 2.6 x86 several years ago. I own several
x86 systems and one Sun Ultra 5, a SPARC-based workstation.
Note: For those of you not familiar with Solaris, this may help with
some versioning confusing (i.e. Solaris 2.6, Solaris 7).
Solaris 2.6, Sun decided to change how it named each Solaris version.
The next version was Solaris 2.7, but Sun called it simply “Solaris
7”. Solaris 8 is actually 2.8, and Solaris 9 is 2.9. They are
sometimes still referred to by the old nomenclature (i.e. 2.7),
especially when dealing with porting and software versioning.
bit confused? I’ve still got more! Solaris versions are also
sometimes referred to as SunOS, and different numbering schemes apply
there as well.. SunOS was the original operating system released by
Sun in 1981 and is based on BSD, where Solaris is based on SVR4 Unix
(System V). The last version of SunOS was 4.1.4, which would make
Solaris 2.0 (Solaris started at 2.0) SunOS 5.0. So Solaris 9 is also
known as Solaris 2.9 and also known as SunOS 5.9.
To evaluate these two venerable operating systems,
I used a VA Linux box I procured on eBay a year or so ago.
Intel Pentium IIIs at 600 MHz, 256 KB cache
MB PC133 ECC
9 GB Maxtor SCSI LVD
Controller Adaptec AIC-7896 Dual Channel
Logic GD 5480 2 MB RAM
It’s not the most
powerful box around, but it’s dual processor, plenty fast, and given
the cost cutting nature of the industry, it’s still a very common
system in terms of both power and configuration.
Red Hat Linux 9
I ran a standard install of Red Hat 9. Before
testing, I applied the updates available from Red Hat’s site, which
among others packages, updated glibc and the kernel, bringing the
system to 2.4.20-20.9smp and glibc 2.3.2-27.9.
mentat 2.4.20-20.9smp #1 SMP Mon Aug 18 11:32:15 EDT 2003 i686 i686
I used a standard
install of Solaris 9 x86 edition. Before testing, I installed the
9_x86_Recommended public patch cluster obtained from Sun’s download
page. Here is the uname
-a from the system:
mentat 5.9 Generic_112234-08 i86pc i386 i86pc
I did no specific
tweaking of either operating system, and except for patches, they are
both running as stock installations with off the shelf-style
A Note On My Choice Of Linux Distribution
If this article gets published with a comments
section, it will invariably be filled with comments such as “you
fool, you should have used Slackware/SuSE/Mandrake” and “your
choice in Linux distributions shows your obvious inclination towards
the drowning of cute kittens”. So I’m going to quickly address
my choice for Linux distributions.
I chose Red Hat 9 for the simple fact that it is a
very popular distribution, and is ubiquitous in terms of corporate
and personal deployment. Of course it is not the end-all be-all of
Linux distributions, but it’s both popular and effective, which makes
it appropriate as an evaluation platform.
Besides, most of what I evaluate has more to do
with Linux itself, and not the distribution. The only significant
effect Red Hat has on this evaluation is the specific version of the
kernel (2.4.20-20.9) and the use of RPMs (which some other Linux
distributions use as well).
I’m sure that despite this little interlude, I’ll still
receive those flame-trolling comments. To that I say, If you have a
problem with my choice in distribution, then feel free to run your
own evaluation. Also, your momma is ugly. Seriously. UG-LY.
Both systems offer both
graphical (X-based) and text-based installation options, and they are
both easy to follow and a snap to use for even green sysadmins.
Red Hat 9’s graphical installation is probably the easier of the two,
although not by much. The installation process is similar for both,
and involve the configuration of hardware, selecting of software
components, and configuring system settings such as networking and
I didn’t run into any problems installing either
operating system. Although I didn’t measure the length of time it
took to install for each (that would involve sitting in front of the
system with a stop watch, reacting to each prompt immediately, and
being very , very bored), my qualitative impression is that they both
took roughly the same amount of time to install.
The Red Hat 9 Installation comes on 5 CDs, but most
installs only need the first two or three. The last two are filled
with mainly source code RPMs. The Solaris 9 install comes on a total
of four CDs: One boot CD, two software CDs, and a language CD
containing, of all things, additional languages.
While both Solaris and
Red Hat 9 offer desktop environments, this evaluation is
concentrating on server features, so I won’t spend a lot of time on
With that said, Red Hat
wins, no contest.
Solaris 9 lets you
choose between a very ugly GNOME 2.0 implementation or the typically
bland CDE, while Red Hat offers both KDE and GNOME 2.0 which are both
beautifully and cleanly implemented. There are no Truetype fonts on
Solaris 9, so fonts often render ugly, and in some cases they look
like an Atari 2600 created them.
Solaris 9 ships with its default browser as – I’m not kidding – Netscape
4.78. It also defaults to “warn on cookie”, which on
Sun’s own page pops up 3 warnings, which is extremely annoying for
browsing. 4.78 fails to render many pages correctly. Red Hat
includes Galeon, Mozilla, and Konquerer, and by contrast are
While Red Hat 9 comes
with XFree86 4.3, Solaris runs Sun’s own X11 system called
OpenWindows. This can be problematic on Solaris with the multitude
of x86 video cards and many not being supported, although Sun offers
a porting kit to use XFree86 drivers with OpenWindows. Mileage on
that will vary greatly, of course.
recognized and correctly configured my Cirrus Logic card with its
pitiful 2MB VRAM and X came up without any problem. Using XFree86
for Solaris x86 is an option too, of course, but that would require
quite a bit of work.
While it’s possible
to get a Solaris desktop nice and pretty, it would take quite a bit
of work, especially in compile time (I don’t know if you’ve ever
tried compiling the full GNOME or KDE from scratch for a
less-than-common operating system, so I’ll just say it’s not my idea
Solaris as a desktop
just isn’t ready yet, and which is why Sun itself is initially using
Linux instead of Solaris x86 for it’s new desktop offering, the Java
Both Solaris and Red Hat Linux (some other Linux
distributions like Gentoo use other methods) use a package management
system for installation of system software, and often use them for
third-party software as well.
are very similar to Red Hat’s rpm
-e, and rpm
-qa. They’re both easy to use to install
software and creating Solaris packages and creating RPMs are also
both fairly easy and well documented.
My only complaint is where many Solaris packages
tend to put software: /opt.
I’m sure I’m treading into religious wars here, but I just prefer
for installed software and /usr
for system software. While that is itself a religious gripe, a real
gripe would be that Sun’s auto disk partitioning during installation
doesn’t make a separate /opt
file system and usually makes the root file (“/”)
system small, thus making for a crowded root file system.
Having used both extensively for a number of
years, functionally they are both fundamentally the same, and that
was certainly true for this evaluation. You’d have to pick something
fairly specific show as an advantage in one product over another,
which I’m sure someone will do.
There is one aspect of Solaris that I’m not fond
of at all, and that’s Sun’s slow response to release security patches
for some of the more serious vulnerabilities. Two potentially
remote-exploitable released recently were Sendmail and OpenSSH.
For the sendmail vulnerability, CERT and Bugtraq
both showed the vulnerability on September 18th.
Sendmail.org released a patch to fix the buffer overflow a day prior
and Red Hat had updated RPM that same day. Sun released and advisory
regarding this issue on the 19th, but as did not have a
public patch released untio September 29th.
There is a similar
story for the SSH vulnerability. One September 16th,
2003, the NetSys full-disclosure mailing list reported a potential
remote-exploitable vulnerability to gain root access via current
versions of SSH. The same day, OpenSSH released version 3.7p1 to
account for possible vulnerabilities, and almost immediately came
out with 3.7.1p1 to counter more possible exploits, and again with
3.7.1p2. Currently OpenSSH is on 3.7.1p2.
While Sun distributes
its own version of SSH, it’s based on OpenSSH and Sun admits their
versions are potentially vulnerable and only issued preliminary
patches on September 30th.
While Solaris systems
may or may not run sendmail, they almost all run SSH, as
administration by plain-text-passwords-over-the-network telnet is
tantamount to gross negligence. Given that both advisories are
potentially root-exploitable and a lack of any Sun patches,
administrators were compelled to compile and install OpenSSH 3.7.1p2,
as well as the sendmail.org’s latest patched version of sendmail.
Given the critical
nature of sendmail and the ultra-critical nature of SSH, Sun gets a
big fat F when it comes to security. Red Hat, and indeed most of the
other Linux distributions earn A’s for their quick and and speedy
patch releases to these and other issues.
Patch management has as much to do with security
as it does performance and bug-fixing, although security if the most
Red Hat has an automated patch-install system, and
releases bug-fixes and security-related RPMs on a regular basis (more
regular than Sun does, as noted above). It’s fairly easy to use and
is effective, especially with Red Hat’s quick deployment of security
However, I think Solaris has the superior
patch-management system. One nice aspect about the Solaris
patch-management scheme is that once a patch has been installed, it
can be backed out if required. The previous versions of the drivers,
libraries, and binaries replaced by the new patch are kept on the
system (in /var/sadm/).
This has saved me on more than one occasion. The command showrev
-p shows all the patches currently
Sun’s patch management system has been honed over
years of experience in dealing with all manner of bugs, and it shows
in the form of a comprehensive and effective patch implementation.
Now if Sun would just release security patches on time.
Both Linux and Solaris have freeware firewall
options available to them. Linux’s 2.4 through 2.6 kernel has the
open source GPL Netfilter, and Solaris has the option of the freeware
IP Filter (http://coombs.anu.edu.au/~avalon/).
Solaris 9 x86 also includes SunScreen 3.2, a Sun-branded non-open
You might remember IP Filter from a spat a few
years ago between the OpenBSD folks (especially Theo) and Darren
Reed, IP Filter’s author. While the disagreement was over the
licensing specifics of IP Filter (it’s still free), the argument got
quite nasty and OpenBSD abandoned IP Filter as its firewall and then
developed pf on their own. However, IP Filter is still actively
maintained by Darren and works great on Solaris systems, as well as
FreeBSD, NetBSD, HP-UX, and others (although not modern Linux).
They both offer typical filtering goodies, such as
blocking by port and protocol, stateful inspection, logging, and NAT
and IP masquerading (when several systems share a single external
broadband connection). They are both full-featured,
high-performance, and can be used on even the most active systems.
I’ve yet to encounter a situation where either has imposed any
noticeable performance penalty.
I prefer IP Filter to Netfilter, primarily for
ease-of-use. IP Filter uses a much more natural language type
configuration, where Netfilter concentrates on building chains which
can be quite cumbersome to build, and difficult to decipher. They’re
even more cryptic than the venerable ACL configuration syntax on
Here is part of a sample configuration for IP
Filter, allowing only port 22 (SSH) and port 80 (HTTP) inbound and
keeping stateful information on those connections.
in quick on iprb1 proto tcp from any to any port = 22 flags S keep
in quick on iprb1 proto tcp from any to any port = 80 flags S keep
in on iprb1
Here is a portion of a Netfilter configuration
with similar rules:
-A tcp_packets -p TCP -s 0/0 –dport 22 -j allowed
-A tcp_packets -p TCP -s 0/0 –dport 80 -j allowed
-P INPUT DROP
Still, they are both
very effective for protecting your systems, although I wish Linux
would take lead from IPFilter (and pf, and OpenBSD) and greatly
simplify it’s configuration style.
Even if the system is
just a host and not a router, its a good idea to add an additional
level of protection by running host-based firewalls.
Linux is omnipresent
to the point where just about every server application imaginable –
commercial, enterprise, open source – is ported to Linux or
written with Linux in mind. The obvious exception is of course
Microsoft; I don’t think we’ll be seeing SQL Server for Linux (or
Solaris for the matter) any time soon!
Linux is usually a
primary (or the primary) port of open source applications, so
virtually everything compiles without problem under Linux. If you’re
not the compile-from-source-type, Linux binaries are usually very
easy to find, in either RPM or tarball form.
like Oracle, PeopleSoft, Veritas, and others which once only ran on
commercial UNIXes, now all run on Linux as well.
The wide installed base
of Linux results in a great support community. If you’ve got a
problem with a commercial application or an open source release won’t
compile, the solution is usually just a Google search away. The same
can be said for Solaris x86, although to a much lesser extent as the
install base is nowhere near Linux.
In short, if it runs,
it usually runs on Linux.
Solaris is a slightly
different story. While just about any enterprise server application
runs on Solaris SPARC, very few of them run on Solaris x86. Oracle,
PeopleSoft and Veritas are just a few of the vendors that have little
or no Solaris x86 ports.
binaries of open-source applications for Solaris 9 x86 is more
problematic for Solaris x86 than for Linux. While some open source
projects will offer pre-compiled binaries at their download sites,
they tend to concentrate on Solaris SPARC, Linux, and sometimes
Windows (MySQL is an example). Most (at least, not any that I looked
at) do not offer Solaris x86 pre-compiled binaries.
On the bright site,
there are a couple of reliable reputable resources for pre-compiled
Solaris x86 binaries, including (http://www.sunfreeware.com),
and Sun’s own site for Solaris freeware
On many of those sites,
there’ll be versions for Solaris 7 or 8 x86, but not Solaris 9 (at
least not yet). For the most part, Solaris 7 and 8 x86 binaries will
work fine with Solaris 9. The only exception would be kernel
modules, such as pre-compiled packages of IP Filter.
In the enterprise
software industry, Linux x86 and Solaris SPARC are always first on
the list for Unix-type ports, while Solaris x86 is often snubbed (a
position which Sun has only itself to blame because of their relegating
x86 to the red-headed stepchild position for so long).
The lxrun utility does
allow Solaris x86 users to run Linux applications, but I’m not sure
how much I would trust this for critical applications. If it were a
background process, like a binary-only monitoring or backup agent, I
might be inclined to use it. If it’s to run IBM’s Java environment
(which works on Linux but not Solaris x86) for Tomcat, then I’d
probably just run Linux.
On the bright side of
Solaris x86 is the fact that compiling open-source packages is fairly
trouble-free, probably owing to the attention paid to making sure
ports work for its SPARC counterpart. Once I got GCC and gmake,
compiling the various applications used in this evaluation was a
However, the Solaris
x86 situation is changing, at least slightly. OpenOffice just
recently started to release Solaris x86 binaries in addition to the
SPARC binaries that were released, and Oracle has announced that
Oracle 10G will be available on Solaris x86.
Of course the irony is
that a proprietary operating system like Solaris is a great
platform to run open source applications. But if you’re looking to
run some proprietary/commercial applications, Solaris x86 really
isn’t much of an option at this time.
File System Performance
RedHat Linux typically uses the ext2 or ext3 file
systems for storage, while Solaris 9 x86 uses the Unix stalwart UFS.
Many people complain about the slowness of UFS, similar to the
complaints about BSD’s FFS until the advent of soft-updates. But,
since Solaris 7, Sun has provided a remedy of this UFS slowness by
the way of UFS logging which many sysadmins are surprised to learn
UFS with logging provides a remarkable speed boost
to file systems for some types of operations, so much so that I’m
surprised that Sun hasn’t just turned it on by default. You can run
UFS logging safely on all file systems, including /.
To enable UFS logging, just add logging to the option column (it’s
the last column) in /etc/vfstab and reboot. The file systems will
automatically come up with logging enabled. Of course be careful
when editing /etc/fstab,
as fudging it up can really ruin your day.
/dev/rdsk/c0t0d0s0 / ufs 1 no logging
/dev/rdsk/c0t0d0s6 /usr ufs 1 no logging
I ran a quick check to
see how UFS logging helped speed, so I did an untar
of the gcc-3.3.1.tar source code from ftp://www.gnu.org/gnu/gcc/
and then deleted the directory. The results are quite dramatic:
| Without UFS Logging | With UFS Logging
-xvf gcc-3.3.1.tar 4m 2s 0m 41s
-rf gcc-3.3.1 2m 53s 0m 4s
Going from 4 minutes to
40 seconds for the tar, and almost 3 minutes to just under 4 seconds
is quite a speedup. Of course tar
operations are by no means a comprehensive of I/O operations in a
production server environment, but you get the picture.
For Linux, the
difference between ext2 and ext3 was minimal, and both were faster
than Solaris (even with UFS with logging):
| ext2 | ext3
-xvf gcc-3.3.1.tar 0m 24s 0m 22s
-rf gcc-3.3.1 0m 2s 0m 2s
For a bit more of a CPU and I/O intensive
operation, I ran the benchmarking utility included with
mysql-4.0.15a, the sql-bench test suite.
Figure 1: Basic file system performance
What surprised me about this test is that when I
ran the tests for Linux in ext2 and ext3, the results were
essentially identical. The same was true with Solaris with and
without logging; the results were the same.
With that in mind, here are the results for Linux
ext3 versus Solaris with logging.
Figure 2: MySQL benchmarks
Figure 3: MySQL benchmarks continuted
The results are mixed,
with Solaris coming out on top for some operations (most notably the
insert operations), and Linux coming out on top for others.
Another test of CPU speed was a test of
compilation times for a number of popular open-source applications.
Again, compilation time can depend on a number of metrics, including
many that aren’t tied to system speed (such as the number of system
include files), so these benchmarks serve to satiate curiosity more
Figure 4: Compilation time
My first step was to use a common compiler, so I
chose GNU GCC’s latest, 3.3.1. For Solaris, I used the 2.95 GCC
build I obtained from Sun’s own freeware site
It compiled without any errors, and took 22 minutes and 26 seconds
For Linux, I used the RedHat’s pre-installed GCC
3.2.2 to compile GCC 3.3.1. This took quite a bit longer, clocking
in at 94 minutes, 10 seconds. Of course since it was 3.2.2 versus
2.95, it’s not a fair comparison and thus I didn’t include them on
I then compiled MySQL 4.0.15a (which was then used
for the MySQL benchmarks), Perl 5.8.1, OpenSSH 3.7.1p2, Apache
1.3.28, and PHP 4.3.3.
So, for the most part, Solaris seems to be the
faster operating system when compiling software, but again, this
isn’t really a critical metric.
Encryption operations are one way to put a system
through its paces, so I compiled OpenSSL 0.9.7c and used its speed
When I initially ran it on Solaris and Linux, the
results showed a huge disparity. Upon investigation, I found that
the default building process for Solaris compiled it with -m486,
optimized for the i486 processor, and the Linux default build
compiled with -mcpu=pentium,
or 586 flag. This system is a Pentium III system, so really the best
compilation would be for -march=i686
(Red Hat distributes an i686-optimized version of OpenSSL).
So I went back and re-compiled with the i686
optimization flag for both operations, and re-ran the tests.
Figure 5: DSA Operation rate
Figure 6: RSA operation rate
Linux held a very slight lead in all of the
results, which is interesting since the same exact hardware was used
As a side note, running each system with i486,
i586, and i686 optimizations showed that they make a very big
difference on both platforms, around 20% between the i486 and i686
Web performance was probably the biggest surprise
of this evaluation, as the results strongly favored one OS over the
other, and the OS I suspected would win didn’t.
One of the most critical performance metrics that
web servers must contend with is connections per second, also
referred to as operations per second. The opening of a new TCP
connection, handing it off to the web server, serving up the request,
closing it off, and all the little things that go in in between the
steps I just mentioned can be very CPU intensive.
Testing web performance normally entails racks and
racks of systems, using sophisticated software and analysis tools and
tests a variety of scenarios. I don’t have racks and racks of
systems, nor do I have the software necessary to test a dynamic range
However, I do have more computers than is good for
any one person to own, and I have freeware tool called http_load,
written by Jef Poskanzer. You can find this great little load
generator at http://www.acme.com.
I used a small 590 byte text file (small files are
best for testing ops/second, whereas large files are best for
testing throughput) and directed http_load on two different load
systems acting as load generators to retrieve it as fast as possible
from the test machine. One system is a Pentium III 1 GHz, and the other
is a AMD 2200+ system, both running Red Hat Linux 9.
I compiled a stock Apache 1.3.28 build with
modules enabled (mod.so) and loaded the PHP 4.3.3 module, although
the test file was not PHP-based. Compilation options and environment
were identical for both systems. The only change to the stock Apache
configuration file was kicking MaxClients up to 256 (the hard-coded
maximum without re-compiling).
I ran these operations for a period of 10 minutes,
and periodically checked the file with a web browser to ensure the
system was still serving up OK. I never had a problem retrieving the
file during the test of either system. The http_load utility showed
no errors for either run. Here are the results:
In this test, Linux was the clear winner showing
double the performance, with 2057 total operations per second to
Solaris’ 946. This result was the most surprising, as I had
hypothesized that Solaris would come out on top by a slight margin,
mostly because of Solaris’ renowned networking stack.
It would be interesting to see what effect
specific operating system tweaks would have on these tests, but that
would be a whole other article.
These tests shouldn’t be considered conclusive or
the final matter on the performance of both systems by any means,
especially considering the complicated nature of performance
assessment in general, and the limited equipment (and time) I had
with which to conduct the tests.
That said, I can make a few conclusions.
Performance was overall similar for most of the metrics tested,
perhaps with Linux in a very slight lead. However, with the web
operations test (arguably the most important and relevant), Linux is
a clear winner.
I didn’t have the opportunity (or means) to test
Java performance on both systems, for both Apache/Tomcat and pure
Java. Also, pitting IBM’s Java on Linux versus Sun’s Java on Solaris
would have made for a fascinating competition.
On the subject of hardware support, Linux wins.
Virtually any common device (such as IDE RAID controllers, server
motherboards, Fast/Gig Ethernet cards) has a production-quality open
source driver, usually distributed with the Linux distribution (and
works out of the box) or the vendor has compiled and made a driver
available as a module.
For more specialized hardware, vendors commonly
release their own Linux binary drivers in cases where open source
drivers may not be available, meaning Linux is taken very seriously
in the Enterprise.
That is not the case with Solaris x86. While I had
no problem installing on my system, there are many systems in which
Solaris x86 will not run because of one or more missing drivers.
This is just a symptom of Sun’s previous lack of interest in Solaris
x86 development, and a lack of open source community support that
gives Linux it’s wide driver base.
Before considering Solaris x86, make sure to take
a look at their HCL (Hardware Compatibility List available at
to see if your hardware will even support it.
Cost is always a consideration when evaluating any technology, and this is
certainly no exception.
Sun is, of course, a commercial and proprietary operating system. To use
it commercially, you have to pay $100 USD for a single processor,
$250 for a dual box, and $1,500 USD for a 4-way box. Educational and
evaluation use is free, as long as you register, and as long as it’s
only a single CPU box. Those prices only for licensing, however.
Support is an additional (and substantial) cost. In fact, it’s possible that installing Solaris x86 on my dual-processor box, even if I disabled one of the processors, violates the evaluation license that Sun offers Solaris x86. Oops.
Something to keep in mind is that Sun’s licensing is akin to the Oracle per-CPU licensing, they refer to the capacity of the system, not just how many processors are actually there. A
box capable of 2 processors with only one processor installed is
still a dual-processor box in their eyes, license-compliance wise).
distributions, of course, can range from free (if you download an ISO)
to even more than what Sun is asking for Solaris x86, such as
RedHat’s Enterprise Linux lists for $1499 for Standard Edition
and $2499 for Enterprise Edition. Both editions support up to 16
processors (Solaris x86 supports up to 4 CPUs).
pricing differences can vary greatly depending on your situation.
With all the commercial applications included with Solaris x86,
including Sun Screen firewall, Sun ONE Application Server, Volume
Manager, and Sun ONE Directory server, it certainly has a value
proposition. However, Linux has the advantage in flexibility in that
you can either pay for your system or not. Building out a grid
cluster of 100 machines can cost you zero dollars in licensing fees.
far as value is concerned, I have to say Linux is the clear winner,
simply because it’s free. You can pay for Linux and support if you
want, but if you’d rather use effort instead of cash (which many
companies that are strapped for cash are doing) then that’s an
option. With Linux, you don’t have to worry about licensing fees
associated with expanding your infrastructure.
Solaris x86 is now where Linux was 4 years ago: Great for
open-source applications and on a limited set of hardware, but
commercial enterprise applications are few and far between. If
you’re looking to run PHP, or Apache/Tomcat/Java (which comes
pre-installed), then Solaris x86 is a solid, stable platform. But so
is Linux. If you’re looking to run any type of commercial
applications, including several enterprise databases and even
commercial backup applications, Linux is the clear choice.
are several issues facing Solaris x86 adoption. Sun’s past history
of neglect, lack of commercial
applications, poor hardware support, and poor security support, all
contribute to Solaris x86’s lack of significant momentum towards
this evaluation, I am inclined to declare Linux the clear winner over
Solaris x86. Linux is simply better supported, shows double the web
performance, enjoys wider internal development in terms of hardware
and kernel, vastly wider application development, and is a better
value (since it’s, you know, free).
x86 isn’t that far off though. It is an impressive operating system
on its own right and if Sun stops spending time disparaging Linux
and open source in general, I can easily see Solaris x86 making a
broad and positive contribution to the market. The ball is in Sun’s