Re: how to make Debian less fragile (long and philosophical)
Justin, I suggst you take a close look at how dpkg handles upgrades of
itself before speading all this FUD.
Justin Wells wrote:
>
> 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
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
--
see shy jo
Reply to: