Linux in Antarctica
I was approached in September 1993 by Martin Hendy at AUSLIG (Australian Surveying and Land Information Group) to give him some information about Linux to see if it was suitable for a large project they had underway.
After I showed him a couple of Linux systems and gave him a rundown, he decided to go ahead, and the end result is that there are now eight Linux boxes scattered around Australia, gathering data on the Global Positioning System. The current systems are at Darwin, Ceduna, Alice Springs, Mawson Base (Antarctica), Davis Base (Antarctica), Casey Base (Antarctica), Macquarie Island, and Hobart. More are planned for other parts of Australia.
The application is a data gathering one. The Linux boxes are attached via serial ports to a “TurboRogue” satellite receiver system, which monitors the 32-satellite Global Positioning System. Data is downloaded from the satellites and stored in a 4MB flashcard in the back of the TurboRogue, and from there it is downloaded to the Linux systems. These systems store the data and forward it to a base system in Canberra.
The monitoring of the GPS system is essential for accurate surveying work. Some other countries (notably Canada) have set up similar networks for the same purpose.
Some of the Linux systems are connected directly to AARNet via Ethernet (yes, Antarctica is networked!) while others have 14.4 Kbps modems and download data via scheduled cron jobs, using the term package. Even the machines on the net have modems, as we can't absolutely rely on the network link.
The Antarctic Linux systems are Digital 48633DX MT PCs with 8MB RAM. They have two 345MB IDE hard disks, with only one electrically connected, (the other is identically configured as a backup). They have one 1.44MB floppy drive and a spare floppy (again, not connected). They have WD8013 Ethernet cards and DataLink 14.4 Kbps modems.
The Linux systems for the other Australian sites are rack-mounted “clone” PCs, for various reasons. They are identically configured.
Each system has four serial ports, each on its own interrupt. We achieved this by making some minor modifications to a cheap 2-port serial board we bought in Canberra. The more recently installed systems have eight serial ports using two 4-port cards. The extra serial lines allow for control of more equipment.
The other custom hardware is a “rebooting module” designed and built by Anthony Wesley here in Canberra. It is a small box that attaches to a serial port, a power lead and the reset line of the computer. Basically, it expects a “healthy” signal from the computer every five minutes on the serial line, or else it “presses reset” by shorting the reset line for 30 seconds. These boxes are very rarely needed, but it's good to know that they are there.
A process runs a script to check half a dozen things every minute and outputs the “healthy” signal if they all pass.
The systems originally ran 0.99pl12 with a few patches. I chose this because I have found it stable for my own use. We have upgraded (only rarely) when we needed particular features or bugs fixed. One of the features of having the PCs running Linux (they were considering DOS) is that we can completely replace the system remotely, either via modem or the net.
Each hard disk has four partitions: a DOS partition with their old software on it (just in case), two Linux root partitions (identically configured), and a data partition (the bulk of the disk).
The Linux root partitions are 20MB and are only half full! Most of them are, in fact, taken up with things that are only included “just in case”, like kernel sources, gcc, sources for the TurboRogue controlling software and even Emacs 19.16 (to make life a little easier).
I have designed the system to be very small. It is small enough, in fact, that the whole system can operate from a single 1.44MB floppy if I leave out the “optional extras”. This is achieved by having the whole of the /usr tree in a compressed tar file which uncompresses onto a ramdisk on bootup, and having next to nothing outside of /usr. The systems on the hard disk are already uncompressed.
This means that in case of emergency we can tell the on-site operators to insert one of the duplicate “Emergency root disks” and we can operate the complete system remotely just from the floppy, including disk-fixing tools like fdisk and e2fsck.
cron is used to control the regular downloading of data from the TurboRogue and transmitting the data to Canberra. Checksums are used to ensure the data is correctly transmitted, and it is re-transmitted if necessary.
Since October 1993, when the first systems in Antarctica came on-line, an enormous amount of data has flowed from the remote systems to the main system here in Canberra. It is a great credit to Linux that it has performed so well under difficult conditions. Congratulations to Linus and all the Linux developers!
Andrew Tridgell has been involved in the Linux community since December 1992. He has worked on a number of projects, including DOSEmu, the “Linux in Antarctica” project, some TCP hacks, and, more recently, Samba. He is currently the convener of the Canberra Linux Users Group. Andrew and his wife Susan live in Canberra and enjoy bushwalking, sailing, watching TV, speaking Swedish, and eating pizza.
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
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
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