Linux on Low-End Hardware
I work in a research lab with many Unix boxes. My problem is that these boxes are dedicated to research almost all the time. Our system administrator doesn't really have time to support people like me, who want more than the traditional dial-in e-mail reading. Sure, term is quite useful, but I'm a traditionalist.
You see, I run Linux at home. I have the full power of a Unix machine in my house, and I am not going to be satisfied by using it as a terminal to dial into a server with it. I want my own e-mail!
In the old days of Unix, before Internet, machines transferred e-mail, news, and files flawlessly [Well, pretty well, anyway—Ed] by calling each other up over phone lines. A machine could have dozens of modems and would accept calls and periodically call up other machines using the system called uucp—Unix-to-Unix copy. Instead of getting files through anonymous ftp, people used “public uucp”. Instead of writing some nightmarish scripts to call in, transfer files, hang up, and process them, I thought—why not use uucp?
So I began looking for a machine to use. About that time, a friend of mine was hired, and we found an old computer in his office. It was an old 16 MHz 386SX. In its previous life, it ran Procomm and was a full-time terminal. What a change we had in mind—we transformed it into a multi-tasking Unix server! It had 4MB of RAM, which was enough to run Linux. But the hard disk wasn't much to gawk at—40MB. We named it “trappen”.
The purpose of trappen was two-fold. First, we wanted uucp connectivity to our home Linux boxes. Second, we wanted to provide anonymous ftp and http for ourselves; not that we badly needed it (though it would be handy) but more because it's fun to have your own personal Unix server.
We decided to split the disk in half—20MB for the system and swap space, and 20MB for file storage. Now, it needed about 5MB of swap space, so how was I supposed to squeeze a Linux system into 15MB and still have plenty of room for news, e-mail, and ftp-able files?
I've installed many Linux systems over the years, but I always simple used Ethernet to copy my setup onto the target computer. (I have almost created my own distribution.) But my system would take me days to prune down to 15MB. I had to resort to using someone else's distribution, instead.
In the beginning, Linux distributions were not really very fancy. They gave you the files, and you were on your own. If you weren't a Unix expert, you could get stuck in a swamp of daemons, config files, and strange programs. But I knew installations were getting better, so I decided it was worth a try.
I grabbed the latest Slackware distribution and looked at the disk contents; I could do it. I didn't need any programming libraries, and I didn't need X-Windows or anything fancy. Just the basics. About 20 minutes later, I had the tiniest Unix system I've ever seen! I went ahead and installed everything I needed, and it took 14MB! I had all the binaries I needed: news-readers, mail-readers, and uucp. The next step was to configure everything.
Now I expected to have a lot of things to configure. We had smail, anonymous ftp, and the rest, but the Slackware system did such a good job of setting up default configuration files that most things worked out of the box. What I did spend time on was smail and uucp. I set up uucp to route things to our two Linux boxes at home, and configured smail to use it. Then we went through and stripped out any functionality we didn't need, to make the system even smaller.
To support us, our network administrator here at the lab agreed to put in DNS MX records for our home computers, pointing to trappen. This would allow e-mail addressed to us at our home machines to be sent to trappen, which would process and spool it and forward it to us when we were connected.
Through trappen, we now had e-mail at home—not just for us, but for anyone who had accounts on our machines. My whole family has access, and they're learning to use e-mail and news. (It takes quite a bit of disk space to store news at home, but I only have a few groups, and I don't keep articles for very long.)
Trappen has plenty of power for all its tasks, though it is pretty slow interactively. But we have its console, as well as a Wyse terminal in its office. We decided to make the ultimate use of the console and terminal—as telnet terminals to other, more powerful machines. We decided to write a program which would ask for a host to telnet to, which would allow trappen to function as a terminal server. It turned out to be easy, thanks to the getty_ps package. Getty_ps is so versatile that we were able to set up configuration files such that instead of spawning login, it would spawn telnet. We changed the login prompt accordingly, and voila! Trappen's VGA console is the fastest terminal we have in the building, especially because it runs over Ethernet. The serial terminal attached to it is quite handy to check e-mail with.
Everything worked perfectly! We didn't have to touch trappen for a week. In fact, when we had time we decided to add a few enhancements. We added a uucp-ftp gateway. Someone can anonymously ftp and place files in a directory named to computer and trappen will automatically copy the files to a directory on the machine with that name.
Then we really went all-out. We didn't want to put an entire X-Windows environment on trappen (it was quite under powered), but it did have a VGA card. We got the X-Windows server program and all the X-Windows fonts and copied them over. Then we ran X-Windows with the -query option, which causes it to be an X-terminal to another machine, in this case to one of our high-powered machines in the lab. It worked! Trappen didn't have nearly enough power to run X-Windows applications locally but it wasn't bad as a graphical terminal. We eventually decided it was too slow, but it did work, and did not require much disk space.
Trappen is still going strong, over a year after it was “born”. It now allows slip access for our home machines. The CPU is severely limited in power, and during interactive use, it is quite slow, but transferring files and telnet sessions through trappen to other machines is almost instantaneous. Trappen now supports several users who use it to access the Internet.
UUCP is almost completely error-proof, so when I want to transfer a file between home and work, I uucp it. Trappen doesn't call out right away, but the machines connect every few hours. It doesn't matter if it can't connect right away; uucp always gets through eventually, and I know that when I get home, the file will be waiting in my incoming directory.
Trent Tuggle is an Engineering student at the University of Central Florida. His other job is programming virtual reality simulations at the Institute for Simulation and Training. Between the two of them he doesn't have any time, so consequently he's into water sports, model airplanes, and music synthesizers. His e-mail address is email@example.com.
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
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Tech Tip: Really Simple HTTP Server with Python
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 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