An Interview with DEC
The Alpha port of Linux actually started on two fronts, one in the Littleton, Massachusetts offices of Digital Equipment Corporation, and one on a riverboat in New Orleans, Louisiana.
The first front was started by Jim Paradis of Digital Semiconductor's Alpha Migration Tools group. Jim's group is responsible for finding innovative new ways of using Alpha processors, and Jim had been looking at several versions of the Unix operating system to determine if there was a possibility of doing a port. Jim had determined that Linux would give an efficient, powerful operating system, and he proceeded to start a 32-bit port of Linux to the Alpha as a test case. Jim believed that a 32-bit version of Linux would be the easiest platform for porting the GNU tools, the X Window System and other applications.
In the meantime, Jon “maddog” Hall was helping to plan for a DECUS event in New Orleans. DECUS is the Digital Equipment Corporation Users' Society, and the Chairman of the DECUS Unix Special Interest Group (Unix SIG), Kurt Reisler, wanted to bring Linus Torvalds to DECUS to speak about Linux. This was in May of 1994, and V1.0 of the kernel had only recently been released. Kurt was having trouble funding Linus's trip from Helsinki, so the Digital UNIX Base Product Marketing Team funded the trip. On meeting Linus, maddog was as impressed with the young man as he already was with the operating system he had designed. After DECUS, while riding the riverboat Natchez, the prospect of doing a 64-bit port to the Alpha was broached, and a short time later, an Alpha system was on its way to Helsinki.
About that same time, I found some of the Digital UNIX engineers were using Linux. Through contacts made in the engineering group, I located Jim Paradis and opened up conversations with him. Shortly afterward, a small team of engineers were put together to do further work on the Alpha port of Linux. Through marketing research, I convinced the team that joining their efforts with Linus in doing his 64-bit port was the thing to do. Although the 32-bit port was further along at the time, the 64-bit port was moving fast, and the issues around 32/64-bit porting were not materializing to the extent Jim had expected. Therefore, Jim “packed up” the 32-bit port, and the engineering staff started to attack the 64-bit port along with Linus and several brave volunteers.
When this project started, Linux only ran on Intel x86-based systems. The early days involved a lot of frantic activity tracking Linux kernel releases, and at the same time, porting Linux to the Alpha AXP platforms. The earliest port of Linux to the Alpha AXP was based upon the 32-bit Intel kernel, and in retrospect, maybe we should have been braver and gone straight to 64-bit native AXP support. At that time Linus was working toward exactly this end. His approach was to port the kernel to AXP and run Digital Unix binaries to get a working system. Our approach was to take 32-bit Intel Linux and port that and the rest of the system applications (for example init and bash) to AXP without disturbing their natural 32-bit-ness. We swapped a lot of code with Linus but in the end felt we were not contributing to the mainstream effort—which was always Linus's codestream. I guess there was just so much to be done that all of the work was useful, but in the end, we switched over to Linus's 64-bit AXP kernel work and contributed there. Very little of the early work was wasted; the work I did on MILO (the Alpha Linux Miniloader) ported straight over to 64-bit Linux, as did Jay Estabrook's device driver work and Jim Paradis's memory management and systems work. The PCI code used in all of Linux's platforms also comes from that time period. Our first goal was to get a self-hosting Alpha Linux system that did not crash and had working SCSI and Ethernet device drivers. We needed SCSI to support the file system and Ethernet device drivers to support networking. There had to be enough applications to be able to build the Alpha Linux kernel.
In the very early days, there were no other Alpha AXP users besides the three of us in Digital and Linus. Another hardy early contributor was David Mosberger-Tang, who was brave enough to buy an Alpha AXP Noname system and start hacking. The five of us worked hard and the code flowed freely. Our early goal was to have a free distribution of Alpha Linux that could be taken and used by the greater Linux Community. Jim Paradis's BLADE release contained enough of a system for people to easily get Alpha Linux up and running on their system well enough to start writing code. At the time BLADE came out, there were only two widely available supported Alpha Linux systems, the Jensen (DECPC 150) and the Noname board (so called because any clone vendor could put their name on it). The Noname board was reasonably—although still rather expensively—priced, and quite a few were purchased for running Linux. BLADE got Alpha out to the mainstream Linux community—or, at least, to the braver souls in the Linux community.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Server Hardening
- BitTorrent Inc.'s Sync
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- New Container Image Standard Promises More Portable Apps
- The Humble Hacker?
- The Death of RoboVM
- The US Government and Open-Source Software
- EnterpriseDB's EDB Postgres Advanced Server and EDB Postgres Enterprise Manager
- Open-Source Project Secretly Funded by CIA
- ACI Worldwide's UP Retail Payments
In modern computer systems, privacy and security are mandatory. However, connections from the outside over public networks automatically imply risks. One easily available solution to avoid eavesdroppers’ attempts is SSH. But, its wide adoption during the past 21 years has made it a target for attackers, so hardening your system properly is a must.
Additionally, in highly regulated markets, you must comply with specific operational requirements, proving that you conform to standards and even that you have included new mandatory authentication methods, such as two-factor authentication. In this ebook, I discuss SSH and how to configure and manage it to guarantee that your network is safe, your data is secure and that you comply with relevant regulations.Get the Guide