[PLUG] For The SysAdmin Gurus

Alan Olsen alan.olsen at gmail.com
Wed Aug 30 17:55:11 UTC 2006


On 8/26/06, plug_0 at robinson-west.com <plug_0 at robinson-west.com> wrote:
>
> Quoting Jeme A Brelin <jeme at brelin.net>:
>
> >
> > On Tue, 15 Aug 2006, Rich Shepard wrote:
> > >  We seem to be eliminating possibilties, and fixing broken links along
> > > the way. I look forward to your next suggestion for me to check out.
> >
> > I think Wil and Michael's points are best taken now.  If you had broken
> > softlinks, your package management system is failing you.
> >
> > You could go around hunting these little problems for ages and you will
> to
> > get this little printing problem resolved.  And then you can go around
> > hunting a new set of problems when you encounter the next error...
> >
> > Or you could go to a systemic fix.  Debian Stable does seem to be
> exactly
> > what you need.
>
> Slackware 10.1 is a lot easier to network boot than Fedora Core 1.  A lot
> of
> people say that slackware's rc scripts are easier to imderstand than
> Fedora's
> init scripts.


Fedora Core 1 has a number of issues.  Fedora Core 5 is much more stable.

As for Slackware init scripts...  It depends on what you mean by readable.
Almost all Redhat init scripts look alike.  Once you understand how one
works, the rest are simple.  Slackware init scripts are from the bad old
days of Solaris style tangled init script.  If you are used to them, they
are not too bad, but they are still a mess and they are very hard for an
installer to work with without serious kludges.  (I had to build a Slackware
box reciently.  I was amazed how little they had learned from the
experiences of others since 1995.


> The way the pango etc. libraries are twisted into packages, I question if
> there is a Linux distribution today that isn't library and dependency
> hell.
> I think a library manager would be far more helpful than a package manager
> if indeed a library is broken.  I wonder if http://www.linuxprinting.org/
> has a mailing list where this problem is mentioned?


The problem of library interdependacies is distro independant.  Each handle
it differently.

The problem is library interface changes and security.

If you have a program that wants version 1.1.1 of library foo and another
that wants 1.2.0, what do you do?  Keep both? What if there is a security
related bug in version 1.1.1? Do you backport the patch to 1.1.1 from 1.2.0?
What if it is a rewrite?  Multiple libraries are a pain.  RPM handles it by
adding in compat-foo packages and then trying to backport packages.  I
assume Debian does something similar.  Slackware just lets you have
overlapping libraries.  Who knows if they get patched.



> On package management being so hyped by people, that's exactly why my
> oldest brother abandoned Debian.  He got overwhelmed by Debian wanting
> to install kde on him.  Being a slackware fan before, he still had
> problems with dependencies in Debian.  I think he's back to Slackware,
> though he could just be an OSX user.


The problem becomes knowing what to install and why.  Software in Linux is
becoming more and more interconnected.  As libraries use chunks from other
libraries, it generates this big web of dependancies.  Because the packager
is usually trying to address the largest audience as possible, they drag in
more and more packages.  The only way to get out of this is to break
packages the Slackwear way or use Gentoo and build just what you need.


According to the posted interview, Fedora is not bleeding edge.  I've had
> problems more often with CentOs more than I have with Fedora.  Fedora does
> seem to be getting fat though.  Fortunately, the focus now appears to be
> trimming  the fat.  Is there a free up-to-date maximum rpm floating
> around?



I have been looking at building an "core and extras" set of dvds for FC5.
Just to busy trying to get Compiz to work on my laptop.

For the most part, I have been very happy with Fedora.  Yes it is bleeding
edge, but that is because they are trying to do useful things.  If they
didn't, it would not be as useful.



More information about the PLUG mailing list