Last week, we took a stab at prepping readers for this week’s LinuxWorld Expo in
New York City. We failed, however, to make the two guaranteed slam-dunk predictions we could make every year: Somewhere, someone is going to say “this is the year Linux finally arrived in the enterprise” and that someone, somewhere is going to say “this is the year Linux will finally arrive on the desktop.”
Tux takes the enterprise — but not for the reasons you’re probably thinking. We highlight the big news to come out of this week’s LinuxWorld Expo. SCO takes its gripe with the GPL to the U.S. Congress. We dust-off ‘du,’ a more single-minded (and simpler) version of the find tool.
So much for an easy opportunity to look prescient and nail down a consulting gig somewhere. All the same, a lot of news did come out of LinuxWorld that helps make the case, even if people have been making it since Oracle turned up on Linux several years ago.
We believe, however, that the cautious voices from within the Linux community itself are more indicative about how mature Linux has become than the array of product releases, partnerships, and certifications we will highlight later in this column.
A prime example of this theory is the hesitation surrounding the latest kernel release.
Several weeks ago, we considered a minor tempest over the new Linux 2.6 kernel. The long and short of the issue was concern over the effect a new kernel release, and the subsequent freeze on development of the 2.4 kernel, would have on the overall project. We didn’t see a lot to worry about because when it comes to refining Linux, we believe much of the work is going on in places outside of the very public mailing list arena of the project proper.
At the same time, we raised, and subsequently walked past, a more troubling issue that came up the last time a new Linux kernel was released: the disconnect between the needs of Linux enthusiasts (the gratification of playing with something new) and enterprises (stability).
When Linux 2.4 was released, an admin of our acquaintance was so overcome with the “thrill of the new” that he executed an upgrade from the old 2.2 kernel to the new 2.4 version before a single point release came out — on production servers. An
informal poll of other Linux users left us unsettled: Several had done the same; others just hadn’t gotten around to it but would soon.
At the risk of having to turn in our Linux Fan Club decoder ring, we’ll admit that even now, a few years down the road, this strikes us as one of the sillier things we’ve heard. It’s almost as silly as the part-time admin who told us that using Linux as a Web server was impossible since with the advent of the graphical browser Unix variants would start crashing because they were text-based.
So we were relieved to hear a voice from within the Linux community advocating caution about the new kernel and the
implications of upgrading right away.
The Open Source Development Lab, an Oregon-based consortium, is very involved with prepping Linux for enterprise deployment. Its director, Tim Witham, was on hand at LinuxWorld. He noted that the thing to be doing with a new Linux kernel at the moment is testing, not deploying.
Throughout the years we’ve heard people grumble that the continual development Linux undergoes out in the open is discomfiting and nervewracking. We beg to differ. With some software companies, which we will refrain from naming, an opaque development process combined with a sense that the profferred upgrades and patches tend to be all-or-nothing affairs is a lot more troubling. During the next several months, and throughout the year, a moderately dedicated admin or IT manager will
be able to watch Linux vendors and notes for Linux point releases (which our sister site, LinuxToday, posts with regularity) and make informed choices on when this kernel is ripe for deployment.
We’ve tussled with the question of IP indemnification more
than once, and come down somewhere in the middle: It’s a nice guarantee if you
can get it. IBM, which is embroiled in a suit with SCO over intellectual property issues, remains steadfast in its insistence that indemnification isn’t necessary.
This week, the company stuck to its guns. Red Hat, which has also avoided offering indemnification, did, too, but in a less
pointed manner. The company announced the Open Source Assurance Program (OSAP). The key feature of OSAP is what Red Hat calls an Intellectual Property Warranty. It doesn’t offer indemnification but rather a promise that if infringing code is found in something Red Hat sells, Red Hat will sanitize its product of the infringement.
We see one possible snag in its logic. Part of the whole issue with SCO’s numerous suits and general conduct has been a disinterest in identifying infringing code and allowing the alleged infringer a chance to clean it up. It’s an easy distinction for Red Hat to miss since, unlike SCO, Red Hat makes money from selling things, not litigating over them.
This week’s parade of announcements about software and hardware from LinuxWorld has the pundits talking about how “Linux is now enterprise ready” (a statement as predictable as kabuki and has been since, well, the last century). Here are some highlights to come out of the show:
In SCO news, several sites around the Web linked to a leaked letter,
(that’s a 370 KB PDF) apparently meant for U.S. legislators. Hopefully
the likely download time or the clumsiness of reading PDFs in a
browser window will scare most people off. We’ve gotta report this
stuff, but as we’ve stressed time
and again,
SCO’s public denunciations of Linux and the GNU Public License veer
between distortion and unintentional McCarthy-era kitsch. Little in this letter
is different from previous assertions.
SCO also launched a “slander of title” lawsuit against Novell for its claim that SCO doesn’t own as much of UNIX as it claims it does.
Everyone busy at LinuxWorld made for a quiet week on the security front. We did, however, catch one widespread patch for slocate, a secure replacement for the locate command, which allows users to find files by
searching a regularly updated index instead of crawling through the file system each time with a find command. Several vendors have reported patches. The bug could allow a malicious local user to gain access to every entry in the slocate database, providing potentially compromising information.
Highlighting the news coming out of LinuxWorld has left us short of space, so a quick tip this week:
You may remember our tip about how to use find to locate large files. Well there’s another handy tool that does the same thing: du, which is more single-minded than
find and, perhaps not incidentally, a little easier to master.
du returns the file size of every file beneath the current working directory and takes quite a few arguments to modify that basic behavior. The most useful are the -h switch to specify “human-readable” size reporting (KBs and MBs instead of blocks), the -c switch to report the grand total of all files in a given hierarchy, and the –max-depth argument to limit how far down the directory tree du searches.
This week, Enterprise Unix Roundup offers a tip of the hat to regular tip contributor Ed Heil.
Property of TechnologyAdvice. © 2025 TechnologyAdvice. All Rights Reserved
Advertiser Disclosure: Some of the products that appear on this site are from companies from which TechnologyAdvice receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. TechnologyAdvice does not include all companies or all types of products available in the marketplace.