Security, cost-savings, performance and innovation are the primary reasons to move to Linux, says Novell Linux...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
developer Darren R. Davis, stating what is, to him, the obvious. Rather than dillydallying with that question, he'd rather help IT shops and developers get moving to Linux.
Davis explains how to port Unix and Windows applications to Linux and how to make those Linux apps support multiple distributions in this interview. We caught up with Davis just after his LinuxWorld San Francisco 2005 workshop, "Porting and migrating software to Linux." Davis offered some nuggets from that presentation in this Q&A.
What would you say are the major issues in porting apps from Unix to Linux?
Darren Davis: Unix applications are quite easily moved to Linux, and I would have to say that most applications that were on UNIX are now on Linux. There are also many excellent resources on how to port from UNIX to Linux including the IBM Press Book on Building Applications with the Linux Standard Base. The only time UNIX applications may become problematic is when they need a collection of third party libraries.
Are there more challenges in porting apps from Windows to Linux?
Davis: Windows applications tend to be more problematic. For standard Win32 applications, the only solution tends to be WINE.
If the developer is willing to spend some time in making their application have an abstraction layer, he can make the applications portable, but that takes a fair amount of work.
This problem is being worked on in both the open source and commercial communities. There are open source solutions, like what the Mozilla Organization is doing in providing a developer platform, and commercial solutions like Troll Tech. But, if a developer is deeply immersed in the Microsoft MSDN world, then he is most likely going to need to do a lot of work. For .Net applications, Mono is quickly becoming a good alternative, but more work is going to be needed there as well.
In your session, you discussed tools and languages used in porting. What are some of them?
Davis: For typical developers who would use a GUI, Eclipse is an excellent tool. Eclipse has support for C and C++. Other GUI tools that support C and C++ are and Anjuta. NetBeans is a GUI tool that supports Java Development environment.The most commonly used scripting languages are Python, a general purpose interpreted, interactive, object-oriented language; Perl, an extensively used general purpose scripting language; and PHP, a Web scripting language.
There are many tools available for debugging and profiling available in Linux from open source solutions to commercial solutions from companies like Intel.
What is the most problematic issue in having Linux apps support multiple distributions or operating systems?
Davis: The primary problematic area is C++ application development or porting. The issue has been that there was no clear ABI defined for the C++ language, and the GNU Compiler team had changed the ABI from release to release. It wasn't until LSB 2.0 ( Linux Standard Base ) that this area was being standardized. Now that LSB 3.0 has been released, there is hope that this will no longer be an issue.
For the most part C applications are easily ported between Unix and Linux platforms. Mono and Java also make it very easy to develop portable applications.
What are other problem areas?
Davis: The next problematic area is in the area of desktop applications. For the most part creating C or C++ desktop applications is straightforward, but I often get asked which desktop environment to target; and I'd say either KDE or GNOME. Currently, Novell supports both of these desktop environments and so there isn't a clear preference of one over the other. The Freedesktop.org group is working to resolve these interoperability issues, but it isn't always clear.
Other than these two issues, I would say choosing a packaging or distribution format is the next unclear point. The LSB does state that RPM is the standard format, and that is what Novell/SUSE and Red Hat support, but developers often have applications that are supported on various Unix systems as well. They prefer to not distribute in RPM format and many applications want to have their own installer like Oracle for example.
This also brings up the side issue of supporting systems management in applications. A good possibility is something like Autopackage, but that is more appropriate for desktop applications. RPM is still the best method for server applications since administrators can use various methods to install or uninstall those applications in a consistent way either locally or remotely. Applications should also conform to the FHS as required by the LSB.
What are some ways to deal with these issues?
Davis: Use the open standards like LSB and Freedesktop.org. Choose new language environments such as Java, Mono or Python for new applications.
If IT managers were aware of things like the LSB, they could demand that the applications they buy adhere to the LSB. It is there to make their lives easier. All significant Linux distributions are now supporting the LSB.
Also, there are also systems management standards such as WBEM (Web-based enterprise management) with open source implementations like OpenWBEM.