SysAdmin to SysAdmin: Linux is the Unix reference implementation

138

Author: Brian Jones

When you quit picking on Windows and start picking on Unix vendors for not being “Linuxy” enough, you’ve become a true zealot. However, if you consider administration, education, software development,
and the labor market (at least in the U.S.), the notion of Linux being the de facto standard Unix starts to look a little less goofy.

I know a ton of admins, and I can’t think of any two who took the same
path to becoming an administrator. Some of the guys who’ve been around
for 15 or 20 years got their starts as operators. Whatever is going on today
with regards to deploying services, they were probably around when it was
invented. To these guys, Unix is pretty much Unix. Sure, there are
religious affinities — BSD vs. System V, etc. but for the most part, they’ve
seen so much that as long as something looks something like Unix,
they can adapt. I do not believe this group is what you’d call a majority
of today’s administrators.

A number of administrators actually came through academia, and hold a degree in computer science, electrical engineering, math, physics, or other departments where computing resources are heavily used and vital to research. For many years, academia was a “mixed bag” environment; deployments were based either on who was donating resources, or (in the event that money actually had to be spent) what best fit the research needs. Many places still have Tru64, IRIX, QNX, OS/2, and other older operating systems being heavily used and fully supported by the local administrative team. However, there has been a great deal of consolidation of these disparate systems over the past few years. As systems
fall out of favor or are no longer supported (or made, in some cases), and as Linux continues to become a more robust platform, administrators are happy to move users and researchers to Linux in the interest of having a more consistent environment.

In addition, teaching labs have been moving to Linux in droves. These labs teach students about operating systems by looking at actual OS source code. By using Linux, they can look at the source code of a system that is actually widely used in large production environments. To top it all off, the software is free, and they can recycle old PCs to learn about bleeding-edge technology.

A few doors down from true academia, there are the continuing education providers. They’re the ones who send out catalogs full of courses that cover anything from Cisco CCIE certification prep to how to use FrontPage. Many of these places offer some sort of Unix training, and of those, almost all use Linux to teach Unix. In fact, there are plenty of examples where the course is listed as (to quote a catalog from a school in my area) “Intro to Unix using Linux.” I found only two or three (of about 15) who used something other than Linux, and in all of those cases, the alternative was Solaris.

Software development

The technology base for Unix software development has been moving steadily toward Linux for some time. IBM is the probably the most widely known and vocal Linux advocate from the “gosh they’re big”
software vendor group. IBM ported its Lotus suite, its DB2 Universal Database, and the Tivoli suite of applications to Linux. This, coupled with “end-to-end” services that support IBM hardware and various software suites (some of it not even IBM’s own) running on Linux, has helped Linux penetrate further into the corporate data center.

IBM is not alone in its commitment. I found (and subsequently lost the link) a quote on the SAP site which read “Linux is the reference Unix implementation” for their developers. Now that’s a vote of confidence. SAP has not only ported a robust collection of its software to Linux, including the mySAP suite, it actually open sourced its SAP DB database, and partnered with MySQL AB to distribute it under the MaxDB brand. The MaxDB-branded database is available under the same dual license as MySQL.

Oracle has also been heavily into Linux
development for some time. I bought my copy of Oracle 8i for Linux in 2000,
when I was working for Sybase, an Oracle competitor. I wondered why Sybase
didn’t do the same thing. Since then, Oracle hasn’t let up a bit, and has
ported, to my knowledge, its entire software collection to Linux.
“Oracle’s continued support of Linux is illustrated in the move of our core
product development teams — for both the database and applications — to the
operating system,” says Wim Coekaerts, director of Linux Engineering, Oracle
Corp. “Oracle has been committed to furthering Linux since 1998 when we
introduced the first database to run on the operating system. That commitment
remains unaltered today.” Many of you will remember Wim
from a Newsforge
interview
last September.

These are just a few of the commercial vendors betting the house
on Linux. Computer Associates, Check Point, Corel, Adobe, Veritas, and plenty of
other large software houses have been porting to Linux to various degrees. In
addition, software that was always typically developed on Linux has become much
more mainstream. For example, Apache is now bundled with Solaris (who also sell
their own distro these days), and GNOME also runs on Solaris. IBM bundled an
entire “Linux Affinity” toolkit with AIX 5L, which included prebuilt binaries
of open source software, along with header files to make compiling your own
that much easier. Yahoo, of course, makes heavy use of MySQL, and not only do
Yahoo developers code in PHP, they even hired PHP’s creator, Rasmus Lerdorf. Amazon, Google,
and eBay are just a few other enormous installations calling Linux their de facto Unix.

Administration

So where does that leave administrators? Well, it’s really not all beer and
skittles yet. Fact is, this idea of Linux as the reference Unix
implementation doesn’t seem to be as widely held a notion as we’d all probably
like. As a result, instead of having something that “just works” in the Linux
world, commercial Unix vendors are forever trying to integrate their platforms
and the rest of their software offerings, in part as a means of selling
services to deploy, maintain, and otherwise support the stuff, all under
the guise of making things easier on us, the admins.

I think I speak for a good number of admins when I say “make it
work like the standard says it should first, worry about the fancy stuff
later.” It’s true that we’re not all working in 100% Linux environments, but
the exposure we’ve had to systems that just work has been refreshing and
enlightening. As a result, when we see other Unix variants not playing nicely
with Linux, the cause is likely some special feature the other Unix vendor developed to make
for their flavor of whatever service you’re trying to
deploy. What you hear from the vendor is generally along the lines of “we can’t
test with everything, and it works fine with our product.” I can only imagine
that quotes like this are meant to encourage you to try their product. If
that’s the case, I have a message for the Unix vendors: It’s backfiring. I’d
sooner replace an expensive RISC system running a proprietary Unix with
Linux/x86 than reward a vendor for not doing things the right way.

So what is the right way? Here are the choices as I see them: The first way is
that product features and implementation details are decided by committee with
little or no input from either the user or developer community. The second way
is that product features and implementations are hashed out in public forums
involving a worldwide community of administrators, developers, and end users.
The result of the first choice, in my experience, is that you need support from a vendor who never dreamed
anyone would ever use their product the way you’re planning to use it (this
after a sales guy said “yeah, it’s done like that everywhere”). The result of
the second way, in my experience, is that the product takes a little bit more
time to mature, but is tested to support scenarios you couldn’t imagine anyone
implementing. I’ll take door number 2, thanks.

In conclusion

My opinions are drawn from observations and discussions with people who deploy or
develop for Linux and Unix in production environments, or use Linux for
teaching (or, conversely, learning). With articles proclaiming The Importance of
Linux
, and tons of reports saying that Linux is taking more market share
from Unix than anything else, and quotes from large software houses saying
“we’re doing Linux,” I would hope that the other Unix vendors
might take note and understand that their mantra now, like it or not,
is “integrate, or disintegrate.”