Re: itp: static bins / resolving static debian issues
On Tue, Aug 24, 1999 at 03:48:50AM -0400, Justin Wells wrote:
>
> So let me demolish the above notion, and establish what the
> technically meritous arguments behind including statics by
> default are.
You are doing a dangerous thing here. You try to apply mathematical concepts
to a matter of that is not of mathematical nature. You can't proof that the
recovery proposals you propose are needed and should be included by default
on every system. You can merely try to convince many people that they will
help many people and try to convince the rest of us that they don't harm.
I will now reveal three mystic trues to you:
* Not everything that can be done, should be done.
* Not everything that works for you works for everybody else.
* Deeds are more convincing than words.
This means:
* That we can improve the overall recovery possibilities does not mean that
we should do so. We should only do so if the costs are low and the benefit
is high.
A default static bin package would increase the cost for everyone using a
default system, and benefit only the few who know about it, know how to use
it and want to use it instead other recovery measures. So it seems that
the accumulated costs are too high and the benefit too low.
* That you can improve the overall recovery possibility for your systems by
using static binaries does not mean that we should make it the default for
all Debian systems.
Nobody has denied that static binaries can help under some circumstances.
But it seems that the people who would use them are few and they would
only use them infrequently, so it is not a good way to improve the overall
stability on all standard Debian systems.
* Words are cheap. People who want to change the world do something about
it.
I suggest you make a rcovery package as you would like to see it. Priority
"extra", section "admin".
If the package is so useful how you claim, people will use it and it can
climb up in the priority ladder. If it is really small and great and useful,
it can become the default later, when it is finished and tested.
There is no way Debian will promise you that it will be included by
default on all standard Debian systems. We ca only evaluate existing
software, not vapourware. Details maybe critical.
"Put up or shut up."
> Proposition #1-- There are kinds of servers for which downtime is
> considered unacceptable
Debian is a general purpose distrbution, not a high end server distribution.
You are free to base your distribution on Debian and make the default
whatever you want.
> Proposition #3-- Debian should, by default, support servers where
> downtime is unacceptable or difficult.
This is wrong. It should support them, but NOT by default but by installing
additional packages.
> Proof: Much of this portion is opinion; but I challenge you to try
> adding a policy statement to the contrary.
The contrary is NOT that Debian should not support such servers at all. The
contrary is that it should not support them by DEFAULT. This IS already
written in policy, read the definitions of the "required", "important" and
"standard" priorities in section 2.2.
> I believe that
> most Debian users (maybe not you) think this is important,
> if only for the sake of Debian's reputation as a server OS.
Believe is not strong enough. Your claim is null and void.
> Proposition #4-- Failure of the C library can occur under Debian
Proposition #4b-- Failure of the static recovery tools can occur under Debian
So what do you propose to do about it? Add another layer of recovery tools?
There are so many more situations where static tools are not useful for
recovery, so this does not back up your point at all. It does only proof
that static tools are not utterly useless, which we all know already
(otherwise we wouldn't talk to you at all).
> Proposition #6-- If a failure of the C library occurs, and the
> servers are still running, then on a system where
> downtime is considered unacceptable or difficult, you
> should fix the problem without a reboot if that is
> possible
> Proposition #7-- Debian should include by default whatever is
> required to fix the server as in #6, providing the
> cost of including these services are not too high
This is wrong. An additional requirement is that the benefit is high.
Proposition #6 is a very narrow occurence, a situation which will occure on
very few systems over time, so it is not suitable as default.
> Proposition #9-- Statics recovery tools are more fault tolerant
> than dynamics equivalents
>
> Proof: Dynamics typically depend on a large number of files, and
> the failure of any of those files will bring the dynamic
> binary down.
This is correct. It is also correct that static binaries are bigger and
failure of any of the blocks will bring the static binary down.
The overall size of all static binaries will not be very much smaller than
the overall size of dynmaic binaries plus shared library, so again the
benefit of static binaries is much smaller than you claim.
The number of files is almost irrelevant. The number of blocks occupied is a
bit more relevant.
Indeed, it is worse with static binaries. If you loose sash, your recovery
environment becomes unusable. If I loose, let's say, mount, I still have all
other tools.
You are only shifting the weakness of the system from the libc6 library to
the recovery tools. This is not such a big deal as you claim. You could also
set up a redundant environment with dynamic bins, for example a chroot
environment.
Any system that Proposition #6 applies to will also need hardware
measurements like RAID.
> For example, bash depends on:
> -- bash, libncurses.so.4 (symlink), libncurses.so.4.2,
> libdl.so.2 (symlink), libdl.so.2.1.2, libc.so.6
> (symlink), libc-2.1.2.so, ld-linux.so.2, and
> until recently on libreadline as well (2 files)
> whereas sash depends on only one file (sash). Thus there
> are eight (previously 10) files upon which bash depends,
> but only one on which sash depends.
Thus if sash breaks, your whole recovery environment goes down. Great.
> Proposition #11-- Static Recovery binaries do not use a lot of
> system resources, such as memory, disk, or CPU
This depends on the hardware you have.
As you want to make it the default, you have to add up the space occupied on
ALL systems. This is much too high.
> Proposition #12-- The presence of static recovery tools will
> not pose any difficulties to ordinary use of the system
Every byte counts on low end hardware, which we also support and which is
more common than high end servers.
> Proposition #13-- Static binaries can be provided with negligible cost
Wrong. Only on the server systems you describe. Not on a 4 MB Ram i386 with
a 80 MB hard disk.
> Conclusion: Debian should provide static binaries
Yes, but NOT by default.
> These were desktop machines,
> but no matter--the experience of needing statics was the same.
Proposition: What works for you is not what works for everybody else.
Proof: I did always well with a boot disk or a second root partition.
> The truth is I still don't know whether reliability and stability
> are important issues here, since several people have bluntly told
> me that live recovery is not what 99% of Debian users need and
> therefore I should go away.
Your perception is wrong. We don't need it by DEFAULT.
You seem to fail to understand the fundamental points:
Make it optional, it can become the default later if it is good.
Put up or shut up.
The only thing people sets up is your world-saving attitude. Many people do
well without static binaries, and instead wasting your time on trying to
convince us otherwise you better work on something that can be used.
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@
Marcus Brinkmann GNU http://www.gnu.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Reply to: