Linux in the Real World
Although the layout system is running WfW and typesetting is running Linux, the file transfer is completely transparent to both departments, just like printing. This is made possible by Samba.
In the most basic sense, everything in the office uses TCP/IP as the underlying protocol. Windows for Workgroups speaks SMB (Session Message Block protocol), a protocol which uses TCP/IP. In order for Linux to speak SMB, we run Samba. Samba is a free implementation of the SMB protocol for Unix. It was developed by Andrew Tridgell in 1992 in an attempt to mount disk space from a Sun to a PC running Pathworks. [See Linux Journal Issue 7 for an account of Samba's development—ED] The Linux filesystem appears as network drives to WfW.
So Samba is used to seamlessly transfer the PostScript files from the WfW system to the Linux machine that drives the AGFA imagesetter. This is essentially a camera with a laser instead of a lens; it uses the laser to expose a large sheet of photographic film. There is one sheet of film for each black and white page and four sheets of film for each color page. This film is what is mailed to the printing company.
Once a magazine is finished, the files are archived on an Iomega Zip drive via Samba. The Zip drive is a removable 100 MB magnetic disk drive, much like a monster floppy, which is connected through a SCSI interface to the same Linux workstation that connects to the imagesetter. It connects to any SCSI-2 controller and acts like any other SCSI device. It is slightly slower than a typical hard drive but faster than some old MFM/RLL drives.
The ZIP disks are mounted on the Linux system like any other Linux filesystem. Linux views the new drive as a mounted partition of an existing drive. It can then be added to the Windows for Workgroups system, where the ZIP drive is seen as another network drive.
Besides Linux Journal, SSC publishes a series of books and references, primarily on Linux and Unix. Most of these products are done using troff and/or groff. The exceptions are the LDP (Linux Documentation Project) books, which are done in LaTeX, and the Internet Public Access Guide, which was done in Quark Express.
Again, we produce film directly at SSC to ship to the printer. One of the more interesting recent innovations was the ability to produce spot color separations using groff. This came about when we were updating the Korn Shell Reference. This card is in four colors. Besides the additional cost of having the printer produce the separations it was going to be very hard to proof a multi-color card if only black and white output was available.
Work on the part of Arnold Robbins and SSC staff produced an easy way to write the color changes directly in the groff source. With two targets in the Makefile, one for printing the color output and one for producing the color-separated film, we were able to accomplish the desired task. These changes require groff and won't work with troff, since they are done by including raw PostScript commands in the groff source.
Many people may be asking why we continue to produce products using what many consider outdated tools. For those who really use the Unix environment, groff offers some advantages. For example, many of our recent products have been written by authors located far away from our Seattle offices. By using groff, we can send small ASCII files and use tools like diff to only send changes between locations. It also means we don't need multiple copies of expensive layout programs to accomplish the task.
Our office manager uses QuickBooks to do our accounting. Why? Because it was available and inexpensive. She uses DOSemu on her Linux workstation for this task, allowing her to quickly switch back and forth between QuickBooks and, for example, her e-mail. In the future we hope to convert this task over to some software that runs on Linux, but for the moment, this offers a reasonable solution.
We have much planned for Linux in the future. For example, we currently do credit card verification off-line. We hope to write the necessary software to do this directly from a Linux system. We also hope that Progress will be ported to Linux. If this doesn't happen we will probably re-write our database system using a database that runs on Linux.
In conclusion, no, we don't use Linux for everything. But we come pretty close. Linux has proven inexpensive, easily expandable and reliable. For those who thought we didn't use Linux to produce the magazine, now you know. With all but one of our employees sitting at a Linux console every day, I think we practice what we preach rather well.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- Purism Librem 13 Review