I am (was) a Solaris admin through to about nine years ago, from v2.5 through v8. I've had a little exposure to Solaris 9, and almost none to 10.
My reasons for avoiding Solaris:
Hardware support is not nearly as good as many Linux or Windows operating systems. It is improving.
You can run Solaris for free, but you can't get updates for free. Not even security updates. Not even 0-day exploits. You have to buy a support plan, per system, which can be expensive. This means that the way to get updates is to wait for the next "U" release, and upgrade at that point.
OpenSolaris is too bleeding edge for me. It changes too often, and the releases wander too close to unstable or unreliable for my needs.
Between Solaris and OpenSolaris, Sun has managed to totally miss the happy medium between "welcome to 2004" and "I'm so new and shiny I don't really work 100%!"
I used to be willing to use Solaris more before the Blastwave project imploded. Through there I could get newer tools that fit more with the Linux way of doing things (which is where I spend 95% of my professional time) with a relatively easy online way of managing the tools and updates. Once Blastwave and CSW settle down, I'll look at both remnants and decide if it is worth putting time and effort into either of them again. Really, the loss of Blastwave as a trustworthy source of tools was a huge blow to Solaris' viability in my circles.
But the number one reason for me is that right now I don't need to do anything that requires Solaris.
The /dev/rdsk devices are character devices. These are used for low level manipulation of the corresponding slice's data a character at a time. The /dev/dsk devices are block devices. These are used for accessing the slice's data in blocks in a structured manner through a filesystem.
ZFS works on storage pools. Storage pools are built using virtual devices (vdevs). Vdevs can be built from disks,partitions or block devices.
Best Answer
This question is not specific to Solaris.
When you install a shared library (or a piece of software that provides a shared library), you get three files, they all look similar but have different purposes.
libfoo.so.1.0.0
‒ This is the (regular) data file. It contains the library itself. You could have multiple of these, with different versions. Inside this file, there is an ELF field called SONAME, which is set tolibfoo.so.1
. On Linux, runobjdump -p libfoo.so.1.0.0 | grep SONAME
to find out.libfoo.so
→libfoo.so.1.0.0
‒ This is a symlink which is used when compiling software against libfoo. When you specify-lfoo
to the linker, it will look for exactlylibfoo.so
. Normally,libfoo.so
is never a regular file, it is always a symlink which points to the version of libfoo which you want to use for linking. In a complex build environment, you could have multiple versions of the library, and you use this symlink to choose, against which version you want to link.libfoo.so.1
→libfoo.so.1.0.0
‒ This is also a symlink, which is used when you run binaries that need your library. Remember the SONAME field I mentioned? When you link a binary against libfoo, the binary will record the SONAME of the library and will use it at runtime.This setup allows you to have multiple versions of the same library installed alongside each other. Different binaries may require different versions of the library, and each binary will find the right version of the library. Usually, the SONAME of the library is changed by the upstream when there is a backward-incompatible API change. All the old binaries still use the old API, while newly linked binaries use the new one.
Some packaging projects, Debian would be one example, use different package names for different versions of a library. This allows you to install and uninstall each version of the shared library independently.
There are some edge cases. For example, dependencies between shared libraries can lead to two versions being pulled in at the same time. Consider:
Imagine that we install a new version of libbaz and recompile foo. Now we have:
At runtime, foo will load
libbaz.so.2
andlibbar.so.1
, andlibbar.so.1
will loadlibbaz.so.1
. See the problem? Two versions of libbaz are loaded at the same time. I'm not entirely sure what's the exact consequence in terms of the layout of the code in memory, but in practice this results in crashes.