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 timezones.
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 desktops.
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 stunningly beautiful.
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.
However, both 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 of fun).
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 Desktop System.
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.
Sun's pkgadd, pkgrm, and pkginfo are very similar to Red Hat's rpm -i, 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 /usr/local/ 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. (http://www.cert.org/advisories/CA-2003-25.html and http://www.cert.org/advisories/CA-2003-24.html, respectively.)
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. (http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert/56860)
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 important.
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 releases.
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 installed.
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 source firewall.
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 Cisco's IOS.
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.
pass in quick on iprb1 proto tcp from any to any port = 22 flags S keep state
pass in quick on iprb1 proto tcp from any to any port = 80 flags S keep state
block in on iprb1
Here is a portion of a Netfilter configuration with similar rules:
$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 22 -j allowed
$IPTABLES -A tcp_packets -p TCP -s 0/0 --dport 80 -j allowed
$IPTABLES -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.
Enterprise applications 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.
Getting pre-compiled 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), blastwave.org (http://www.blastwave.org/), and Sun's own site for Solaris freeware http://wwws.sun.com/software/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 snap.
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.