My Next Pentium Is A DEC Alpha
The DEC Alpha source has been merged back into the generic Linux version 1.3.x. The result is, you can go to Linus' home page and download and build the linux-pre2.0.10 with full Alpha support. But, there is no support (yet) for sharable libraries (neither about QMAGIC/ZMAGIC, nor ELF). Plans are afoot to go to ELF while retaining DEC Unix compatibility via statically-linked binaries.
BLADE 0.3 based on 1.3 kernel; freely available
Red Hat 2.1 1.3.57 kernel; commercial distribution; shipping
Craftworks 2.1 1.3.89 kernel; commercial distribution; shipping soon
Of these, BLADE 0.3 is the original stable distribution. The README file at gatekeeper.dec.com suggests that you go with a commercial distribution instead. BLADE therefore is basically recent legacy code, albeit freely available.
BLADE, Red Hat, and Craftworks all come with the requisite kernel, compilers, libraries and utilities you would expect from a baseline Linux distribution. The commercial distributions, however, come with all the “goodies” you would expect (and get) from their Intel brethren—such as editors, networking, X-Windows, TCL/TK, etc.
What differentiates one commercial distribution from the other is the package mix that each vendor ships with his CDs. Ease of use of the installation packages has to be weighed in. The documentation is essentially the same for the Alpha and the Intel versions. Both Red Hat and Craftworks, however, come with installation instructions. Red Hat adds the Alpha FAQ to the documentation. Either way, there is little enough unique about the AXP to require custom documentation.
My UDB came pre-installed with Windows NT and Linux (I had ordered Red Hat 2.1). The vendor, DCG Computers, installed a pre-release of the Craftworks 2.1 package, so I could help them compare and contrast the two versions. Here are some of my findings.
The Craftworks product is newer than Red Hat 2.1; you get Linux kernel 1.3.89 versus Red Hat's 1.3.57. Both are fairly stable, and of course, you can always download the latest kernel no matter which package you use.
The DEC DC21030 display controller chip (aka the TGA) is built into the Multia. The Red Hat 2.1 does not come with an X display driver for this chip, although Craftworks does. Other video drivers come with the XFree86 port for the Alpha, including the S3, P9000, and Mach 64 (which both Red Hat and Craftworks have.) When Red Hat 2.1 was released, you had to buy a PCI video adaptor to run X on the UDP. In the interim, DEC has released an X server for the TGA, which Craftworks includes. Craftworks also comes with Lesstif, a Motif 1.2-like widget library.
The great equalizer is the installation program. Both run reasonably well, but each has little personality quirks that provide a few minutes' grief. The Red Hat package will partition your hard disk, make the swap partition (mkswap), but then forget to make the ext2 partition (mke2fs). Fortunately, you can switch over to the second virtual terminal and take care of this omission before continuing the installation process.
The Craftworks install package is somewhat overzealous in enforcing the size of the swap partition. They want you to have a 32 MB swap. That is fine, but I made a smaller one with Red Hat previously. The notification/irritation prompt keeps coming up about the small swap partition. It wouldn't let me do anything about it, such as kill it, and resize the partitions, but it was very persistent in its warnings. I finally had to bring up Red Hat's partition editor to delete all partitions by hand before I could continue. It could understand an empty partition table, but one that was made incorrectly beforehand could not be dealt with.
The trials and tribulations provided by the install programs yielded more amusement than anything else. So, the question is, which distribution would I use? Well, before I chicken out and tell you that I hand-merged things that I liked from both distributions (such as: glint from Red Hat, NYS shadow passwords from Craftworks, the Craftworks X Server, 1.3.89 kernel, etc.) let me mention to you that not all the candidates have been heard from.
Red Hat is scheduled to release version 3.0.3. I noticed that they have the new X Server. No doubt their standard packages have been updated to match their Intel 3.0.3 offerings.
On PCs, the boot ROM attempts to read the initial sector of the primary floppy drive, or of the primary hard disk. Bootstrapping from that sector, the rest of the operating system is loaded. This design is fairly limited and the fact that the DEC moves away from that nonsense is the good news. The SRM Console Loader for the Multia comes with the ARC loader. ARC is pretty cool, insofar as you can have multiple operating systems configured (from which you may choose at boot-time); these systems' boot sector can exist on any partition of any addressable device, including the floppy disk or CD-ROM. In fact, you can have vmlinux on the floppy drive and have the root partition be on a hard disk. This is all the good news.
The bad news is that I am a dangerous fellow. As I mentioned, I had DCG Computers install Windows NT and Linux together. Unfortunately, too much space was given to NT (more appropriately, I like to fit 2GB of Linux onto a 1GB partition). So, there I was, an hour after unpacking everything and firing it up, readjusting the partition table and trying to keep the ARC loader appraised of what I was doing. Well, I ended up with ARC knowing of NO operating system, and the partition table being empty, and I could boot neither NT nor Linux! Now comes the moment of gravely earned education...
Craftworks comes with the boot and root/installation partition on floppies. There are instructions on how to reprogram ARC to understand that the floppy disk has the operating system. Red Hat has the images of these floppies on the CD-ROM, but you have to find a way to get those downloaded to floppy. A friend with a PC and CD-ROM drive is useful (definitely, definitely, definitely make master copies of those floppies after you finish your installation).
ARC was written by Microsoft and DEC. Its specialty is loading operating systems from file systems it understands, specifically MSDOS FAT partitions. Once you point to one, you tell it which executable to run in order `to load the desired operating system. For Windows NT, that would be OSLOADER.EXE. For Linux, that would be MILO. But, the requirement here is that your loader has to be found on a FAT file system (it could be in any subdirectory, given whatever name you'd like). Let me add to the fun by telling you that I initially received the UDP without the Craftworks CD-ROM and boot diskettes (they came the next week). Oh, and don't forget the three pages of documentation: none of the pictures told me what I wanted to know about ARC.
Thankfully, I had Windows NT, and ARC was written to simplify NT support. There's a menu option called “install NT”, which will install from the CD-ROM. The Microsoft documentation for any non-Intel platform was sort of humorous, saying, “see the vendor's documentation for detailed installation instructions for your platform.” But, then it said to run cd:\system\setupldr. System, system; what's a system?!?
Thankfully, the Pentium was nearby, and a quick directory of the NT's CD-ROM yielded that there were several directories, named after risc processors, where setupldr could be found. One of which is “alpha”... (Insert “D'Oh!” here).
Off to the races I went. Setupldr allowed NT to be installed, which gave me a nice FAT partition. On that Windows NT partition I placed a copy of MILO. A fun Saturday, which I stretched out to 4 am Sunday as the result ...
So, could I have moved the Red Hat CD to the Pentium and had it make the boot floppies? Yes, but if I remained Alpha-centric, I was doomed. Also, I had to learn ARC, and expected that having Windows NT install itself would educate me enough to get through it. Which it did; but if you look at something like this with no background, it looks scary:
LOADIDENTIFIER=Linux SYSTEMPARTITION=multi(0)disk(0)fdisk(0) OSLOADER=multi(0)disk(0)fdisk(0)\linload.exe OSLOADPARTITION=multi(0)disk(0)fdisk(0) OSLOADFILENAME=\milo OSLOADOPTIONS=
Which, if I look at SYSTEMPARTITION, tells me that the system partition can be found off the Multia, off of the floppy disk controller, on floppy disk 0. As opposed to my current Linux setup:
LOADIDENTIFIER=Linux SYSTEMPARTITION=scsi(0)disk(0)rdisk(0)partition(1) OSLOADER=scsi(0)disk(0)rdisk(0)partition(1)\linload.exe OSLOADPARTITION=scsi(0)disk(0)rdisk(0)partition(1) OSLOADFILENAME=\udb.arc OSLOADOPTIONS=boot sdb1:vmlinux.gz root=/dev/sdb1
Which says that I should go to the SCSI controller, a SCSI hard disk, raw hard disk 0, partition 1. Do you notice that this looks like a hierarchical file system? And so it does, except that it is describing the controller/hardware path to get to the boot code.
Practical Task Scheduling Deployment
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.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
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