Enterprise Unix Roundup: Microsoft Targets Tux

by Michael Hall

Microsoft launches an ad campaign to close the window on Linux. A raft of patches are out for a Linux kernel bug that could allow for denial of service or local privilege escalation attacks. We review 'The UNIX Programming Environment,' a golden-oldie that holds (mostly) true 20 years after publication, and we recommend the bash history search as a way to drastically cut down command line keystrokes.

Microsoft has been dipping its toe in the waters of anti-Linux marketing in foreign markets for years. The company evidently now feels threatened enough in the United States that it decided to launch an 18-month-long print ad campaign (with an accompanying Web site), designed to tackle Linux on the issue of total cost of ownership (TCO). Although the campaign is global, it is the first time Microsoft has advertised against Linux in the United States.

The bulk of Microsoft's argument seems to lie with the issue of training and management. There's no denying it takes time to train a Linux admin if the said admin's experience has been limited to Microsoft products, and Linux is still behind in terms of management tools. However, that may be changing. As "something to watch in 2004," Novell's entry into the Linux space and its port of NetWare's traditionally solid management tools to Linux might do a lot to mitigate any claims Microsoft has in this area.

Compared to Microsoft's past approaches, there's something commendable in the company at least putting out some numbers. Granted, it's using a study it bought for some of those numbers, but any presentation of data is useful. You can argue with numbers; it's hard to argue with accusations of a crypto-Communist conspiracy, which was a favorite of Microsoft executives when the company was struggling to formulate a response to Linux in the late '90s.

But perhaps even more important than the fact that Microsoft is actually concerned enough about Linux to start marketing actively against it after assiduously avoiding that approach for years is that, of all the competitors in the world to tackle, Microsoft picked Linux. Specifically, Linux on the mainframe, an area of interest that sets aside any concern about Sun Microsystems, Hewlett-Packard, or other competitors in favor of the potent combination of Linux and IBM.

That's a more risky proposition than it might appear. The numbers tend to show that Linux makes its greatest impact against old-line Unix deployments, with Microsoft remaining relatively untouched. By legitimizing Linux as a primary competitor, and drawing attention to the operating system's potential usefulness as a Windows replacement, it's clear that Redmond doesn't like whatever it has seen in its crystal ball, and it's concerned enough to start brawling -- before Linux is well and truly on its doorstep.

Why else act before Linux is done eroding a still-vital proprietary Unix market?

In Other News

  • SCO sent out a letter to 6,000 UNIX licensees, asking them to certify they are not violating their license with SCO or contributing any SCO source to Linux. Recipients have 30 days to comply with the request for certification, after which SCO says it will start examining its legal options, including suspension of licenses.
  • Ximian announced its GNOME Desktop 2 product now supports SUSE 9. Considering Ximian and SUSE share a common corporate parent in Novell, that makes some sense.
  • A lot of people thought it was just a game of chicken when Israel announced its intent to halt its acquisition of Microsoft software, but the country did just that this week when it announced it will begin distributing OpenOffice this year. Sun backs OpenOffice's commercial incarnation, StarOffice. An interesting thing to watch with this particular story is how the switch will play at the operating system level: OpenOffice and StarOffice run with equal facility on Windows, Linux, and Solaris. If users overcome their dependence on Office-specific features, there's no reason to believe they can't overcome similar dependencies at the desktop level.

Security Roundup

  • A raft of patches are available for a bug in the Linux kernel that could allow for denial of service or local privilege escalation attacks. We've been watching the errata come in on this since Tuesday. Every major Linux vendor has something out, and Red Hat has gone so far as to offer patches for the versions of its Red Hat Linux product, which it end-of-lifed last week.
  • Patches continue to roll in for a bug in lftp. Check with your vendor if you haven't seen an announcement yet.
  • A previously reported vulnerability in ethereal, the network traffic analyzer, is also seeing some sporadic patching from late vendors.

The Unix Bookshelf

When we first started looking at Unix books, we spent some time with books that dealt with the Unix philosophy. Last week we diverged from that when we considered a recent book about clever solutions to problems on a Linux server. This week, we'll return to the previous arc with "The UNIX Programming Environment," by Brian Kernighan and Rob Pike.

Written in 1984, "The UNIX Programming Environment" might not seem a cutting-edge way to learn your way around the Unixen of today, and you'd be partially correct: Some things have changed to the point that a text written at a time when there were fewer Unix variants running around will show its age. On the other hand, some things about Unix just don't change. About the time this book was being written and DOS power users were learning to write batch files, Unix had been around for 15 years, behaving much as Kernighan and Pike describe it.

Twenty years later, the fundamentals of Unix life are still largely the same: You have to understand the Unix emphasis on pipes and filters; you have to understand the basics of the Unix filesystem (which remains largely unchanged despite some disagreements about the proper use of things like the /opt directory); and you have to understand the value of shell programming.

"The Unix Programming Environment" assumes very little of the user, providing an opening chapter that introduces how to log in, manipulate files, and redirect input/output from assorted programs. One area where the book's age definitely shows is its advocacy of the editor ed, which will remind anyone who ever wrote one of those DOS batch files of edlin. Few people still use ed, but in defending its use in their book, the authors noted its similarity to sed and awk, which continue to be Unix standbys.

Later chapters deal with job control, shell programming, pipes, and filters before moving into basic C programming and even document preparation using traditional Unix tools.

To be sure, there are better general-purpose "Unix books" out there. For simply explaining how all the commands work, for example, O'Reilly's "Unix in a Nutshell" combined with its "Learning the Unix Operating System" are probably a better combination for about the same price. There are three things cause us to recommend "The UNIX Programming Environment," though. For general users, the fluidity with which the book is written makes it easy to work through. Its age is also a strange sort of recommendation on its own: The book is a Unix ur-text, written during a time when Unix was everywhere but, as the authors ruefully noted, Unix expertise was increasingly hard to find. Finally, for the beginning Unix programmer, "The UNIX Programming Environment" offers a useful overview of development tools still in common use today.

Finally, in terms of the progression of our Unix bookshelf, it's a useful bridge text, taking us from the abstractions of "The Unix Philosophy" and "In the Beginning Was the Command Line," into the basics of applying the Unix Philosophy in a practical manner.

Tips of the Trade

This week's tip comes to us from Ed Heil, who dropped a quick line about something that has saved him (and us) an awful lot of keystrokes: the bash history search.

Suppose you've spent an afternoon poring over all the examples in "The UNIX Programming Environment," stringing together line after line of useful pipes and filters. After a while, you might get tired of repeatedly typing the same commands and wish there was a way to get at commands you've typed in the past.

Every Unix shell has its own way of dealing with this. Most allow you to use the up and down arrows to move through your command history, which is handy enough. But bash also allows for an incremental history search.

Consider, for example, this rather lengthy command:

$ cat /var/log/apache/access.log|grep catalog.php|grep -v

Faced with having to type that every now and then, you'd probably get tired of it pretty quickly. With the bash history search, you could dig that command up by simply pressing the ctrl and r keys, which generates this prompt:


Then you just have to start typing some portion of the command, such as catalog.php, to start an incremental search of your command history. When you get to the command you'd like to reuse, press the enter key, and that command will be entered. If you'd like to use most of the command, just press an arrow or editing key when it gets to the command you'd like to reuse and start editing, then press return to use it.

Emacs fans will be interested to note, if they don't know it already, that many Emacs-style commands, like ctrl-R, are available in bash, including using esc-< to go to the top of the command history, ctrl-a and ctrl-e to move to the beginning or end of a line, and ctrl-n and ctrl-p to move up and down through the command history.

This article was originally published on Thursday Jan 8th 2004
Mobile Site | Full Site