Re: how to make Debian less fragile (long and philosophical)
On Sun, Aug 15, 1999 at 08:20:24AM -0400, Dale Scheetz wrote:
> > Or is stability, reliability, and therefore cost-of-ownership a
> > non-issue with the Debian group?
> >
> and have we stopped beating our wives?
>
> It seems to me that you have missed a fundamental point:
>
> Potato is unstable. Unstable is, by definition "fragile". No one running a
> production machine is ever encouraged to use packages from unstable.
I'm not complaining that it actually crashed here, so much as I am
complaining that this is just a disaster waiting to happen, whether
potato is marked stable or unstable--it's fundamentally in there.
What was the reasoning for NOT doing this? Most other Unixes do
things this way. And according to the debian policy:
important:
Important programs, including those which one would expect to
find on any Unix-like system. If the expectation is that an
experienced Unix person who found it missing would say `What
the F*!@<+ is going on, where is foo', it must be in important.
This is an important criterion because we are trying to produce,
amongst other things, a free Unix. Other packages without
which the system will not run well or be usable must also be
here. This does not include Emacs, the X Window System, TeX
or any other large applications. The important packages are
just a bare minimum of commonly-expected and necessary tools.
So, I have been running Linux systems for five years now, and administered
all kinds of Unix stuff, and generally consider myself to be an experienced
Unix person.
So what the F*!@<+ is going on, where are static binaries? Why aren't they
installed by default? Why aren't they used by core system tools?
Let's look at other OS's: RedHat has, by default, a suite of static
binaries installed just for this purpose--including a static rpm.
Solaris has a bunch of static stuff in /sbin. All the BSD systems
have made anythign on / static. These are present on other systems
because they provide basic reliability guarnatees--where's Debian's
guarantee?
I basically expect this, and view it as crucial to the robustness
and reliability of a Unix system.
I was shocked to discover Debian doesn't install it by default, and in
my view, the recent problem is fundamentally a result of it.
> While staticly linked binaries would have avoided the recent brokenness in
> bash. It is not the solution to a "fragile" development process.
Yes it is, because bash is a hugely complicated and large program that
changes regularly. Eliminating a fundamental dependency on that, for
everything the installer does, is an enormous reduction in the number
of failure points. Huge.
The existence of dependencies such as this one makes the whole thing
fairly fragile, subject to being broken every time some human makes
an error in its vicinity. Since humans are prone to make errors, that
makes things fragile.
Bash is just one example, dpkg, apt-get, and dselect are fairly
complex as well, and should not be involved in circular or complex
dependencies under situations when the system may be unstable or broken.
It also makes a running Debian system fragile, because unless I went
out of my way to install the sash package, I'm going to be unable to
recover.
The basic point here was clearly reasoned out in my last message: If the
package manager tries to operate on itself, it ALWAYS risks messing
itself up. If it doesn't try to operate on itself, that risk GOES AWAY.
> How
> different would the situation be if the staticly linked bash (upgraded
> first to "guarantee" success of the rest of the install) was subtly broken
> such that certain crucial install processes fail. Now you are in the same
> boat as with dynamic linked brokenness.
A statically linked package manager could always bootstrap itself by
installing versions of itself into a new directory, and then manipulating
symlinks. Sure this is not 100% foolproof, but:
-- a statically linked shell is broken if it is broken
-- a dynamically linked shell is broken if it is broken, and
it is broken if any library it depends on fails to link, and
it is broken if any library it depends on is broken
I pointed out in my message that you can thoroughly test a statically
linked binary just once. But it is difficult to do the same for
dynamically linked binaries.
On top of that, as we can see in the current failure, the circular
dependency with readline brought bash down because in the end.
So there are many more ways to fail with dynamic binaries, and far fewer
ways to fail with static binaries.
Sure you can still fail, but it will be rare. A system which fails only
rarely is said to be "robust" and "reliable".
> The "problem" you are trying to fix is the frailty of human developers who
> don't always do the "right thing". Debian deals with these problems by
> having a publicly available "unstable" distribution, so that such problems
> may be discovered by those willing to risk breaking their systems to find
> them. It is not intended to provide the general user with the most
> up-to-date packages, as some folks seem to want to believe.
The problem is fundamentally there, in the stable distribution as well. Since
Debian is maintained by frail humans, and frail humans make mistakes, the
idea is to reduce the possibility for error.
> Can anyone think of a reason this would not be adequate?
Most Unix systems have on root recovery packages, and experienced
Unix users expect them to be there. According to the debian policy,
they should therefore be "important" and not something that is only
installed when specifically requested.
Aside from that, having a system installer that manipulates itself
introduces a turing problem where you just can't trust anything, since
it might mess itself up.
There are many Linux distributions for which stability and reliability
are not the central issues. Based on Debian's policy, I had thought this
was a main point of Debiasn--to be more reliable and stable than
other Linux distributions. Perhaps I just think that for no reason,
and it's not more of an issue here than elsewhere.
However, if it is, then you have to pay attention to details like
this: some basic guarantees that the system can fix itself are
important to a reliable system, and you can't have those guarantees
when the core system recovery and package managmeent tools have
complicated dependencies.
Justin
Reply to: