[svlug] Choice of Linus to Install
Karsten M. Self
karsten at linuxmafia.com
Fri Aug 13 12:25:30 PDT 2004
Please do *not* CC on list posts.
on Sun, Aug 08, 2004 at 05:27:11PM -0700, Brian Street (brian.street at bayarea.net) wrote:
> Karsten M. Self wrote:
> >on Fri, Aug 06, 2004 at 02:52:32AM -0700, Richard Evans
> >(rgevans at rawbw.com) wrote:
> >>I know I am asking for it..
> I'd like to think I'm a relatively experienced, and competent, system
> administrator across multiple OSes (multiple unix and windows) but
> light on linux in particular.
Well! Get cracking then!
If you've got general Unix experience, Linux will be pretty familiar
overall. Distros vary, but generally it's most similar to Solaris/HPUX,
with bits and pieces borrowed from all over. If you're familiar with
the Nemeth books, take a look at her Linux version released a couple of
The major differences are greater transparancy, and greater currency, in
Linux. If you're already using the GNU toolset, you're going to find
most of userland is very familiar. If you aren't, you're likely to be
> I've been a lurker on this mailing list for awhile and can't say as I
> recall seeing anything that says these linux versions are better for
> firewall applications versus application/file servers. Do they break
> down in this fashion or is distinguishing factors more along the lines
> of ability/ease/timeliness of upgrades?
I'd say discriminating characteristics are more a matter of marketing
influence and top-tier vendor relationships than anything. And that
these are highly orthogonal to overall technical quality. Within
specified regimes (say, Linux-on-Mainframe), vendor relations and
support levels are likely going to strongly favor certain distros (eg:
In the firewall space, a distro which allows you to minimize the total
build and exposure is going to be strongly favored. Here I'd put
OpenBSD (not a Linux distro, but a BSD) and Debian GNU/Linux as the
primary candidates, though there are also specifically tailored
microdistros. Which raises another fact: there are several hundred
"distributions" of GNU/Linux, ranging from the top three (Debian, RH,
SuSE) through other general distros (Xandros, Lindows, Mandrake), and
then many, many specialized distros focussing on specific application
areas, architectures, national regions (eg: China, Brazil), security
(SELinux, STRONG Linux), clustering (Mosix, Beowulf), or boot
configurations (LNX-BBC, tomsrtbt, Knoppix...). Etc.
There are also numerous turnkey firewall systems which bundle both
distro and hardware, in which case the decision's already made for you,
though you _should_ perform due-dilligence to find out what the
underlying base system is. The medium^Wdistro is the message^Wsystem.
In a corporate environment, RH and SuSE are likely going to lead because
of their marketing and partnership operations, though Debian is a strong
contender, and does have a very strong tier-one supporter in HP. For
those who'd think that a corporate distro is a positive selling point,
I'll note the cautionary tales of a certain outfit formerly known as
Caldera (now a smoking crater operation), and of Red Hat's radical
changes in vendor support plans with the transition to RHEL. Both
transitions left many organizations in the lurch. There's a somewhat
paradoxical stability in banking on a community-based distribution.
> I would wager a guess that certain distros are quicker to include the
> latest features than others as well as timely support (as in how fast
> do they fix bugs) or is this again more a personal opinion as seems to
> be the case with so many distros.
Debian's offered a mix of currency vs. stability in its stable vs.
unstalbe (and now testing and experimental) releases for most of a
decade. Recently, other major distros have been following a similar
tack, as with Fedora Core, (and formerly Rawhide), and similar type
Truth is, "latest" features largely boil down to:
- Kernel-level support, generally of devices, though also for
performance and scalability enhancements. This is pretty much
independent of any other system components, and can be applied to
systems of any vintage. If you're looking at firewalling and the
like, iptables/ipchains and related features are also
- Core system library enhancements. These are complex and highly
interdependent relationships, and are _not_ easily applied to
existing systems, absent significant other upgrades. This is where
Debian's package management and policy systems excel.
- Application-specific enhancements. Features available in a more
current version of an application. This could be desktop apps
(GNOME, OpenOffice, Mozilla), services (Exim vs. Exim4, Apache vs.
Apach2, BIND8 vs. BIND9), languages (Perl 5 vs. Perl6, Python vs.
Python 2), etc. These may or may not be dependent on library
features, which could result in greater or lesser interdependencies.
Again, Debian excells in resolving these relationships.
So it's really a matter of what it is that you really need, and what
trade-offs (stability, availability, compatibility) you're willing to
> One of the reasons I ask is that a selling factor, from a corporate
> viewpoint, for installing OTS Unix (I would never, given the choice,
> put company critical applications on M$ - but in the real world we
> don't usually have this choice for a variety of reasons) vs. Linux is
> that I can always call the manufacturer for support when my butt is on
> the line. In the linux world (yes, there are a couple of companies
> that provide paid technical support for linux distros) most of the
> support comes from a mailing list...or am I missing the boat on this
There are numerous options for Linux support, ranging from mailing lists
and IRC support to tier one vendors for the top three leading distros.
Including Debian. There are also other options ranging from independent
consultants to mid-tier VARs offering support services. Some of these
will advertise in various venues such as Linux Journal, on the Debian
Project's Consultants page, etc.
> Another reason for asking, is to find out what arguments have been
> used to successfully bring in the first linux servers to the M$ world
> (as is the case I'm trying to make at the moment). I can certainly
> argue the upfront cost and uptime but that might not be enough to sway
> the jury.
The single most compelling argument is increased control over your own
internal corporate/organizational systems. Ultimately, control
translates to control over costs.
The up-front cost argument is a bit murky. *Any* conversion of existing
systems will involve costs, and those costs will almost always exceed
the apparent costs of continuing the status quo.
However, the status quo itself will involve transitions. If you're
currently running Win2K or Win2K3, there's eventual Longhorn migration.
If you're still running NT Server, you're already on an EOL'd product.
The key selling points, in general, are:
- Choice. Linux is about choice. Of distributions, of vendors, of
hardware, of architectures, of deployment models, of software.
While there are certainly a set of generally favored configurations,
if they don't suit your business/organizational needs, you can
change them. You're not stuck with a "single seamless integrated"
solution -- or as they say in the Army: one size fits none. Fit
your information systems to your business, not vice versa.
- Low aquisition cost. The software, by and large, _is_ freely
available. And while free-as-in-speech is what many people
emphasize, I feel that free-as-in-beer matters too.
- Easy replication. Whether for additional rollouts, failover,
redundancy, testing purposes, it's generally trivial from a
procedural standpoint, and fully alloweed from a licensing
standpoint, to clone or extend additional systems from an existing
deployment. No special tools or additional licensing required.
- Security. Operationally, there are far fewer security issues with
Linux systems than legacy MS Windows systems. Microsoft has been
trying for years to promote FUD saying it ain't so, but that doesn't
change the fact that there are far better tools to see what's
running on a Linux system, to minimize what's running on a Linux
system, and simply, to minimize what's on a system to reduce its
exposure profile, in ways which simply aren't possible under legacy
MS Windows. Any boss, regardless of hair pointiness, is going to
know about spyware and viruses. These are simply not problems on
the Linux side of the house.
- Flexibility. You can deploy Linux as workstations or servers, as
thin clients, as mixed-model deployments (eg: NFS mounted /usr and
/home), on a wide range of hardware. Often you can retain existing
hardware otherwise long past its useful life, though you may want to
upgrade some components (video and NIC being the most likely).
That's a $10 - $50 investment in extending equipment life for years.
- Capability. Between available software, scalability, access, and
local customization, there's little that Linux cannot do, and
virtually no imposed artificial limits. If you can identify
*specific* legacy needs which aren't met by Linux, then by all means
deploy legacy OSs to deal with them. Otherwise, look at a
transition plan involving incremental migration. For servers, that
means services moved one at a time to a Linux system and checking
for any incompatibilities resulting. For desktops, it means
breaking your Microsoft dependency cycle with apps such as
OpenOffice, Mozilla, and the GIMP, and transitioning a few key power
users to a part-time remote desktop (Cygwin's X server is very
useful for this), before making a complete cutover. Remote access,
WINE, Crossover Office, and VMWare can patch in as needed, but
you'll find those needs are likely few. The really key ingredients
are planning, time, and selling the upside.
1. Though as I've said before and I'll say again, this isn't something
we want to be *too* smug about. Though much of this is due to the
Linux/Unix architecture and security model which prevents ordinary
users from writing to system files and directories, it's also
dependent on applications being written in sane ways, such that they
don't arbitrarially execute (or allow execution) of untrusted
programs. Still, the highly modular structure of Linux/Unix means
that you're far less likely to be stuck with single-source, take-it-
or-leave-it spaghettiware which tangles functionality deeply between
what should be wholly independent and features.
Karsten M. Self <karsten at linuxmafia.com> http://linuxmafia.com/~karsten
Ceterum censeo, Caldera delenda est.
More information about the svlug