[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: how to make Debian less fragile (long and philosophical)



This a lengthy thread, so much of the original content has been removed.

On Sun, 15 Aug 1999, Dale Scheetz wrote:

> <lots of good stuff removed>
> 
> Well, I _do_ think stability and reliability are "central" issues for
> Debian, I just think we have a different idea about how to accomplish
> that, that doesn't include static binaries.
>
> <---snip--->
> 
> I _do_ think we should provide some static packages for recovery purposes
> for those folks like yourself who feel more comfortable with that sort of
> "backup system", but I don't think we should redesign the distribution to
> be more UNIX like in this regard. Linux is derived from UNIX, but it
> _isn't_ UNIX. Debian is unique in many ways with respect to other Linux
> distributions. I'm not sure we want to move in the direction you are
> suggesting, but I _am_ willing to be convinced.

Unless I'm reading this incorrectly, I think there is a bit of a
misunderstanding going on here.  I don't think that Mr. Wells wants the
entire base distribution compiled with static binaries.  He just would
like to see a set of statically compiled tools for use when something goes
wrong with the system.  NOT because Debian's stable release software isn't
top-notch.  It is.  I've had a dozen boxes in production since early 1997,
and have had no serious failures attributable to Debian.  (I run only
stable.)  Things that have failed are either the kernel itself or
hardware.  And this, I think, is key to Mr. Wells' point.  When the /usr
partition turns to mush, you'd like to be able to boot your system and
have enough tools to try to salvage something, or maybe even start a
restore.  Instead of trying to have a superfloppy with 30MB of tools on
it, if you have statically linked binaries, you can run them from
/target/bin/tool and not have to work about dependencies on libraries,
which may (also) be whacked.  I think that the worst thing I ever had to
do on a Debian box was recreate enough device files in /dev so that the
box could boot. I couldn't tell you what happened to them (some other form
of makedevbadness? ;), but my system was toast, and MAKEDEV wouldn't run.

I don't think that this isn't a "Unix-thing," it's a best of practice
technique that has slowly developed over the years for operating systems
which provide dynamic linking.  It's the Right Thing, like package
dependencies.  (Ever trashed a Win95 box by loading some software that
includes a few of the system .DLLs of older versions?  This is because
there !#$@ installer doesn't protect against this sort of stuff.)  I was
working at a PPT that told Hewlett-Packard that they would get their
payment for support ($600k) when they would supply a version of HP-UX that
had statically-linked binaries in /bin and /sbin.  This was just a couple
of years back.  As to your comment about Linux not being UNIX, I think
that with the demise of NCR, SCO (or did Novell buy it) is the only UNIX
out there. HP-UX, Solarix, OSF/1, etc. are all Unix-like systems, just
like Linux.  The point being made for robustness is not with intent to
mimic others, but to help put a copy of Debian in data centers everywhere,
and keep it there.

What I envision is a set of binaries, not even part of the normal path,
which are statically linked to be used in emergency down situations.  I'm
undecided about the package tool, but tend to believe that a
statically-linked version of it could be handy.  If we're getting the
point were we have to decide if Debian is going to be a server OS or a
workstation OS, then perhaps an alternate set of the critical base
packages for use by those of us who run Debian for a living would help.

I hope that acts as a FUD-buster.  If it doesn't, then I *really* don't
know what you guys are arguing about.

  tony@mancill.com         |  I find no absolution
http://www.debian.org      |     in my rational point of view.
                           |        (Peart)





Reply to: