Sun Microsystems has recently released Solaris 10. It is currently free, as in beer, and most of it is promised to be released under an OSI approved license in the second quarter of 2005. Most everyone reading this probably knows all of that. The release and subsequent open sourcing of Solaris 10 has caused quite an uproar in the Open Source community and the IT industry as a whole. Linux advocates have been fighting Solaris advocates on forums across the Internet. The zealotry and misrepresentation from both sides has been really quite impressive. However, I am a BSD user. I am not on either side and will do my best to allow neither zealotry nor misrepresentation into this review.
Please continue reading after you have stopped laughing.
All political issues aside, Solaris 10 is a very impressive OS. It has some features no other operating system can claim and some that are not necessarily new, but have been implemented in an excellent way. This is not to say it is perfect. There are definitely things I dislike and areas that seem quite unpolished.
One of those aforementioned unpolished areas is the installation routine. It can be assumed that Solaris will not be installed by a novice. Even so, the Solaris install is painful and brings with it memories of Windows 2000 installs of old. This is not because its difficult, it is not. The installation is simply unwieldy. My main complaints are the following:
You must partition, install a small base system and reboot to finish the install. I expect an OS to be installable without a reboot.
For the first section of the install there is a web browser in the background, but for unknown reasons there is no browser in the second section.
You have to switch CD's during the install, which is fine, but you can't just switch and walk away. You have to wait for it to read the CD and display another screen and then press next. There is probably a reason for this, but I just find it annoying.
Issues like these make the installation routine seem unfinished and just don't fit with the overall quality of the OS.
Upon booting Solaris for the first time, you are greeted by dtlogin. This is the default graphical login manager for Solaris and plainly has CDE roots. At this point, there is a drop-down menu in which you can choose to go back to a console login or choose which wm/dm to enter, both CDE and JDS3 are options. I am sure CDE has many great features and I know that some people love it. However, I am not one of them. JDS3 on the other hand is a nicely polished GNOME desktop. The theme and general feel is much improved over Sun's earlier versions. Nothing is very remarkable about JDS3, except network browsing. I have never seen any GNOME desktop do as well with windows and NIX network browsing.
There are things I dislike about JDS. As a media player, Sun has chosen the “Java Media Player.” This program has no redeeming factors. XMMS or Rhythmbox would be much better choices. They also tapped Mozilla to be the web browser, not Firefox. With FF gaining more and more attention, this choice makes very little sense to me. However, those are my only complaints about JDS3 and they are small ones.
Nobody is considering Solaris 10 because of JDS3 or its installation routine. They are looking at it because of new features like DTrace, Zones and the new Service Management Framework. Indeed, it has been quite awhile since we have seen a release of any OS with as many large features as Solaris 10.
DTrace
One of the main new features in Solaris 10 is DTrace, a dynamic instrumentation system. DTrace consists of a scripting language, named D (not to be confused with the fledgling D Programming Language), and loadable kernel modules named “providers.” When called upon, these “providers” track and report system information. DTrace has several features that separate it from other similar systems:
It is dynamic. DTrace has no effect on system performance when not in use. Only those providers that are needed by a particular command are loaded and used. This means if you want to collect data on the scheduler, DTrace will not be collecting data on the IO system as well. This greatly improves performance over those systems that collect a huge amount of unneeded data.
It can instrument both the kernel-level and user-level.
It is safe. DTrace will not allow you to damage the system through its use. Some may find the idea of anything being “totally safe” rather amusing. However, this appears to be true. Time will tell if it holds up, but for the moment I have no evidence to the contrary.
It is adaptable. DTrace really is more a scripting language then it is a tool like truss or top. This has its downside and upside. The disadvantage is that it is not a small thing to learn. Most will probably never use DTrace directly, but instead use programs written in D. There are already some of these and there will eventually be many more. The advantage to this is that its not limited like top or truss. Supposedly the test of a well-designed program is that people use it for things the author never thought of. DTrace passes this test with flying colors.
DTrace will inevitably be compared to similar systems. These include The Linux Trace Toolkit (LTT) and Dprobes. These systems may grow into something equivalent to DTrace, but at the moment they are not even close. LTT is not dynamic and has only around 45 points of instrumentation to avoid a large performance penalty. Comparing that to Dtrace:
# DTrace -l | wc -l
36110
Dprobes is much more advanced, but has problems as well. It is dynamic, but lacks some of the advanced features of the D language and is not safe. You can definitely bring down a machine with a badly written Dprobes script. It also supposedly performs poorly on multiple CPUs.
One interesting DTrace script I found is seeksize.d. This script tracks the offset value of seek requests to the discs, per process. I have never been able to see this information before and it is really quite interesting, although somewhat shocking. The script was written by Brendan Gregg, who has produced many DTrace scripts that review system information from shell use to socket statistics. [http://users.tpg.com.au/adsln4yb/dtrace.html]
seeksize.d in action
Zones
If you have used FreeBSD Jails, Solaris Zones are going to sound very familiar. They are based on the same basic concept. Both can be considered somewhat like a heavy-duty chroot. Each Zone or Jail is a virtual OS, complete with IP address, separate configuration and even a separate package DB (zones can also share a DB). Now, this may seem like exactly what UserModeLinux or Xen do, but it isn't. The difference is that all the Zones/Jails share one kernel.
In Xen or UML, the sub-machines are full OS's, kernel and all. They run on vm-like layer over the actual kernel. The advantage to this is security; it is very difficult to break out of a virtual server setup in this way. The disadvantage is speed; running all these different kernels has a large performance hit. This is why FreeBSD Jails were thought of in the first place and Sun has gone that direction with Zones.
It is theoretically possible to break out of a Jail or Zone. In fact, there have been security vulnerabilities in the past that allow processes to do just that. It is of course up to the System Administrator to balance these issues. Personally, I would rather be able to run a large number of Jails/Zones and take the minimal security risk.
Service Management Framework
SMF (The Service Management Framework) is Solaris 10's replacement for the aged sysV init. I have mixed feelings about SMF. It is definitely a step forward, but it adds a level of complexity that was not there before. The idea behind it is fairly simple and SMF can be logically split into several parts:
Startups scripts. These are very like the normal scripts you see in every UNIX implementation
XML manifests. This is where things get different. Every service has an XML file that holds information about the service. What other services does it depend on? What services does it not depend on, but are recommended? All these relationships and more are stored in the manifests.
svcs. The svcs command is one of the main interfaces to SMF. It can tell you what services are started, which are stopped and even what services failed to start and why. For example, if service A depends on service B and you have stopped service B, svcs might tell you that service A has failed because service B is stopped.
svcadm. This is the administrative tool for SMF. You can add, delete, stop and start services here.
init. The init systems works a bit differently on Solaris 10 because of all this. If a service fails to start or crashes, it will be restarted. Also, if you stop a service that another service depends on, that service will also be stopped. Likewise, if you start a service that depends on several others, they will all be started. Also, the dependency system allows init to start multiple services in parallel.
My concern about SMF is that its not as transparent as a system like rc.d on NetBSD/FreeBSD or even the old sysV init. It is still fairly easy to understand, but there is a level of “magic” that wasn't there before. Maybe my concerns are baseless? I don't know. It will be interesting to watch how users react to the new system.
Along with new features, there have been improvements made to the general OS, many having to do with speed. Solaris has been given the nickname “Slowlaris” in the past. With Solaris 10, Sun has worked hard to make that name no longer applicable.
