Archive for the ‘linux’ Category

Do What You’re Good At

August 8, 2008

In 1993, I unexpectedly did some good when I was hired to do something I wasn’t good at.

I was going to college part-time and working to pay my way. For almost five years, I had been writing and maintaining various utilities that were part of the GNU operating system (now used mainly with Linux). For a couple of those summers I’d actually been employed as a programmer by the Free Software Foundation, the nonprofit organization that coordinates the GNU Project.

I was looking for year-round part-time work (full-time in the summer), so I got in contact with Cygnus Support, a company founded to do for-profit work on GNU code. (It’s now part of Red Hat.) It seemed like a logical fit. After a telephone interview, I was hired. I spent the summer at the beautiful Cygnus offices in Mountain View, California; here is what the front entrance looked like:

Cygnus Support entrance

Cygnus was looking for someone to maintain the GNU linker/loader ld, part of the binutils compiler toolchain that their employees had written. The guy who wrote GNU ld, Steve Chamberlain, is a brilliant programmer several years older than I am. He had written it for a contract with an insane deadline, and then had to move immediately to another project with another insane deadline in order to keep bringing in enough income to keep the company afloat. In the meantime, he hadn’t had time to do much documenting of his code. And he didn’t have time to explain it to me, either.

Although I was working on a CS degree, I hadn’t taken a compilers class yet. When I started looking at the source code to ld, I was horrified to discover that it was all a hand-written parser for a complex linker language derived from System V Unix (but extended so it was even more complicated). I’d chase function calls and pointers from here to there but could never figure out what the control flow was. It was way more complicated than I’d expected. I never did understand most of the code.

I got so frustrated that weekly I’d rush into my boss’s office in tears saying I couldn’t do it. She’d reassure me and I’d go stare at the code some more. I did learn enough about the code to fix some isolated bugs, but the hard ones I’d always find ways to pass off onto more experienced coders on the team, even though they weren’t supposedly working on the linker.

While I was struggling to understand the code, I learned a significant amount about the BFD library that the Cygnus binutils are based on, and there I started to make a difference. Some things I am good at are making things more consistent and making things more user-friendly. Cleanup work. I’d done that a lot on other GNU utilities for the FSF. I started improving the BFD library; I added some missing functionality, documented it better, and wrote a new utility to make it easier to analyze files built with it.

While doing that, I also took a close look at the configuration scripts that the binutils used. They were designed to support many computer architectures, but a lot of the configuration had to be done by hand. For the FSF utilities, I had written a system called Autoconf to generate automatic configuration scripts, but those couldn’t handle CPU architecture selection. I decided to merge the two systems into a best-of system (Autoconf 2), and I spent much of the summer of ’93 doing that and converting all of Cygnus’s utilities to use it. It got an enthusiastic reception and I believe it’s still in use 15 years later.

While improving and documenting Autoconf, I examined the Texinfo documentation system that GNU and Cygnus used. There were some scripts for printing out manuals in various formats, which involved some tricks with indexing and Postscript. I made some improvements to the documentation tools that summer, but I’ve forgotten exactly what they were.

After a few more months, I left the job at Cygnus to work as a programmer and system administrator for the University of Maryland. Cygnus deserved someone more suitable to work on the linker. But though I was just treading water as a linker maintainer, Cygnus got some valuable improvements to their software surrounding the linker that no one else probably would have done. And I enjoyed doing that.

It seems like this happens at most of the jobs I’ve had. I end up redefining the job description to be things I’m good at, and everyone’s pretty happy with how it turns out.

A Pragmatic Decision

August 5, 2008

(The following appears in the March 1988 UNIX Review magazine, in a comparative review of C compilers. The version of gcc that they tested in the article was 1.17, but you can still find the code they mention in gcc 1.40, in cccp.c.)

GCC’s early handling of the ANSI #pragma construct is perhaps worth noting at this point. Compiler writers are at liberty to deal with #pragma as they see fit. Paul Rubin, in a bit of whimsy, chose to start running the Tower-of-Hanoi game under emacs. Where this was impossible, a session of the hack game was attempted. Failing that, a rogue session was attempted. When all of these efforts failed, the compiler printed the error message: “You are in a maze of twisty compiler features, all different”.

More recent versions of GCC have this code disabled, however, and #pragma directives now are simply ignored. The original code is still distributed, though, for those who prefer it.

Origin of POSIX

August 5, 2008
From jsq@longway.tic.com Thu May  3 19:16:29 1990
From: jsq@longway.tic.com (John S. Quarterman)
Newsgroups: comp.std.unix
Subject: Re: Answer to "what does POSIX stand for?"
Date: 2 May 90 18:17:10 GMT
Reply-To: std-unix@uunet.uu.net

From: John S. Quarterman 

In article  From: Don_Lewine@dgc.ceo.dg.com:
>From the Rationale and Note section of IEEE Std 1003.1-1988 section B.1:
>
>"Since the interface enables application writers to write portable
>applications -- it was developed with that goal in mind -- it has been
>dubbed POSIX, an acronym for Portable Operations System Interface.  The
>name POSIX, suggested by Richard Stallman, was adopted during the printing
>of the Trial Use Standard."

At the time, the official name of the proposed standard was IEEE
Standard Portable Operating System Environment, or POSE.  Thus POSIX
was a fairly obvious pun to produce something that sounded and looked
similar to UNIX.  The official name of the standard has changed several
times since then (it was at one point Standard Portable Operating
System for Computer Environments, or SPOSCE, and the name on the cover
of the Full Use Standard is IEEE Standard Portable Operating System
Interface for Computer Environments, or SPOSICE), but the name POSIX
has stuck.  Could have been worse:  there exist bound draft copies of
the Trial Use Standard that say IEEEIX on the cover....

>"... The term POSIX is expected to be pronounced pahz-icks, as in positive,
>not poh-six, or other variations."

Note that this assertion appears only in the rationale and the foreword,
not in the body of the standard.  This is because the committee could not
standardize a pronunciation, and in fact had no consensus on what it might be.
Nonetheless, there is a small clique that considers it their duty to enforce
what they regard as the correct pronunciation, even though they don't all
pronounce it the same way themselves.

Volume-Number: Volume 19, Number 98


Design a site like this with WordPress.com
Get started