When to use Unix or Linux?

Unix-Linux expert Ken Milberg guides you through the increasingly complex task of choosing what operating system best suits your needs.

My IT consulting company is called Unix-Linux Solutions, so determining when to use one operating system (OS) or the other is my calling. I'm glad I can now recommend Linux as a production OS with confidence; but I don't recommend it for every project. So, how do I decide? In this tip, I'll bring forth common questions people ask when making this decision and explain which factors influence the choice.

What is your answer when a possible customer or client asks you what they should use? As the CIO, what would you do when your team suggests changing trains? I would suggest a series of questions, including:

  1. Why are you considering migrating off your existing platform?
  2. What is your application?
    1. How many users do you support?
    2. Does your application require high availability?
  3. What operating system are you currently using?
  4. Which OSes are your IT staff most knowledgeable about?
  5. As IT owners, what service-level agreements (SLAs) do you promise the business?

Why are we asking these questions? The primary reason is that both Unix and Linux are reasonable infrastructure solutions for most of today's applications. Five years ago, Linux was relegated to the data center to run domain name servers (DNS) or Web servers. Today, Fortune 500 companies have started to use Linux for their most mission-critical applications. Because you can't go wrong with either solution, we must look at these other factors.

Why are you considering migrating off your current platform? That is a most important question to ask when evaluating OS choices. Is your company unhappy with your current operating system's support, scalability, reliability or any number of other factors? Is it currently using Unix and looking to cut costs by moving toward open source? After the why is answered, we can address the other issues.

It's possible that after addressing the reasons for migrating, we learn that the current platform is actually the best solution. It's possible that the you may just need more scalability or a better distribution.

For example, a small business is running SLES 10 on 500 standalone PC servers that have taken up the majority of a its small data center. At the same time, the business has had many problems managing its server farm, from patch management to unscheduled outages. Costs have also risen due to software licensing and energy/cooling costs. Rather than migrate to a more reliable OS, perhaps the problem is hardware related. In a situation like this, you might want to consider an IBM System p. Using this architecture, you may be able to consolidate your entire farm to several IBM System p servers using Linux partitions and a technology calledPowerVM x86. This technology actually allows one to run Linux x86 applications out of the box on a powerful RISC IBM System p, without a recompile or port. This solution might enable you to solve problems without porting to a different OS.

On the other hand, if you are running enterprise resource planning applications on older Sun servers and have the same concerns discussed above, it may behoove you to consider moving to a different flavor of Unix entirely – AIX (IBM's Unix) rather than Solaris or Linux. This is also more about hardware than OSes. Historically, IBM has always been more about scaling vertically than Sun, and for a business that wants to reduce its footprint in the data center, cut costs, and increase reliability and performance, moving to AIX on a System p rather than Linux might be the answer. I only suggest this because AIX is more tightly integrated with System p hardware than Linux, it performs slightly better on that platform and is a more mature product.

On the other hand, moving to an IBM System p is not for everyone. The total cost of acquisition (TCQ) for System p is usually much higher than for most systems, and a company needs to have a large enough budget to even think about such a migration, particularly if it is new to this architecture.

Let's consider a different scenario: As a Sun customer, you want to move away from your Solaris server farm because its systems are extremely old, perform poorly and the staff is already familiar with Linux. You are not currently using IBM System p for AIX, nor are you running extremely large databases that require the horsepower of System p. You may be a great candidate to move off of the SPARC environment to commodity-based Linux servers – perhaps blade servers, which can also help reduce the data center footprint and cut energy costs.

What about some of the technical factors you may need to look at when evaluating Unix or Linux? Consider the following:

  • Endianness. The first thing that should come to mind is endian issues. Endianness is a term that defines how a data element and its bytes are stored in memory. It is dictated exclusively by the CPU (hardware) architecture of the system, not the OS. For example, if one is running Linux on SPARC or IBM RISC hardware, that usually means that the code compiled for the SPARC or IBM System p will not run on an x86 PC. That is because both SPARC and System p hardware are big endian (using forward byte ordering) while x86 is little endian. So if the goal is to port an application running Solaris on SPARC to Linux on Intel, byte ordering can be a big problem. Of course, things will be much simpler if the customer is running Solaris on Intel, though it will still require a migration of some sort.
  • Kernel. Let's discuss the kernel for a minute. The commercial Unix vendors (HP, Sun and IBM) release their kernel in binary form – they are not open source (though it is worth noting that Sun has released OpenSolaris, so of the "big three," it's clearly the most open Unix). Because of the approach that Unix vendors use, systems administrators will need to wait for vendor updates prior to patching their systems.

    The advantage to this is that IT managers can feel more secure that a large amount of regression testing has taken place to remove bugs from the system. The other side of the coin is that with Linux, patches are sometimes released instantaneously because the kernel is open source. Some folks are even capable of compiling the kernel themselves, though I don't recommend this unless you really know what you're doing. This is a good segue into the next topic.

  • Support. Another important difference is philosophy. Linux system administrators are much more used to doing things themselves, because they usually don't have the level of hardware or OS vendor support that the Unix vendors provide. Some companies like the luxury of having that type of support. Others are fine without it. Some of the Linux distribution folks have recognized this issue and have already started providing Linux with similar support models. Even database vendors, such as Oracle, have thrown themselves into the mix. Oracle supports a product called Unbreakable Linux (similar to the Centos distribution, it's Red Hat behind the scenes -- without the colored hat) and even has its own model in place supplanting Red Hat support for those who want to use Oracle directly. Without question, the support available for Linux today is rapidly increasing, particularly now that Linux is in the enterprise.

    In conclusion, I can't stress enough the importance of asking the right questions. When to use Unix or Linux is a question that definitely has a different answer today than two or three years ago.

Dig Deeper on Linux servers