One of IT consultant Robert Hubbard's corporate clients runs Red Hat Linux. Linux was chosen because the company's programmers need flexibility to dabble with source code and create custom programs. Big trouble ensued, however, when a remote programmer flexed too much. In this instance, Hubbard thinks that Linux was the wrong choice.
In March, Hubbard was involved in fixing a problem -- the one mentioned above and detailed below -- when he read SearchEnterpriseLinux.com's "Wrong Choice" series of articles. Hubbard said his client had problems, like poor scalability and inadequate vendor support, with Linux in enterprise environments. He noted that his consulting firm, Pasadena, Calif.-based Epic Microsystems Global Inc., is not a Microsoft partner, and he has worked with Unix and Linux systems for years.
In March, Hubbard visited the Southern California headquarters of a client, a large company in a vertical market. He noticed a high-pitched sound coming from a server running Red Hat Linux 7.1. "A change the programmer made caused the RAID controller to go into alert, and the two external drives are no longer mirroring," he said.
Upon further examination, Hubbard discovered that the external tape drive he'd installed on the server was no longer visible to the Linux operating system. "The client is now in a highly critical 'panic state,' with no means to backup or restore," he said. Fortunately, the second drive on the server was still visible.
Obviously, Hubbard quickly got down to troubleshooting. It turned out that a contract programmer had just made adjustments to one of the company's Linux-based custom applications. The programmer worked in the United Kingdom.
Hubbard worried that the programmer's wild code might affect the second drive. "If the second drive 'disappears,' the client is out of business, literally," he said. "My client is in such a panic mode that he's barely coherent."
Hubbard was in a bind. The customer's programmer had done so much tweaking of the OS and application code that Hubbard had trouble identifying the problem-causing modification. Since a non-Red Hat programmer had changed the code, he said, his client would have to pay Red Hat for a support call. He didn't feel confident that the client's dollars would be well spent, since his own previous calls to Linux vendor support lines had left him dissatisfied. "I've figured out the [Linux] problems I've encountered myself," he said.
As of this writing -- in late April 2003 --the programmer had not dealt with the problem. As a contract worker, said Hubbard, the programmer isn't very responsive, even in emergencies. Trouble is, he's done a lot of programming for Hubbard's client and hasn't provided documentation. "Because he knows the program and what codes and changes he wrote, no one can touch it but him," Hubbard said.
Once the programmer fixes the problem, Hubbard plans to use a utility to extract the data from the code and import it to Microsoft SQL Server.
In this case, the customer would have been better off with a Microsoft environment, in Hubbard's opinion. First, programmers wouldn't have had such a free hand. Fewer customization options would have made diagnosis easier. "If this were a Windows machine, I could have had him operational in a couple of hours," Hubbard said. Also, Hubbard has had positive experiences with Microsoft support.
Because of the use of custom applications, it's too difficult to move this customer's system over to the Microsoft platform. "But I am going to move him eventually," said Hubbard. "I will move the company to a Windows server and free the client from this ball-and-chain programmer that has him captive."
With other clients, however, Hubbard is keeping his options open. If a customer prefers Linux, "I say, 'Go for it.'"
FOR MORE INFORMATION:
- FEEDBACK: Were there other alternatives the consultant in this Wrong Choice article should have considered?
Send your feedback to the SearchEnterpriseLinux.com news team.