Linux Goes to Sea
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.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide