Re: itp: static bins / resolving static debian issues
So, you quote the least likely need for static binaries, and then
conclude that all the other cases are equally unlikely.
Oh well, logicians have words for that too: attacking a straw man.
By far the most common cause of dynamic library failure is administrator
error, followed closely by package manager error. And the most common
case where it's needed is not a system that is highly reliable, but
one that is far away. Sure you can get to it--but it's costly, if you
can make the upgrade work remotely you save either time or money or
maybe just buy yourself a few more hours of sleep.
The more extreme cases do exist, though their probabilities are less.
The clinching arugment, which you have still failed to address, despite
my repeatedly begging for someone to address it, is why you would deny
this critical redundancy when its cost is absolutely negligible.
Justin
On Tue, Aug 24, 1999 at 03:08:36PM +0200, Marcus Brinkmann wrote:
> Hi,
>
> On Tue, Aug 24, 1999 at 07:56:36AM -0400, Justin Wells wrote:
> >
> > Finally I am not certain I agree that a disk error ONLY increases with
> > the number of blocks on a given medium. If the disk error is actually
> > caused by a buggy kernel, or buggy memory, then it is also likely to
> > increase linearly with the number of inodes. Since a typical dynamic
> > depends on 10-12 inodes, and a typical static depends on only 2
> > (itself plus the directory it is in) once again the probability
> > of a dynamic getting wiped out is much higher.
>
> Mathematicians have a word for this: It's called pathological cases. If I
> were you, I would be much more concerned about the user data when I have
> faulty memory or a buggy kernel. If you are worried about 10 inodes vs 2,
> but not about data corruption of your data files, something is very wrong.
> Better shut down the machine as fast as possible, before people get annoyed
> by subtle errors in their data.
>
> All the cases you propose have a very low likelihood. If you have buggy
> RAM's you better replace them, so you have to shut down the machine anyway.
> The frame where it is actually useful to bugger around with static binaries
> when the hardwrae is broken is so short that it is not worth to take
> preparations for it.
>
> Indeed, with every example you give I feel more confident that static
> binaries are hardly needed at all in a sane environment (reliable hardware,
> stable software releases, not messing around with the working system).
>
> The cases where live recovery with static binaries seem to be useful point to
> a wrong concept of system management to me (on a high reliability server, you
> don't update the software when clients connect etc). There are a few servers
> who need absolutely high uptime. Such a setup is so special that Debian
> can't support it by default.
>
> It seems clear to me by now that you have absolutely failed to provide sound
> technical arguments for the need of static binaries by default on a
> standard system.
>
> Thanks,
> 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
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: