Re: how to make Debian less fragile (long and philosophical)
On Mon, Aug 16, 1999 at 10:45:17PM -0400, Michael Stone wrote:
> Dynamic linking provides these benefits:
> 1) Saves space.
optimization issue
> 2) Removes the need for seperate rescue and run-time binaries.
optimization issue
> 3) Easier to update critical binaries in the event that a library flaw
> is discovered. (E.g., security problem or correctness issue.)
optimization issue
> and has this flaw:
> 4) Library damage can prevent binaries from working.
recovery issue
> You can poo-poo point 1. For most people this isn't a real big issue.
> Another 20-30M isn't a huge chunk on a modern hard disk. We do have some
> users with older systems, but they can cope.
I suppose we need real numbers here.
> Point 2 is a little harder. This is a volunteer effort. It's hard
> enough sometimes for people to maintain their packages without
> maintaining an extra set of them. You could put the static versions
> in /sbin instead of breaking them off in a seperate dir, but then
> you waste RAM instead of hd space. (Dynamic libs are loaded once,
> static libs are loaded for each binary.) It's a tradeoff, just like
> everything else in a distribution.
I'm confused by this line of argument, but I'll try to break it down:
(a) consider the possibility that the static versions will be
maintained by different maintainers than the dynamic versions (presumably
not updated as often either). [Perhaps I should do it, since I'm
so interested in the subject.]
(b) the directory where something is stored has nothing to do with how
much ram the executable consumes. [Anyways, ram consumption has little
to do with point 2.]
> Point 3 is more thought-provoking. If you statically link everything
> then any libc update means updating 30 packages by 30 different
> maintainers rather than a updating a single libc package.
Not really.
libc update usually doesn't matter for the key administrative programs.
Where it does matter, it may be advantageous to update the administrative
programs well before libc is ready for general consumption. [Of course,
if we have both dynamic and static versions of these programs there's
the added complexity of deciding to switch which program you're using
under non-emergency circumstances -- which is a plausible argument in
favor of not having two distinct instances/versions of the same program.]
> Against the pros of dynamic linking, you have a single con: a damaged
> library can prevent programs from loading. But as I said earlier:
> what are the odds that a massive failure will affect only libraries?
(1) This con is in a different class from the pros. More generally,
premature optimization is bad.
(2) there are other potential failure modes besides massive disk failure
where these precautions would be vaild.
I don't think all users will want to take these precautions, just as
I'm sure that many of our users don't perform regular backups. Like
you say: it is a tradeoff.
> If even one of your static binaries is destroyed, you're in the same
> place that you were with a broken library.
Again, not really.
More likely you're forced to operate under degraded (inconvenient)
circumstances. But you've got more chances at working around the
problem if you have some working executables.
> (E.g., a disk problem or a bad case of the dumbs wiped out /dev and
> /lib. You've got static bins, but mknod also got wiped out. Bummer.)
Well, if sash is working you could use its built-in -mknod.
If it's not maybe you've got uudecode [or some other way of quoting
binary characters] (which might mean you can paste a program into a
running session).
> For static bins to be useful you need a particular combination of
> disaster and luck.
Knowing your way around the system also helps.
> Optimizing for that combination is like writing an algorithm for
> best-case performance: I can't say that it never helps, but it buys
> you nothing when you really need it.
In general, if you have a shell or can obtain a shell you're a lot
better off than if you cannot.
> If a particular machine has to be highly available, it needs more than
> static binaries.
Very true.
> What do I think a machine needs to be reliable? Here's a couple for
> starters: 1) A backup root disk. It's easy, it's cheap in today's
> market, and it buys me protection from both hardware and human error.
> (Even static binaries quail in the face of rm.) 2) A serial console.
> If some disaster is pulling the rug out from under my server, I don't
> want to rely on its network interface. There's too much that can go
> wrong, and I can't boot over it. 3) A failover machine. Sometimes
> things really do break.
In many circumstances these are good practices.
However, this is far from complete. You wouldn't expect that a backup
root disk would replace a regular backups -- why expect it to replace
static binaries?
> That's exactly right. That's why you don't screw around with a
> production system unless you have a way out. And that's why you don't
> run a production system unless you have a way to compensate for
> catastrophic failure. And that has nothing to do with static binaries.
I disagree -- static binaries are just one of many ways to compensate
for catastrophic failure.
I agree that there are many classes of catastrophic failures which
static binaries can do nothing for. However, I've run into several
real life cases where static binaries have helped (or: would have
helped).
--
Raul
Reply to: