Linux Goes to Sea

An Interview with Stephen Harris.

Randolph: What is your background and how did you learn of Linux?

Steven: I attended St. Peters College, Oxford University, 1987-1990, studing the joint honours school of Mathematics and Computation. This is where I was first exposed to Unix (Sun3 with SunOS 3.5, and High Level Hardware Orions under BSD 4.2 with some 4.3 extensions).

In summer 1990 I joined Papachristidis Ltd. (who do the administrative and agency functions for Hellespont Group) as one of a team of three. Various organisational changes mean I'm in charge of the whole lot now...

The Hellespont Group is a Greek shipping company, based in Piraeus, running a number of ULCC (Ultra Large Crude Carrier) and VLCC (Very Large Crude Carrier) oil tankers—some of the largest ships on the ocean, trading worldwide. There is an office in London as well, and the two offices are connected by an analogue leased line providing two speech and four data circuits. In the offices we run a network of Unix machines, with the users accessing the machine via dumb terminals (e.g. DEC VT320) and terminal servers. Our primary interface is simply users running vi and creating roff documents. Admittedly, not the most user-friendly of interfaces, but highly flexible and capable of being run on many Unix systems. On top of this we have written a large variety of shell scripts and C programs, also highly portable, and a well-defined file tree which determines where reports and files are to be stored, matching the hard-copy filing.

Back in Novemeber 1991 I had just got Interactive Unix disks (a real old version) and had installed it on my 386DX-20, when I heard in one of the comp.unix groups about a free Unix clone and a reference to alt.os.linux. I quickly found out where the kernel was, and downloaded Linus' root and boot disks. I was impressed.

Randolph: It's clear that you enjoy working with Linux. How did you persuade your firm to consider Linux?

Stephen: I showed the early Linux version to my Greek and American colleagues, who weren't impressed. I passed through 0.11 and 0.12 kernels when Owen LeBlanc's MCC-Interim Release 0.95 came out. 5 disks with a working Unix on them! Threw away Interactive (which never worked properly) and installed Linux. Peter MacDonald came out with his SLS package and I spent a fortune on phone bills downloading the disks.

At this stage the shipboard project was being planned around Sun Sparc systems (one per ship with VT terminals). My colleagues didn't think Linux was capable. SLS changed their minds, so I have Peter to blame (thank!) for convincing them. I offered to make copies of SLS available for people in the UK who couldn't afford to download it themselves, and Adam Richter sent me an Yggdrassil CD free. Now that I had the source code I built my own setup, which meant I could get around some of the problems SLS had.

From there it was a small step to experimenting in the office, installing a small Linux system on my desk, and determining if it could be used. Except for a few network problems (packet storms), it all worked quite well.

Randolph: Can you tell us more about how Linux is used on board?

Stephen: Firstly, the system now deals with 90% of the typed communications between ship and shore. Using software on the office hub, messages can be sent to the office and relayed out to third parties, using the much cheaper landlines. Frequently, one message is sent to multiple parties, so now the ship simply sends one message to the office and the computer automagically sends it to all the other recipients. Of course, the office doesn't just have telex either, and uses many alternatives, but that's another story.

Next, ship's reports can be created on the system, and printed, filed, sent to the office very easily. Similarly, reports and procedures written in the office can be distributed in source form to the ships for printing and local storage, making it an easy way to update manuals.

We are now sending more traffic than we were before installing the system, but the increase has had minimal cost effect compared to our savings... When we first installed fax machines onboard (many years ago) we initially saw a reduction in cost since fax was cheaper than telex, but then costs exploded when everything was faxed (even things that don't require it). Contrarily, the email system actually takes traffic away from fax (sending data as fixed-format email rather than fax) which has helped reduce costs more! We anticipate costs to rise slightly above the current level (to nowhere near the previous one!) as we send more data, but this should improve efficiency and the ability of the office to monitor shipside better, and so is an overall gain.

Spares and inventory control has been done on one of the ships—the complete parts list from the ship's plans has been entered, allowing an easy search for the official specifications when needing to order replacement parts and so on.

Requisitions (spares, stores, etc) are already handled by a structured document that is parsed by a script and printed in the office, instead of needing to fax the document from ship to shore.

The possibilities are endless.

Randolph: What was involved in installing this on board?

Stephen: At the time we had a ship in drydock just outside Lisbon, so that was the perfect ship to test on. The ship wasn't going anywhere, and we had access to landside facilities in case we forgot something!

The initial design called for a computer and five terminals, which would be placed in strategic locations in the ship (Captains office, Chief Engineers, Ships Library, Cargo Control Room, and Engine Control Room) allowing access to the main system for those that needed it. Wiring through the ship was done with unshielded twisted pair (3 pair) cables, terminating in RJ12 connectors, with two sets of wire to each location. The main unit was placed in the Radio Room. The wiring was chosen because it meant that the same wires could be used for telephones, 10baseT ethernet, or serial cables, simply by making the correct modular cables.

Installation was pretty straight forward. My American colleague, also onboard with me, had spent the previous week buying and fitting together the hardware, and making sure it was actually capable of booting a minimal system. I also had my notepad running Linux, so I could build an emergency boot floppy set if everything failed with the tape.

This was the beginning of a daily find bug / fix bug cycle that lasted through the two weeks we were onboard. While I did this, my colleague installed the working files to make the file tree look identical to that in the office. The end result was a system that looked very close to that running in the office—on the vastly more expensive Sun's.

After this, we left the ship to purchase some new equipment, some different modems, and so on, with plans to return a month later before the ship left dock.

When we returned, we replaced the terminals with smaller Linux systems, so the setup we now have is a central 486DX2-66 and three client machines, all running X and NFS'd together. The central server acts as communications and printer server for the network. To cope with a failure of the server machine a simple script was developed to change some of the main configuration files on one of the clients so that it acts as the server. Admittedly a server without any of the user files, but enough that the communications can be continued, and some simple work can be done.

We have since installed a similar system on a further five ships, this time using only 486SX-33 VLB machines (with VESA graphics) as clients; machine prices dropped to a level that it didn't make sense to use any with less power!

Randolph: What kinds of special problems do you find on board?

Stephen: A ship is one of the most electrically noisy environments I can think of, but only the longest cable produced noise—and then only when left unplugged from the terminal! We were quite impressed that the serial cables worked over such a large distance.

Power for the system is also problem: the ships generate their own power: 220V at 60Hz. To cope with this, we bought American equipment, and had a transformer to convert from 220 to 110V. We had a Triplite UPS to cope with the inevitible power fluctuations, and an Isobar to try and cope with any surges. A week earlier, another ship's generator went overspeed and shot over 660V through the mains—not something I wanted to risk on the PC!

Connecting the modem to the system was a lot of hard work. (When in range of shore stations we use cellular phones and when at sea we use the satellite based voice communication system Inmarsat A.) This wasn't the fault of Linux though! The main problem was the modem. Eventually we got reliable connections using Taylor UUCP. Using the 'g' protocol we could get 300+ cps average throughput. Not good compared to what v32 should be able to do, but a lot better than telex! When we upgraded the office Suns to use Taylor UUCP we managed to get 600+ cps average throughput using the 'i' protocol. The ship polls the office at four fixed times a day (different ships have different times to cut down on collisions).

Randolph: How do you administer these distant systems?

Stephen: Basically we give the radio officers some intensive training in the office on a system configured the same as the server. We show them how to perform basic admin tasks, such as backups, rebooting, sending email, and so on. They are also shown the hardware, how to reseat cards, and so on. A big problem on the ship is vibration, and so we expect more hardware problems than software. That, along with scripts and cron jobs, copes with most of the forseable problems. For the others...well, I'm only a phone call away!

In fact, from the problems we have had so far, our expectation of hardware failure being the biggest problem seems correct. One PC failed with a bad power supply (luckily this was on the first ship in the month we were upgrading the modems and so on, so we set up a new server and put that onboard at the same time). One laser printer failed to feed properly. One Boca board port blew. But the hardware is cheap and spares can be sent to a port where the ship is due, and the radio officers can perform the physical swap out. Only one software problem has occured (and unfortunately recurs because I haven't found a fix yet—printer daemons on slaves sometimes “stick”).

Randolph: What are your plans for future development?

Stephen: Well, we are still building the network. We consider the configuration to be a success and are planning to add a similar configuration to our remaining ships.

The office communications hub has recently been replaced with a Linux server that now routes most messages for the group, including our external email connections. A longer-term plain is to upgrade the office, replacing the dumb terminals with networked Linux machines.

One thing we will not do is “version chase”. The kernel and libraries we are using are out of date. But while it is doing what we want adequately there is no need to upgrade. If I did, then I would spend most of my time sending updates to the ships and doing little else!

Linux has proven itself extremely reliable. The cheapness of the hardware has meant that we could and did build a network onboard the ships vastly superior to one that would have been made based around Sun equipment. The extra facilties of email over telex, and the relative cheapness of the connection has meant that shipboard data can be sent to the office in a more usable form.

Since Inmarsat A costs are approximate US $1 for 6 seconds, message size becomes an important consideration! We want to develop a system that is 8 bit clean, allows routing of traffic via various media (direct uucp logins, internet email, modem dialup etc) and provides a sophisticated “receipt” system so the sender knows when the message has reached the destination (e.g. we don't want the ship to generate a receipt because it will cause extra ship-shore traffic (expensive) so the shore based hub will generate it once it knows the ship has collected it). Because all routing will be by my software, it can ensure the message survives whatever the transport restrictions are—e.g. with direct uucp it could gzip the file for sending, email it could uuencode, etc.

Randolph: When can I get a tour? I live in Seattle.

Stephen: Our ships (when they go to the USA) are mainly the other side—Galveston (for lightering, so they're offshore and you'd need helicoptor ride to reach them) and LOOP (Louisiana Offshore Oil Port—not easy to get to), so a tour of the ship is highly unlikely, I'm afraid. Of course, most of the time they spend away from any visible land travelling across the Atlantic Ocean, but sometimes they go to European ports (e.g. Rotterdam's Europort).

Randolph: Besides sending Linux to sea, what other claims to fame can you make?

Stephen: I'm the originator of the “I hate Linus Torvalds” thread in c.o.l where I said I hated him for making me upgrade my PC so I could run the excellent OS he had written (and was flamed by lots of people who never read the second page! Linus recognised it as a joke thankfully!)

I never did get round to sending him the postcard that was requested in the early release notes...

Randy Bentson has been programming for money since 1969—writing more tasking kernels in assembly code than he wants to admit. His first high-level language operating system was the UCSD P-system. For nearly 14 years he has been working with UNIX and for the last year he's been enjoying Linux. Randy is the author of the Linux driver for the Cyclades serial I/O card.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState