2.4 and ‘the Red Hat operating system’

Apparently PR types think that Red Hat
Linux has become a separate and distinct operating system.
The
question is, are they right? And is it a problem?

What is an operating system in Linux? Or are there several? Or is
there
even such a thing? Is Linux really “an” operating system, as opposed to a codebase
of
software elements you can use to concoct anything you want (as long as
you
document it in detail)?

The question seems particularly relevant now that version 2.4 of the
kernel has been released by Linus Torvald et al. The kernel is a
relatively
small part of any effective Linux-based operating system; a common
kernel
does not make for a common operating system. In many cases, the kernel itself has
been heavily patched and tweaked. The inevitable result is interoperability
and
compatibility problems.

Sometimes all the patching is the natural result of developers
trying to
adapt Linux to architectures that it was never intended for. When SuSE
or
IBM or Red Hat (or whoever) announces that it has “adapted” Linux to
run
on a mainframe or a PDA or a toaster oven or whatever — I chuckle to
myself.
These various devices have fundamentally different architectures, and
all
sorts of quite radical changes have to be made to Linux’s codebase in
order
to generate a functioning system. It may be “Open Source” but should
the
results of such an effort even be considered Linux?

More troubling are commercial distributions that veer away from the
“standard” to the degree that code compiled on one distro doesn’t work
on
another distributor’s Linux. That’s become an issue, particularly with
Red
Hat 7.0. It’s not really news to the more dedicated members of the
Linux
community that code compiled on 7.0 has tended to do really weird stuff
(like not run) when the resulting code is used on another version of
Linux.

The result has been the one thing corporate systems people dread —
unpredictable, non-portable software.

It may be that this “fork,” if it is a fork, is some sort of
temporary
aberration. As Linus Torvalds himself said, 7.0 had a “idiotic … broken” development-quality, third-party compiler. This
sort
of problem was inevitable. After all, 7.0 was released during the big
Linux
explosion when the resources of all commercial developers were severely
strained trying to meet the demands of their customer base and their
investors. Stuff happens. Red Hat has already announced that patches
and
fixes are available.

But there are lots of other niggling deviations from one version of
Linux to
another, and the variations among distros have increased over time.
Perhaps
the release of the 2.4 kernel will spur Red Hat and other commercial
developers to make sure their products are truly compatible. However,
re-integration is not easy to accomplish. The history of software
development suggests that once a platform has begun to split away from
its
parents, it stays that way. The many and varied attempts of commercial
Unix
developers to re-connect their platforms over the years is instructive
here.

Most enthusiasts will suggest that the problem really isn’t
a
problem. After all, Torvalds has suggested that Linux code is
a
compromise between various contending visions and that some patching “for
specific uses” is part of the natural evolution of the code. That may
be
true. And it may also be true that Open source code allows would-be
users to
adopt and re-compile code to their hearts content, theoretically
limiting
the impact of software incompatibilities.

But that’s unlikely to reassure the beleaguered corporate IT manager
wants the software he bought to run on the platform he owns, and who
has
neither the time nor the expertise to be messing about with each and
every
software element in his system, or monitoring corporate listserves to
pick
up the most recent patch to the software that he assumed was going to
work
when he bought it. If incompatibilities begin to become a serious
problem,
that manager is likely to either:

• “Standardize” on one distro — in effect treating it like a
  separate
  and distinct operating system, or
• Avoid Open Source software as inherently unreliable.

Neither is a good thing for the long-term prospects of Linux and
Open
Source.

NewsForge editors read and respond to comments posted on our discussion page.