Re: core recovery tools, apt-get, and dpkg should be static
I think you'd be surprised to learn how little RAM we're talking
about here. Especially if the statics used old libc rather than
glibc (sh, ls and dd certainly don't need to be multi-threaded,
and don't require any advanced support from the C library).
First, none of the system install, upgrade, and maintenance commands
are an issue at all--you likely never run multiple copies of fdisk,
fsck, mke2fs, mknod, restore, ifconfig, route, and so forth. A lot
of these you might even drop to single user mode before running
(assuming there were multiple people logging into your box, and
you wanted them off your box before doing maintenance).
Second, all the users logged into your system will likely choose
the dynamic /bin/bash as their shell, rather than the small and
static /bin/sh (-->/bin/ash) that has been proposed.
Third, even if all the common unix commands such as ls, dd, cp,
mkdir, rm, kill, sleep, ps, ln, mv, df, and chmod were statically
linked, the truth is you just don't run them that often. You might
run one of these commands once every minute or so, if you are
busily doing shell stuff. 'ls' in particular might get run once
every twenty or thirty seconds--but nothing more than that, and
it would take a LOT of users on your machine doing this before
it would add up to more than 500-600k at any given time.
If you actually analyze it, we're talking about very small
amounts of memory here, in excange for a large increase in
the reliability of the system.
Also it's worth mentioning that these core unix tools do not need
to be multi-threaded, or take advantages of the latest glibc features.
It would probably be OK to link them, statically, against the old
libc, which would result in a big reduction in size.
But if finally you still somehow insist that you cannot afford
the extra 300k of RAM that static linking would cost you, then
yes they could be put in /sbin or somewhere like /stand instead,
and you could ignore them most of the time... until your system
failed. And the package manager could live in /sbin too and
not rely on dynamic linking.
Justin
On Tue, Aug 17, 1999 at 01:24:08PM -0700, Chris Waters wrote:
>
> Here's a suggestion: what if we make statically linked versions of
> some of these basic tools *available*, but *don't* make them
> standard. Let people choose for themselves how to manage their
> systems, and which risks are worth what costs.
>
> Personally, I am very much opposed to the idea of making statically
> linked versions standard. My motherboard is already at its limit for
> RAM -- I can't add any more. So a proposal to make the system use a
> lot more RAM *by default* is not something I can support.
>
> But as an *option*, I think it would be fine. I agree that it may
> have advantages in certain cases (cases that don't apply to me at this
> point, but still...).
>
> The only question then becomes, should the statically linked packages
> conflict or co-exist with the dynamically linked ones? I think
> co-existence is better, but obviously more work. But co-existence
> probably increases the chance that the statically linked binaries will
> survive a hostile break-in.
>
> --
> Chris Waters xtifr@dsp.net | I have a truly elegant proof of the
> or xtifr@debian.org | above, but it is too long to fit into
> http://www.dsp.net/xtifr | this .signature file.
>
>
> --
> To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: