15. Scenario 2 – Unix

(This page uses style sheets.)

The Administration has Unix servers (“big Unix” – Solaris, HP/UX, AIX, OSF/1, etc). Uses PCs with client-server applications. Some Unix Workstations and X Terminals.

Migrating the PC desktops will be similar to Scenario 1 above. The Workstations and X terminals are likely to be running X based applications which should run without any problem on the new OSS desktops. The main problem here is migrating the servers.

Migrating from Unix to GNU/Linux is similar to porting from one version of Unix to another. Bearing in mind that the term Unix includes the AT&T, BSD and the OSF/1 code bases which are different implementations of the POSIX standard – as is GNU/Linux. The differences lie when a program uses features that are outside POSIX, typically things like system administration and performance enhancing features. Poorly written programs that have been written with little regard for POSIX will also have problems – writing portable programs is an art, “home grown'' programs are likely to need some work (elimination of all compiler warnings produced at the highest warning level is a good start). However the problems are likely to ones of detail rather than fundamental architectural ones. Unixes make use of open protocols such as TCP/IP and use common services such as DNS and DHCP.

Configuration is also likely to be different. However the system data is unlikely to be held in a proprietary format and so manipulating it to conform to GNU/Linux requirements should be fairly easy. This includes usernames and passwords although subtle differences may mean that simple transfer is not possible.

If source code is available then recompilation should allow the code to be ported. However there are some issues which will need to be addressed:

  1. There is no standard for the location of files and these maybe hard coded into programs (such as /usr/bin, /usr/local/bin or /opt/bin).

  2. There may be different values for system constants for instance the maximum number of files that can be open at any time.

  3. Subtle differences in the programming language, for instance ksh and pdksh. Different C compilers are more or less strict on syntax checking, therefore code which would be allowed on one machine might give an error on another.

The code could be unportable because of for instance:

gcc, the compiler on GNU/Linux, has options to be quite flexible in these circumstances.

  1. Each Unix may have different header files and libraries. They may also be in different locations. The locations and names can be changed automatically once they have been found. However if the library or header file provides different behaviour then manual intervention is needed. For instance:

The original code may use proprietary applications or libraries that are not available under GNU/Linux. It may have to be re-written to use what is available on GNU/Linux. This could be the case if special hardware interfaces are required, for instance a fax card. There is possibly much work to do in these circumstances.

  1. The makefiles which help build applications may need to be updated to reflect the differences mentioned above.

  2. Applications may make assumptions about specific subsystems such as printing and databases. This means for instance that SQL code may have to be re-written.

  3. Porting any code to a new hardware, compiler or operating system can show bugs in the program that were always there but just never showed themselves, for instance because memory is laid out differently, integers have different sizes or bytes are ordered differently.

The following references give more detail.

http://www.linuxhq.com/guides/LPG/node136.html

http://www1.ibm.com/servers/esdd/articles/porting_linux/index.html?t=gr,l=335,p=PortSolaris2Linux

http://www-106.ibm.com/developerworks/linux/library/l-solar/?open&t=grl,l=921,p=Sol-Lx

http://www-1.ibm.com/servers/eserver/zseries/library/techpapers/pdf/gm130115.pdf

http://www.unixporting.com/porting-guides.html