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

Re: core recovery tools, apt-get, and dpkg should be static



Anthony Towns <aj@azure.humbug.org.au> writes:

> On Mon, Aug 16, 1999 at 12:44:34PM -0400, Justin Wells wrote:
> 
> May I summarise your proposal briefly?
> 
> 	* You want statically linked recovery stuff to be standard.
> 
> 	* You mainly want this so you can recover from your own mistakes
> 	  (or other less clueful admin's mistakes on the same box, say)
> 
> Your main argument is:
> 
> 	* Dynamic linking is a single point of failure, that can entirely
> 	  wreck your weekend, and static linking of the tools you need to
> 	  recover is a good way of avoiding it.

And arguments against it are:

        * static binaries are bigger (disk and RAM, which is a problem)
        * Dynamic linking gives one point of failure, but also one
          point to repair and not 50 bins to revert to the previous
          version
        * static binaries must be updated more often and are bigger,
          increasing bandwith and download costs

The only benefit from static linking is, that removing libc doesn't
break the system anymore. And thats not worth the space, ram and time,
bandwith and downloadcosts. If the lib is broken, all statically
linked binaries will break also with the update.

...
> So here are some alternatives.
> 
> (1) Do nothing. Not very interesting.

The only option in my eyes.

> (2) Make sash.deb priority standard, or at least make it more obvious so
>     that people who have any idea why static linking might be a good thing
>     can say "Ooooo. I want that" and be thankful for it later.

The rescue disk is such cases and any work should go to make a better
rescue system, that boots from CD and/or creates a zip with everything
needed.

> (3) Make ash the default /bin/sh. ash links to libc6 and ld-linux, whereas
>     bash links to libreadline, ncurses, libdl, as well as libc6 and
>     ld-linux. Risk reduction isn't as good as risk removal, but it
>     ain't bad. Theoretically improves bootup speed, and probably means
>     bashisms become a lot less common.

No script using /bin/sh may use any bashisms and if they use /bin/bash 
having sash won't help.
 
> > The current reliance on dynamic linking is not acceptable for a production
> > server that is administered remotely, or where downtime is to be avoided
> > at all costs.
> 
> Please cut the hyperbole. Lots of people manage this well enough already
> in just such a situation. Yes, having statically linked binaries would be
> nice, but -- shock! horror! -- Debian already works fairly well without
> them.

My old, small Amiga couldn't boot with statically linked
binaries. Even 8 MB would probably not last until swap is started.

May the Source be with you.
                        Goswin


Reply to: