Re: MJR on Linux/OSS

[David Lang <david.lang () digitalinsight com>]

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" butt-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