My Life and Free Software
Often I get questions of how I got started in Linux, why I like Linux, or why I spend so much time on Linux. In this article, I hope to show that the concepts of free software and the gift of intellectual property to complete strangers are not necessarily new ideas.
The year was 1968. I was a college student studying electrical engineering at Drexel Institute of Technology (now Drexel University) in Philadelphia, PA. As a cooperative education student, I was expected to go into industry for a six-month work period. With great luck, I managed to land a job at the Western Electric Plant in Baltimore, Maryland.
The plant, which employed thousands of people, principally made wire for the Bell System. As part of the engineering department, they had an IBM 1130 computer that was run by a small staff of programmers/operators. The 1130 was a single-task machine, where you would typically write a program in FORTRAN, punch it on cards, and compile, link and run your program all at one time. Since the 1130 also had console lights and a very noisy disk coil, you could “see” and “hear” your program run. With a little practice, you could even tell when your program was in trouble by watching the console lights and listening to the disk drive “grunt”.
Back in those days, people did not have computers in their homes, and even the most forward-thinking high schools usually did not have a computer, so there was no way I could have learned to program an IBM 1130 in school. So I jumped at the chance to participate in a correspondence course called “Programming the IBM 1130 in FORTRAN”, sponsored by Western Electric. Over that summer, I learned to program the machine, completing a few small tasks for my supervisor, John Kammer. The people who ran the computer in the lab were very helpful to me, answering my many questions very patiently, which made a lasting impression.
Drexel had two large machines: one was a Burroughs B5500, the other an IBM. The IBM was shared as a facility with the University of Pennsylvania and Temple University. Both the IBM and the Burroughs were programmed with punched cards, and neither were available for me to “watch the lights and hear the grunts”. In other words, they were “glass house” machines. Discouraged by this, I looked around the school and found an electrical engineering lab with a couple of PDP-8 “minicomputers”, a Linc-8 minicomputer (all made by Digital Equipment Corporation) and a Data General Nova. These were “hands-on” machines, using an ASR-33 Teletype (five characters per second output) as printer/console terminals and paper tape as the load medium. Loading the editor took five minutes; loading the assembler took 15 minutes. A complete round of “edit, assemble, load program and run” took about half an hour, even with no editing time taken into account. A person got used to checking their code very carefully, in order to find as many errors on each run as possible.
Drexel offered no courses in computer languages. If you wanted to learn FORTRAN, you learned it on your own. If you wanted to learn assembly, you learned that on your own. Fortunately, I somehow made the acquaintance of the Digital Equipment Corporation salesman who gave me a couple of paperback books, one of which was on the fundamentals of programming in assembler, the other entitled Programming the PDP-8. From these two books, I started the task of learning to program the machines in assembly language. While learning assembler language programming from a book might sound daunting to some, the books (part of a handbook series put out by Digital) were very good, and along with the other students using the lab (the “lab rats”), we managed to coach each other through the process.
Later, several of the “lab rats” started a computer club. Our goal was to try to teach others how to use the minicomputers. We had some help from two sources: the DEC salesman (who gave us more books and encouragement) and the organization known as DECUS. Even in those early days, DEC's User Society had student chapters, and they also had a catalog of freely distributable software—free for the copying cost of transfer to paper tape, or (for the “really wealthy”) magnetic tape. There were hundreds of titles, from text editors to programs for doing mathematical analysis of all types. Each of these programs had been written by a DECUS member and submitted to the DECUS library for free dissemination.
I never forgot the kindness of that Digital salesman, nor the philosophy of the DECUS organization. It would have a profound effect on my later life, both as I chose new jobs and as I dealt with other people.
After graduation, I started looking for a job. I had several offers from different companies including the Bell System, but they all wanted people to program in high-level languages, and I wanted to continue to program in assembly. My chance came with Aetna Life and Casualty, an insurance company in Hartford, CT.
At the time, Aetna was the “largest multi-line insurance company in the free world”, which goes to show that if you use enough qualifiers, you can be the best of anything. Nevertheless, Aetna employed over 4,000 programmers, operators and computer operations people at their headquarters in Hartford, and they developed some of the first real-time transaction systems in the industry. They had a massive floor of IBM equipment, and they were the “largest commercial customer of IBM in the free world”. I was hired to write programs in IBM assembly. I told the interviewers I had never coded in IBM assembler, but they said they felt I “could learn”. So before I left for Hartford, I went to a bookstore and purchased a book on IBM assembly language and read it. Between that book and the IBM Principles of Operations of the IBM 360 manual, I learned the language and architecture.
While working at Aetna, two major things occurred. First, I started going to graduate school at night for my MSCS; the second was making friends with some of the operators of the machines. The second event brought me out of a shell I was in, and made me more outgoing. It also gave me physical access to the computer floor, something very useful from time to time as a programmer at Aetna. I also noticed that my tapes got mounted faster, my listings were sorted nicer, and various good things happened to me because I liked these people and treated them with respect. Other programmers who did not treat them with respect often had a hard time getting good service. Another major lesson learned in life.
After receiving my MSCS and having worked in two major divisions of Aetna over a four-year period, I decided to try my hand at teaching. I answered an advertisement for an assistant professor at Hartford State Technical College, a small two-year technical college in Hartford. Before taking the job or even applying for it, I spent a morning at the school looking at the lab, browsing through the college catalog and talking to the students.
I liked the lab at Hartford, because (unlike many schools of the day) it was not keypunch-card-oriented. Instead, they had twelve terminals hooked up to a PDP-11/70 timesharing machine, along with a stand-alone PDP-11/34 with a graphics tube and a large Gerber plotter for making drawings. The curriculum taught courses such as operating system design and compiler theory, both of which I felt were necessary if a programmer was truly to know what they were doing. Finally, the students were friendly and seemed to be dedicated to learning computer science. Remember, this was 1977, and for most of these students, HSTC was the first time they had set hand to computer keyboard.
I gave Aetna a two-week notice and took a $3,000 pay cut to teach at HSTC (to put things in perspective, in 1975 I bought a brand-new Toyota pickup truck for $5,000). But for the next four years, I enjoyed teaching at the school.
Most of you have heard that my nickname “maddog” came from the school and from my “discussions” with the Dean of Instruction. Even with these “discussions” (and sometimes even because of them), I look back on HSTC with fondness. Taking students who have no knowledge of computers at all and training them to be good programmers and designers, so they could enter the work force and get good jobs, has to be one of the most rewarding feelings in the world, no matter what the pay scale. Unfortunately, I have a rather eclectic lifestyle, and after four years, it started to catch up with me. Sadly, I left HSTC (after giving a year's notice) and went on to the next phase of my career, Bell Laboratories, to the dismay of the students, but to the cheering crowds of my creditors.
When I started interviewing at Bell Labs, the management wanted me to be the system administrator for a CDC Cyber machine. The CDC was a fascinating machine, and this would have been a good job, but I had heard Bell had their own operating system called Eunuchs, and I wanted to learn that. Eventually, the Lab management agreed, and I was hired as a system administrator for an operating system I had never seen.
The first few months of being a UNIX system administrator were “difficult”. Learning this new operating system that had no real good documentation, seemed to have programs scattered throughout the file system, and even had a deep hierarchical file system (instead of a flat “catalog” file system) was hard for me. Fortunately, I met two senior engineers there who (although they had not been trained in computer science) were administering two Digital machines, a PDP-11/70 and a VAX 11/780. They gave me guidance until I was ready to take over responsibility. However, after a short time I “got the swing of it”, and I also started teaching at night at Merrimack College in North Andover, MA. I did both of these jobs for four more years.
While at Bell Labs, I met a Digital salesman who told me about a project at Digital to create a commercial version of UNIX for the PDP-11 and VAX line. Since I was having some philosophical differences with the management at Bell Labs, I decided to leave them and go to Digital. There, I met a group of young, enthusiastic engineers who were determined to make the world's best UNIX system. It was too bad that their management did not share that vision. For the next sixteen years, we struggled to create and sell a UNIX product inside a corporation that (for the most part) only wanted to say “VMS” (later “OpenVMS”) and “Windows NT”. We struggled (and finally won) the battle of getting GNU software onto our distribution, after almost every other vendor was bundling it. It was at the start of these fifteen years that I was (once again) thrust back into DECUS and started attending USENIX conferences.
USENIX in 1983 was an exciting time. People came to this technical conference to talk about how they were improving the UNIX operating system. While many talks came from academia, some were from companies like Mitre, BBN and others that needed to have UNIX move forward for their own business reasons. After a talk was given, the UUCP address of where to get the code would be listed, or else a complete source code listing was included in the proceedings. However, as more and more companies got into the market of selling UNIX distributions in binary form, and more and more companies started buying UNIX this way, the availability of source code almost completely dried up. Although USENIX kept providing the venue for concept and knowledge exchange, it took many years and the insertion of the Open Source community before the same feeling of excitement came back.
While at Digital, I was a software engineer, a product manager and finally, a technical marketing manager. As a technical marketing manager, I had three main jobs. The first was to take complex technical concepts and present them in simple terms to customers; the second to take customer's requirements and feed them to engineering; and finally, to help create marketing opportunities for Digital. This included working with DECUS to make technical presentations relevant to the customer's needs.
As part of DECUS, there was a special interest group (SIG) called UNISIG which looked into “everything UNIX”. Kurt Reisler, the group's chairperson, had heard of a small operating system that had been started in Finland and was now being developed all over the world. He wanted to invite the architect of this operating system to DECUS in New Orleans in May of 1994. After watching Kurt send many, many letters to potential funders of the ticket, I decided this would be worthwhile for our customers and convinced my management to fund the ticket and hotel costs. It was in New Orleans that I first saw Linux and met Linus Torvalds.
After DECUS was over, I took Linus out on the Natchez, one of the riverboats that goes up and down the Mississippi River. We had dinner and discussed Linux. I asked Linus if he had ever considered porting Linux to a 64-bit processor and a RISC chip, to make sure it was portable. Linus told me he had considered that, but was having trouble getting an Alpha system from the Digital people in Helsinki. Knowing Digital's procedures, I could imagine the Helsinki people were trying, but having difficulty. I went back to my office, called a few friends, pulled in a few favors, and an Alpha system was on its way to Linus' apartment.
As I was getting the system for Linus, I became aware of how many engineers inside Digital were already using Linux, and that a group in Digital Semiconductor was trying to port Linux to the Alpha, but as a 32-bit port, not a 64-bit port as Linus was doing. With a little convincing, I got them to join forces with Linus.
In January of 1995, the project actually got underway, and as it unfolded, I found many people in the Linux community who wanted to help. Some people who already had access to an Alpha immediately started working on the code. Others actually bought their own Alpha to help with the project. In November of 1995, the first distribution of Alpha Linux came out. I was proud of the fact that the Linux community thought so much of Alpha, Digital and their own Linux system that they had all cooperated on this project.
About the same time, my travel schedule picked up and I started going all over the world to speak on Digital UNIX (the commercial system available from Digital). As I went from customer to customer, I would ask the same question: “Do you use Linux here?” Almost every one had the same pattern—the management said “No”, and the technical people would say “Yes, but don't tell our managers.” As I continued on my trips, more and more of my presentations became oriented toward Linux, and I began to write articles for both internal use and Linux Journal.
In 1996, the original Executive Director for Linux International stepped down, and I was elected to this position. For three years, I volunteered as Executive of Linux International while doing my duties at Digital Equipment. At first, it was relatively easy to work for both, but as the Linux marketplace heated up, I put in more hours on both sides. Finally, I had an offer from Larry Augustin of VA Linux Systems to have VA Linux pay my salary but work for Linux International full-time, so I left Digital and have been working on Linux International full-time since the spring of 1999.
I have been in the industry more than thirty years. All along the way, there have been people helping me out, giving me guidance and advice. While some of it was bad advice, much of it was good, and most of it was given with the best possible intentions. I have participated in the industry in both profit-making and non-profit-making projects. I have tried (not always completely successfully) to keep my word at all times, and to “do right” by the “customer”, whoever I considered “the customer” to be.
I have found in the Linux community what I feel is the best of all of my experiences. Good technical people to work with, open exchange of ideas, excitement and enthusiasm for what is going on. Young people (no matter what physical age) who strive to do their best, but also know how to have fun. The warmth of meeting new friends, and in some cases even being welcomed into their family. The potential of Linux in education, embedded systems, supercomputing, as well as the “normal” desktop and server situations is both to save money and extend computer science.
I know that in some parts of the Linux community, there is the feeling that the “suits are taking over”. From my experiences, labeling everyone in business a “suit” is as much an act of bigotry (and with all the same bad features) as any other type of bigotry. Many people I have met in industry who are moving into the Linux marketplace do want to learn what the Linux community is about, and they do appreciate the culture as they try to understand it. I have faith that the Linux community can expand to embrace these commercial interests without diluting our message, but we have to learn that it is easier to extend the hand of friendship rather than the battle axe (unless the battle axe is really needed).
The picture on this month's cover is very telling. And while some of my jobs over the years have required me to wear a suit on occasion, I am much happier as a shorts-and-T-shirt guy. While I have held jobs in commerce most of my life, I was and am happier when the free exchange of ideas (including source code) is available. And while I am definitely an American, I have been fortunate enough to meet and enjoy many different cultures and peoples. I hope Linux will be one of their main paths to computer autonomy, and for some emerging nations, development of their own computer industries.
Finally, over a thirty-year period I have been fortunate enough to meet and know some really fantastic pioneers of the computer industry, some famous and some not so famous. In the Linux community, I have already met hundreds more. As the next millennium moves on, I look forward to meeting thousands more both over the Internet and face to face.
Jon “maddog” Hall (email@example.com) is Executive Director of Linux International and Director of Linux Evangelism at VA Linux Systems.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
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.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
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