Cooking with Linux
Linux users these days have it easy. Back when I was starting out with the system (around the 0.12 days), we didn't have the luxuries of networking, documentation, DOSEMU, or XFree86 for that matter. We didn't have “Plug and Play” Linux distributions on media ranging from floppy to tape to CD-ROM. There were two so-called “distributions” to choose from: H.J. Lu's classic “boot/root” diskettes, or the then-popular MCC-Interim release-which contained nearly all of the Linux software available at the time on a whopping seven diskettes.
Today, Linux development has improved to such a point that nothing seems to be challenging anymore. Running gcc without a segmentation fault used to give me thrills; now it's a part of everyday life. (On occasion,
I will fire up my ancient 0.95+ kernel and try to compile Emacs with gcc-1.38, just to bring back the excitement of cursing at the machine for hours as error messages fill the screen.) Linux is just too easy. Anybody can download Slackware and run their own WWW server over a SLIP line. And without having to compile a single line of code! It's sad, I'm telling you.
To fully appreciate the power of Linux, I believe that all newcomers should be forced to relive those days of yore, when the definition of a “real hacker” was someone who would stay up all night in a vain attempt to decipher the semantics of the serial driver. (Possibly in order to get the serial cheese grater to work, but that is another story.) Without going through this kind of painful, teeth-grinding ordeal it is too easy for users to take the many, many hours of hard work by the Linux developers for granted.
So, I think it is appropriate at this time to inflict a reality check on the current generation of Linux users, in the form of a short “Do You Remember?” quiz. Without overdoing the nostalgia, let us say that if you can remember at least, er, half of the items in this list then you are qualified to call yourself a Linux grunt—who has earned the right to sit back and drink coffee while your Linux box formats your thesis with TeX, recompiles libc, and provides anonymous FTP access to the majority of Eastern Europe all at the same time.
Be warned: Some of the items in the following list may bring back painful memories. If you are overly sentimental or have small children, you may want to consider turning the page—now.
1. ...comp.os.linux? All right, that's an easy one, but since the proliferation of the—what is it now?—five Linux newsgroups, some of us may have forgotten how pleasant it was to spend a Friday evening—scratch that—an entire week, catching up on articles in the single Linux-related Usenet forum. Unless you had a killfile larger than the collected works of Terry Pratchett you simply had no hope of following it all. And woe to the faithful reader that missed “important” postings, such as announcements of new kernel releases, or the weekly “Linux is Obsolete” flamewar.
Eventually, the Linux community wised up and decided to create comp.os.linux.announce, and six months later the current slew of Linux groups. This was at a time when nearly 50% of postings to c.o.l were calls for a newsgroup split, so it was inevitable.
Bonus question: If you remember comp.os.linux, what about alt.os.linux, its predecessor? Or, what about the first Linux threads to emerge on comp.os.minix? (If you can remember this, then you really are a Linux hacker. Either that, or you spend too much time reading Usenet.)
2. ...When the major Linux FTP site was banjo.concert.net? That's right—long before SunSITE was merely a desk calculator, there was banjo. Alan Clegg, who ran banjo at the time, was eventually forced to remove the Linux archives from that machine, as they required too much diskspace—an entire 45 megs. To top it all off, there were dozens of FTP logins a day. It was too much for the poor machine, so banjo had to call it quits.
SunSITE's entry into the Linux world was due in part to Jon Magid (do you remember him?) being hired as the systems administrator for a new FTP/Gopher/WAIS/WWW site funded by Sun Microsystems. Sun gave the SunSITE administrators permission to provide any kind of interesting information that they wished from the new machine, so Jon copied banjo's entire Linux archives over.
Since then, Linux FTP usage on SunSITE has grown to amazing proportions. The Linux archives there now require more than 640 megabytes of disk storage. On a typical day, there might be 2,500 Linux FTP logins, and around 43,000 Linux files downloaded in all. If you were to count all of the Linux-related FTP traffic to SunSITE's many mirrors, as well as the other major Linux archive sites, I'm sure you'd have enough statistics to give the NSF a real headache.
3. ...The Minix filesystem? This filesystem was (and perhaps still is) a favorite of Linux hackers for quite some time. Never mind the fact that it was originally the only filesystem type supported by the kernel, and that it limited partitions to 64 megabytes in size. Linus Torvalds began development of the Linux kernel under Minix, an academic Unix clone featured in an operating systems book by Andy Tanenbaum. So it made perfect sense to implement the Minix filesystem for which Linus had the source code. There is an interesting anecdote (or shall we say “legend?”) in which Linus accidentally trashed one of his Minix filesystems—the one which happened to contain the entire Linux kernel source tree on his system. Linus, being the Minix filesystem wizard that he is, managed to repair the damaged superblock by hand and save untold hours of work. The day was saved.
4. ...Ross Biro and the Linux TCP/IP code? Back in the early days of the Linux kernel (a mind-staggering two years ago), there was no networking support in the Linux kernel whatsoever. Many users were forced to boot MS-DOS (or some other operating system) to talk to the network—others resorted to more dated methods such as (gasp) UUCP.
The first generation of the Linux TCP/IP code (now known as “NET-1”, but that is a posthumous title) was developed by many people, Ross Biro being one of the foremost. Although it supported a limited range of hardware (Ethernet only, of course—SLIP was out of the question), and was far from perfect, it was really quite impressive at the time. Well, perhaps I should put that another way. After pulling an all-nighter to hack the alpha TCP/IP code into my, er, “personalized” kernel, you'd better believe that I was impressed. After wrestling with compilation errors and kernel panics all night, bloodshot and weary, I remember running telnet just as the first rays of dawn made their way through the window—and it worked! Of course, the kernel crashed five minutes later, but it was good enough for me. “Login or bust!” was my motto for the evening.
Ross was one of the key figures in the development of the Linux TCP/IP suite, along with Don Becker and others. However, as more and more Linux users attempted to employ their code, more and more problems would emerge—inevitably causing Ross' mailbox to be flooded with unwarranted complaints and flames. Not long thereafter Ross “threw in the towel”, tired of the inappropriate treatment by the Linux user community. The Linux development effort lost an important player on that day. (The moral of the story? I forget.)
5. ...Shoelace? These were short lengths of string or cord, used to tie shoes, that were eventually driven into obsolescence by Velcro. Wait a minute! Shoelace was actu-ally the predecessor to LILO, which as we all know is the LInux LOader, responsible for booting Linux (and whatever other operating systems you may have installed). Shoelace was originally the only way to boot Linux from the hard drive—and most Linux users at the time used a kernel floppy. What did using Shoelace entail? The exact details are lost in the mists of time, but I do remember having to modify sectors 508 and 509 of the kernel image—by hand—in order to set the root filesystem device. (In fact, this was necessary even if you didn't use Shoelace—but manual editing of kernel images is something that Linux veterans always love to brag about.)
Another caveat associated with Shoelace was that it could only be recompiled under Minix. In fact, the Linux kernel once shared the same fate: One had to have Minix installed in order to compile the Linux kernel—and, at one time, to even install the Linux software. (This period was to Linux what the Dark Ages were to European history. Minus famine and cultural stagnation, of course.)
6. ...The original Linux FAQ? (Perhaps this question should read, “Do you want to remember the original Linux FAQ?”) The original list of Linux Frequently Asked Questions was coordinated by Marc-Michel Corsini (although the first version was posted by Robert Blum). It was a dinosaur of a document. The list of authors and contributors numbered in the dozens, and the number of mistakes and incongruencies topped that. It was a valiant effort, mind you—in fact, I maintained, or tried to maintain, several sections of the FAQ before giving up. Eventually, as the document was nearing critical mass (800K or so) and was posted in no less than 7 parts each month, everyone agreed that it was too long and out-of-date to maintain any further. Ian Jackson rewrote the FAQ from scratch, and we started the HOWTO project to pick up the pieces. Since then things have been relatively peachy.
The last version of the original FAQ that I have archived is from July 1993, which places it just before Ian's rewrite and the comp.os.linux newsgroup split of that summer. Linux users who were around at that time may remember the following classic excerpts, both of which are attributed to Marc-Michel Corsini:
“The last-change-date of this posting is always `two minutes ago'. :)”
“The FAQ contains a lot of information sometimes I've put it down in 3 different ways because people seem not to understand what they read (or what I wrote, you know I'm just a froggy and English is not my natural language). What I mean is that not all is in the FAQ but many things are there, so please just take time to read it this will spare a lot of the other Linuxers [and if you think I should rephrase some Q/A just drop me a note with the corrections].”
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)
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- 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