Re: [fw-wiz] MJR on Linux/OSS

From: David Lang (david.lang_at_digitalinsight.com)
Date: 03/13/05

  • Next message: Crispin Cowan: "Re: [fw-wiz] MJR on Linux/OSS" 
    To: "Marcus J. Ranum" <mjr@ranum.com>
Date: Sat, 12 Mar 2005 20:04:22 -0800 (PST)

    Marcus, while I definantly agree with you that the differences between
    distros is hurting things, I will say that there are some valid reasons
    for splitting things and creating a new distro (while also saying that
    there are some very bad ones). I'll start with the caviot that I don't
    know the various *bsd systems (I tried BSDI once for a couple months, but
    didn't see advantages worth the effort and went back to the Linux distros
    that I was more familiar with.)

    we've seen the bad reasons from the Unix wars where each distro went for
    vendor lock-in. I believe that we are seeing this from RedHat to some
    degree, they are the king of the hill and would like to stay there.

    another big problem we've seen over the last several years is the distros
    significantly modifying the kernel, in some cases to the point where the
    standard kernels are incompatable (RedHat is the biggest offender, but
    they are far from the only one). Hopefully the changes in the 2.6
    development model

    however there have also been good reasons for different distros, Primarily
    this boils down to trying new ways of doing things, sometimes it works,
    sometimes it doesn't

    Package management is a big example

    The early systems didn't have any package management at all, you just got
    the distro and then compiled whatever other software that you needed.
       This works well until you start having multiple different options for a
    given job and want to switch from one to the other

    Slackware has about the mose minimalistic package management you can get
    away with, it basicly uses tarballs with a few scripts to allow you to
    remove and upgrade the packages.

    RedHat significantly improved this with the RPM packages becouse you
    gained an ability to have dependancies

    Debian took this a bit further and has the ability to have several levels
    of dependancies, ranging from 'must-have' to 'it will let you add a couple
    features', and then also can suggest that 'if you've put this in you
    probably want this other thing as well'

    Gentoo has basicly turned things on their ear and is going back to the
    early 'compile everything' approach, but by defining packages in terms of
    HOW to compile and install that package.

    however (with the exception of the Gentoo system) there are tools out
    there to convert packages from one format to another so that is seldom a
    huge problem

    Another area that has drift (and this one hurts the sysadmins) is boot
    configuration and sequencing.

    From the Unix wars we started off with two basic systems

    the *bsd approach (sets of interrelated scripts that call each other)
    and the SysV approach (lots of independant scripts that start and stop one
    particular thing)

    arguments can be made for both systems, but overall it appears that the
    SysV system is winning (but there are a number of holdouts, but even they
    useually support the SysV approach as well as their native bsd approach)
    so any packages being installed should provide the SysV scripts

    however from here there have been problems. At the time RedHat started
    there was a Linux standard, designed for bsd startup scripts that
    specified that they should be in /etc/rc.d, RedHat eliminated the bsd
    scripts (useing SysV scripts), but instead of putting them in the normal
    place they put them in /etc/rc.d/rcX.d instead. And then to make things
    worse (from a vendor neutral sysadmin perspective) they didn't leave the
    scripts self contained, they made them call other scripts, parse other
    config files, etc (analyse the bootup sequence some time, you will come
    away cringing). From there other distros have been attempting to 'fix' the
    problems, but each has their own idea of what's right (and frankly I don't
    really like any of them)

    for the bootup process things are very much in flux, and are likly to get
    worse. the emphysis on creating nice GUI tools to manage a box is tending
    towards creating config files that are easy for the GUI tools to deal
    with, and then hacking the boot scripts to somehow use these files (and
    since most of the GUI developers weren't sysadmins to begin with this is
    getting even worse)

    What I believe that the correct approach for this problem will be is to
    write more intellagent GUI tools that can actually understand the startup
    scripts and modify them rather then adding layers of indirection to
    everything. but this is a lot more work and it's wasier for the tool
    writers to change the startup scripts :-(

    in terms of compatability between different distros, the biggest
    fundamental problem is that existing tools and knoledge aren't being used.

    Libraries are versioned, and it's easy to check what versions are
    available on a system, but third-party software developers don't make use
    of this. I've moved software from one distro to another and asked vendors
    what libraries they need and in most cases the vendor can't tell me. they
    just say 'RedHat version X full install'. now even if I am useing RedHat
    version X, I am certinly not doing a full install of it and so it's very
    possible that I won't have all the libraries on the system and am on my
    own to figure out what I need to make it work.

    the LSB is addressing this by trying to define the minimum set of things
    that will be on a linux box. unfortunantly they suffer from a couple
    problems

    1. they are viewed by many as rubber-stamping anything RedHat
    2. the minimums are going to be either so minimal that they're useless, or
    so complete that many people won't want that much installed on their
    system

    what is needed is the tools (and recognition that the tools should be
    used) for the developers to say what libraries they need (and the minimum
    versions of those libraries). big bonus points to vendors who actually
    pick their minimum nessasary version based on it's API and bugs rather
    then what happens to be installed in distro X version Y

    on the library writers side there needs to be better regression testing to
    make sure that if a package says it needs library version X then it will
    really work with version X+n

    the only real good news on this front is that people are concerned about
    it. companies have blown it and made the wrong decisions in the past, but
    are (for the most part) trying to figure out how to get out of the holes
    they have dug for themselves. unfortunantly there are still a small number
    that really would like to lock their customers in to useing only their
    distro (or at least they act like this is their motive)

    David Lang

      On Wed, 9 Mar 2005, Marcus
    J. Ranum wrote:

    > Date: Wed, 09 Mar 2005 22:53:19 -0500
    > From: Marcus J. Ranum <mjr@ranum.com>
    > To: R. DuFresne <dufresne@sysinfo.com>,
    > Devdas Bhagat <devdas@dvb.homelinux.org>
    > Cc: "'firewall-wizards@honor.icsalabs.com'"
    > <firewall-wizards@honor.icsalabs.com>
    > Subject: Re: [fw-wiz] MJR on Linux/OSS
    >
    >
    >> So, marcus, which dist did you end up with? <smirk>
    >
    > I couldn't find my BSDI disks. :(
    > So I would up using RedHat ES. And, of course, the BSD-db
    > code that built fine on Fedora didn't work right on it for mysterious
    > pthreads-related reasons that I refuse to take the time to figure out.
    > Why should I have to?
    >
    > What the Open Source advocates just don't seem to get is
    > that "fragmentation" didn't just *happen*. I think it's pathetic
    > that people are now arguing about how to converge on a
    > common Linux interface spec. Excuse me? There was
    > one Linux spec, back when Linux came out. Fragmentation
    > was a choice (and a bad one) made by enough members
    > of the Open Source community. For ego reasons, financial
    > reasons, or sheer "not invented here" ***-headedness, we
    > now have some ridiculously huge number of distributions of
    > an operating system that, fundamentally, is not different
    > enough to be interesting. Ditto on the BSD camp. I used
    > BSDI and it was good. I don't give a rat's ass about the
    > personality conflicts and ego-puffery that brought us
    > OpenBSD and FreeBSD and whatnot. I observe that
    > this kind of playground attitude is not going to beat
    > Microsoft.
    >
    > Aside from ego-reasons, who needs 60 different versions
    > of UNIX? Scott McNealy was right when he suggested, "all
    > the wood behind one arrow" - I suspect that most UNIX
    > users would be thrilled to death if there was just one darned
    > UNIX again. I wouldn't care which. I can adapt O/S knowledge
    > in a couple weeks. I just don't want to do it every week. :)
    >
    > Bah, this is a useless discussion. Everyone wants to
    > reach for immortality by being a contributor in "the big thing"
    > it's not actually about accomplishing an objective, it's
    > about posing, stylin' and having fun on the journey. :( A
    > bunch of amateurs is not going to beat Microsoft, no
    > matter how much I wish they could.
    >
    > mjr.
    >
    > _______________________________________________
    > firewall-wizards mailing list
    > firewall-wizards@honor.icsalabs.com
    > http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
    > 

    -- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare
_______________________________________________
firewall-wizards mailing list
firewall-wizards@honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
  • Next message: Crispin Cowan: "Re: [fw-wiz] MJR on Linux/OSS"