Enterprise Unix Roundup: Dawdling to the Barricades With SCO
November 26, 2003
There's a sign popular among middle managers that reads "the beatings will stop when morale improves." SCO's variation on that might be "the suing will start unless revenue improves."
During the past week SCO announced that an unspecified Linux-using company somewhere out there among the 1,500 SCO has been menacing with the threat of litigation since May will be the unhappy target of a lawsuit meant to enforce SCO's claims that every Linux user is, in fact, a SCO user.
One attorney we read this week said there's a company out there "with a target on its back," which isn't quite accurate. Until SCO gets around to revealing which "uncooperative" and "high profile" corporate Linux user is in the crosshairs, every company has a target on its back.
With each passing day, SCO's legal maneuvers are looking more and more like a shakedown fueled by fear instead of facts. Since first announcing its suit against IBM at the beginning of the year, SCO has behaved with the least amount of transparency one can imagine, considering the far-reaching nature of the case it claims to have. Licensees are never named, targets of litigation are never announced, and infringements aren't displayed to the alleged infringers so a remedy, if one is even required, can be applied before more "damage" is done.
This latest announcement looks less to us like a warning and more like yet another threat aimed at pushing a company without the legal resources to survive protracted litigation into blinking first. All so SCO can claim a settlement and grant the overall case legitimacy it has yet to establish in the courts of law or public opinion.
Perhaps the most damaging thing for SCO's case is less the unhappy muttering of the computing world at large, than it is a typically cautious assessment from Gartner, which urges its clients to ignore SCO's demands for money until the court case with IBM, scheduled for 2005, is resolved. In addition, Gartner believes SCO is in danger of becoming increasingly beholden to the attorneys it has retained.
"We believe that these moves," writes Gartner analyst George Weiss, "compromise SCO's mission as a software company."
Weiss points out one more thing we have to agree with, though:
So far, few Linux companies have stepped up with assurances that they'll cover the court costs of companies adopting their products, should SCO actually get around to suing anyone besides IBM. Hewlett-Packard has done this, and Sun has done it to a limited extent. But what about Red Hat? Part of the strength of the Red Hat brand is its near synonymous association with Linux. That, in our view, confers some responsibility, too.
In Other News
So how is it that a project team can remain confident of the integrity of its data after a computer break-in? One way to handle it is with md5 fingerprinting.
md5 is an algorithm in which a given file is, based on its contents, assigned a unique "fingerprint" or "digest" value: a string of letters and numbers that md5 won't recreate with any other file, regardless of how minor the variations. It's also not, in the words of md5's creator, "mathematically feasible" to produce a file with a pre-specified target fingerprint.
In the GNU world, m5sum is how one goes about applying the power of md5 to file fingerprinting. Consider, for example, a collection of three tarballs named huey.tar.gz, dewey.tar.gz, and louie.tar.gz, which are the sole tarballs in a given directory.
Running the command md5sum *.tar.gz might produce output like:
The long string of numbers and letters in the first column is each file's fingerprint. Redirecting md5's output to a file (using the command, for instance, md5sum *.tar.gz > ducks.fingerprints and storing that file in a physically secure place (perhaps on CDROM in a vault) guarantees that there's a small, reliable record of each file's unique fingerprint. Following a security breach, the list can be used to confirm that files in a given archive are valid using md5sum's "check" option: md5sum -cv ducks.fingerprints, which should return output like this:
If it didn't, and returned instead "FAILED" next to any of those files, it means the file has been modified since it was first fingerprinted, which means you might have a problem on your hands you'll need to investigate.
Unix BookshelfThe holiday season is upon us, and since we're pretty big fans of the well-selected book as presents, we've decided to add a new section to the Roundup for the next several editions: The Unix Bookshelf.
With those in the United States looking ahead to a long holiday weekend, and one where they might not want to spend too much time on technical reading, our first recommendation is a light one. Better yet, the stores won't even have to be open for you to grab a copy, since it's available online: "In the Beginning Was the Command Line", by Neal Stephenson.
Weighing in at 151 pages, "Command Line" isn't so much a technical book as it is a book about the distinct computing cultures found in the worlds of Unix (primarily through the author's experiences with Linux), Macintosh, and Windows. If books like "The Unix Philosophy" provide a programmatic approach to why Unix is the way it is, "Command Line" provides the case for why Unix should be the way it is, and it does so with a light touch.
One thing that dates the book (it was first published in 1999) is the author's fascination with BeOS as a sort of harmonious convergence between the Macintosh and Unix computing cultures. BeOS, of course, is no longer a real contender, and the Macintosh has become that convergence with its adoption of a Unix kernel and accompanying tool set.
There's still plenty to enjoy about it, however. Stephenson is one of our better current science fiction writers, and his style shows through. It isn't often that the Russian Revolution is connected with the rise of graphical interfaces, nor do many Unix writers ever get around to mentioning Disney's EPCOT center (let alone calling it "creepy"), but Stephenson pulls all that and more into his metaphors.
"Unix people" will like this book because it provides a right-brained defense of their preferences, which is something that's pretty rare in the computing world. Non-Unix people may not like what they read but might still come away with an understanding of the value of the Unix ideal in terms of its underlying literacy and transparency.