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.
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
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Returning Values from Bash Functions
- Rogue Wave Software's Zend Server
- Doing for User Space What We Did for Kernel Space
- 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